> 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.
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.
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.
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.
-
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