Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 Jan 1999 20:23:37 -0700
From:      Warner Losh <imp@village.org>
To:        freebsd-arch@FreeBSD.ORG
Subject:   Re: DEVFS, the time has come... 
Message-ID:  <199901060323.UAA19841@harmony.village.org>
In-Reply-To: Your message of "Tue, 05 Jan 1999 19:42:02 %2B0100." <20686.915561722@critter.freebsd.dk> 
References:  <20686.915561722@critter.freebsd.dk>  

next in thread | previous in thread | raw e-mail | index | archive | help
In message <20686.915561722@critter.freebsd.dk> Poul-Henning Kamp writes:
> Well, that might be a usable model for embedded environments, but
> since you wouldn't offer PCCARD support, PnP support, or any of
> the other dynamic technologies which need high-level intelligence
> support, you wouldn't really be much better off than by using a
> shell script, so I don't think what you describe will be a much
> wanted solution...

I don't think that matters at all.  pccard support is provided by
pccardd while pnp support is provided by controller pnp0 in your
config file.

I disgree that you'd need more intellegence than what I've proposed.
It will easily handle all the dynamic stuff that I can think of, of
devices coming and going, etc.  I don't see what pnp, pccard, etc have
to do with this.  They are orthoginal to the problem.  My devfsd
dynamically deals with devices coming and going.

I also disagree that it won't buy you much beyond the shell script.
It buys you two things:
	1) the ability to 
		chmod /dev/ttyd1 imp
	   and have that change persist w/o any further action.  This
	   is certainly POLA for thise case.
	2) The ability to insert a modem card and have it have its
	   old permissions and ownerships restored.  When the new
	   device arrives in the tree, the daemon will set its meta
	   data properly.

However, this does raise an interesting question, which is what is the
scope of this daemon?

Warner

[Sorry for the delay in handling this bunch of messages - technical
mail-filtering error in my end. -EE]

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?199901060323.UAA19841>