Subject: Re: Pending entries support for fileassoc(9)
To: None <elad@NetBSD.org>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: tech-kern
Date: 12/28/2007 11:35:04
> 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?

as i said, via a generic upcall mechanism.
i don't have concrete ideas of implemetation details yet.
i think i will implement upcalls for nfsd, so you can use it if you are
patient enough. :)

> (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?)

yes.

an interesting question is what to use as query keys.
eg. pathname, file handles, etc.

considering how fileassoc works, file handles sound more natural,
but it can yield some difficulties for loaders.
otoh, if you use pathnames, you might need to implement the file_to_path
feature.

> >> 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. :)

we are talking about interactions with per-process namespace, which
we don't have today.

process B could be an arbitrary process exec'ed by rc.d scripts.
per-process namespace means each processes (with enough privileges)
can create its own namespace.  you can consider chroot as
a special case of it.

> >>> 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...

see below.  it isn't clear to me why you want to communicate with mount in
this way.

> >> 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.

i meant, mount a file system using mount(2), and then load entries for
the file system as usual.

YAMAMOTO Takashi