headers
olafBuddenhagen | 1 Feb 2006 01:21
Picon

Re: Meantime

Hi,

> In fact, I strongly agree with Olaf: Anybody who wants to help with
> design issues should make sure they understand the Hurd on Mach well
> enough to see the strengths and weaknesses.

Now this surprises me. When I suggested a while back to point "idling"
Hurd/L4 developers to take a look at Hurd/Mach, you were strongly
against it. Am I missing something, or did you change your opinion on
that?...

Anyways, glad you agree now :-)

-antrik-
Permalink | Reply | 3 comments |
headers
Marcus Brinkmann | 1 Feb 2006 02:02
Picon
Favicon

Re: Meantime

On Wed, 2006-02-01 at 01:21 +0100, olafBuddenhagen <at> gmx.net wrote:
> Hi,
> 
> > In fact, I strongly agree with Olaf: Anybody who wants to help with
> > design issues should make sure they understand the Hurd on Mach well
> > enough to see the strengths and weaknesses.
> 
> Now this surprises me. When I suggested a while back to point "idling"
> Hurd/L4 developers to take a look at Hurd/Mach, you were strongly
> against it. Am I missing something, or did you change your opinion on
> that?...

I don't recollect that particular conversation, but maybe my
understanding at the time was that you meant "look at" to mean actively
developing it instead of (or in addition to?) contributing here.  There
is a wide diversity of what "look at" can mean, and some of them I find
useful for anybody who wants to help, while others I find useful only if
specific needs exist.  Maybe it was just a misunderstanding.

This has, from my point of view, nothing to do with the time scale,
although in each individual case it very well might.  I think it is only
natural that, if you expect to be able to help redesigning the Hurd, you
should know what the Hurd is.

THanks,
Marcus
Permalink | Reply | 0 comments |
headers
Marco Gerards | 1 Feb 2006 16:26
Picon
Picon
Favicon

Re: Meantime

<olafBuddenhagen <at> gmx.net> writes:

>> In fact, I strongly agree with Olaf: Anybody who wants to help with
>> design issues should make sure they understand the Hurd on Mach well
>> enough to see the strengths and weaknesses.
>
> Now this surprises me. When I suggested a while back to point "idling"
> Hurd/L4 developers to take a look at Hurd/Mach, you were strongly
> against it. Am I missing something, or did you change your opinion on
> that?...

This does not surprise me.  Marcus never said such thing.  He just
said that Mach is not the way to go (so for the long term).

--
Marco
Permalink | Reply | 1 comment |
headers
olafBuddenhagen | 2 Feb 2006 07:27
Picon

Re: Meantime

Hi,

> This does not surprise me.  Marcus never said such thing.

How can you know, not having been present at the conversation I'm
referring to?

I guess it was a misunderstanding indeed (sadly, not the only one it
seems), and let's just settle it at this, OK? Thanks.

-antrik-
Permalink | Reply | 0 comments |
headers
Marcus Brinkmann | 2 Feb 2006 19:56
Picon
Favicon

DogCows or Polymorphism in the Hurd

Hi,

here is a small issue to ponder.  I'd like input on this.

Consider an object system.  Sometimes, it is very clear which interface
an object should implement.  Sometimes, it is not so clear, and objects
can be viewed from different angels; these objects have multiple facets.

Take for example a tar.gz file object.  You can look at it as a binary
file.  But you can also look at it as an archive, which provides many
files in a directory structure.  In this case, the tar.gz object itself
is the root directory of the archive.

In the object oriented paradigm, this problem can be elegantly solved by
polymorphism.  The tar.gz class can be derived from the file class on
the one hand, and the directory class on the other hand.  In Java, such
abstract base classes as file and directory in this example are called
interfaces.

The Hurd (on Mach) takes a similar approach.  Although MiG does not
support type hierarchies, the Hurd objects are organized in a hierarchy.
And in this hierarchy, there is a single class "fs", which is derived
from "io" and which contains the file _and_ the directory methods.  So,
in effect, all objects you encounter in the filesystem implement both
the file and directory operations.  The "fs" class constitutes a
"DirFile" type, a type that is the result of lumping together two
different types.

To make this more abstract, you can think of the "DirFile" Type as a
"DogCow" type, from which you can derive Dogs, Cows, or arbitrary
(Continue reading)

Permalink | Reply | 38 comments |
headers
Jonathan S. Shapiro | 3 Feb 2006 03:28
Favicon
Gravatar

Re: DogCows or Polymorphism in the Hurd

Marcus is replaying a conversation that started at my house. Some ascii
art may help. I will try to respond to questions on this subject, but
poor Marcus is stuck on a plane for the next 18 hours, so he may need to
correct me later.

The term "dogcow" came about to describe the following interface
hierarchy:

      Animal
      /    \
     Dog   Cow
      \    /
      DogCow

That is: a holder of a DogCow capability can invoke either the "Dog"
methods or the "Cow" methods. If I remember, the original discussion
started with Plan-9, where directory and file operations are mingled in
the 9p protocol.

