Lost in Flash Drive PCI USB SCSI hotplug, etc.

[Marcelo Giles]

A rather long thread by this time, Walt. The issues are many, and=20
complex as this world.

On Aug 7, 2004, at 8:50 PM, Walt Pawley wrote:

> On 8/7/04 4:00 PM -0300, Marcelo Giles wrote on Re: Lost in Flash=20
> Drive PCI
> USB SCSI hotplug, etc.
>
>> But Linux has its wealth of free and well-written documentation.
>> Check-out, for instance, the set of Red Hat manuals at
>> www.redhat.com/docs. ... Each of them from 100 to more than 300
>> pages long.
>
> Actually, bulk of documentation is a real problem. 1200 pages is TOO=20=

> much
> to deal with. It's not quantity that's the problem. It's having what's
> available be meaningful. IMHO, there are gobs and gobs of gobs and =
very
> little really good reading.

That's why I cared to mention bulky AND well-written documentation.
>
>> Regarding the HFS+ issue, I understand that support for this file
>> system comes in the latest 2.4 kernels and, of course, in 2.6.
>> Probably, you're using an earlier version.
>
> I believe YDL 3.0.1 comes with 2.4.22-f, as I recall. For me the point=20=

> is
> that the data that's installed with the OS says that HFS and HFS+=20
> should be
> mountable. Perhaps they are. Perhaps I'm just not reading the right=20
> bit of
> canabula to figure out how, despite seeing direct examples of what to=20=

> type.
>
Still have to find some docs to support this.

>> Finally, I'll look for some documentation that explains the issue of
>> usb-to-scsi mapping and (if I find something decent), I'll forward it
>> to you (in case you're still interested, of course).
>
> I'd post it here (assuming it's a URL, rather than the data itself, or=20=

> just
> not so much stuff that it would be no burden) so we could all see=20
> about it.
> Or, is this another one of those deals where it's "just me"?   ;-)
>
Here is what I could find. Actually, this info was scattered here and=20
there, but I think it more or less explains why Linux uses this=20
usb-to-scsi mapping thing.

<quote>

Good USB and IEEE1394 support may be rather recent developments in=20
Linux, but it=92s common to boot from USB devices, and both protocols=20
enable easy online insertion and removal of storage devices.

Both USB and 1394 storage devices masquerade as SCSI disks to allow=20
most existing applications to use them transparently. Each device is=20
mapped to a SCSI device file of the form /dev/sd which can be=20
interrogated with the scsi_info command.

Although Linux=92s SCSI subsystem was not really designed for hotplug=20
capabilities, with the right hardware and supporting driver, and care=20
in avoiding actions such as repeatedly inserting and removing drives=20
quickly, hotplugging can usually be made to work.

On the other hand, the USB and 1394 protocols and equipment were=20
designed with hotplugging in mind. USB and 1394 work around Linux=92s=20
device file mapping limitations by mapping their storage devices to a=20
pseudo SCSI device and recording unique identifying information under=20
/proc/scsi/usb-storage-N.

...

The Linux SCSI Generic (sg) driver interface.
The driver's purpose is to allow SCSI commands to be sent directly to=20
SCSI devices. The responses of those commands can then be obtained.=20
This type of driver is sometimes termed as a "pass through". In the=20
case of SCSI disks, the block subsystem which is normally used to mount=20=

and access a disk, is bypassed permitting low level operations such as=20=

formatting to be performed.

Many devices that use other physical buses (e.g. ATAPI cdroms, USB mass=20=

storage devices and IEEE 1394 sbp2 devices) utilize the SCSI command=20
set. By using Linux pseudo SCSI device drivers which bridge between the=20=

native protocol stack and the SCSI subsystem, the upper level SCSI=20
device drivers, including sg, can be used to control "non-SCSI"=20
devices.

</quote>

A site for more information on the subject could be www.linux-usb.org

--
Marcelo=