CD writing - related question

CD writing - related question

[Bill Davidsen]

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: CD writing - related question

[Pavel Machek]

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!

Re: CD writing - related question

[Jan Engelhardt]

>> 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
-- 

Re: CD writing - related question

[Bill Davidsen]

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: CD writing - related question

[Pavel Machek]

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!

Re: CD writing - related question

[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

Re: CD writing - related question

[Jens Axboe]

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

Re: CD writing - related question

[Krzysztof Halasa]

Bill Davidsen <davidsen@tmr.com> 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

Re: CD writing - related question

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
Doing interesting things with little computers since 1979

Re: CD writing - related question

[Matt Keenan]

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

Re: CD writing - related question

[Xavier Bestel]

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

Re: CD writing - related question

[Jens Axboe]

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

Re: CD writing - related question

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
Doing interesting things with little computers since 1979