In <88g1pn$6h1$1@cesium.transmeta.com> H. Peter Anvin (hpa@transmeta.com) wrote:
> Followup to: <200002162304.KAA05769@mobilix.atnf.CSIRO.AU>
> By author: Richard Gooch <rgooch@ras.ucalgary.ca>
> In newsgroup: linux.dev.kernel
>>
>> > c) whether kernel has update support or not is determined by whether
>> > the minor=184 is accessible (perhaps by loading a driver) or not.
>> > /proc does not make things much easier.
>>
>> It's much friendlier to the sysadmin or script writer to list the
>> directory or test for the file than to do a speculative open. I don't
>> know of a standard programme (say part of shell utils) that does this.
>>
> Isn't that how devfs expects to do module autoloading?
Yes. But situation is slightly different now with devfs. In early versions
there was only 1 /dev/vc/X initially (/dev/ttyX => /dev/vc/X with devfs).
When you tried to open /dev/vc/5 (starting mingetty on said consile, for
example) /dev/vc/5 was created. Now there are 64 /dev/vc/X files :-((
Of course if module for /dev/tss/1 (old name /dev/ttyS1) is not in memory
then there are no /dev/tts and /dev/tts/1. When you try to speculative
opne for /dev/tts/1 module (serial.o) is loaded and TWO nodes are created:
/dev/tts/0 & /dev/tts/1. That is: if MODULE for device is not in memory there
are no such device and you can do specilatiove open to load that module.
If module is loaded then ALL devices supported by that module are in /dev ...
That is: for ALL devices supported by kernel RIGHT NOW there are dev-entries.
Some things can be supported with additional modules: just try to use device
and if device is there kernel will load module and all will be fine.
I liked old style better but I can see reason for new style as well.
-
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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:18 EST