From owner-cvs-all Fri Feb 13 16:05:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA11002 for cvs-all-outgoing; Fri, 13 Feb 1998 16:05:22 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA09946; Fri, 13 Feb 1998 16:01:32 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id PAA04531; Fri, 13 Feb 1998 15:57:58 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd004528; Fri Feb 13 15:57:49 1998 Date: Fri, 13 Feb 1998 15:54:01 -0800 (PST) From: Julian Elischer To: Mike Smith cc: Poul-Henning Kamp , Paul Traina , core@FreeBSD.ORG, junichi@jp.freebsd.org, committers@FreeBSD.ORG Subject: Re: wfd block major number reassignment from 24 to 1 In-Reply-To: <199802132343.PAA05222@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Fri, 13 Feb 1998, Mike Smith wrote: > > In message <199802132319.PAA05082@dingo.cdrom.com>, Mike Smith writes: > > >> I belive that persistence in DEVFS is a BAD thing, but I'm appearantly > > >> pretty alone on -core with this view... > > > > > >Have you ever wanted to change permissions on an entry in /dev? > > > > yes. > > Ok. > > > In which case I always add it to /etc/rc.local so I'm sure it will > > be there on the next reboot. > > Why? Do you do this for all the other files throughout your system > that you change the permissions on? Do you *expect* permissions on > arbitrary files to change when you reboot? > > > >If not, then your stance is understandable. But as soon as you accept > > >that there may be more than one "right" set of permissions for > > >something, you accept that persistence is required. > > > > Yes I have, and no I do not accept that. > > But you do. Your entry in /etc/rc.local is an implementation of > persistence. Unfortunately, it's not adequte for at least the > following reasons: > > - If you mount devfs somewhere else (think "chroot()"), the new > permissions are not necessarily going to come across (cf. > conversations with Julian on this). that's optinal. I COULD make them come across.. it was the default at one stage. > - There is no logical connection between /etc/rc.local and /dev > - If a device node first appears after /etc/rc.local is run, it is not > possible to set its permissions. This is an issue for PCI, PnP, > PCCARDs and CARDBUS at the very least. yes. sometimes I think PHK's poor-man's devfs ( a devfs daemon that makes devices as needed) sounds attractive :) > > > If I decide that disks should be "642 foo.mumble" on my machine, > > I should be able to express that such that when I add more disks > > it will DTRT. > > > > Permissions in /dev is a policy issue, and should be handled as > > such: ie, from a root-controlled config file. > > No argument with anything there. > > > I belive persistence in devfs (as in /dev) is a very bad thing. > > You certainly haven't expressed that. In fact, everything else you > have said in this message directly contradicts that. I can only > conclude that you're reading a different meaning into "persistence" > than I am, and by inference a lot of other people. persistance means that using 'chmod' and 'chown' lasts across a reboot or a unmount/remount. I really don't like that idea. what about new devices that pop up? till you go do the chmod, what happens? my scheme outlined in other mail (you are on committers right?) also fails to deal with this.. > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message