linux-kernel - Re: Slow DOWN, please!!!

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 2 May 2008 15:22:07 +0200
From:	Enrico Weigelt <weigelt@...ux.de>
To:	linux kernel list <linux-kernel@...r.kernel.org>
Subject: Re: Slow DOWN, please!!!

Hi folks,

<big_snip>

Just a few naive thoughts:

a) What about reducing code size ?

Some parts, IMHO, doen't necessarily need to be in the kernel,
eg. certain filesystems. Less code, less patches to review, less
chance of kernel bugs. Of course this might also cause other 
impacts (eg. performance), so those decisions require great care.

b) Mutli-tier trees / patchlines

IMHO, a major problem are conflicting patches (eg. a core change
causes some driver to break). In measurement instrumentation 
(eg. timesync), there's typically one primary reference point 
(eg. atomic clock) as tier-0, where (a limited set of) tier-1's 
are synchronized against, tier-2 syncs against tier-1 and so on.

So for the linux kernel, we perhaps could have something like:

* tier-0: core
* tier-1: arch
* tier-2: hw drivers
* tier-3: sw drivers
* tier-4: userland interfaces

If a change from a lower tier wants to it's upper tier, it first
MUST fit it's current mainline and carefully checked. Of course
this introduces longer times for an individual change to go to
into release (since it has to pass several tiers), but IMHO the
chance of new bugs in release should be reduced this way.

Of course there might be chances in a lower tier, which obviously 
won't affect several intermediate tiers. Those could skip some tiers.

For example, I'm currently working on an /proc interface for 
changing process privileges. In my model, this had to be settled
in #4, but shouldn't touch drivers (#2,#3), but maybe arch (#1).
So these changes could be kicked directly to #2. 

What do you think about this ?

cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
--
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/