All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jes Sorensen <jes@trained-monkey.org>
To: root@chaos.analogic.com
Cc: ServeRAID For Linux <ipslinux@us.ibm.com>,
	alan@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [patch] ips.c spin lock 64 bit issues
Date: Thu, 16 Aug 2001 08:55:22 -0400	[thread overview]
Message-ID: <15227.49850.404277.718903@trained-monkey.org> (raw)
In-Reply-To: <Pine.LNX.3.95.1010816084145.8161A-100000@chaos.analogic.com>
In-Reply-To: <OFB6726B6C.6282CC76-ON85256AAA.00434E7F@raleigh.ibm.com> <Pine.LNX.3.95.1010816084145.8161A-100000@chaos.analogic.com>

>>>>> "Richard" == Richard B Johnson <root@chaos.analogic.com> writes:

Richard> I don't think that "unsigned long" is the correct data type.

Richard> Isn't there a data type that means "the largest unsigned
Richard> integer type that fits into a register on the target..."? I was
Richard> told that that's what "size_t" means. If so, all the flags
Richard> variables <everywhere> should be changed to this type. If not,
Richard> then somebody should define a "flags_t" type. With the new
Richard> 64-bit machines, this is going to bite over and over again
Richard> until something like this is done.

Face it, unsigned long *is* the correct data type. The API has been
specified like this for years, no reason to change it. long us
guaranteed to be able to hold a pointer on Linux, ie. the largest
natural data type.

And no, you are more likely to find a 32 bit size_t on some systems and
we do not need yet another obscure data type flags_t when unsigned long
does the job fine as it is.

Jes

  reply	other threads:[~2001-08-16 12:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-16 12:23 [patch] ips.c spin lock 64 bit issues ServeRAID For Linux
2001-08-16 12:48 ` Richard B. Johnson
2001-08-16 12:55   ` Jes Sorensen [this message]
2001-08-16 12:57   ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2001-08-16  4:11 jes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15227.49850.404277.718903@trained-monkey.org \
    --to=jes@trained-monkey.org \
    --cc=alan@redhat.com \
    --cc=ipslinux@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.