Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Feb 1998 23:25:39 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        sthaug@nethelp.no
Cc:        tlambert@primenet.com, current@FreeBSD.ORG
Subject:   Re: devfs persistence
Message-ID:  <199802172325.QAA07146@usr09.primenet.com>
In-Reply-To: <22612.887749938@verdi.nethelp.no> from "sthaug@nethelp.no" at Feb 17, 98 10:12:18 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > > - 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.)

Ask David Dawes.  XFree86 already does this; it had to for SVR4.

> > > 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.

Local transient modifications, or local build-time modifications?

I would argue for build-time, and let you edit the class template
data if you felt inclined to do it post-build.  But I'm just being
generous; there's no real reason for allowing that, especially in a
first revision, since you always have rc.local.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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?199802172325.QAA07146>