Date: Sun, 7 Jul 1996 20:38:43 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> 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: <199607071838.UAA27228@uriah.heep.sax.de> 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
As Bill Paul wrote: > > 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. You cannot generalize this case. If they won't go away for _you_, so that's your problem. I think there's consensus that they won't survive the end of the century for most other FreeBSD users. > Sun already burned me with their "we're giving you these new features > whether you like them or not" attitude. It's not really a new feature, and i've seen devfs-based systems (DG/UX, as i've already mentioned) where it took me about a year or so to realize that they are actually using such a thing. (Ok, my degree of Unix experience wasn't that high back in the old days.) It fit smothelessly into the entire environment. The static /dev tree has been a misconception in the first place, since it always tends to disagree between the actual device configuration and the existing device nodes. You know as well as me that this is a fatal discrepancy, either direction. Also, it requires a central authority to give out major device numbers, even for locally maintained drivers. This is not to say that we don't need a good methodology to allow for all kinds of valid requirements, e.g. some sort of ``persistency''. Anyway, i doubt people who are crying ``I wanna get my V7 back in FreeBSD-current!'' will influence the overall decision too much. ;-) (Funny, you didn't oppose to the merged VM/buffer cache changes, and that's far more into the direction of "we're giving you these new features...".) > Getting back to the subject at hand, dump and restore are > supposed to preserve _everything_, ... Nobody ever claimed the opposite. You're running into open doors here. > 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 They don't allow it (except for the newer cpio formats, but we support this, but^2 quite a bunch of other systems don't). > 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 is not intended as a replacement for a broken backup tool. You must be confusing this some way. Having said this, remember: that's just my very personal opinion. It's in no way related to other people, neither of the FreeBSD core team or else. With the current buggy state of affairs, it doesn't look like a mandatory devfs would already happen next week... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607071838.UAA27228>