DragonFly kernel List (threaded) for 2009-05
DragonFly BSD
DragonFly kernel List (threaded) for 2009-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: GSoC: DevFS

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 14 May 2009 10:15:43 -0700 (PDT)

:I intend to keep a page on http://leaf.dragonflybsd.org/~alexh/ about
:the progress on DevFS. It currently is a bit outdated as there is still
:the original idea about a proposal for DevFS. Also, if you happen to
:look around, both the LLVM/clang and I/O Scheduler pages need a major
:overhaul; better to just ignore them right now.
:Sorry for the long mail, but I'm looking forward to hear any
:ideas/suggestions/comments about this.

    I'm looking forward to seeing this project!  We've needed a devfs
    for a very long time!

    Right now disks don't autoprobe but I think it would be fairly easy
    to make them autoprobe.  The slice table and disklabel is checked
    on-the-fly when first accessed.

    I think the core of the slice and disklabel probe is run via
    dsopen() in kern/subr_diskslice.c.  There are a lot of comments
    there that talk about not probing the slices the raw whole-disk is
    opened, and not probing the disklabel if a raw slice is opened
    (and not a partition under that slice).

    There is also a disk iterator in kern/subr_disk.c

    Clearly for devfs to work that stuff now needs to be autoprobed.
    However, for the purposes of a program opening the raw disk or a raw
    partition, those operations must work properly whether the slice &
    partition probe succeeds or not, since the slice/partition might
    not exist (but we still need to open the raw disk to initialize it),
    or if it is corrupted (we still need to open the raw disk to
    reinitialize the slice table or open the raw slice to initialize
    the disklabel).

    So there is some complexity here.

    I recommend that disk enmeration, re-enumeration, and handling of
    new disk devices or the removal of disk devices, be made the
    responsibility of a separate kernel thread, created by the kernel
    during boot.  In the past the attempt to do the enumeration in-line,
    synchronously via the device, has led to many problems.  Having a
    separate kernel thread which is integrated into devfs would make
    things a lot easier.

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]