From owner-cvs-all Fri Feb 13 16:51:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA20177 for cvs-all-outgoing; Fri, 13 Feb 1998 16:51:10 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA19608; Fri, 13 Feb 1998 16:47:03 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id QAA05385; Fri, 13 Feb 1998 16:18:58 -0800 (PST) Message-Id: <199802140018.QAA05385@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Poul-Henning Kamp cc: Mike Smith , Julian Elischer , 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: Your message of "Sat, 14 Feb 1998 00:51:26 +0100." <3896.887413886@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Feb 1998 16:18:58 -0800 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > In message <199802132343.PAA05222@dingo.cdrom.com>, Mike Smith writes: > > >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? > > Because devices come and go... No, they don't. The operating system comes and goes, but if I plug a device into my system, it *stays* there. If I take the OS away, and bring it back, the device is *still* there, and unless I explicitly do something to the device, I expect it to be like it was. > >> Yes I have, and no I do not accept that. > > > >But you do. Your entry in /etc/rc.local is an implementation of > >persistence. > > No it isn't, it's an implementation of policy. Er, you've already said that persistence is policy. I can't see any difference. > > - If you mount devfs somewhere else (think "chroot()"), the new > > permissions are not necessarily going to come across (cf. > > conversations with Julian on this). > > Which is the right thing to do, I may not even want all the devices > to come across... Sure. I agree entirely. > > - There is no logical connection between /etc/rc.local and /dev > > No, it should probably be called /etc/rc.deviceperms or something > along those lines. No again. It's specific to the mount instance. > > - 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. > > For each of these there will need to be some kind of daemon to manage > a whole lot of stuff anyway (ifconfig/mount &c &c), so it is clearly > a task for that daemon to get the perms right according to local > policy. No. Now you're suggesting that persistence should be implemented in multiple inconsistent fashions. > >> 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. > > What you want is: > > # ls -l /dev/asr33 > crw-rw-rw- 1 root wheel 0, 0 13 Feb 21:20 /dev/asr33 > # chown fumble /dev/asr33 > # ls -l /dev/asr33 > crw-rw-rw- 1 fumble wheel 0, 0 13 Feb 21:20 /dev/asr33 > # reboot > # ls -l /dev/asr33 > crw-rw-rw- 1 fumble wheel 0, 0 13 Feb 21:20 /dev/asr33 > > What I want is: > > # ls -l /dev/asr33 > crw-rw-rw- 1 root wheel 0, 0 13 Feb 21:20 /dev/asr33 > # chown fumble /dev/asr33 > # ls -l /dev/asr33 > crw-rw-rw- 1 fumble wheel 0, 0 13 Feb 21:20 /dev/asr33 > # reboot > # ls -l /dev/asr33 > crw-rw-rw- 1 root wheel 0, 0 13 Feb 21:20 /dev/asr33 > # vi /etc/rc.devperms > (add/change line to read: "chown asr* fumble.wheel" ) > # reboot > # ls -l /dev/asr33 > crw-rw-rw- 1 fumble wheel 0, 0 13 Feb 21:20 /dev/asr33 So we want the same thing. As I said, we are arguing implememtation. Count the lines, and the breaks in paradigm, between what you suggest I want and what you want. Your desire is for a more complicated, inconsistent, non-extensible technique. That's Bad. -- \\ 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