Re: udev and devfs - The final word

[Mark Mielke <mark _at_ xxxxxxxxxxxxxx>]

On Sun, Jan 04, 2004 at 09:48:24PM -0600, Rob Landley wrote:
> On Sunday 04 January 2004 21:06, David Lang wrote:
> > Linus, what Andries is saying is that if you export a directory (say
> > /home) the process of exporting it somehow uses the /dev device number so
> > if the server reboots and gets a different device number for the partition
> > that /home is on the clients won't see it as the same export, breaking the
> > NFS requirement that a server can be rebooted.
> NFS always struck me as a peverse design.  "The fileserver must be
> stateless with regard to clients, even though maintainging state is
> what a filesystem DOES, and the point of the thing is to export a
> filesystem."  Okay...  (If it was exporting read-only filesystems
> with no locking of any kind, maybe they'd have a point, but come on
> guys...)

Statelessness translated to capacity back in the day when maintaining state
for hundreds or thousands of machines was expensive...

I don't buy NFS as an excuse, though. I refuse to believe that a
shared /dev is necessary or desirable for *any* environment. /dev/pts
is one example of where everybody seems to have already agreed on
this.

With udev, or with devfs, a shared /dev becomes unnecessary. /dev will
no longer need to be 7000+ entries. It could be a few hundred or less
for common configurations, and 0% persistence/remote storage for
tmpfs-udev or devfs.

There are a few cases that we might be forced to maintain regular
numbers: mkfifo() creates a named pipe, and bind() creates a named
socket. These might be accessed between reboots over NFS, or local
mounts by many existing programs. I think these must be guaranteed to
keep the same major:minor numbers across reboots (preferably, even
across kernel releases). These are exceptional cases, though, and
should be considered as such.

Cheers,
mark

-- 
mark _at_ mielke.cc/markm _at_ ncf.ca/markm _at_ nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo _at_ vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/