lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 20 Sep 2007 21:44:16 -0400
From:	Robin Getz <rgetz@...ckfin.uclinux.org>
To:	David McCullough <David_Mccullough@...urecomputing.com>
Cc:	Paul Mundt <lethal@...ux-sh.org>,
	Bernd Schmidt <bernds_cb1@...nline.de>,
	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@....nec.co.jp,
	linux-m32r@...linux-m32r.org
Subject: Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations

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" :)

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.

-Robin
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