linux-kernel - Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5]

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: <20071112074441.GC9771@stusta.de>
Date:	Mon, 12 Nov 2007 08:44:41 +0100
From:	Adrian Bunk <bunk@...nel.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	David Howells <dhowells@...hat.com>, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-am33-list@...hat.com
Subject: Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the
	kernel [try #5]

On Sat, Nov 10, 2007 at 11:43:20AM -0800, Andrew Morton wrote:
> On Sat, 10 Nov 2007 12:18:50 +0000 David Howells <dhowells@...hat.com> wrote:
>...
> > has a couple of examples on it's front page.  If you work through the menus of
> > modern Panasonic tellies, you might find a URL pointing somewhere on this
> > website that isn't reachable by linking from the index page of the website.
> > 
> > I don't know who else uses this CPU, but it's possible MEI sell them to other
> > companies.
> 
> If it is indeed the case that this architecture is used internally by a
> single organisation then perhaps it doesn't make sense for us to merge it.
> 
> One of the main reasons we put code into the kernel is as a means of
> distribution: to get it into the hands of people who need it.  But in this
> situation there is no advantage to *anyone* from this merge apart from MEI.
> 
> IOW, the submitter gains and everyone else loses.  It's a curious situation.
>...

You miss the point that we want people to be able to use Linux in such 
situations.

There are basically two choices:
- Either tell them code won't get merged and offer some degree of API
  stability in exchange or
- allow all code with >= 1 users to enter the kernel. [1]

With the current development model (and the mere amount of changes 
merged), the first choice is not possible.

The only reason for not merging it [1] would be if it would be 
unmaintained and bitrot, but considering that David is already doing a 
good job at maintaining the frv port that's not an issue here.

cu
Adrian

[1] assuming the code itself is considered OK

-- 

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