From owner-freebsd-arch Sat Jan 2 10:33:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA11763 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:33:32 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA11754 for ; Sat, 2 Jan 1999 10:33:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24327 for ; Sat, 2 Jan 1999 19:33:06 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95595 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:33:06 +0100 (MET) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA08966 for ; Sat, 2 Jan 1999 03:50:51 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id MAA20368 for freebsd-arch@FreeBSD.ORG; Sat, 2 Jan 1999 12:50:27 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.1/8.9.1) id MAA13309; Sat, 2 Jan 1999 12:41:13 +0100 (MET) (envelope-from j) Message-ID: <19990102124112.29898@uriah.heep.sax.de> Date: Sat, 2 Jan 1999 12:41:12 +0100 From: J Wunsch To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Reply-To: Joerg Wunsch References: <199901020116.RAA03885@dingo.cdrom.com> <199901020312.UAA09044@harmony.village.org> <199901020438.VAA15410@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199901020438.VAA15410@mt.sri.com>; from Nate Williams on Fri, Jan 01, 1999 at 09:38:50PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Nate Williams wrote: > To counter Joerg's 'not bothered by non-persistent DEVFS', I'd have to > say that my experience with Solaris has been less than enthusiastic. > Note, it only dealt with one device (the tape drive), but it was a pain > in the butt. Well, that's funny. It's not funny that you had problems with Solaris, but it's funny since in some recent discussion in -core, I quoted Solaris as an example of a persistent DEVFS that has been causing me major grief _due to its persistence_. (Jordan's reply was that the grief is mainly caused by a poor implementation, not by the fact that they've implemented persistence. He's probably right on this.) I can't follow you on this, btw, and have just tried it again. The Solaris implementation _is_ persistent, and they store their persistent data in the root f/s (which I believe is terribly wrong). I have been able to chmod something, and to reboot, and everything was as previously. Their persistence is sticky until you boot -r (or run drvconfig(1m), and even then, old devices under /devices and /dev are remembered forever unless you manually rm the entries there (sounds like AIX, doesn't it? :). I always found this terrible, since there's no clean way to tell the system to ``go to hell and restart from scratch''. My bad experience with them was an attempt to migrate a disk from an Ultra 10 machine with a SymBios Logic SCSI card to a Sun AXi OEM-board based clone with an onboard SymBios Logic. Although both architectures are fairly similar, it has proven to be plain impossible to do this, short of a reboot from a CD-ROM after the migration, mounting the disk's root f/s, rm -rf'ing all the /dev and /devices cruft, and copying it over from the dynamically created /dev and /devices that exist in the CD-ROM environment. This is a good example of something I'd never like to happen to a FreeBSD disk. But again, that's probably more a point to prove that the Solaris _implementation_ is poor, not that persistence itself is something that sucks. But maybe then, it could be that any possible implementation of a persistent DEVFS sucks similarly. :.) (After working with some really large server machine, I began to understand why they did some things the way they did, still I believe it could have been done better.) -- 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. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message