lkml.org 
[lkml]   [2006]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: CD writing in future Linux (stirring up a hornets' nest)
Martin Mares <mj@ucw.cz> wrote:

> > 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.
>
> How exactly does Linux prevent this???

By not treating ATAPI the same as all other SCSI devices.


> > 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.
>
> How do you perform -scanbus for TCP/IP? :-)

There are various programs that do that for you.
You could e.g. send a ping to the broadcast address in order to find hosts
that are on the local network.


> > 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.
>
> There is an interesting similarity: in the TCP/IP stack, you also shouldn't
> assume anything about names of network interfaces, they are just opaque
> identifiers (in many times assigned by the administrator, not by the kernel).
> The right way of addressing is by IP addresses or DNS names, which is
> pretty similar to the addressing of SCSI devices on Linux, isn't it?

If you understand this, why then insists other people in using names like
/dev/hd*?



> Scanning for all available CD burners is of course a nice feature, but
> I don't think it should be implemented by asking all existing SCSI-like
> devices if they are a CD burner (for example because there can be an
> almost infinite number of them, given that you can do SCSI-over-IP
> and other similar tricks). The problem of presenting devices to the

And while this kind of scanning works in case that you have all devices
integrated inside a single SCSI implementation, it does not work for ATAPI
because someont artificially decided to exclude one single SCSI transport
from the global view.

And regarding iSCSI, If you like to talk to such a device, you need to
authentificate first. This is typically done by the kernel that in turn
trnaferres the remote iSCSI device into a virtual local SCSI device.



Jörg

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-31 14:33    [W:0.302 / U:0.264 seconds]
©2003-2014 Jasper Spaans. Advertise on this site