Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 08:19:42AM +0100, Dominik Brodowski wrote:
> On Wed, Mar 09, 2005 at 04:45:09PM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote:
> > > > Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Most pcmcia devices are matched to drivers using "product ID strings"
> > > > > embedded in the devices' Card Information Structures, as "manufactor
> > > > > ID /
> > > > > card ID" matches are much less reliable. Unfortunately, these
> > > > > strings cannot
> > > > > be passed to userspace for easy userspace-based loading of
> > > > > appropriate
> > > > > modules (MODNAME -- hotplug), so my suggestion is to also store
> > > > > crc32 hashes
> > > > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > > > >
> > > > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> > > >
> > > > What is the difficulty in passing these strings via /sbin/hotplug
> > > > arguments?
> > >
> > > The difficulty is that extracting and evaluating them breaks the
> > > wonderful
> > > bus-independent MODNAME implementation for hotplug suggested by Roman
> > > Kagan
> > > ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that
> > > these
> > > strings may contain spaces and other "strange" characters. The latter may
> > > be
> > > worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks
> > > really
> > > clean because of this MODNAME implementation:
> >
> > Same goes with Open Firmware match strings that we are about to pass
> > down to userspace as well. Hotplug will have to learn to deal with
> > those.
>
> Hotplug isn't the tricky part. file2alias is. Any idea on how to do that?
I do not, sorry. Rusty's the person to bug about that.
good luck,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
> > > The difficulty is that extracting and evaluating them breaks the > > > wonderful > > > bus-independent MODNAME implementation for hotplug suggested by Roman > > > Kagan > > > ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that > > > these > > > strings may contain spaces and other "strange" characters. The latter may > > > be > > > worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks > > > really > > > clean because of this MODNAME implementation: > > > > Same goes with Open Firmware match strings that we are about to pass > > down to userspace as well. Hotplug will have to learn to deal with > > those. > > Ok, any suggestions that don't involve hashes? Not sure, I haven't looked at the details & issues involves (I just "spotted" the issue about space while quick-reading lkml). I suppose quotes around the strings are good enough, at least for OF, I yet have to see a "compatible", "name" or "type" property with quotes in it... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 04:45:09PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote:
> > > Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Most pcmcia devices are matched to drivers using "product ID strings"
> > > > embedded in the devices' Card Information Structures, as "manufactor
> > > > ID /
> > > > card ID" matches are much less reliable. Unfortunately, these strings
> > > > cannot
> > > > be passed to userspace for easy userspace-based loading of appropriate
> > > > modules (MODNAME -- hotplug), so my suggestion is to also store crc32
> > > > hashes
> > > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > > >
> > > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> > >
> > > What is the difficulty in passing these strings via /sbin/hotplug
> > > arguments?
> >
> > The difficulty is that extracting and evaluating them breaks the wonderful
> > bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
> > ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
> > strings may contain spaces and other "strange" characters. The latter may
> > be
> > worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
> > clean because of this MODNAME implementation:
>
> Same goes with Open Firmware match strings that we are about to pass
> down to userspace as well. Hotplug will have to learn to deal with
> those.
Hotplug isn't the tricky part. file2alias is. Any idea on how to do that?
Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 04:45:09PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote:
> > > Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Most pcmcia devices are matched to drivers using "product ID strings"
> > > > embedded in the devices' Card Information Structures, as "manufactor
> > > > ID /
> > > > card ID" matches are much less reliable. Unfortunately, these strings
> > > > cannot
> > > > be passed to userspace for easy userspace-based loading of appropriate
> > > > modules (MODNAME -- hotplug), so my suggestion is to also store crc32
> > > > hashes
> > > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > > >
> > > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> > >
> > > What is the difficulty in passing these strings via /sbin/hotplug
> > > arguments?
> >
> > The difficulty is that extracting and evaluating them breaks the wonderful
> > bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
> > ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
> > strings may contain spaces and other "strange" characters. The latter may
> > be
> > worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
> > clean because of this MODNAME implementation:
>
> Same goes with Open Firmware match strings that we are about to pass
> down to userspace as well. Hotplug will have to learn to deal with
> those.
Ok, any suggestions that don't involve hashes?
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote:
> > Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> > >
> > > Most pcmcia devices are matched to drivers using "product ID strings"
> > > embedded in the devices' Card Information Structures, as "manufactor ID /
> > > card ID" matches are much less reliable. Unfortunately, these strings
> > > cannot
> > > be passed to userspace for easy userspace-based loading of appropriate
> > > modules (MODNAME -- hotplug), so my suggestion is to also store crc32
> > > hashes
> > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > >
> > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> >
> > What is the difficulty in passing these strings via /sbin/hotplug arguments?
>
> The difficulty is that extracting and evaluating them breaks the wonderful
> bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
> ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
> strings may contain spaces and other "strange" characters. The latter may be
> worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
> clean because of this MODNAME implementation:
Same goes with Open Firmware match strings that we are about to pass
down to userspace as well. Hotplug will have to learn to deal with
those.
> #!/bin/sh
>
> cd /etc/hotplug
> . ./hotplug.functions
>
> if [ "$ACTION" = "" ]; then
> mesg Bad PCMCIA agent invocation, no action
> exit 1
> fi
>
> case $ACTION in
>
> add)
> modprobe $MODNAME
>
> ... work around some exotic buggy PCMCIA hardware ...
> ...
>
> and I would very much like to avoid breaking the line "modprobe $MODNAME".
>
> On Tue, Mar 08, 2005 at 02:54:57PM -0800, Linus Torvalds wrote:
> >
> >
> > On Tue, 8 Mar 2005, Dominik Brodowski wrote:
> > >
> > >Unfortunately, these strings cannot
> > > be passed to userspace for easy userspace-based loading of appropriate
> > > modules (MODNAME -- hotplug), so my suggestion is to also store crc32
> > > hashes
> > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > >
> > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> >
> > Hmm.. I'm with Andrew on this one - I'd much rather really pass them to
> > user space as strings. We already pass a number of strings as environment
> > variables.
> >
> > In fact, what's wrong with DEVPATH? Which we already expose as the
> > NAME=xxx environment variable. So if the kboject associated with a device
> > has has this string associated with its name (which it should)
> drivers/base/core.c::device_add()
> kobject_set_name(>kobj, "%s", dev->bus_id);
> and the bus_id isn't the device's name for common buses.
>
> Nontheless, the strings _are_ exported at DEVPATH/prod_id[1-4], but for the
> reasons mentioned above I'd prefer not to use them.
>
>
> On Tue, Mar 08, 2005 at 12:34:26PM -0800, Andrew Morton wrote:
> > > ...
> > > To make the life easier for device driver authors,
> > > - a big warning is put into dmesg if a pcmcia driver is inserted
> > > into the kernel and the hash mentioned in PCMCIA_DEVICE_PROD_ID()
> > > is incorrect,
> >
> > As long as the kernel shouts loudly at the driver developer at
> > development-time, and that shouting mentions a bit of documentation in
> > Documentation/somewhere, I expect we'll be OK.
>
> Andrew, please apply this patch on top of 2.6.11-mm2, if you and Linus still
> agree:
>
>
> Add some information useful for PCMCIA device driver authors to
> Documentation/pcmcia/, and reference it in dmesg in case of hash mismatches.
>
> Also add a reference to pcmciautils to Documentation/Changes. With recent
> changes, you don't need to concern yourself with pcmcia-cs even if you have
> PCMCIA hardware, so the example above the list needed to be adapted as well.
>
> Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
> Index: 2.6.11+/Documentation/Changes
> ===
> --- 2.6.11+.orig/Documentation/Changes2005-03-08 23:23:30.0
> +0100
> +++ 2.6.11+/Documentation/Changes 2005-03-08 23:23:33.0 +0100
> @@ -44,9 +44,9 @@
>
> Again, keep in mind that this list assumes you are already
> functionally running a Linux 2.4 kernel. Also, not all tools are
> -necessary on all systems; obviously, if you don't have any PCMCIA (PC
> -Card) hardware, for example, you probably needn't concern yourself
> -with pcmcia-cs.
> +necessary on all systems; obviously, if you don't have any ISDN
> +hardware, for example, you probably needn't concern yourself with
> +isdn4k-utils.
>
> o Gnu C 2.95.3 # gcc --version
> o Gnu make 3.79.1 # make --version
> @@ -57,6 +57,7 @@
> o jfsutils 1.1.3 # fsck.jfs -V
> o reiserfsprogs 3.6.3 # reiserfsck -V
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Tue, Mar 08, 2005 at 03:37:07PM -0800, Greg KH wrote: > module aliases, and fixing up modprobe to handle spaces in module > aliases wouldn't work out easier. spaces _and_ characters. And characters are already used to separate different fields. pcmcia:pa"some string"pb"some other string" doesn't look bad though, indeed. Problem is: how to access the strings in file2alias.c? They're in different sections than the __mod_devicetables, and you'd need to get architecture-dependant relocation... so this doesn't seem feasible... or am I missing something? Dominik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 12:16:36AM +0100, Dominik Brodowski wrote:
> > Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> > >
> > > Most pcmcia devices are matched to drivers using "product ID strings"
> > > embedded in the devices' Card Information Structures, as "manufactor ID /
> > > card ID" matches are much less reliable. Unfortunately, these strings
> > > cannot
> > > be passed to userspace for easy userspace-based loading of appropriate
> > > modules (MODNAME -- hotplug), so my suggestion is to also store crc32
> > > hashes
> > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > >
> > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> >
> > What is the difficulty in passing these strings via /sbin/hotplug arguments?
>
> The difficulty is that extracting and evaluating them breaks the wonderful
> bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
> ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
> strings may contain spaces and other "strange" characters. The latter may be
> worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
> clean because of this MODNAME implementation:
I think that MODNAME should be replaced with MODALIAS, but that's a
different email thread...
Anyway, hashes are icky, I still don't see why using the string as
module aliases, and fixing up modprobe to handle spaces in module
aliases wouldn't work out easier.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 12:16:36AM +0100, Dominik Brodowski wrote:
> > Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> > >
> > > Most pcmcia devices are matched to drivers using "product ID strings"
> > > embedded in the devices' Card Information Structures, as "manufactor ID /
> > > card ID" matches are much less reliable. Unfortunately, these strings
> > > cannot
> > > be passed to userspace for easy userspace-based loading of appropriate
> > > modules (MODNAME -- hotplug), so my suggestion is to also store crc32
> > > hashes
> > > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> > >
> > > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
> >
> > What is the difficulty in passing these strings via /sbin/hotplug arguments?
>
> The difficulty is that extracting and evaluating them breaks the wonderful
> bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
> ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
> strings may contain spaces and other "strange" characters. The latter may be
> worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
> clean because of this MODNAME implementation:
In addition: this isn't the problematic part. The product ID string and/or
the hash can easily be passed from kernelspace to userspace in calls to
hotplug, and that's not the real reason for the hashing. Instead, it is
caused by the module.alias generation (even module.pcmciamap, if it existed,
wouldn't be of help here) at compilation time: the format of such aliases is
alias [bus_name]:[{one or multiple chars as separators}{NUMBERS!} multiple such
blocks] [module_name]
This means: only (hex) numbers are allowed as _values_ in such a module alias
map. The module alias map is generated by file2alias.c, which cannot and
should not be able to access strings inside modules, because that would mean
awareness of all sorts of (arch-dependant) relocation. Therefore,
file2alias.c can't calculate the hashes for us, and as the C preprocessor
cannot either, only the explicit passing of strings _and_ hashes to struct
pcmcia_device_id-generating macros is the only feasible way I currently see
to use module.alias for PCMCIA devices.
Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
> Dominik Brodowski <[EMAIL PROTECTED]> wrote:
> >
> > Most pcmcia devices are matched to drivers using "product ID strings"
> > embedded in the devices' Card Information Structures, as "manufactor ID /
> > card ID" matches are much less reliable. Unfortunately, these strings
> > cannot
> > be passed to userspace for easy userspace-based loading of appropriate
> > modules (MODNAME -- hotplug), so my suggestion is to also store crc32
> > hashes
> > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> >
> > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
>
> What is the difficulty in passing these strings via /sbin/hotplug arguments?
The difficulty is that extracting and evaluating them breaks the wonderful
bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
strings may contain spaces and other "strange" characters. The latter may be
worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
clean because of this MODNAME implementation:
#!/bin/sh
cd /etc/hotplug
. ./hotplug.functions
if [ "$ACTION" = "" ]; then
mesg Bad PCMCIA agent invocation, no action
exit 1
fi
case $ACTION in
add)
modprobe $MODNAME
... work around some exotic buggy PCMCIA hardware ...
...
and I would very much like to avoid breaking the line "modprobe $MODNAME".
On Tue, Mar 08, 2005 at 02:54:57PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 8 Mar 2005, Dominik Brodowski wrote:
> >
> > Unfortunately, these strings cannot
> > be passed to userspace for easy userspace-based loading of appropriate
> > modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes
> > of the strings in the MODULE_DEVICE_TABLEs, e.g.:
> >
> > PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
>
> Hmm.. I'm with Andrew on this one - I'd much rather really pass them to
> user space as strings. We already pass a number of strings as environment
> variables.
>
> In fact, what's wrong with DEVPATH? Which we already expose as the
> NAME=xxx environment variable. So if the kboject associated with a device
> has has this string associated with its name (which it should)
drivers/base/core.c::device_add()
kobject_set_name(>kobj, "%s", dev->bus_id);
and the bus_id isn't the device's name for common buses.
Nontheless, the strings _are_ exported at DEVPATH/prod_id[1-4], but for the
reasons mentioned above I'd prefer not to use them.
On Tue, Mar 08, 2005 at 12:34:26PM -0800, Andrew Morton wrote:
> > ...
> > To make the life easier for device driver authors,
> > - a big warning is put into dmesg if a pcmcia driver is inserted
> > into the kernel and the hash mentioned in PCMCIA_DEVICE_PROD_ID()
> > is incorrect,
>
> As long as the kernel shouts loudly at the driver developer at
> development-time, and that shouting mentions a bit of documentation in
> Documentation/somewhere, I expect we'll be OK.
Andrew, please apply this patch on top of 2.6.11-mm2, if you and Linus still
agree:
Add some information useful for PCMCIA device driver authors to
Documentation/pcmcia/, and reference it in dmesg in case of hash mismatches.
Also add a reference to pcmciautils to Documentation/Changes. With recent
changes, you don't need to concern yourself with pcmcia-cs even if you have
PCMCIA hardware, so the example above the list needed to be adapted as well.
Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
Index: 2.6.11+/Documentation/Changes
===
--- 2.6.11+.orig/Documentation/Changes 2005-03-08 23:23:30.0 +0100
+++ 2.6.11+/Documentation/Changes 2005-03-08 23:23:33.0 +0100
@@ -44,9 +44,9 @@
Again, keep in mind that this list assumes you are already
functionally running a Linux 2.4 kernel. Also, not all tools are
-necessary on all systems; obviously, if you don't have any PCMCIA (PC
-Card) hardware, for example, you probably needn't concern yourself
-with pcmcia-cs.
+necessary on all systems; obviously, if you don't have any ISDN
+hardware, for example, you probably needn't concern yourself with
+isdn4k-utils.
o Gnu C 2.95.3 # gcc --version
o Gnu make 3.79.1 # make --version
@@ -57,6 +57,7 @@
o jfsutils 1.1.3 # fsck.jfs -V
o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep
reiserfsprogs
o xfsprogs 2.6.0 # xfs_db -V
+o pcmciautils001
o pcmcia-cs 3.1.21 # cardmgr -V
o quota-tools3.09# quota -V
o PPP2.4.0 # pppd --version
@@ -186,13 +187,20 @@
work correctly with this version of the XFS kernel code (2.6.0 or
later is recommended, due to
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Tue, 8 Mar 2005, Dominik Brodowski wrote:
>
>Unfortunately, these strings cannot
> be passed to userspace for easy userspace-based loading of appropriate
> modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes
> of the strings in the MODULE_DEVICE_TABLEs, e.g.:
>
> PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
Hmm.. I'm with Andrew on this one - I'd much rather really pass them to
user space as strings. We already pass a number of strings as environment
variables.
In fact, what's wrong with DEVPATH? Which we already expose as the
NAME=xxx environment variable. So if the kboject associated with a device
has has this string associated with its name (which it should), then
hotplug will automatially pass that as the DEVPATH.
So if you just fill out the kobject name with the product ID's (well,
with the proper escaping of strange characters, of course), everything
should just work. No?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
Dominik Brodowski <[EMAIL PROTECTED]> wrote:
>
> Most pcmcia devices are matched to drivers using "product ID strings"
> embedded in the devices' Card Information Structures, as "manufactor ID /
> card ID" matches are much less reliable. Unfortunately, these strings cannot
> be passed to userspace for easy userspace-based loading of appropriate
> modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes
> of the strings in the MODULE_DEVICE_TABLEs, e.g.:
>
> PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
What is the difficulty in passing these strings via /sbin/hotplug arguments?
> ...
> To make the life easier for device driver authors,
> - a big warning is put into dmesg if a pcmcia driver is inserted
> into the kernel and the hash mentioned in PCMCIA_DEVICE_PROD_ID()
> is incorrect,
As long as the kernel shouts loudly at the driver developer at
development-time, and that shouting mentions a bit of documentation in
Documentation/somewhere, I expect we'll be OK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
Andrew, Linus, all,
[note: for detailed code please take a look at 2.6.11-mm2]
Most pcmcia devices are matched to drivers using "product ID strings"
embedded in the devices' Card Information Structures, as "manufactor ID /
card ID" matches are much less reliable. Unfortunately, these strings cannot
be passed to userspace for easy userspace-based loading of appropriate
modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes
of the strings in the MODULE_DEVICE_TABLEs, e.g.:
PCMCIA_DEVICE_PROD_ID12("LINKSYS", "E-CARD", 0xf7cb0b07, 0x6701da11),
Only the hashes are stored in "modules.alias", and only the hashes
calculated upon device insertion are passed to userspace.
While having to determine the crc32 hashes is a hassle to device driver
authors, I do not see a smart way to generate these (or similar) hashes
automatically at compilation time:
- the C preprocessor doesn't seem to be smart enough
- scripts/mod/file2alias.c would need to learn all architectures
(and be cross-compilation aware) to relocate/dereference/access
strings saved as
const char * prod_id[4];
in struct pcmcia_device_id s
To make the life easier for device driver authors,
- a big warning is put into dmesg if a pcmcia driver is inserted
into the kernel and the hash mentioned in PCMCIA_DEVICE_PROD_ID()
is incorrect,
- the hash can easily be calculated in userspace from existing
/etc/pcmcia/config files, from inserted PCMCIA cards and and and...,
- I've added the appropriate hashes for all device matches for
drivers in the base linux kernel.
Even though I'm a bit uncomfortable with this solution, I do not see any
other feasible way. Linus, Andrew, do you agree with this handling despite
all the troubles involved with it?
Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
Andrew, Linus, all, [note: for detailed code please take a look at 2.6.11-mm2] Most pcmcia devices are matched to drivers using product ID strings embedded in the devices' Card Information Structures, as manufactor ID / card ID matches are much less reliable. Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), Only the hashes are stored in modules.alias, and only the hashes calculated upon device insertion are passed to userspace. While having to determine the crc32 hashes is a hassle to device driver authors, I do not see a smart way to generate these (or similar) hashes automatically at compilation time: - the C preprocessor doesn't seem to be smart enough - scripts/mod/file2alias.c would need to learn all architectures (and be cross-compilation aware) to relocate/dereference/access strings saved as const char * prod_id[4]; in struct pcmcia_device_id s To make the life easier for device driver authors, - a big warning is put into dmesg if a pcmcia driver is inserted into the kernel and the hash mentioned in PCMCIA_DEVICE_PROD_ID() is incorrect, - the hash can easily be calculated in userspace from existing /etc/pcmcia/config files, from inserted PCMCIA cards and and and..., - I've added the appropriate hashes for all device matches for drivers in the base linux kernel. Even though I'm a bit uncomfortable with this solution, I do not see any other feasible way. Linus, Andrew, do you agree with this handling despite all the troubles involved with it? Dominik - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
Dominik Brodowski [EMAIL PROTECTED] wrote: Most pcmcia devices are matched to drivers using product ID strings embedded in the devices' Card Information Structures, as manufactor ID / card ID matches are much less reliable. Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), What is the difficulty in passing these strings via /sbin/hotplug arguments? ... To make the life easier for device driver authors, - a big warning is put into dmesg if a pcmcia driver is inserted into the kernel and the hash mentioned in PCMCIA_DEVICE_PROD_ID() is incorrect, As long as the kernel shouts loudly at the driver developer at development-time, and that shouting mentions a bit of documentation in Documentation/somewhere, I expect we'll be OK. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Tue, 8 Mar 2005, Dominik Brodowski wrote: Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), Hmm.. I'm with Andrew on this one - I'd much rather really pass them to user space as strings. We already pass a number of strings as environment variables. In fact, what's wrong with DEVPATH? Which we already expose as the NAME=xxx environment variable. So if the kboject associated with a device has has this string associated with its name (which it should), then hotplug will automatially pass that as the DEVPATH. So if you just fill out the kobject name with the product ID's (well, with the proper escaping of strange characters, of course), everything should just work. No? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
Dominik Brodowski [EMAIL PROTECTED] wrote: Most pcmcia devices are matched to drivers using product ID strings embedded in the devices' Card Information Structures, as manufactor ID / card ID matches are much less reliable. Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), What is the difficulty in passing these strings via /sbin/hotplug arguments? The difficulty is that extracting and evaluating them breaks the wonderful bus-independent MODNAME implementation for hotplug suggested by Roman Kagan ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these strings may contain spaces and other strange characters. The latter may be worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really clean because of this MODNAME implementation: #!/bin/sh cd /etc/hotplug . ./hotplug.functions if [ $ACTION = ]; then mesg Bad PCMCIA agent invocation, no action exit 1 fi case $ACTION in add) modprobe $MODNAME ... work around some exotic buggy PCMCIA hardware ... ... and I would very much like to avoid breaking the line modprobe $MODNAME. On Tue, Mar 08, 2005 at 02:54:57PM -0800, Linus Torvalds wrote: On Tue, 8 Mar 2005, Dominik Brodowski wrote: Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), Hmm.. I'm with Andrew on this one - I'd much rather really pass them to user space as strings. We already pass a number of strings as environment variables. In fact, what's wrong with DEVPATH? Which we already expose as the NAME=xxx environment variable. So if the kboject associated with a device has has this string associated with its name (which it should) drivers/base/core.c::device_add() kobject_set_name(dev-kobj, %s, dev-bus_id); and the bus_id isn't the device's name for common buses. Nontheless, the strings _are_ exported at DEVPATH/prod_id[1-4], but for the reasons mentioned above I'd prefer not to use them. On Tue, Mar 08, 2005 at 12:34:26PM -0800, Andrew Morton wrote: ... To make the life easier for device driver authors, - a big warning is put into dmesg if a pcmcia driver is inserted into the kernel and the hash mentioned in PCMCIA_DEVICE_PROD_ID() is incorrect, As long as the kernel shouts loudly at the driver developer at development-time, and that shouting mentions a bit of documentation in Documentation/somewhere, I expect we'll be OK. Andrew, please apply this patch on top of 2.6.11-mm2, if you and Linus still agree: Add some information useful for PCMCIA device driver authors to Documentation/pcmcia/, and reference it in dmesg in case of hash mismatches. Also add a reference to pcmciautils to Documentation/Changes. With recent changes, you don't need to concern yourself with pcmcia-cs even if you have PCMCIA hardware, so the example above the list needed to be adapted as well. Signed-off-by: Dominik Brodowski [EMAIL PROTECTED] Index: 2.6.11+/Documentation/Changes === --- 2.6.11+.orig/Documentation/Changes 2005-03-08 23:23:30.0 +0100 +++ 2.6.11+/Documentation/Changes 2005-03-08 23:23:33.0 +0100 @@ -44,9 +44,9 @@ Again, keep in mind that this list assumes you are already functionally running a Linux 2.4 kernel. Also, not all tools are -necessary on all systems; obviously, if you don't have any PCMCIA (PC -Card) hardware, for example, you probably needn't concern yourself -with pcmcia-cs. +necessary on all systems; obviously, if you don't have any ISDN +hardware, for example, you probably needn't concern yourself with +isdn4k-utils. o Gnu C 2.95.3 # gcc --version o Gnu make 3.79.1 # make --version @@ -57,6 +57,7 @@ o jfsutils 1.1.3 # fsck.jfs -V o reiserfsprogs 3.6.3 # reiserfsck -V 21|grep reiserfsprogs o xfsprogs 2.6.0 # xfs_db -V +o pcmciautils001 o pcmcia-cs 3.1.21 # cardmgr -V o quota-tools3.09# quota -V o PPP2.4.0 # pppd --version @@ -186,13 +187,20 @@ work correctly with this version of the XFS kernel code (2.6.0 or later is recommended, due to some significant improvements). +PCMCIAutils +--- + +PCMCIAutils replaces
Re: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 12:16:36AM +0100, Dominik Brodowski wrote:
Dominik Brodowski [EMAIL PROTECTED] wrote:
Most pcmcia devices are matched to drivers using product ID strings
embedded in the devices' Card Information Structures, as manufactor ID /
card ID matches are much less reliable. Unfortunately, these strings
cannot
be passed to userspace for easy userspace-based loading of appropriate
modules (MODNAME -- hotplug), so my suggestion is to also store crc32
hashes
of the strings in the MODULE_DEVICE_TABLEs, e.g.:
PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11),
What is the difficulty in passing these strings via /sbin/hotplug arguments?
The difficulty is that extracting and evaluating them breaks the wonderful
bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
strings may contain spaces and other strange characters. The latter may be
worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
clean because of this MODNAME implementation:
In addition: this isn't the problematic part. The product ID string and/or
the hash can easily be passed from kernelspace to userspace in calls to
hotplug, and that's not the real reason for the hashing. Instead, it is
caused by the module.alias generation (even module.pcmciamap, if it existed,
wouldn't be of help here) at compilation time: the format of such aliases is
alias [bus_name]:[{one or multiple chars as separators}{NUMBERS!} multiple such
blocks] [module_name]
This means: only (hex) numbers are allowed as _values_ in such a module alias
map. The module alias map is generated by file2alias.c, which cannot and
should not be able to access strings inside modules, because that would mean
awareness of all sorts of (arch-dependant) relocation. Therefore,
file2alias.c can't calculate the hashes for us, and as the C preprocessor
cannot either, only the explicit passing of strings _and_ hashes to struct
pcmcia_device_id-generating macros is the only feasible way I currently see
to use module.alias for PCMCIA devices.
Dominik
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 12:16:36AM +0100, Dominik Brodowski wrote: Dominik Brodowski [EMAIL PROTECTED] wrote: Most pcmcia devices are matched to drivers using product ID strings embedded in the devices' Card Information Structures, as manufactor ID / card ID matches are much less reliable. Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), What is the difficulty in passing these strings via /sbin/hotplug arguments? The difficulty is that extracting and evaluating them breaks the wonderful bus-independent MODNAME implementation for hotplug suggested by Roman Kagan ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these strings may contain spaces and other strange characters. The latter may be worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really clean because of this MODNAME implementation: I think that MODNAME should be replaced with MODALIAS, but that's a different email thread... Anyway, hashes are icky, I still don't see why using the string as module aliases, and fixing up modprobe to handle spaces in module aliases wouldn't work out easier. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Tue, Mar 08, 2005 at 03:37:07PM -0800, Greg KH wrote: module aliases, and fixing up modprobe to handle spaces in module aliases wouldn't work out easier. spaces _and_ characters. And characters are already used to separate different fields. pcmcia:pasome stringpbsome other string doesn't look bad though, indeed. Problem is: how to access the strings in file2alias.c? They're in different sections than the __mod_devicetables, and you'd need to get architecture-dependant relocation... so this doesn't seem feasible... or am I missing something? Dominik - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote: Dominik Brodowski [EMAIL PROTECTED] wrote: Most pcmcia devices are matched to drivers using product ID strings embedded in the devices' Card Information Structures, as manufactor ID / card ID matches are much less reliable. Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), What is the difficulty in passing these strings via /sbin/hotplug arguments? The difficulty is that extracting and evaluating them breaks the wonderful bus-independent MODNAME implementation for hotplug suggested by Roman Kagan ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these strings may contain spaces and other strange characters. The latter may be worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really clean because of this MODNAME implementation: Same goes with Open Firmware match strings that we are about to pass down to userspace as well. Hotplug will have to learn to deal with those. #!/bin/sh cd /etc/hotplug . ./hotplug.functions if [ $ACTION = ]; then mesg Bad PCMCIA agent invocation, no action exit 1 fi case $ACTION in add) modprobe $MODNAME ... work around some exotic buggy PCMCIA hardware ... ... and I would very much like to avoid breaking the line modprobe $MODNAME. On Tue, Mar 08, 2005 at 02:54:57PM -0800, Linus Torvalds wrote: On Tue, 8 Mar 2005, Dominik Brodowski wrote: Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), Hmm.. I'm with Andrew on this one - I'd much rather really pass them to user space as strings. We already pass a number of strings as environment variables. In fact, what's wrong with DEVPATH? Which we already expose as the NAME=xxx environment variable. So if the kboject associated with a device has has this string associated with its name (which it should) drivers/base/core.c::device_add() kobject_set_name(dev-kobj, %s, dev-bus_id); and the bus_id isn't the device's name for common buses. Nontheless, the strings _are_ exported at DEVPATH/prod_id[1-4], but for the reasons mentioned above I'd prefer not to use them. On Tue, Mar 08, 2005 at 12:34:26PM -0800, Andrew Morton wrote: ... To make the life easier for device driver authors, - a big warning is put into dmesg if a pcmcia driver is inserted into the kernel and the hash mentioned in PCMCIA_DEVICE_PROD_ID() is incorrect, As long as the kernel shouts loudly at the driver developer at development-time, and that shouting mentions a bit of documentation in Documentation/somewhere, I expect we'll be OK. Andrew, please apply this patch on top of 2.6.11-mm2, if you and Linus still agree: Add some information useful for PCMCIA device driver authors to Documentation/pcmcia/, and reference it in dmesg in case of hash mismatches. Also add a reference to pcmciautils to Documentation/Changes. With recent changes, you don't need to concern yourself with pcmcia-cs even if you have PCMCIA hardware, so the example above the list needed to be adapted as well. Signed-off-by: Dominik Brodowski [EMAIL PROTECTED] Index: 2.6.11+/Documentation/Changes === --- 2.6.11+.orig/Documentation/Changes2005-03-08 23:23:30.0 +0100 +++ 2.6.11+/Documentation/Changes 2005-03-08 23:23:33.0 +0100 @@ -44,9 +44,9 @@ Again, keep in mind that this list assumes you are already functionally running a Linux 2.4 kernel. Also, not all tools are -necessary on all systems; obviously, if you don't have any PCMCIA (PC -Card) hardware, for example, you probably needn't concern yourself -with pcmcia-cs. +necessary on all systems; obviously, if you don't have any ISDN +hardware, for example, you probably needn't concern yourself with +isdn4k-utils. o Gnu C 2.95.3 # gcc --version o Gnu make 3.79.1 # make --version @@ -57,6 +57,7 @@ o jfsutils 1.1.3 # fsck.jfs -V o reiserfsprogs 3.6.3 # reiserfsck -V 21|grep reiserfsprogs o xfsprogs 2.6.0 # xfs_db -V +o pcmciautils001 o pcmcia-cs 3.1.21 # cardmgr -V o quota-tools
Re: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 04:45:09PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote: Dominik Brodowski [EMAIL PROTECTED] wrote: Most pcmcia devices are matched to drivers using product ID strings embedded in the devices' Card Information Structures, as manufactor ID / card ID matches are much less reliable. Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), What is the difficulty in passing these strings via /sbin/hotplug arguments? The difficulty is that extracting and evaluating them breaks the wonderful bus-independent MODNAME implementation for hotplug suggested by Roman Kagan ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these strings may contain spaces and other strange characters. The latter may be worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really clean because of this MODNAME implementation: Same goes with Open Firmware match strings that we are about to pass down to userspace as well. Hotplug will have to learn to deal with those. Ok, any suggestions that don't involve hashes? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 04:45:09PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote: Dominik Brodowski [EMAIL PROTECTED] wrote: Most pcmcia devices are matched to drivers using product ID strings embedded in the devices' Card Information Structures, as manufactor ID / card ID matches are much less reliable. Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), What is the difficulty in passing these strings via /sbin/hotplug arguments? The difficulty is that extracting and evaluating them breaks the wonderful bus-independent MODNAME implementation for hotplug suggested by Roman Kagan ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these strings may contain spaces and other strange characters. The latter may be worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really clean because of this MODNAME implementation: Same goes with Open Firmware match strings that we are about to pass down to userspace as well. Hotplug will have to learn to deal with those. Hotplug isn't the tricky part. file2alias is. Any idea on how to do that? Dominik - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
The difficulty is that extracting and evaluating them breaks the wonderful bus-independent MODNAME implementation for hotplug suggested by Roman Kagan ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these strings may contain spaces and other strange characters. The latter may be worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really clean because of this MODNAME implementation: Same goes with Open Firmware match strings that we are about to pass down to userspace as well. Hotplug will have to learn to deal with those. Ok, any suggestions that don't involve hashes? Not sure, I haven't looked at the details issues involves (I just spotted the issue about space while quick-reading lkml). I suppose quotes around the strings are good enough, at least for OF, I yet have to see a compatible, name or type property with quotes in it... Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 08:19:42AM +0100, Dominik Brodowski wrote: On Wed, Mar 09, 2005 at 04:45:09PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote: Dominik Brodowski [EMAIL PROTECTED] wrote: Most pcmcia devices are matched to drivers using product ID strings embedded in the devices' Card Information Structures, as manufactor ID / card ID matches are much less reliable. Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), What is the difficulty in passing these strings via /sbin/hotplug arguments? The difficulty is that extracting and evaluating them breaks the wonderful bus-independent MODNAME implementation for hotplug suggested by Roman Kagan ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these strings may contain spaces and other strange characters. The latter may be worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really clean because of this MODNAME implementation: Same goes with Open Firmware match strings that we are about to pass down to userspace as well. Hotplug will have to learn to deal with those. Hotplug isn't the tricky part. file2alias is. Any idea on how to do that? I do not, sorry. Rusty's the person to bug about that. good luck, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
