[PATCH 2/3] Implement mountee startup.

[Sergiu Ivanov]

* mount.c (mountee_node): New variable.
(mountee_root): Likewise.
(mountee_started): Likewise.
(start_mountee): New function (based on node_set_translator
in nsmux).
(setup_unionmount): New function.
* mount.h (mountee_root): New variable.
(mountee_started): Likewise.
(start_mountee): New function.
(setup_unionmount): New function.
* netfs.c (netfs_validate_stat): Start the mountee at the
first invocation.
---

Hello,

On Sun, Nov 22, 2009 at 09:05:16PM +0100, olafbuddenha...@gmx.net wrote:
> On Thu, Nov 19, 2009 at 10:28:37AM +0200, Sergiu Ivanov wrote:
> 
> > +  /* Fetch the effective UIDs of the unionfs process.  */
> > +  nuids = geteuids (0, 0);
> > +  if (nuids < 0)
> > +return EPERM;
> > +  uids = alloca (nuids * sizeof (uid_t));
> > +
> > +  nuids = geteuids (nuids, uids);
> > +  assert (nuids > 0);
> 
> Hrmph, I didn't spot this before: I don't think the assert() is right --
> "nuids" (or "ngids") being exactly 0, is probably a perfectly valid
> case... And even if it is not, the test in the assert should be
> equivalent to the EPERM test above, to avoid confusion.

OK, changed.
 
> > +  /* 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 that unionfs appears as the underlying translator
> > + to the mountee.  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.  */
> 
> Grammar nitpick: it should be "*would* obscure" :-)
> 
> (It don't think it hampers understanding though, so I can't say that I
> really care... Just a hint for you :-) )

Changed :-) Thank you for the hint :-)

Regards,
scolobb

---
 mount.c |  144 +++
 mount.h |   17 +++
 netfs.c |7 +++
 3 files changed, 168 insertions(+), 0 deletions(-)

diff --git a/mount.c b/mount.c
index 7bc1fb8..72c720d 100644
--- a/mount.c
+++ b/mount.c
@@ -22,8 +22,152 @@
 
 #define _GNU_SOURCE
 
+#include 
+#include 
+
 #include "mount.h"
+#include "lib.h"
 
 /* The command line for starting the mountee.  */
 char * mountee_argz;
 size_t mountee_argz_len;
