Re: Interface for SCSI transactions ?

[Thomas Schmitt]

Hi,

about registering the new call in struct device_emulation_ops:

me:
> > I would see this as further cementing a bad tradition.
Olaf Buddenhagen:
> I'm not really set on this; but to me it looks like a new path for
> directly invoking driver-specific functions would just be taking an
> unnecessary risk here.
> (OTOH, you looked at this code more than me; so you probably have a
> better idea what it really takes...)

All i can see of device_emulation_ops usage with e.g. device_get_status()
is this call in gnumach/device/ds_routines.c
  return (*dev->emul_ops->get_status) (dev->emul_data, flavor, status,
                                       status_count);

It dispatches the received RPC to one of the instances of
struct device_emulation_ops. All block devices are covered by the
same method of instance
  linux_block_emulation_ops
in
  gnumach/linux/dev/glue/block.c

My plan would directly call a new function in the same source file.
So no brain would be lost.

Nevertheless, my sketch of yesterday (Oct 16) can easily be widened
to use a device_emulation_ops method.
Just choose what you would prefer. :))


> My hope is that once we use a modern Linux driver, we could use
> *exactly* the same code in libburn;

My newest sketch would already provide this compatibility in
userspace. (It does not matter much whether we add more members
to the end of struct sg_io_hdr. Nevertheless, my current sketch
does not yet plan for such additions, because they would not be
supported in gnumach yet.)

libburn would have no problem with a Hurd-specific way of performing
SCSI transactions. But of course sg_io_hdr would ease porting of
growisofs, libcdio, or even wodim.


Have a nice day :)

Thomas