lkml.org 
[lkml]   [2002]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: bit ops on unsigned long?
Date
In message <200203250621.g2P6LG023329@vindaloo.ras.ucalgary.ca> you write:
> > These changed are required because otherwise you try to do set_bit on
> > something not aligned as a long on all archs.
>
> But of course. I'm not denying that. Naturally the type should be
> changed. I thought that was obvious so I didn't bother agreeing. But
> in fact, it already *is* aligned on a long boundary. Better, in
> fact. It's aligned on a 16 byte boundary. Even though the type was
> __u32.

I'm confused:

@@ -212,7 +212,7 @@
struct minor_list
{
int major;
- __u32 bits[8];
+ unsigned long bits[256 / BITS_PER_LONG];
struct minor_list *next;
};

How, exactly, did "bits" end up on a 16-bute boundary before this
patch?

Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.928 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site