Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Apr 1997 11:13:45 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        avalon@coombs.anu.edu.au (Darren Reed)
Cc:        jkh@time.cdrom.com, proff@suburbia.net, hackers@FreeBSD.org
Subject:   Re: devfs
Message-ID:  <199704021813.LAA13944@phaeton.artisoft.com>
In-Reply-To: <199704021415.GAA01403@freefall.freebsd.org> from "Darren Reed" at Apr 3, 97 00:10:35 am

next in thread | previous in thread | raw e-mail | index | archive | help
> if only name & permission persistance is sought, why can't devfs inherit
> permissions from /dev and just change major/minor #'s (or is persistance
> required there too) ?

1)	What do you do with a "persistance" record for a pluggable
	(PCMCIA, etc.) device that is not currently present?

2)	This requires that you maintain specfs for normal FS's.
	One of the main benefits of a devfs is that I can mount
	my root NFS from a system which does not support FreeBSD's
	bizarre idea of the number of bits in a major and minor
	number.  Like, oh, all of them but FreeBSD.

3)	This requires that the root FS be writeable.  This is
	unsuitable for embedded applications, POS systems, and
	NC systems, among other applications.

> maybe mounting devfs needs to be a boot "procedure" where name->permissions
> ownership is transfered from /dev to /devices.  Hmmm, what if /dev was a
> sym. link to /dev.old (or was reset to that at boot time), then after
> the devfs block was mounted under /devices and attributes transfered,
> changed to point to /devices ?

This persistance crap is just crap.  If people cared about it, it
should be possible to simply add an ioctl() that would return the
location in KVM of the entry which created the devfs entry you are
interested in changing, and then mung the real kernel image at that
offset for the struct entries mode_t, uid_t, and gid_t to implement
"persistance" as a permanent change to boot image data instead of
something that's stored seperately from the kernel, for no good
reason.

The problem is that the people who care about persistance aren't the
people writing the code -- the same problem FreeBSD has always had
with IDE device, floppy tape devices, and anything else that works
fine in another free OS but not in FreeBSD.

If FreeBSD is to act historically consistent, then it would integrate
devfs, and let the people who cared about persistance of permissions
other than the default, either submit patches for the default values
set on device registration (losing the need for persistance) or they
can implement persistance and submit it on their own.

If this doesn't seem to be a good idea, then getting rid of netiso
was probably a bad idea with exactly the same character.


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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704021813.LAA13944>