Re: unionmount branches
Hi, On Sun, Oct 25, 2009 at 06:10:42PM +0200, Sergiu Ivanov wrote: > On Sat, Oct 24, 2009 at 06:46:49AM +0200, olafbuddenha...@gmx.net > wrote: > > While I do think that such main a "unionmount" branch is probably a > > good idea, it should contain only the "approved" patches; while > > those still in development would better be placed in true topic > > branches... > > OK. I'll stick to this in the future. Shall I move the yet > not-completely-approved patches away from master-unionmount into > corresponding topic branches? I think so. However, it's probably better not to change the existing master-unionmount branch, but rather drop it alltogether and create a new one with a different name once you actually start adding the approved patches. Otherwise, people who already checked out the original branch will get in trouble... (Also, I still don't get the point of the "master-" prefix. This is not CVS, where we needed to remember where the branch comes from, as it was hard to figure it out from history; and it was crucial to know, because merging had to be handled in a strictly controlled manner to work at all...) -antrik-
Re: unionfs: ULFS information storage issues
Hi, On Mon, Aug 17, 2009 at 01:03:30PM +0300, Sergiu Ivanov wrote: > If one would like to keep *both* the information about the filesystems > *and* the ports to their root nodes in *a single* place, one would > have two choices: either add something like a ``port'' field to each > entry in the ulfs_chain, thus duplicating the port list in the > netfs_root_node and still leaving the necessity of synchronizing > things explicitly; or keep the information about the filesystems (i.e. > the information stored in ulfs_chain) in *every* node, thus > duplicating the same bits of information across a (potentially) large > number of locations. Obviously we can't keep the information for all the nodes and for the constituent filesystmes in one place, considering that there are several nodes per filesystem. All we want is to make sure that the information in the list of any particular node and in the list of filesystems can be easily associated. I can see at least three ways to do it: - Make sure that the per-node lists can also easily be addressed by a numeric index, so we can read both the filesystem list and the per-node lists with a simple loop counter. - Make sure that it's easy to figure out the numeric index of any given per-node list entry, so when iterating the per-node list, we can directly look up the corresponding entry in the filesystem list without having to keep an extra counter. - Let the per-node entries keep pointers to the entries in the filesystem list, so we can access them directly when iterating the per-node lists. -antrik-
Re: [PATCH 2/3] Start the mountee in a lazy fashion.
Hi, On Mon, Aug 17, 2009 at 07:15:09PM +0300, Sergiu Ivanov wrote: > On Sun, Aug 16, 2009 at 07:42:30PM +0200, olafbuddenha...@gmx.net wrote: > > On Mon, Aug 03, 2009 at 08:41:55PM +0300, Sergiu Ivanov wrote: > > > Subject: [PATCH 2/3] Start the mountee in a lazy fashion. > > > > This title line is not very helpful. The important point is that > > this patch adds the code for starting the mountee. > > AIUI, this title line does say that some code for starting the mountee > is added. Or do I understand something wrong? The fact that you mention the specific detail "in a lazy fashion", creates the impression that this is the major point -- it sounds like the purpose of this patch is changing the code to use "lazy fashion" instead of some other approach used before... It's not at all clear that this patch adds the mountee starting code for the first time. > I changed the title of this patch because the very first one -- ``Add > the code for starting up the mountee'' -- is too verbose (almost every > patch *adds* some code). I don't think it is too verbose. In either case, I don't quite understand that you try to make it less verbose by adding more detail?... :-) "Add mountee startup" or "implement mountee startup" would be perfectly fine -- saying the same thing in less words. Or even just "start mountee", if you think the "add" is superfluous. > I won't submit patch with corrections you mention in this E-mail right > away, because the corrections are mainly about changing some comments > or strings and I think it will be harder for you to review the changes > if I post the whole patch again. Well, I can't really give a final ACK without seeing the whole patch in its final form... > > > + /* The mountee will be sitting on this node. This node is based on > > > + the netnode of the root node, so most RPCs on this node can be > > > + automatically carried out correctly. */ > > > > I guess it would be helpful to explicitely mention the word "clone" > > somewhere. Also, the comment should explain *why* it is necessary to > > clone, instead of just using the original node... > > Changed to: ``The mountee will be sitting on this node. This node is > based on the netnode of the root node (it is essentially a clone of > the root node), so most RPCs on this node can be automatically carried > out correctly. Note the we cannot set the mountee on the root node > directly, because in this case the mountee's filesystem will obscure > the filesystem published by unionfs.'' "most RPCs ont this node can be automatically carried out correctly" is way too vague... It's not ever clear what "correct" means in here, no what RPCs you mean. I think you should say that the mountee is set on a (clone of) the unionfs root node, so that unionfs appears as the parent translator of the mountee. AIUI that's the idea behind it, right? > > > + /* Set the mountee on the new node. > > > + Note that the O_READ flag does not actually limit access to the > > > + mountee's filesystem considerably. Whenever a client looks up a > > > + node which is not a directory, unionfs will give off a port to > > > + the node itself, withouth proxying it. Proxying happens only for > > > + directory nodes. */ > > > > Why are you passing O_READ, anyways?... > > The flags which I pass to start_mountee are used in opening the port > to the root node of the mountee. (I'm sure you've noticed this; I'm > just re-stating it to avoid ambiguities). Inside unionfs, this port > is used for lookups *only*, so O_READ should be sufficient for any > internal unionfs needs. Ports to files themselves are not proxied by > unionfs (as the comment reads), so the flags passed here don't > influence that case. Hm, but wouldn't unionfs still need write permissions to the directories for adding new entries, when not in readonly mode?... Also, if it's *always* O_READ, why do you pass it as a function parameter at all? -antrik-
Re: [bug #27539] pfinet hangs
Hi, On Sun, Sep 27, 2009 at 03:08:40PM +, anonymous wrote: > awoodland: hmm I seem to be able to repeatably cause /hurd/pfinet to hang by > running 'apt-get source icedove' in an NFS directory > awoodland: at least I think it's pfinet that's hanging because I can't ping > the box any more > awoodland: and no applications that send/receive over the network work on the > hurd box either > awoodland: console applications continue to work I wonder whether this might be the same issue I'm experiencing here: pfinet reproducibly dies for me after apt-get fetching something around 90 MB of packages... However, I never got around to check whether this is related to the eth-multiplexer I'm running, or a general issue. -antrik-
Re: [PATCH 3/3] Add the mountee to the list of merged filesystems.
Hi,
On Mon, Aug 17, 2009 at 08:55:37PM +0300, Sergiu Ivanov wrote:
> On Sun, Aug 16, 2009 at 07:56:03PM +0200, olafbuddenha...@gmx.net wrote:
> > On Mon, Aug 03, 2009 at 08:42:27PM +0300, Sergiu Ivanov wrote:
> > > + /* A path equal to "" will mean that the current ULFS entry is the
> > > + mountee port. */
> > > + ulfs_register ("", 0, 0);
> >
> > This comment would actually be more appropriate near the definition of
> > the actual data structure and/or the function filling it in...
> >
> > Of course, it doesn't hurt to mention it here *in addition* to that :-)
>
> I've added the corresponding comment to ulfs_register, but I didn't
> add anything to variable or structure declarations, because I'm not
> sure whether it would be suitable to describe the convention in the
> comment to the declaration of struct ulfs or in the comment to the
> declaration of ulfs_chain.
The latter I'd say -- it's not really a property of the ulfs structure
itself, but rather a special entry in the list...
> Also, in ulfs.h, both are near the declaration of ulfs_register, so it
> seems to me that it's sufficient to describe the convention in the
> comment to ulfs_register only.
Perhaps. Though generally, properly documenting data structures is more
important than documenting functions... So I'd rather do it the other
way round :-)
> > I actually wonder whether the patches are really split up in the
> > most useful manner... But I'd rather leave it as is now.
>
> I'm asking out of pure interest: what different way of splitting the
> functionality across patches do you envision?
Quite frankly, I don't know :-)
> diff --git a/mount.c b/mount.c
[...]
> @@ -535,8 +539,13 @@ node_init_root (node_t *node)
> break;
>
>if (ulfs->path)
> - node_ulfs->port = file_name_lookup (ulfs->path,
> - O_READ | O_DIRECTORY, 0);
> + {
> + if (!ulfs->path[0])
You forgot to indent the contents of the block I think?...
> diff --git a/ulfs.c b/ulfs.c
[...]
> @@ -212,14 +216,16 @@ ulfs_for_each_under_priv (char *path_under,
>return err;
> }
>
> -/* Register a new underlying filesystem. */
> +/* Register a new underlying filesystem. A null path refers to the
> + underlying filesystem; a path equal to an empty string refers to
> + the filesystem of the mountee. */
This comment is very confusing, as "underlying filesystem" is used in
two different meanings side by side... Please try to reword it.
It's very unfortunate that the original unionfs often refers to the
constituents of the union as "underlying filesystems" -- perhaps it
would be useful to change this globally...
Aside from these formalities, this patch looks fine to me :-)
-antrik-
Re: nsmux: Build system
Hi, On Sun, Oct 25, 2009 at 06:13:47PM +0200, Sergiu Ivanov wrote: > On Sat, Oct 24, 2009 at 06:51:57AM +0200, olafbuddenha...@gmx.net > wrote: > > On Wed, Sep 30, 2009 at 02:35:14PM +0300, Sergiu Ivanov wrote: > > > Which way would be preferred: adapting the build system before the > > > merge of after the merge? > > > > > > I'd stand for the ``before the merge'' variant, since the current > > > ``build system'' is actually a one-liner bash script invoking gcc. > > > > Either before the merge, so you can test it by moving the existing > > repository to a subdirectory in the hurd/ tree and test it there; or > > directly in the merge process, without an extra commit for the build > > system change alone. Not sure which is better really. > > I think I have an extra argument for the second way: if I create a > separate commit before the merge, things will stop working, Yeah, you are right: you can't adapt the build system of the main Hurd tree before merging in the directory; and you can't merge the directory in without adapting the build system in the main Hurd... I forgot that adapting the build system requires changes in the global tree, not only in the subdirectory in question. > and, as you once said, a commit is a set of changes after which > everything works :-) Indeed. The established term for this is "bisectability" -- I just didn't know it at the time :-) -antrik-
Re: Is there interest in Hurd people meeting at: [...@gnu.org: GNU Hackers Meeting Registration - Gothenburg 2009]
Hi, On Mon, Sep 28, 2009 at 01:53:26PM +0200, Thomas Schwinge wrote: > Please see the attached email. Is there interest among Hurd people to > meet there? Hm... I guess it's a bit late now :-( At some point I actually considered going there... -antrik-
Re: Further Git repositories?
Hi, On Tue, Aug 11, 2009 at 12:12:51PM +0200, Thomas Schwinge wrote: > 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.) No, we can't keep the *whole* world in one repository. But we can keep our little part of the world in one repository perfectly well :-) You haven't answered my question at all: who would benefit from such a split, and why? Such a thing should never be an end to itself -- it only makes sense if it solves actual problems we are experiencing... Don't get me wrong: I totally agree that modularization is useful in many situations, and thus often a noble goal. But are you sure the Hurd tree is one of these cases? It seems to me that the situation here is somewhat different than in many other cases, and a split wouldn't really be to our advantage in this case... For one, it is different in that we don't have to deal with a lot of activity, so developers of different components are not likely to step on each others toes anyways. It's also different in that the components in question are not really very independent: a change in the interface of each library, but also of each server, always requires the other components to be updated. And the Hurd small and simple enough, and there are so little external things depending on us, that people never have the requirement of keeping some components unchanged while updating others. Keep in mind that modularization doesn't come for free. (Neither in terms of the initial conversion, nor ongoing maintenance.) On the contrary -- it tends to be very costly. API and ABI versioning; keeping components in sync that live in other repositories; and coordinating releases: these are all very painful things. (Ask any Xorg developer.) In many situations, there are other advantages however, which make up for this cost. But do any of these really apply to the Hurd in the current state?... BTW -- as once you mentioned Xorg as an example in favor of modularization -- you might be interested to hear, that the developers seem to be getting serious about plans for remerging the relevant drivers into the server: they want to avoid the pain of having to keep things in sync between components that aren't really independent at all... And I think our situation is actually very similar to the X server and drivers in terms of component independence. > > > 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. Don't you think that branches are perfectly suitable for handling experimental stuff? I don't see any technical disadvantage; and as for formal reasons, I firmly believe that we should encourage new development by treating as much things as realistically possible as part of the main distribution. > 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. What is considered the way to go for the future, and what makes sense right now, are two different things... Even if you have plans ultimately to split the repository, that's not a good reason to discriminate new components right now. Not only does it put the new components at a disadvantage in practice right now; but also it's IMHO fundamentally wrong to create facts for something there is no consensus about so far... > (We discussed this already.) Indeed we did (both the question whether a split is desirable at all; and the point that independent of the outcome, indefinite plans should not be an excuse to deny new modules an equal place right now) -- but the previous discussion came to no conclusion, so it was inevitable that the issue pops up again... -antrik-
