From: Will Dyson <will.dyson@gmail.com>
To: James Morris <jmorris@redhat.com>
Cc: Andrew Morton <akpm@osdl.org>,
viro@parcelfarce.linux.theplanet.co.uk,
Stephen Smalley <sds@epoch.ncsc.mil>,
Christoph Hellwig <hch@infradead.org>,
Andreas Gruenbacher <agruen@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] xattr consolidation v2 - generic xattr API
Date: Mon, 20 Sep 2004 13:50:25 -0400 [thread overview]
Message-ID: <8e6f9472040920105013b4e0cd@mail.gmail.com> (raw)
In-Reply-To: <Xine.LNX.4.44.0409180305300.10905-100000@thoron.boston.redhat.com>
On Sat, 18 Sep 2004 03:20:37 -0400 (EDT), James Morris
<jmorris@redhat.com> wrote:
> This patch consolidates common xattr handling logic into the core fs code,
> with modifications suggested by Christoph Hellwig (hang off superblock,
> remove locking, use generic code as methods), for use by ext2, ext3 and
> devpts, as well as upcoming tmpfs xattr code.
Hi James,
I'd like to raise an issue with the documentation your patch
introduces. The lack of it, actually.
While it might be obvious to someone who is familiar with the ext2 and
ext3 xattr code, I had a rather hard time understanding how a
filesystem would make use of the generic functions that your patch
introduces. While I think I have it now, that is 30 minutes of my life
that I will never get back :) . 30 minutes is not a long time (I've
spent as much thinking about this message), but this sort of thing is
an issue all throughout the generic vfs code.
When I was working on the readonly befs filesystem, I may have spent
as much as 20 percent of my time actually thinking about on-disk data
and how to use it. Most of the rest of that time was spent reading
code from the vfs layer (or other existing filesystems), trying to
figure out how I should call helper functions or how they would call
my code. Some of that code is very clever and solves complex problems,
which makes it hard to grok on the first (or third) read-through.
I don't plan on holding my breath while waiting for "The linux vfs
layer for dummies" to come out. But a quick comment to explain the
purpose and use of a block of code can make a world of difference to
someone trying to come up to speed.
For example:
/*
In order to implement different sets of xattr operations for each
xattr prefix, a filesystem should create a null-terminated array of
struct xattr_handler (one for each prefix) and hang a pointer to it
off of the s_xattr field of the superblock. The generic_fooxattr
functions will search this list for a xattr_handler with a prefix
field that matches the prefix of the xattr we are dealing with and
call the apropriate function pointer from that xattr_handler.
*/
--
Will Dyson - Consultant
http://www.lucidts.com/
next prev parent reply other threads:[~2004-09-20 17:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Xine.LNX.4.44.0409180252090.10905@thoron.boston.redhat.com>
2004-09-18 7:20 ` [PATCH 1/6] xattr consolidation v2 - generic xattr API James Morris
2004-09-18 23:31 ` Andreas Gruenbacher
2004-09-18 23:47 ` James Morris
2004-09-19 10:13 ` Andreas Gruenbacher
2004-09-19 14:46 ` James Morris
2004-09-20 17:50 ` Will Dyson [this message]
2004-09-20 23:07 ` James Morris
2004-09-21 3:25 ` Will Dyson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8e6f9472040920105013b4e0cd@mail.gmail.com \
--to=will.dyson@gmail.com \
--cc=agruen@suse.de \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=jmorris@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sds@epoch.ncsc.mil \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox