Date: Sat, 02 Jan 1999 00:13:24 -0700 From: Warner Losh <imp@village.org> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901020713.AAA09699@harmony.village.org> In-Reply-To: Your message of "Sat, 02 Jan 1999 14:35:03 %2B0800." <199901020635.OAA03578@spinner.netplex.com.au> References: <199901020635.OAA03578@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199901020635.OAA03578@spinner.netplex.com.au> Peter Wemm writes: [trimmed, an excellent recap of the past discussions] > Re chroot jails.. Would mounting an instance, cleaning it out and then > doing a 'mount -u -r /my/chroot/jail/dev' cut it? (making it readonly > would prevent changes, devices appearing, etc.) I withdraw my objection to having devfs add/remove devices from some file systems. I didn't even think about chroot jails. Accessing devices in chroot jails is useful enough for an interesting number of cases to allow that. > Yes, we need a devfs. Yes, it should be on by default. I prefer > non-persistance, especially if measures are taken to make it easier to > cope with. I would prefer to not have to put policy into drivers, but > some will be unavoidable - /dev/null for example. Perhaps classifying > nodes and having a group of settings might do the trick. I agree with this sentiment. I also agree that we need devfs more than we need to have persistance. So long as there is a way to change the default settings of a class on the fly, then this will work for the examples I've been giving: new pccard device as well as a mouse appear/disappear. If I wanted to grant ownership to the console devices to one person, I'd just set the defaults to that person. Then it doesn't matter. While rough around the edges, I think what Peter has outlined will be better enough to move forward w/o persistance. Any discussion of this in the larger context needs to have something that is that clear and shows that most cases are covered well enough and leave the rest for devfs v2 if the well enough devolves over time and needs fixing. Warner 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?199901020713.AAA09699>