--jq0ap7NbKX2Kqbes
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 26, 2005 at 11:15:54AM -0700, Jonathan Stone wrote:
> In message <F1E1A773-FE03-4E20-906D-601FC522D750@shagadelic.org>Jason Tho=
rpe writes
> >
> >On Oct 26, 2005, at 10:22 AM, Bill Studenmund wrote:
> >
> >> In the past, we (NetBSD folks) have talked about a devfs. One issue =
=20
> >> that
> >> has come up (I'll be honest, I've raised it a lot)=20
>=20
> And me, too. I suspect Thor Lancelot Simon and a few others are in the
> same camp.
>=20
> >> is a desire to =20
> >> retain
> >> permission changes across boots, and to tie devices (when possible) =
=20
> >> to a
> >> device-specific attribute rather than a probe order.
> >
> >The permission thing is solvable using scripts that can fix up the =20
> >perms after mount.
>=20
> Huh?? But for those of us like Bill and Thor, that doesn't even come
> clsoe to a solution.  Not when you need to build, and freeze, a
> pre-defined set of device-node and permissions.  When that's what you
> really want, *no* devfs is a workable subsitute for persistent
> filesystem state.  (think: securelevel 2...)

I'm not so sure about that. I agree it would need to be done "well," and=20
that most implementations today may not match that criteria.

But I think if we had a set of requirements, we could get it done. For=20
instance, make devfs aware of securelevel. If you want it to not permit=20
changes above secure level X, we can do that.

For instance, say we configured devfs to require all nodes actually be=20
created by userland. Then said script (or more likely a config file for=20
the script) becomes your wiring down. One thing I really like is the idea=
=20
that you can chmod a device node and its changes stick. That could be=20
achieved by having a daemon update the script or data file in response to=
=20
the change.

> >The "nodes named after attributes" thing is interesting... and =20
> >largely something I'm concerned about with wedges, although in that =20
> >case, it's pretty easy to handle from within wedges itself.
> >
> >> Does FreeBSD's devfs support locators and persistent information? Are
> >> there plans to support something like that, if not?
> >
> >FreeBSD's devfs does not, to my knowledge, include the things that =20
> >you have mentioned above.
> >
> >FWIW, I think a devfs based on our new tmpfs would be better for NetBSD.
>=20
> Maybe so, but how can we support a "no devfs allowed here" for those
> who depend on the decades-old existinge semantics?

In the long run, I think we shouldn't. While I have a lot of thoughts=20
about what I want/think devfs should be, I think we can achieve it. I=20
think if we figured out what you really want from the existing semantics,=
=20
we can do that.

Part of the reason I think we shouldn't support both devfs and no-devfs is=
=20
that one huge point of devfs is that we no longer need to worry about=20
explicit major numbers. I don't see how we can really support that with a=
=20
no-devfs world. All the thoughts that come to mind seem like they are=20
equivalent to really locked-down devfs environments. So let's just lock=20
down devfs and be done with it. :-)

Take care,

Bill

--jq0ap7NbKX2Kqbes
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFDYAzWWz+3JHUci9cRAmnnAJ90msL8XcUwoS95BoWrdj+ru29PwwCfROjp
WDC1rVZj2TTR3BZFK3unVlQ=
=YNp/
-----END PGP SIGNATURE-----

--jq0ap7NbKX2Kqbes--