bug-hurd
[Top][All Lists]
Advanced

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

Re: Interface for SCSI transactions ?


From: Samuel Thibault
Subject: Re: Interface for SCSI transactions ?
Date: Fri, 9 Sep 2011 01:13:47 +0200
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Thomas Schmitt, le Tue 06 Sep 2011 18:32:55 +0200, a écrit :
> I have to guess a bit. But it looks like
>   http://www.gnu.org/software/hurd/users-guide/using_gnuhurd.html#Helping-Out
> in its node
>   
> http://www.gnu.org/software/hurd/users-guide/using_gnuhurd.html#Basic-CVS-Usage
> shows an example that brought me to "Hurd Hacking Guide"
>   http://www.gnu.org/software/hurd/hacking-guide/hhg.html
> where
>   http://www.gnu.org/software/hurd/hacking-guide/hhg.html#Requirements
> says
> "
>   4. The sources of Hurd and GNU Mach are also useful:
>      mkdir ~/hurd-cvs
>      cd ~/hurd-cvs/
>      cvs -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd \
>          co hurd
>      cvs -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd \
>          co -r gnumach-1-branch gnumach
> "

Oops, Thomas, we should probably at least fix the URLS in the HHG.

> Would it be a problem to transport MAX_BUF + 252 bytes through a RPC ?

Not a problem at all. RPCs can have out-of-band data, which is mostly
unbound.

> > > Currently it seems appealing to have one [RPC] that calls quite directly
> > > scsi_ioctl_send_command() .
> 
> > That's probably the most correct way.
> 
> But looks quite out of my personal reach for now.

It's actually very simple to define an RPC, it essentially looks
like a C function declaration, see ./include/device/device.defs
for the device_set_status RPC declaration for instance. What is
a bit more involved will be to add the method to the
device_emulation_ops structure, and the ds_device_foo routine in
device/ds_routines.c just like the ds_device_set_status() one.

Rebuild the glibc, and voilà, you have your RPC.

> To my excuse i can only state that all info about Hurd emphasizes servers
> and translators.

Yes, since that's our goal.

> So it did not come to me that the situation is not much different from
> a Linux kernel

Actually it shouldn't. It happends to be so just because it was
initially simpler to embed Linux drivers in the kernel, but we aim at
doing the same in userland now.

> I rather expected something like one translator per SCSI bus.

That's our goal with the userland drivers.

Samuel



reply via email to

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