--XOIedfhf+7KOe/yw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 26, 2004 at 01:23:08PM -0800, Jonathan Stone wrote:
> In message <DBD36E09-3E62-11D9-9EC5-000A957650EC@shagadelic.org>,
> Jason Thorpe writes:
>=20
> >On Nov 19, 2004, at 2:56 PM, Jonathan Stone wrote:
> >
> >> I know of certain applications where old-style nodes in the fs is an
> >> absolute, non-negotiable requirement, and for which the proposed devfs
> >> is an absolute non-starter.
>=20
> >Give me an example. =20
>=20
> As someone -- perhaps Daniel Carosone -- guessed at: think of an
> hardened embedded device (not unlike the hardened routers Thor
> sometimes talks about) The kind of embedded-device where perhaps you
> already have filesystems set up as either executable, or non-writable,
> or both.  (For a second example, think of a chroot jail in such an
> appliance.)

I'm sorry, but I do not at all see how such a device is one that NEEDS=20
on-disk nodes. I can see how it wants things to be locked down, but the=20
devfs ideas I've heard (and have in my head) can lock stuff down.

If you're creating such images, you're creating an image of the root file
system as part of creation (I'd expect you're shoving it into a kernel
like what we do for install kernels, but you might do something else). =20
So just build into this image a devfs file (of whatever form we end up
with) that has your devices as you like them. Add a mount flag, and new=20
devices don't show up. So you get exactly what you configured.

As long as this image is constructed such that "/dev/foo" will access
device bar, why does it matter if /dev is a devfs or a directory on /?

I admit that I've objected to having the canonical data storage for devfs=
=20
be in a text mtree file. However I do think it'll be useful to have tools=
=20
that will take devfs info and turn it into an mtree segment and vis versa.

> I can think of even more stringent requirements giving more compelling
> examples, but I don't much care to discuss them in public when people
> are taking unreasonable views from the get-go.

Actually, you're the one being unreasonable at the moment. :-) You're
saying that everyone (or at least the vocal discussion) is starting with
unreasonable views from the get-go, but you aren't saying why. You're just
stating that they are.

> >That sounds absolutely ridiculous to me.
>=20
> There are applications where devfs is a non-starter.  That's just a
> fact. Objecting to facts is unreasonable.

No, actually, it's an assertion. We are asking you to explain what a devfs
won't do that on-disk dev inodes will do. Once you do this, I think one of
three things will happen: 1) we will ask you to elaborate on a specific
point as we didn't see the distinction, 2) we will explain how we believe
devfs will do what you are describing needing, or 3) we will realize we
left something out of the devfs ideas we have and will add a requirement=20
to all devfs implementations to address the issue(s) you have in mind.

The third reason is why I really really want you to explain what you are=20
thinking. While I think that the proposals we have for different devfs=20
implementations will not be visible to applications (they can't tell the=20
difference between devfs nodes and on-disk ones), I could be wrong.

Take care,

Bill

--XOIedfhf+7KOe/yw
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBqQV0Wz+3JHUci9cRAvM2AJ9yF0jFV6wsQED6h9fNrxMioi7aOgCfeM6p
5yEMKaRSZBh5PzUUkRpzAmU=
=EwI7
-----END PGP SIGNATURE-----

--XOIedfhf+7KOe/yw--