Re: unionmount branches

[Sergiu Ivanov]

Hello,

On Wed, Dec 09, 2009 at 12:37:31AM +0100, Thomas Schwinge wrote:
> On Tue, Dec 08, 2009 at 09:20:45PM +0200, Sergiu Ivanov wrote:
>
> > Just to make sure: I can push the mount patch series (starting with
> > ``Add the --mount command line option'' to ``Add the mountee to the
> > list of merged filesystems'') to the unionmount branch in the
> > unionfs.git repository, right?
> 
> Isn't that exactly what the existing master-unionmount branch is about /
> contains?  Or is that branch to be considered obsolete and you have a
> similar patch series that should be used instead?

antrik suggested that I put only the patch series to which he has
given a final acknowledge into the public repository.  Since the mount
patch series has just (seemingly) received this kind of acknowledge, I
think the branch should contain exactly this series.  (However, I must
also crawl about mail archive to see whether antrik has given a final
approval to anything else.)

> If the latter, then yes, publishing that under a different name (be
> it unionmount or be it master-unionmount-Mk_2 or whatever) is the
> correct thing to do.  Please also remove the then-obsolte branch:
> 
> $ git push savannah :master-unionmount

Yes, I will surely do that.  Thank you for information :-)

Regards,
Sergiu

Re: additional questions

[olafBuddenhagen]

Hi,

On Tue, Dec 08, 2009 at 10:27:12PM +0100, Jakub Daniel wrote:

> I read a paper about mach not being the best choice of microkernel for
> hurd.

There are various comments to that effect floating around the net --
some well-founded, some myths...

> And I also know that viengoos has been in development for some time.
> What I hoped to find on the web was whether it (viengoos) is ment to
> replace mach if everything goes as expected (if viengoos is part of
> gnu project).

Viengoos is a testbed for some ideas about adressing certain concerns
found during Hurd development. So in a sense, it indeed caters to Hurd's
needs -- though I don't think Neal ever explicitely meant it to be a
replacement for Mach; but rather a research project, that *might* turn
out useful for the Hurd as well...

> As i took a look on the git repository of viengoos i found out that
> there have not been many commits since the beginning of this year, is
> it still being developed (actively).

No, unfortunately Neal changed his research focus. Nobody is working on
Viengoos anymore AFAIK.

> Would it be hard to switch from mach to viengoos (when it is ready)?

Depends on how it is approached. Probably it would be possible to create
some wrappers, so the existing Hurd implementation could be ported with
minimal effort. Making good use of Viengoos would require more
fundamental changes, though.

> Would it bring difficulties or would it be benefitial?

Both...

Viengoos addresses the shortcomings of Mach, but many of the ideas are
experimental, so it's hard to tell what it would bring. In either case,
it would require a considerable amount of work to do the initial port.

> I know this might sound a bit unrelated to this mailing list..

Not at all.

> but i have heard that hurd suffers from difficulties with mach..

It does in some areas. IMHO they are not the most urgent problems we are
facing -- but some people have a different opinion on that...

On Tue, Dec 08, 2009 at 11:13:15PM +0100, Jakub Daniel wrote:

> "From early on, the Hurd was developed to use GNU
> Machas the microkernel. This
> was a technical decision made by Richard Stallman, and one that he
> later saw as a mistake."

The mistake was in assuming that developing a multiserver system on top
of an existing microkernel would be faster than writing a monolithic
kernel from scratch.

I don't think RMS ever actually made a judgement on the merits of Mach
as a microkernel...

> even though i thought viengoos would bring newer drivers and support
> for various things that mach has not yed focused on.

Viengoos was never about drivers. That's an entirely different issue,
and pretty independent of the choice of microkernels.

(Zheng Da is presently working on the driver issue -- let's see how it
works out :-) )

> I also wondered if GNU/Hurd had some plan for future as other project
> have or due to the fact that there is lot of work on bugs that might
> yet occur it doesnt..
> 
> I mean whether there are some points when next release is made... some
> main revision versions with TODO lists..

Unfortunately, we do not have any roadmap. This is, in part, because
people have different visions about where the project should go...

-antrik-

Re: [PATCH 2/3] Implement mountee startup.

[olafBuddenhagen]

Hi,

On Tue, Dec 08, 2009 at 08:53:46PM +0200, Sergiu Ivanov wrote:
> On Sun, Nov 22, 2009 at 09:05:16PM +0100, olafbuddenha...@gmx.net wrote:
> > On Thu, Nov 19, 2009 at 10:28:37AM +0200, Sergiu Ivanov wrote:

> > > +  /* Fetch the effective UIDs of the unionfs process.  */
> > > +  nuids = geteuids (0, 0);
> > > +  if (nuids < 0)
> > > +return EPERM;
> > > +  uids = alloca (nuids * sizeof (uid_t));
> > > +
> > > +  nuids = geteuids (nuids, uids);
> > > +  assert (nuids > 0);
> > 
> > Hrmph, I didn't spot this before: I don't think the assert() is right --
> > "nuids" (or "ngids") being exactly 0, is probably a perfectly valid
> > case... And even if it is not, the test in the assert should be
> > equivalent to the EPERM test above, to avoid confusion.
> 
> OK, changed.

For the record: We agreed on IRC that rather than changing the assert,
it's better to go back to the original code, i.e. do the check/EPERM
thing again. It is actually possible that the number of UIDs changes in
the middle of things...

(Yes Frederik, I agree that this is not ideal either :-) But fixing this
properly is non-trivial, and out of scope here... Might be useful to
file a bug on Savannah though so it won't get lost.)

I'll just assume that the rest of the patch is also fine now, rather
than looking through the whole thing again... I looked at it many times
already; and even though it seems I'm spotting new things to nitpick
about each time I look, I have neither time nor patience right now to do
it yet another time. Also, I'm too afraid of actually discovering more
stuff to nitpick about ;-)

In other words: please push this to the main unionmount branch :-)

-antrik-

Re: [PATCH] Implement the sync libnetfs stubs.

[olafBuddenhagen]

Hi,

I think it's ready to go now :-)

-antrik-

Re: man: pipeline

[olafBuddenhagen]

Hi,

On Tue, Dec 08, 2009 at 10:27:12PM +0100, Jakub Daniel wrote:

> when i tried to examine man page of dpkg i got the following error
> (not right away but after i scrolled to line 129 or similar):
> 
> man: pipeline.c:1671: pipeline_peek_skop: Assertion `len <=
> p->peek_offset' failed.

This is a know bug (at least I'm experiencing it regularily) -- though
I'm not sure whether it's actually in the bug tracker. You might want to
check the bug tracker, and add it if it's not there yet :-)

-antrik-