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

From: Dominik Brodowski
Date: Tue Mar 08 2005 - 14:19:40 EST

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?

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/