[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46F28A14.6050501@t-online.de>
Date: Thu, 20 Sep 2007 16:56:20 +0200
From: Bernd Schmidt <bernds_cb1@...nline.de>
To: Paul Mundt <lethal@...ux-sh.org>,
Bernd Schmidt <bernds_cb1@...nline.de>,
David McCullough <David_Mccullough@...urecomputing.com>,
Robin Getz <rgetz@...ckfin.uclinux.org>,
uclinux-dist-devel@...ckfin.uclinux.org, bryan.wu@...log.com,
Bernd Schmidt <bernd.schmidt@...log.com>,
Greg Ungerer <gerg@...pgear.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
ysato@...rs.sourceforge.jp, miles.bader@...el.com,
linux-m32r@...linux-m32r.org
Subject: Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Paul Mundt wrote:
> This is making API changes where it's convenient for your platform to use
> this value, and there's no reason to change the API here at all.
Your proposed addition of flat_validate_relval is an API change, and
very similar in nature to what I've done.
A local variable here is the most natural way to store this information.
What do you suggest we use, a global? A member in the task struct?
> Why should all architectures have to change their APIs (not just adding
> new things mind you, also changing existing definitions) to accomodate
> something that can trivially be kept in the blackfin code?
I don't see how there's a burden given that we've provided patches, and
most maintainers have already said their fine with it. It seems to me
that it's a natural and common thing for many architectures to be
updated when new things are added to core code.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists