From: Stamatis Mitrofanis <ewstam@softhome.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: A cleaner load_drivers function.
Date: Sat, 05 Jan 2002 18:42:24 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-101026510609536@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-101018898908226@msgid-missing>
Stamatis Mitrofanis wrote:
> To put it more clearly: just load the module _unless_ there exists
> /etc/hotplug/TYPE/DRIVER.agent to delegate to.
>
> Note the `.agent' extension!
>
> IMO, this driver-agent interface is much more forward-looking and
> uniform. You just can't exclude the possibility that a driver may want
> to do something device-specific in user-space _before_ `modprobe'ing.
The driver-specific agents can do some _additional filtering_ this way.
(I forgot that -- why do I keep forgetting to mention things? :-( )
The input subsystem can be an example. It has many bitmasks, some more
than 32 bits.
ACTION ... add|remove
PRODUCT ... idbus/idvendor/idproduct/idversion
NAME ... Device name from device descriptor.
PHYS ... pci00:07.2/usb0:2.3/input0 (device physical address ID).
EV ... Bitmask (32 bits) for the kinds of events this device supports.
KEY ... 511 bits for the keys&buttons the device has.
REL ... 15 bits for relative axes (x/y/z, mouse-wheel etc.) it provides.
ABS ... 31 bits for absolute axes (x/y/z, throttle, pressure etc.).
LED ... 15 bits for the LEDs on the device (num/caps-lock etc.).
SND ... 7 bits for the characteristic sounds the device can make (beep!).
FF ... 127 bits for supported force-feedback effects!
MSC ... 7 more bits for the rest.
It would be great if the input-driver-specific agents could do some
extra filtering as appropriate.
/****/
Here is a _tiny_ patch that will make load_drivers delegate (full
backward compatibility):
diff -r linux-hotplug/etc/hotplug/hotplug.functions
linux-hotplug2/etc/hotplug/hotplug.functions
123a124,130
> # Available driver-specific agent?
> if [ -f "/etc/hotplug/$TYPE/$MODULE.agent" -a \
> -x "/etc/hotplug/$TYPE/$MODULE.agent" ]; then
> "/etc/hotplug/$TYPE/$MODULE.agent"
> continue
> fi
>
Now, the driver-specific agent (if available) can handle `add' events
for devices it most likely handles. It can forget about devices it
doesn't really handle.
It would be a good idea to extend the `load_drivers' interface so that
it handles `remove' events as well.
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
prev parent reply other threads:[~2002-01-05 18:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-04 2:05 A cleaner load_drivers function Stamatis Mitrofanis
2002-01-04 2:05 ` Stamatis Mitrofanis
2002-01-05 18:42 ` Stamatis Mitrofanis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-hotplug-101026510609536@msgid-missing \
--to=ewstam@softhome.net \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.