Skip to contentSkip to conversation

HAVE_FORMAT32 never enabled in mainline

DISCUSSION Christoph Hellwig 3 participants 4 messages Mar 17, 2007 – Mar 19, 2007

lore
Share & tools
lore
#0 lore raw

Looks like the code for dealing with x86/amd64 logs is never actually enable in mainline because nothing defines HAVE_FORMAT32.

#1 lore raw
Quoted 1 line · Christoph Hellwig

Looks like the code for dealing with x86/amd64 logs is never actually enable in mainline because nothing defines HAVE_FORMAT32.

Actually since it's all #ifndef (note the n) everything under the #ifndefs -is- enabled (since it's never defined), so I think it's all functional.... structures under the #ifndefs are used outside the #ifndefs, so the #ifndefs can probably just be removed...?

-Eric

#2 lore raw

Hi Eric,

Quoted 6 lines · --On 17 March 2007 5:00:47 PM -0500 Eric Sandeen <[email protected]> wrote:
Quoted 2 lines · Christoph Hellwig

Looks like the code for dealing with x86/amd64 logs is never actually enable in mainline because nothing defines HAVE_FORMAT32.

Actually since it's all #ifndef (note the n) everything under the #ifndefs -is- enabled (since it's never defined), so I think it's all functional....

Yep (sorry, just missed your email).

Quoted 2 lines

structures under the #ifndefs are used
outside the #ifndefs, so the #ifndefs can probably just be removed...?

Would need to sort out the userspace header sharing situation first as mentioned in the hch email.

Cheers,
Tim.

#3 lore raw
In reply to Christoph Hellwig

Hi Christoph,

Quoted 2 lines · --On 17 March 2007 4:40:28 PM +0100 Christoph Hellwig <[email protected]> wrote:

Looks like the code for dealing with x86/amd64 logs is never actually enable in mainline because nothing defines HAVE_FORMAT32.

It is enabled, the HAVE_FORMAT32 is #ifndef around some particular type definitions. (The code has been tested:)

It is currently used because those header files are shared between userspace and kernel. And in userspace, there is a case where the 32bit format definition is already defined in another header file - that case is for IRIX, whose pack syntax is different with its compiler. So if this is a concern then I would need to have these defined elsewhere or break the kernel/userspace link on this file, etc... Suggestions welcome...

--Tim