:...
: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.
:
:Cheers,
:Alex
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.
-Matt
Matthew Dillon
<dil...@backplane.com>
