Re: CD writing in future Linux (stirring up a hornets' nest)

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Jürg Billeter <j@bitron.ch> wrote:
>
> > Hi Jörg
> >
> > On Mon, 2006-01-30 at 12:43 +0100, Joerg Schilling wrote:
> > > > Hm, this ATAPI stuff makes me a headache. Well, anyway, out of
> > > > curiosity, what is an ATAPI drive (IDE-ATAPI) supposed to return when asked
> > > > for bus number, id or lun - independent of OS and/or cdrecord?
> > >
> > > The drive does not return this information, but the SCSI subsystem creates
> > > these instance numbers. A SCSI drive (like a CD/DVD burner) is supposed to
> > > be known to the SCSI sub-system and thus needs to have a SCSI subsystem
> > > related instance number.
> >
> > Whenever someone talks about ATAPI drives, you respond with
> > s/ATAPI/SCSI/. Why do you insist that every transport should be used as
> > it was a SCSI bus? ATAPI drives use the same SCSI command set as SCSI
> > drives do, but that won't change the fact that ATAPI drives are not
> > connected to a SCSI bus.
>
> Well, this is simple: it is SCSI.
>
> When SCSI started from modifying the SASI (Shugart Asociated System Interface)
> system around 1984 and at that time come with it's own transport only
> (a 50 wire cable), this did change soon (around 1986) by introducing
> transports that use one or two 68 wire cable(s) (16 resp. 32 Bit SCSI).
>
> Around 1990, even this did change while ATAPI (ATA Packet Interface) was
> introduced.
>
> Around 1995, the T10 standard group (SCSI) did split up the SCSI standard
> into a transport specific part and a protocol specific part. SCSI is now using
> many different transport mechanisms.
>
> This is a list of some known SCSI transports:
>
>         -       Good old Parallel SCSI 50/68 pin (what most people call SCSI)
>         -       SCSI over fiber optics (e.g. FACL - there are others too)
>         -       SCSI over a copper variant of FCAL (used in modern servers)
>         -       SCSI over IEEE 1394 (Fire Wire)
>         -       SCSI over USB
>         -       SCSI over IDE/ATA (ATAPI)
>         -       SCSI over TCI/IP (iSCSI)
>         -       SCSI over SSCSI (see below)
>
> SCSI over Serial SCSI cabling uses the same transport (cable type) as SATA uses.
> If you buy a SATA HBA card for your PC, you may connect SSCSI & SATA
> disks to this HBA using the same cables and connectors.
>
> So the circle is closing again....
>
>
> > It makes sense to address parallel SCSI devices via target id. If an
> > operating system likes to simulate virtual SCSI buses for other bus
> > types as well, ok, I have no objections. But if the operating system
> > doesn't like to simulate virtual SCSI buses and allows applications to
> > address devices by a filename, you should have no objections, too.
>
> It seems that you missunderstand this. No operating system uses file names
> internally. OS instead typically handle SCSI devices that are not connected
> via an arbitraring Bus like the "Good old Parallel SCSI 50/68 pin" system
> by asuming they are all on separate SCSI busses that only have one single drive
> conected each.
>
> What Linux does is to artificially prevent this view to been seen from outside the
> Linux kernel, or to avoid integrating a particular device into a unique SCSI
> driver system although it would be apropriate.
>
> Users like to be able to get a list of posible targets for a single protocol.
> Nobody would ever think about trying to prevent people from getting a unified
> view on the list possible hosts that talk TCP/IP. What cdrecord does with
> -scanbus is nothing really different.

Yes and it is Linux limitation (lets face it).   There are 2 problems:

* no generic block layer transport infrastructure so that you cannot
  specify in the low-level driver which transport types your device does
  support (this information would be exported to the applications).

  Jens, maybe sysfs attribute "transports" will be sufficient so that
  application  can use libsysfs to get full list of devices supporting "SCSI"
  transport (/dev/hd* is fine with this scheme).  Does it make sense?
  Having block layer sysfs attributes for device type (disk, tape, cd etc)
  would have additional bonus of not needing to inquire wrong device
  types.  This would probably simplify other applications (HAL?).
  [ These are just quick ideas... ]

  Joerg, I don't see any sense in providing users with fake SCSI
  lun and bus numbers for ATAPI devices.  I think that what users
  would like is the list of devices consisting of "fd" and actual vendor
  name of device (+ optionally serial no + optionally "x:y:z" for real
  SCSI).  Nobody wants to see some artificial "x:y:z" for her/his
  ATAPI device (it has always annoyed me in Windows), not to say
  that the majority of desktop users have absolutely no idea of meaning
  of these numbers.

* ide-* drivers for ATAPI devices are needed (some devices just doesn't
  work with ide-scsi ATM) so please accept this fact that we cannot just
  now simply switch over everything to using ide-scsi and we have to use
  SG_IO ioctl for ide-cd (and ide-{floppy,tape} if anybody cares to add
  support for it).  I'm not saying this won't change in future but this requires
  doing actual work and people seem to be more interested in discussing
  stupid naming issues than doing it so...

> In addition, nobody would ever think about implementing a separate TCP/IP stack
> for network interfaces that are PPP connections via a modem vs. network
> interfaces that go via a Ethernet adaptor. Nobody would ever try to convince
> me that you could save code in the kernel by avoiding the usual network stack
> as a specific machine may not have Ethernet but a Modem connection only.
>
> So why do people try to convince me that there is a need to avoid the standard
> SCSI protocol stack because a PC might have only ATAPI?

SCSI protocol stack is far too Parallel SCSI centric (vide SAS flamewar).
Once again this is Linux problem which will get fixed with time or will fix
itself if we switch to libata for PATA.

> Major OS implementations use a unique view on SCSI (MS-win [*], FreeBSD, Solaris,
> ...). Why do people believe that Linux needs to be different? What does it buy
> you to go this way?

Linux needs to be better, no? ;-)

> *] MS-WIN-NT even includes SCSI emulation (it allows you to connect to the
> SCSI subsystem, set the Address and use SCSI commands from a limited list
> to read/write sector from ATA only hard disks).
>
> If the Linux folks could give technical based explanations for the questions
> from above and if they would create a new completely orthogonal view on SCSI [*]
> I had no problem. But up to now, the only answer was: "We do it this
> way because we do it this way".

The answer is - we do this this way because of historical reasons and we
simply lack resources to change it immediately (be it your "everything is
SCSI" or mine "block layer devices claiming supported transport types").

Please also note things don't change because you say so - they require
somebody doing actual work and work/time is not free (despite what some
people think).  If you think that badmouthing Linux will motivate people to
work, you are wrong (it has the opposite effect of time wasting flamewars).

I would like you to ask to remove warnings from about /dev/hd* interface
from cdrecored - they are just confusing users.  This is the current way
of doing things in Linux and applications have to deal with it for now.

Thanks,
Bartlomiej

> *] Note that this would need to implement SCSI Generic support for drives that
> have no native driver in the system.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/