Re: Interface for SCSI transactions ?

[Svante Signell]

Thomas,

Don't you have any time any longer for working on this? I/we understand
if you don't, but no reply since October 17 makes one wonder.

Best regards,
Svante Signell
Currently a Debian GNU/Hurd porter, not (yet) a developer :(

On Mon, 2011-10-17 at 09:17 +0200, Thomas Schmitt wrote:
> 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
> 
>