Subject: Re: ZIP drive problems
To: None <thorpej@nas.nasa.gov>
From: Terry Lambert <terry@lambert.org>
List: port-hp300
Date: 01/10/1997 11:04:57
> On Thu, 9 Jan 1997 16:53:45 -0700 (MST) 
>  Terry Lambert <terry@lambert.org> wrote:
> 
>  > Is there any plans to move to a devfs in the near future for NetBSD/OpenBSD?
> 
> Once problems like "how to preserve permissions and symlinks across reboot"
> and other nastiness surrounding devfs are resolved, NetBSD may get one.

This is the strange question people ask in the FreeBSD camp as well.

Other than syslog (which should be moved to /var instead of being in
/dev), there is no need for links; if there were, there is always
the possibility of a union mount to provide them.

Permissions are either set transiently by programs with sufficient
priveledge (which works without a backing store), or they are
established as a matter of system policy (in which case they can
be implemented at kernel compilation time via data changes instead
of at runtime with the expectation of persistance).

At absolute worst, rc.shutdown could store the permissions and rc.local
could put them back once the system comes back up.  If you allowed for
transient changes (such as the existance of symlinks) that could work
too.

I would discourage the use of symlinks in devfs; I would like to see
the "struct fileops" go away.  The main offenders are the pipe, AF_LOCAL
(AF_UNIX) domain socket, and specfs code.  devfs kills specfs, and I
would like to see pipes and named sockets move down where they belong
as well.  This would *greatly* simplify the gymnastics necessary to
get a character in or out of an object opened from the FS name space,
no matter which FS it was openend on.


> Also, in the future, please do not ask questions about OpenBSD on port-hp300.
> It is a NetBSD mailing list.

Noted.


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