I'm not sure I understand your device. All multi-function devices I've seen work in one of two ways: (1) They present a single USB interface, with multiple LUNs (2) They present multiple USB interfaces.
Are you saying you've now got a 3rd type of device, which presents all 6
media types on one USB interface and does _not_ use LUNs for each?
Remember, not all SmartMedia devices requre the us->extra parameter. Many
take care of all of that in the hardware, which is common for 3-in-1,
4-in-1 and larger devices.
To do what you're talking about would require a multifunction device that
did not use any of the standard storage class mechanisms for _any_ of it's
types... is that what you've got?
Matt
On Thu, May 02, 2002 at 10:54:44PM +0200, [EMAIL PROTECTED] wrote:
> 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
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
You were using cheat codes too. You guys suck.
-- Greg to General Studebaker
User Friendly, 12/16/1997
msg06212/pgp00000.pgp
Description: PGP signature
