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:	Fri, 27 Jun 2008 14:59:37 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	monstr@...nam.cz, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, stephen.neuendorffer@...inx.com,
	John.Linn@...inx.com, john.williams@...alogix.com, matthew@....cx,
	will.newton@...il.com, drepper@...hat.com,
	microblaze-uclinux@...e.uq.edu.au, grant.likely@...retlab.ca,
	linuxppc-dev@...abs.org, vapier.adi@...il.com,
	alan@...rguk.ukuu.org.uk, hpa@...or.com,
	Michal Simek <monstr@...str.eu>
Subject: Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or
	redirect to asm-generic

On Fri, Jun 27, 2008 at 01:23:05AM +0200, Arnd Bergmann wrote:
> On Thursday 26 June 2008, Adrian Bunk wrote:
> > Honestly, I do not completely like your approach of getting the 
> > microblaze port submitter to create the asm-generic files - I would 
> > personally prefer if the microblaze port would look exactly like all 
> > other ports and the (reasonable) changes you have in mind were not
> > being discussed and done as part of the submission of a new port.
> 
> But it works really well this way ;-). My point is that a new port
> should look just like all the other ports should have looked as
> well, not like they did. When it comes to the ABI, you
> cannot make incompatible changes after it's merged, so IMHO all
> ABI defining headers should go to asm-generic if possible.
>...

For the ABI it doesn't matter where the headers are.

> > After all, it won't matter whether we'll unify resp. remove
> > 22 or 23 files.
> 
> That wasn't my idea. The logic was that if one more file exists
> in asm-generic that can be removed from the architectures,
> we get 22 more files to remove without anyone having to look
> at the big picture. When microblaze is in,

Discussions of the "big picture" should be in an own thread, not as 
part of a merge of a new architecture.

I am not an architecture maintainer, but I do not like the way you want 
to couple the microblaze merge with the move of stuff to asm-generic.

They both make sense, but they are clearly separate issues.

> I can compile a list
> with asm-generic files that can be used to replace the architecture
> specific files, so the arch maintainers can decide on their own
> whether to clean their own stuff up or not.
>...

We need either all architectures changed or none at all - we do need the 
arch headers to become more similar, not more different.

And this is why we need an agreement _before_ an asm-generic header gets 
added, not after it.

> 	Arnd <><

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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