From: Andi Kleen <ak@suse.de>
To: Carlos O'Donell <carlos@baldric.uwo.ca>
Cc: willy@debian.org, akpm@osdl.org, linux-arch@vger.kernel.org
Subject: Re: compat-signal-noarch-2004-01-29.patch
Date: Sat, 28 Feb 2004 20:36:58 +0100 [thread overview]
Message-ID: <20040228203658.5a11df00.ak@suse.de> (raw)
In-Reply-To: <20040228191536.GA19963@baldric.uwo.ca>
On Sat, 28 Feb 2004 14:15:37 -0500
Carlos O'Donell <carlos@baldric.uwo.ca> wrote:
> I agree wholeheartedly. I don't want to remove choice, but I do want to
> make maintenance easier, and reduce duplication of effort.
With adding is_compat_task() you're making long term mainteance harder.
> > They are pretty standard, except for the odd long long is different
> > from long long in 32bit requirement (which many people who try to
> > design compat compatible interfaces get wrong unfortunately because
> > it's a non issue on the RISCs)
>
> AFAIK 'long long' has to be a _minimum_ of 64-bits, but may infact be
> larger. Implementation details always have to be worked out by hand :o)
You misundertood, but never mind.
> The patch below will effectively remove is_compat_task() for x86_64.
> Apply it if you wish. You can do a number of nasty things with the
> definition of is_compat_task() in order to catch improper uses.
I must admit I am still not very happy about this.
It would be better to not have it in the first place, because it's a bogus
interface. In the current form people will start to use it for all kinds
of broken uses and it will be eventually impossible to get rid of it.
Is it really that hard to do the switch in architecture specific code?
I really fail to see where the problem is for you with this.
-Andi
next prev parent reply other threads:[~2004-02-28 19:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040225152204.2769a99b.akpm@osdl.org>
[not found] ` <20040226043605.GD17229@baldric.uwo.ca>
[not found] ` <20040229021045.78ac9466.ak@suse.de>
[not found] ` <20040226155930.GB24779@baldric.uwo.ca>
[not found] ` <20040226173115.7bd1aa86.ak@suse.de>
[not found] ` <20040226163812.GP25779@parcelfarce.linux.theplanet.co.uk>
[not found] ` <20040226174753.4319802c.ak@suse.de>
[not found] ` <20040226194747.GA28037@baldric.uwo.ca>
[not found] ` <20040226205058.5a0d1e34.ak@suse.de>
2004-02-27 23:40 ` compat-signal-noarch-2004-01-29.patch Carlos O'Donell
2004-03-02 20:39 ` compat-signal-noarch-2004-01-29.patch Andi Kleen
2004-02-28 19:15 ` compat-signal-noarch-2004-01-29.patch Carlos O'Donell
2004-02-28 19:36 ` Andi Kleen [this message]
2004-02-28 20:28 ` compat-signal-noarch-2004-01-29.patch Carlos O'Donell
2004-02-28 21:40 ` compat-signal-noarch-2004-01-29.patch Andi Kleen
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=20040228203658.5a11df00.ak@suse.de \
--to=ak@suse.de \
--cc=akpm@osdl.org \
--cc=carlos@baldric.uwo.ca \
--cc=linux-arch@vger.kernel.org \
--cc=willy@debian.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox