In message <20041130023234.GC28385@netbsd.org>,
Bill Studenmund writes:

>
>--UPT3ojh+0CqEDtpF
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Mon, Nov 29, 2004 at 11:06:17AM -0800, Jonathan Stone wrote:
>> In message <20041127230339.GC25324@netbsd.org>,
>> Bill Studenmund writes:
>>=20
>> >I think that Eric's comment was either incorrect or poorly-worded. I thi=
>nk
>> >we will depreciate all on-disk device nodes with devfs,=20
>>=20
>> Why on Earth would you want to do that?  I'd be happy with a dynamic
>> devfs on my laptop, but static on-disk (actually, in-filesystem, with
>> static in-filesystem permissions) device nodes are *EXACTLY* what I
>> want. For certain applications.
>
>Because specfs (the add-ons we have to hook device vnodes into the device=
>=20
>system) will need changes, and I am not looking forward to maintianing the=
>=20
>old and the new ways in one kernel. 

<Shrug>.  Again, see Christos' message about "devfs will be optional
until...".

I submit if you and Jason want devfs now, that maintenance is the
price you have to pay. Until and unless there's both: (i) a consensus
that there's enough commited machinery to supplant the status quo;
and  (ii) said necessary machinery is sufficiently secure,
well-designed, well-implemented, and well-tested, that we can
seriously contemplate removing static device inodes.

At least, that's how I read Christos' message.  My estimate for that
(looking at progress in other open-source kernels): we're talking a
year or two, not weeks or than months. (And even so, or perhaps as an
interim solution, I -personally- would strongly prefer an option to
allow static device inodes. But that brings back the maintenance
headache.)


>And to be honest, if we're concerned=20
>about security, I think it'd be cleaner to have one way of doing things,=20
>not two.

Yes, exactly. And for anyone who cares about security in the
short-to-medium term, that's static in-filesystem inodes.