* Re: Support for multiple usermaps in hotplug usb.agent
2002-07-19 0:10 Support for multiple usermaps in hotplug usb.agent Maksim (Max) Krasnyanskiy
@ 2002-07-21 13:57 ` Maksim (Max) Krasnyanskiy
2002-07-21 13:58 ` Maksim (Max) Krasnyanskiy
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Maksim (Max) Krasnyanskiy @ 2002-07-21 13:57 UTC (permalink / raw)
To: linux-hotplug
> > 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.
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Support for multiple usermaps in hotplug usb.agent
2002-07-19 0:10 Support for multiple usermaps in hotplug usb.agent Maksim (Max) Krasnyanskiy
2002-07-21 13:57 ` Maksim (Max) Krasnyanskiy
@ 2002-07-21 13:58 ` Maksim (Max) Krasnyanskiy
2002-07-21 17:26 ` Fumitoshi UKAI
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Maksim (Max) Krasnyanskiy @ 2002-07-21 13:58 UTC (permalink / raw)
To: linux-hotplug
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Support for multiple usermaps in hotplug usb.agent
2002-07-19 0:10 Support for multiple usermaps in hotplug usb.agent Maksim (Max) Krasnyanskiy
2002-07-21 13:57 ` Maksim (Max) Krasnyanskiy
2002-07-21 13:58 ` Maksim (Max) Krasnyanskiy
@ 2002-07-21 17:26 ` Fumitoshi UKAI
2002-07-21 17:54 ` Johannes Erdfelt
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Fumitoshi UKAI @ 2002-07-21 17:26 UTC (permalink / raw)
To: linux-hotplug
Hi,
At Thu, 18 Jul 2002 17:10:45 -0700,
Maksim (Max) Krasnyanskiy wrote:
> 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.
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Support for multiple usermaps in hotplug usb.agent
2002-07-19 0:10 Support for multiple usermaps in hotplug usb.agent Maksim (Max) Krasnyanskiy
` (2 preceding siblings ...)
2002-07-21 17:26 ` Fumitoshi UKAI
@ 2002-07-21 17:54 ` Johannes Erdfelt
2002-07-22 4:55 ` David Brownell
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Johannes Erdfelt @ 2002-07-21 17:54 UTC (permalink / raw)
To: linux-hotplug
On Mon, Jul 22, 2002, Fumitoshi UKAI <ukai@debian.or.jp> wrote:
> At Thu, 18 Jul 2002 17:10:45 -0700,
> Maksim (Max) Krasnyanskiy wrote:
>
> > 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.
>
> > 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
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Support for multiple usermaps in hotplug usb.agent
2002-07-19 0:10 Support for multiple usermaps in hotplug usb.agent Maksim (Max) Krasnyanskiy
` (3 preceding siblings ...)
2002-07-21 17:54 ` Johannes Erdfelt
@ 2002-07-22 4:55 ` David Brownell
2002-07-22 22:03 ` Maksim (Max) Krasnyanskiy
2002-07-24 1:34 ` David Brownell
6 siblings, 0 replies; 8+ messages in thread
From: David Brownell @ 2002-07-22 4:55 UTC (permalink / raw)
To: linux-hotplug
Maksim (Max) Krasnyanskiy wrote:
>>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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Support for multiple usermaps in hotplug usb.agent
2002-07-19 0:10 Support for multiple usermaps in hotplug usb.agent Maksim (Max) Krasnyanskiy
` (4 preceding siblings ...)
2002-07-22 4:55 ` David Brownell
@ 2002-07-22 22:03 ` Maksim (Max) Krasnyanskiy
2002-07-24 1:34 ` David Brownell
6 siblings, 0 replies; 8+ messages in thread
From: Maksim (Max) Krasnyanskiy @ 2002-07-22 22:03 UTC (permalink / raw)
To: linux-hotplug
At 09:55 PM 7/21/2002 -0700, David Brownell wrote:
>Maksim (Max) Krasnyanskiy wrote:
>>>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 ?
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.
>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.
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Support for multiple usermaps in hotplug usb.agent
2002-07-19 0:10 Support for multiple usermaps in hotplug usb.agent Maksim (Max) Krasnyanskiy
` (5 preceding siblings ...)
2002-07-22 22:03 ` Maksim (Max) Krasnyanskiy
@ 2002-07-24 1:34 ` David Brownell
6 siblings, 0 replies; 8+ messages in thread
From: David Brownell @ 2002-07-24 1:34 UTC (permalink / raw)
To: linux-hotplug
>> 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.
>> 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?
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 8+ messages in thread