Re: [address@hidden: Interface for SCSI transactions ?]

[Thomas Schmitt]

Hi,

olafBuddenhagen@gmx.net wrote:
> you still need a way to access the actual burner... I don't
> really know, but I rather doubt that any VM solution actually exposes
> the host system's burner to the guest system as an ATAPI device
> connected to a virtual PATA controller...

libburn does not talk to the controller but to the system's
abstraction of SCSI command transactions. It does not matter whether
PATA, SATA, USB or old SCSI is used for transport.
libburn is client, the CD drive is server, inbetween is a cloud.

I googled and found on http://wiki.centos.org/HowTos/KVM
this command
  qemu-kvm -hda win2k.img -cdrom win2k.iso -m 512 -boot d
with the further statement
  "If you were booting the cdrom from the host machine's CDROM
   drive, you would use -cdrom /dev/cdrom." 

I assume that a booting Win2K will talk to the virtual CDROM by
SCSI commands. Non-MMC drives are out of fashion since more than a
decade.

There might occur the obstacle that the CDROM emulation will not
allow to send certain commands like WRITE or BLANK.
A libburn system adapter for Hurd could be tested by read-only
commands, nevertheless.


> If your machine supports IO virtualisation (IIRC AMD simply calls that
> IOMMU), you *might* be able to use a real PATA burner, and give the
> guest system direct access to the the PATA controller it is connected
> to. Don't know though whether this really works...

The machine has a SATA DVD burner and a PATA DVD-ROM drive.

I will have to learn about running kvm on Debian GNU/Linux and then
install Debian Hurd, as Samuel advised me.
This may last a while for various reasons.


> However, I hardly do any burning nowadays; so I'm not sure I would be a
> good tester...

(Hmmm ... maybe if the bounty money could bribe real users into
 testing Hurd then there would be more urge to use CD drives.
 Something like a paperchase ... :))


> The drivers are from Linux 2.0 -- not sure whether the
> functionality they offer is suitable for modern use...

I still frown a bit on the serialized struct that is transfered.
But its components should suffice for a start.
Maybe one first has to hardcode longer timeouts and later introduce
a better struct that allows to set such parameters from user space.


> > I still have to explore how to beef up the userland side of
> > device_get_status().

> just invoke it with the right parameters...

I understand we need a new value for function parameter
  dev_flavor_t flavor
which will indicate that
  dev_status_t status
actually contains a serialized struct sdata for parameter buffer of
  int scsi_ioctl_send_command(Scsi_Device *dev, void *buffer)
  {
    ...
    /*
     * The structure that we are passed should look like:
     *
     * struct sdata {
     *  unsigned int inlen;
     *  unsigned int outlen;
     *  unsigned char  cmd[];  # However many bytes are used for cmd.
     *  unsigned char  data[];
     * };
     */

Will there no declaration or recognition needed on the local side of RPC ?


Have a nice day :)

Thomas