linux-ext4 - Re: [RFC PATCH 7/9][e2fsprogs] Add new blk64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080512122521.4f9b270e@gara>
Date:	Mon, 12 May 2008 12:25:21 -0500
From:	"Jose R. Santos" <jrs@...ibm.com>
To:	Theodore Tso <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [RFC PATCH 7/9][e2fsprogs] Add new blk64_t handling inline
 functions

On Mon, 12 May 2008 10:49:03 -0400
Theodore Tso <tytso@....edu> wrote:

> On Fri, May 09, 2008 at 11:40:12AM -0500, Jose R. Santos wrote:
> > From: Jose R. Santos <jrs@...ibm.com>
> > 
> > Add new blk64_t handling inline functions
> > 
> > Introduce inline fuctions to handle blk64_t and low/high values in
> > super blocks and inodes.
> 
> If you do this patch first, then you can address some of the FIXME's
> earlier in the patch series...

Will do.

> And as I mentioned, we probably want to avoid making them INLINE
> functions.  It's always easier to inline a function later if we find
> that it shows up on profiles for performance reasons, but if we find
> out we need to make changes and it is inline already, it's much harder
> to deal with the backwards compatibility issues.

I agree that making the not inline is the right thing to do, but now
the question is where do we put these new functions.  Is it still
appropriate to place them in ext2fs.h or do you prefer a new location?

> 						- Ted

-JRS
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html