Re: Migrating to larger numbers

Richard Gooch (rgooch@atnf.csiro.au)
Tue, 8 Jun 1999 23:20:48 +1000


Raul Miller writes:
> Richard Gooch <rgooch@atnf.csiro.au> wrote:
> > > Dynamic numbers will break NFS guarantees when the server reboots.
> > > [And breaking NFS was one of the big arguments for not going to 64 bits.]
> > > Admittedly, not always -- just at the worst possible times.
> > >
> > > A proper solution to the generic problem would be to associate a device
> > > number with a configuration string via user space.
> >
> > Devfs doesn't mean dynamic device numbers. In fact, all drivers in the
> > device patch still have their old device numbers. Compatibility,
> > compatibility, compatibility.
>
> That's smoke and mirrors, and has nothing to do with the cases where
> devfs addresses a reason you'd want larger device numbers.

I'll point out that I'm not the one who said that devfs means we don't
need 64/128/256 bit device numbers a few email ago. And devfs wasn't
written to work around the current 16 bit limit (even though it could
be used that way). So I don't have to defend such a statement.

However, for the sake of argument, let's say we write device drivers
and make use of dynamic device numbers. I don't actually see where the
problem is. You can NFS export a devfs if you want others to see your
device nodes (of course, they can't actually access your drivers since
we don't have clustering). The only case I've heard where you would
even do this is to allow an NFS client to replace a device node with a
file, in case you're debugging an application in an install disc.

Another reason for exporting device nodes is for exporting root to
legacy machines. No problem. Populate a directory with device nodes as
we've done for ages and export that.

Looking in the reverse direction, mounting device nodes over NFS onto
a devfs-capable machine. Well, there's no point. This is only ever
done for discless clients. With devfs, this isn't necessary
anymore. It's like wanting to mount /proc from elsewhere.

> Please try to approach this honestly?

Please try not to be offensive.

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.tux.org/lkml/