Date: Tue, 17 Feb 1998 22:12:18 +0100 From: sthaug@nethelp.no To: tlambert@primenet.com Cc: current@FreeBSD.ORG Subject: Re: devfs persistence Message-ID: <22612.887749938@verdi.nethelp.no> In-Reply-To: Your message of "Tue, 17 Feb 1998 10:57:48 %2B0000 (GMT)" References: <199802171057.DAA10576@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Just a small case in point: I make the following changes to /dev every > > time I install a new version of FreeBSD: > > > > - chmod g+w rfd0.1440 > > And you don't want other rfd0 densities greoup writable because? Having the rest group writable would be fine. Since I only use rfd0.1440, that's the only one I regularly change the access on. > I think this qualifies as a class of devices (fd devices are exported > by the fd driver, and raw fd devices are a seperate class of exported > device). Fine by me. > > - chmod g+r bpf0 > > And not bpf1? If bpf1 (etc.) exists, I would do the same here. But "MAKEDEV std" only creates bpf0 :-) > I think this is the same issue. I'll note, for the record, that bpf > should be a cloningin device in any case, and should act like: > > 1) fd1 = open /dev/bpf > 2) fd2 = ioctl( fd1, DEVCLONE, &clone) > 3) close( fd1) > > Step 2 would create a /dev/bpf/0 (whose path is repoeted in the clone > structure). Fine by me. > > - ln -s cuaa0 mouse > > This is somewhat non-sensical as well. The mouse should use a protocol > virtualizer so that a /dev/mouse is reexported, and it doesn't matter > what your physical mouse hardware is, the thing looks like a mousesystems > (or other) mouse, always, so that programs don't have to care about this. Sure. But that makes XFree86 dependent on the mouse protocol virtualizer also. Do you want to introduce more dependencies? (Just playing the devil's advocate here.) > > Thus, if DEVFS is used, I want *some* way to have this happen > > automagically when the machine is booted. /etc/rc.devices would be fine. > > You could do it this way, of course, but the permissions thing can > be applied to the modules exporting the default attributes for a given clss, > as a local configuration modification. That's fine. But no matter how you do it, you need some way of making local modifications that stick, and that can be repeated at next bootup. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22612.887749938>