Date: Tue, 17 Feb 1998 03:03:10 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: julian@whistle.com, current@FreeBSD.ORG Subject: Re: devfs persistence Message-ID: <199802170303.UAA07172@usr04.primenet.com> In-Reply-To: <199802170218.TAA26553@mt.sri.com> from "Nate Williams" at Feb 16, 98 07:18:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > >> I would say that 99.99% of our user community never modifies the > > > >> permissions from the default that MAKEDEV creates. They seem to be > > > >> able to use their devices just fine. > > > > I'd say it's 1% who actually want the permissions to STICK. > > I think you'd be sadly mistaken. I think it's probably more like 10-20% > of the users who modify at least *one* /dev entry on their system. > Maybe more than that. The real question here is whether the changes are discrete, or are class based, and whether the drivers have the apropriate class granularity. A real-world example (which probably belongs in /etc/rc.serial, if you think about it) is to change all tty devices that are dialout modems to be owned and readable/writeable by group "dialout". Other than that, are we talking a set of standard paermissions for all devices in a class? If we are, the place to put that local modification is in the local configuration data -- which would ideally be editable in the device object file and/or a post-link kernel (all it takes is a little thinking before implementing). People who have no problem with the existance of a config program should have no problem with this idea. The one place this falls down is where multiple devices get their permissions from a single template instance in the driver, and the user (strangely) wants differring instances to have differring attributes, rather than a set of attributes common to the class. For these wierdo configurations, there is rc.local, rc.shutdown, and mtree. > > The trouble with new nodes is that you really can't predict REALLY new > > nodes. No matter WHAT the mechanism. > > Sure you can. No new nodes are going to show up on devices you have no > driver for, and I certainly hope new kernels aren't built w/out any > attention to what's put in them. Well, perhaps it would be better said that you can't predict what drivers will be available for dynamic loading when you set about on your administrative permissions changing fiat. For example, the auto-loading mechanism Stefan described for PCI drivers based on their existance and a user mode data file. These data file changes and driver installations could take place long after (months!) the system is initially booted. For example, I could have a PCI sound card for which a driver does not currently exist, but for which one becomes available. Or I could have an upgraded version of a driver for a non-boot-critical device (say an if_de driver that works in SMP). As to the argument about "hope new kernels aren't built w/out any attention to what's put in them", the same argument applies to class of device defaults, at the very least. If all this happens at administrative whim, then you have a strong argument for adding a "-f" option to chmod for use in rc.local... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802170303.UAA07172>