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

[olafBuddenhagen]

Hi,

On Sun, Apr 10, 2011 at 08:42:53PM +0200, Thomas Schmitt wrote:

> > > So i would rather propose a new function with the semantics of
> > > SG_IO:
> >
> > A completely hurdish interface for this would probably be the best,
> > yes.
[...]
> I understand the recent statements about the reason behind Hurd in a
> way that a hurdish interface should foremost provide a better or at
> least novel approach to doing things.

Well, no, not really :-) There is no fixed definition for "hurdish"; but
in general we mean something that doesn't use UNIX emulation interfaces,
but rather something that fits better with Hurd's own mechanisms. Often
this means using native RPC interfaces, which I guess is what Samuel
meant here.

It should be noted though that we generally do not try to implement
hurdish interfaces at Mach level. The truth is that the Hurd was built
around Mach; Mach wasn't specifically adapted for the purposes of the
Hurd. Some aspects of Mach aren't really very hurdish -- and the device
driver interface probably least of all...

The current approach for handling device drivers in the Hurd is creating
a userspace server (translator) that talks to device driver in Mach
using Mach's protocols (which would probably mostly mean
device_get_status()/device_set_status() here), and presents a device
file on top of it. Such a device file can expose some established UNIX
protocol, and/or Hurd-specific mechanisms. If there are no standards for
certain functionality, "established protocol" often simply means
emulating Linux -- which probably would be most reasonable here...
xorriso itself wouldn't need a Hurd-specific backend at all this way :-)

(A "hurdish" solution at this level would be not to emulate Linux
interfaces, but rather implement a Hurd-specific native RPC interface --
but unless there is something fundamentally wrong with the Linux ioctl()
interface, I don't see much point in that.)

> xorriso is my implementation of these generalized models of
> streamwriting oriented media and filesystem. It encapsulates most of
> the media peculiarities and the task of coordinating image tree
> loading and session writing.
> 
> Its own usage model is command-and-reply. Like a shell script or
> dialog session. Seems to fit nicely into
> http://www.gnu.org/software/hurd/microkernel/mach/mig.html (Am i too
> stupid to see the links to tutorials and manuals ?)
> 
> Only that xorriso is *fat*. At least for an OS driver candidate. I
> would not dare to propose it to any of the usual kernel communities.
> 
> 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 ?

Actually the whole point of the Hurd architecture is to eliminate the
barriers between system functionality and user programs as much as
possible :-)

As Samuel pointed out, we wouldn't want to move xorriso's functionality
into Mach; but we could run it as another Hurd translator in userspace.
Note that this is completely different from the stuff discussed above:
the device file would be the interface xorriso uses to communicate with
the system-specific driver; while now we are talking about the interface
between xorriso's core functionality, and users/frontends. Instead of
the command line interface, we would have an RPC interface -- which
would indeed be a very hurdish approach, and might actually make sense
here :-)

Let me explain where I'm coming from. The traditional UNIX approach to
modularity is by invoking external processes that implement some generic
functionality. Many burning applications for GNU/Linux work that way:
they invoke tools such as xorriso to do the actual work.

However, such command invocations get very awkward when used in a
non-trivial fashion: things like progress indicators, error handling
etc. are not easy to fit into the simple serial input/output streams,
which are the main communication mechanism between UNIX processes.

To avoid these problems, many developers prefer to use shared libraries
(such as libburn) instead -- which however introduces a host of other
problems. (IMHO those people haven't really understood UNIX :-) )

The Hurd allows for a different approach: every process can export an
RPC interface, which can be attached to the filesystem namespace. (Often
this interface will provide some kind of pseudo-filesystem; but that's
not strictly required, if other kinds of interfaces fit the task
better.) Such RPC and/or filesystem interfaces allow for much better
interactive control than simple streams, while mostly preserving the
simplicity and other advantages of external process invocation. IMHO
it's a logical continuation of the UNIX approach. (Note that it's very
similar to the Plan9 concept, which is what some of the original UNIX
designers actually created as a followup to UNIX...)

So instead of directly exposing the command line interface, the core
functionality of xorriso would run as a Hurd translator, exposing an RPC
and/or filesystem interface, which could in turn be used by all kinds of
frontends. (A pseudo-filesystem is often more awkward and less efficient
than a specialised RPC interface; but on the other hand it offers a
great benefit: standard filesystem functionality can be used to access
the interface from any programming language without any special
bindings -- including shell scripts, or even manual invocations by
hardcore users...)

One of the frontends would of course be implementing the traditional
command line interface -- but now it would be required *only* for direct
invocation by users. Other frontends would not invoke tha command line
interface anymore, but instead would talk to the server using the
RPC/filesystem interface.

These possibilities are precisely what got me interested in the Hurd; so
I'd *love* to see something like that implemented! However, it should be
noted that this project goes far beyond the basic task of providing
xorriso support in the Hurd... That would strictly only require the
kernel interface described above.

-antrik-