Messages in this thread | | | From | (david parsons) | Subject | Re: [linux-usb] Re: USB device allocation | Date | 10 Oct 1999 19:30:20 -0700 |
| |
In article <linux.kernel.199910081727.KAA04826@zack.bitmover.com>, Zack Weinberg <zack@bitmover.com> wrote:
>If the user visible dev_t is changed, the new representation has to >obey a few simple constraints and all the system calls that pass >device numbers in and out of the kernel have to get new versions. >That's stat, fstat, lstat, mknod, and maybe a couple of ioctls. > >99% of user space code will not notice AT ALL. > >0.9% of user space code gets dev_t values from stat() and compares >them for equality. It will break mildly until the C library is >updated to use the new system calls. (Note glibc's dev_t is already >64 bits wide.) For example, a program has a chance of mistakenly >thinking that two files on different mounted filesystems - say, one on >device #3,2 and one on #258,2 - are the same file.
Or thinking that the two filesystems are the same.
As you point out, the gotchas won't happen very often, but they will happen.
I'd love to see dev_t pushed out to some unreasonable size (even with d*vfs; plan-9 namespaces are great, but backwards compatability is better) and the kernel version bumped up to 3.0 -- this would give a wonderful opportunity to widen out some of the overly constrained entry points (with a update document saying ``EVERYTHING YOU'VE EVER WRITTEN HAS JUST BROKEN. RECOMPILE IT ALL'', or the FreeBSD linux emulator could be ported to Linux for pdp-11, er, pre 3.0 code.) as well as discard some of the old interfaces (like the old fcntl interfaces.)
>David Parsons will have to put a larger dev_t into libc4.
It would give me a good opportunity to do libc7 and take out gnu db and curses, too.
____ david parsons \bi/ and with 3.0, we could put UDI into the kernel \/ and start scavenging device drivers from other operating systems.
- 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/
| |