Re: FreeBSD devfs support on NetBSD 5.0

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Jun 20, 2009 at 07:38:22AM -0400, der Mouse wrote:
 > > (4) Structurally, permissions are (and should be) properties of the
 > > device driver, not of some intermediate devfs object.
 > 
 > I very strongly disagree with this.  For example, I see it as totally
 > reasonable to have different permissions on the very same device in
 > /dev and /ftp-chroot/dev and /ntp-chroot/dev (most likely, the chroot
 > jails get read-only versions of what's read-write in /dev, but not
 > necessarily).

That is entirely reasonable; the question is how best to accomplish
it. ISTM that for simple cases at least the best way to establish a
restricted clone of a magic /dev in a chroot area is with nullfs or
something like nullfs. That is, the chroot's /dev is a transformation
of the global one rather than a separate independent thing.

The only case I can think of where this is clearly the wrong approach
is serving nfs roots to diskless clients; but there you can't properly
use devfs anyway.

 > > Some devices have (or should have) fixed permissions; for example,
 > > "chmod 711 /dev/null" serves no purpose but to render the system
 > > dysfunctional and there's no need to allow it at all...
 > 
 > On most systems, yes.  But "Unix does not prevent you from doing stupid
 > things because that also prevents you from doing clever things".  Are
 > you certain there is no use, anywhere, under any set of special
 > circumstances, for unusual permissions on /dev/null?  I'm not.

I am, actually.

 > > let alone go to a lot of effort to make its effects persistent.
 > 
 > Again, I disgaree.  The major reason to support that is that it is an
 > automatic consequence of something much more useful and important -
 > persistent mode bits on *other* entries in /dev.  I really really don't
 > like the idea of duplicating permission changing and saving code in
 > each device driver rather than doing it once.

It doesn't have to be duplicated. One would just drop genfs_devchmod
or something into the right slot if desired, provide the proper
default permissions, and forget about it.

Anyway, this point didn't come across that clearly. (Unlike the first
couple, it hasn't had ten years to gel.) See the other message I just
posted.

 > > And finally, I'm still not entirely clear on what the benefit of a
 > > devfs is supposed to be.  [...]
 > 
 > I entirely agree with you here.  I see devfs as a solution looking for
 > a problem.

There is a problem of sorts; there's a reason it's widely thought that
some kind of devfs is a good idea, and and a reason why people try
over and over to implement a useful one despite the repeated failures.

However, the reason there are repeated failures is that the problem is
deeper than generally realized and the solutions don't take this into
account. :-/

(I would characterize the underlying problem as "device special files
are a hack.")

-- 
David A. Holland
dholland%netbsd.org@localhost