Date: Mon, 8 Jul 1996 15:24:52 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Cc: joerg_wunsch@uriah.heep.sax.de, current@freebsd.org Subject: Re: Which tools can back up inodes with 32bit minor numbers ? Message-ID: <199607082224.PAA22643@phaeton.artisoft.com> In-Reply-To: <199607071744.NAA15262@skynet.ctr.columbia.edu> from "Bill Paul" at Jul 7, 96 01:44:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Well, as i wrote, the existing static /dev is about to be killed > > anytime soon. MAKEDEV as well -- shouldn't you have it already > > noticed. > > Wrong. > > The existing /dev and MAKEDEV are _not_ going away any time soon. > Not on any of the systems I maintain anyway (including my personal > machines at home). You'll never catch me putting 'options DEVFS' in > any of my kernel config files. And the day it changes from optional > to mandatory is the day I stop running FreeBSD. What?!? Why?!? > Sun already burned me with their "we're giving you these new features > whether you like them or not" attitude. I'm not letting anyone else > force any unwanted innovation down my throat if I can avoid it, even > if it doesn't cost me any money. This is pure silliness... pointing to an ugly baby does not imply that all babies are ugly. For one thing, FreeBSD has already gone to 32 bit values. The known drawbacks are: 1) Archive tools have problems with 32 bit minors. 2) V3 NFS has problems with 32 bit minors. 3) You must use a FreeBSD system on the other end of the wire for a netboot. 4) ISOFS has problems with 32 bit minors (no bootable cdroms) 5) exports of /dev can be damaging/cryptic to remote systems other than FreeBSD systems, which are mounting FreeBSD exported resources. In general, the problems with /dev and MAKEDEV are: 1) /dev directory contents are synchronized with kernel configuration using a human and MAKEDEV, either of which (the human or the MAKEDEV) can fail to operate correctly. 2) You are required to have working disk drivers and FS mounts working to do a port to a new platform. 3) You can't support DOS partitioning in a consistent manner. 4) You can't support BSD partitioning (disklabel) in a consistent manner. 5) You can't support CCD partitioning (volume spanning) in a consistent manner. 6) You have to rebuild /dev each time you boot up a kernel with a different configuration. 7) There has to be a central authority for assigning major numbers (the main ammunition for "closed developement" arguments used by Linux fanatics). 8) Loadable device drivers have to be externally synchronized with a MAKEDEV at load time to produce valid devie nodes. 9) No support for transient device availability (PCMCIA cards, "docking", removable media, transportable devices (ZIP drives via parallel port, tape drives, etc.). 10) No support for "fail safe" recovery in face of device failure for a system-critical device. If you can propose a way around these 14 items (this is just off the top of my head; my engineering pad with nearly double this number is at home right now), we will be happy to listen to you. For what it's worth, I think Sun *did* screw up with their "hybrid" approach, which is what everyone is trying to force on us through the consideration of symlinks and user-provided hard links. There is nothing to say, however, that the "MAKEDEV" could not operate by creating symlinks in the "/dev" directory to the "/devfs", letting you keep your old hat without robbing the rest of us of the benefits. However, I have to say that static major and minor number assignment was a design error, and it needs to go away, one way or the other, no matter how we end up implementing it. > Getting back to the subject at hand, dump and restore are > supposed to preserve _everything_, including 32-bit major/minor > values (we got 'em, we gotta deal with 'em). Ideally, tar and cpio > should too. If they don't, they should be made to, but only if their > archive formats allow it without breaking compatibility with all the > other tar and cpio implementations on the planet. If dump and restore > aren't doing it, they are broken and need to be fixed. DEVFS doesn't > enter into it. DEVFS enters into it only in as much as a devfs's contents should be non-archivable. Since it is locally generated, it does not need to be expressed in an NFS export. One issue to consider: A devfs that does not operate by major/minor is useful for sharing device nodes over a network mount with no additional changes necessary. An NFS vnode is an alias for vnode operations to be transported to the remote system. For a devfs, since the device references are vnodes rather than major/minor pair, the operations on the device are transportable to a remote system. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607082224.PAA22643>