PCMCIA product id strings -> hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]

[Dominik Brodowski]

On Wed, Mar 09, 2005 at 12:16:36AM +0100, Dominik Brodowski wrote:
> > Dominik Brodowski <linux at dominikbrodowski.net> 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