[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [address@hidden: Interface for SCSI transactions ?]
From: |
Samuel Thibault |
Subject: |
Re: [address@hidden: Interface for SCSI transactions ?] |
Date: |
Thu, 21 Apr 2011 02:15:58 +0200 |
User-agent: |
Mutt/1.5.12-2006-07-14 |
Thomas Schmitt, le Sun 10 Apr 2011 22:41:23 +0200, a écrit :
> > > So what is Hurd's attitude towards a driver that occupies 2.5 MB
> > > of memory when idle and might expand much more on the job ?
> > > Is it worth to continue thinking about xorriso-in-the-system ?
> >
> > Not a problem in a Hurdish mind. The stuff can be split in low-level
> > driver which just does the SCSI commands and a daemon which does the big
> > stuff, run as mere user.
>
> The low-level driver would be the SCSI transaction call.
>
> Do i get it right that device_get_status() is on the other side
> of the RPC interface ? (Seen from a user process.)
Yes.
> And that there needs to be defined a new RPC to reach a new call
> device_transact_command() ?
Yes.
> If so: is there a chance to transfer a new struct through the
> existing RPC of device_get_status() ?
> (Probably not, i expect.)
device_get_status transports an variable-size array of integers, no
more, no less.
> Honestly spoken, i do not feel apt to cope with the task of wiring
> the SCSI transaction to userspace.
> I probably could design the struct and derive the scsi transaction call
> from scsi_ioctl_send_command(). (Copying from Linux might help, too.)
> But i am already clueless about the task to assert that the device
> handle of device_transact_command() is suitable for scsi_do_cmd().
>
> So it looks as if we have to stop here until a better skilled person
> appears who is interested in enabling burner drive operation.
I'll let it to anybody who has time for this.
Samuel
Re: [address@hidden: Interface for SCSI transactions ?], olafBuddenhagen, 2011/04/12