YAMAMOTO Takashi wrote:

> because you can use the same mechanism for mounted filesystem and
> unmounted filesystems.

I think I understand what you mean here, but can you elaborate on how
you see this implemented?

(IIUC, you're talking about a userland daemon that the kernel will
dispatch queries to, and cache the result of the answers, so that it
doesn't matter when a file-system is mounted, because the query will
be made as soon as missing information is needed -- like meta-data
paging?)

>> I don't mean it can't co-exist with per-process namespace, I mean that I
>> don't see how the two are related...
> 
> for example,
> 1. process A loads pending entries.
> 2. process B, which doesn't share namespace with process A, mounts
>   a file system.  pending entries loaded by process A are meaningless here.

What do you mean by "doesn't share namespace with process A"? do we have
this today?

I see the "pending entries loader" started by /sbin/init, at the top of
the rc.d scripts, so I'm not entirely sure where process B is coming
from. :)

>>> it isn't clear to me how generic you consider the "pending entries" is.
>>> is it merely a hidden communication channel between fingerprint loaders
>>> and mount(2)?  if so, there is no point to implement it in kernel, IMO.
>> First, it's not a hidden channel between fingerprint loaders and
>> mount(2). It's a way to introduce entries in fileassoc(9) -- that works
>> on the VFS layer -- before the files these entries are for exist on the
>> system.
> 
> your pending-entries-loader needs to know where file systems will
> be mounted.  loaded entries will be consumed only by mount.
> i don't see how it isn't a communication channel between the loader
> and mount.

Okay, and what is the problem with that? or is it merely a definition? I
didn't quite understand what you meant by "hidden communication
channel", but if that's what it is, then so be it...

>> Hence, the need for pending entries in fileassoc(9): a temporary list
>> saying "we want to attach this meta-data to these files as soon as
>> they're introduced to the system".
> 
> what's wrong with simply loading them immediately after mount?

Can you be a little less vague? I can't comment on what's "wrong" with
it before I know how you see it done. My intention in putting the call
in do_sys_mount() was exactly that: loading them *immediately* after
mount. :)

-e.