linux-kernel - Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c

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, 19 Feb 2013 23:00:08 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	li guang <lig.fnst@...fujitsu.com>
cc:	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	x86@...nel.org, isimatu.yasuaki@...fujitsu.com
Subject: Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to
 x86/kernel/acpi/srat.c

On Wed, 20 Feb 2013, li guang wrote:

> Yes, I know there's no new changes in my patch as I said before(not
> based on lasted), but as I try to apply my patch(1/4), it will do
> the right work to move current srat.c from arch/x86/mm/ to
> arch/x86/kernel/acpi/ regardless of what I based is not latest.
> 

Sorry, but that makes no sense.  Your patch cannot be used cleanly if 
there have been subsequent changes to a hunk prior to applying it -- in 
this case the hunk would be the entire file since you're removing it.

These patches would also be pushed by the x86 maintainers, who are not 
cc'd on this patch, and I think it would be unfair to ask them to make up 
for your inability to generate a bleeding edge patch with linux-next.  The 
changes already cited in this thread have been in linux-next for almost 
two weeks, yet you refuse to rebase on top of them.
--
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/