bug-hurd
[Top][All Lists]
Advanced

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

get_translator_{children,source} (v2)


From: Justus Winter
Subject: get_translator_{children,source} (v2)
Date: Thu, 11 Jul 2013 18:09:03 +0200

Hi,

this is an updated and broken up version of my mtab prototype.

[PATCH 01/17] libdiskfs: fix consistency check
[PATCH 02/17] libnetfs: fix consistency check

These are bug fixes. Please have a look.

[PATCH 03/17] libdiskfs: track file name in struct peropen
[PATCH 04/17] libnetfs: track file name in struct peropen

Samuel wrote:
> 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.

I agree that it's sad to do it like this, but I'm not convinced there
is another way currently. I looked at getcwd(3) but the situation
there is different, because getcwd(3) starts with a file_t referencing
a directory.

We discussed this in #hurd. Richard mentioned that moving mount points
might not be a problem. He tried this on Linux and it returns EBUSY
there. I tried this on the Hurd and moving a translator with a process
inside worked fine there. Richard said that it would probably be best
to also prevent this because (I quote from memory here, please correct
me if I'm wrong) there are two nodes stacked onto another and moving
them requires the greatest care.

POSIX says:
> The rename() and renameat() functions shall fail if:
> [...]
> [EBUSY]
>     The directory named by old or new is currently in use by the
>     system or another process, and the implementation considers this
>     an error.

This needs further discussion.

[PATCH 05/17] libfshelp: add translator-list.c
[PATCH 06/17] libdiskfs: add fsys_get_children
[PATCH 07/17] libnetfs: add fsys_get_children
[PATCH 08/17] libtrivfs: add fsys_get_children
[PATCH 09/17] trans/symlink.c: add fsys_get_children
[PATCH 10/17] hurd: add fsys_get_children

Keep a list of translators (lib{fshelp,diskfs,netfs}), stub out the
functions (libtrivfs, symlink), add procedure.

[PATCH 11/17] libdiskfs: add fsys_get_source
[PATCH 12/17] libnetfs: add fsys_get_source
[PATCH 13/17] libtrivfs: add fsys_get_source
[PATCH 14/17] trans/symlink.c: add fsys_get_source
[PATCH 15/17] hurd: add fsys_get_source

Add server function (lib{disk,net,triv}fs) and make them
user-overridable, stub out the functions (symlink), add procedure.

[PATCH 16/17] XXX this looks wrong to me, please have a look

This looks wrong. And does not work for me, that's why the
fsys_get_children patches contain a call to
mach_port_request_notification.

[PATCH 17/17] add mtab prototype

This turned into an libtrivfs-based translator. It's still a bit
rough, but as far as I can see it leaks neither memory nor ports.

% settrans -cga tmp tmpfs/tmpfs --mode=1777 10M
% settrans -cga tmp/foo tmpfs/tmpfs --mode=1777 11M
% settrans -cga mtab trans/mtab tmp
% cat mtab
none tmp tmpfs/tmpfs writable,no-inherit-dir-group,no-sync,size=10M 0 0
none tmp/foo tmpfs/tmpfs writable,no-inherit-dir-group,no-sync,size=11M 0 0
% settrans -g tmp/foo
pthread_create: Resource temporarily unavailable
% cat mtab
none tmp ./tmpfs/tmpfs writable,no-inherit-dir-group,no-sync,size=10M 0 0

(What's up with pthread_create? Is that the dying translator?)

Cheers,
Justus



reply via email to

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