[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [address@hidden: Interface for SCSI transactions ?]
From: |
olafBuddenhagen |
Subject: |
Re: [address@hidden: Interface for SCSI transactions ?] |
Date: |
Thu, 19 May 2011 01:48:34 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi,
On Tue, May 17, 2011 at 03:35:45PM +0200, Thomas Schmitt wrote:
> 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.
Yes, but the guest system needs a way to talk to a the burner, which is
under the host system's control... Plus, gnumach can't talk to a SATA
burner at all.
> 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."
Interesting... Might be worth a try :-)
> > > 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 ?
For the "flavor", you just define a new value in an appropriate header
file in [gnumach]/include/device/; and the userspace code can use it
after including that header file.
"status" is just an array of integers -- so you don't have to define
anything here. Just serialize the parameter structure in the code
invoking device_get_status()/device_set_status() -- which should be
rather easy according to the above declaration...
-antrik-