Re: PROPOSAL: /proc/dev

Richard Gooch (rgooch@atnf.CSIRO.AU)
Thu, 8 Jan 1998 12:22:58 +1100


david parsons writes:
> 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.)

OK, I should have been a little clearer. Once I have devfs working
(coming along nicely now), I'll modify the misc_register() function to
use that instead. People (like me:-) who want to play with it will
then mount it under /devfs or some such and place compatibility
symlinks in /dev. Alternatively, they could copy the contents of /dev
elsewhere and mount devfs onto /dev and install compatibility symlinks
in the devfs-based /dev. So all misc devices will work immediately
(early benefits for those writing miscellaneous device drivers)
without any porting effort and retaining backwards-compatibility.

Regards,

Richard....