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 > >
