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-
