From owner-freebsd-arch Sat Jan 2 10:14:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA09269 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:14:18 -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 KAA09264 for ; Sat, 2 Jan 1999 10:14:15 -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 TAA24144 for ; Sat, 2 Jan 1999 19:13:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95486 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:13:50 +0100 (MET) Received: from dingo.cdrom.com (castles354.castles.com [208.214.167.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA11035 for ; Fri, 1 Jan 1999 21:21:33 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id VAA00463; Fri, 1 Jan 1999 21:18:09 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901020518.VAA00463@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 X-To: Nate Williams X-cc: Mike Smith , Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Fri, 01 Jan 1999 22:11:36 MST." <199901020511.WAA15502@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Jan 1999 21:18:08 -0800 From: Mike Smith To: undisclosed-recipients:; Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 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. > > > > > > I setup the machine so that 'normal users' could do their own backups to > > > the tape drive, but the default permissions would not allow this to > > > work, so I had to 'chmod' the device special node. The combination of > > > the Solaris init implementation (where do I stick the chmod call in the > > > mess of init files?), the fact that the tape drive was 'mobile' (it > > > moved to a PC for backups on occasion), and the fact that I couldn't > > > make the mods persistent w/out a lot of work. > > > > > > Yes, it could be done, but it was a huge pain in the backside to get it > > > to work 100%, and it shouldn't be that much work IMO. > > > > This sounds more like you were bitten by the lack of easily-adapted > > support infrastructure than that the basic concept is flawed, > > especially as the case you offer as support is one that would be a > > non-issue with our infrastructure. > > What infrastructure? Nothing exists at this point in FreeBSD to do this > 'easily'. There is lots of hand-waving, but nobody has even agreed on > *what* form a persistence mechanism would take, other than those who > argue 'we really don't need it'. :( You were specifically complaining about not being able to fix something that a boot-time script would have been more than adequate for. > We've got boot rc.* scripts (which I hope Warner has pointed out is > insufficient), Actually, in most cases they'd be fine, if decidedly inelegant. > and the infamous 'daemon', which IMO would be difficult > to customize easily, A non-comment on a non-design. > I'd like to see something of substance *implemented* before we agree to > go with DEVFS. How can you implement something for something else that doesn't exist? > There are still also outstanding issues of *how* a device node shows up > in the first place. We still have the chicken/egg problems of whether > or not to create device nodes for *every* conceivable disk device for a > particular disk (wd0, wd0a, wd0s1a, wd0s2a, etc...), which SLICE was > supposed to help with. Lack of SLICE-equivalent functionality would instantly disqualify any DEVFS candidate; I think that much has to be obvious. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message