linux-kernel - Re: [GIT PATCH] block: cleanup patches, take#2

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]

Date:	Tue, 17 Mar 2009 09:10:12 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
CC:	axboe@...nel.dk, linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] block: cleanup patches, take#2

Hello, Bartlomiej.

Bartlomiej Zolnierkiewicz wrote:
> Patches look fine but 0002-0003 will cause pata/block merge conflicts
> for linux-next once they go into block tree so no ACK from me for this
> approach.
> 
> $ patch -p1 --dry-run < 0002.patch
> patching file drivers/ide/ide-disk.c
> Hunk #1 FAILED at 405.
> 1 out of 1 hunk FAILED -- saving rejects to file drivers/ide/ide-disk.c.rej
> patching file drivers/ide/ide-ioctls.c
> 
> $ patch -p1 --dry-run < 0003.patch
> patching file drivers/ide/ide-cd.c
> Reversed (or previously applied) patch detected!  Assume -R? [n]

Heh... for some reason, I think Stephen wouldn't have much problem
merging those conflicts.

I was hoping to push this patchset into 2.6.30.  The thing is that if
you only want to take changes from -linus and don't want to provide
git trees, your tree is kind of blocked from both sides except around
-rc1 window, so if there are multiple related changesets, they either
have to go in one after another during a -rc1 window or they need to
be split over multiple -rc1 windows, either of which isn't gonna work
very well.

Please note that this isn't exactly some overhead which is unduly
weighed on you.  Mid-layer or inter-related API changes often incur
merge conflicts and things get very difficult unless there's some
level of cooperation among related trees.

I understand that you're constrained time and resource-wise and will
be happy to make things easier on your side but options are severely
limited if you don't want to take any changes other than from
upstream.  It would be best if you can maintain IDE changes in a git
tree.  All that you lose are petty controls over change history.  The
tree might look less tidy but it makes things much easier when
multiple trees are involved.  I'll be happy to provide merge commits
between blk and ide at sync points, so that you can pull from them and
don't have to worry about conflicts.  I don't really think it will add
a lot to your workload.

That said, let's postpone this patchset post -rc1 window and see how
things can be worked out then.  Hmmm... I'll move the IDE patches on
top of linux-next/pata-2.6 with other IDE patches.

Jens, please keep reviewing.  I'll keep track of ack status.

Thanks.

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