Re: Flexible Console open (really little patch)

Richard Gooch (rgooch@atnf.csiro.au)
Fri, 21 Aug 1998 11:28:54 +1000

Nathan Hand writes:
>
>
> On Wed, 19 Aug 1998, Clifford Wolf wrote:
>
> > On Wed, 19 Aug 1998, Richard Gooch wrote:
> >
> > > > > As Matti has pointed out, you can have /dev/console sitting on your
> > > > > root device for use before devfs is mounted.
> > > >
> > > > Not if /dev does not exist, the exact problem I ran into with LRP,
> > > > which creates /dev/ from /linuxrc.
> > >
> > > Well, your initrd boot scripts could just create /dev/console for
> > > you.
> >
> > Not if the disk is (ro) at this point. Anyway: I really hate the idea of
> > mounting a disk/filesystem at a not-empty directory. It's as dirty as my
> > first suggestion of haveing /etc/console.
> >
> > > However, there is a better solution to this: replace the call to
> > > open(2) in init/main.c with code that allocates a file and calls
> > > chrdev_open() directly. That way, even if /dev/console doesn't exist
> > > on a non-devfs system, there are no problems.
> >
> > This sounds like a very good idea for me. I don't know the linux
> > filesystem code good enought to write this patch - but I would be
> > happy if someone else could implement this ...
>
> The solution is to keep /dev as a normal UNIX filesystem, with normal
> storage on disk, then nodes are entirely persistent across reboots.

But then you are left with all the disadvantages of the existing
scheme.

> Then devfs gets replaced by a user space daemon "devd" with some sort
> of communication to a kernel module "kdev".
>
> Any kernel changes are reported by kdev to devd. The devd then erases
> and creates /dev nodes using nothing more intelligent than unlink and
> mknod. Devd can perhaps discover needed nodes once, when starting.

Devfs can operate in this mode (using devfsd and mounting devfs
elsewhere). However devfs also provides other operating modes.

> The only loss from this system is you can't autoload a module just by
> accessing its (non-existant) /dev entry. I am not sure this is really
> an issue: the discover phase should do this in user space anyway, and
> I think it's confusing that "ls /dev" won't show an entry for devices
> you actually do have, as happens with the current system.

Devfs can operate in either mode. It can also be an advantage to have
autoloading of non-existent device entries.

> As far as I can tell, this solution addresses all the problems people
> have with bloat, persistence, strange new filesystems, missing nodes,
> races, weird changes to modprobe, putting policy in kernel, etc. It's
> also possible to get a Solaris-like system by starting devd up, using
> it once, then killing it.
>
> Are there any serious objections to this proposal? If not, I'll start
> coding it up this weekend as an alternative to devfs.

Unfortunately, it doesn't provide some of the other benefits of
devfs. For example, here's a new one that occurred to me: you can send
open events to devfsd which can then run a programme or script. This
can be used (for example) for modifying the ownership of /dev/dsp
which is normally not readable by everyone, upon open of console
devices. This works even if your login session crashes (note how the
utmp database is often wrong). It is also more general.

I've updated my devfs FAQ to explain this idea and others that you can
do with a true device management daemon.
See: http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.txt

Regards,

Richard....

-
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.altern.org/andrebalsa/doc/lkml-faq.html