bug-hurd
[Top][All Lists]
Advanced

[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:
> address@hidden 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-



reply via email to

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