* HAVE_FORMAT32 never enabled in mainline
@ 2007-03-17 15:40 Christoph Hellwig
2007-03-17 22:00 ` Eric Sandeen
2007-03-19 1:04 ` Timothy Shimmin
0 siblings, 2 replies; 4+ messages in thread
From: Christoph Hellwig @ 2007-03-17 15:40 UTC (permalink / raw)
To: tes, xfs
Looks like the code for dealing with x86/amd64 logs is never actually
enable in mainline because nothing defines HAVE_FORMAT32.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: HAVE_FORMAT32 never enabled in mainline
2007-03-17 15:40 HAVE_FORMAT32 never enabled in mainline Christoph Hellwig
@ 2007-03-17 22:00 ` Eric Sandeen
2007-03-19 1:05 ` Timothy Shimmin
2007-03-19 1:04 ` Timothy Shimmin
1 sibling, 1 reply; 4+ messages in thread
From: Eric Sandeen @ 2007-03-17 22:00 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: tes, xfs
Christoph Hellwig wrote:
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: HAVE_FORMAT32 never enabled in mainline
2007-03-17 15:40 HAVE_FORMAT32 never enabled in mainline Christoph Hellwig
2007-03-17 22:00 ` Eric Sandeen
@ 2007-03-19 1:04 ` Timothy Shimmin
1 sibling, 0 replies; 4+ messages in thread
From: Timothy Shimmin @ 2007-03-19 1:04 UTC (permalink / raw)
To: Christoph Hellwig, tes, xfs
Hi Christoph,
--On 17 March 2007 4:40:28 PM +0100 Christoph Hellwig <hch@lst.de> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: HAVE_FORMAT32 never enabled in mainline
2007-03-17 22:00 ` Eric Sandeen
@ 2007-03-19 1:05 ` Timothy Shimmin
0 siblings, 0 replies; 4+ messages in thread
From: Timothy Shimmin @ 2007-03-19 1:05 UTC (permalink / raw)
To: Eric Sandeen, Christoph Hellwig; +Cc: tes, xfs
Hi Eric,
--On 17 March 2007 5:00:47 PM -0500 Eric Sandeen <sandeen@sandeen.net> wrote:
> Christoph Hellwig wrote:
>> 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).
> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-03-19 1:06 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-03-17 15:40 HAVE_FORMAT32 never enabled in mainline Christoph Hellwig
2007-03-17 22:00 ` Eric Sandeen
2007-03-19 1:05 ` Timothy Shimmin
2007-03-19 1:04 ` Timothy Shimmin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox