From: David McCullough <David_Mccullough@securecomputing.com>
To: Robin Getz <rgetz@blackfin.uclinux.org>
Cc: Paul Mundt <lethal@linux-sh.org>,
Bernd Schmidt <bernds_cb1@t-online.de>,
uclinux-dist-devel@blackfin.uclinux.org, bryan.wu@analog.com,
Bernd Schmidt <bernd.schmidt@analog.com>,
Greg Ungerer <gerg@snapgear.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
ysato@users.sourceforge.jp, miles@lsi.nec.co.jp,
linux-m32r@ml.linux-m32r.org
Subject: Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Date: Fri, 21 Sep 2007 13:32:16 +1000 [thread overview]
Message-ID: <20070921033216.GA11139@securecomputing.com> (raw)
In-Reply-To: <200709202144.16301.rgetz@blackfin.uclinux.org>
Jivin Robin Getz lays it down ...
> On Thu 20 Sep 2007 11:03, David McCullough pondered:
> > I would say that (a) is definately not the case. I am sure the BF guys
> > will say they have been banging us on the head with changes for a long
> > time and getting no where as we considered the changes to severe or out
> > of line.
>
> I don't think we have been "banging heads" with you (unless that is your
> feeling?) - how about "working together, but diverting to satisfy different
> needs" :)
No head banging feelings here, but I would understand if you guys felt
that way occasionally ;-) I obviously forgot the happy face on that
statement. It was meant as a good thing.
> I think that we have had more issues in the uClinux-dist (userspace and build
> environment), but for kernel code, we have moved from some non-standard
> (stupid) things we were doing early on to what we have today - which is as
> common/standard with other archs as we can be.
>
> Although this is slightly off topic - on the uClinux distribution side - most
> of our changes are based on requirements/desires from being able to support
> fdpic elf and flat formats, and to attempt to make things easier for end
> users/us to use/maintain. Where we do make changes - we always send the patch
> upstream and have the conversation with you (not everyone else does this),
> and some/most times rework things so they are more acceptable to you. We
> don't always come to an agreement - but we always have the discussion, and
> are willing to move if we can make things better that still meets both our
> needs/desires.
>
> > This particular patch was trivial in comparison to others I've seen,
>
> That is what we thought.
>
> > it fixed all the existing arches (not something that is always done) and
> > seemed a reasonable start to finally get the BF guys up and running.
> > Still, happy to make it better of course ;-)
>
> As always - we are more than happy to explore/review alternative patches if
> people want to write/sumbit them.
Cheers,
Davidm
--
David McCullough, david_mccullough@securecomputing.com, Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
next prev parent reply other threads:[~2007-09-21 3:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-18 8:09 [PATCH] binfmt_flat: minimum support for the Blackfin relocations Bryan Wu
2007-09-19 15:52 ` [Uclinux-dist-devel] " Bryan Wu
2007-09-20 1:31 ` [PATCH] binfmt_flat: minimum support for theBlackfin relocations Robin Getz
2007-09-20 1:55 ` David McCullough
2007-09-20 2:46 ` Robin Getz
2007-09-20 3:18 ` Paul Mundt
2007-09-20 3:42 ` Mike Frysinger
2007-09-20 3:54 ` Paul Mundt
2007-09-20 6:08 ` Robin Getz
2007-09-20 6:34 ` Bryan Wu
2007-09-20 6:41 ` Bryan Wu
2007-09-20 7:35 ` Miles Bader
2007-09-20 12:04 ` Bernd Schmidt
2007-09-20 14:25 ` Paul Mundt
2007-09-20 14:56 ` Bernd Schmidt
2007-09-20 15:03 ` David McCullough
2007-09-21 1:44 ` Robin Getz
2007-09-21 3:32 ` David McCullough [this message]
2007-09-28 15:46 ` Bryan Wu
2007-09-20 7:42 ` Hirokazu Takata
2007-09-28 23:08 ` [PATCH] binfmt_flat: minimum support for the Blackfin relocations Andrew Morton
2007-09-28 23:48 ` Bernd Schmidt
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=20070921033216.GA11139@securecomputing.com \
--to=david_mccullough@securecomputing.com \
--cc=akpm@linux-foundation.org \
--cc=bernd.schmidt@analog.com \
--cc=bernds_cb1@t-online.de \
--cc=bryan.wu@analog.com \
--cc=gerg@snapgear.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m32r@ml.linux-m32r.org \
--cc=miles@lsi.nec.co.jp \
--cc=rgetz@blackfin.uclinux.org \
--cc=uclinux-dist-devel@blackfin.uclinux.org \
--cc=ysato@users.sourceforge.jp \
/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.