Subject: Re: scsipi/physio trouble
To: Martin Husemann <>
From: Reinoud Zandijk <>
List: tech-kern
Date: 01/24/2005 15:04:02
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hiya Martin,

On Mon, Jan 24, 2005 at 10:21:38AM +0100, Martin Husemann wrote:
> On Mon, Jan 24, 2005 at 03:37:51AM +0100, Reinoud Zandijk wrote:
> > What do you guys think? should either scsipi be fixed to not use physio? or 
> > should physio be fixed to allow transfers to kernel memeory too?
> I don't have any opinion on this, but..
> > Feedback would be much apreciated for this means that a lot of IOCTL's like 
> > SCIOCCOMMAND (scsi command) can't be be executed from kernel-space.
> without knowing the details, this sounds like some abstraction is not right.
> Why would anything outside of sys/dev/scsipi need to do SCSI commands?
> Everything in there, of course, just calls scsipi_command().

i've looked into the scsipi's code for references to scsipi_command() but 
am not sure yet as to claim its ok to call those scsi calls involved with 
that function to transfer stuff to kernel-space.

The code in question in fs/udf/ (not committable yet) deals with 
abstraction indeed. It deals with the abstraction of whether udf is 
accessing a cd/dvd or is accessing a vnd/file/generic block device.

In order to get information about tracks, sessions, disc state, device 
class (CD, DVD, BluRay-'dvd') and capabilities (read-only, sequential, 
restricted overwrite, blocksize, rewriteable, ....) i need to execute 
generic SCSI commands since thats the only way to inquiry scsi/atapi/usb 
devices in a generic way.

A different solution offcource could be to implement the various scsi 
function calls needed, a hand full, as seperate VOP_IOCTL() calls on the cd 
device in scsipi's tree. This would mean both exposing them to userland as 
ioctl's but also in an increase of ioctl's on the cd-device.

Would that be preferable then?


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.6 (NetBSD)