From owner-freebsd-arch Sat Jan 23 06:36:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA06674 for freebsd-arch-outgoing; Sat, 23 Jan 1999 06:36:32 -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 GAA06666 for ; Sat, 23 Jan 1999 06:36:26 -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 PAA09686 for ; Sat, 23 Jan 1999 15:36:01 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA09681 for freebsd-arch@freebsd.org; Sat, 23 Jan 1999 15:36:01 +0100 (MET) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA04484; Sat, 23 Jan 1999 01:10:51 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id BAA16737; Sat, 23 Jan 1999 01:10:42 -0800 (PST) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma016735; Sat, 23 Jan 99 01:10:32 -0800 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id BAA14995; Sat, 23 Jan 1999 01:10:32 -0800 (PST) From: Archie Cobbs Message-Id: <199901230910.BAA14995@bubba.whistle.com> Subject: Re: DEVFS, the time has come... In-Reply-To: <94808.915113237@critter.freebsd.dk> from Poul-Henning Kamp at "Dec 31, 98 03:07:17 pm" To: arch@FreeBSD.ORG Date: Sat, 23 Jan 1999 01:10:32 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Cc to -current trimmed. If you want to have any form of Cc: elsewhere, please keep it a Bcc - moderating a discussion that goes in several fora is difficult. This also implies that I'd like you to not reply to anything Cc:'ed to arch except through the mail you get from the -arch mailing list. -EE] Poul-Henning Kamp writes: > ... to make up our mind about it. > > [ clear arguments for DEVFS and why persistence is complicated ] This email was a few weeks ago, and there was a lively debate, then Julian sent an email listing some issues/requirements, and then the thread kindof died and now we're back to where we were before, which is not any further on.. So I'd like to make another attempt to get agreement on the next step here, so that *something* can happen. We need to get more people using DEVFS, so we can gain some experience & feedback. I don't think DEVFS has any issues that are not surmountable. However, at some point you must take the next step. To do this, we need to come up with a 'next step' that doesn't necessarily make everybody happy, but does make enough people happy that they can use it and it becomes somewhat 'mainstream'... Here's my proposal, which is basically the same thing Poul was suggesting: - Have a non-persistent DEVFS in the kernel; when devices appear they have the default permissions - Have an /etc/rc.devices script to make any site-specific customizations at boot up - Have a mount flag that would disable the appearance of new devices - DEVFS remains a kernel option for now To try and answer some of the issues from Julian's email, in the interest of making decisions so we can proceed: > 3/ The filesystem needs to give a method to allow new devices to appear > as created. If the layout of a /chroot/dev filesystem has been > changed, then you need to work out WHERE in the filesystem to > create the new device. Devices should appear in the same place (relative to the root of the mount) every time. For now, this path can be hardwired in the device driver. > 4/ If a user changes the name of a device or makes a link to it, those > devices must still be removed when the device becomes invalid. > ... > 6/ If a process has a device open and it 'goes away', what should happen? No automatic removal of device nodes.. if the device goes away, then operations start returning ENXIO or whatever. After all, this is what a non-DEVFS system would do in the same situation (if it could). > 7/ Persistence is I think a WOFTAM. Some people want it. It could be > ignored in my opinion but you should at least have a scheme in > mind.. My suggestion is to pick up permissions and owners from > inodes of the same name read from the filesystem on which the devfs > was mounted. A synthetic / filesystem (An idea that I know Poul has > been kicking around for a while) wouldn't be able to do that, but > there are other ideas I guess. Devices appear with default permissions and ownership... always. "What about a new device that appears when I insert my PCCARD?" Well, you can always do what you do now, which is not have them appear, So at least things get no worse. "Well, actually now I have the device node with my special permissions set already created in /dev, so when the PCCARD is inserted, the device node already exists with those permissions..". Good question.. for now, we ignore this case (and potentially lose a few DEVFS customers). Solving this can be part of the next step. Ideas: (a) have a user daemon; (b) have DEVFS inherit permissions from a 'stub' node of the same name that already exists (if any) when the device appears (then /etc/rc.devices could do its thing for these dynamically appearing nodes as well). > 5/ If a device has its modification time changed, does that change > reflect through all instances of that device? (E.g. /dev/xxx and > /chroot/dev/xxx). What about permissions? What about ownerships? No.. separate nodes are separate files, they just refer to the same device. OK.. so there is some percentage X% of people for whom this proposal would be sufficient to use DEVFS on their systems. Personally, I find it hard to believe that X is not a large number, because for "normal" usage you'd get exactly what we have now, functionally speaking. It seems like this proposal would make DEVFS acceptable for a large percentage of folks.. but definitely not 100% -- and that's OK for a first step. Ultimately, we want to get to a fully DEVFS world. By taking a few steps at a time, and getting people to *use* it, we can eventually discover and address everybody's concerns. Comments?? The issue here is not whether this proposal is a sufficient *final* incarnation of DEVFS, but whether it's a sufficient next step.. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 23 06:36:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA06719 for freebsd-arch-outgoing; Sat, 23 Jan 1999 06:36:51 -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 GAA06714 for ; Sat, 23 Jan 1999 06:36:48 -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 PAA09695 for ; Sat, 23 Jan 1999 15:36:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA09697 for freebsd-arch@freebsd.org; Sat, 23 Jan 1999 15:36:36 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA06474 for ; Sat, 23 Jan 1999 01:35:38 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id KAA09737 for ; Sat, 23 Jan 1999 10:35:06 +0100 (CET) To: arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Sat, 23 Jan 1999 01:10:32 PST." <199901230910.BAA14995@bubba.whistle.com> Date: Sat, 23 Jan 1999 10:35:06 +0100 Message-ID: <9735.917084106@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have deliberately let this discussion fizzle out for some time, to give people a chance to think about the stuff. The "next step" for DEVFS, is something that is good enough to be the default if people install from a snapshot. That is the next hurdle we have to clear. There is no "perfect for 100% of the users" solution that doesn't require us to rape and pillage the KISS principle one way or the other. Most of the "perfect for 90%, good enough for 99% and workable for 100% of the users" solutions take a hit in the POLA criteria. I'd rather trade some POLA for KISS. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message