xfs
[Top] [All Lists]

Re: Extended attributes: process vs. kernel context (e.g. HSM)

To: "Theodore Ts'o" <tytso@xxxxxxx>
Subject: Re: Extended attributes: process vs. kernel context (e.g. HSM)
From: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Date: Fri, 15 Nov 2002 17:07:30 +0000
Cc: Andreas Gruenbacher <agruen@xxxxxxx>, Alexander Viro <viro@xxxxxxxxxxxx>, "Stephen C.Tweedie" <sct@xxxxxxxxxx>, ext2-devel@xxxxxxxxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
In-reply-to: <20021111210524.GB6032@xxxxxxxxxxxxxxx>; from tytso@xxxxxxx on Mon, Nov 11, 2002 at 04:05:24PM -0500
References: <200211100135.26236.agruen@xxxxxxx> <20021110013233.GH9589@xxxxxxxxxxxxxxx> <200211111334.32074.agruen@xxxxxxx> <20021111210524.GB6032@xxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.2.5.1i
Hi,

On Mon, Nov 11, 2002 at 04:05:24PM -0500, Theodore Ts'o wrote:
> On Mon, Nov 11, 2002 at 01:34:31PM +0100, Andreas Gruenbacher wrote: 
> > I think adding a (struct task_struct *) parameter to the xattr inode
> > operations is a better idea --- I don't know how likely it is that
> > credentials will be passed around in a future kernel, but if it's
> > likely then the xattr inode operations would move in the right
> > direction, instead of introducing weird flag(s).
 
> Asking the HSM module to fake up a task structure just so it can
> create a "credential" that has CAP_SYS_ADMIN set is simply madness.

Perhaps, but do we need it?

I'd have thought that the likely model for an HSM system is that the
requesting user process would find the inode marked "not-in-core", and
would pass the "please make this inode resident" request out to a
separate process for completion.  Only that external process would
require access to the HSM metadata, so it's not immediately obvious
why the initial caller process absolutely has to have access to the
HSM metadata.

--Stephen


<Prev in Thread] Current Thread [Next in Thread>