Date: Sun, 03 Jan 1999 11:07:24 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <9105.915358044@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 02 Jan 1999 23:25:13 MST." <199901030625.XAA18116@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199901030625.XAA18116@mt.sri.com>, Nate Williams writes: >> > We must remember that rc.* is not an acceptible solution because >> > devices can come and go. >> >> Devices which come and go will need a daemon anyway to swing them >> into action (mount, ifconfig and so on). > >That's not true (think modems), and putting 'permission' policy into >mount and ifconfig is utter silliness. It sure is the case. And please try to read, in particular on the lines, we're not talking about putting permissions in ifconfig or mount but about a daemon which can amongst other things set the permissions and call ifconfig/mount. >Assuming we agree that a non-persistent DEVFS is acceptable, we still >need some way of setting policy, and so far the most common solution is >the rc.* solution, which is inadequate. No, the question is whether "chmod 777 /dev/null" will succeed or not. >> Do we want a "chmod 764 /dev/foo" to be persistent over reboot, >> despite the significant amount of code it takes, and the potential >> to pop out of the blue six months later and bite people ? > >Yes. And would you care to elaborate on why ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9105.915358044>