Skip site navigation (1)Skip section navigation (2)
Date:      05 Jul 2002 11:40:09 +0930
From:      "Daniel O'Connor" <doconnor@gsoft.com.au>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Bruce Evans <bde@zeta.org.au>, "Greg 'groggy' Lehey" <grog@FreeBSD.ORG>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Mario Goebbels <mariog@tomservo.cc>, current@FreeBSD.ORG
Subject:   Re: About DEVFS (was: Re: About GEOM...)
Message-ID:  <1025835014.4223.5.camel@chowder.gsoft.com.au>
In-Reply-To: <3D24BB6E.3829314A@mindspring.com>
References:  <20020704210304.Y21619-100000@gamplex.bde.org>  <3D24BB6E.3829314A@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2002-07-05 at 06:47, Terry Lambert wrote:
> o	Inability to create non-existant ("convenience") nodes and
> 	symbolic links, thus providing device aliases matching those
> 	rendesvous expected by existing third party programs, in
> 	particular, with regard to ABI compatability
> o	Inability to persistently modify default permissions values
> 	away from the system defined acceptable safe values persistantly
> 	across a reboot, without modifying instance declaration in
> 	source code.
> o	"One size fits all" per major number for template permissions
> 	definitions

I am pretty sure you can put chmod/ln -s commands in /etc/rc.local (I
rc.devfs? My -current box is asleep ATM) which largely solves this
problem.

It isn't perfect but the current DEVFS has good advantages - especially
the hardware/node synchronisation which is very useful when you have to
shuffle hard drives and have neglected to make the right device nodes
first.

> Personally, I've never been persuaded that the persistance of modifications
> argument against devfs had any validity; I have yet to see one case that
> can not be managed via rc.local or modification of driver defaults
> (e.g. I know of no transient device that results in the creation of
> multiple device nodes for the same major number).  I personally think
> the correct way to handle this is to write the changes back to the
> kernel image, if we are talking about modifications to the primary
> instances of the devices.

Loader?
ie on shutdown write a list of permissions etc into a file which the
loader can slurp up next boot and shove into the kernel and be parsed.

> But overall, it seems to be a move forward.  I guess if you valued
> persistance (e.g. the ability to rename your floppy device to be
> /dev/mickeymouse) over the new features, I guess I could see your
> point.

Mmmm.. unnecessary pain.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5


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?1025835014.4223.5.camel>