[At the time of the discussion, my dog Morgan was assisting us by
allowing us to scratch her back, and our cat, Snickers, was commenting
on how silly we all looked in front of the whiteboard with the stupid
dog when we should really be petting him instead.]

Consider the following DogCow interface:

     FsObject
      /   \
     File Dir
      \   /
(Continue reading)

Permalink | Reply | 2 comments |
headers
Barry deFreese | 3 Feb 2006 04:31
Picon

Re: DogCows or Polymorphism in the Hurd


----- Original Message ----- 
From: "Jonathan S. Shapiro" <shap <at> eros-os.org>
To: "Marcus Brinkmann" <marcus.brinkmann <at> ruhr-uni-bochum.de>
Cc: <l4-hurd <at> gnu.org>
Sent: Thursday, February 02, 2006 9:28 PM
Subject: Re: DogCows or Polymorphism in the Hurd

> Marcus is replaying a conversation that started at my house. Some ascii
> art may help. I will try to respond to questions on this subject, but
> poor Marcus is stuck on a plane for the next 18 hours, so he may need to
> correct me later.
>
>
> The term "dogcow" came about to describe the following interface
> hierarchy:
>
>      Animal
>      /    \
>     Dog   Cow
>      \    /
>      DogCow
>
> That is: a holder of a DogCow capability can invoke either the "Dog"
> methods or the "Cow" methods. If I remember, the original discussion
> started with Plan-9, where directory and file operations are mingled in
> the 9p protocol.
>
> [At the time of the discussion, my dog Morgan was assisting us by
> allowing us to scratch her back, and our cat, Snickers, was commenting
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonathan S. Shapiro | 3 Feb 2006 05:25
Favicon
Gravatar

Re: DogCows or Polymorphism in the Hurd

On Thu, 2006-02-02 at 22:31 -0500, Barry deFreese wrote:

> I like this approach.  I could think of other uses for facets such as .deb 
> or .rpm files.  How invasive would this be to existing applications?

I have no direct experience, but from the cases that Marcus described,
it sounds like moving to this model would *reduce* invasiveness to
existing applications.

shap
Permalink | Reply | 0 comments |
headers
Tom Bachmann | 3 Feb 2006 09:42
Picon

Re: DogCows or Polymorphism in the Hurd

Marcus Brinkmann wrote:
> These applications face a problem in the Hurd: They will see objects
> that look like Directories _and_ like Files.  This causes erratic
> behaviour.  For example, "grep *" will search through the binary content
> of directories

Why the hell directories provide their binary content?

> (because it treats them as files). 

Yes. But grep usually doesn't choose the files to examine at all. The 
user/shell does.

> One suggestion was
> that we add extra options to such programs to control how hybrid types
> should be treated by the application.
> 
> So, here is the deal: Either we convince ourselves that such erratic
> behaviour is isolated and can be fixed by proper defaults and making
> minor modifications to existing programs.  Or we find out that in
> general this problem is too hard to fix: How an application should treat
> a DirFile may be context-sensitive and depend on the exact type of the
> object, the intent of the application ("find" used for backup vs "find"
> used for locatedb), or even the intent of the user. 

This is true, sadly.

> In this case, it
> may be better to drop the notion of "DogCows", and make the _current_
> facet of the object explicit in its type.  Here is how this can be done:
(Continue reading)

Permalink | Reply | 8 comments |
headers
Bas Wijnen | 3 Feb 2006 10:55
Picon
Favicon

Re: DogCows or Polymorphism in the Hurd

On Thu, Feb 02, 2006 at 01:56:50PM -0500, Marcus Brinkmann wrote:
> here is a small issue to ponder.  I'd like input on this.
> 
> However, it happens that in Unix, Directories and Files are not only
> very distinct objects, but they are also understand by a wide range of
> applications simultaneously.  Ie, many applications look at a node in
> the filesystem, decide if it is a file _or_ a directory, and then take
> an appropriate action.  All applications that can traverse a filesystem
> belong into this group, for example ls, rm, grep, find, etc.  This is
> the most prominent group, but I would expect there to be isolated cases
> of other applications that do this (maybe Apache?  Input welcome here).

Huh?  Why?  I'd say it's quite clear that there is a huge number of
applications which fall into this category.  Everything that has a file->open
dialog for example.  This group is so large that IMO it's undoable to make a
(possibly small) change in all of them.

> Using the poly-type approach would remove all ambiguities: Applications
> would either see a file or a directory, but not both.  Applications who
> _know_ about hybrid types can use the new functions to switch facets
> explicitely.  If a user wants to use an application with a hybrid type,
> he will have to make his intent explicit by providing the node with the
> right facet type to the application.

This sounds good.  I think I would like to have the creation of the nodes with
other facets (so the creation of "foo" when "foo.tar.gz" exists) explicit.
That is, the user has to do it.  Otherwise there will be too many name space
collisions.  For example, it is usual that a foo.tar.gz unpacks a directory
called foo and files inside it.  If that directory and those files already
exist, strange things will happen when a script unpacks it, possibly removing
(Continue reading)

Permalink | Reply | 19 comments |

Gmane