>Of course I can have a special driver that knows that the SmartMedia
>extra data is at some given offset in us->extra, but otherwise
>this driver is completely identical to the driver of some other
>reader that only reads one type of card.
i.e. you want to use datafab.c for lun #0, but you own driver for lun #1..3 ?
>So, it is bad design to build this knowledge into the driver.
>It leads to code duplication.
>
>A different solution is to pass everywhere the pair (us,info) around,
>instead of just us. That is a pity. A single handle to all one needs
>is much better.
>
>Such considerations bring me to the desire to have something like
> info = ((struct per_lun_data *) us->extra)[lun].data;
> kill = ((struct per_lun_data *) us->extra)[lun].destructor;
>for all drivers in usb-storage.
Yes and no. There are other drives that have totally different commands for
each 'lun', but still share status & media change bits.
In this case you'd have problems distributing the media change information
over the different luns.
As your case is a fairly uncommon one, i'd suggest:
struct big_6in1_reader_extra_data {
struct something_for_cf cf_data;
struct something_for_sm sm_data;
...
}
and then, do all the lun <--> xxx_data handling in your transport routine
(ie. then swap the us->extra is you really want to use other code this way).
- sda
p.s. got a cat /proc/bus/usb/devices of the reader for us ?
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
