From owner-freebsd-current Sat Feb 21 15:41:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA09065 for freebsd-current-outgoing; Sat, 21 Feb 1998 15:41:38 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA09047 for ; Sat, 21 Feb 1998 15:41:35 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id QAA29838; Sat, 21 Feb 1998 16:41:32 -0700 (MST) Message-Id: <199802212341.QAA29838@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), current@FreeBSD.ORG Subject: Re: devfs persistence In-reply-to: Your message of "Sat, 21 Feb 1998 23:22:29 GMT." <199802212322.QAA07185@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Feb 1998 16:38:39 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Well, then let me ask a question: > > How do I know what permissions to assign a PCMCIA or a > PCI-hot-pluggable card device that has never been plugged > into the machine before? > >Perhaps you have an argument for: > > If this device shows up, chmod and chown it thusly. My argument is that if a device has never seen up before, it should either not be shown (DEVFS mount option), or should be shown with the default and secure permissions specified by the kernel. If the device has been seen before and the sysadmin has chosen to change chmod/chown the device, those settings should be persistent and been seen on the device when it arrives. To change the permissions on new devices as they show up, automagically, you use a daemon. >This is the daemon soloution. You should feel free to start such >a deamon. In your rc.local. Not in rc.local. From mount_devfs if you specify the correct mount option. >Devfs should probably provide an arrival interface for such a daemon, >in case one is registered, to allow it to vet/change defaults before >the device actually gets exported. I made this point already when I pressed that any type of "template" or "prototype" mechanism belongs outside of the kernel. >But should there be a requirement that such a daemon be written? Or >that the interface be in the code before it becomes the default way >of accessing a device? > >I say "no". Just as someone wanting a GUI install, a feature >which does not currently exist, must write it, so must someone >wanting a vetting daemon write the code. I would happily accept a "template-less" DEVFS. >Notice that devices which have not arrived before rc.local can be >run are a new feature. Therefore, there is no valid argument for >any "historical procedent" for imminenet (about to arrive but not >yet arrived) devices. This is not true. We have PCMCIA code in the system now. The "historical precedent" is that you must create the device node before you can use the device regardless of when it appears. > Terry Lambert > terry@lambert.org -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message