[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interface for SCSI transactions ?

From: Thomas Schmitt
Subject: Re: Interface for SCSI transactions ?
Date: Sat, 10 Sep 2011 13:46:23 +0200


i believe to have found the connection between device_t in
userspace and Scsi_Device in kernel:

device_t arrives in device_set_status() of gnumach/linux/dev/glue/block.c
as (void *) and gets casted to (struct block_data *).
This struct has an element   
  kdev_t dev; /* Linux device number */

E.g. in gnumach/linux/src/drivers/scsi/sr.c i see
  void sr_photocd(struct inode *inode)
  { [...]
    kernel_scsi_ioctl(scsi_CDs[MINOR(inode->i_rdev)].device, ...);
which is received in gnumach/linux/src/drivers/scsi/scsi_ioctl.c by
  int kernel_scsi_ioctl (Scsi_Device *dev, ...)

struct inode is defined in gnumach/linux/dev/include/linux/fs.h
with element
   kdev_t i_rdev;

So i assume that a new function in gnumach/linux/src/drivers/scsi/sr.c
would be able to either:
- derive Scsi_Device from kdev_t
- or run the scsi_ioctl_send_command() from a kdev_t id parameter.

Is this conclusion correct ?


There is no Scsi_Device used outside gnumach/linux/src/drivers/scsi.
So i deem it more desirable to implement the latter alternative.
I.e. a wrapper around scsi_ioctl_send_command() implemented in sr.c.

Would that be acceptable ?


A new question arised while exploring:

Shall i use  scsi_ioctl_send_command()  or  kernel_scsi_ioctl() ?
The latter is a wrapper around scsi_ioctl(), which can call
I do not yet understand what this wrapping is good for.
sr.c mostly uses kernel_scsi_ioctl() but for once scsi_ioctl().


Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]