From owner-freebsd-arch Sat Jan 2 10:47:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA13304 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:47:58 -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 KAA13299 for ; Sat, 2 Jan 1999 10:47:55 -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 TAA24450 for ; Sat, 2 Jan 1999 19:47:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95671 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:47:30 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA19695 for ; Fri, 1 Jan 1999 23:15:40 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zwLHD-0001Mv-00; Sat, 2 Jan 1999 00:15:11 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id AAA09699; Sat, 2 Jan 1999 00:13:25 -0700 (MST) Message-Id: <199901020713.AAA09699@harmony.village.org> X-To: Peter Wemm Subject: Re: DEVFS, the time has come... To: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Sat, 02 Jan 1999 14:35:03 +0800." <199901020635.OAA03578@spinner.netplex.com.au> References: <199901020635.OAA03578@spinner.netplex.com.au> Date: Sat, 02 Jan 1999 00:13:24 -0700 Mail-Followup-To: freebsd-arch@FreeBSD.org From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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