Subject: Re: scsipi/physio trouble
To: Martin Husemann <email@example.com>
From: Reinoud Zandijk <firstname.lastname@example.org>
Date: 01/24/2005 15:04:02
Content-Type: text/plain; charset=us-ascii
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
-----END PGP SIGNATURE-----