Messages in this thread | | | From | (david parsons) | Subject | Re: PROPOSAL: /proc/dev | Date | 6 Jan 1998 20:21:04 -0800 |
| |
In article <linux.kernel.199801062131.IAA30449@vindaloo.atnf.csiro.au>, Richard Gooch <rgooch@atnf.CSIRO.AU> wrote: >david parsons writes: >> In article <linux.kernel.199801060945.UAA27719@vindaloo.atnf.csiro.au>, >> Richard Gooch <rgooch@atnf.CSIRO.AU> wrote: >> >> >Nope: if CONFIG_DEVFS is enabled then drivers can only be accessed >> >through devfs and symlinks to devfs. >> >> Ick. This screams of enforcing policy; if someone wanted to update a >> physical /dev from a devfs /devices (boot the machine, mount /devices, >> update /dev from the contents of /devices, unmount /devices), they'd be >> out of luck. And is it really worth the trouble to clutter up the >> kernel ensuring that people can't do this (and what about device drivers >> that have not been updated to populate a devfs; will support for them be >> dropped, subject to someone going back and eventually coding this change >> in?) > >Then don't use devfs.
I want a devfs so that I can have the kernel tell the outside world what devices exist. For things like ptys, I don't particularly care about a devfs -- the existing scheme is sufficient -- but for serial, parallel, ide, and scsi devices I'd much rather mount a magic filesystem instead of having to root through /proc/kmsg to find out what the kernel actually found (and, also, I remember the joy of chasing after minor numbers for secondary and tertiary IDE devices after the first few alphas of WebShield fell over laughing hysterically on IDE boxes; for this, having devfs actually TELL me what the major and minor numbers are is A Good Thing, because then I can have these numbers change in the future without hilarious consequences.)
Not using devfs wouldn't help here, unless I wanted to have my bootup process boot the machine with a devfs kernel, do an ls on the devfs filesystem, then reboot with a non-devfs kernel to interpret the results and properly populate /dev
>> david parsons \bi/ Working, intermittently, on his own devfs. > >When will it be ready?
Sometime between february and hell freezing over; I made the horrible mistake of doing a first cut inside /proc, which doesn't have the infrastructure I want (and hacking major and minor numbers into /proc is, umm, icky, particularly when you're an applications programmer like myself.) Now I actually have to learn how filesystems should work instead of my traditional method of taking chainsaws to existing code.
____ david parsons \bi/ It *did* nicely populate /proc/dev/sd*, even though \/ that population was basically worthless.
| |