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

[Dominik Brodowski]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/