Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
- From: Owen Taylor <otaylor redhat com>
- To: jg pa dec com (Jim Gettys)
- Cc: Dr Andrew C Aitchison <A C Aitchison dpmms cam ac uk>, David Brownell <david-b pacbell net>, Ryan Shaw <ryan shaw stanfordalumni org>, linux-hotplug-devel lists sourceforge net, wm-spec-list gnome org, xpert XFree86 Org
- Subject: Re: [Xpert]Re: User-level Tasks in Hotplug Scripts?
- Date: Mon, 4 Feb 2002 00:57:44 -0500 (EST)
jg pa dec com (Jim Gettys) writes:
> This is certainly true: but not sufficient...
I wasn't trying to give a complete solution, just trying to dispell
any notion that interactivity with hotplug events would necessarily
involve popping up a root shell on the current login users desktop :-)
> Here's the sequence as I understand it:
> 1) new device gets plugged in.
> 2) system has to figure out what driver to use.
> 3) if it has seen it before, presumably it can consult some sort of database
> to help hook it up, both by whatever driver parameters it needs, and to hook
> it up to a user level program it activates. We're done at this point.
> 4) if the system has never seen it before, we have to somehow ask the user
> what to do.
> 5) the driver finally gets loaded, with the user specified configuration
> information that might be required.
> 6) record the necessary driver configuration, and go to 3).
> So what we need is a convention whereby the hotplug framework activates
> a GUI component talking to the user somewhere on the network to get
> the configuration data required, and a way to communicate that configuration
> information back to the hotplug system to record for future use (and completion
> of the first hot plug event for that device).
> So the hotplug scripts (running as root) have to be able to initiate the
> GUI talking to the user, and get data back from there. And it isn't
> necessarily on the same system, as hotplug is not all about human interface
> devices: it is also used for disk drives, tapes, etc, and eventually pluggable
> processors, memory etc.
> So we have two problems:
> o A convention of how to know who is administering this system. It may
> be this is something just for the hotplug folks to worry about.
> o How to securely get the right configuration back and forth from the user;
> this is the authentication problem, in concert with how to get data back
> and forth...
I think it probably makes sense to reduce the communication to one of
- In response to the hotplug event, if the device can't
be configured automatically, record that data, and
notify the appropriate user(s).
- When the user gets the notification, present them with the
option to run a config tool, which would then complete
This has various advantages; principally.
- It's flexible (notification could be sending an email
saying "go to this URL to configure your new printer.)
- It reduces the authentication problem to a known and
solved problem. (Can user X do Y.)
In terms of how to do notification, you can go from simple to complex:
- Watch a file in a timeout. (We had hotplug for USB storage
devices in Red Hat 7.1 working quite nicely by watching
/etc/fstab for changes; kudzu added new entries in
response to hotplug events. magicdev noticed the
changes, signaled mc which added icons on the desktop.)
- Local messaginge daemon; if you keep it simple, use unix
perms, don't worry to much about quality-of-service, etc,
it doesn't need to be a big project.
- Networked based messaging; jabber, etc. May make
sense to piggyback off an existing solution. But then
you get the problem that you are talking about something
big that everybody needs to adopt.
Anyways, just my random thoughts on the issue. My main observation is
that I think it's a mistake to think of this as "hotplug script pops
up a configuration dialog" even if it might appear like that to the
user in the simplest case.
] [Thread Prev