bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] get_translator_info wip


From: Samuel Thibault
Subject: Re: [PATCH] get_translator_info wip
Date: Mon, 8 Jul 2013 11:41:51 +0200
User-agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)

Hello,

Justus Winter, le Wed 03 Jul 2013 23:11:58 +0200, a écrit :
> +/* Return the options describing the operation of the receiving
> +   filesystem (sutiable for fsys_set_options).  */

Make sure to update comments of copy/pasted code :)

> +routine fsys_get_translator_info (
> +     server: fsys_t;
> +     RPT
> +        out children: data_t);

So, to sum it up, the idea is to return an array of strings giving the
mount points. See below for comments.

> +        out source: string_t;

This should probably go to another RPC, as I don't think getting
mountpoints and getting the underlying device should be related (even if
in your case they are related).

> --- a/libdiskfs/dir-lookup.c
> +++ b/libdiskfs/dir-lookup.c
> @@ -82,6 +82,11 @@ diskfs_S_dir_lookup (struct protid *dircred,
>        goto gotit;
>      }
>  
> +  free (dircred->po->path);
> +  dircred->po->path = strdup(path); /* XXX is this the right place? */
> +  if (! dircred->po->path)
> +    return ENOMEM;
> +

Mmm. It indeed looks odd to store the path at lookup.

Concerning storing the path, it's a bit sad to have to do that, and
it'll become wrong if one moves the mount points.  Another way would
be to make the client figure it out by itself from a port to the mount
point, much like glibc/sysdeps/mach/hurd/getcwd.c. It'll be slower, but
should be safer.  The RPC would thus return an array of ports to the
mount points instead of an array of strings.

Anybody else?

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]