MPSAFE TTY schedule - FreeBSD

This is a discussion on MPSAFE TTY schedule - FreeBSD ; Hello everyone, About 2 weeks ago I sent a message to these lists about the new MPSAFE TTY layer I've been working on. In my opinion, it is quite robust and after some minor polishing it should be a great ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: MPSAFE TTY schedule

  1. MPSAFE TTY schedule

    Hello everyone,

    About 2 weeks ago I sent a message to these lists about the new MPSAFE
    TTY layer I've been working on. In my opinion, it is quite robust and
    after some minor polishing it should be a great candidate for inclusion
    in FreeBSD -CURRENT (never to be MFC'd). The last 2 weeks I've ported
    all the console drivers and fixed some bugs after I received some
    feedback from testers.

    Below is a list of pros and cons of the new TTY layer:

    + The new TTY layer allows drivers to operate without the Giant lock.
    Drivers like uart(4), the console drivers and the pseudo-terminal
    driver already support fine grained locking.

    + The new pseudo-terminal driver is capable of garbage collecting unused
    PTY's. Because PTY's are never recycled, they are a lot more robust
    (they are always initialized the same, no need to revoke() them before
    usage, etc).

    + The new TTY layer includes a new buffer scheme called the ttyinq and
    ttyoutq. Unlike clists, they provide unbuffered copying of data back
    to userspace, making read() calls in raw mode more efficient.

    + The programming interface for kernel drivers is a lot more simple.
    There is no need to have any knowledge about the internal state
    of the TTY layer.

    - Not all drivers have been ported to the new TTY layer yet. These
    drivers still need to be ported: sio(4), cy(4), digi(4), ubser(4),
    uftdi(4), nmdm(4), ng_h4(4), ng_tty(4), snp(4), rp(4), rc(4), si(4),
    umodem(4), dcons(4).

    Even though drivers are very important to have, I am convinced we can
    get these working not long after the code as been integrated. I have
    considered adding two TTY layers to the FreeBSD kernel, but looking at
    the drivers, I'm not sure this is worth it, it turns certain parts of
    the kernel into rubbish. If you really care about one of these drivers,
    please port it to the new TTY layer as soon as possible!

    Below is the schedule I'm proposing for the integration of the MPSAFE
    TTY layer into our kernel. I would really appreciate it if I could get
    this code in before the end of the summer break, because I've got heaps
    of spare time to fix any problems then.

    July 2 2008 (today):
    Send a schedule to the lists about the integration of the MPSAFE
    TTY layer.

    July 13 2008:
    Make uart(4) the default serial port driver, instead of sio(4).
    sio(4) has not been ported to the new TTY layer and is very hard
    to do so. uart(4) has been proven to be more portable than
    sio(4) and already supports the hardware we need.

    July 20 2008:
    Send another heads-up to the lists about the new TTY layer.
    Kindly ask people to test the patchset, port more drivers, etc.

    August 3 2008:
    Disconnect drivers from the build that haven't been patched in
    the MPSAFE TTY branch.

    August 8 2008:
    Send the last heads-up to the lists, to warn people about the
    big commit.

    August 10 2008:
    Commit the new MPSAFE TTY driver in several commits (first
    commit the layer itself, then commit changes to drivers one by
    one).

    I'll stay close to my inbox the next couple of days after I've
    integrated the code, to make sure I can fix any bugs which may be
    spotted to be fixed shortly.

    Please, make sure we can make this a smooth transition by
    testing/reviewing my code. I tend to generate diffs very often. They can
    be downloaded here:

    http://www.il.fontys.nl/~ed/projects/mpsafetty/patches/

    Thanks!

    --
    Ed Schouten
    WWW: http://80386.nl/

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (FreeBSD)

    iEYEARECAAYFAkhr0k0ACgkQ52SDGA2eCwVIAACeI4NqzWRZ3S i7b5zhBdoCc6mM
    T3YAn2qvQJHuSgTeIZXFKkL2mDydJcLD
    =x78/
    -----END PGP SIGNATURE-----


  2. Re: MPSAFE TTY schedule

    Hello all,

    * Ed Schouten wrote:
    > July 13 2008:
    > Make uart(4) the default serial port driver, instead of sio(4).
    > sio(4) has not been ported to the new TTY layer and is very hard
    > to do so. uart(4) has been proven to be more portable than
    > sio(4) and already supports the hardware we need.


    Just a small message to inform that I've just changed the default serial
    port driver on amd64 and i386 to uart(4) (see SVN commit 180487). I've
    decided to leave pc98 as it is now, because I'd rather let the
    respective maintainers look into this.

    Thanks!

    --
    Ed Schouten
    WWW: http://80386.nl/

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (FreeBSD)

    iEYEARECAAYFAkh5rU4ACgkQ52SDGA2eCwX46QCfakX8RJ4yK4 ruWLSlgswPxi5C
    vgUAnjFKJ0Sati8+XcaJ9Hydzqzo1asT
    =+8SM
    -----END PGP SIGNATURE-----


  3. Re: MPSAFE TTY schedule

    Hello everyone,

    Today is July 20, which means I'm supposed to send you a message:

    * Ed Schouten wrote:
    > July 20 2008:
    > Send another heads-up to the lists about the new TTY layer.
    > Kindly ask people to test the patchset, port more drivers, etc.


    As usual, the latest mpsafetty patchset can be found here. I would
    really appreciate it if I could get more reviews on the code. Thanks!

    http://www.il.fontys.nl/~ed/projects/mpsafetty/patches/

    The following drivers have not been ported to the new TTY layer yet:

    cy(4), digi(4), ng_h4(4), ng_tty(4), nmdm(4),
    rc(4), rp(4), si(4), sio(4), snp(4), ubser(4).

    I've been working on nmdm(4). I'll probably get it working in time. If
    not it will be fixed not long after the integration next month. The line
    disciplines like snp(4), ng_tty(4) and ng_h4(4) can only be fixed after
    the import, because the hooks layer will be written after the import.

    In the other news: kris@ reported a possible performance regression to
    me. He discovered `make -C /usr/ports index' consumed more system time
    on his hardware when the mpsafetty patches were applied. For some
    reason, I'm not capable of reproducing them. I even experience a
    performance gain when running mpsafetty, which is quite plausible,
    because I've also made some small improvements to `struct session'
    locking, but we also don't pick up Giant in kern_proc.c anymore.

    Because kris@ committed a patch to improve `make index' performance
    yesterday, I re-ran my tests today, showing the performance difference
    is now nihil. Here are the raw numbers:

    http://80386.nl/files/mpsafetty-stats.txt

    Maybe someone is interested in performing more thorough benchmarks?

    Yours,
    --
    Ed Schouten
    WWW: http://80386.nl/

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (FreeBSD)

    iEYEARECAAYFAkiDMHgACgkQ52SDGA2eCwXIaACePBQ+9QntL3 faYFCyck8VOlOp
    C6QAn3E0Pd1dm3xBTa77pRrAbAvlPO5j
    =+NBc
    -----END PGP SIGNATURE-----


+ Reply to Thread