Re: Cdrtools-2.01a25 ready
> >Pass-through SG_IO (interface is question) is not specific to /dev/hd*.
> >In other words it's not an "/dev/hd* interface" or an IDE-specific hack,
>
> If you previously did write correct code for the Linux /dev/sg* interface, you
> should know better.
>
> The fact that the interfaces share a single common ioctl() does not make
> them equal.
Note that I'm not saying that /dev/hd* and /dev/sg* are equivalent. I'm
saying that 2.6 *pass-through SG_IO interface* is applicable not only to
/dev/hd*, but to *all* *block* storage devices, such as /dev/hd*,
/dev/sr*, /dev/sd*. It's unified across all block devices and is
perfectly usable interface. In a sense it renders /dev/sg* superfluous
[at least in CD recording context] and in my opinion it's actually a
step forward.
> >Note that SCSI
> >command-level programming through "tangible" block device not some
> >Linux-specific novelty, but widely accepted implementation strategy.
>
> Not correct: the most widely spread interface implementation strategy is
> to support generic SCSI transport. This is a level _below_ the block device
> layer.
Note that I made no claims about it being "most widely spread stategy."
I said "widely accepted [by OS designers]." E.g. quoting
IOCTL_SCSI_PASS_THROUGH page from Windows 2000 DDK:
"If a class driver for the target type of device exists, the request
must be sent to that class driver. Thus, an application can send this
request directly to the system port driver for a target logical unit
only if there is no class driver for the type of device connected to
that LU."
In other words native NT interface *requires* "tangible" block device.
BTW, is NT native interface "widely spread" enough? Another example.
Quoting Solaris sgen(7D) manual page:
"It is important for the administrator to ensure that dev-
ices claimed by the sgen driver do not conflict with exist-
ing target drivers on the system. For example, if the sgen
driver is configured to bind to a direct access device, the
standard sd.conf file will usually cause sd to claim the
device as well. This can cause unpredictable results. In
general, the uscsi(7I) interface exported by sd(7D) or
st(7D) should be used to gain access to direct access and
sequential devices."
Same story again. Native USCSI ioctls should be issued against
"tangible" block device entry...
> >It's rather contrary. It's not disregarding SCSI protocol layering, but
> >affirming it by putting applications to the level they naturally belongs
> >in. Layers lower than SCSI command block is pure kernel domain.
>
> Definitely wrong.
> ... the kind of code that support
> CD writing scanning and similar belongs into user space.
Let's stick to CD writing, because a) that's what we're discussing here
and b) recorder units *are* [and will be for foreseeable feature]
handled by block drivers.
> The highest possible protocol layer is the generic SCSI transport layer.
> ...
> As CD writing is a user space task, applications that
> support these tasks should use the highest possible protocol layer
^^^^^^^^^^^^^^^^ Says who? The
commonly acceptable and respected principle is "required minimum." SCSI
command block is more that sufficient to implement recording and
therefore there is no reason whatsoever to expose lower transport layers
to user-land. A.
Reply to: