linux-kernel - Re: Announce: Linux-next (Or Andrew's dream :-))

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: <20080212.164149.209357519.davem@davemloft.net>
Date:	Tue, 12 Feb 2008 16:41:49 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	greg@...ah.com
Cc:	torvalds@...ux-foundation.org, jeff@...zik.org,
	arjan@...radead.org, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

From: Greg KH <greg@...ah.com>
Date: Tue, 12 Feb 2008 11:15:53 -0800

> On Tue, Feb 12, 2008 at 10:26:53AM -0800, Linus Torvalds wrote:
> > We absolutely MUST NOT have the mindset that "cross-subsystem conflicts 
> > happen all the time". 
> 
> They usually don't, by virtue of our current development model and how
> we have the kernel structured.

BTW, there are some things we can do to with the kernel structure
to help a lot of really idiotic cases.  Here are some odd-the-cuff
suggestions:

1) Make feature-removal-schedule a directory with files in it.
   Everyone touches that file, creating merge issues.

2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
   instead have each "thing" have it's own Kconfig.foo or
   Makefile.foo that gets automatically sucked into the main
   directory Makefile or Kconfig using file globs or similar.

   Even better, encode the building of things into the *.[ch]
   files themselves, and have the Kconfig/Makefile machinery
   automatically extract this information when you build.

Little things like this would go a long way to eliminating merge
hassles.

For example, with #2, when a driver is added it would only
every add files never edit existing files.  Merge conflicts
are impossible unless two new drivers try to use the same
file names. :-)

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