Messages in this thread | | | Date | Tue, 8 Jun 1999 23:20:48 +1000 | From | Richard Gooch <> | Subject | Re: Migrating to larger numbers |
| |
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/
| |