[task #9686] implement functions missing in the Hurd port of glibc

[Thomas Schwinge]

Update of task #9686 (project hurd):

 Summary:implement readlinkat => implement functions
missing in the Hurd port of glibc

___

Follow-up Comment #3:

That's what I told them to use instead of the * && !defined(__gnu_hurd__) *
which the Debian maintainer had come up with: no changes needed for us once we
have readlinkat implemented -- real soon now, as you say.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[task #9686] implement readlinkat

[Thomas Schwinge]

Follow-up Comment #1, task #9686 (project hurd):

insserv is now working around this by also detecting whether
__stub_readlinkat is defined or not, and resorting to alternative code if it
is.

Nevertheless, readlinkat, as well as other functions should be implemented. 
See /usr/include/gnu/stubs-32.h for a complete list; not all of them are
likewise important, though.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Is there interest in Hurd people meeting at: [...@gnu.org: GNU Hackers Meeting Registration - Gothenburg 2009]

[Thomas Schwinge]

Hello!

Please see the attached email.  Is there interest among Hurd people to
meet there?


Regards,
 Thomas
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Registration is now open for the GNU Hackers Meeting on 11-13 November
in Gothenburg, Sweden.  It is being held jointly with the FSCONS
conference on 14-15 November.

The meeting is intended for GNU maintainers and active GNU
contributors.  Its theme is "the continued advancement of the GNU
system".  Full details can be found at http://www.gnu.org/ghm/2009/

If you want to attend, please fill in the online registration form at
the URL above.

If you're not sure whether you will be able to attend, please register
as 'provisional' and let us know your final decision later.

If you need support for travel or accommodation costs, you can
indicate this on the registration form.

Thanks to Henrik Sandklef and the FSCONS organisers for hosting the
event.  Hope to see you in Gothenburg.

- -- 
Brian Gough

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iJwEAQECAAYFAkqJVBMACgkQ9U2K2oCCH+rotgQAne7OMOuxQZJbl8h2a7Mpa1P1
US8dUNSnqOQf1Y+I7pJPGzhhlumXCQweMNH6t7CC5IylYIzqp9pXA24VhvCEkduP
fUV/KYEaGZ6/9H0eEGKqN17m/MIrMt1lyp02tWyEosnh8vp6k2XXzIRyxXASy0Bv
fLScEtshlrhdsKRjqPo=
=c4/f
-END PGP SIGNATURE-



--
http://lists.gnu.org/mailman/listinfo/gnu-prog

--- End Message ---


signature.asc
Description: Digital signature

News 2009-08-31, documentation, wiki

[Thomas Schwinge]

Hello!

Instead of following up to each email individually, I'll combine some
answers in here.


On Sat, Sep 05, 2009 at 04:04:19PM +0200, Arne Babenhauserheide wrote:
> It's time again for news

> Or did you merge in more of the old code repositories into git? 
> 
> And while I'm asking ( :) ): What happened to the code from last years GSoC? 

This stuff is amongst the next I'll be doing.


On Mon, Sep 07, 2009 at 02:15:44AM +0200, olafbuddenha...@gmx.net wrote:
> On Sun, Sep 06, 2009 at 06:07:01PM +0300, Sergiu Ivanov wrote:
> > > > Also (if required) I can provide a short explanation on some Hurd
> > > > wiki page.  
> [...]
> > There is a small problem though: I'm not sure on which page to create
> > the documentation.  There is hurd-web/hurd/translator/unionmount.mdwn,
> > but it's the description of the project idea.

> I have no opinion on that -- it wasn't me who moved the page there :-)

This is from the time when my understanding was that unionmount would
indeed be a separate translator from unionfs.  If now the consensus (or
actually, more simple, what Sergiu has implemented) is that it is part of
unionfs proper, then this page should be merged into the h/t/unionfs one,
or be made a subpage of it, like h/t/unionfs/unionmount.

> It was originally in the project ideas directory, and the purpose was
> clear; but I don't know what it is supposed to be now... (With the
> current content, it certainly doesn't make sense as a description of an
> existing translator.)

It was meant to be a starting point, and to be improved over time.

> > antrik, is it okay if I add the short documentation about the usage of
> > union-mount-mode options in unionfs to this page?

Please, in my opinion at least, try to get rid of your (noble-minded, I
know) habit of always asking for permission before doing such changes.
Just do the change -- you're an active part of the community, so you're
entitled to do changes -- and if we don't like it we'll later enhance /
rework / fix / delete it.  By the sum of time we spent with you asking
for this change, some of us reading your email, thinking about it,
answering it, you'd already have done this enhancement a few times.

> (BTW, the redirect from the original location seems broken.)

Which one exactly?


On Sun, Sep 06, 2009 at 03:20:04PM +0200, Arne Babenhauserheide wrote:
> Am Sonntag, 6. September 2009 13:30:46 schrieb Sergiu Ivanov:
> > Also (if required) I can provide a short explanation on some Hurd wiki
> > page.  
> > This will take less time than writing full-fledge documentation
> > (which means that I'll be able to do it much sooner) and should be
> > enough for the majority of use-cases.
> 
> Maybe you can also use it as starting point.  Then you won't have to write 
> everything over again, but can just reuse the short description to turn it 
> into full fledged docs later on. 

Exactly.  Let this be our future work-flow: begin with bits of
information, and improve them over time.  This is actually, by the way,
exactly what I am doing, and the reason why there are so many unfinished
pages -- which is not a bad thing, as otherwise these unfinished pages
wouldn't be published at all, but only sitting somewhere on my computer.


On Mon, Sep 07, 2009 at 10:34:12PM +0200, Arne Babenhauserheide wrote:
> Am Montag, 7. September 2009 22:04:58 schrieb Sergiu Ivanov:
> > OK.  We only have to wait for another two weeks, I guess, until he
> > gets back :-)
> 
> Why don't you just do it? 
> 
> It's version controlled after all, so if something is a big problem for 
> someone, we can easily fix it. 
> 
> We don't lose anything when those who have most knowledge about the special 
> area just act, but we lose a lot of time by waiting too much. 
> 
> If there's a better place for the documentation, it's trivial to just copy 
> the 
> info there later on.

Thank you, Arne, exactly my thoughts.

> The only thing which is hard to fix are pages which have 
> very many manual backlinks.

Even that (usually) is not hard at all if you know your Unix shell
scripting: find / grep / sed / ...


On Tue, Sep 08, 2009 at 10:08:23AM +0300, Sergiu Ivanov wrote:
> On Mon, Sep 07, 2009 at 10:34:12PM +0200, Arne Babenhauserheide wrote:
> > Why don't you just do it? 
> > 
> > It's version controlled after all, so if something is a big problem for 
> > someone, we can easily fix it. 
> 
> I can see your point, but please note that if I were to think of the
> Hurd wiki in terms of a version controlled entity, I would create a
> personal branch and wait for approval from the authorized person to
> move the corresponding modification in the master branch.  However,
> it's obvious that creating a personal (private) branch in the hurd-web
> repository is rather meaningless since nobody can see it anyway.

Well, it's not visible in the HTML pages, but it definitly is visible for
everyone interested in it in the source pages, and I can then simply
merge your branch if I like it.  Again, simply *doing* thi

Source repositories, unionmount code

[Thomas Schwinge]

Hello!

Instead of following up to each email individually, I'll combine some
answers in here.


On Sun, Sep 06, 2009 at 11:45:34AM +0300, Sergiu Ivanov wrote:
> On Sat, Sep 05, 2009 at 04:04:19PM +0200, Arne Babenhauserheide wrote:
> > How did the GSoC work out?  
> 
> antrik gave me a passing final evaluation, so (at least formally) the
> GSoC was a success.

Congratulations!

> In my local repositories I have a working
> implementation of what I understood was expected of me.  However, I'm
> not sure as to whether these changes should all go in the public
> unionfs git repository or not :-(

There is absolutely no reason why they shouldn't go into the Hurd
repositories at Savannah.  Please, everyone, realize that these
repositories are mainly to be *USED* by *YOU*, the developers, and
they're only secondary to be used for publishing a crystal-clear /
no-error changeset history.  Please *ACTIVELY USE* the machinery that we
provide.  It really seems totally absurd to me that you, one of the few
active Hurd code contributors would (have to) publish his stuff on a
third-party server (github, gitorious).

And if you're afraid or installing stuff into master or master-TOPIC
branches, then we can also use the scheme à la SAVANNAH_LOGIN/WHATEVER
for branch names.  What you do on the scolobb/WHATEVER branches is
totally your own business.

Even for publishing the various variants of your patches in the progress
of development, I'd have used scolobb/unionmount-FEATURE-mark1 .. mark23
branches (or scolobb/unionmount-FEATURE-2009-07-07...) (each of them
based on the then-current unionfs master) instead of only publishing the
in email.  Email is fine for discussing patches (which we've successfully
been doing), but also for creating a bit of a mess and losing track of
the whole thing (which we've successfully been doing).


On Mon, Sep 07, 2009 at 01:53:08AM +0200, olafbuddenha...@gmx.net wrote:
> On Sun, Sep 06, 2009 at 02:30:46PM +0300, Sergiu Ivanov wrote:
> > On Sun, Sep 06, 2009 at 12:20:11PM +0200, Arne Babenhauserheide wrote:
> > However, I'd say that we somehow failed to discuss how exactly to make
> > the code public :-(
> 
> Actually, we did discuss it. We agreed that it is fine for now to have a
> unionmount branch in the main unionfs repository -- though ultimately I
> want to see both as part of the main Hurd tree...

Why, oh why?


> However, only approved patches should go into the main unionmount
> branch. So what to do with those that still need review/fixing? Usually
> each such patch series would go into a topic branch in a personal
> repository. Unfortunately Savannah doesn't offer personal repositories;
> so this leaves us with two options: putting the topic branches in the
> main repository as well; or putting them in some other repository, e.g.
> on gitorious...

As I said above: main repository, but personal branch(es).  Simply let
branches like SAVANNAH_LOGIN/* be our way of having a personal
repository.  And this is not common: other project are also working like
this.


> > I'm rather inclined to consider that shipping unionfs and nsmux with
> > LiveCDs and QEMU images is not an imperative to encourage their
> > testing.  Potential users could just as well download the code or
> > clone the repositories locally.
> 
> Yes, they could. But it's a *considerable* barrier. In practice, it
> simply means that hardly anybody will do it, so it's left to rot -- just
> like all the stuff in hurd-extras...

Part of this is simply a packaging problem -- that is, that these
translators are in fact not packaged for Debian.  Can't someone simply do
this eventually?


> > Note that as opposed to some other translators (like Zheng's
> > eth-multiplexer), both unionfs and nsmux were designed to be
> > stand-alone,
> 
> ...which is the reason why I still haven't tested nsmux -- I'm still
> waiting for you to integrate it in the Hurd tree

That doesn't make any sense.  If you're interested: just get the source
code and run make.  Why does it need to be part of the Hurd code
conglomerate in order for you being able to test it?  And yes: they
should remain stand-alone.  I will integrate these packages into our git
repositories soonish.


On Mon, Sep 07, 2009 at 10:44:00PM +0300, Sergiu Ivanov wrote:
> I'd rather refrain from pushing my personal topic branches to the
> unionfs repository -- this does smell of something like messing things
> up.

And why exactly?  Again: these repository infrastructure is meant to *be
used*, to *be worked with*, for enabling us, the developers, to *make
progress*!  (And only secondary for showing to the world our (few) nice
almost-perfect changesets.)


> On Mon, Sep 07, 2009 at 01:53:08AM +0200, olafbuddenha...@gmx.net wrote:
> > On Sun, Sep 06, 2009 at 02:30:46PM +0300, Sergiu Ivanov wrote:
> > > I'm rather inclined to consider that shipping unionfs and nsmux with
> > > LiveCDs and QEMU images is not an imperative to encourage their
> > > testing.  Potential users could just as

Software (and text) management

[Thomas Schwinge]

Hello!

Instead of following up to each email individually, I'll combine some
answers in here.


On Tue, Sep 08, 2009 at 12:28:09PM +0200, Arne Babenhauserheide wrote:
> Am Dienstag, 8. September 2009 09:08:23 schrieb Sergiu Ivanov:
> > I can see your point, but please note that if I were to think of the
> > Hurd wiki in terms of a version controlled entity, I would create a
> > personal branch and wait for approval from the authorized person to
> > move the corresponding modification in the master branch.  
> 
> I think there are several different ways of seeing history, all depending on 
> how people interact (and how many people read the history). 
> 
> One is to see history as a decision record.  You create clean patches and 
> show 
> them to people to propose a change.  In that case you need a clean history, 
> or 
> you need to flatten your local history into distinct patches before 
> publishing 
> it.  When people read your history, they see the effects of your groups 
> decision process, but not the process itself.  When you have very complex 
> systems or very many people interacting, this looks to me like the only way 
> to 
> avoid running into problems.  The same might be true for companies who need 
> to 
> be able to clearly blame people for errors.
> 
> Another way is to see the history as a means to synchronize the work and as a 
> simple track record.  It makes it easier to work distributed, because work 
> can 
> more easily be merged, but it isn't necessary for the history to look pretty 
> to someone outside.  You don't need to turn everything into a final patch, 
> because people can simply skit over change descriptions like "typo" and such, 
> and more importantly, the final look of the history isn't important.  If you 
> work in a small project which regularly synchronizes or in a project where 
> the 
> parts aren't too tightly interwoven, this can increase the development speed. 
>  
> Getting something perfect before publishing means that others have to wait 
> longer before they can include and test it.  And if everyone polishes very 
> much, it means that everyone has to wait until everything is polished (and 
> many things might become stale and disappear before even going public).  

Nice descriptions!

> I use the second approach most of the time, since I don't currently work in 
> big groups and the projects I do aren't so complex that small changes can 
> throw off everything (I hope Thomas doesn't hate me for the many "typo" 
> commits...). 

I don't care -- though I think that you could probably mostly reduce them
by simply re-reading what you're going to commit...  :-)

> If I were in a big group where people don't really know each other, or in a 
> project where maintenance is harder than creating the data, I'd switch to the 
> first way, though.  

Or put it this way: the first way is absolutely necessary if your
software is being used out in the wild, and any new bugs you introduce
(while trying to fix others) would be directly visible by others and
(potentially) cause harm to them.  That is, released software, considered
stable.

Now, for the whole set of Hurd software, I think that we can consider all
of it experimental, in development, not stable and released.  Thus, we're
rather entitled to do it the second way, for easier procedures.

And of course, even when going the second way, it doesn't hurt to apply
as many principles from the first as possible -- as long as they don't
interfere with what you're trying to do in the first place.


> > However,
> > it's obvious that creating a personal (private) branch in the hurd-web
> > repository is rather meaningless since nobody can see it anyway.
> > 
> > OTOH, if I do just commit a change to the master branch right now and
> > should it be decided that this change was inappropriate later, there
> > would be two ways out: either remove the commit from the middle of the
> > history or do clean-up commits, both of which are rather ugly.
> 
> Do you mean, they either are ugly for people who want to synchronize their 
> own 
> repository, or they are ugly to those who want to read the history later on? 
> 
> For me the first is a concern, but the latter doesn't matter that much for a 
> wiki.  A wiki is meant to be quickly edited by many people.  A VCS doesn't 
> change the kind of project it's supporting (for example I version control a 
> roleplaying rulebook I work on).  It does give us additional options, though. 
>  
> 
> More exactly: Thinking a lot about the latter can eat far more time than 
> cleaning up afterwards.  And a quick clean up commit like 
> "moved the union mount description to foo because bar and baz" 
> doesn't look ugly to me.  It's clear what it does, so I don't even have to 
> look at the patch, and its effect is clearly contained.  
> 
> And our wiki tends to get out of date, so updating status or providing 
> current 
> information is our bottleneck.  
> 
> On the other hand, the Linux kern

On vacation

[Thomas Schwinge]

Hello!

For your information.  No Hurd-wise progress from my side lately: the
last two weeks I've been totally occupied with our local Zeltcafe
festival (see  if you're interested), and
tomorrow I'll be leaving for three and a half weeks of vacation in sunny
California.  See you again in fall, then I'll get back to resume working
on all the stuff that is currently in process!


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH] Implement the sync libnetfs stubs.

[Thomas Schwinge]

Hello!

On Sun, Aug 16, 2009 at 08:57:46PM +0200, olafbuddenha...@gmx.net wrote:
> On Tue, Aug 04, 2009 at 12:30:30AM +0200, Thomas Schwinge wrote:
> > Please, please, please, let's try to finally get some of these patches
> > installed before discussing matters to death.
> 
> The real problem is not patches being discussed to death, but rather
> patches that have been reviewed still not getting comitted... Like some
> of Zheng Da's patches for example.

I know about this problem.  Unfortunately, my time is limited.


> The ironic thing here is that once you actually started looking at this
> patch, you did the same kind of "discussing to death" :-)

Touché.

> > So.  Sergiu, if you need specific review of some parts of this patch
> > (or any other patches), then please say so, otherwise please get it
> > installed.
> 
> I'd be very grateful for you not to tell people to ignore my remarks and
> commit broken patches.

Sorry, that never was my intention.  I thought that all issues had been
addressed.  Unfortunately, as we know now, this wasn't the case.

> The origianl patch is wrong and needs to be reverted, and a new one
> comitted once all concerns actually have been addressed.

A follow-up patch has been published (but not yet installed) that makes
netfs_attempt_sync behave as expected, and I think all of us three agree
that this is correct.  I think that this follow-up patch should simply be
installed on top of the one that is in the repository.  No need for
reverting anything; for example, even though the patch in the repository
is not totally correct, it already is an improvement as compared to the
situation before.

Then, what indeed needs discussion is netfs_attempt_syncfs.  Instead of
continuing to speculate, I began documenting the Hurd's RPCs.  Some of
them are documented in the manual, some are in definition or header
files, some can be second-guessed by looking though library sources that
implement them, etc.  Look here (and contribute!):
<http://www.bddebian.com/~hurd-web/hurd/interface/>.  Especially, I added
what I found for file_sync, file_syncfs, and fsys_syncfs.  And the thing
is that I couldn't find a really clear example for the syncfs ones, about
their exact modus operandi.  What one does find is that for some
implementations they indeed foreward syncfs to all child servers, but I'm
missing a rationale why this is better than syncing the root directory.
But, as the forwarding is the technique that is already being applied, I
have no objections for changing unionfs' netfs_attempt_syncfs in this way
-- Sergiu also already posted a patch to do that.  So, then I think all
of us agree, correct?  I suggest: (1.) fix for netfs_attempt_sync is to
be installed on top of the current master; (2.) change for
netfs_attempt_syncfs is to be installed on top of that.


> > I assume that you can confirm in some way (testing, staring at the
> > code, ...) that it does the correct thing.  And should there be any
> > breakage, and we discover it later on, we'll repair it later on.
> 
> The correct functioning of filesystem syncing is very hard to test; and
> any errors will be extremely hard to track down later on. Which makes it
> all the more important that we be able to say with some confidence that
> the code is really doing the right thing.

Actually it is not that hard to test once we have a proper testing
framework.  Unfortunately nobody is working on that so far.  My idea is
to have a remote-controllable (pseudo) translator, which the testing
framework can query, and with which it can interact: create unsynced data
in /foo; file_sync ("/bar"); query /foo -- should still be unsynched;
file_syncfs ("/bar"); query /foo -- should be synced now (as per our
above expectations).


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: unionfs Documentation

[Thomas Schwinge]

Hello!

On Sun, Aug 16, 2009 at 08:06:28PM +0200, olafbuddenha...@gmx.net wrote:
> On Tue, Aug 04, 2009 at 01:00:10AM +0200, Thomas Schwinge wrote:
> > On Fri, Jul 17, 2009 at 05:08:28AM +0200, olafbuddenha...@gmx.net wrote:
> > > On Sat, Jun 13, 2009 at 09:23:23AM +0300, Sergiu Ivanov wrote:
> > > > I'm sending in my attempt to compile a unionfs documentation. It
> > > > is formatted as a stand-alone Texinfo file for now, so that I am
> > > > able to build and view .info files from it.
> [...]
> > > put it in the normal Hurd manual, where the "shadowfs" placeholder
> > > used to be.
> > 
> > I disagree: let's please put it into the unionfs repository and render
> > into a separate info file.  Sergiu, then please remove the shadowfs
> > reference(s) from the GNU Hurd Reference Manual.  unionfs is not an
> > integral core part of the GNU Hurd kernel infrastructure, even is held
> > in a separate repository, and thus doesn't really belong into the
> > GHRM.
> 
> It certainly was *meant* to be, as evidenced both by the mention in the
> design document, and by the placeholder in the manual.

Which design document do you mean?

The placeholder in the manual was added in mid-1998 by Gordon Matzigkeit,
when he overhauled it in various parts.  I wouldn't interpret too much
into him having added a stub node.

> It was a mistake that unionfs was not added to the main repository in
> the first place. This should be fixed, rather than proliferated.

Strong words for a simple technical decision that I have done (that is,
not to keep every software package in one single Git repository).  All
this is only about physical structure, which by no means dictates how all
the packages are eventually to be used in the assembled GNU system.

> > (Of course I'm not saying that unionfs was an unimportant part for the
> > envisoned GNU system.)
> 
> The vision hasn't changed, to the best of my knowledge.

Sure, that's what I was saying.  And you are correct: this is absolutely
relevant for the GNU system.  But here we are talking about the
repositories that hold the sources of some Hurd components, and how to
structure these, and not about the GNU system, which is a distinct (and
different) project (and on hold at the moment, as far as I can tell).
The Hurd components are as service-provider for the GNU system, as they
are for Debian GNU/Hurd.  The GNU system depends on a highly-functional
unionfs, but the Hurd components themselves do not.


> > > > @node Basic Internals
> > > > @chapter Basic Internals
> > > > @cindex internals, node, light node, conflict
> > > > 
> > > > In this chapter a short description of how @command{unionfs} works
> > > > will be done. This description is intended for people who have at
> > > > least a vague idea about GNU/Hurd translator programming.
> > > > 
> > > > Note that what follows is an overview of the basic functionality.
> > > 
> > > I don't think the introduction paragraphs are necessary.
> > 
> > Without having at all looked at them so far, why remove them?
> 
> A meaningful title, like "implementation", is sufficient. You don't need
> two paragraphs to explain what this is. People reading the manual aren't
> morons. Bloating the text with useless fluff only makes it harder to
> read.

I now had a look at this chapter.  This ``useless fluff'' is a
description about how this unionfs implementation works internatlly.  I
still don't see why you wouldn't want to publish this information in the
manual?  Or are we somehow talking past each other?


Regards,
 Thomas


signature.asc
Description: Digital signature

Socket definitions in glibc

[Thomas Schwinge]

Hello!

There are a few programs that depend on SOL_IP being defined (instead of
IPPROTO_IP).  For Linux this is defined (to 0; as is IPPROTO_IP) in
glibc's sysdeps/unix/sysv/linux/bits/in.h, but not in the generic one at
bits/in.h, which we use.  Also, some of the values in there are defined
to different values than in the Linux file.  Shouldn't we harmonize these
files (and similar ones), or are there real reasons for defining these
constants to differing values?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH] Don't stop when syncing a directory returns an error.

[Thomas Schwinge]

Hello!

On Fri, Aug 14, 2009 at 10:26:10PM +0300, Sergiu Ivanov wrote:
> On Fri, Aug 14, 2009 at 08:26:18PM +0200, Thomas Schwinge wrote:
> > On Fri, Aug 14, 2009 at 07:41:08PM +0300, Sergiu Ivanov wrote:
> > > On Fri, Aug 14, 2009 at 05:18:59PM +0200, Thomas Schwinge wrote:
> > >node_ulfs_iterate_unlocked (np)
> > >{
> > > +error_t err;
> > > +
> > >  /* Get the information about the current filesystem.  */
> > >  err = ulfs_get_num (i, &ulfs);
> > >  if (err)
> > > -  break;
> > > +  {
> > > + final_err = err;
> > > + continue;
> > > +  }

By the way: this continue statement would have been erroneous
nevertheless, as we'd miss the increment of i in this case.


> > Looking at ulfs_get_num's implementation I wonder whether we should
> > actually report its failing back to the invoker of netfs_attempt_sync?
> > Wouldn't ulfs_get_num failing be a sign of corrupted internal state?  So,
> > would either a silent continue or even a assert (err == 0) be more
> > appropriate here?
> 
> You are right -- if a node contains more node_ulfs entries than there
> are registered in ulfs_chain, then something has gone seriously
> corrupted.  However, I have a question, which is related to
> consistency (again *sigh*): ulfs_get_num is invoked in two places
> only: in netfs_attempt_sync and in node_init_root (node.c:533 in my
> code version).  In node_init_root the return value of ulfs_get_num is
> checked in an if statement.  Is it alright to check this value via an
> assert in netfs_attempt_sync?  Or should I change the handling of the
> return value in node_init_root instead?

I don't really know the unionfs code, but if these two structures are
always meant to be kept synchronized (which I don't really know, so you'd
have to verify that -- or unify these structures, which was the long-term
plan, isn't it?), then a fatal error (assert) is OK.

But then, node_init_root raises other issues: what is the err check at
the beginning of node_ulfs_iterate_unlocked good for?


> --- a/netfs.c
> +++ b/netfs.c

OK for master, I'd say.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH] Don't stop when syncing a directory returns an error.

[Thomas Schwinge]

Hello!

On Fri, Aug 14, 2009 at 07:41:08PM +0300, Sergiu Ivanov wrote:
> On Fri, Aug 14, 2009 at 05:18:59PM +0200, Thomas Schwinge wrote:
> > Why did you send it in a separate message by the way?  Anyways, I'll post
> > my few comments in here.
> 
> I just didn't think about sending it in one message.  (I hope this one
> is formatted properly).

Jup, arrived just fine, and I was able to import it into my repository
with a simple ``git am < [file]''.  Doing it this way, the advantage is
that all what belongs together can easily be viewed together (that is,
the discussion and the patch), without having to juggle with two emails
in parallel.

> > | +  /* The index of the currently analyzed filesystem.  */
> > | +  int i = 0;
> > | +
> > | +  /* The information about the currently analyzed filesystem.  */
> > | +  ulfs_t * ulfs;
> > | +
> > | +  mutex_lock (&ulfs_lock);
> > | +
> > | +  /* Sync every writable directory associated with `np`.
> > | +
> > | + TODO: Rewrite this after having modified ulfs.c and node.c to
> > | + store the paths and ports to the underlying directories in one
> > | + place, because now iterating over both lists looks ugly.  */
> > | +  node_ulfs_iterate_unlocked (np)
> > 
> > Having had a look at ulfs.h again: why didn't you use ulfs_iterate and
> > have that one handle the locking?

> > Also, do you really have to define ulfs -- both ulfs_iterate and
> > node_ulfs_iterate_unlocked do that already, isn't it?

Jeez, sorry, my fault: I was looking at ulfs.h's ulfs_iterate_* stuff
instead of node.h's node_ulfs_iterate_* that you (correctly) use.

> > | +if ((node_ulfs->port != MACH_PORT_NULL)
> > 
> > What is the rationale for this check -- do we really need it, or won't
> > calling file_sync ([invalid port], ...) already do the right thing
> > (nothing) and report back a suitable error value?  Perhaps I'm missing
> > something.
> 
> Note that netfs_attempt_sync is meant to work okay on *every* node
> handled by unionfs.  This means that the situation when one of the
> entries in the list of ports is MACH_PORT_NULL is completely normal
> and valid (consider the situation when a certain directory is only
> present in one of the merged filesystems).  I'm strongly inclined to
> think that returning an error in a normal situation is not we would
> like to have.

Alright, I see.  Perhaps that warrants a small comment in front of this
check, something like: ``It is perfectly valid that node NP is not
present on every underlying file system.''

>node_ulfs_iterate_unlocked (np)
>{
> +error_t err;
> +
>  /* Get the information about the current filesystem.  */
>  err = ulfs_get_num (i, &ulfs);
>  if (err)
> -  break;
> +  {
> + final_err = err;
> + continue;
> +  }

Looking at ulfs_get_num's implementation I wonder whether we should
actually report its failing back to the invoker of netfs_attempt_sync?
Wouldn't ulfs_get_num failing be a sign of corrupted internal state?  So,
would either a silent continue or even a assert (err == 0) be more
appropriate here?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH] Implement the sync libnetfs stubs.

[Thomas Schwinge]

Hello!

On Fri, Aug 14, 2009 at 04:36:45PM +0300, Sergiu Ivanov wrote:
> On Tue, Aug 11, 2009 at 11:42:41AM +0200, Thomas Schwinge wrote:
> > This comment is based on the version of the patch that you installed into
> > master.  (By the way: this commit didn't show up on commit-hurd; I'll
> > have a look at that.)
> 
> Is it my duty to look after my commits showing up on commit-hurd?  If
> so, I'm sorry and please tell me how to do that, because I don't even
> know what ``commit-hurd'' is :-(

Heh, no problem: that's simply the commit-hurd mailing list where all
commits (should) show up.


> I agree with your statement about always syncing all nodes and, IIRC,
> antrik has already mentioned that, and I have forgotten about that :-(
> 
> I'm rather inclined to implement the ``last one wins'' approach, since
> it really is simpler and more common.  Please, take a look at my new
> patch and tell me if it's acceptable.

Why did you send it in a separate message by the way?  Anyways, I'll post
my few comments in here.

| --- a/netfs.c
| +++ b/netfs.c
| @@ -282,7 +283,45 @@ error_t
|  netfs_attempt_sync (struct iouser *cred, struct node *np,
|   int wait)
|  {
| -  return EOPNOTSUPP;

Your new patch should be based on what is in unionfs' master branch at
the moment, that is, it will be committed on top of the previously
committed patch.

| +  error_t err = 0;

Generally, move local variables into the innermost frame where they are
needed.  Here, move err into the node_ulfs_iterate_unlocked loop.

| +  /* A pessimistic combination (failure wins) of the results of all
| + calls to file_sync.  */
| +  error_t combined_err = 0;

``combination of'' sounds like ``combined_err |= ...'' (which is wrong,
of course).  Perhaps use the name final_err, and adjust the comment
accordingly, perhaps something like: ``The error we're finally going to
report back: the last failure wins.''

| +  /* The index of the currently analyzed filesystem.  */
| +  int i = 0;
| +
| +  /* The information about the currently analyzed filesystem.  */
| +  ulfs_t * ulfs;
| +
| +  mutex_lock (&ulfs_lock);
| +
| +  /* Sync every writable directory associated with `np`.
| +
| + TODO: Rewrite this after having modified ulfs.c and node.c to
| + store the paths and ports to the underlying directories in one
| + place, because now iterating over both lists looks ugly.  */
| +  node_ulfs_iterate_unlocked (np)

Having had a look at ulfs.h again: why didn't you use ulfs_iterate and
have that one handle the locking?  Also, do you really have to define
ulfs -- both ulfs_iterate and node_ulfs_iterate_unlocked do that already,
isn't it?

| +  {
| +/* Get the information about the current filesystem.  */
| +err = ulfs_get_num (i, &ulfs);
| +if (err)
| +  combined_err = err;
| +
| +if ((node_ulfs->port != MACH_PORT_NULL)

What is the rationale for this check -- do we really need it, or won't
calling file_sync ([invalid port], ...) already do the right thing
(nothing) and report back a suitable error value?  Perhaps I'm missing
something.

| + && (ulfs->flags & FLAG_ULFS_WRITABLE))

If you got err != 0 you probably shouldn't proceed here to dereference
ulfs, and instead continue with the next ulfs (as I had it in my
suggestion).

| +  {
| + err = file_sync (node_ulfs->port, wait, 0);
| + if (err)
| +   combined_err = err;
| +  }
| +
| +++i;
| +  }
| +
| +  mutex_unlock (&ulfs_lock);
| +  return combined_err;


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Further Git repositories?

[Thomas Schwinge]

Hello!

On Sun, Aug 09, 2009 at 06:20:41PM +0200, olafbuddenha...@gmx.net wrote:
> On Sun, Aug 02, 2009 at 02:05:30PM +0200, Thomas Schwinge wrote:
> > Now, for publishing last years' GSoC projects etc., we'd need another
> > bunch of 'em: for the projects that create new ``modules'' (procfs,
> > LISP stuff, libchannel, eth-filter, eth-multiplexer, proc_proxy,
> > nsmux, ...) -- I'd like to have theses in separate repositories
> > instead of muddling all of them into the Hurd proper repository.
> 
> Why? Who exactly would would benefit from that?

We can't keep the whole world in one repository.  (Actually, we could,
but we don't want to.)

> > But instead of creating a full-fledged (separate) Git repository for
> > each of the projects, I propose to have a ``dump'' repository in which
> > there are several independent branches (`lisp', `channel', `eth-*',
> > ...) containing the respective files.
> 
> Sounds like a mess. What is the advantage over branches in the main
> repository?

Somewhere the line has to be drawn between what is considered part of the
official Hurd distribution, and stuff that is currently in the incubator.
In my book, the collect-'em-all hurd/hurd.git repository is not the way
to go for the future -- that's why I don't intend to add new modules to
it, but instead use separate repositories per module.  (We discussed this
already.)  Branches for working on existing modules are another issue:
these are fine to live in hurd/hurd.git.

> Ideally, users should be able to create their own repositories, like on
> freedesktop.org. I don't think Savannah supports that though?... :-(

Correct, Savannah doesn't support that -- and note that this is exactly
what I meant the hurd/dump.git repository to be used for.

Of course, if this scheme turns out to be unwieldy, we can simply throw
it away again -- thanks to the Git design no information will be lost.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: ioperm and iopl in gnumach

[Thomas Schwinge]

Hello!

On Sun, Aug 09, 2009 at 06:48:05PM +0200, olafbuddenha...@gmx.net wrote:
> On Mon, Aug 03, 2009 at 07:12:22PM +0200, Thomas Schwinge wrote:
> > There are two ways to use it: either the GNU Mach RPCs
> > i386_io_perm_create and i386_io_perm_modify (see
> > [gnumach]/i386/include/mach/i386/mach_i386.defs) can directly be used,
> > or the more standard (at least on x86) glibc ioperm function (see
> > [glibc]/sysdeps/mach/hurd/i386/ioperm.c), which makes use of the
> > former two RPCs.
> > 
> > Note that you currently have to be the root user to make use of all
> > this. This is what the envisioned (not yet existing, but which we've
> > once been chatting about) ioperm server, sitting on /servers/ioperm,
> > is meant to change.
> 
> The ironic thing is that with the iopl device, it was already possible
> without any special server...

But iopl is a all-or-nothing-like thing (all I/O ports), and also is for
root only (the device_master port is needed).

> I still wonder why the extra RPCs are considered better.

Because they use the capability system for allowing access to arbitrarily
restricted ranges of I/O ports; these capabilities can then be passed to
arbitrary non-root clients.  What the ioperm server will do is allowing
non-root clients to request access to I/O ports, and then had out these
rights according to some policy.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH] Fix the ``--priority'' option handling in netfs_append_args.

[Thomas Schwinge]

Hello!

On Tue, Aug 11, 2009 at 12:03:59AM +0300, Sergiu Ivanov wrote:
> * netfs.c (netfs_append_args): Change the format specification
> to ``%d''.

OK for master, but please use ``* netfs.c (netfs_append_args) :
Change the...'' to indicate that only the priority value handling was
affected.


> I've been looking at this gcc warning for about a year, but I though
> it was some secret plan of the creator of unionfs, until I ran into
> some memory corruption due to this bug.

Yo, fixing compiler warnings is always a good idea.  Not only in unionfs
code.  At some point we may consider -Werror.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH] Implement the sync libnetfs stubs.

[Thomas Schwinge]

Hello!

This comment is based on the version of the patch that you installed into
master.  (By the way: this commit didn't show up on commit-hurd; I'll
have a look at that.)


On Sun, Jul 12, 2009 at 10:50:07PM +0300, Sergiu Ivanov wrote:
> On Sat, Jul 11, 2009 at 03:56:02AM +0200, olafbuddenha...@gmx.net wrote:
> > On Wed, Jul 08, 2009 at 10:30:41PM +0300, Sergiu Ivanov wrote:
> > > +if (err)
> > > +  break;
> > 
> > I wonder whether it wouldn't perhaps be better to continue in spite of
> > errors?...
> 
> Yes, it's definitely better to do it like that.  And also, I think I
> forgot to add the check for the validity of the port corresponding to
> the current filesystem :-(
>  
> > > +
> > > +if (ulfs->flags & FLAG_ULFS_WRITABLE)
> > > +  {
> > > + err = file_sync (node_ulfs->port, wait, 0);
> > > + if (err)
> > > +   break;
> > > +  }
> > > +
> > > +++i;
> > > +  }

I agree that syncing the other nodes should continue even if any of the
nodes fail to do so.  Or is there a reason not to do it like that?  My
idea is that all nodes are tought to receive the sync command in
parallel, and then all their return values are collected and combined in
a passimistic manner (that is, failure wins).  If you agree, then please
change this code accordingly.  Like this perhaps (totally untested)?

node_ulfs_iterate_unlocked (np)
{
  error_t err_l = ulfs_get_num (i, &ulfs);
  if (! err_l
  && (ulfs->flags & FLAG_ULFS_WRITABLE))
{
  err_l = file_sync (node_ulfs->port, wait, 0);
  /* We can only report back a single error value; the first one
 wins.  */
  if (! err)
err = err_l;
}
  ++i;
}


Regards,
 Thomas


signature.asc
Description: Digital signature

[bug #27184] Memory leak in procfs

[Thomas Schwinge]

Update of bug #27184 (project hurd):

  Status:None => Confirmed  
 Reproducibility:None => Every Time 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[spaes...@gmail.com: Sustainable development]

[Thomas Schwinge]

Hello Steve!

Please use  or  for such discussions;
see .


Regards,
 Thomas
--- Begin Message ---
Hi,
I am new to the hurd and more specifically the L4-hurd/viengoos microkernel.

I would like to (suggest) form(ing) a co-operative that makes use of what I
call a 'dev comp' software licence that has for intent to compensate the
production/development costs of the software, that is, sustain to a
reasonable/fair quality of life the developers of the software. This
includes all involved eg: project managers, package administrators,
developers, designers, graphic artists, translators, document authors,
project server maintainers etc.. etc...
in a manner that is consistant with the product delivered and not related to
'sub venues' such as advertising etc... The idea is in fact grandiose as I
would like to see and be a part of a global crew of IT personel that would
replace the current billion dollar corp IT crew.  The precept is that a well
run coop can offer the same or better quality products at a better price and
with right intent towards it's members/clients than the major sotware
providers the coop is intended to replace.

I am willing to go as far as assessing the overall IT market,
determining the greed elements that would be removed(hence providing
the better cost) and developing a proposal that would be presented to
potential supporters (customers/members) in order to secure funds for
sustaining the cooperative (that is, the people who would develop the gnu
hurd and it's applications, sustain/maintain it etc...)

Personally I believe it's time to move along these lines. Either with the
Hurd, or with GnuLinux (or perhaps both..) as in my view people
are to be receive from the community/society unto which they provide. In
short my intention is for people to receive compensation for their
development efforts.

I would like to know where the original Hurd developers stand in this
regard.

Steve Paesani
--- End Message ---


signature.asc
Description: Digital signature

Re: ioperm and iopl in gnumach

[Thomas Schwinge]

Hello!

On Tue, Aug 04, 2009 at 04:15:10PM +0800, Da Zheng wrote:
> I am porting the keyboard driver to the user space and here is my problem:
> The driver reads the keyboard status from the port 0x64, and it seems
> OK. It doesn't work when the driver tries to write the command to the
> port 0x64. The whole process dies.

That obviously shouldn't happen, and thus it's the first thing to figure
out why it dies.  Is this already in the context of a translator, or a
stand-alone process?  If the former, then see
 for two
different approaches.  But: doing this as a simple process for now will
be easier.


> (the port 0x64 is used for both read
> the status and writing the command.)
> I have used ioperm to acquire the access to the port 0x64 before
> accessing the port (K_STATUS is 0x64).
>   if (ioperm (K_STATUS, 1, 1) < 0)
> return FALSE;
> I use the root user to run the keyboard driver. I don't know what the
> possible reason is:-(

What is your apporach?  You disabled the GNU Mach kernel keyboard driver?
And then, for now, use polling (in a busy-waiting loop) instead of IRQ
handling?   seems to
contain useful instructions.


Regards,
 Thomas


signature.asc
Description: Digital signature

glibc repository for Hurd matters on sourceware or Savannah?

[Thomas Schwinge]

Hello!

We'd like to publish a version of the glibc Git repository containing
various Hurd-related branches (but not only; also general cleanups and
enhancements that we're doing along the way).  Shall we publish that on
Savannah, as hurd/glibc.git, or on sourceware, next to the master glibc
sources?

I already have a sourceware account, and the only other committer (for
now) would be Samuel Thibault.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH 2/3] Add the code for starting up the mountee

[Thomas Schwinge]

Hello!

On Mon, Aug 03, 2009 at 08:20:19PM +0300, Sergiu Ivanov wrote:
> On Sat, Jul 18, 2009 at 06:33:11AM +0200, olafbuddenha...@gmx.net wrote:
> > On Thu, Jul 16, 2009 at 01:04:06PM +0300, Sergiu Ivanov wrote:
> > > +/* Starts the mountee (given by `argz` and `argz_len`), sets it on
> > > +   node `np` and opens a port `port` to with `flags`.  `port` is not
> > > +   modified when an error occurs.  */
> > > +error_t
> > > +start_mountee (node_t * np, char * argz, size_t argz_len, int flags,
> > > +mach_port_t * port)
> > 
> >  [...]
> > And I still don't like "np".
> 
> I looked through unionfs again and I can confirm that it uses ``np''
> for ``node pointer'' everywhere.  Should I break the convention?  I do
> agree that this isn't a very intuitive name, but I'm not sure what to
> choose: a better name or consistency.

Consistency.  `np' is used throughout all of the Hurd code, and also in
the reference manual.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: unionfs Documentation

[Thomas Schwinge]

Hello!

On Fri, Jul 17, 2009 at 05:08:28AM +0200, olafbuddenha...@gmx.net wrote:
> On Sat, Jun 13, 2009 at 09:23:23AM +0300, Sergiu Ivanov wrote:
> > I'm sending in my attempt to compile a unionfs documentation. It is
> > formatted as a stand-alone Texinfo file for now, so that I am able to
> > build and view .info files from it.
> 
> I don't understand -- why can't you just build it as part of the Hurd
> manual?

> do it as I asked
> you from the beginning: put it in the normal Hurd manual, where the
> "shadowfs" placeholder used to be.

I disagree: let's please put it into the unionfs repository and render
into a separate info file.  Sergiu, then please remove the shadowfs
reference(s) from the GNU Hurd Reference Manual.  unionfs is not an
integral core part of the GNU Hurd kernel infrastructure, even is held in
a separate repository, and thus doesn't really belong into the GHRM.  (Of
course I'm not saying that unionfs was an unimportant part for the
envisoned GNU system.)


Sergiu, please address Olaf's valid comments as much as you want, put the
unaddressed ones into the file (commented-out, like: ``Olaf Buddenhagen:
rather say s.th. like ...''), and put it into the unionfs repository.
Don't spend too much time on the build infrastructure; I'll take care of
that as soon as I do the overall Automake dance.


> > @item -u
> > @itemx --underlying
> > Add the underlying file system to the list of union mounted file
> > systems.
> > 
> > @item -w
> > @itemx --writable
> > Specify the following file system as writable. This makes it possible
> > to create new nodes in the specified file system.
> 
> Are these two really only possible on startup? Seems like a major
> limitation, which should be fixed...

If yes, then this is worth either a item in the Savannah task list, a new
*open issue* in the web pages, or an entry in a TODO file in the unionfs
repository.


> > @node Basic Internals
> > @chapter Basic Internals
> > @cindex internals, node, light node, conflict
> > 
> > In this chapter a short description of how @command{unionfs} works
> > will be done. This description is intended for people who have at
> > least a vague idea about GNU/Hurd translator programming.
> > 
> > Note that what follows is an overview of the basic functionality.
> 
> I don't think the introduction paragraphs are necessary.

Without having at all looked at them so far, why remove them?


> > @item
> > If there's a name conflict in underlying file systems between
> > directories (or between files), and the user has no permission to
> > delete all the entries -- e.g. one hidden entry is read-only -- then
> > he will get an @samp{EPERM} even if permissions seems ok. This is a
> > structural bug (there's no clean way to solve it), and should be
> > fixed.
> 
> I think both of these problems are actually a result of handling file
> deletion fundamentally wrong; or perhaps even handling writable entries
> wrong in general. It's probably never right to write to more than one
> directory at a time.
> 
> This is a non-trivial problem. Other unionfs implementations probably
> spent considerable time figuring out how to do it best. I entreated
> Gianluca to check what over implementations do, instead of trying to
> reinvent the wheel -- but he wouldn't listen :-(

This for sure has been ``solved'' (in one way or another) by now in other
designs and implementations.  Some weeks ago I added a few links to some
Linux unionfs pages to our unionfs web page.  Someone could go looking
there.


> In general, there are various places where I believe I could improve the
> wording -- but instead of explaining each seperately, I think it's
> easier if I just post a followup patch

Please do so, yes!


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH] Implement the sync libnetfs stubs.

[Thomas Schwinge]

Hello!

Please, please, please, let's try to finally get some of these patches
installed before discussing matters to death.  Of course, discussion is
very important -- and many thanks to Olaf et al. for doing all these
reviews! -- but I'm totally losing track of all these emails and huge
discussion threads and proposals and misunderstandings and clarifications
of them and further possibilities.


On Mon, Aug 03, 2009 at 09:19:17PM +0300, Sergiu Ivanov wrote:
> On Sat, Jul 18, 2009 at 08:08:20AM +0200, olafbuddenha...@gmx.net wrote:
> > On Sun, Jul 12, 2009 at 10:50:07PM +0300, Sergiu Ivanov wrote:
> > > On Sat, Jul 11, 2009 at 03:56:02AM +0200, olafbuddenha...@gmx.net wrote:
> > > > On Wed, Jul 08, 2009 at 10:30:41PM +0300, Sergiu Ivanov wrote:
> > So there is no other way to associate the two lists? This is ugly
> > indeed. In this case, I think it would be better not to use the iterator
> > at all -- what you did here looks really hackish, and it breaks the
> > iterator paradigm anyways...
> 
> Yeah, true, it breaks the paradigm.  However, I actually borrowed this
> piece of code from node_init_root (node.c), so this is the style used
> in unionfs.  Should I forget about consistency in this case, what do
> you think?

Go for consistency, and add something like ``TODO: this should be
rewritten like this: ..., because ...''.  Olaf, you're of course also
very much encouraged to add such comments in code that you have reviewed.
Then it is written down, right next to the code, and doesn't have to be
investiagted again and again later on.


> > > > > @@ -290,7 +322,10 @@ netfs_attempt_sync (struct iouser *cred, struct 
> > > > > node *np,
> > > > >  error_t
> > > > >  netfs_attempt_syncfs (struct iouser *cred, int wait)
> > > > >  {
> > > > > -  return 0;
> > > > > +  /* The complete list of ports to the merged filesystems is
> > > > > + maintained in the root node of unionfs, so if we sync it, we 
> > > > > sync
> > > > > + every single merged directory.  */
> > > > > +  return netfs_attempt_sync (cred, netfs_root_node, wait);
> > > > 
> > > > I'm don't think this is really the right approach. Why not forward the
> > > > syncfs to all unioned filesystems?

Why would that be the wrong approach?

> Ah, so you mean forwarding syncfs to all unioned *directories*?
> Sorry, I thought your were talking about doing fsys_syncfs on all
> unioned *filesystems* :-)
> 
> In this case, I'd tell you that the current implementation does
> exactly what you are talking about: sends file_sync to all writeable
> directories maintained by unionfs :-) You see, the list of *ports* to
> the directories is stored in the root node of unionfs (only), so doing
> netfs_attempt_sync on netfs_root_node is a pretty natural choice,
> IMHO.  The ULFS list (maintained in ulfs.[ch]) is actually only a list
> of paths and attributes.

Yes, I think that this is exactly the right thing to do: sync everything
that is reachable from the root node.

> > > OTOH, I'm not sure whether syncing the whole filesystem is that very
> > > good, because in this way we lose the specificity: it's very probable
> > > that such syncing will employ a larger number of directories than just
> > > those merged by unionfs.
> > 
> > So? Syncing more than necessary is never a problem... (Except for
> > performance perhaps.)
> >
> > Syncing is safety measure -- it can be too little, but it can never be
> > too much :-)

But why do that in the first place?  Or am I misunderstanding something?


So.  Sergiu, if you need specific review of some parts of this patch (or
any other patches), then please say so, otherwise please get it
installed.  I assume that you can confirm in some way (testing, staring
at the code, ...) that it does the correct thing.  And should there be
any breakage, and we discover it later on, we'll repair it later on.  We
can't address or even fix all potential design or implementation
odditites of the unionfs code in this single discussion thread.

I hope that these words of mine aren't seen as an affront against the
lots of time that you people invest in discussing patches, writing
emails, etc. -- which is absolutely not my intention! -- but, yeah, let's
get something DONE!  :-)


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: ioperm and iopl in gnumach

[Thomas Schwinge]

Hello!

On Mon, Aug 03, 2009 at 08:23:49PM +0800, Da Zheng wrote:
> There is some code in gnumach that implements ioperm, but it doesn't
> work. I think tschwinge has told me that.  But could anyone tell why it
> doesn't work, how much work is left and when it will work?

No.  ioperm is expected to work just fine, so please tell us if there are
problems with it.  There are two ways to use it: either the GNU Mach RPCs
i386_io_perm_create and i386_io_perm_modify (see
[gnumach]/i386/include/mach/i386/mach_i386.defs) can directly be used, or
the more standard (at least on x86) glibc ioperm function (see
[glibc]/sysdeps/mach/hurd/i386/ioperm.c), which makes use of the former
two RPCs.

Note that you currently have to be the root user to make use of all this.
This is what the envisioned (not yet existing, but which we've once been
chatting about) ioperm server, sitting on /servers/ioperm, is meant to
change.


> gnumach from the debian repository supports iopl. This gnumach provides
> an iopl device and I find that this device only supports device_map
> when I read the code. but I don't know how to use this device. Does the
> device provide the same function as the iopl system call in Linux?
> Could anyone give me an example showing how to change the I/O privilege
> level with this device?

I think that you're mixing up two things.  First, you shouldn't need to
use the iopl function as it exists, for example, on Linux on x86:
instead, on Mach, you can use the interface I spoke about above for that.
Second, what this iopl Mach device is indeed being used for, is to access
arbitrary device memory by using device_map, as you found out already.

What problem exactly are you trying to solve?


Regards,
 Thomas


signature.asc
Description: Digital signature

Further Git repositories?

[Thomas Schwinge]

Hello!

We already have a number of Git repositories, see
.

Now, for publishing last years' GSoC projects etc., we'd need another
bunch of 'em: for the projects that create new ``modules'' (procfs, LISP
stuff, libchannel, eth-filter, eth-multiplexer, proc_proxy, nsmux, ...)
-- I'd like to have theses in separate repositories instead of muddling
all of them into the Hurd proper repository.

But instead of creating a full-fledged (separate) Git repository for each
of the projects, I propose to have a ``dump'' repository in which there
are several independent branches (`lisp', `channel', `eth-*', ...)
containing the respective files.  On these branches, the projects can
evolve until they ``are given birth'': until they are published in a
stand-alone repository.  This is clearly the right thing to do for
projects where it is not yet certain if they'll persist at all
(proc_proxy, for example); others will be in their top-level repositories
right now: procfs for one example.  As a sequel, this dump repository is
then also meant for developers to publish new stuff they're working on,
etc. (unless that is based on other Hurd code, for example, and thus is
to be published as a branch of the Hurd repository).

Your thoughts?


Regards,
 Thomas


signature.asc
Description: Digital signature

[patch #6851] fix a bug in BPF

[Thomas Schwinge]

Follow-up Comment #3, patch #6851 (project hurd):

> The packet delivered from gnumach should have the packet header. NPF
returns the packet_header and pfinet always assumes that the packet from
gnumach has the packet_header.

OK, I understand that, and it is fine, but is there a specific reason to send
package_header to user-space?  (That is,  if it's *not* required, then we
should perhaps change pfinet and net_filter to not handle it?)  If I
understand the code correctly, packets that go from pfinet to the kernel to be
sent out, *do not* contain the packet_header, but packets that go from the
kernel to pfinet *do* contain the packet_header.  Why this asymmetry?  Perhaps
I fail to understand what this packet_header is actually good for.  (All that
is unrelated to this bug report, of course, but while we're at it...)


> For your first question, the return value of net_do_filter is boolean,
i.e., it can only be passed or not passed, but bpf_do_filter returns the size
of the data that passes the filter.

OK, I see.  The code could be written in a way that this is more obvious... 
(15 years old code, I know.)

My question also was whether net_do_filter should be changed to not handle
the packet_header-part of the packet, as that is not related to the actual
packet data (as I understand it), and thus should not be involved in deciding
whether to allow or deny a given packet.  (That's also unrelated to this bug
report.)


Given the same instructions as in bug #20612, please install this patch. 
(And then we can think about the other issues I'm talking above.)


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #20612] rpctrace: heisenbug

[Thomas Schwinge]

Update of bug #20612 (project hurd):

  Status:None => Works For Me   
 Assigned to:None => zhengda

___

Follow-up Comment #2:

Thanks!  I have briefly tested this: the patch does the right thing in the
failure case, and let's hope that it doesn't break anything else.

Please install it in the master branch -- instructions are on
[http://www.bddebian.com:/~hurd-web/rules/source_repositories/], please
read that page carefully before pushing to Savannah, or ask me if you need
help.  Even better: first publish it in a throw-away repository on flubber, or
in a private branch on Savannah, until we get all that new Git stuff going
correctly.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[patch #6851] fix a bug in BPF

[Thomas Schwinge]

Follow-up Comment #1, patch #6851 (project hurd):

I had a look at this.  In general, the patch seems to be correct.  Two
questions: Why isn't the same adjustment being done for net_do_filter, or why
doesn't it have to be done?  Why do we (have to) return the packet_header to
user-space?


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: Getting libpthread working again

[Thomas Schwinge]

Hello!

On Tue, Jun 23, 2009 at 12:05:42AM +0200, I wrote:
> On Sun, Apr 12, 2009 at 05:32:12PM +0200, I wrote:
> > When linking the pthread tests against a libpthread built (with Samuel's
> > TLS patches) from CVS HEAD (or any of the Viengoos branches, for that
> > matter) I always get this:
> > 
> > $ ./test-1
> > test-1: ../../HEAD/libpthread/sysdeps/mach/hurd/i386/pt-setup.c:103:
> > __pthread_setup: Unexpected error: (ipc/send) invalid destination
> > port.
> > Aborted
> > $ ./test-1-static 
> > test-1-static:
> > ../../HEAD/libpthread/sysdeps/mach/hurd/i386/pt-setup.c:103:
> > __pthread_setup: Unexpected error: (ipc/send) invalid destination
> > port.
> > Aborted
> > 
> > I tracked this down to the 2008-08-16 __pthread_free_threads change --
> > apparently nobody ever tried to use the CVS HEAD libpthread since then?
> > (We absolutely need to come up with better automated testing methods...)
> > The pthread library was now trying to reuse kernel threads that have been
> > invalidated before.  I created the attached patch to get that fixed again
> > (plus the malloc to calloc patch needed for CVS HEAD).  Neal, is this
> > approach correct?  I have stolen the thread_suspend thing from Viengoos
> > -- is that correct for Mach as well?  (And the while (1) loop is
> > superfluous for all variants, isn't it?)  At least, this way all of the
> > libpthread test suite programs complete to satisfaction, both dynamically
> > and statically linked.
> 
> I now put my preliminary (unfinished) patch into the
> master-fix_have_kernel_resources branch.  The commit currently also has
> some additional comments by Neal in the commit message (for the next
> person to work on it).

For convenience, here a Neal's comments again:

 do you want a reply on the libpthread one inline?
 the short answer is: yes, that's a bug
 unfortunately, your fix is not enough
 the predicate controls two resources: the wakeup port and the
  thread itself
 Oh, right, I see.
 also, there may be a race:
 set the predicate to free, then kill the thread
 that's not so good
 so a proper solution requires a bit more thought
 I think I wondered about that as well.  But isn't there the
  same problem with Viengoos?
 it is difficult as cleanly committing suicide is hard :-)
 could be
 on viengoos, I don't actually deallocate the thread in
  pt-thread-halt.c
 I just call suspend
 the thread is only deallocated in pt-thread-dealloc.c

I had a look at this issue again, but didn't get to a state where I'd say
that I really understand how thread->have_kernel_resources is to be
handled correctly.  Neal, can you help?

Is it in the first place correct to call __thread_terminate in
__pthread_thread_halt, or should this be __thread_suspend (followed by
__thread_abort?)?  (And where should the kernel thread then be destroyed
eventually?)  In the Viengoos case you call __pthread_thread_halt from
__pthread_thread_dealloc, for Mach this is not done, and only the wakeup
port is being destroyed in there.  And so on; I'm confused.  What are
these allocation and deallocation functions exactly meant to do these
days?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: News...

[Thomas Schwinge]

Hello!

On Thu, Jul 23, 2009 at 10:37:33AM +0200, Arne Babenhauserheide wrote:
> Am Mittwoch, 22. Juli 2009 10:38:31 schrieb Thomas Schwinge:
> > Thanks for doing that! -- glad to see that you're beginning to follow my
> > habit of putting contenful emails into the web pages!  (But please also
> > get used to put into the comming message a note what the source is:
> > message ID, author, date, for example.)
> 
> I'll try to remember it. 
> 
> Actually I picked up the habit of putting my and Olafs useful mails into the 
> wiki weblog :) 

Well, in this case the content actually was mostly from an email of mine,
I'd say.  :-)

> > > http://www.bddebian.com/~hurd-web/community/weblogs/ArneBab/howto-news-mo
> > >nth- of-the-hurd/
> >
> > I'd even suggest to move that page to a more prominent page:
> > contributing/web_pages/news, perhaps?
> 
> Maybe we can postpone that a bit, till we have some experience with the news. 
> Moving the page is easy - I love DVCS CMS's (DVCMS? - merry buzzword 
> inventing ;) )
> 
> Currently that page serves as reminder for me, how to work on the news ;) 
> That way I don't get caught in git usage errors every time :) 

Well, I have done some enhancement to it, the usage policy is clear
enough (and for everyone to follow, not just us two), and I think that
the page already is ``good enough'' to be part of the main set of pages,
so I moved it already now:
<http://www.bddebian.com:/~hurd-web/contributing/web_pages/news/>.


Regards,
 Thomas


signature.asc
Description: Digital signature

Someone interested in writing a regression test suite for Hurd components?

[Thomas Schwinge]

Hello!

As we all know, the Hurd lacks a regression test suite.

Ben once began writing a test suite for libpipe, which can be retrieved
from his homepage.  I intend to integrate this into the Hurd build.

Now, Zheng Da has been submitting patches to fix bugs in rpctrace and
extend it in general.

Before installing these patches, I'd like to have a basic regression test
suite set-up that gives us some confidence that they don't in turn cause
breakage on other parts / uses of rpctrace.

For example, we already do have a few examples of code that works
stand-alone, but not when run by rpctrace, and we have patches to fix
that.

Now, testing rpctrace is not like testing libpipe, where you simply come
up with some testing programs that use the libpipe C API and do some
consistency checks alongside.  Testing rpctrace means running it against
testee programs, and then parse rpctrace's output and compare that
against a to-be-expected version.  Some fuzzy comparisions will be
needed, as PIDs and all sort of other things will vary between two runs
of the same testee.  Also some machinery to take care of hanging rpctrace
processes will be needed.

I guess that instead of starting to write shell scripts etc. for handling
all this, something like expect, , or DejaGnu,
, should instead be used for this
task, but I have no experience with these.  Is someone interested in
working on that?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Want to Contribute

[Thomas Schwinge]

Hello!

On Sun, Jul 19, 2009 at 12:01:00AM +0600, Salahuddin Pasha wrote:
>I would like to contribute in GNU/HURD.

Thanks for your interest!


> - What areas are you interested in contributing to?

For the curious ones: these questions are from the questionnaire I once
put up at
.  If
you have suggestions or ideas about how to improve that one, please
simply change or add them.


> I would like to contribute in "Porting Packages", I have previous  
> experience of creating Debian GNU/Linux packages from source.

OK, that's fine for starters.  As referenced from
,
there is a list of packages that need work at
.  The former
page also has additional information about porting issues.  Of course,
not all packages are considered likewise important, so you could ask on
 if you're unsure which one to start with.


> - How is your expertise about system and kernel programming?
> 
> I have basic knowledge about system and kernel programming. I just  
> finished my undergrad and need to study details on these.

The GNU Hurd project covers all areas of systems' programming and thus
has enough areas to work on to keep you busy for years.  Have fun
exploring these!


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: News...

[Thomas Schwinge]

Hello!

On Wed, Jul 22, 2009 at 01:15:40AM +0200, Arne Babenhauserheide wrote:
> I now wrote a short guide on how to work on the news_next branch. I hope 
> everything is correct 

Thanks for doing that! -- glad to see that you're beginning to follow my
habit of putting contenful emails into the web pages!  (But please also
get used to put into the comming message a note what the source is:
message ID, author, date, for example.)

> (I tested everything but the pull --rebase and the 
> checkout if the branch already exists locally), 

I'll review it.

> http://www.bddebian.com/~hurd-web/community/weblogs/ArneBab/howto-news-month-
> of-the-hurd/

I'd even suggest to move that page to a more prominent page:
contributing/web_pages/news, perhaps?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Restore GNU/Hurd functionality

[Thomas Schwinge]

Hello!

On Mon, Jul 20, 2009 at 11:22:34AM +0100, Pedro Alves wrote:
> I've had the patch below here for months already (I think I wrote it
> around the the time of the solaris changes), but,
> since I had borked by GNU/Hurd setup and hadn't found the energy
> yet to restore it, I completelly forgot about it.  :-(

Well, thanks to you for helping with maintining GDB's Hurd port!  If you
need help with a new Hurd image, or want shell access to a system
(), please just
speak up.  (Likewise everyone else who is interested, of course!)

> It does some house cleaning on the gnu target (by making it inherit from
> the inf-child target), and ends up up making those functions static
> (while at the same time, getting the port a bit more into shape for
> a future !x86 Hurd port).
> 
> What do you think about it?  Could you try it if you like it?

I did review it and did some testing in the areas that could most likely
be touched by it and found no problems.  I only had to do three very
minor corrections:

> Index: src/gdb/gnu-nat.c

> @@ -2082,6 +2080,7 @@ gnu_create_inferior (struct target_ops *
>int from_tty)
>  {
>struct inf *inf = cur_inf ();
> +  int pid;
>  
>void trace_me ()
>{
> @@ -2090,34 +2089,31 @@ gnu_create_inferior (struct target_ops *
>  if (ptrace (PTRACE_TRACEME) != 0)
>error (_("ptrace (PTRACE_TRACEME) failed!"));
>}
> -  void attach_to_child (int pid)
> -  {
> -/* Attach to the now stopped child, which is actually a shell...  */
> -inf_debug (inf, "attaching to child: %d", pid);
>  
> -inf_attach (inf, pid);
> +  inf_debug (inf, "creating inferior");
>  
> -push_target (&gnu_ops);
> +  pid = fork_inferior (exec_file, allargs, env, trace_me, NULL, NULL, NULL);
> [...]

Whether it is better to do it the old way ( have a nested function
attach_to_child that will be passed to and called from within
fork_inferior), or do it like your patch does (inline the former
attach_to_child to be executed after fork_inferior has returned) -- I
have no idea, so I'll leave that to you.

> +/* Create a prototype generic GNU/Hurd target.  The client can
> +   override it with local methods.  */
> +
> +struct target_ops *
> +gnu_target (void)
> +{
> +  struct target_ops *t = inf_child_target ();

That one needs ``#include "inf-child.h"''.

> +  t->to_can_run = gnu_can_run;

This statement should be removed: the default value (as set by
inf_child_target) is alright and you removed gnu_can_run just above.

> +  t->to_thread_alive = gnu_thread_alive;
> +  t->to_pid_to_str = gnu_pid_to_str;
> +  t->to_stop = gnu_stop;
> +}

``return t;'' is missing.


Regards,
 Thomas


signature.asc
Description: Digital signature

Restore GNU/Hurd functionality (was: Modernize solaris threads support.)

[Thomas Schwinge]

Hello!

On Tue, Feb 24, 2009 at 02:38:58PM +, Pedro Alves wrote:
> On Tuesday 24 February 2009 14:33:05, Pierre Muller wrote:
> > Pedro, 
> > you also broke windows-nat.c compilation...
> 
> Uh!  Darn it.  [...]

... and another one (which I noticed only now...): when we recently got a
new Debian gdb package, all attempts to use GDB on GNU/Hurd started
failing like this:

$ gdb /bin/true
GNU gdb (GDB) 6.8.50.20090628-cvs-debian
Copyright (C) 2009 Free Software Foundation, Inc.
[...]
(no debugging symbols found)
(gdb) r
Starting program: /bin/true 
Segmentation fault

> In any case, as I said before, I had to touch most *native*
> configurations, so it's likelly that I missed several cases.  If
> you do spot one, the fix is *dead trivial*, so go ahead and commit a
> fix as obvious ...

You did change the ``extern gnu_store_registers'' and ``extern
gnu_fetch_registers'' declarations in gnu-nat.c, but not their definitons
in i386gnu-nat.c, which I have committed now (as obvious).  Should we
perhaps move these two declarations into a file that is #included from
i386gnu-nat.c?  gnu-nat.h perhaps?


Index: ChangeLog
===
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.10725
diff -u -p -r1.10725 ChangeLog
--- ChangeLog   18 Jul 2009 23:35:30 -  1.10725
+++ ChangeLog   20 Jul 2009 09:50:16 -
@@ -1,3 +1,8 @@
+2009-07-20  Thomas Schwinge  
+
+   * i386gnu-nat.c (gnu_fetch_registers, gnu_store_registers): Adjust to
+   2009-02-23 target_ops changes.
+
 2009-07-18  Michael Snyder  
 
* infrun.c (handle_inferior_event): Remove an execution_direction
Index: i386gnu-nat.c
===
RCS file: /cvs/src/src/gdb/i386gnu-nat.c,v
retrieving revision 1.36
diff -u -p -r1.36 i386gnu-nat.c
--- i386gnu-nat.c   3 Jan 2009 05:57:52 -   1.36
+++ i386gnu-nat.c   20 Jul 2009 09:50:16 -
@@ -111,7 +111,8 @@ supply_fpregset (struct regcache *regcac
 
 /* Fetch register REGNO, or all regs if REGNO is -1.  */
 void
-gnu_fetch_registers (struct regcache *regcache, int regno)
+gnu_fetch_registers (struct target_ops *ops,
+struct regcache *regcache, int regno)
 {
   struct proc *thread;
 
@@ -202,7 +203,8 @@ store_fpregs (const struct regcache *reg
 
 /* Store at least register REGNO, or all regs if REGNO == -1.  */
 void
-gnu_store_registers (struct regcache *regcache, int regno)
+gnu_store_registers (struct target_ops *ops,
+struct regcache *regcache, int regno)
 {
   struct proc *thread;
   struct gdbarch *gdbarch = get_regcache_arch (regcache);


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: News...

[Thomas Schwinge]

Hello!

On Fri, Jul 10, 2009 at 05:17:27AM +0200, olafbuddenha...@gmx.net wrote:
> On Tue, Jul 07, 2009 at 07:10:15PM +0200, Thomas Schwinge wrote:
> > We should not update news items that have already been published (that
> > is, on gnu.org; no problem for the bddebian machine), as the system
> > will always also update the RSS feeds, etc., causing the old news item
> > to reappear on feeds, which is a bit of a nuisance.
> 
> This would certainly be annoying when doing trivial changes like fixing
> spelling etc.; but I think it would be perfectly fine in this case,
> where we have substantial new content.
> 
> Alternatively, we could post a new item as "update" with the additional
> items only.
> 
> I really don't like the idea of postponing the news till the next month.
> That kinda contradict the idea of monthly reports...

I agree in general, but it's not really postponing: we're in mid-July
already, and the patches are not yet in the upstream sources.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: plan to work on user-level device drivers

[Thomas Schwinge]

Hello!

On Fri, Jul 10, 2009 at 07:47:33PM +0200, olafbuddenha...@gmx.net wrote:
> On Wed, Jul 08, 2009 at 07:21:04PM +0200, Thomas Schwinge wrote:
> > What also could be done, and what I had in mind for a long time
> > already, is a simple driver for a SoundBlaster ISA card (again, no PCI
> > for now -- I don't know if PCI device registration actually is
> > difficult, but let's simply avoid that for now).
> 
> I'm not entirely sure, but my impression thus far is that PCI stuff is
> actually easier to handle than legacy devices with all their quirks...

That may very well be true, but note that I never talked about handling
any quirks at all, or being feature (or whatever) complete.  Only a
prototype thing is what I'm talking about.  (Aren't you usually the
person to encourage such incremental progression?)  And for doing that I
still think a simple SoundBlaster ISA user-space driver would be (a) an
easy device driver to write and (b) one that includes all of the needed
infrastructure: I/O port access, IRQs, DMA.

If I remember correctly, the functionality of this device driver would be
as simple as follows: set up the sample rate etc. by writing to some I/O
ports; create a DMA memory region, register that one with the soundcard,
request IRQs to be sent each time half of the DMA memory had been
handled; handle these IRQs in the device driver by filling one half of
the DMA memory with sample data (while the other half is being output).

But of course, it is up to the person doing the work to decide what to
work on.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: GNU Mach -> Git

[Thomas Schwinge]

Hello!

On Tue, Jun 09, 2009 at 12:40:04AM +0700, Ivan Shmakov wrote:
>   BTW, did the transition to Git already happen for GNU Mach
>   development tree, or is it still in CVS?

Here it is: 


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Moving to git

[Thomas Schwinge]

Hello!

On Thu, Jul 02, 2009 at 11:05:50PM +0200, I wrote:
> replace every ChangeLog file's content with information about how to get
> back its former content, and that later in time the Git commit messages
> are correct.

This is now done; thanks to Olaf for suggesting a more straightforward
wording.


Neal: I did not yet apply this change to the two Viengoos branches
(though I did apply it to the two libpthread Viengoos branches).  Tell me
if you want me to cover your Viengoos branches as well.


Regards,
 Thomas


signature.asc
Description: Digital signature

nfs, nfsd (was: Unionmount: proxying the control port)

[Thomas Schwinge]

Hello!

On Fri, Jul 10, 2009 at 12:18:58AM +0300, Sergiu Ivanov wrote:
> For the sake of pushing the horizon of my knowledge, I'd like to ask
> one more question: is nfs a kind of an interface to nfsd, the latter
> being responsible for actually fetching the remote filesystems,
> maintaining caches, etc., while nfs's role being to publish this as a
> virtual filesystem?  (I'm asking because I was surprised when I found
> out that there not only is nfs, but also nfsd.)

It's actually simpler: nfs is the NFS client (that is, used for importing
/ ``mounting'' remote NFS file systems locally) and nfsd is the Hurd's
NFS server, which exports to other machines the local file system using
the NFS protocol.


Indeed both fsys_getfile and file_getfh are only used for
exporting-via-NFS purposes -- you can safely ignore that for now.  (I
don't know any details about that, but if I understand this correctly,
the worst thing which not implementing them means is that a remote user
(who is importing a Hurd machine's file system using NFS) won't be able
to see any files served / translated by unionfs (and most of the other
translators).)  That aside, I have never used nfsd and don't know of
anyone who has (during the last years).  I do use nfs (as does Olaf, as
he told), and it basically works.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: News...

[Thomas Schwinge]

Hello!

On Wed, Jul 08, 2009 at 12:38:28PM +0200, Arne Babenhauserheide wrote:
> Am Dienstag, 7. Juli 2009 19:10:15 schrieb Thomas Schwinge:
> > The instructions from
> > <http://lists.gnu.org/archive/html/bug-hurd/2008-11/msg00129.html>
> > basically still apply, replacing homepage with master-news_next, of
> > course.  If there are concrete questions about how to handle these two
> > branches (master and master-news_next), then please ask -- before pushing
> > experiments to flubber.
> 
> Just to make sure I understand it correctly: That means I use the following 
> commands: 

First, there are two options: you can have separate repositories
(*clones*, or *checkouts*; what you get from ``git clone'') for the
master and master-news_next (not master-next_news, by the way) branches,
or you can deal with both in the same repository.  Having separate
repositories you don't have to remember which branch you're on, and don't
have to switch between branches before beginning to edit files, and it
doesn't matter -- as no switching between branches is needed -- if you
have uncomitted changes to some files.  On the other hand, you may want
to keep it all in one repository, to save disk space, and for shuffling
different branches' commits being (a bit) easier.

> ## get the latest version of next_news
> 
>   git fetch && git checkout -b master-next_news origin/master-next_news

Use the ``git checkout -b master-news_next ...'' command to *create* a
local news branch.  That only has to be done once (unless you remove that
branch later on -- ``git branch -d ...'').  Once you have such a branch
(check with ``git branch'', or ``git branch -a'' to also see the remote
branches) you'd just do ``git checkout [branch]'' to change your
repository to the [branch].

Always do check which branch you're on (asterisk in the first column of
``git branch'''s output), and only then begin to do your changes and
commit them.  (Of course it is possible to move commits between branches,
but you can also simply avoid having to do that.  Talk to me in case it
should be needed and you can't figure out for yourself how to do it.)

> ## check the outgoing changes
> 
>   git log --reverse -p -C -M master-next_news..origin/master-next_news

``-M'' is redundant, I think.  One might want to use ``--cc'' to see if a
merge introduces additional changes (to resolve conflicts and the like),
but that shouldn't be relevant for your use case.  And I got it the wrong
way round in my older email: it should be ``origin/[branch]..[branch]''
to see the changes needed for getting from origin/[branch]'s state to
(local) [branch]'s state -- those we're going to push.

> ## push the changes
> 
>   git push master-next_news

You also have to specify to which repository to push (typically named
origin), in front of the branch head to push.  Then, this command will
transfer the reachable commits to the remote repository and update its
(the remote's) notion of master-news_next to the ID of your last commit
on that branch.

> ## if push fails, fetch and rebase
> 
>   git fetch && git rebase origin/master-next_news

Correct.  Note that this might cause some conflicts to arise -- if the
remote repository contains commits that conflict with any that you've
been recording in your local repository.  For this reason, you might want
to already do this *rebase* before beginning you local edits, simply to
shorten the time frame in which such conflicts can arise.
(Theoretically, in the very rare case of very much concurrent editing
going on, you'd have to repeat this again (and again...) before
succeeding to push your changes.)  Additional explanation: if your branch
is in a state where it doesn't contain any commits that are not yet as
well in the remote repository (or the other way round: it only contains
commits that are as well in the remote repository) -- that is, after a
successful *push* to the remote repository -- this *rebase* will in fact
be a *fast-forward*: it will simply add the commits
[branch]..origin/[branch] (which are those that are in the origin
repository's branch, but not in the local one's) on top of your current
branch, which is the work that others have pushed to the remote
repository in the mean time.


Further questions?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: plan to work on user-level device drivers

[Thomas Schwinge]

Hello!

On Fri, Jun 26, 2009 at 02:48:24PM +0800, Da Zheng wrote:
> I am thinking about writing user-level device drivers. When I searched 
> Internet, I found the paper "An Architecture for Device Drivers 
> Executing as User-Level Tasks" written by David B. Golub, Guy G. 
> Sotomayor and Freeman L. Rawson, III. It might be exactly what I want 
> but unfortunately, the paper isn't available for downloading on 
> Internet.

Confirmed.  Neither is it (it's part of the ``Proceedings of the USENIX
Mach III Symposium'', by the way) available at my university's library or
another library nearby.

Options:

  * Thomas, Roland (CCed): Do you have a copy somewhere?

  * Send email to the authors, asking for a copy.

  * Send email to other authors who referenced it, asking for a copy.

  * Order it from USENIX:


  * Buy it elsewhere:


  * For a small fee, I can use interlibrary loan to get hold of these
proceedings.  I can do that, no problem.


> I wonder if anyone knows the work and more importantly, where 
> I can download the code.

I have no idea.  Perhaps it's part of the Mach multiserver distribution?
A lot of CMU stuff is available via FTP; do something like this to get
hold of it:

$ lftp -c mirror --verbose --delete \
ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public \
CMU_Mach

 also has interesting stuff, and as well
have ,  and
 -- the latter including a Hurd snapshot from
1995 ;-).  (Done anyone know of other collections of Mach-related
resources?)  (I should take a month off to actually read all these
papers.)


Also, I began to put up some stuff and references here:

and
,
but this is totally unfinished and unpolished so far.

> My plan is to write a user-level device driver for testing and ideally, 
> to port ddekit to Mach if it is possible.
> The first device I choose will be ethernet card, which I think is the 
> one I relatively familiar with.
> Any suggestion is welcome!

I would start with something much simpler.  Something that does not even
involve PCI.  For example, continue to work on the user-space keyboard
driver that I linked to on the user-space_device_drivers page.  Or even
simpler, begin with something that really only sends a message to a
user-space server when an interrupt occurs (from the keyboard, for
example, or serial line (mouse); for now additionally to handling that
interrupt in the kernel driver), work out how user-space servers can
register as receivers for interrupts, stuff like that.  Have a look at
the Omega0 paper I linked to from the same web page.  I think (if I
recall correctly from having read it two years ago) it has a nice summary
of how the PC IRQ system works, and how to deal with that in a
microkernel system.  Also, as you noticed in the ``An I/O System for Mach
3.0'' paper, such stuff should already be part of the (of *some*) Mach
code base.  I have no idea whether it's in GNU Mach.  Actually, I just
had a look and here is my very quick analysis: interrupts are handled in
i386/i386at/interrupt.S:interrupt, from where it is diverted to the
registered handler as specified in ivect.  This one is originally defined
in i386/i386at/pic_isa.c and later modified (according to run-time device
registrations during booting) in i386/i386at/autoconf.c:take_dev_irq and
take_ctlr_irq (the latter being obsolete, it seems),
i386/i386at/kd_mouse.c and linux/dev/arch/i386/kernel/irq.c.  No sign of
anything that would allow for registering a user-space server for
receiving interrupt messages.  But perhaps I've been looking at the wrong
place.  Perhaps there are some Mach sources in the FTP repositories that
include such things?

That aside, I still don't know if a NIC is the most easy thing to begin
with.  What also could be done, and what I had in mind for a long time
already, is a simple driver for a SoundBlaster ISA card (again, no PCI
for now -- I don't know if PCI device registration actually is difficult,
but let's simply avoid that for now).  I think that QEMU and friends can
still emulate such ISA sound cards.  And then: there are quite a few
Minix 2 and Minix 3 papers that describe the design and implementation of
exactly such servers for Minix.  Perhaps we can even use their code.
(Minix 3 being the most valuable candidate, of course.)  Also have a look
what they're doing in general for delivering IRQs, and setting up DMA,
etc.  Or, you could have a more detailed look at what the L4 people are
doing: are there some paper that reference the Omega0 one, perhaps?

I will try to add more links to such stuff to the web pages.  Pleas

Re: News...

[Thomas Schwinge]

Hello!

On Sun, Jul 05, 2009 at 07:21:08PM +0200, Arne Babenhauserheide wrote:
> Am Samstag, 4. Juli 2009 17:13:17 schrieb Thomas Schwinge:
> > Just a quick comment: instead of altering the existing announcement now,
> > what about publishing these (undoubted!) enhancements in the next one --
> > by then these changes will (I expect) be present in the master sources.
> 
> That's a nice idea. 
> 
> Can you put my changes into a branch to be merged next month? 

That's actually a nice scheme: we'll have a branch master-news_next where
we work on the current month's news item (that is, add new stuff to it as
soon as it arises), and then, when we have settled on what we intend to
publish, we'll merge that branch into master and have the news item
published that way.

We should not update news items that have already been published (that
is, on gnu.org; no problem for the bddebian machine), as the system will
always also update the RSS feeds, etc., causing the old news item to
reappear on feeds, which is a bit of a nuisance.

After having merged master-news_next into master, work for the next
month's news item can continue on master-news_next.

> (I'd like to have them in the main repo, but the last time I haggled with git 
> branching I had to reclone my local repo)

You already did put your changes (creating the July news item) into the
master branch, so what I had to do now was reverting that commit on the
master branch, but preserve the changes you had done on the new
master-news_next branch.  This is now in a state that it's usable.  On
flubber, that is.  If someone also wants to see it on the Savannah
hurd/web Git repository, just talk to me.

The instructions from
<http://lists.gnu.org/archive/html/bug-hurd/2008-11/msg00129.html>
basically still apply, replacing homepage with master-news_next, of
course.  If there are concrete questions about how to handle these two
branches (master and master-news_next), then please ask -- before pushing
experiments to flubber.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Moving to git

[Thomas Schwinge]

Hello!

On Fri, Jul 03, 2009 at 10:00:52PM +0200, olafbuddenha...@gmx.net wrote:
> On Thu, Jul 02, 2009 at 11:05:50PM +0200, Thomas Schwinge wrote:
> > +After commit e227045b06d62ee7d2fbab9d5ade9030ff43170b, Git's commit 
> > messages
> > +are valid.
> 
> Is it really *after*, or starting with?...
> 
> A less ambiguous wording would be preferable :-)

Yes, I'm myself not entirely happy with the wording.

e227 is the last CVS commit.  So indeed *after* that one the pure Git
ones begin.  (Obviously we can't know the SHA1 of the commit
to-be-created, so we can't use that one as ``starting with''.)  Or is
there some flaw in my logic?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: News...

[Thomas Schwinge]

Hello!

On Sat, Jul 04, 2009 at 10:27:58AM +0200, olafbuddenha...@gmx.net wrote:
> On Tue, Jun 30, 2009 at 02:53:15PM +0200, Arne Babenhauserheide wrote:
> > I just compiled the information from Thomas Schwinge into the first
> > monthly news entry: 
> > 
> > - http://www.bddebian.com/~hurd-web/news/2009-06-30/
> > 
> > If you have further news you'd like to get included for this month,
> > please send me a mail! 
> 
> Sorry for being late (as always), but here is a couple more things:

Just a quick comment: instead of altering the existing announcement now,
what about publishing these (undoubted!) enhancements in the next one --
by then these changes will (I expect) be present in the master sources.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Moving to git

[Thomas Schwinge]

Hello!

On Thu, Jun 18, 2009 at 03:02:41PM +0200, I wrote:
> On Tue, Apr 28, 2009 at 12:39:48AM +0200, I wrote:
> > Here is one additional topic I want to confirm with you all before
> > committing it: the duplication of ChangeLog snippets and commit log
> > messages is a pain.  However, it is not mandatory to maintain ChangeLog
> > files in the VCS sources -- it's fine with the GNU Coding Standards to
> > only create ChangeLog files for distribution tarballs (where one doesn't
> > have access to the VCS logs anymore).  GNU Coreutils is already using
> > this scheme, and I got it confirmed on the GNU-internal maintainers'
> > mailing list that this is indeed fine.  When needed, the ChangeLog files
> > would be created automatically from the VCS commit messages.  (We can
> > steal all the mechanisms from GNU Coreutils.)
> > 
> > Commit messages would then have this mandatory format: [...]
> > 
> > Any objections?
> 
> There was a bit of support, and no objections, so that is it; see section
> ``Commit messages'' on
> .

The sequel to that is that I intend to install the equivalent of the
following on every branch that was converted from CVS to Git -- in short:
replace every ChangeLog file's content with information about how to get
back its former content, and that later in time the Git commit messages
are correct.  Then, for doing releases (that is, any kind of *snapshot*
that does not include the whole VCS history), some magic machinery will
serialize all history back into ChangeLog files.  Does that seem alright?

diff --git a/ChangeLog b/ChangeLog
dissimilarity index 99%
index edb4a89..532a4df 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,6329 +1,8 @@
-2009-02-26  Samuel Thibault  
-
-   * i386/i386/prog_reg.h (invlpg_linear): Rename macro into...
[...]
Tue Feb 25 15:42:23 1997  Thomas Bushnell, n/BSG  
-
-   * i386/Makefrag (INCLUDES): Find `include' directory in new
-   location.
-   * Makefile (INCLUDES): Find `include' directory in new location.
-   (%.symc): Find gensym.awk in new location.
-
-   * Reorganized directories into new layout and unified mach4 and
-   mach4-i386 into a single tree.
-
-
-Older changes in ChangeLog.00 (for i386 directory) and ChangeLog.0 (for
-all other files).
+After commit e227045b06d62ee7d2fbab9d5ade9030ff43170b, Git's commit messages
+are valid.
+
+To examine earlier changes use this:
+
+$ git show e227045b06d62ee7d2fbab9d5ade9030ff43170b:ChangeLog
+$ git show e227045b06d62ee7d2fbab9d5ade9030ff43170b:ChangeLog.0
+$ git show e227045b06d62ee7d2fbab9d5ade9030ff43170b:ChangeLog.00
diff --git a/ChangeLog.0 b/ChangeLog.0
deleted file mode 100644
index 2ef943a..000
--- a/ChangeLog.0
+++ /dev/null
@@ -1,721 +0,0 @@
-Wed Feb 12 16:22:07 1997  Thomas Bushnell, n/BSG  
[...]
diff --git a/ChangeLog.00 b/ChangeLog.00
deleted file mode 100644
index 553b5fe..000
--- a/ChangeLog.00
+++ /dev/null
@@ -1,858 +0,0 @@
-Wed Feb 19 15:51:34 1997  Thomas Bushnell, n/BSG  
[...]


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: New Xen domU: blubber

[Thomas Schwinge]

Hello!

On Thu, Jul 02, 2009 at 09:39:42PM +0300, Sergiu Ivanov wrote:
> On Thu, Jul 02, 2009 at 12:00:19PM +0200, Thomas Schwinge wrote:
> > On Sat, Jun 27, 2009 at 03:07:53PM +0200, I wrote:
> > > what I can offer is that you get a separate Xen domU
> > > on zenhost (where flubber is also running on) and you can do in that one
> > > whatever you want.
> > 
> > This has been finished, *blubber* is born.  See
> > <http://www.bddebian.com/~hurd-web/public_hurd_boxen/> and its two
> > subpages for information -- and, I suggest, contact me on IRC so that we
> > hash out the last details.
> 
> This is great! Thanks a lot! I hope it didn't take up too much of your
> time...

Sure, no problem!  Even though that it took some time to finish and
polish my automatic installation script (which I had begun already months
ago, but never followed up) -- but that is now finished, and I can newly
install and configure up-to-date GNU/Hurd systems (including a standard
set of packages) with only very few keystrokes.


> I just can't really find the *two* subpages. I can see
> public_hurd_boxen/zenhost only... Which is the other one?

Oh, there is also a public_hurd_boxen/bddebian page.  On that one you
should later register additional IP addresses that you use, but no need
to hurry with that.


> Surely, I'll contact you on the IRC, when you have time.

It was roughly like this: I had left a minute before you popped up -- and
got back a one minute after you had left again.  ;-)


One thing returned to mind --
<http://lists.gnu.org/archive/html/bug-hurd/2008-10/msg3.html> --
there'll be some work needed as soon as it gets to setting the
Xen-emulated net devices to promicios mode, or whatever else Zheng's work
might need, as Xen Mach's device_set_status currently looks like this:
``return D_INVALID_OPERATION;''.  But perhaps you don't need that for
starters.  And also, with Samuel's and Zheng's help that should easily be
possible to implement.


Regards,
 Thomas


signature.asc
Description: Digital signature

Berkeley Packet Filter

[Thomas Schwinge]

Hello!

Zheng Da asked me to tell him about previous work that has been done on
supporting and using Berkeley Packet Filters.  Here it is:



Regards,
 Thomas


signature.asc
Description: Digital signature

[patch #6624] gnumach provides the interface for the program to set the kernel device into promiscuous mode.

[Thomas Schwinge]

Update of patch #6624 (project hurd):

  Status:Works For Me => Done   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

New Xen domU: blubber (was: Where to run the Hurd)

[Thomas Schwinge]

Hello!

On Sat, Jun 27, 2009 at 03:07:53PM +0200, I wrote:
> what I can offer is that you get a separate Xen domU
> on zenhost (where flubber is also running on) and you can do in that one
> whatever you want.

This has been finished, *blubber* is born.  See
 and its two
subpages for information -- and, I suggest, contact me on IRC so that we
hash out the last details.


Regards,
 Thomas


signature.asc
Description: Digital signature

[SCM] Hurd meta package branch, master, updated. 1709ca81522baffea2cfecc7c7b85618ac8894a5

[Thomas Schwinge]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Hurd meta package".

The branch, master has been updated
   via  1709ca81522baffea2cfecc7c7b85618ac8894a5 (commit)
  from  7690e14a0c5665e8ccc8d4ed01a6b43a253a0615 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 1709ca81522baffea2cfecc7c7b85618ac8894a5
Author: Thomas Schwinge 
Date:   Thu Jul 2 11:52:28 2009 +0200

Forward people to the Git repositories summary page.

---

Summary of changes:
 README |   10 +++---
 1 files changed, 3 insertions(+), 7 deletions(-)


hooks/post-receive
-- 
Hurd meta package

[bug #17648] glibc: ioctl() incorrectly decodes argument

[Thomas Schwinge]

Update of bug #17648 (project hurd):

  Status:None => Duplicate  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Duplicate of patch #4762.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[patch #6856] Declare trivfs hooks external and provide defaults

[Thomas Schwinge]

Update of patch #6856 (project hurd):

  Depends on: => patch #308 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[patch #1790] Implements the routing interfaces in pfinet

[Thomas Schwinge]

Update of patch #1790 (project hurd):

  Depends on: => patch #1789


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [bug #26914] Add an option to enforce limits to increase stability

[Thomas Schwinge]

Hello!

On Wed, Jul 01, 2009 at 08:09:47AM +0200, Arne Babenhauserheide wrote:
> Am Mittwoch, 1. Juli 2009 04:17:24 schrieb olafbuddenha...@gmx.net:
> > On Tue, Jun 30, 2009 at 08:07:46AM +, Arne Babenhauserheide wrote:
> > > URL:
> > >   
> > >
> > >  Summary: Add an option to enforce limits to increase
> > > stability
> >
> > I said *task* tracker, not bug tracker...

> ...corrected, sorry for the noise. 

Likewise -- the other way round -- for Samuel's report.  For your
information: you can also move issues between the different trackers: see
the ``reassign this item'' functionality on the bottom of each issue's
report page.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: News...

[Thomas Schwinge]

Hello!

On Tue, Jun 30, 2009 at 02:53:15PM +0200, Arne Babenhauserheide wrote:
> I just compiled the information from Thomas Schwinge into the first monthly 
> news entry: 
> 
> - http://www.bddebian.com/~hurd-web/news/2009-06-30/

(1): Arne, thanks very much!  I applied some few formatting changes and
formulation improvements -- I hope that's fine with you?  (2): Barry,
we're able to use port 80 again?  That's also good news!


> If you have further news you'd like to get included for this month, please 
> send me a mail! 

Hurry up, June ends today (already, wow!) -- I'll push this online (to
the main page) tomorrow.


> > Which relevant improvements did you do / are you working on?
> 
> > I want to gather the parts and parse them into a news entry for the wiki -
> > ideally with links to relevant emails / commits.

I'd like to have this continued -- Arne, you're prepared for that?  :-)


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Problems with large swap partitions

[Thomas Schwinge]

Hello!

On Thu, May 28, 2009 at 07:02:11PM +0200, Marc Dequènes (Duck) wrote:
> First, i don't know if Hurd can handle several swap partitions, so i  
> deactivated the initial one, just to be sure my result is not biased.

This needs investigation.  But I may have used that in the past, I think.


> At boot, or run manually, swapon result in a segfault. Samuel  
> suggested to try 1.7GB, which is known to work, as used on buildds  
> currently. It failed in the same way. I attached the rpctrace, but i  
> don't know what to do now. Could someone help ?

> [...]
> swapon:  114->io_write_request ("swapon: " -1) = 0 8
> /dev/hd2s1: Linux 2.0 swap signature, 1781736k swap-space (-1650988k bad, 
> 1650992k wasted at end) 114->io_write_request ("/dev/hd2s1: Linux 2.0 swap 
> signature, 1781736k swap-space (-1650988k bad, 1650992k wasted at end)" -1) = 
> 0 97
>  114->io_write_request ("

This very much looks like the following scenario -- which I experienced
earlier today (v0 vs. v1 swap signature).

sh-3.2# mkswap.linux /dev/hd1
mkswap.linux: warning: truncating swap area to 130752 KiB
Setting up swapspace version 0, size = 130748 KiB
sh-3.2# swapon -a
swapon: /dev/hd1: Linux 2.0 swap signature, 524280k swap-space (-393532k 
bad, 393536k wasted at end)
Segmentation fault
sh-3.2# mkswap.linux -v1 /dev/hd1
Setting up swapspace version 1, size = 524284 KiB
no label, UUID=6248abc2-64c0-11de-809c-411e4c248c5a
sh-3.2# swapon -a
swapon: /dev/hd1: Linux 2.2 swap signature v1, 524284k swap-space (excludes 
8k at end of partition)

Since when is (a) mkswap to be spelled mkswap.linux (only on Hurd
systems?), and since when does one (b) have to explicitly specify the
newer v1 format (failing Linux kernel version autodetection; has it
always been like this?)?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Moving to git

[Thomas Schwinge]

Hello!

On Mon, Jun 29, 2009 at 10:56:01PM +0300, Sergiu Ivanov wrote:
> On Mon, Jun 29, 2009 at 01:05:30AM +0200, olafbuddenha...@gmx.net wrote:
> > On Thu, Jun 25, 2009 at 10:17:03PM +0300, Sergiu Ivanov wrote:
> > > I'm sorry for being dumb, but I'd like to avoid misunderstandings: is
> > > it true that it is being suggested that my nsmux github repository be
> > > moved to Savannah? Or, even more, am I supposed to create a branch in
> > > the Hurd git repository for nsmux and put nsmux there?
> > 
> > The latter.
> 
> OK. So, I'm asking the same thing as in some other letter of mine:
> tell me please where the Hurd git repository is, since I cannot find
> it myself :-(

See my other email.

> Please note that most of my commits to nsmux repository are ugly. Is
> that okay?.. Or should I refactor them somehow?
> 
> I'd also be happy to be given a suggestion on how this injection of
> nsmux into Hurd should happen: shall I convert the nsmux repository
> into patches and them apply them to my branch?

I will take care of that, no worries.  (And get back to you to talk about
details.)


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Setting up eth-multiplexer in QEMU

[Thomas Schwinge]

Hello!

On Mon, Jun 29, 2009 at 10:21:22PM +0300, Sergiu Ivanov wrote:
> On Mon, Jun 29, 2009 at 08:55:51AM +0800, Zheng Da wrote:
> > On Sun, Jun 28, 2009 at 9:56 PM, Sergiu
> > Ivanov wrote:
> > > This makes me suspect that eth-multiplexer is not the troublesome
> > > component we are looking for. Do you share this opinion or do you
> > > still insist on my trying to deprive eth-multiplexer of the
> > > functionality of setting the device in promiscuous mode?
> > 
> > Since the modified pfinet cannot work either, the problem should be in 
> > pfinet.
> > I wonder what modification in pfinet can cause the problem.
> 
> I've found out a stunning thing (for me) today: I checked out a fresh
> Hurd from CVS in the following way:
> 
>  $ cvs -z3 -d:pserver:anonym...@cvs.savannah.gnu.org:/sources/hurd co hurd
> 
> Then I created build/ , went there, configured and ran make
> pfinet. The executable file pfinet I got as a result behaves in the
> *same* way as the modified pfinet + devnode! That is, things work a
> little bit slowly, and wget stalls having downloaded the same 2,576
> bytes :-(

May I ask, and I should have realized this earlier! -- in the context of
our IRC discussion one or two weeks ago when we told you to update your
system -- which version of GCC did you use to build pfinet?
 -- did you use GCC 4.3?  If yes,
then sorry for the wasted time!, and hooray for having (hopefully)
resolved this mystery.


> I wonder whether this can be caused by the fact that I'm using the CVS
> repository... I tried to find Hurd git repository, but I only ran over
> some links on Savannah which pointed to a repository having only a
> README file.

That one, and a lot of other (web) pages, should be updated to reflect
that we moved to Git.

> Could somebody point out where I could find the correct
> git repository?

: ``Git
repositories on Savannah, see  (search
for hurd).'' --  is a more
suitable link, which I'll add to that page.


> Also, I didn't apply Debian patches, but I'm not sure whether they
> could be the cause... I didn't apply them because, apparently,
> something is different in the main Hurd branch and Zheng's branch,

Probably it's been some time since the HEAD branch has last been merged
into Zheng's branch.  (This will improve as soon as I've transitioned
these working-branches to Git.)

> because exactly the series of patches which worked in Zheng's branch
> failed in the source tree I got by means of the command mentioned
> above.

Relevant (depending on your version of glibc) are (very likely) need the
in6_addr.patch, to avoid a build failure, which is in HEAD (and Git
master, but not in Zheng's branch, I guess).  Then there is the DHCP
patch for pfinet, which is not important for your usage, and that's it:
nothing else is relevant for pfinet.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Where to run the Hurd

[Thomas Schwinge]

Hello!

On Sat, Jun 27, 2009 at 05:47:41PM +0300, Sergiu Ivanov wrote:
> On Sat, Jun 27, 2009 at 03:07:53PM +0200, Thomas Schwinge wrote:
> > On Sat, Jun 27, 2009 at 01:12:40PM +0300, Sergiu Ivanov wrote:
> > > I put much hope into my old box, but I forgot that it had some weird
> > > software RAID stuff embedded into the motherboard, which I cannot turn
> > > off. When I tried to install Debian Hurd on this box, the installation
> > > system could not detect my hard drives at all.
> > 
> > The installation system is an old Linux 2.2 (?) one, but if that one has
> > problems detecting your HDs, then GNU Mach likely also will have.  To
> > check that, you could simply boot a GNU Mach kernel on it (just the
> > kernel, nothing else) and have a look at the kernel messages.  Perhaps
> > we're lucky.
> 
> Suppose I take the gnumach executable I'm using presently under QEMU,

It doesn't really matter which one you take, as you're only testing its
HDD detection, and that hasn't been touched for a long time.

> put it on the partition I have created on the old computer for the
> Hurd, then create a GRUB entry similar to the one I'm using at the
> moment. Is this the right course of actions

Yes, something like that.  But it can be even simpler: boot GRUB, go to
its command line, type in ``kernel (hdwherever)/it/is/gnumach'' and
``boot''.  (If you haven't installed it already, you could even boot GRUB
from a rescue CDROM, for example.)


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Where to run the Hurd

[Thomas Schwinge]

Hello!

On Sat, Jun 27, 2009 at 01:12:40PM +0300, Sergiu Ivanov wrote:
> However, when I do apt-get update, it (very slowly) fetches me
> ~800B, then hangs for around 6-7 minutes and then stops with warnings
> and errors about failures in fetching data.
> 
> Taking into consideration that neither antrik (running Hurd on bare
> metal) nor Zheng (running Hurd not in QEMU) experience no problems of
> the kind, and, moreover, when antrik tried the exact sequence of
> commands I had used, it worked for him, I suspect QEMU's user-space
> network of getting into the way of eth-multiplexer in my case.

It may indeed be a QEMU issue, or it may be something else.  Testing the
individual components (as Zheng Da just suggested in his email) is the
right way to figure that out.  Of course, your suggestion to test it on
another host system (architecture) will also give input to that matter.


> I put much hope into my old box, but I forgot that it had some weird
> software RAID stuff embedded into the motherboard, which I cannot turn
> off. When I tried to install Debian Hurd on this box, the installation
> system could not detect my hard drives at all.

The installation system is an old Linux 2.2 (?) one, but if that one has
problems detecting your HDs, then GNU Mach likely also will have.  To
check that, you could simply boot a GNU Mach kernel on it (just the
kernel, nothing else) and have a look at the kernel messages.  Perhaps
we're lucky.


> Also, I remember Zheng having been given an account on flubber (I hope
> I remember things well) last summer and I wonder whether it is
> possible for me to get an account too :-)

Sure.  I'll talk to you on IRC about it.


I'm obviously a bit reluctant to replace flubber's pfinet with the
in-progress one, but what I can offer is that you get a separate Xen domU
on zenhost (where flubber is also running on) and you can do in that one
whatever you want.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Moving to git

[Thomas Schwinge]

Hello!

On Tue, Jun 23, 2009 at 01:25:34PM +0200, olafbuddenha...@gmx.net wrote:
> On Thu, Jun 18, 2009 at 03:02:41PM +0200, Thomas Schwinge wrote:
> > Olaf asked whether we could fix the author and committer information
> > for the changesets.  This can't be done reliably in an automated way
> > and surely no one wants to inspect 10,000+ changesets manually.  As I
> > consider a correct-believed but nevertheless incorrect automatic
> > conversion worse than the current one where you exactly know that the
> > information is not accurate, I decided to leave this alone as is.
> 
> I don't agree. What's the use of this damn pedantic GNU-style changelog
> format, if we can't even reliably extract author information from it?!

You can extract that information, but it's a manual process.  It involves
looking into the ChangeLog *file* and extract the information from there.

Consider this case: P commits change C1 with log message L1.  L1 does
*not* contain any authorship information, but contains soleley the
textual description of the actual change.  P commits further changes Cx
with log messages Lx, as above.  Eventually P will commit change
C(ChangeLog) with log message L(``.'')).  Only then the ChangeLog will
reflect the correct attribution of the changes.  And note that I didn't
make this up, but this is in fact how it has (partly) been done in the
past.  This means that the revision control system alone will never be
able to correctly describe the authorship information of individual
changes.  Only the ``serialized form'' (say, a tarball release's
ChangeLog file) will have the correct information.

> I also do not agree that having everything wrong is better than having a
> few errors, perhaps, or maybe not.

I object: having most of it correct, but not all, gives the false
impression that everything would be correct.  And as we're talking about
legally relevant matters here, better be on the safe side.

> (And it's not even more consistent, as any new commits will have it
> right.)

Indeed there is a cut-off point, and before that one the ChangeLog is
correct, and after it the Git information is correct.  On the cut-off
point (i.e., now), the ChangeLog files will be removed from the trees (or
be renamed to ChangeLog.old or whatever).

> Also note that not only the original Author information is missing, but
> also the Committer is "tschwinge" for all commits -- I guess you did
> some careless rebasing or something like that... So the result is that
> the Committer is bogus, the Author contains the actual comitter, and the
> real author is only mentioned in the Changelog. That's extremely ugly
> and confusing IMHO.

We can't really do anything about it.  The situation after the cut-off
point: standard Git usage.  The situation before the cut-off point:

Git committer name == CVS committer name, or tschwinge
Git committer date == CVS committer date, or a recent date
Git author name == CVS committer name
Git author date == CVS committer date

Indeed -- you guessed correctly; set aside the ``careless'' allegation --
the Git committer {name,date} != CVS committer {name,date} in the cases
where I manually re-spooled a lot of series of commits in order to
re-craft proper merges between branches.  So, in Git sense, it is correct
that the Git commit {name,date} is updated to the person having
re-committed each original commit.

So, to sum up: after the cut-off point, everything is as expected, and
before the cut-off point, the Git committer information is useless, and
the Git author information is the CVS commiter information, and the
changes' author information is hidden in the relevant ChangeLog file.


> > Also, there was the idea of aggregating all the individual one-file,
> > [...], then ChangeLog commits into aggregates, but this also can't be
> > done reliably in an automated fashion without a lot of manual
> > corrections (as could be seen in the glibc CVS to Git conversion), so
> > I also left that alone.
> 
> I feared that much... It's a pity, but I guess there is nothing we can
> do about it :-(

Unfortunately, yes.


See, these are (a part of) the resons why the CVS to Git migration took
that long.  As you, I wanted to get it all right, so that the Git VCS
information is ``correct''.  But it is just not possible (without manual
intervention, of course).


Regards,
 Thomas


signature.asc
Description: Digital signature

[PATCH] Make it possible to use ``-'' for reading from stdin.

[Thomas Schwinge]

* mig.in  (-*): Change to ``-?*'' to let ``-'' fall through.
---

Hello!

On Mon, Jun 22, 2009 at 10:06:08PM +0200, olafbuddenha...@gmx.net wrote:
> On Wed, Jun 17, 2009 at 12:40:56AM +0200, Thomas Schwinge wrote:
> > +%.sdefsi:
> > +   echo '#include ' | \
> > + $(CPP) \
> > +   $(CPPFLAGS) $(MIGSFLAGS) $($*-MIGSFLAGS) -DSERVERPREFIX=S_ \
> > +   -x c - -o $@
> 
> Interesting idea, was looking for something like that...
> 
> I wonder whether it can be used for direct MiG invocations too.

Sure you can, but you have to use ``mig /dev/stdin'' -- or test and
confirm that the attached patch doesn't break anything, which I think
that it can't, but who knows...


Regards,
 Thomas

---
 mig.in |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mig.in b/mig.in
index 7707bf2..bed9b39 100644
--- a/mig.in
+++ b/mig.in
@@ -116,7 +116,7 @@ EOT
-imacros | -isystem ) cppflags="$cppflags $1 `prj_quote_sh "$2"`"; 
shift; shift;;
-cc) cpp="$2"; shift; shift;;
-migcom) migcom="$2"; shift; shift;;
-   -* ) cppflags="$cppflags `prj_quote_sh "$1"`"; shift;;
+   -?* ) cppflags="$cppflags `prj_quote_sh "$1"`"; shift;;
* ) files="$files $1"; shift;;
 esac
 done
-- 
1.6.3.1

Re: Getting libpthread working again

[Thomas Schwinge]

Hello!

On Sun, Apr 12, 2009 at 05:32:12PM +0200, I wrote:
> When linking the pthread tests against a libpthread built (with Samuel's
> TLS patches) from CVS HEAD (or any of the Viengoos branches, for that
> matter) I always get this:
> 
> $ ./test-1
> test-1: ../../HEAD/libpthread/sysdeps/mach/hurd/i386/pt-setup.c:103:
> __pthread_setup: Unexpected error: (ipc/send) invalid destination
> port.
> Aborted
> $ ./test-1-static 
> test-1-static:
> ../../HEAD/libpthread/sysdeps/mach/hurd/i386/pt-setup.c:103:
> __pthread_setup: Unexpected error: (ipc/send) invalid destination
> port.
> Aborted
> 
> I tracked this down to the 2008-08-16 __pthread_free_threads change --
> apparently nobody ever tried to use the CVS HEAD libpthread since then?
> (We absolutely need to come up with better automated testing methods...)
> The pthread library was now trying to reuse kernel threads that have been
> invalidated before.  I created the attached patch to get that fixed again
> (plus the malloc to calloc patch needed for CVS HEAD).  Neal, is this
> approach correct?  I have stolen the thread_suspend thing from Viengoos
> -- is that correct for Mach as well?  (And the while (1) loop is
> superfluous for all variants, isn't it?)  At least, this way all of the
> libpthread test suite programs complete to satisfaction, both dynamically
> and statically linked.

I now put my preliminary (unfinished) patch into the
master-fix_have_kernel_resources branch.  The commit currently also has
some additional comments by Neal in the commit message (for the next
person to work on it).


I also published a patch in master-fix_inline to fix an inlining problem
that I discovered when using Debian unstable's gcc-4.4.  Neal, Samuel, is
this fine for master?


Already some weeks ago, I published master-tls_support containing
Samuel's TLS support for libpthread.  How are we going to proceed with
that one?


And then, today I created and now published master-stand-alone whose
purpose is it to dissolve the libpthread package's build system from the
Hurd proper's.  It works and yields identical binaries.  But please give
it some more testing before we merge it into master.  Also, someone could
Automakifize the test suite.


For all changes, I'll try to update the Viengoos code as needed, when we
merge them in.


Again, some simple instructions about how to review commits in branch B:

$ git clone git://git.savannah.gnu.org/hurd/libpthread.git
$ cd libpthread/
$ git log --reverse -p --find-copies-harder -C --cc origin/master..B


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH 1/1] Update the bug-reporting address.

[Thomas Schwinge]

Hello!

On Thu, Jun 18, 2009 at 11:35:16PM +0300, Sergiu Ivanov wrote:
> From 18bb06e5af5bfccfdb5212307bf36aadd94e4f5f Mon Sep 17 00:00:00 2001
> From: Sergiu Ivanov 
> Date: Thu, 18 Jun 2009 23:31:17 +0300
> Subject: [PATCH] Update the bug-reporting address.
> 
> * Makefile (LDFLAGS): Add -lhurdbugaddr.
> * option.c (argp_program_bug_address): Remove definition.

OK for unionfs/master.  (Where needed, add updating the copyright years
to this commit before pushing; no commit message for that.)


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH] Don't abuse $(prefix) for finding build-time files.

[Thomas Schwinge]

Hello!

On Fri, Jun 19, 2009 at 12:21:17AM +0300, Sergiu Ivanov wrote:
> On Wed, Jun 17, 2009 at 12:40:56AM +0200, Thomas Schwinge wrote:
> > +%.sdefsi:
> > +   echo '#include ' | \
> > + $(CPP) \
> > +   $(CPPFLAGS) $(MIGSFLAGS) $($*-MIGSFLAGS) -DSERVERPREFIX=S_ \
> > +   -x c - -o $@
> 
> Could you please explain what this expression does? Does it somehow
> inject the #include statement into the code of fs_notifyServer.c?..

The echo statement does the obvious, replacing $* with the so-called stem
(see the Make info manual; the stem is the % part of the target).  I.e.,
for ``make foo.sdefsi'' we'll get ``#include ''.  This
line of code is piped into GCC (same compiler flags and output file as
before), but additionally GCC is told to read C language source code (-x
c) from stdin (-).


Regards,
 Thomas


signature.asc
Description: Digital signature

Some more about Git usage (was: [PATCH] Don't abuse $(prefix) for finding build-time files.)

[Thomas Schwinge]

Hello!

On Fri, Jun 19, 2009 at 12:21:17AM +0300, Sergiu Ivanov wrote:
> On Wed, Jun 17, 2009 at 12:40:56AM +0200, Thomas Schwinge wrote:
> > To finally bring this to an end, I propose the following.  Can you please
> > confirm that it works for you?
> 
> Yes, it works for me.

OK, then please apply this change of mine to your local tree, like this,
for example (untested, so beware, and ask it there are questions):

$ git checkout -b master-prefix_fix origin/master

That creates a new (local) branch master-prefix_fix, based on
origin/master, and switches to the new branch.

$ git am < ~/where/you/saved/my/email

Apply my change to that branch.  It should be the only change on there
compared to origin/master, but better be sure, so...

$ git log --reverse -p -C --cc origin/master..HEAD

... review the changes between origin/master and the current HEAD (HEAD
could be omitted in the command line, as it is the default), do this in
reverse ordering (i.e. the chronologically first change is shown first),
show the diff itself (I always quickly review patches again before
finally pushing them), be less verbose for copied / renamed files (not
relevant here), show merges more nicely (not relevant here).

$ git push origin HEAD:master

Push to the origin repository the local HEAD branch into the remote
master branch.

$ git checkout WHATEVER

Move away from the master-prefix_fix branch.  WHATEVER could be
origin/master, for example.  (But don't do commits directly in there!)

$ git branch -d master-prefix_fix

Remove the working branch.


> And another question: how does one get such neatly formatted
> mail+patch things? Does one use git format-patch alone?

I'm also still mostly new to this, but here is what I do: first, I work
on branches, as indicated above already.  Then, I use ``git format-patch
[...]''.  If needed, I edit the resulting patch file(s) to include
further messages, explanations, etc.: add such texts after the first ---
line, so that it isn't considered part of the commit message.
(Everything between the first --- and the actual start of the changes
will be ignored by Git later on.)  Then, I send the patch file(s) using
``git send-email [...]'' (needs a local MTA).


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH 1/3] Add the ``--mount'' command line option

[Thomas Schwinge]

Hello!

On Thu, Jun 18, 2009 at 11:10:19PM +0300, Sergiu Ivanov wrote:
> On Wed, Jun 17, 2009 at 01:43:42AM +0200, Thomas Schwinge wrote:
> > So, instead of your version...
> > 
> > [...]
> > (argp_parse_common_options): Add the code for handling option
> > ``--mount''.
> > [...]
> >
> > ... I would have written this commit message as follows:
> >
> > [...]
> > (argp_parse_common_options): Handle it.
> > [...]
> 
> I took the liberty of making this changelog entry a bit longer
> (``Handle the new option''). The reason is that it took me some time
> to realize what ``it'' refers to. I hope this deviation isn't that
> critical...

Sure, that is fine.


> > On Mon, Jun 15, 2009 at 10:39:22PM +0300, Sergiu Ivanov wrote:
> > > --- a/options.c
> > > +++ b/options.c
> > > @@ -124,6 +131,13 @@ argp_parse_common_options (int key, char *arg, 
> > > struct argp_state *state)
> > >ulfs_match = 0;
> > >break;
> > >  
> > > +case OPT_MOUNT:
> > > +  /* TODO: Improve the mountee command line parsing mechanism.  */
> > > +  err = argz_create_sep (arg, ' ', &mountee_argz, &mountee_argz_len);
> > 
> > If I understand it correctly, indeed: doing it this way, you loose the
> > ability to pass strings containing ``quoted space characters'', i.e. ones
> > that do not separate arguments.  Of couse, for simple use cases it
> > doesn't matter too much.
> 
> In this patch series I do pursue simple use-cases :-)

OK then.

> > There must be other applications that have the same problem --
> > unfortunately it's too late for me to investigate and see how they solve
> > this quoting / argument splitting problem.
> 
> I'll try to make an investigation of my own, shall we choose the
> continue the ``--mount'' idea, but I'll definitely be happy to have
> your help in that situation :-)

OK, I'll tell you as soon as I happen to find something usable or at
least interesting.


> > > diff --git a/unionmount.c b/unionmount.c
> > > new file mode 100644
> > > index 000..2b3041f
> > > --- /dev/null
> > > +++ b/unionmount.c
> > 
> > > +#define _GNU_SOURCE 1
> > 
> > That should usually be done in the Makefile / build system.
> 
> All .c files in unionfs define _GNU_SOURCE explicitly (though, true,
> they do only #define _GNU_SOURCE /*(no 1)*/, and I've changed my new
> patch accordingly). I chose to do similarly in unionmount.c, because
> moving the definition of _GNU_SOURCE into Makefile (if I understand
> you correctly) will mean changing a lot stuff loosely connected to
> unionmount matters. I guess this transition has its place in a
> separate clean-up patch.

Absolutely right, and sorry that I didn't check the other unionfs files
before complaining -- that's one major problem with reviewing patches out
of their context.

Yes, that's totally a separate change then, and you are correct to first
do it like it's done in the other unionfs files.  So, this change is
first to be done in the unionfs repository, and then that commit is to be
merged into your unionmount branch, at the same time extending the merge
to cover the unionmount.c file (needing the exactly same change) that is
present in your branch, but not in the master one.  I think this is
exactly how we're doing to deal with this issue -- sometime later, as
this is not really that important right now.  And then you'll see how
non-trivial (but not too difficult either) merging is done.


Regards,
 Thomas


signature.asc
Description: Digital signature

ChangeLog style (was: [PATCH 1/3] Add the ``--mount'' command line option)

[Thomas Schwinge]

Hello!

On Thu, Jun 18, 2009 at 11:10:19PM +0300, Sergiu Ivanov wrote:
> On Wed, Jun 17, 2009 at 01:43:42AM +0200, Thomas Schwinge wrote:
> > On Mon, Jun 15, 2009 at 10:39:22PM +0300, Sergiu Ivanov wrote:
> > > * options.h (OPT_MOUNT): Add the definition.
> > > (OPT_LONG_MOUNT): Likewise.
> > > Update copyright information.
> > > 
> > > * options.c (argp_common_options): Add option ``--mount''
> > 
> > There is no need to put blank lines between changed files that are
> > related to each other in the current changeset.
> 
> I'm sorry, but could you please give an example where there *is* a
> need for a blank line? (I just feel a bit dizzy about that changeset
> terminology :-( )

Sure, here we go -- and note that this is just my interpretation of the
GCS, of how I think it should be done, and what I observe how it is done
in other projects:

(a) A blank line is to be added it two independent changes are committed
together -- which shouldn't be done in most cases in the first place, of
course.

* file1 (foo): Handle option bar here.
* file2 (bar): Use file1's foo instead instead of own implementation.

* file1 (foo): Rewrite function.

Instead, first the ``rewrite foo'' change should be committed, and then
the ``handle option bar'' one.  Remember that ChangeLogs are kept in
reverse chronological ordering with respect to individual blocks
(``rewrite foo'' (first change) is below ``handle option bar'' (second
change)), but inside a block typically chronological ordering is used
(``handle option bar'' before ``use foo'').

(b) As a corollary to (a), a blank line is also needed when real
ChangeLog *files* are being used, and a change is registered in there by
the same author on the same day and no duplicate header line is being
added.

Example:

ChangeLog file before the second commit:

DATE  AUTHOR  EMAIL

* file1 (foo): Rewrite function.

ChangeLog file after the second commit:

DATE  AUTHOR  EMAIL

* file1 (foo): Handle option bar here.
* file2 (bar): Use file1's foo instead instead of own implementation.

* file1 (foo): Rewrite function.


To sum up: both these cases are not really relevant to us anymore, as (a)
should be committed as two independent commits and (b) is no issue
anymore as we don't have a real ChangeLog file anymore.


Further questions?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Moving to git

[Thomas Schwinge]

Hello!

On Tue, Apr 28, 2009 at 12:39:48AM +0200, I wrote:
> A bit of a status update.

... and again -- perhaps that last one?

> The CVS to Git conversion is mostly finished.
> 
> There are still some quirks with converting the
> gnumach-1-branch-Xen-branch, but I'm working on resolving these with the
> help of the conversion program's author, Simon 'corecode' Schubert, whose
> fromcvs / rcsparse combo I finally ended up using, by the way.

In case that someone is interested -- what was wrong with the previous
import: the method fromcvs uses to decide where in the timeline to put
commits that have been aggregated from more than one CVS files' revisions
is to put them in the place where the aggregate's part with the earliest
timestamp would have been put -- thus pre-dating all parts of the
aggregate that would originally appear later.  (That was the short
version.)  This is for one an aesthetic issue, and for another changing
this algorithm to putting commits at the position of the latest timestamp
made this mysterious gnumach-1-branch-Xen-branch conversion problem go
away!

So, with this fromcvs change, I re-converted the repositories -- only
hurd and gnumach were actually affected by this issue.

Olaf asked whether we could fix the author and committer information for
the changesets.  This can't be done reliably in an automated way and
surely no one wants to inspect 10,000+ changesets manually.  As I
consider a correct-believed but nevertheless incorrect automatic
conversion worse than the current one where you exactly know that the
information is not accurate, I decided to leave this alone as is.

Also, there was the idea of aggregating all the individual one-file,
[...], then ChangeLog commits into aggregates, but this also can't be
done reliably in an automated fashion without a lot of manual corrections
(as could be seen in the glibc CVS to Git conversion), so I also left
that alone.

But what I did, for extra kicks, is that I rebuilt (or: reconnected) the
history of various GNU Mach branches: HEAD, oskit-branch,
gnumach-1-branch, gnumach-1-branch-Xen-branch -- including the merging
between them.  Looks nice with gitk!

Fetch the whole shebang from .
Give it a try.  Unless someone finds any issues that really need to be
corrected, these trees shall be the new basis for our collaboration!

Later, I'll push a few branches containing Hurd patches applied (libpager
/ ext2fs extensions, TLS support, ...), so that these can be easily
merged into your local working branches.  Also, I'll add branches for the
former GSoC projects -- are there any former GSoC people (CCed) who
already have done their work somewhere else than in our CVS repository,
or should I take the history contained in the CVS repository?


> Here is one additional topic I want to confirm with you all before
> committing it: the duplication of ChangeLog snippets and commit log
> messages is a pain.  However, it is not mandatory to maintain ChangeLog
> files in the VCS sources -- it's fine with the GNU Coding Standards to
> only create ChangeLog files for distribution tarballs (where one doesn't
> have access to the VCS logs anymore).  GNU Coreutils is already using
> this scheme, and I got it confirmed on the GNU-internal maintainers'
> mailing list that this is indeed fine.  When needed, the ChangeLog files
> would be created automatically from the VCS commit messages.  (We can
> steal all the mechanisms from GNU Coreutils.)
> 
> Commit messages would then have this mandatory format: [...]
> 
> Any objections?

There was a bit of support, and no objections, so that is it; see section
``Commit messages'' on
.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH 1/3] Add the ``--mount'' command line option

[Thomas Schwinge]

Hello!

On Fri, Jun 12, 2009 at 04:40:12PM +0300, Sergiu Ivanov wrote:
> On Fri, Jun 12, 2009 at 08:53:50AM +0200, Carl Fredrik Hammar wrote:
> > On Thu, Jun 11, 2009 at 09:10:24PM +0300, Sergiu Ivanov wrote:
> > > >From d0f0f5c41d9046aec765a7264914c19642adead9 Mon Sep 17 00:00:00 2001
> > > From: Sergiu Ivanov 
> > > Date: Thu, 11 Jun 2009 15:22:24 +0300
> > > Subject: [PATCH] Add the ``--mount'' command line option.
> > > 
> > > +++ b/unionmount.c
> > > @@ -0,0 +1,28 @@
> > > +/* Hurd unionmount
> > > +   The core of unionmount functionality.
> > > +
> > > +   Copyright (C) 2009 Free Software Foundation, Inc.
> > > +
> > > +   Written by Sergiu Ivanov .
> > > +
> > > +   This program is free software; you can redistribute it and/or
> > > +   modify it under the terms of the GNU General Public License version
> > > +   2 as published by the Free Software Foundation.
> > 
> > This should be:
> > 
> >This program is free software; you can redistribute it and/or
> >modify it under the terms of the GNU General Public License
> >as published by the Free Software Foundation; either version 2
> >of the License, or (at your option) any later version.
> > 
> > Note the ``or any later version'' part.
> 
> Yes, it initially was like that, but Thomas told me that the idea
> about later versions is implied... (or, actually, it was how I
> understood his remark about the ``implied *'').

Ah, what I mean was simply that there was a literal asterisk character
inside the text.  (See my Makefile patch posted earlier where I removed
it.)


> > > +   You should have received a copy of the GNU General Public License
> > > +   along with this program; if not, write to the Free Software
> > > +   Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
> > > +   USA.  */
> > 
> > I remember being told that the address has changed when I was working
> > on libchannel.  And indeed the address is different in my libchannel
> > source:
> > 
> >If not, write to the Free Software Foundation, 675 Mass Ave, Cambridge,
> >MA 02139, USA.
> > 
> > I think your using the old address but I'm not sure.  Thomas will have
> > to clarify.  Perhaps there is a definitive source somewhere.
> 
> Hm, nice... I've never heard of that change... I'll wait for what
> Thomas should say, if you don't mind...

Sure there is a definitive source:
.  So, both of you are wrong.  ;-P

Obviously, use the current address when creating new files, and then we
can sometime later bother to update all the other files in one go.  This
also need to be adjusted in the main Hurd sources, etc.


On Sat, Jun 13, 2009 at 03:53:27PM +0200, Carl Fredrik Hammar wrote:
> This time around I'll review your patch more thoroughly.

Thanks for your help, by the way!  Unless I'm noting specifically, I'm
fine with your comments.

> On Thu, Jun 11, 2009 at 09:10:24PM +0300, Sergiu Ivanov wrote:
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1,6 +1,10 @@
> >  # Hurd unionfs
> > -# Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
> > +# Copyright (C) 2001, 2002, 2003, 2005, 2009 Free Software Foundation,
> > +# Inc.
> 
> Break the line after the years instead, like so:
> 
> # Copyright (C) 2001, 2002, 2003, 2005, 2009
> #   Free Software Foundation, Inc.
> 
> As is done in other parts of the Hurd.

Also note that this is not done very consistently.  Some months ago, I
switched to simply have Emacs' M-q (fill-paragraph) do this work --
that's why I'm adding blank lines before and after the Copyright lines
when amending them (if they're not there already).

> > --- a/options.c
> > +++ b/options.c
> > @@ -51,6 +56,8 @@ static const struct argp_option argp_common_options[] =
> >"send debugging messages to stderr" },
> >  { OPT_LONG_CACHE_SIZE, OPT_CACHE_SIZE, "SIZE", 0,
> >"specify the maximum number of nodes in the cache" },
> > +{ OPT_LONG_MOUNT, OPT_MOUNT, "MOUNTEE", 0,
> > +  "start MOUNTEE and add the filesystem it publishes" },
> 
> "start the translator MOUNTEE and add it's filesystem" would be clearer
> IMHO.

I think it would also help if this comment made it clear that this is a
whole *translator command line* that is to be specified there, as
compared to only the translator binary.


Back to your latest version of the patch:

On Mon, Jun 15, 2009 at 10:39:22PM +0300, Sergiu Ivanov wrote:
> From 87963e32b39b8bc8f6a29f5033d99e7f0583c5b4 Mon Sep 17 00:00:00 2001
> From: Sergiu Ivanov 
> Date: Thu, 11 Jun 2009 15:22:24 +0300
> Subject: [PATCH] Add the ``--mount'' command line option.
> 
> * Makefile: [...]
> Update copyright information.

No need to reflect such non-functional changes in the ChangeLog / commit
message.

> * options.h (OPT_MOUNT): Add the definition.
> (OPT_LONG_MOUNT): Likewise.
> Update copyright information.
> 
> * options.c (argp_common_options): Add option ``--mount''

There is no need to put blank lines between changed files that are
related to e

[PATCH] Don't abuse $(prefix) for finding build-time files.

[Thomas Schwinge]

* Makefile: Simply have GCC #include the needed file -- the current unionfs
build system doesn't do any dependency tracking for header files anyway.
---
Hello!

On Sun, Jun 07, 2009 at 02:00:49PM +0200, Samuel Thibault wrote:
> Samuel Thibault, le Sun 07 Jun 2009 13:53:37 +0200, a écrit :
> > Sergiu Ivanov, le Sun 07 Jun 2009 13:30:12 +0300, a écrit :
> > > * Makefile: Define $prefix to be /usr if the user does not
> > > provide and override.
> > 
> > Errr, no, the GNU system uses an empty prefix by default.
> 
> (yes, the Debian GNU/Hurd system uses /usr as prefix by default, but
> that's not GNU).

... and the GNU Coding Standards mandate /usr/local as default, see
.
So let's do that: then both Debian GNU/Hurd and GNU system users have
their share on specifying prefix when building ;-).  Oh wait.  This
$(prefix) variable isn't even used for installing, but for locating a
build-time header file.  Hmpf.


On Sun, Jun 07, 2009 at 01:30:12PM +0300, Sergiu Ivanov wrote:
> +# Provide a default prefix if the user hasn't defined one.
> +ifeq ($(strip $(prefix)),)
> +prefix=/usr
> +endif

This ifeq is non-functional: you can always invoke make like ``make
prefix=/usr'' to override $(prefix) even when the Makefile
unconditionally defines ``prefix = whatever''.


To finally bring this to an end, I propose the following.  Can you please
confirm that it works for you?


Regards,
 Thomas
---
 Makefile |   16 +---
 1 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index b180072..e6d907d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,10 +1,12 @@
 # Hurd unionfs
-# Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
+#
+# Copyright (C) 2001, 2002, 2003, 2005, 2009 Free Software Foundation, Inc.
+#
 # Written by Jeroen Dekkers .
 # 
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or *
+# the Free Software Foundation; either version 2 of the License, or
 # (at your option) any later version.
 #
 # This program is distributed in the hope that it will be useful, but
@@ -58,11 +60,11 @@ $(mig-sheader-prefix)%_S.h %Server.c: %.sdefsi
-sheader $(mig-sheader-prefix)$*_S.h -server $*Server.c \
-user /dev/null -header /dev/null < $<
 
-%.sdefsi: %.defs
-   $(CPP) $(CPPFLAGS) $(MIGSFLAGS) $($*-MIGSFLAGS) -DSERVERPREFIX=S_ $< -o 
$@
-
-vpath %.defs $(prefix)/include/hurd
-
+%.sdefsi:
+   echo '#include ' | \
+ $(CPP) \
+   $(CPPFLAGS) $(MIGSFLAGS) $($*-MIGSFLAGS) -DSERVERPREFIX=S_ \
+   -x c - -o $@
 
 
 all: unionfs
-- 
1.6.0.4

Re: [PATCH 1/1] Update the bug-reporting address.

[Thomas Schwinge]

Hello!

Catching up with some emails...

On Thu, Jun 11, 2009 at 01:20:06PM +0200, Carl Fredrik Hammar wrote:
> On Thu, Jun 11, 2009 at 01:38:58PM +0300, Sergiu Ivanov wrote:
> > On Thu, Jun 04, 2009 at 04:02:31PM +0200, Carl Fredrik Hammar wrote:
> > > On Fri, May 29, 2009 at 12:34:23AM +0300, Sergiu Ivanov wrote:
> > > > >From 23763c18399985e62686282ec848c42c3a540066 Mon Sep 17 00:00:00 2001
> > > >
> > > >  const char *argp_program_version = STANDARD_HURD_VERSION (unionfs);
> > > >  const char *argp_program_bug_address =
> > > > -"Gianluca Guida ";
> > > > +"";
> > > 
> > > You could do this be simply linking to libhurdbugaddr.  Just drop
> > > the definition of argp_program_bug_address and pass -lhurdbugaddr to
> > > the linker in the Makefile.
> > 
> > Thank you for the information! However, I did exactly what Thomas told
> > me to do, so it depends on him which way to choose to handle the bug
> > address...
> 
> I'm guessing Thomas just forgot about good ol' libhurdbugaddr

Indeed, I can't say that I'm particularely fond of the existence of this
library -- at least not anymore in times now where this address is
unlikely to ever change again.  But, yes, it is there, and it is in use,
so, yes, simply do as Carl suggested above.


Regards,
 Thomas


signature.asc
Description: Digital signature

Headlines: more CSS magic wanted (was: Hurd Mission Statement)

[Thomas Schwinge]

Hello!

Hijacking this thread again: then, there is this change,
6b7cb4dbb2aa81685f93f1abb9be5251dccf1443, ``debian distro: smaller headings.'',
which does things like that:

diff --git a/hurd/running/debian.mdwn b/hurd/running/debian.mdwn
index bf21740..97d35bd 100644
--- a/hurd/running/debian.mdwn
+++ b/hurd/running/debian.mdwn
@@ -1,25 +1,25 @@
 [[!meta title="Debian GNU/Hurd"]]
 
-## Debian Resources
+### Debian Resources
 
 - Official page about the Debian GNU/Hurd port: [Debian 
GNU/Hurd](http://www.debian.org/ports/hurd/)
 
 - Debian [[FAQ]] -- Frequently Asked Questions
 
-## Installing
+### Installing

This is wrong, as -- in my understanding -- these #s are for logical
grouping and not for stating how big these headlines should be rendered
on the screen.  In my opinion, all pages (this is wrong in other pages as
well) should use a single # for their top-level headlines, ## for the
second level, and so on, and we should use some CSS magic to make them
appear not in that huge letters.  (Read: I agree that what currently is
being used for rendering # and perhaps even ## is too big.)  Can you
propose something more suitable?


Regards,
 Thomas


signature.asc
Description: Digital signature

Copyright and license conditions of mailing list texts and the like (was: Hurd Mission Statement)

[Thomas Schwinge]

On Fri, Jun 05, 2009 at 09:36:54AM +0200, Arne Babenhauserheide wrote:
> Also I added Olafs explanations in the wiki-weblog section - I hope that's ok 
> (if not, we can just remove the commits - or refactor them). 

What you could have done (attention: more Git magic forthcoming) when
committing 958bd5447e717d80bc14d4ca7257a55d6638bcc9 is to tell Git who
the original author was: git commit --author="...".  But no big deal, as
that's obvious from the commit message as well.

> http://www.bddebian.com:/~hurd-web/community/weblogs/antrik/hurd-mission-
> statement/

You didn't add the copyright and license boilerplate on that page.
Intentionally or just forgotten?

In general, not neccessarily Hurd-specific, is there consensus ``in the
Net'' and amongst lawyers on what the copyright and licensing conditions
are with respect to putting texts by individuals that appears on
projects' mailing lists or other forums, for example, email or IRC
messages, into official web pages or documentation?

I'm perfectly fine with my (Hurd related) texts being used with Copyright
FSF and whatever documentation license we are using at the moment.  Is
this OK for others as well, or do I have to ask everytime I transfer or
use texts this way?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Hurd Mission Statement

[Thomas Schwinge]

Hello!

On Fri, Jun 05, 2009 at 09:36:54AM +0200, Arne Babenhauserheide wrote:
> I just put the mission stement into the wiki 

I only did one tweak (consistently use ``GNU Hurd''), but otherwise I'm
fine with that -- both Olaf's text itself, and the appearance on the
page, so: thanks!

Of course we could have endless discussions about what everyone of us is
out for with the project, but the text Olaf came up with should be fine
for everyone to subscribe to.


> (that's the beauty of using the wiki as staging area for the website: I can 
> just change something and upload it, and if it isn't good enough for the 
> website, we can work on it till it is). 

That exactly is the idea and I'm glad that you like this system!  :-)

> http://www.bddebian.com:/~hurd-web/

Will go online at  shortly.


Regards,
 Thomas


signature.asc
Description: Digital signature

[b...@gnu.org: [Savannah-announce] Recover your repositories]

[Thomas Schwinge]

Hello!

Email is full-quoted and with my comments inlined.

| - Forwarded message from Sylvain Beucler  -
| Date: Tue, 2 Jun 2009 09:16:55 +0200
| Subject: [Savannah-announce] Recover your repositories
| 
| The system is now completely functional.
| It's time to decide what to do with your data.
| (see first explanations at 
http://lists.gnu.org/archive/html/savannah-users/2009-05/msg00023.html)
| 
| 
| Please discuss and send questions at savannah-us...@gnu.org !
| 
| For import requests: see below, you need to send a support request via
| the web interface.
| 
| 
| 
| Basically your choices are:
| a) you can use the backup from April 29

This is good enough for us, because...

| b) you can use our latest (incomplete) backup from May 29
| c) you can import another backup you have
| d) you can wait a few days until we possibly recover latest data from the 
crashes disk (nothing is sure though). More details about this later.
| 
| 
| Here's how do it for the various VCSs:
| 
| * CVS:
| a) The version from 29 April in the 'backup-20090429' subdirectory.
| b) The version from 29 May in the 'backup-20090529-incomplete' subdirectory.
| c) Upload your backup in your download area (SFTP) for us to import
| 
| Access commands:
| cvs -d:pserver:anonym...@cvs.sv.gnu.org:/sources/backup-20090429/your_project 
co your_module
| cvs 
-d:pserver:anonym...@cvs.sv.gnu.org:/sources/backup-20090529-incomplete/your_project
 co your_module
| rsync rsync://cvs.sv.gnu.org/sources/backup-20090429/your_project/

... this version (backup-20090429) is sufficiently recent for us, as no
checkins to the CVS repository have been done after this date, due to the
(still) ongoing CVS to Git migration.  (By the way, I'm currently (a)
waiting for a clean-up script by Jim Meyering, and (b) tracking down,
with the help of its author, either a bug in the conversion program, or a
repository corruption in the gnumach module.)  Also, I diffed the
backup-20090429 rsync tree against my local rsync mirror and found it to
be in a correct state.

| rsync rsync://cvs.sv.gnu.org/sources/backup-20090529-incomplete/your_project/
| 
| IN ALL CASES: post a support request, authenticated (i.e. login first) at 
https://savannah.gnu.org/support/?func=additem&group=administration with 
category "RECOVERY: CVS/SVN". Requests send by mail or in the wrong category 
won't be processed.
| 
| If after 2 weeks we didn't receive an answer for your project, we'll 
reinstall the latest backup we have.
| 
| 
| * SVN:

[Snipped, as not relevant for us.]

| * Git:
| a) We installed the version from 29 April.
| b) You can attempt to recover from the partial 29 May backup: 
http://git.savannah.gnu.org/r/backup-20090529-incomplete/
| c) You can push a local version if you have one (git push --all; git push 
--tags)
| 
| You can import the repository directly, without our help.

... exactly! (thanks DVCS!); for the web pages repository I already
pushed the missing changes, and for the other repositories the same can
be done, and I'll take care of that as soon as I have the conversion
finished properly.  Neal, you can also simply push your viengoos and
viengoos-on-bare-meal branches back into the Viengoos Git repository.

| * Mercurial:

[Snipped, as not relevant for us.]

| * WebCVS:
| 
| We plan to either recover the data from disk, or failing that, manually 
commit the latest version at www.gnu.org and www.nongnu.org.

... we don't care, as we have all the history in our web pages' Git
repository and use the CVS one only as a transport mechanism to get the
files to the web server.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH 5/5] Changed argp parsing policy

[Thomas Schwinge]

Hello!

On Tue, May 26, 2009 at 11:31:59PM +0300, Sergiu Ivanov wrote:
> diff --git a/Makefile b/Makefile
> index b7e5716..7b7ce01 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -21,7 +21,7 @@
>  # USA.
> 
>  # Get the information from under /usr.
> -prefix = /usr/
> +prefix = /usr

Aha, here we go ;-).  But please put it like this into your first commit.

> -OBJS = main.o node.o lnode.o ulfs.o ncache.o netfs.o \
> -   lib.o options.o pattern.o stow.o update.o
> +OBJS = main.o node.o lnode.o ulfs.o ncache.o netfs.o lib.o options.o \
> +   pattern.o stow.o update.o unionmount.o

This is not really that important here (and the same applies to my other
nit-picking by the way -- but you chose to be with those picky Hurd
people, didn't you?), but as a guideline for forthcoming situations, and
to make reviewing your changes easier: try to preserve as much as is
possible from the previous version.  (As long as is sensible, of course.)

Make this change look like this:

>  OBJS = main.o node.o lnode.o ulfs.o ncache.o netfs.o \
> -   lib.o options.o pattern.o stow.o update.o
> +   lib.o options.o pattern.o stow.o update.o unionmount.o

Or like this:

>  OBJS = main.o node.o lnode.o ulfs.o ncache.o netfs.o \
> -   lib.o options.o pattern.o stow.o update.o
> +   lib.o options.o pattern.o stow.o update.o \
> +   unionmount.o

That way it is easier for the reviewer to grasp that you simply added
unionmount.o and didn't do any other changes to the list.

Of course, it is also possible to introduce a commit like ``Reformat OBJS
for better readability'', or ``... for better use of display width'', or
whatever, before doing your change.  And of course, that is always a
trade-off between simply doing a change that is correct and works (your
original version) and something like ``formally correctly doing a
change''.

I hope you don't mind if I give comments like these.  You don't have to
subscribe to all of them right now, but perhaps you can keep such things
in the back of your head.


> diff --git a/main.c b/main.c
> index e407926..43e4846 100644
> --- a/main.c
> +++ b/main.c

I forgot in my earlier email: copyright years updates.  Samuel also
forgets them all the time, but perhaps you can do better?  ;-)


> diff --git a/options.c b/options.c
> index beed9f4..c12974c 100644
> --- a/options.c
> +++ b/options.c
> @@ -6,12 +6,12 @@
> modify it under the terms of the GNU General Public License as
> published by the Free Software Foundation; either version 2 of the
> License, or * (at your option) any later version.
> -
> +

Please try to avoid such whitespace changes.  If there is really
something that needs to be changed, then do that separately.

> @@ -78,7 +80,7 @@ argp_parse_common_options (int key, char *arg,
> struct argp_state *state)
>static int ulfs_flags = 0, ulfs_mode = 0, ulfs_modified = 0,
>  ulfs_match = 0, ulfs_priority = 0;
>static struct patternlist ulfs_patternlist =
> -{
> +{

Again, and some more below.


>  const char *argp_program_version = STANDARD_HURD_VERSION (unionfs);
> -const char *argp_program_bug_address =
> +const char *argp_program_bug_address =
>  "Gianluca Guida ";

Please, while you're at it, push a commit to master to change that to
.


> diff --git a/unionmount.c b/unionmount.c
> new file mode 100644
> index 000..a8939f8
> --- /dev/null
> +++ b/unionmount.c
> @@ -0,0 +1,38 @@
> +/*---*/
> +/* Hurd unionmount */
> +/* The core of unionmount functionality. */
> +/*---*/
> +/* Copyright (C) 2009 Free Software Foundation, Inc.  Written by
> +   Sergiu Ivanov .

Please add an empty line between the copyright line and the written by
line.


> +   This program is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU General Public License as
> +   published by the Free Software Foundation; either version 2 of the
> +   License, or * (at your option) any later version.

There is an embedded asterisk.  (Switching to GPLv3+ is another
discussion, for later on.)

Same for the other new file, unionmount.h.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH 3/5] Made unionmount always include the underlying node

[Thomas Schwinge]

Hello!

On Tue, May 26, 2009 at 11:31:52PM +0300, Sergiu Ivanov wrote:
> diff --git a/netfs.c b/netfs.c
> index 89d1bf6..7c375d2 100644
> --- a/netfs.c
> +++ b/netfs.c
> @@ -71,9 +71,9 @@ netfs_append_args (char **argz, size_t *argz_len)
>   {
> if (ulfs->path)
>   err = argz_add (argz, argz_len, ulfs->path);
> -   else
> +   /*  else
>   err = argz_add (argz, argz_len,
> - OPT_LONG (OPT_LONG_UNDERLYING));
> + OPT_LONG (OPT_LONG_UNDERLYING));*/

I suggest to not comment out code like this.  It has problems with
embedded comments, and probably other (stylistic) issues.  If is is
indeed temporary, then I suggest to use something like:

#if 0
/* Disabled because of X.  */

Or, as I guess in this case, if you'll never going to need this again for
unionmount, then simply really remove the code.  In case that you should
later need to read it again, or in fact need to recover recover it, then
there is git log -p, git revert, and friends.

This commit as well as the other ones are of course fine for your
unionmount branch.  (I did not check them for functionality.)


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH 2/5] Updated the Makefile (unionfs -> unionmount)

[Thomas Schwinge]

Hello!

On Tue, May 26, 2009 at 11:31:54PM +0300, Sergiu Ivanov wrote:
> diff --git a/Makefile b/Makefile
> index 3129031..b7e5716 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,6 +1,9 @@
> -# Hurd unionfs
> -# Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
> -# Written by Jeroen Dekkers .
> +# Hurd unionmount
> +#
> +# Copyright (C) 2001, 2002, 2003, 2005, 2009 Free Software Foundation,
> +# Inc.  Written by Jeroen Dekkers .

Oh, there is the copyright year update.  Please put it into your former
patch, though.  (And don't mangle the ``Written by...'' into the same
line.)

Other wise this patch is, of course, fine for your master-unionmount (or
whatever you'll name it) branch.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH 1/5] unionfs now builds successfully

[Thomas Schwinge]

Hello!

On Tue, May 26, 2009 at 11:31:49PM +0300, Sergiu Ivanov wrote:
> diff --git a/Makefile b/Makefile
> index b180072..3129031 100644
> --- a/Makefile
> +++ b/Makefile

Don't forget to update the list of copyright years.

> +# Get the information from under /usr.
> +prefix = /usr/

No trailing slash.

Ugly, but yeah.  Eventually, I plan to transition all that stuff to
Automake.  For the Hurd proper, there is already some work by Jeff Bailey
in that area and I also extended that, but one open issue is to teach
Automake to cooperate with mig (if interested, see the GNU Mach build
system for the gory details of how I'm doing this at the moment...) --
which is needed for unionfs: see the Makefile rules where this prefix
variable is used.

But for now, with these two changes I mentioned above, plus a proper
commit message (see again
,
``Behavior, Commit messages''), this is fine to be installed into
unionfs.git's master branch.  Please send your patch again, and then I'll
OK it for you to push into there.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [PATCH 0/5] Change unionfs argument handling policy

[Thomas Schwinge]

Hello!

On Tue, May 26, 2009 at 11:31:45PM +0300, Sergiu Ivanov wrote:
> I am working on unionmount project, which is (at the moment) a branch
> in unionfs git repository
> (http://git.savannah.gnu.org/cgit/hurd/unionfs.git/). The goal of
> unionmount is to mount a translator is such a way that the underlying
> filesystem gets merged with the (virtual) filesystem published by the
> translator.

Here is that project's description, by the way:



> I'm posting a series of patches which bring unionfs to an intermediate
> stage on its road towards unionmount

In the end, how much code will be shared between unionfs and unionmount?
Would it perhaps make sense -- in the long term, need not be right now --
to transfer the guts of unionfs into a library that can then be shared
between unionfs and unionmount?

For now, as you forked the unionfs code, I suggest development to happen
in the unionfs Git repository, on a separate branch, named perhaps
master-unionmount (going with my naming scheme detailed on
 --
other suggestions are still welcome! -- this would mean that it is
branched off of master and has the topic unionmount).  If working on this
branch should become unwieldy for a reason or another, we can easily move
that branch into a separate unionmount Git repository.


> OTOH, the general command line handling policy should be different for
> unionmount. It should be similar to what settrans does (and this is
> very much different from how unionfs parses its command line). In this
> series of patches there is one which tailors unionfs's command line
> handling policy to the needs of unionmount.

So, unionmount will in fact be a melange of what unionfs is at the
moment, but limited to one additional (implicit) filesystem (in unionfs
parlance) and all that in the context of how settrans is used at the
moment?  Wouldn't even a syntax like ``settrans --unionmount ...'' make
sense perhaps?

I guess that would be the first thing to come up with some examples --
and I have to admit that I don't completely grok those on the web pages
mentioned above whan reading them for the first time -- that this
functionality is useful for.  Feel invited to enhance that web page.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Fwd: Debian Installer - Hurd

[Thomas Schwinge]

[Posting this to bug-hurd -- Mahesh, I hope that's fine?]


Hello!

On Sat, May 23, 2009 at 11:06:57AM +0530, മഹേഷ് മുകുന്ദന് | Mahesh M wrote:
> I was able to re-master a live cd, boot it, create a ramdisk, create a
> chroot environment in ramdisk, run sh in chroot, fdisk an attached hdd and
> mount it.
> 
> Now this is what GNU/Linux does in the current installer and thus it can be
> completely replaced. Current method DO NOT install grub. In Hurd, Grub is
> broken too.. (It doesnt know how to talk to Mach -- tschwinge). As per
> current installation, a baseGNU.tgz is uncompressed and dumped into the
> target hdd, from where a "native-install" script is used to configure some
> of the files. This can be done as of now.

Great!  Please take some minutes to properly document what you've done
and how you've done that, so that we can put this documentation online.
(Just talk to me and I'll tell you where to put it.)


> Praveen: When I run dbootstrap from within Hurd, I do get all the "required"
> file and the bin, dev, etc, usr etc folders created. But error occurs when
> it configures the packages. The dbootstrap log shows some broken pipe error
> and resource busy error. Will attach the log file soon. You had successfully
> run dbootstrap right (as the webpage tells).

That sould like some essential translators (like pflocal on
/servers/socket/1) aren't running.


> Can anyone fix the Grub. I am too young for that!

Too young, hehe ;-).  And I'm getting old, it seems: on 2005-08-23,
nearly four years ago, it was the last time that I had been looking at
porting GRUB to run on GNU/Hurd...  Anyways, I now put that stuff up on
.  I
don't think that fixing the remaining bits would even be that difficult.
Perhaps Barry is willing to do that and learn a bit of programming for
enabling GRUB to access our disk drives?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Google Summer of Code 2009; how to fork off the unionfs code base

[Thomas Schwinge]

Hello!

On Fri, May 15, 2009 at 09:25:54PM +0300, Sergiu Ivanov wrote:
> On Tue, Apr 28, 2009 at 1:42 AM, Thomas Schwinge  wrote:
> > <http://git.savannah.gnu.org/cgit/hurd/unionfs.git/> -- but please do not 
> > yet
> > push changes there.

I see no reason to any longer hold off with pushing changes into this
particular repository.  However, this doesn't mean that it's also true
for the other Hurd repositories (which I might still decide to
re-convert).


> I beg my pardon for a bit of a silly question: if I want to fork
> unionfs from this repository, should I use git clone, git checkout or
> git fetch to get the source files from the repository you
> created?.. And, unfourtunately, I'm rather at a loss as to what should
> come next...

Here's what one'd do if going with my suggestions from
<http://www.gnu.org/software/hurd/rules/source_repositories.html>:

$ git clone --no-checkout 
ssh://git.savannah.gnu.org/srv/git/hurd/unionfs.git
$ cd unionfs/
$ git checkout -b TAG origin/master
$ ...
$ git push TAG

TAG would either be master-scolobb, or master-scolobb-FEATURE1, or
master-scolobb-gsoc2009, or master-scolobb-gsoc2009-FEATURE1, or simply
master-FEATURE1, or...

> FYI, I want to create a new repository at github...

Of course you're free to do that, but why not simply use the Savannah
repository?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Context switching tests (especially perfomance measuring and FPU/MMX/SSE/etc)

[Thomas Schwinge]

Hello!

On Sat, May 02, 2009 at 12:43:47AM +0400, Evgeniy Ivanov wrote:
> Does Hurd (GnuMach) has such tests? I wasn't able to locate them.

What Samuel said.  Additionally: in the Hurd repository there is an old
benchmark for measuring fork performance: benchmarks/forks.c.  This
operates on a much more high-level interface, of course.

Having results from such benchmarking and profiling topics would be
really helpful.

Throwing in a random idea: how difficult do people estimate it to be to
port the oprofile framework, for example?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: [bug #19255] Booting a sub-hurd made Mach crash

[Thomas Schwinge]

Hello!

On Sat, May 02, 2009 at 01:11:58PM +, Samuel Thibault wrote:
> Update of bug #19255 (project hurd):
> 
>   Status:None => Duplicate  
> 
> ___
> 
> Follow-up Comment #1:
> 
> Most probably a duplicate of #19426: memory allocation in Mach is not
> very flexible.

Well, bug-reporting wise it can't be a duplicate -- as 19255 < 19426, but
nevertheless this report of mine wasn't really helpful, so no problem
with closing it.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Google Summer of Code 2009; how to fork off the unionfs code base

[Thomas Schwinge]

Hello!

On Thu, Apr 23, 2009 at 09:49:01AM +0200, I wrote:
> So, I'd rather go for the conversion method, to not hide the previous
> history.  And, as I'm already in this dirty business -- a bunch of the
> main Hurd's repositories and their branches have already been published,
> by the way -- I'm hereby offering to do the conversion for you.  Stay
> tuned.

 -- but please do not yet
push changes there.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Moving to git

[Thomas Schwinge]

Hello!

A bit of a status update.

The CVS to Git conversion is mostly finished.

There are still some quirks with converting the
gnumach-1-branch-Xen-branch, but I'm working on resolving these with the
help of the conversion program's author, Simon 'corecode' Schubert, whose
fromcvs / rcsparse combo I finally ended up using, by the way.


Here is one additional topic I want to confirm with you all before
committing it: the duplication of ChangeLog snippets and commit log
messages is a pain.  However, it is not mandatory to maintain ChangeLog
files in the VCS sources -- it's fine with the GNU Coding Standards to
only create ChangeLog files for distribution tarballs (where one doesn't
have access to the VCS logs anymore).  GNU Coreutils is already using
this scheme, and I got it confirmed on the GNU-internal maintainers'
mailing list that this is indeed fine.  When needed, the ChangeLog files
would be created automatically from the VCS commit messages.  (We can
steal all the mechanisms from GNU Coreutils.)

Commit messages would then have this mandatory format:

One-line summery.
Blank line.
ChangeLog-like list of changes, but without leading tabs.

The header line of each ChangeLog (DATE NAME EMAIL) snippet will also be
stripped off of the commit message, and instead the author and committer
of a change, together with the dates, will be maintained natively by Git.

Example:

commit 3054767a46e0142cacef895c13edb4391435c722
Author: Gianluca Guida 
AuthorDate: Thu Jun 30 18:49:55 2005 +
Commit: Gianluca Guida 
CommitDate: Thu Jun 30 18:49:55 2005 +

Frobnicate the foo.

* frob.c (foo): Frob it.
* oldfoo.c [OLD] (oldfoo): Likewise.
[OLD_OLD_FOO] (oofoo): Permute every second word with itself, and
beginning with the tenth line, every third one also.  Pure
nonsense.

The indentation here is only for readability, but not in the actual
commit messages.

Any objections?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: mremap

[Thomas Schwinge]

Hello!

On Sun, Apr 26, 2009 at 11:37:27AM -0700, Roland McGrath wrote:
> mremap cannot be defined correctly in terms of mmap and munmap.

Not the complete interface, for sure.  And even for the specific bit I
mentioned I'm not sure it would be possible at all (thinking about
preserving MAP_* and PROT_* flags).

> It is not in the common GNU API/ABI, only in Linux.
> The malloc code is full of HAVE_REMAP conditionals.
> Just fix whatever the new case is to properly conditionalize its use.

Prolem gone: Jakub Jelinek already did that (unconditionally).


Regards,
 Thomas


signature.asc
Description: Digital signature

mremap

[Thomas Schwinge]

Hello!

/home/thomas/tmp/source/glibc/work.new.build.gnu-1/locale/locarchive.o: In 
function `file_data_available_p':
/home/thomas/tmp/source/glibc/work.new/locale/programs/locarchive.c:263: 
undefined reference to `mremap'
/home/thomas/tmp/source/glibc/work.new.build.gnu-1/locale/locarchive.o: In 
function `enlarge_archive':
/home/thomas/tmp/source/glibc/work.new/locale/programs/locarchive.c:315: 
undefined reference to `mremap'

That is, glibc is now unconditionally using mremap (in locale code).
However, mremap is not available on GNU/Hurd.  It is a syscall for Linux.

Why isn't there a generic ENOSYS stub for mremap?  I attached one.  How
to do symbol versioning?  sysdeps/unix/sysv/linux/Versions has it defined
for GLIBC_2.0.  What to do now in misc/Versions?

Other uses of mremap: in the malloc code, #if linux is used.  The other
use of mremap in libio/fileops.c is protected by _G_HAVE_MREMAP.  This
definition (previously also #if linux) was introduced by Marcus in 2004,
c.f. <http://sourceware.org/ml/libc-alpha/2004-11/msg00065.html>.  This
definiton of _G_HAVE_MREMAP still is the only difference between
sysdeps/gnu/_G_config.h and the then-introduced
sysdeps/mach/hurd/_G_config.h.  In libio/fileops.c, if _G_HAVE_MREMAP is
not defined, a fallback code-path of munmap followed by mmap is chosen.
Wouldn't it be possible to generalize this (for the MREMAP_MAYMOVE case)
in the otherwise-ENOSYS stub?


2009-04-26  Thomas Schwinge  

* misc/Makefile (routines): Add mremap.
* misc/Versions: TODO.
* misc/mremap.c: New file.

diff --git a/misc/Makefile b/misc/Makefile
index 1357634..240ac79 100644
--- a/misc/Makefile
+++ b/misc/Makefile
@@ -55,7 +55,8 @@ routines := brk sbrk sstk ioctl \
chflags fchflags \
insremque getttyent getusershell getpass ttyslot \
syslog syscall daemon \
-   mmap mmap64 munmap mprotect msync madvise mincore remap_file_pages\
+   mmap mmap64 munmap mprotect msync madvise mincore mremap \
+   remap_file_pages \
mlock munlock mlockall munlockall \
efgcvt efgcvt_r qefgcvt qefgcvt_r \
hsearch hsearch_r tsearch lsearch \
diff --git a/misc/mremap.c b/misc/mremap.c
index e69de29..7d40f0b 100644
--- a/misc/mremap.c
+++ b/misc/mremap.c
@@ -0,0 +1,38 @@
+/* Copyright (C) 2009 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#include 
+#include 
+#include 
+
+/* Remap pages mapped by the range [ADDR,ADDR+OLD_LEN) to new length
+   NEW_LEN.  If MREMAP_MAYMOVE is set in FLAGS the returned address
+   may differ from ADDR.  If MREMAP_FIXED is set in FLAGS the function
+   takes another paramter which is a fixed address at which the block
+   resides after a successful call.  */
+void *
+__mremap (void *__addr, size_t __old_len, size_t __new_len,
+   int __flags, ...)
+{
+  __set_errno (ENOSYS);
+  return MAP_FAILED;
+}
+
+stub_warning (mremap)
+#include 
+weak_alias (__mremap, mremap)


Regards,
 Thomas


signature.asc
Description: Digital signature

Google Summer of Code 2009; how to fork off the unionfs code base

[Thomas Schwinge]

Hello!

On Wed, Apr 22, 2009 at 02:05:44PM +0300, Sergiu Ivanov wrote:
> I'm going to start implementing the VFS-style union mount functionality
> (http://preview.tinyurl.com/cpftg2).

Congratulations for having gotten this GSoC project accepted!  Sergiu
will be our only GSoC student for this summer.  As he has, through his
previous work, already proven during the last year that he's capable of
working on Hurd stuff, I have no doubt that it will be a success both for
him and for us.  :-)


> The current strategy is based on
> forking off the unionfs code base (retrieved from
> http://www.nongnu.org/hurdextras/#unionfs). I am going (rather
> naturally) to use git as the VCS for my project, which rises the
> following question: how do I do the forking itself? Do I have to convert
> the CVS repository of unionfs to git, or may I create an empty
> repository, do a big push of all unionfs code there, and start working
> in this repository?

As far as I can tell, from a quick inspection, the copyright for all
changes to the unionfs code is assigned to the FSF, so we can safely
import that next to the main Hurd repositories.

So, I'd rather go for the conversion method, to not hide the previous
history.  And, as I'm already in this dirty business -- a bunch of the
main Hurd's repositories and their branches have already been published,
by the way -- I'm hereby offering to do the conversion for you.  Stay
tuned.


Regards,
 Thomas


signature.asc
Description: Digital signature

[bug #17646] glibc: ``-z relro''

[Thomas Schwinge]

Update of bug #17646 (project hurd):

  Status:None => Fixed  
 Assigned to:None => sthibaul   
 Open/Closed:Open => Closed 

___

Follow-up Comment #7:

Samuel would eventually also hit this relro problem, but then also come up
with a fix: 


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/

Re: Getting libpthread working again

[Thomas Schwinge]

Hello!

On Sun, Apr 12, 2009 at 08:37:40PM +0200, Samuel Thibault wrote:
> Thomas Schwinge, le Sun 12 Apr 2009 17:32:12 +0200, a écrit :
> > PPS: While digging through the libpthread code I wondered whether for the
> > Hurd servers cthreads to pthread migration PTHREAD_THREADS_MAX being
> > defined to 64 might be too small for some heavily multi-threaded Hurd
> > servers?
> 
> Where is that defined to 64?

Sorry, ignore that; I confused _POSIX_THREAD_THREADS_MAX getting defined
(in pt-sysdep.h) with PTHREAD_THREADS_MAX getting checked (in
pt-alloc.c:__pthread_alloc).


Regards,
 Thomas


signature.asc
Description: Digital signature

Getting libpthread working again

[Thomas Schwinge]

Hello!

When linking the pthread tests against a libpthread built (with Samuel's
TLS patches) from CVS HEAD (or any of the Viengoos branches, for that
matter) I always get this:

$ ./test-1
test-1: ../../HEAD/libpthread/sysdeps/mach/hurd/i386/pt-setup.c:103:
__pthread_setup: Unexpected error: (ipc/send) invalid destination
port.
Aborted
$ ./test-1-static 
test-1-static:
../../HEAD/libpthread/sysdeps/mach/hurd/i386/pt-setup.c:103:
__pthread_setup: Unexpected error: (ipc/send) invalid destination
port.
Aborted

I tracked this down to the 2008-08-16 __pthread_free_threads change --
apparently nobody ever tried to use the CVS HEAD libpthread since then?
(We absolutely need to come up with better automated testing methods...)
The pthread library was now trying to reuse kernel threads that have been
invalidated before.  I created the attached patch to get that fixed again
(plus the malloc to calloc patch needed for CVS HEAD).  Neal, is this
approach correct?  I have stolen the thread_suspend thing from Viengoos
-- is that correct for Mach as well?  (And the while (1) loop is
superfluous for all variants, isn't it?)  At least, this way all of the
libpthread test suite programs complete to satisfaction, both dynamically
and statically linked.

diff --git a/sysdeps/mach/pt-thread-dealloc.c b/sysdeps/mach/pt-thread-dealloc.c
index 55d8c4d..0c4a4fc 100644
--- a/sysdeps/mach/pt-thread-dealloc.c
+++ b/sysdeps/mach/pt-thread-dealloc.c
@@ -38,4 +38,6 @@ __pthread_thread_dealloc (struct __pthread *thread)
  assert.  */
   __mach_port_destroy (__mach_task_self (),
   thread->wakeupmsg.msgh_remote_port);
+
+  thread->have_kernel_resources = 0;
 }
diff --git a/sysdeps/mach/pt-thread-halt.c b/sysdeps/mach/pt-thread-halt.c
index 973cde1..a9c3858 100644
--- a/sysdeps/mach/pt-thread-halt.c
+++ b/sysdeps/mach/pt-thread-halt.c
@@ -32,6 +32,21 @@
 void
 __pthread_thread_halt (struct __pthread *thread)
 {
-  error_t err = __thread_terminate (thread->kernel_thread);
-  assert_perror (err);
+  if (thread->have_kernel_resources)
+{
+  if (thread == _pthread_self ())
+   {
+ while (1)
+   {
+ error_t err = __thread_suspend (thread->kernel_thread);
+ assert_perror (err);
+ assert (! "Failed to suspend self.");
+   }
+   }
+  else
+   {
+ error_t err = __thread_terminate (thread->kernel_thread);
+ assert_perror (err);
+   }
+}
 }


Regards,
 Thomas


PS: Please, don't install patches into the CVS repositories at the
moment, due to the CVS to git migration.


PPS: While digging through the libpthread code I wondered whether for the
Hurd servers cthreads to pthread migration PTHREAD_THREADS_MAX being
defined to 64 might be too small for some heavily multi-threaded Hurd
servers?


PPPS: Happy easter!


signature.asc
Description: Digital signature

[bug #25961] fatfs truncating files

[Thomas Schwinge]

URL:
  

 Summary: fatfs truncating files
 Project: The GNU Hurd
Submitted by: tschwinge
Submitted on: So 22 Mär 2009 13:10:03 CET
Category: Hurd Servers
Severity: 3 - Normal
Priority: 5 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Reproducibility: Every Time
  Size (loc): None
 Planned Release: None
  Effort: 0.00
Wiki-like text discussion box: 

___

Details:

In a QEMU system, accessing the same file through ext2fs (backed by a disk
partiton image file) and fatfs (on-the-fly generated by QEMU from a directory
hierarchy), these files generally are reported by cmp to differ at ``char
8193''.  Copying such a file off of the fatfs will result in a bus error and
the file being truncated to 32768 bytes.

The problem is likely to be in fatfs, as GRUB can successfully access and
load files off of the QEMU-generated fatfs.





___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/

Latest Xen commit

[Thomas Schwinge]

Hello Samuel!

First, you latest gnumach-1-branch-Xen-branch commit did not show up on
commit-hurd, AFAICT.  But you probably don't have an explanation for
that.

Second, trying to boot this I get: ``Error: (2, 'Invalid kernel',
'elf_xen_addr_calc_check: ERROR: ELF start or entries are out of
bounds.\n')'', both without and with --enable-pseudo-phys.


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: Moving to git

[Thomas Schwinge]

Hello!

On Tue, Mar 10, 2009 at 04:33:51AM +0100, olafbuddenha...@gmx.net wrote:
> On Sat, Feb 28, 2009 at 06:11:07PM +0100, Thomas Schwinge wrote:
> > And I'm seeing the same (I think) problems: converting gnumach with
> > git-cvsimport will yield an unusable gnumach-1-branch -- on which you
> > would still find all the oskit files that are not present in the CVS
> > branch. [...]
> 
> Have you made any progress with that?

I threw parsecvs into the pool of possible tools to use.  From a quick
glance, it gave the best results so far, but unfortunately also exhibits
one major problem: it gets the branch-off of gnumach-1-branch from HEAD
too late, thus on the first commit on the then-new gnumach-1-branch, all
files that have been added on HEAD in the mean time (including the huge
merge-in of oskit-branch -- the reason for creating the
gnumach-1-branch).  Talking to Keith Packard (parsecvs' author), he also
didn't have an immediate explanation -- it might be due to CVS repository
corruption.  Also, the problems that the other conversion tools are
having might be due to that.  Either I get this potential error located
and corrected in the RCS *,v files, or perhaps I'm simply -- as it's a
one-time-only thing -- able to remodel a to-git converted repository into
the right shape manually.


> I'm not sure whether you saw my note on IRC: I suggest converting the
> Hurd repository only for now, and postpone gnumach until we have a
> solution for this problem. They are independent enough that we don't
> need to delay one because of the other...

I agree.


> Potential GSoC students will (hopefully) start popping up in a couple of
> days, and I really want to be able to point them to the Git repository
> right away -- at least for the Hurd itself...

I have some university work to be done right now, but I'll try to
schedule some time for this later today.


Regards,
 Thomas


signature.asc
Description: Digital signature

Google Summer of Code 2009

[Thomas Schwinge]

Hello!

On Fri, Mar 06, 2009 at 10:57:32AM +0100, Arne Babenhauserheide wrote:
> Am Freitag 06 März 2009 06:32:44 schrieb olafbuddenha...@gmx.net:
> > > downloaded more than 2000 times last month.
> >
> > Interesting -- I wonder where these come from :-)
> 
> Same for me, but I generally only access my logs via the supplied usage 
> statistics, so I can't easily check the full logs. 

Perhaps Google is indexing ISO images by now?  ;-)


> > > Besides: Is anyone already working on an application for GSoC 2009?
> >
> > Yes, I started a couple of days ago. (Yeah, my reply is a bit late... It
> > would have been "not yet", if I had replied timely ;-) )
> 
> Many thanks for taking it up! 
> 
> I'll gladly doublecheck and proofread it; please post, once you get to a 
> point, where we can comment on it. 

It's in the web pages (former wiki) repository, in community/gsoc/.  I do
know that Olaf likes to use them, but what about making these texts more
formally appealing and remove all (or most of) the smileys?


Olaf, again, I'm not sure if I mentioned this already: I'd offer to
fulfill the administrator role again.


Also, we need mentors.  Samuel?  Others?  Neal, do you want to come up
with projects for viengoos?


Regards,
 Thomas


signature.asc
Description: Digital signature

Re: glibc patches

[Thomas Schwinge]

Hello!

On Sat, Feb 28, 2009 at 05:41:56PM +0100, I wrote:
> what about going a different route and really go ahead and
> publish a glibc fork for Hurd use?  I think I would base this on the
> official glibc git mirror and publish it again from the Hurd Savannah git
> repository -- a waste of disk space, but oh well.  Then the Debian glibc
> could (for the Hurd) simply use this (or automatically create a diff
> against the official repo) instead of maintaining all the independent
> patches.

Let me say again that this fork would only be so that we can continue
working more effectively.  Of course, we would continue submitting all
patches to the main glibc.


> Nevertheless, for now, as I can't commit to the Debian glibc SVN repo, I
> send this to you, Samuel.  Here are comments on some of the patches from
> [glibc]/trunk/debian/patches/hurd-i386/:

Another one: as per a recent glibc HEAD change, our upstream posix_opt.h
was already changed by Ulrich, but now in Debian's
hurd-i386/local-pthread_posix-option.diff, _POSIX_THREADS should no
longer be defined to 200112L, but to 200809L instead.  If we advertize
libpthread in there, should we do so in there for other _POSIX_* likewise
as well?  I'm not familiar with that interface, and I didn't check yet.


Regards,
 Thomas


signature.asc
Description: Digital signature