linux-kernel - Re: [PATCH 48/60] microblaze_v4: headers simple files

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]

Message-Id: <200806270123.06669.arnd@arndb.de>
Date:	Fri, 27 Jun 2008 01:23:05 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Adrian Bunk <bunk@...nel.org>
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 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.

Since there doesn't seem to be anyone investing work into moving the
files there (I started it before, but got bored before submitting
them all myself), the point of adding a new architecture is exactly
the right one for putting the file to asm-generic. For Michal, there
is no difference between putting the file into asm-generic or
asm-microblaze, other than that he has to change his existing
patch once, but in return he gets fewer files to maintain afterwards.

The fundamental principle here is: if you want your code to get in,
do it in a way that makes your own code cleaner by making it cleaner
for everyone else as well.
The result is that more people look at the code, and that Michal's
name gets more widely known, so the next time he needs something
from another developer, he's more likely to get heard because
you think of him as the person that did all the useful work on
the asm-generic files.

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

With namei.h, I may have gone too far to request moving it
to asm-generic as part of the microblaze merge, because it's
not an ABI header, but I think it's a step in the right direction
anyway, and I may put it there myself if I ever get to do
my "how to port Linux to a new architecture the right way" paper.

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