Andrey Borzenkov wrote:
[]
>> The modalias format is like this:
>>
>> scsi:type-0x04
That's actually scsi:t-0x04 in the patch. But it makes no real
difference and is trivial to adjust.
>> (for TYPE_WORM, handled by sr.c now).
>>
>> Several comments.
>>
>> o This hexadecimal type value is because all TYPE_XXX constants
>> in include/scsi/scsi.h are given in hex, but __stringify() will
>> not convert them to decimal (so it will NOT be scsi:type-4).
>> Since it does not really matter in which format it is, while
>> both modalias in module and modalias attribute match each other,
>> I descided to go for that 0x%02x format (and added a comment in
>> include/scsi/scsi.h to keep them that way), instead of changing
>> them all to decimal.
>
> well, I started with the same but then changed my mind.
>
> - is it possible that in future some more information may be added? Like
> vendor ID, product ID or whatever? At least in one case SCSI type is not
> enough to distinguish between drivers (st vs. osst Onstream tapes).
Yeah, as mentioned in my second comment - it's the same as 8139cp vs
8139too drivers.
But sure it's possible to change the things in the future, since it's
all internal to kernel - the only requirement is that modalias device
attribute should match module alias attributes.
> - it makes sense to redo bus matching then; which requires some sort of
> explicit ID table anyway.
Oh well. I don't think it's worth the effort really. Only 4 drivers so
far (sd, sr, st and osst). The only reason to try harder is to avoid
loading of osst for non-osst tapes. But I don't think it's a big deal
to load osst module -- it's harmless, and after all, it's always possible
to "blacklist" it on a particular machine, just like some people do with
8139cp module.
> Unfortunately I do not have the patch ready as yet; may be end of week.
>
>> o There was no .uevent routine for SCSI bus. It might be a good
>> idea to add some more ueven environment variables in there.
>>
>> o osst.c driver handles tapes too, like st.c, but only SOME tapes.
>> With this setup, hotplug scripts (or whatever is used by the
>> user) will try to load both st and osst modules for all SCSI
>> tapes found, because both modules have scsi:type-0x01 alias).
>> It is not harmful, but one extra module is no good either.
>> It is possible to solve this, by exporting more info in
>> modalias attribute, including vendor and device identification
>> strings, so that modalias becomes something like
>> scsi:type-0x12:vendor-Adaptec LTD:device-OnStream Tape Drive
>> and having that, match for all 3 attributes, not only device
>> type. But oh well, vendor and device strings may be large,
>> and they do contain spaces and whatnot.
>> So I left them for now, awaiting for comments first.
>
> We can go the PCMCIA way that stores string hashes; like in
>
> Identification: manf_id: 0x0156 card_id: 0x0002
> function: 6 (network)
> prod_id(1): "TOSHIBA" (0xb4585a1a)
> prod_id(2): "Wireless LAN Card" (0x0b537c13)
> prod_id(3): "Version 01.01" (0xd27deb1a)
> prod_id(4): --- (---)
BTW, a question for osst folks (Willem Riede?) -- why osst checks for
both vendor and device strings, isn't it sufficient to just check vendor
for "OnStream" ? Just curious maybe...
> strictly speaking, modalias real value is not relevant, we are going to
> do "modprobe $modalias" anyway without even looking at it.
Sure thing - that's why I said it makes no difference whenever to use
hex or dec values.
/mjt
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
