Subject: Re: devfs, was Re: ptyfs fully working now...
To: Christos Zoulas <christos@zoulas.com>
From: Steven M. Bellovin <smb@research.att.com>
List: tech-kern
Date: 11/12/2004 22:34:36
In message <20041113033122.4CA9E2AC7B@beowulf.gw.com>, Christos Zoulas writes:
>On Nov 12, 10:18pm, smb@research.att.com ("Steven M. Bellovin") wrote:
>-- Subject: Re: devfs, was Re: ptyfs fully working now...
>
>| This is all pretty convoluted.  Let me phrase the question this way: 
>| what problem does this solve?  I see two possibilities: it keeps /dev 
>| from being cluttered with non-existent nodes, and it avoids the 
>| necessity of having to create nodes when a new device is added.  Let me 
>| suggest a simpler devfs that will avoid the need for this file.
>| 
>| Indeed have a devfs.  At boot time, though, before anything at 
>| userlevel is run and before devfs is mounted, each device driver 
>| verifies that its /dev entries exist.  Any that don't exist --
>| this can be table-driven, with parameters describing what nodes are
>| to be created.  That solves the second problem.  The first problem is 
>| solved by a devfs layer that, before returning any device inode, 
>| verifies that it exists in the running system.
>
>Where is that table? In userland or the kernel? What are the permissions
>and ownerships for these devices? Can they change?

The table is compiled into the drivers, and has the same defaults that 
are currently instantiated in MAKEDEV.  The other questions are not 
nearly as important, because a table entry is used once per device per 
system, to create the initial /dev entries.  The sysadmin can create 
links or symlinks for new names; the ownership and modes after the name 
exists are entirely irrelevant to the kernel, and can be changed at 
will by the administrator or by various daemons (as is done for ttys 
now).

I'll post more when I'm awake.

		--Steve Bellovin, http://www.research.att.com/~smb