Subject: Re: Pending entries support for fileassoc(9)
To: None <firstname.lastname@example.org>
From: YAMAMOTO Takashi <email@example.com>
Date: 12/05/2007 22:58:05
> YAMAMOTO Takashi wrote:
> > your patch doesn't seem to remove the window.
> Are you referring to the lack of locking on the mount itself, in a way
> that allows performing operations on the mount-point right after it was
> mounted and before the traversal on the pending list was done?
> > i think fileassoc has scalability problems, and this 'pending' thing
> > will make it worse.
> > how about making fileassoc (or veriexec, or whatever) issue upcalls
> > to userland daemon? ie. keep databases in userland and consider
> > in-kernel entries as cache.
> First, I'd like to point out that (ideally) this list of pending entries
> will exist about a minute: right after the kernel is alive, and right
> before file-systems are mounted.
> Before I address the second paragraph about userland dameon upcalls, I
> have to know if you're referring to this addition specifically (the
> pending pathnames list), or the entire subsystem(s). If the former, see
> above; if the latter -- I'm afraid that (at least for now) that's out of
> the question.
> > for long term i'd like to make filesystem namespace per-process.
> > so, in general, i don't like the idea to keep pathnames in kernel without
> > associating them to a process.
> Nothing is set in stone, introducing functionality now only means we'll
> have to adapt it to a new reality in the future. While I am interested
> in this, I'd like to hear about it in a different thread. :)
it isn't always possible to adapt it later in a natural way.
it's better to shake out possible problems when designing api as far as
possible, rather than later.
for your purpose, is it appropriate to associate pathnames to
a namespace of a process which loaded entries?