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

[Joerg Schilling]

Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx> wrote:

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

This is called integration and it is done by Linux e.g. for 1394 and USB SCSI 
devices. So why not for ATAPI?


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

Well, the problem with ide-scsi is not a general one but caused by a simple
bug that needs to be fixed.


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

If this is true for Linux, it should be fixed. But this is not a general 
problem.

> > 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? ;-)

In case that Linux would offer better methods, I would not complain.


> > 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").

This is obviously not true: There _was_ (and still is) a useful implementation 
with minor bugs. But instead of fixing the minor bugs, a lot of work has been 
done to introduce a new and unneded new interface.

Jörg

-- 
 EMail:joerg@xxxxxxxxxxxxxxxxxxxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
       js@xxxxxxxxxxxxxxx                (uni)  
       schilling@xxxxxxxxxxxxxxxxxxx     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/