Subject: Re: Pending entries support for fileassoc(9)
To: YAMAMOTO Takashi <email@example.com>
From: Elad Efrat <elad@NetBSD.org>
Date: 12/23/2007 19:15:41
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
>> 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
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
>>> 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
> 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