Messages in this thread | | | Date | Tue, 31 Jan 2006 15:23:19 +0100 | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: CD writing in future Linux (stirring up a hornets' nest) |
| |
On 1/31/06, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote: > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> 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?
Because we have native drivers which do not require SCSI stack et all.
> > * 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.
Please _reread_ this paragraph: * some devices (not cd-writers) doesn't work with ide-scsi * they require quirks which are in ide-cd so it ide-cd needs to stay as a driver * if is very useful if cd-writing can be done with ide-cd and without SCSI stack (a hack but very useful one)
[ more below ]
> > > 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.
From technical point of view:
pros: * you don't need SCSI stack (a lot of code saved!) * you use subsystem native driver (a lot of complexity with locking etc avoided!) * you don't need to provide users with fake data (SCSI lun and bus)
cons: * user-space applications need to support it
What are the _technical_ problems with SG_IO interface besides issue with enumaration of devices available in the system?
I know that you don't like SG_IO but it is hardly technical argument.
Thanks, Bartlomiej - 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/
| |