Support for multiple usermaps in hotplug usb.agent
Hi Ukai,
We were discussing my proposal to introduce support for multiple usermaps in usb.agent
on linux-hotplug-devel mailing list. David Brownell had a concern that my solution
is different from Debian and therefor may introduce some problems. So I'd like to get your opinion, as a Debian hotplug maintainer, on that.
Here is my patch for hotplug 2002.04.01
usb.agent Thu Jul 18 04:53:02 2002 renamed from usb.agent.orig Thu Jul 18 01:03:23 2002 +11 -8
@@ -82,8 +82,7 @@ # config scripts (which mustn't overlap with kernel modules). Those # could change $DEVICE permissions, etc. # -MAP_USERMAP=$HOTPLUG_DIR/usb.usermap - +MAP_USERMAP_DIR=$HOTPLUG_DIR/usb # accumulates list of modules we may care about DRIVERS=""
@@ -335,13 +334,17 @@ fi # some devices have user-mode drivers (no kernel module, but config) - # or specialized user-mode setup helpers - if [ -r $MAP_USERMAP ]; then + # or specialized user-mode setup helpers + MAPS="$HOTPLUG_DIR/*.usermap $MAP_USERMAP_DIR/*.usermap" + if [ "$MAPS" != "" ]; then MODPROBE=: - load_drivers usb $MAP_USERMAP "$LABEL" - if [ "$DRIVERS" != "" ]; then - FOUND=true - fi + for map in $MAPS; do + load_drivers usb $map "$LABEL" + if [ "$DRIVERS" != "" ]; then + FOUND=true + break + fi + done fi if [ "$FOUND" = "false" ]; then
---
Basically the idea is simple. Packages/subsystems simply install their own XXX.usermap
into /etc/hotplug/usb. And usb.agent processes them in addition to original usb.usermap.
It seems to be simpler than what Debian does right now. ie generating new usb.usermap
whenever something gets installed or uninstalled.
Comments ?
Max
http://bluez.sf.net
http://vtun.sf.net
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines
Quoted 2 lines
Basically the idea is simple. Packages/subsystems simply install their own XXX.usermap
With update-usb.usermap(8), package install own usb.usermap in /usr/lib/hotplug/<package>/usb.usermap, and do as follows in postinst & postrm
if [ -x/usr/sbin/update-usb.usermap]; then
/usr/sbin/update-usb.usermap
fi
Quoted 2 lines
Sorry, this information should be in
/usr/share/doc/hotplug/README.Debian. I'll add this in next upload.
Sure. I looked at the sources and know all that :)
I guess the question is do you see any problems with my approach ?
Max
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines
Why do you rebuild the usermap database. Would it be easier to just find a group of usermap's via a glob and then parse all of them each hotplug, like Maksim's patch ?
The only advantage I can think of rebuilding the database, is you can better control conflicts, but that's a tricky situation anyway.
They don't resolve any conflicts. update.usermap is pretty much just
for map in $(all installed maps); do cat $map >> /etc/hotplug/usb.usermap done
Max
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Hi,
At Thu, 18 Jul 2002 17:10:45 -0700,
Quoted 8 lines · Maksim (Max) Krasnyanskiy
Hi Ukai,
We were discussing my proposal to introduce support for multiple usermaps in usb.agent
on linux-hotplug-devel mailing list. David Brownell had a concern that my solution
is different from Debian and therefor may introduce some problems. So I'd like to get your opinion, as a Debian hotplug maintainer, on that.
hotplug.deb has update-usb.usermap(8) to manage such situations.
Quoted 2 lines
Basically the idea is simple. Packages/subsystems simply install their own XXX.usermap
With update-usb.usermap(8), package install own usb.usermap in /usr/lib/hotplug/<package>/usb.usermap, and do as follows in postinst & postrm
if [ -x /usr/sbin/update-usb.usermap ]; then
/usr/sbin/update-usb.usermap
fi
Sorry, this information should be in /usr/share/doc/hotplug/README.Debian. I'll add this in next upload.
Regards,
Fumitoshi UKAI
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 17 lines · Fumitoshi UKAI
At Thu, 18 Jul 2002 17:10:45 -0700,
Quoted 8 lines · Maksim (Max) Krasnyanskiy
Hi Ukai,
We were discussing my proposal to introduce support for multiple usermaps in usb.agent
on linux-hotplug-devel mailing list. David Brownell had a concern that my solution
is different from Debian and therefor may introduce some problems. So I'd like to get your opinion, as a Debian hotplug maintainer, on that.hotplug.deb has update-usb.usermap(8) to manage such situations.
Quoted 2 lines
Basically the idea is simple. Packages/subsystems simply install their own XXX.usermap
Quoted 6 lines
With update-usb.usermap(8), package install own usb.usermap in /usr/lib/hotplug/<package>/usb.usermap, and do as follows in postinst & postrm
if [ -x/usr/sbin/update-usb.usermap]; then
/usr/sbin/update-usb.usermap
fi
Why do you rebuild the usermap database. Would it be easier to just find a group of usermap's via a glob and then parse all of them each hotplug, like Maksim's patch?
The only advantage I can think of rebuilding the database, is you can better control conflicts, but that's a tricky situation anyway.
JE
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 11 lines · Maksim (Max) Krasnyanskiy
Quoted 6 lines
Why do you rebuild the usermap database. Would it be easier to just find a group of usermap's via a glob and then parse all of them each hotplug, like Maksim's patch ?
The only advantage I can think of rebuilding the database, is you can better control conflicts, but that's a tricky situation anyway.
They don't resolve any conflicts. update.usermap is pretty much just
for map in $(all installed maps); do cat $map >> /etc/hotplug/usb.usermap done
So at a technical level, ignoring the "where does stuff install" issue (we want just one answer, the path doesn't much matter) the only real difference is who does the match/catenate, and when.
In fact, if Max's patch had scanned /usr/lib/hotplug/*/usb.usermap, then there'd be compatibility with Debian, and Debian could get rid of the "update.usermap" script. Yes?
How did /usr/lib/hotplug get settled on? There's also some code using /usr/share/usb (/usr/lib is wrong for sharable stuff ...) for firmware downloading, and I see that RedHat has /usr/share/hwdata/usb.ids ... that is, not using /usr/share/usb either. Does the Linux Filesystem standard have anything useful to say about this? Shouldn't it?
In general I tend to think avoiding extra commands ("update.usermap") is a good thing, but then so is avoiding wildcards in shell scripts. In this case I'd prefer the latter, I must say.
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 12 lines · David Brownell
Quoted 10 lines · Maksim (Max) Krasnyanskiy
Quoted 6 lines
Why do you rebuild the usermap database. Would it be easier to just find a group of usermap's via a glob and then parse all of them each hotplug, like Maksim's patch ?
The only advantage I can think of rebuilding the database, is you can better control conflicts, but that's a tricky situation anyway.
They don't resolve any conflicts. update.usermap is pretty much just
for map in $(all installed maps); do
cat $map >>/etc/hotplug/usb.usermap
done
Quoted 7 lines
So at a technical level, ignoring the "where does stuff install" issue (we want just one answer, the path doesn't much matter) the only real difference is who does the match/catenate, and when.
In fact, if Max's patch had scanned
/usr/lib/hotplug/*/usb.usermap, then there'd be compatibility with Debian, and Debian could get rid of the "update.usermap" script. Yes ?
I guess so. It should work for them.
btw if we simply kept support for the central usb.usermap it will work fine with current
update-usb.usermap.
Quoted 9 lines
How did
/usr/lib/hotplugget settled on? There's also some code using/usr/share/usb(/usr/libis wrong for sharable stuff ...) for firmware downloading, and I see that RedHat has/usr/share/hwdata/usb.ids... that is, not using/usr/share/usbeither. Does the Linux Filesystem standard have anything useful to say about this? Shouldn't it?In general I tend to think avoiding extra commands ("update.usermap") is a good thing, but then so is avoiding wildcards in shell scripts. In this case I'd prefer the latter, I must say.
I don't see how wildcards would be a problem (assuming they're used appropriately).
Anyway in this case update.usermap is extra commands and shell wildcards ;) (update.usermap uses shell wildcards).
Max
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines
Quoted 3 lines
In fact, if Max's patch had scanned
/usr/lib/hotplug/*/usb.usermap, then there'd be compatibility with Debian, and Debian could get rid of the "update.usermap" script. Yes ?I guess so. It should work for them.
btw if we simply kept support for the central usb.usermap it will work fine with current
update-usb.usermap.
My thought exactly. How about this: Max generalizes his (small :) patch to use a configurable location (or several? :) for usbmap extensions, so Debian can point that to /usr/lib/hotplug (assuming it still wants), and other distros can use /etc/hotplug/usb. Then "update-usb.usermap" could vanish from Debian (shouldn't matter in the short term), and this difference would all but go away. Someone writes this up for the usb hotplug webpage.
Quoted 5 lines
Quoted 5 lines
How did
/usr/lib/hotplugget settled on? There's also some code using/usr/share/usb(/usr/libis wrong for sharable stuff ...) for firmware downloading, and I see that RedHat has/usr/share/hwdata/usb.ids... that is, not using/usr/share/usbeither. Does the Linux Filesystem standard have anything useful to say about this? Shouldn't it?
My personal taste is not to create another such directory, FWIW. We have /etc/hotplug and /etc/hotplug/usb already in use, so that'd be my preferred default (as in Max's original patch). Does anyone here do LSB things?
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel