Re: devfs: The conclusion.

karl (karl@ronin.u-net.com)
Mon, 10 Aug 1998 23:31:45 +0100 (GMT)


On Mon, 10 Aug 1998, Alan Cox wrote:

> > You sort of touched on something not really mentioned before here. If the
> > root partition is read only then /dev has to be separate, you cannot
>
> Sorry but thats not the case. The fact mingetty is broken on read only
> root file systems isnt at all a kernel problem. I've got working r/o /dev
> equipment.
>

hi alan

I'm not sure what in mingetty would break on a readonly root FS, however
the point I was trying to make is that your device nodes are subject to
change and that it not possible on a read only root FS with /dev on there.

For any program like login to do its task properly on a readonly root then
/dev has to be separate, eg ramdisk/devfs. It's just a question of getting
it right wrt memory usage.

> > How does POSIX relate to major/minor numbers. mknod isn't POSIX according
> > to my man page and I believe NTFS is a POSIX fs (whatever!!) but doesn't
> > support major/minor numbers. so what gives anybody.
>
> POSIX doesnt care. POSIX deals with the most generic I/O operations only
> in POSIX.1 - its not a unix standard its a general standard for behaviour
> thats designed to encompass stuff down to 8bit embedded kit.
>
> Unix98 is the relevant document but I dont have my access to it right now.
>

Thats what I thought. The POSIX argument was a red herring. Can you pass
any references to the relevant UNIX98 docs available, or are they closed.

Even if UNIX98 mandates having major/minor numbers, what is user space are
they used for except for displaying and creating devnames.

> > You probably can have various deamons running all the time just for
> > updating devnames but it seems a waste of resources.
>
> Daemons use less resources than devfs - because they are pageable
>

You are taking about richard's implementation there?

while you might have to run daemons for PCMCIA/USB etc, I'm not an
authority on that. You would have to include a ramdisk with a potentially
large collection of devnames within it, for a user space only solution.

As I said before, the waste is filling up kernel memory with devnames
especially ones not frequently used. So that collection of devnames
should be put to pageable memory, therefore only code for looking up
devnames (maybe a bit more?) is required in the kernel.

karl

-
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