Date: Fri, 01 Jan 1999 20:55:55 -0800 From: Mike Smith <mike@smith.net.au> To: Nate Williams <nate@mt.sri.com> Cc: Warner Losh <imp@village.org>, Mike Smith <mike@smith.net.au>, freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901020455.UAA01211@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 01 Jan 1999 21:38:50 MST." <199901020438.VAA15410@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901020455.UAA01211>