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
