Subject: Re: Non-portability in kernel

From: Chris Rutter <[email-masked]>
Date: Fri, 4 Aug 2000 15:40:40 +0100

On Fri, 04 Aug 2000 09:35:35 Russell King - ARM Linux Admin wrote:

> Chris Rutter writes:
> > Um, does no one care that code like this:
> 
> That's very a harsh way of putting it.  Yes, people do care, however
> no one has reported this specific area as a problem before now, and
> therefore it hasn't been fixed.
> 
> What would've been more useful is to have received a patch to correct
> this.

I thought it possible that there are widespread portability assumptions
made in the Linux kernel that made that irrelevant.  I wasn't making a
value judgement.

For instance, is it true that __u8, __u16 and __u32 are assumed to be
precisely that many bits wide?

It would be necessary to know what portability assumptions are made in
order to know how generically portable the patch would need to be; I
doubt that it would need the full mLib READ32_L treatment, for instance;
I imagine sexswap(__u32) might do the trick.  I assume so much of Linux
would break if those types weren't as they say...

Roll off C9-fin-X.

c.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]
This is a backup list for [email-masked], and the subscription
list is regularly synchronised.

---

From: Chris Rutter <[email-masked]>
Date: Fri, 4 Aug 2000 15:40:40 +0100

Roll off C9-fin-X.

c.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 4 Aug 2000 17:17:58 +0100 (BST)

> made in the Linux kernel that made that irrelevant.  I wasn't making a

The assumptions are that:

  __u8, __u16, __u32 are all unsigned quantities of the indicated size.
  __s8, __s16, __s32 are all signed quantities of the indicated size.

  sizeof(unsigned long) >= sizeof(unsigned int) (standard ANSI)
  sizeof(unsigned int) >= sizeof(unsigned short) (standard ANSI)
  sizeof(unsigned short) >= sizeof(unsigned char) (standard ANSI)

> would break if those types weren't as they say...

We have nothing called "sexswap" because that is too specific.  Instead,
we have cpu_to_le16(), be32_to_cpu() to convert from a specified endian
to whatever endianness the cpu is.

However, having said that, there were quite a few instances where the
use of the unguaranteed types (unsigned int etc) were used in
fs/partitions/acorn.[ch] which I have now corrected, so its no longer
necessary for a patch.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 4 Aug 2000 17:17:58 +0100 (BST)

---

From: Matthew Wilcox <[email-masked]>
Date: Fri, 4 Aug 2000 13:23:34 -0400

>   sizeof(unsigned short) >= sizeof(unsigned char) (standard ANSI)

Linux also assumes that sizeof(void *) == sizeof(unsigned long).
but that's ok, because all sane architectures are either ILP32 or LP64.

-- 
Revolutions do not require corporate support.

---

From: Matthew Wilcox <[email-masked]>
Date: Fri, 4 Aug 2000 13:23:34 -0400

---

From: "H. Peter Anvin" <[email-masked]>
Date: 9 Aug 2000 15:19:04 -0700

Followup to:  <[email-masked]>
By author:    Russell King - ARM Linux Admin <[email-masked]>
In newsgroup: linux.dev.arm
>   sizeof(unsigned short) >= sizeof(unsigned char) (standard ANSI)

There is also an assuption that uintptr_t is unsigned long.  This is
not standard.

	-hpa
-- 
<[email-masked]> at work, <[email-masked]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]
++        Please use [email-masked] for           ++
++                        kernel-related discussions.                      ++