linux-kernel - Re: avoiding rejects

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: <20070710201923.GA22675@localdomain>
Date:	Tue, 10 Jul 2007 23:19:23 +0300
From:	Dan Aloni <da-x@...atomic.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: avoiding rejects

On Tue, Jul 10, 2007 at 12:44:22PM -0700, Andrew Morton wrote:
> 
> There are many situations where patching the kernel involves adding a new
> item to a list, such as:
> 
> - adding a makefile line
> - adding a new #include
> - adding a new Kconfig entry
> - adding a new PCI ID
> - adding a record to feature-removal.txt
> - adding a new sysctl table entry
> - etc
> 
> Of course, everyone just sticks the new entry at the end of the existing
> entries.  This strategy carefully maximises the opportunity for patch
> rejects and leads to unhappiness.
> 
> Most of these lists are unordered anyway, so inserting the new item at a
> randomly-chosen position is a better approach than just appending it.

AFAIK some Kconfig entries do have some importance to order (take 
kernel/Kconfig.hz for example, though it's not a good one, not long 
enough).

I think that random insertions can hurt on the readability side. So, here's
a list of more ways to discuss:

1. How about adding a context-aware logic to the merging process? (i.e, 
project-specific "plugins") That is, beside the regular 3-line context, 
the merging logic can be a aware of particular file formats, whether it's a 
Kconfig tree-like structure or list of lines all starting with a prefix of 
'#include'. 

2. Alternatively, these special one-liner diff hunks can be generated with
smaller context space (2, 1, or even no lines). This means instead of 
adding context-awareness to the merger process, add context-awareness
to the diff generator. The other 'more complex' code modifications hunks 
must remain with a context of 3 lines.

3. Another option is to come up with file formats that have '3 space 
lines' dilimeters between items (it wouldn't make sense for #include, but 
for PCI IDs it might be worth it).

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
-
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/