Re: Kerneltrap interview available

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:> Jeremy did another interview of me in Kernel Trap, here's the URL:
:
:Heh, judging by all the anonymous comments, somebody really has a bee in
:their pants over the whole SMP thing.  I better stop feeding those trolls.
:
:Dare I ask for the cold hard truth about the state of SMP on DragonFly?

    It's not actually that bad.  The main paths that need to be locked up
    are the I/O path (all the way through to the filesystem code, including
    the buffer cache) and the VM path (which is less important).  A
    per-process spinlock is also needed to handle MP safe operations in
    the presence of multiple threads (LWPs or rforked processes).
    Just about everything else is already coded MP safe, but still make
    general procedure calls into the kernel which are not yet coded MP safe.
    This is basically where the networking code is... MP safe except for
    mbuf statistics and mbuf dup/free paths.  Network drivers are serialized
    within themselves but still make kernel calls which are not MP safe.
    Protocol threads themselves are coded MP safe but do the same thing (make
    general calls that aren't).

    For userland applications we need to switch from libc_r to libthread_xu,
    which means figuring out what still needs to be done in that library to
    make it work properly with major applications.  KDE, Firefox, etc.
    There isn't a whole lot left that needs to be done there, its just a
    matter of tracking down the remaining issues.  We probably need to
    implement the various posix scheduling methodologies, too.

    SMP isn't on my priority list but that shouldn't stop anyone who wants
    to work on it.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>