From: Mark Fasheh <mark.fasheh@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH]remove ocfs_fill_super and port ocfs_read_super
Date: Mon Mar 29 17:06:15 2004 [thread overview]
Message-ID: <20040329230609.GY10672@ca-server1.us.oracle.com> (raw)
In-Reply-To: <20040329223754.GA15877@penguin.co.intel.com>
On Mon, Mar 29, 2004 at 02:37:54PM -0800, Rusty Lynch wrote:
> ah... first of all, s/I should be inline/It should be inlined/
> hey, it's not like englihs is first (and only) language or anything :->
heh, i dont' now wat your taking abuot
> The only thing left in __ocfs_read_super that requires #if LINUX.../#endif's
> is the ocfs_iget/iget4 stuff, which is one of those areas that I have been meaning
> to deal with... ocfs_iget() should be what get's called regardless of 2.4/2.6,
> and then deal with 2.4 verses 2.6 specifics in that function instead of sprinkled
> over super/namei/hash.
>
> You mind if I tackle this in the same patch, or do you want two patches? (It's just
> that ocfs_iget needs to be fixed before __ocfs_read_super can be made clean.)
Actually, two patches please. I don't mind the extra over #ifdef, and it'll
give us time to run with the new read_super while you deal with the inode
stuff (which I'd like to test seperately anyway).
While we're on the topic of iget, here's a thought. Theoretically we don't
need iget4/iget5 anymore, as our inode numbers are no longer tied to 64 bit
disk offsets and instead are taken from iunique, which, as the name
indicates, gives you a unique inode number. We should be able to just always
use iget instead, which is much simpler.
Of course, eliminating the #ifdef ... iget4 #else ocfs_iget #endif stuff is
a step in a good direction. However, if you want to give moving to iget a
shot, I'd be more than happy to help out with at least the 2.4 side of
things (testing, etc)
--Mark
--
Mark Fasheh
Software Developer, Oracle Corp
mark.fasheh@oracle.com
next prev parent reply other threads:[~2004-03-29 17:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-25 21:00 [Ocfs2-devel] [PATCH]remove ocfs_fill_super and port ocfs_read_super Rusty Lynch
2004-03-26 8:35 ` Joel Becker
2004-03-26 14:47 ` Rusty Lynch
2004-03-29 15:29 ` Mark Fasheh
2004-03-29 15:32 ` Rusty Lynch
2004-03-29 16:42 ` Rusty Lynch
2004-03-29 17:06 ` Mark Fasheh [this message]
2004-03-29 17:46 ` Rusty Lynch
2004-03-29 20:44 ` Mark Fasheh
2004-03-30 11:28 ` Rusty Lynch
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=20040329230609.GY10672@ca-server1.us.oracle.com \
--to=mark.fasheh@oracle.com \
--cc=ocfs2-devel@oss.oracle.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.