On 12-12-03 12:57 PM, Sebastian Andrzej Siewior wrote:
On Thu, Nov 01, 2012 at 09:21:16AM +0200, Felipe Balbi wrote:
then we can merge to net tree and handle the conflicts when merging to
Linus, that'd be fine by me as long as people know how to solve the
conflict properly ;-)
Felipe please drop this patch. I don't like this VLAIS patch and its
macro magic. I support the goal of compiling the kernel with clang but I
don't think that this is appropriate. Davem has also his problems with
the netfilter part so I am no the only one.
You are definitely not the only one. :)
But that's okay. The idea is to find an alternative that works for
everyone. It was the first attempt, which didn't work out. <shrug>
*I* think the gadget part of the kernel is something most people won't
use so it won't show up.
Anyway, please drop this completely I try to think of something sane.
He actually didn't take the patch. He was asking the netfilter team to
take it, and they didn't want to. Fair enough.
However, in order to approximate what gcc is doing in code, obviously
some math is required. The thought was that macros would hide the worst
of it, trying not to obfuscate what was actually being done.
One of the project members came up with this alternative. How about
something like this? Less math, though more string pasting. When
compiled, the unused variables get optimized away. Otherwise the memory
packing is identical to using VLAIS in gcc.
#define vla_struct(structname) size_t structname##__##next = 0
#define vla_struct_size(structname) structname##__##next
#define vla_item(structname, type, name, n) \
type * structname##_##name; \
size_t structname##_##name##__##pad = \
(structname##__##next & (__alignof__(type)-1)); \
size_t structname##_##name##__##offset = \
structname##__##next + structname##_##name##__##pad; \
size_t structname##_##name##__##sz = n * sizeof(type); \
structname##__##next = structname##__##next + \
structname##_##name##__##pad +
structname##_##name##__##sz;
#define vla_ptr(ptr,structname,name) structname##_##name = \
(typeof(structname##_##name))&ptr[structname##_##name##__##offset]
Then you can do something like this that looks vaguely struct-like:
vla_struct(foo);
vla_item(foo, char, vara, 1);
vla_item(foo, short, varb, 10);
vla_item(foo, int, varc, 5);
vla_item(foo, long, vard, 3);
size_t total = vla_struct_size(foo);
char buffer[total];
vla_ptr(buffer, foo, varc);
foo_varc = 1;
I've been profiling some sample code around this implementation
comparing it between compilers, and it approximates the code size and
speed of using VLAIS in gcc (especially with -O2). It actually performs
better than the previously proposed macros.
But certainly if anyone has a solution which works for everyone, then
I'm more than happy to adopt it. The LLVM community has made quite a few
changes in order to help get Linux working with clang. However, VLAIS is
not something they are willing to accept (for various reasons). There
are other patches to LLVM that are still working their way upstream that
are required to be able to compile Linux as well.
As far as I've been told (though I have been unable to verify), Variable
Length Arrays In Structs (VLAIS) is a feature which made it into gcc
along with nested functions by the work on the Ada frontend. By
contrast, the C99 standard specifies Variable Length Arrays (outside of
structs) and Flexible Array Members (essentially zero-length arrays at
the end of a struct), and as such both are supported by gcc and clang.
The LLVMLinux project is a meta-project between the LLVM and Linux
communities trying to get the toolchain from one working with the code
from the other. The LLVMLinux project isn't trying to replace, nor
break gcc (in fact all the project's kernel patches are tested with gcc
as well). The idea is to bring another toolchain and set of tools to the
table and the kernel community.
Behan
--
Behan Webster
behanw@xxxxxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