+
+/* The node the mountee is sitting on.  */
+node_t * mountee_node;
+
+mach_port_t mountee_root;
+
+int mountee_started = 0;
+
+/* Starts the mountee (given by `argz` and `argz_len`), attaches it to
+   the node `np` and opens a port `port` to the mountee.  */
+error_t
+start_mountee (node_t * np, char * argz, size_t argz_len, mach_port_t * port)
+{
+  error_t err;
+  mach_port_t underlying_port;
+
+  mach_port_t mountee_control;
+
+  /* Identity information about the unionfs process (for
+ fsys_getroot).  */
+  uid_t * uids;
+  size_t nuids;
+
+  gid_t * gids;
+  size_t ngids;
+
+  /* The retry information returned by fsys_getroot.  */
+  string_t retry_name;
+  mach_port_t retry_port;
+
+  /* Fetch the effective UIDs of the unionfs process.  */
+  nuids = geteuids (0, 0);
+  if (nuids < 0)
+return EPERM;
+  uids = alloca (nuids * sizeof (uid_t));
+
+  nuids = geteuids (nuids, uids);
+  if (nuids < 0)
+return EPERM;
+
+  /* Fetch the effective GIDs of the unionfs process.  */
+  ngids = getgroups (0, 0);
+  if (ngids < 0)
+return EPERM;
+  gids = alloca (ngids * sizeof (gid_t));
+
+  ngids = getgroups (ngids, gids);
+  if (ngids < 0)
+return EPERM;
+
+  /* Opens the port on which to set the mountee.  */
+  error_t open_port (int flags, mach_port_t * underlying,
+mach_msg_type_name_t * underlying_type, task_t task,
+void *cookie)
+  {
+err = 0;
+
+/* The protid which will contain the port to the node on which the
+   mountee will be sitting.  */
+struct protid * newpi;
+
+struct iouser * unionfs_user;
+
+/* Initialize `unionfs_user` with the effective UIDs and GIDs of
+   the unionfs process.  */
+err = iohelp_create_complex_iouser (&unionfs_user, uids, nuids, gids, 
ngids);
+if (err)
+  return err;
+
+/* Create a port to node on which the mountee should sit (np).  */
+newpi = netfs_make_protid
+  (netfs_make_peropen (np, flags, NULL), unionfs_user);
+if (!newpi)
+  {
+   iohelp_free_iouser (unionfs_user);
+   return errno;
+  }
+
+*underlying = underlying_port = ports_get_send_right (newpi);
+*underlying_type = MACH_MSG_TYPE_COPY_SEND;
+
+ports_port_deref (newpi);
+
+return err;
+  }/*open_port */
+
+  /* Start the translator.  The value 6 for the timeout is the one
+ found in settrans.  */
+  err = fshelp_start_translator (open_port, NULL, argz, argz, argz_len,
+6, &mountee_control);
+  if (err)
+return err;
+
+  /* Attach the mountee to the port opened in the previous call.  */
+  err = file_set_translator (underlying_port, 0, FS_TRANS_SET, 0, argz,
+   

[PATCH] Implement the sync libnetfs stubs.

[Sergiu Ivanov]

* netfs.c (netfs_attempt_sync): Sync every directory associated
with the supplied node.
(netfs_attempt_syncfs): Send file_syncfs to every directory
maintained by unionfs.
---

Hello,

On Sun, Nov 22, 2009 at 09:08:33PM +0100, olafbuddenha...@gmx.net wrote:
> On Thu, Nov 19, 2009 at 11:18:45AM +0200, Sergiu Ivanov wrote:
> 
> > +assert (err == 0);
> 
> Another thing you forgot to change in the second loop...

Yeah, sorry :-( Changed.

Regards,
scolobb

---
 netfs.c |   81 --
 1 files changed, 78 insertions(+), 3 deletions(-)

diff --git a/netfs.c b/netfs.c
index 89d1bf6..9d24f06 100644
--- a/netfs.c
+++ b/netfs.c
@@ -1,5 +1,6 @@
 /* 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 Moritz Schulte .
 
This program is free software; you can redistribute it and/or
@@ -282,7 +283,45 @@ error_t
 netfs_attempt_sync (struct iouser *cred, struct node *np,
int wait)
 {
-  return EOPNOTSUPP;
+  /* The error we are going to report back (last failure wins).  */
+  error_t final_err = 0;
+
+  /* The information about the currently analyzed filesystem.  */
+  ulfs_t * ulfs;
+
+  /* The index of the currently analyzed filesystem.  */
+  int i;
+
+  mutex_lock (&ulfs_lock);
+
+  /* Sync every 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.  */
+  i = 0;
+  node_ulfs_iterate_unlocked (np)
+  {
+error_t err;
+
+/* Get the information about the current filesystem.  */
+err = ulfs_get_num (i, &ulfs);
+assert (!err);
+
+/* Since `np` may not necessarily be present in every underlying
+   directory, having a null port is perfectly valid.  */
+if (node_ulfs->port != MACH_PORT_NULL)
+  {
+   err = file_sync (node_ulfs->port, wait, 0);
+   if (err)
+ final_err = err;
+  }
+
+++i;
+  }
+
+  mutex_unlock (&ulfs_lock);
+  return final_err;
 }
 
 /* This should sync the entire remote filesystem.  If WAIT is set,
@@ -290,7 +329,43 @@ netfs_attempt_sync (struct iouser *cred, struct node *np,
 error_t
 netfs_attempt_syncfs (struct iouser *cred, int wait)
 {
-  return 0;
+  /* The error we are going to report back (last failure wins).  */
+  error_t final_err = 0;
+
+  /* The information about the currently analyzed filesystem.  */
+  ulfs_t * ulfs;
+
+  /* The index of the currently analyzed filesystem.  */
+  int i;
+
+  mutex_lock (&ulfs_lock);
+
+  /* Sync every unioned directory maintained by unionfs.
+
+ 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.  */
+  i = 0;
+  node_ulfs_iterate_unlocked (netfs_root_node)
+  {
+error_t err;
+
+/* Get the information about the current filesystem.  */
+err = ulfs_get_num (i, &ulfs);
+assert (!err);
+
+/* Note that, unlike the situation in netfs_attempt_sync, having a
+   null port on the unionfs root node is abnormal.  */
+assert (node_ulfs->port != MACH_PORT_NULL);
+err = file_syncfs (node_ulfs->port, wait, 0);
+if (err)
+  final_err = err;
+
+++i;
+  }
+
+  mutex_unlock (&ulfs_lock);
+  return final_err;
 }
 
 /* lookup */
-- 
1.6.5.3

Re: unionmount branches

[Sergiu Ivanov]

Hello,

On Thu, Oct 29, 2009 at 07:11:16AM +0100, olafbuddenha...@gmx.net wrote:
> 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...

Just to make sure: I can push the mount patch series (starting with
``Add the --mount command line option'' to ``Add the mountee to the
list of merged filesystems'') to the unionmount branch in the
unionfs.git repository, right?

Regards,
Sergiu

man: pipeline, additional questions

[Jakub Daniel]

Hello

when i tried to examine man page of dpkg i got the following error (not
right away but after i scrolled to line 129 or similar):

man: pipeline.c:1671: pipeline_peek_skop: Assertion `len <= p->peek_offset'
failed.


I was also wondering about the following:

I read a paper about mach not being the best choice of microkernel for hurd.
And I also know that viengoos has been in development for some time.
What I hoped to find on the web was whether it (viengoos) is ment to replace
mach if everything goes as expected (if viengoos is part of gnu project).
As i took a look on the git repository of viengoos i found out that there
have not been many commits since the beginning of this year, is it still
being developed (actively).
Would it be hard to switch from mach to viengoos (when it is ready)? Would
it bring difficulties or would it be benefitial?

I know this might sound a bit unrelated to this mailing list.. but i have
heard that hurd suffers from difficulties with mach.. i was not able to find
much information about this
so i hoped i would find answers here as you all know much more about it.

thanks
Jakub Daniel

Re: man: pipeline, additional questions

[Samuel Thibault]

Jakub Daniel, le Tue 08 Dec 2009 22:27:12 +0100, a écrit :
> man: pipeline.c:1671: pipeline_peek_skop: Assertion `len <= p->peek_offset'
> failed.

This lookes like a bug in Hurd.

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

Where did you hear that?

> i was not able to find much information about this

We haven't had any GNU Mach bug for a long time, while we do know quite
a few bugs in the Hurd itself, so for sure it's not the part that is
hindering GNU/Hurd :)

Samuel

Re: man: pipeline, additional questions

[Jakub Daniel]

> Where did you hear that?

i don't know all the sources but i heard it several times but it of course
might not be true..  one of the sources is wikipedia.org.. but this one i
might have misunderstood.

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

If the reality is how You pointed it out then i am much happier right away
:).. even though i thought viengoos would bring newer drivers and support
for various things that mach has not yed focused on.


I also wondered if GNU/Hurd had some plan for future as other project have
or due to the fact that there is lot of work on bugs that might yet occur it
doesnt..

I mean whether there are some points when next release is made... some main
revision versions with TODO lists.. i hoped i could help searching for bugs
maybe even fixing some of them when i learn more about how actual
debain/hurd distro is constructed.

Jakub

Re: man: pipeline, additional questions

[Samuel Thibault]

Jakub Daniel, le Tue 08 Dec 2009 23:13:15 +0100, a écrit :
> If the reality is how You pointed it out then i am much happier right away 
> :)..
> even though i thought viengoos would bring newer drivers and support for
> various things that mach has not yed focused on.

I believe viengoos doesn't have more drivers that GNU Mach :)

> I also wondered if GNU/Hurd had some plan for future as other project have or
> due to the fact that there is lot of work on bugs that might yet occur it
> doesnt..

There are projects to use an existing driver glue, can't remember the
name.

> I mean whether there are some points when next release is made... some main
> revision versions with TODO lists.. i hoped i could help searching for bugs
> maybe even fixing some of them when i learn more about how actual debain/hurd
> distro is constructed.

See http://bugs.debian.org/src:hurd and http://sv.gnu.org/p/hurd
tasks/bugs, and the alioth hurd bugs/tasks.  A lot of stuff to do, not
many people taking care of it.

Samuel

Re: man: pipeline, additional questions

[Jakub Daniel]

>
> I believe viengoos doesn't have more drivers that GNU Mach :)
>

right, this is just what i expected from a project that started more
recently than gnu mach and thus is probably being developed to run on
machines that are similar to those we have now..


> See http://bugs.debian.org/src:hurd and http://sv.gnu.org/p/hurd
> tasks/bugs , and the alioth hurd
> bugs/tasks.  A lot of stuff to do, not
> many people taking care of it.
>
> Samuel
>

i will take a look at this. however i think that i might not be experienced
enough to help much. hopefully reporting bugs helps a bit as well.

Jakub

Re: unionmount branches

[Thomas Schwinge]

Hello!

On Tue, Dec 08, 2009 at 09:20:45PM +0200, Sergiu Ivanov wrote:
> On Thu, Oct 29, 2009 at 07:11:16AM +0100, olafbuddenha...@gmx.net wrote:
> > 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...
> 
> Just to make sure: I can push the mount patch series (starting with
> ``Add the --mount command line option'' to ``Add the mountee to the
> list of merged filesystems'') to the unionmount branch in the
> unionfs.git repository, right?

Isn't that exactly what the existing master-unionmount branch is about /
contains?  Or is that branch to be considered obsolete and you have a
similar patch series that should be used instead?  If the latter, then
yes, publishing that under a different name (be it unionmount or be it
master-unionmount-Mk_2 or whatever) is the correct thing to do.  Please
also remove the then-obsolte branch:

$ git push savannah :master-unionmount


Regards,
 Thomas


signature.asc
Description: Digital signature