Hi, 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 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(). ----------------------------------------------------------------- Have a nice day :) Thomas