Thomas Schmitt, le Sat 10 Sep 2011 13:46:23 +0200, a écrit :
> 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 */
Also notice the DECL_DATA and INIT_DATA macros. I guess they build
valid inode and file structures.
> 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, ...)
I've rather had a look at sr_ioctl, but it's basically the same.
> 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 ?
That looks right, yes, although I don't really see the difference
between the alternatives you propose: in both case you turn in sr.c the
i_rdev field from the inode structure into a Scsi_Device pointer, and
call scsi_ioctl_send_command from that.
> -----------------------------------------------------------------
>
> 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 wrapper looking like sr_ioctl (i.e. taking inode & file), yes.
> -----------------------------------------------------------------
>
> 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
> scsi_ioctl_send_command().
> I do not yet understand what this wrapping is good for.
> sr.c mostly uses kernel_scsi_ioctl() but for once scsi_ioctl().
Use the former. The latter is only needed when the call is triggered by
a kernel thread and not a userland processus.
Samuel
