On Thu, May 02, 2002 at 12:31:52AM +0200, [EMAIL PROTECTED] wrote: > Some questions about USB, especially usb-storage. > > 1. The structs allocated to describe media (e.g. the PBA-LBA > translation table for a SmartMedia card) must be freed upon > media change. At present this does not happen. > How does a media change become visible?
It doesn't. This is broken.
> 2. The structs allocated to describe media must be freed upon
> device removal. At present this does not happen.
> How does a device removal become visible?
Doesn't. We assume that the device could come back, and at that time we
re-connect the device with it's struct. That means that if you have a USB
disk connected to /dev/sda, it will still be /dev/sda after
disconnect/reconnect.
> 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.
> 4. The various units of a USB device are distinguished by LUN.
> Is the numbering constant (independent of kernel or history,
> dependent only on the device)?
Yes. The device defines how LUNs are assigned.
> And a much more specific question:
> dpcm.c has code
>
> /*
> * Set the LUN to 0 (just in case).
> */
> srb->lun = 0; us->srb->lun = 0;
> ret = sddr09_transport(srb, us);
> srb->lun = 1; us->srb->lun = 1;
>
> Why?
The sddr09 driver often gets invoked as a 'fake' second LUN (LUN 1) on
dual-use devices (i.e. CF and SM readers). As such, it's a trick... the
sddr09 transport code needs to address SM reader #0, not #1, but the kernel
sees the CF reader as #0 and SM reader as #1.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
It was a new hope.
-- Dust Puppy
User Friendly, 12/25/1998
msg06193/pgp00000.pgp
Description: PGP signature
