Date: Fri, 1 Jan 1999 21:38:50 -0700 From: Nate Williams <nate@mt.sri.com> To: Warner Losh <imp@village.org> Cc: Mike Smith <mike@smith.net.au>, freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901020438.VAA15410@mt.sri.com> In-Reply-To: <199901020312.UAA09044@harmony.village.org> References: <199901020116.RAA03885@dingo.cdrom.com> <199901020312.UAA09044@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Personally, I think a persistent DEVFS would be "better" than a > > non-persistent DEVFS. But it's been quite clear for some time that > > persistence is something that can be built onto a working DEVFS, so a > > non-persistent DEVFS is something that we definitely want to start with. > > We must remember that rc.* is not an acceptible solution because > devices can come and go. Agreed, this is my point exactly. 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. > 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. Also, if it requires too much user intervention to mess with things it will also be a net loss. Ex: I want to add a modem card to my FreeBSD laptop system. 1) Edit /etc/pccard.conf and add the new devices. 2) Edit /etc/devfs.init to add the new serial devices permissions. 3) Kill -hup /var/run/devfs.pid 4) Insert the card, and hope you got everything right. 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. > [The problem of insecure device-creations can be solved by defaulting > to not create devices dynamically after boot. -EE] This is unacceptable with hardware such as laptops and such. We are trying to move to a more dynamic model for the kernel, and this flies completely in the face of this. Nate 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?199901020438.VAA15410>