On Thu, 2007-08-16 at 09:26 -0700, Luck, Tony wrote:
> > -#define ACPI_ID_LEN9
> > +#define ACPI_ID_LEN16 /* only 9 bytes needed here, 16 bytes are
> > used */
>
> What will happen if someone uses more than 9 bytes? With the old
> limit there would be a compile time error it some
> -#define ACPI_ID_LEN 9
> +#define ACPI_ID_LEN 16 /* only 9 bytes needed here, 16 bytes are used */
What will happen if someone uses more than 9 bytes? With the old
limit there would be a compile time error it someone initialized
with:
{"PNP0C0ABCDEFGH", 0},
But if we change ACPI_ID_
On Fri, 2007-08-03 at 08:08 +1000, Rusty Russell wrote:
> On Thu, 2007-08-02 at 09:25 -0700, Luck, Tony wrote:
> > > Adrian Bunk: scripts/mod/file2alias.c is compiled with HOSTCC and ensures
> > > that
> > > kernel_ulong_t is correct, but it can't cope with different padding on
> > > different arc
On Fri, Aug 03, 2007 at 08:08:20AM +1000, Rusty Russell wrote:
>...
> scripts/mod/file2alias is the program that reads this: although it can
> be altered to parse 32-vs-64, Adrian's fix is the simplest.
s/Adrian/Thomas/
> Hope that clarifies,
> Rusty.
cu
Adrian
--
"Is there not promise
On Thu, 2007-08-02 at 09:25 -0700, Luck, Tony wrote:
> > Adrian Bunk: scripts/mod/file2alias.c is compiled with HOSTCC and ensures
> > that
> > kernel_ulong_t is correct, but it can't cope with different padding on
> > different architectures.
>
> Surely this is the root cause ... you can't expec
On Thu, Aug 02, 2007 at 09:24:56PM +0200, Sam Ravnborg wrote:
> I am well aware of that.
> My point was that we are dealing with userspace - in this case depmod.
> So I wondered why we had special (as in less strict) rules here.
In reality it's a pointer...
-
To unsubscribe from this list: send th
On Thu, Aug 02, 2007 at 09:15:09PM +0200, Adrian Bunk wrote:
> On Thu, Aug 02, 2007 at 08:09:03PM +0200, Sam Ravnborg wrote:
> >
> > I second this. For anything visible in userspace from
> > include/* we require usage of the kernel specific
> > __u8, __u16, __u32, __u64 typedefs but for device_id
On Thu, Aug 02, 2007 at 08:09:03PM +0200, Sam Ravnborg wrote:
>
> I second this. For anything visible in userspace from
> include/* we require usage of the kernel specific
> __u8, __u16, __u32, __u64 typedefs but for device_id we accept
> kernel_ulong_t which result in the following crap in
> file
On Thu, Aug 02, 2007 at 10:40:14AM -0700, Luck, Tony wrote:
> >>> struct acpi_device_id {
> >>> __u8 id[ACPI_ID_LEN];
> >>> + __u8 dummy[FILLUP_LEN];
> >>> kernel_ulong_t driver_data;
> >>> };
> >>
> >> What's so special about this structure that we get an error?
> >
> > It's special because
>>> struct acpi_device_id {
>>> __u8 id[ACPI_ID_LEN];
>>> + __u8 dummy[FILLUP_LEN];
>>> kernel_ulong_t driver_data;
>>> };
>>
>> What's so special about this structure that we get an error?
>
> It's special because it's a device_id structure, and those structures
> must come out identic
"Luck, Tony" <[EMAIL PROTECTED]> writes:
>> +#define FILLUP_LEN 7 /* dirty fix for i386 -> 64bit cross-compilation */
>>
>> struct acpi_device_id {
>> __u8 id[ACPI_ID_LEN];
>> +__u8 dummy[FILLUP_LEN];
>> kernel_ulong_t driver_data;
>> };
>
> What's so special about this structur
> Adrian Bunk: scripts/mod/file2alias.c is compiled with HOSTCC and ensures that
> kernel_ulong_t is correct, but it can't cope with different padding on
> different architectures.
Surely this is the root cause ... you can't expect that the alignment
rules of HOSTCC to make any sense for an arbitr
On Sat, 2007-07-28 at 03:39 +0200, Adrian Bunk wrote:
> On Fri, Jul 27, 2007 at 04:21:47PM -0700, Luck, Tony wrote:
> > > So it seems on ia64 with gcc 3.3.6 there's some 8 byte alignment of the
> > > array members?
> > >
> > > Sam and the ia64 maintainers Cc'ed - they might know better what's goin
13 matches
Mail list logo
