Re: ITP: devfsd
On Sun, Feb 20, 2000 at 04:40:24PM -0700, Bdale Garbee wrote:
> In article <873dqnbgc6.fsf@adsl-63-193-247-253.dsl.snfc21.pacbell.net> you wrote:
> > Elie Rosenblum <fnord@debian.org> writes:
>
> > What I'm doing is writing a config file that tries to duplicate the
> > MAKEDEV permissions. Example lines:
>
> It probably wouldn't be hard to emit this from my hypothetically rewritten
> makedev.
>
> > The trouble with just going through the script is that I don't always
> > know what the new name in devfs is
>
> :-) Keeping makedev up to date as the kernel changes is a similar problem.
Not quite: makedev can choose whatever name it wants, as long as
the numbers match. With devfs, the kernel picks the name of the
device in /dev. So to write a devfsd config you must know the path
name, while with makedev, you can really just make it up. :) (not
really, but since without devfs it's a flat name space, there's
less in question).
> > I'm also thinking of making a directory /etc/devfs-extras/ to hold
> > files, such as a /dev/mouse symlink or /dev/xconsole, which need to be
> > installed at boot time.
>
> Is this completely per-machine, or are most things likely to be Debian'isms?
> I'm trying to understand the division of responsibilities between makedev and
> the devfs user-space code. For example, makedev currently uses an init.d
> fragment to install a /dev/MAKEDEV symlink. I'd like that to just go away
> in the future, but my point is that the makedev package is already trying to
> maintain this one element of persistent state across reboots in the presence
> of devfs...
Things like that are what the devfs init script in my devfs package
already takes care of (which is just a slightly modified version of
the upstream sample script). He is right though that it won't take
care of saving state for devices created by modules, unless the mod
is still loaded when the script saves state, and already loaded when
it restores state.
I'm not ready to put devfs up for adoption (my ITP for devfsd was
about 6 months ago), and I think that working with your development
for a new makedev, we can come up with something that will address
the devfs concerns as well.
I like the idea of a program you can run that updates a file (like
/etc/devfs/debian_dev.conf) that is sourced with a devfsd.conf
OPTIONAL_INCLUDE directive, using data pulled from makedev's
information source. It can then be overridden by /etc/devfs/local.conf
by the user, and the default /etc/devfs/devfsd.conf would just by
default do OPTIONAL_INCLUDE on both files.
--
Elie Rosenblum That is not dead which can eternal lie,
http://www.cosanostra.net And with strange aeons even death may die.
Admin / Mercenary / System Programmer - _The Necronomicon_
Reply to: