Please take this as a question to elicit information, not an invitation
for argument.
In Linux currently:
SCSI - liiks like SCSI
USB - looks like SCSI
Firewaire - looks like SCSI
SATA - looks like SCSI
Compact flash and similar - looks like SCSI
ATAPI - looks different unless ide-scsi used
Was there a reason, a technical reason, why the minor blotches in
ide-scsi weren't fixed so that everything could look the same and share
the same device naming form? The DMA issue is solved for blocks, and
several people have stated to the list that the remaining issues could
be solved in minimal time. Seeing no disagreement, I'll assume that's true.
There are separate IDE drivers for disk, tape, floppy, and CD, and the
only reason I ever heard was that ide-scsi adds overhead. I did some
tests using a mighty Pentium-II 350, and there was no overhead with disk
or CD (within the limits of measurement). So there's no huge CPU
penalty, why then the decision to have the separate ide drivers?
The last time I tried, there was one thing which didn't work quite right
doing ZIP drives unless ide-scsi was used, and MO drives don't seem to
work any other way, but I haven't tried since about 2.6.6 or so, that
info could be dated.
This is NOT an argument for change, it may be a reminder that ide-scsi
is not unused, I just never saw any technical reason mentioned.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Mon 30-01-06 18:30:29, Bill Davidsen wrote:
> Please take this as a question to elicit information, not
> an invitation for argument.
>
> In Linux currently:
> SCSI - liiks like SCSI
> USB - looks like SCSI
> Firewaire - looks like SCSI
> SATA - looks like SCSI
> Compact flash and similar - looks like SCSI
Your definition of "looks like scsi" is way too broad. CF looks like
PCMCIA and that in turn is ide chip on isa-like bus.
(unless you plug it to usb reader)
--
Thanks, Sharp!
>> Please take this as a question to elicit information, not
>> an invitation for argument.
>>
>> In Linux currently:
>> SCSI - liiks like SCSI
SCSI disks - pop up using the 'sd' driver
SCSI cdroms - sr
>> USB - looks like SCSI
USB mass storage - pops up using the 'sd' driver
(USB cdrom - dunno, don't have any, presumably sr)
>> Firewaire - looks like SCSI
Firewire disks - pop up using the 'sd' driver
(Firewire cdrom - dunno either, presumably sr)
>> SATA - looks like SCSI
SATA disks - pop up using the 'sd' driver
(SATA cdrom - dunno either, presumably sr)
>> ATAPI - looks different unless ide-scsi used
(ATAPI disk - we don't have any, really :) )
ATAPI cdrom - pop up using
- standard: 'ide-cd'
- ide-scsi: 'sr'
I think that's where people stumble.
Jan Engelhardt
--
Pavel Machek wrote:
> On Mon 30-01-06 18:30:29, Bill Davidsen wrote:
>
>>Please take this as a question to elicit information, not
>>an invitation for argument.
>>
>>In Linux currently:
>> SCSI - liiks like SCSI
>> USB - looks like SCSI
>> Firewaire - looks like SCSI
>> SATA - looks like SCSI
>> Compact flash and similar - looks like SCSI
>
>
> Your definition of "looks like scsi" is way too broad. CF looks like
> PCMCIA and that in turn is ide chip on isa-like bus.
>
> (unless you plug it to usb reader)
>
I was unaware of any serious use of PCMCIA reader cards therese days, as
you note the CD shows up as an sd device. I have a laptop which might
have a card slot, if it takes CD I'll pull one from my camera and try it
there instead of the USB reader.
The question is still why not make all devices look like SCSI, and use
one set of drivers and a bit of glue. Redhat used to use ide-scsi by
default if my memory serves, and the overhead wasn't an issue even back
on my 1st Linux laptop running Slackware on a Thinkpad 486-25 (the fat
one, not the 486-16 -;).
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Čt 02-02-06 14:40:28, Bill Davidsen wrote:
> Pavel Machek wrote:
> >On Mon 30-01-06 18:30:29, Bill Davidsen wrote:
> >
> >>Please take this as a question to elicit information, not
> >>an invitation for argument.
> >>
> >>In Linux currently:
> >>SCSI - liiks like SCSI
> >>USB - looks like SCSI
> >>Firewaire - looks like SCSI
> >>SATA - looks like SCSI
> >>Compact flash and similar - looks like SCSI
> >
> >
> >Your definition of "looks like scsi" is way too broad. CF looks like
> >PCMCIA and that in turn is ide chip on isa-like bus.
> >
> >(unless you plug it to usb reader)
> >
> I was unaware of any serious use of PCMCIA reader cards therese days, as
> you note the CD shows up as an sd device. I have a laptop which might
> have a card slot, if it takes CD I'll pull one from my camera and try it
> there instead of the USB reader.
CD? Did you want to say CF?
Anyway it is not really PCMCIA reader. It is just PCMCIA-to-CF
adapter, plugged into PCMCIA slot. Adapter is pretty much passive.
> The question is still why not make all devices look like SCSI, and use
> one set of drivers and a bit of glue. Redhat used to use ide-scsi by
> default if my memory serves, and the overhead wasn't an issue even back
> on my 1st Linux laptop running Slackware on a Thinkpad 486-25 (the fat
> one, not the 486-16 -;).
CF card is as much ide as it can get. You can even pug it to IDE cable
with passive adapter!
Forcing everything to SCSI makes about as much sense as making
everything look like IDE.
Pavel
--
Thanks, Sharp!
On Thu, Feb 02 2006, Bill Davidsen wrote:
> The question is still why not make all devices look like SCSI, and use
Because it's a really bad idea? Right now we have a few storage drivers
that don't use SCSI, that number will increase in the future.
The fact that lots of drivers use the SCSI stack even if they didn't
have to is mainly because the SCSI layer had all those handy features
that they all needed. During 2.5 and 2.6 we moved a lot of that
functionality transparently to the block layer instead. As we complete
that work, it would be just as easy to write a native block driver
instead of a SCSI LLD. libata is one such example.
--
Jens Axboe
On Mon, Jan 30 2006, Bill Davidsen wrote:
> Please take this as a question to elicit information, not an invitation
> for argument.
>
> In Linux currently:
> SCSI - liiks like SCSI
> USB - looks like SCSI
> Firewaire - looks like SCSI
> SATA - looks like SCSI
SATA will _not_ look like SCSI in the future.
> Compact flash and similar - looks like SCSI
? CF adapters are usually IDE, so looks like ATA.
> ATAPI - looks different unless ide-scsi used
But it's all besides the point, it doesn't matter what the device
special file looks like (if it's SCSI or not). What matters is that you
talk to the device the same way - and that way is currently SG_IO.
That a device hangs off the SCSI stack because that is the way the
author wrote eg usb-storage is irrelevant. What matters is that you open
the device in question and use SG_IO to talk to it.
Talking about the SCSI stack and ide-scsi completely misses the point.
--
Jens Axboe
Bill Davidsen <[email protected]> writes:
> The question is still why not make all devices look like SCSI, and use
> one set of drivers and a bit of glue.
That could probably make sense, and libata currently does that (which,
I hope, will obsolete drivers/ide WRT PATA as well), but SCSI commands
are a different thing than a bus/ID/lun address from outer space.
--
Krzysztof Halasa
On Thu, 2 Feb 2006, Pavel Machek wrote:
>
> X-UID: 40919
>
> On Čt 02-02-06 14:40:28, Bill Davidsen wrote:
> > Pavel Machek wrote:
> > >On Mon 30-01-06 18:30:29, Bill Davidsen wrote:
> > >
> > >>Please take this as a question to elicit information, not
> > >>an invitation for argument.
> > >>
> > >>In Linux currently:
> > >>SCSI - liiks like SCSI
> > >>USB - looks like SCSI
> > >>Firewaire - looks like SCSI
> > >>SATA - looks like SCSI
> > >>Compact flash and similar - looks like SCSI
> > >
> > >
> > >Your definition of "looks like scsi" is way too broad. CF looks like
> > >PCMCIA and that in turn is ide chip on isa-like bus.
> > >
> > >(unless you plug it to usb reader)
> > >
> > I was unaware of any serious use of PCMCIA reader cards therese days, as
> > you note the CD shows up as an sd device. I have a laptop which might
> > have a card slot, if it takes CD I'll pull one from my camera and try it
> > there instead of the USB reader.
>
> CD? Did you want to say CF?
Yes, thanks.
>
> Anyway it is not really PCMCIA reader. It is just PCMCIA-to-CF
> adapter, plugged into PCMCIA slot. Adapter is pretty much passive.
>
> > The question is still why not make all devices look like SCSI, and use
> > one set of drivers and a bit of glue. Redhat used to use ide-scsi by
> > default if my memory serves, and the overhead wasn't an issue even back
> > on my 1st Linux laptop running Slackware on a Thinkpad 486-25 (the fat
> > one, not the 486-16 -;).
>
> CF card is as much ide as it can get. You can even pug it to IDE cable
> with passive adapter!
>
> Forcing everything to SCSI makes about as much sense as making
> everything look like IDE.
No, we have the way to make everything look like SCSI now, ide-scsi. We
can't make (real) SCSI look like IDE. And if you are using IDE instead of
ATAPI (non-SCSI command set?) you would ahve to stay with an older kernel.
> Pavel
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with little computers since 1979
Jens Axboe wrote:
>On Mon, Jan 30 2006, Bill Davidsen wrote:
>
>
>>Please take this as a question to elicit information, not an invitation
>>for argument.
>>
>>In Linux currently:
>> SCSI - liiks like SCSI
>> USB - looks like SCSI
>> Firewaire - looks like SCSI
>> SATA - looks like SCSI
>>
>>
>
>SATA will _not_ look like SCSI in the future.
>
>
>
>> Compact flash and similar - looks like SCSI
>>
>>
>
>? CF adapters are usually IDE, so looks like ATA.
>
>
>
>> ATAPI - looks different unless ide-scsi used
>>
>>
>
>But it's all besides the point, it doesn't matter what the device
>special file looks like (if it's SCSI or not). What matters is that you
>talk to the device the same way - and that way is currently SG_IO.
>
>That a device hangs off the SCSI stack because that is the way the
>author wrote eg usb-storage is irrelevant. What matters is that you open
>the device in question and use SG_IO to talk to it.
>
>Talking about the SCSI stack and ide-scsi completely misses the point.
>
>
>
Jens,
Is there a document that clearly lists how these components (SCSI,
SG_IO, ATA/PI etc et al) connect together and what protocol / transports
they use? I suspect the problem with all these current arguments is that
very few people understand how this all works / connects. I think alot
of people equate kconfig options with how the stuff works under the hood
(even though a number of these config options are badly named to say the
least).
Matt
On Tue, 2006-02-07 at 10:22, Matt Keenan wrote:
> Is there a document that clearly lists how these components (SCSI,
> SG_IO, ATA/PI etc et al) connect together and what protocol / transports
> they use? I suspect the problem with all these current arguments is that
> very few people understand how this all works / connects.
Maybe people that don't understand how all these components are tied
together should refrain from arguing about them ?
Xav
On Tue, Feb 07 2006, Matt Keenan wrote:
> Jens Axboe wrote:
>
> >On Mon, Jan 30 2006, Bill Davidsen wrote:
> >
> >
> >>Please take this as a question to elicit information, not an invitation
> >>for argument.
> >>
> >>In Linux currently:
> >>SCSI - liiks like SCSI
> >>USB - looks like SCSI
> >>Firewaire - looks like SCSI
> >>SATA - looks like SCSI
> >>
> >>
> >
> >SATA will _not_ look like SCSI in the future.
> >
> >
> >
> >>Compact flash and similar - looks like SCSI
> >>
> >>
> >
> >? CF adapters are usually IDE, so looks like ATA.
> >
> >
> >
> >>ATAPI - looks different unless ide-scsi used
> >>
> >>
> >
> >But it's all besides the point, it doesn't matter what the device
> >special file looks like (if it's SCSI or not). What matters is that you
> >talk to the device the same way - and that way is currently SG_IO.
> >
> >That a device hangs off the SCSI stack because that is the way the
> >author wrote eg usb-storage is irrelevant. What matters is that you open
> >the device in question and use SG_IO to talk to it.
> >
> >Talking about the SCSI stack and ide-scsi completely misses the point.
> >
> >
> >
> Jens,
>
> Is there a document that clearly lists how these components (SCSI,
> SG_IO, ATA/PI etc et al) connect together and what protocol / transports
> they use? I suspect the problem with all these current arguments is that
> very few people understand how this all works / connects. I think alot
> of people equate kconfig options with how the stuff works under the hood
> (even though a number of these config options are badly named to say the
> least).
The main transport mechanism in the block layer is the request queue.
This is where we place work-to-do for block devices, and where they
retrieve it. There is a defined API for the kernel to queue work on the
queue, and like wise for the block device driver to pull work off the
queue (and process it, etc). So that is really the transport we use in
the end to send commands to a drive. Some of these commands are "Linux"
commands, things like "read or write sectors foo at location bar" which
typically originate from the file system. But you can also transport
other command types on that queue, such as "SCSI" commands - note that
the SCSI here has _nothing_ to do with how you happen to have things
wired inside the computer. The actual device may be ATAPI, USB,
firewire, etc. They typically have the actual _command set_ in command -
eg if you want to read something from the drive, you would send for
instance a READ_10 with the command data block filled out according to
the command specification. Again, not related to the transport! They
just share the same command definitions. How you actually send out that
"SCSI" command is a low level driver detail that we know nothing about,
nor do we care.
Given the fact that they all basically share the same command set, Linux
defines a request type called REQ_BLOCK_PC. That enables us to send
these commands directly to a given block device, just using the request
queue we use for file system requests as well. This is what gives us the
power to use SG_IO on any device type, not just SCSI devices (here
meaning devices that may or may not be SCSI transport, but at least are
managed by the SCSI stack).
So, really, how devices are connected and what the transport looks like
has very little relevance and you don't need to know that fact. You just
need to know how to open a device, then you can talk to it.
--
Jens Axboe
On Tue, 7 Feb 2006, Xavier Bestel wrote:
> On Tue, 2006-02-07 at 10:22, Matt Keenan wrote:
> > Is there a document that clearly lists how these components (SCSI,
> > SG_IO, ATA/PI etc et al) connect together and what protocol / transports
> > they use? I suspect the problem with all these current arguments is that
> > very few people understand how this all works / connects.
>
> Maybe people that don't understand how all these components are tied
> together should refrain from arguing about them ?
Don't mislead yourself into thinking that "don't understand why anyone
would do it this way" implies "don't understand how it works."
This is mostly a discussion of keeping the kernel simple and letting the
applications cope with the constantly changing interfaces vs. keeping the
application interface constant (or at least not breaking things which did
work) and having the kernel more complex.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with little computers since 1979