Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

2.6.8 uses SCSI for CD recording?

Posted Aug 19, 2004 10:15 UTC (Thu) by sdalley (subscriber, #18550)
Parent article: 2.6.8 and CD recording

> Burning a CD requires sending a number of
> special-purpose SCSI commands to the drive,
> so the operation is performed outside of the regular I/O paths

I always scratch my head when I read things like this. Most CD/DVD writers are not SCSI devices these days. USB devices, too are not SCSI devices. Yet very often it turns out that in Linux anyway, these devices depend intimately on the kernel SCSI subsystem and end up with /dev/sd sorts of names. In 2.4 this was a convenient hack. Are there any pointers to how this is being tidied up in the brave new wold of 2.6? Or is the scsi subsystem still doubling up as a convenient generic block device service?

(Log in to post comments)

Posted Aug 19, 2004 11:02 UTC (Thu) by rjw (guest, #10415) [Link]

Most hardware storage devices (Firewire, USB, SATA, PATA) do in fact work in terms of scsi commands (or very minor variations) internally.

We have a SCSI layer. We use it for these SCSI based devices whether they use a SCSI cable standard or not.

As SCSI is so universal, it is becoming pointless to name device nodes like that. So eg IDE cdwriters can just be opened as /dev/hdc or whatever, and scsi commands issued. This is AFAIK possible in 2.6.

I'm sure patches that cleared up device naming in other encapuslated SCSI situations would be accepted ( eg SBP2, libata).

The problem here is that the SCSI standards (and all these encapsulated-SCSI standards) have not really fully encompassed the full range of what the devices are capable of. So its very hard to tell how much damage any particular command can do, as it might do different things
Basically, its a big old standards mess, and it is up to the vendors to sort out - if they can be bothered.

For existing drives, this becomes very similar to the X security question. Graphics cards often have total DMA freedom. So we have a few choices:
a) large parts of cdrecord in the kernel - eek.
b) trusted demon / suid binary - eek
c) command checking in the kernel for dodgy commands.

c) is what they are doing here. b) is what X does currently, but moving to c) (with quite some pain) . But if the commands are totally arbitrary, maybe userspace setup using a trusted udev/hotplug/hal callout (which informs the kernel of an allowed set of commands) would be the best way of dealing with it. Any extra userspace is always ultra painful to get in the distros though.

2.6.8 uses SCSI for CD recording?

Posted Aug 19, 2004 11:41 UTC (Thu) by sdalley (subscriber, #18550) [Link]

Ahh, that's a bit clearer. It's logical SCSI, not physical SCSI. Device commands are conveniently defined in terms of logical SCSI operations, even though they don't go near a physical SCSI device driver or device.

That being the case, maybe a new name for this logical layer could be invented.

2.6.8 uses SCSI for CD recording?

Posted Aug 19, 2004 15:48 UTC (Thu) by rjw (guest, #10415) [Link]

Well, it is actually SCSI commands that are being sent. Not some abstraction around a different command set.

That is because the *device manufacturers* are using SCSI commands.

So it would just be stupid to make up a new name, and pretend that the SCSI commands are something else.

SCSI means two things : a) A set of somewhat related controller / cable / plug standards b) a set of commands for storage ( and a few other ) devices.

b) can be used without a), but a) is very rarely used without b).

It has gone this long without a name split. I don't see why it should be changed now.