--mP3DRpeJDSE+ciuQ
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?

Cheers,
Reinoud


--mP3DRpeJDSE+ciuQ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQfUASoKcNwBDyKpoAQKw7AgAgW7c5Lud+y5pam20CBmUcyXf9aC9QEwJ
YJqjwjV0c1Lh9EUt5BtOM5XmXCqcaUZDlQY1PGxU4p8VGuQui0wzBAcKLobnYK62
85zlgghveeB6f2ZeQ4ruAbHaFM61OCri4z7+/YisnO8IzvJEq0peuP1xvUYs6yQN
qTCSqIg+wVQedX0m4UUvdagIwEYn020sU67LtTKFQ+n0tKmp09PTirchz7ZJosYN
LB/PRX6Jpmb/N0FNAuc2l/ll1KSYMn+SReW6qmkonOVWTD7/7CjPcXpFIPycQQ+l
pMua5NdHqtpMU1IgW1ePUE62rb4ysGUonZNOdxHeU1zNd72N3ihqOQ==
=d+xM
-----END PGP SIGNATURE-----

--mP3DRpeJDSE+ciuQ--