Subject: Re: devfs, was Re: ptyfs fully working now...
To: Bill Studenmund <>
From: Jonathan Stone <>
List: tech-kern
Date: 11/29/2004 18:51:44
In message <>,
Bill Studenmund writes:

>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 <>,
>> 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
>not two.

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