Hi tglx, Arnd, Kyle and Sam,
Thank you for your kindly reply, I will update
the code according to your comments.
The fixed patches will be sent out soon.
--
Best regards
Liqin
liqin.chen@xxxxxxxxxxxxx
Arnd Bergmann <arnd@xxxxxxxx> 写于 2009-03-28 04:53:05:
> On Friday 27 March 2009, Sam Ravnborg wrote:
>
> > Thats strange indeed.
> > This structure will then change layout depending on the target
bit-size
> > of the compiler.
> >
> > From x86:
> > #ifdef __i386__
> > unsigned long __unused1;
> > #endif
> > __kernel_time_t shm_dtime; /* last detach time */
> > #ifdef __i386__
> > unsigned long __unused2;
> > #endif
> >
> > long is 64 bit in one case and 32 bit in another case.
> > I'm confused..
>
> The idea here is to have the same layout for both by adding
> long (32 bit) padding between 32 bit members on i386 and not
> having the padding along the __kernel_time_t (which is also
> long) members on x86_64. The problem is that some architectures
> copying this didn't understand the part about the padding,
> while others (big-endian ones) put the padding in the wrong
> place by copying from i386.
>
> By now, most of the existing architectures copied the i386
> file, which is at least consistent and we've learned to
> deal with it. I recommend just using this one as the
> asm-generic version and letting all new archs fall back
> to that.
>
> > I would expect it to be safer to be bit-size neutral in our
> > exported headers.
> > But the score people know there userlend best so let them decide.
>
> > Still they should audit all their exported headers.
> > They cannot assume it was right because they copied them from
> > somewhere.
>
> Yes, I agree. Hopefully I'll manage to get my patches into
> shape to post the generic versions in the next days so we can use
> them on microblaze and score as well as all future versions.
>
> Arnd <><
?韬{.n?????%??檩??w?{.n???{饼??Ф?塄}?财??j:+v?? ? ???2??璀??摺?囤??z夸z罐?+?????w棹f
