linux-origin
[Top] [All Lists]

Re: broken compiler?

To: Kanoj Sarcar <kanoj@xxxxxxxxxxxxxxxxxxx>
Subject: Re: broken compiler?
From: Ralf Baechle <ralf@xxxxxxxxxxx>
Date: Wed, 29 Mar 2000 02:55:05 +0200
Cc: linux-origin@xxxxxxxxxxx
In-reply-to: <200003290040.QAA90554@google.engr.sgi.com>
References: <20000329023343.C11023@uni-koblenz.de> <200003290040.QAA90554@google.engr.sgi.com>
Sender: owner-linux-origin@xxxxxxxxxxx
On Tue, Mar 28, 2000 at 04:40:41PM -0800, Kanoj Sarcar wrote:

> > The bitfield operations are supposed to only be used on objects that
> > are of type long or are arrays of longs.  So it seems you want to fix
> > things in the wrong direction?
> 
> I can;t say I agree completely. Firstly, the prototype definition is
> (void *), (which is bad in itself). Secondly, if generic code does
> have something like

The prototype is legacy from the dark ages before Linux 1.0.

>       long variable = xxxx.
>       test_and_set_bit(N, &variable)
> 
> it must guarantee that N is less than the size of a long. _Most_
> generic code would then pass in a value N <= 31, to be able to 
> work on most architectures.

This is indeed the assumption.

> Anyway, I am modifying the code into a state where it will be easy
> to revert to the current behavior by changing a couple of #defines
> in bitops.h. I haven't tried the ll/sc to see whether it helps any.

Reverting to ll / sc is _WRONG_ unless you just want to modify the code
to work on objects with 32-bit alignment which will make it unecessarily
slow.

  Ralf

PS: Read the comments about atomicity for example in the definition of
    struct netdevice in include/linux/netdevice.h in 2.2.x.

<Prev in Thread] Current Thread [Next in Thread>