Re: My $0.02 on devd and devfs

Khimenko Victor (khim@sch57.msk.ru)
Tue, 12 Oct 1999 00:44:01 +0400 (MSD)


In <3802330C.B022D2FA@transmeta.com> H. Peter Anvin (hpa@transmeta.com) wrote:

> This seems to be a standing issue of yours, yet there is never any
> explanation of why this is a bad thing, at least not on the scale we're
> currently discussing. I get the feeling that it just looks messy, and
> that that offends you. Anyhow, as part of my "supermodule" proposal, I
> am trying to separate out probing code for the rather few remaining
> busses that need it - non-PnP ISA and what else?

1. SCSI. And SCSI will need TONS on devices. You can not hot plug SCSI device,
but you can forgot to power on external ZIP or scaner. And from kernel
viewpoint it's no better then non-PnP ISA. Even much worse: just one zip drive
will need tens of "devices" to handle possible partition schemes.
2. USB, Firmware, wantever with removaible media
3. Devices, connected via parport (there EXISTS autodetection, but it does
not work for all printers/cdroms/zips, etc)

>> Then there is the problem with dealing with removable media (where say
>> the partition number changes). Do you create all possible partition
>> nodes? If yes, more clutter. If no, how do you automatically rescan
>> the partition table and build the correct device nodes.

> The kernel has to be notified *anyway* when the partition table changes,
> so it is perfectly capable of invoking the notification mechanism. Not
> an issue.

You know when it's notified right now with devfs, do you ? When user tries to
access non-existing file with mount() ... Only then module will be loaded,
special file will be created and mount() will successfully mount filesystem.
That is: notification even come from user who tries to use non-existing
device. Such event is possible to use with devfs but not with devd and
disk-based /dev ...

>> Devfs handles these "inconvenient" cases much more cleanly.

> No difference.

See above. Try to turn on printer, do `cat something > /dev/printer/0` with
devfs and explain how it'll be handled with devd.

>> > > > > - since you need to store the device tree structure in the kernel
>> > > > > anyway (see above), you may as well allow it to be mounted, which
>> > > > > gives maximum flexibility to users (and adds very little extra
>> > > > > code).
>> > > >
>> > > > You don't need to store the device tree structure in the kernel.
>> > > > You only need to notify with the appropriate iterator, which is a
>> > > > much more condensed representation.
>> > >
>> > > OK, so you save a few pages, but you lose the autoloading and other
>> > > features.
>> >
>> > See above for autoloading.
>>
>> Which isn't dealt with as cleanly compared to devfs.

> I disagree that it is a significant difference.

It is. See above.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/