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

On Tue, Nov 30, 2004 at 03:54:33AM -0500, Matthew Orgass wrote:
> On 2004-11-29 wrstuden@NetBSD.org wrote:
> > On Sun, Nov 28, 2004 at 01:15:11AM -0500, der Mouse wrote:
> >
> > The biggest thing we gain with some sort of devfs vs new dev nodes is t=
hat
> > we don't have to change any file systems; we aren't creating a new on-d=
isk
> > inode type.
>=20
>   Something else to consider might be how devfs would differ from an
> improved mfs design containing these special nodes (plus some helper
> tools).  I am fairly certain that everything a specialized devfs could do
> could be arranged to work under a general mfs system with userland support
> and a few minimally "special" additions, although some devfs possiblities
> would work better than others this way.

Well, mfs is ffs which is also ufs. So you're still talking about changing=
=20
an on-disk file system. You're just suggesting limited changes to a=20
probably-never-on-disk case.

>   A few other thoughts I don't remember reading yet (that may not be
> entirely self consistant):
>=20
> * If there are separate per instance and default permissions on devices,
> userland could do complex device recognition per instance without worrying
> that the modified per instance permissions will accedently be applied to
> the wrong device.  This could be implemented on a mfs or disk based system
> by requiring that a device be "blessed" after it appears before named
> device nodes successfully refer to the device (an option to autobless all
> devices could also be available to allow fixed configuration similar to
> current behavior).  A userland program would get an event notification
> when devices are attached and removed and could remove the file at detach
> (if desired) and add and set default permissions on all nodes that it
> manages at attach time before blessing the device (of course, nodes that
> it doesn't know about wouldn't be changed but use of nodev by default
> except on those file systems intended to be used for mfs would avoid this
> problem by default while allowing such nodes to be created if desired).

Uhm, I don't think we need the "blessing" step as userland will be the=20
agent creating the device node, in this scheme. Removing the node on=20
deletion sounds good too.

> * I would like to see the permissions map separate from saved atimes, etc.
> to reduce the chance of time update corrupting the map (which could be
> more likely if everything lives in a single file) and so that it could
> easily live on a read only file system.  This would make the most sense if
> changing the permissions on a file in a mounted devfs did not change the
> default but only the instance permissions.

I think this idea would be a bad one. I much prefer keeping all of the=20
information in one place. It strikes me as much simpler to audit if you=20
only have to look in one file.

As to issues involving errors on write, I think a rather simple solution=20
is to have two copies of the file and ping-pong between them.

> * In general, allowing dynamic behavior to be constrained by userland
> programs (and not just static files) seems like a good thing to me, as
> long as the interaction of such programs is designed to do so safely.
>=20
> * I don't think there should be any magical default permissions
> (especially not in drivers); entirely new device types should never appear
> until permissions are provided by the admin.  I do think the ability to
> specify default permissions for any number of such devices or for a
> limited range of such devices would be a good thing.  It would also be a
> good idea to make it possible for modload to add such permissions (but it
> should not do so by default).

Why? Note that there is a difference between the device having default=20
permissions and the node showing up. In all the devfs proposals I've seen,=
=20
there either has been an explicit hook for policy upload to the kernel=20
(the binary file idea I've suggested) or userland daemons (what you're=20
proposing), or there could be one (devfs on other nodes, say symlinks). So=
=20
there is a space to say, "don't just add nodes." Thus the act of the=20
device showing up (with the despised, uncontrolled default permissions)=20
can be easily stopped.

> * I think the idea of "locator" names needs more thought, or at least more
> desciption.  Multiple namespaces raises the possiblity of different names
> for different means of reference (device file, kernel printed message,
> sysctl node, ifconfig -a type stuff, etc.), and trying to determine what
> name is appropriate where and matches what other name(s) could become an
> easy source of error and confusion.  I haven't noticed any suggested
> details about how this would work in this thread.

The only locator namespace I've had in mind, and the only one I've=20
understood other folks have had in mind, is that of kernel devices. i.e.=20
config locators, the things you can put in kernel config files.

Take care,

Bill

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

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

iD8DBQFBrPqoWz+3JHUci9cRAvkVAJ9jxfds3gyB3F+zw1gBVWAkJVzPvwCeMR6+
Q/GvRudcgxUphslSg74CdlY=
=DcyO
-----END PGP SIGNATURE-----

--eJnRUKwClWJh1Khz--