From owner-freebsd-arch Fri Jan 1 21:10:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA09826 for freebsd-arch-outgoing; Fri, 1 Jan 1999 21:10:07 -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 VAA09811 for ; Fri, 1 Jan 1999 21:10:05 -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 GAA05771 for ; Sat, 2 Jan 1999 06:09:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA93787 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 06:09:41 +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 UAA09247 for ; Fri, 1 Jan 1999 20:59:23 -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 UAA01211; Fri, 1 Jan 1999 20:55:56 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901020455.UAA01211@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Nate Williams cc: Warner Losh , Mike Smith , freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Fri, 01 Jan 1999 21:38:50 MST." <199901020438.VAA15410@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Jan 1999 20:55:55 -0800 From: Mike Smith 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. > > If my mouse were plugged into a USB port, > > and I unplugged it then plugged it back in, the device would go away > > and come back. If I chmod'd it on boot, those setting would be lost. > > I hope this isn't lost in the noise. Any 'boot' configuration is a loss > for the (hopefully soon to be coming) 'dynamic' scheme that keeps > getting talked about. Devices will come and go, and any scheme that > doesn't take this into account will be a net loss. I was just discussing this with Eivind; I think that we can comfortably cover every set of requirements with: - a kernel-wide default owner/group/permissions for new nodes, which can be overridden by the device driver in response to eg. configuration arguments or device-specific concerns. - a mount option which determines whether new nodes show up in the devfs instance. > You get the point. If we plan on making the system secure out of the > box, then we need a way for people to make it usable w/out too much > grief. This is a key point, yes. -- \\ 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