From: Matthew Dharm <[EMAIL PROTECTED]>
> 3. Presently usb-storage uses a single pointer us->extra
> with corresponding destructor us->extra_destructor.
> However, this does not really suffice. Multi-lun devices
> need one struct per lun, and such structs must be allocated
> and freed upon media change, independently of each other.
> Objections against introducing a second level, so that
> us->extra is a pointer to an array of length maxlun
> of pairs (pointer to info struct, pointer to destructor)?
> Can maxlun be very large so that the array length should
> be separate from maxlun?
us->extra is designed for devices which have their own drivers. The
'stock' protocol/transport conbinations don't use it. If you have a
driver which needs some extra data, you're expected to manage it
yourself. So this isn't an issue.
I'll come back to the other things later.
But concerning this us->extra, it is in fact an issue.
Life is easy when struct us_data *us is all one needs.
The additional information is found via us->extra.
But many devices are multi-lun, where each of the luns requires
an entirely different driver. I have here a 6-in-1 reader that
will read all of CompactFlash, SmartMedia, MemoryStick, SecureDigital..
Since the CompactFlash and SmartMedia drivers are completely
unrelated, and both are used at the same time, they cannot
both find their data at us->extra.
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.
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.
Andries
_______________________________________________________________
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
