Re: bit ops on unsigned long?

[Richard Gooch <rgooch@ras.ucalgary.ca>]

Rusty Russell writes:
> 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?

Oh, I wasn't talking about this part of the code at all. That's
actually broken in other ways as well (see the other thread where I
replied to Carsten Otte).

I'm just talking about the devfs_alloc_unique_number() implementation,
which *also* was using an array of __u32. That's where you cast doubt
upon the memset/memcpy, a few emails ago. Apart from the missing cast
to void *, I assert that devfs_alloc_unique_number() is 100% correct.
The type of the bitfield should be changed, of course, for cleanliness
reasons, but it isn't actually a bug.

Clear now? Or should I just telephone you for a few minutes rather
than go back and forth in a dozen more emails? :-)

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca