[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interface for SCSI transactions ?

From: Thomas Schmitt
Subject: Re: Interface for SCSI transactions ?
Date: Mon, 17 Oct 2011 09:17:17 +0200


about registering the new call in struct device_emulation_ops:

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

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]