Subject: Re: devfs, was Re: ptyfs fully working now...
To: Bill Studenmund <wrstuden@NetBSD.org>
From: Jonathan Stone <firstname.lastname@example.org>
Date: 11/29/2004 18:51:44
In message <20041130023234.GC28385@netbsd.org>,
Bill Studenmund writes:
>Content-Type: text/plain; charset=us-ascii
>On Mon, Nov 29, 2004 at 11:06:17AM -0800, Jonathan Stone wrote:
>> In message <20041127230339.GC25324@netbsd.org>,
>> Bill Studenmund writes:
>> >I think that Eric's comment was either incorrect or poorly-worded. I thi=
>> >we will depreciate all on-disk device nodes with devfs,=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=
>system) will need changes, and I am not looking forward to maintianing the=
>old and the new ways in one kernel.
<Shrug>. Again, see Christos' message about "devfs will be optional
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
>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
Yes, exactly. And for anyone who cares about security in the
short-to-medium term, that's static in-filesystem inodes.