linux-kernel - Re: [PATCH] Cast removal

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: <200610050043.41997.len.brown@intel.com>
Date:	Thu, 5 Oct 2006 00:43:41 -0400
From:	Len Brown <len.brown@...el.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ACPI List <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH] Cast removal

On Thursday 05 October 2006 00:12, Andrew Morton wrote:
> On Wed, 4 Oct 2006 23:56:02 -0400
> Len Brown <len.brown@...el.com> wrote:
> 
> > I'm okay applying this patch it touches the linux-specific
> > drivers/acpi/* files only, no ACPICA files.
> 
> Why?

Why am I okay with it?
I'm okay with it because it touches files in drivers/acpi/*.c
Those files are Linux specific, and thus no problem
doing with them what we do with any other
Linux file.

> Would it help if it was split into two?

no need to, as the patch didn't touch ACPICA files.

> How do mortals distinguish ACPICA files from Linux files?

the sub-directories under drivers/acpi are ACPICA files.
They have a dual BSD/GPL license on them.
I've though of making an acpica sub-directory
to make this really clear, but there never seems to be
a good time to do stuff like that...

> > But I don't know if Linus will want changes like this post -rc1.
> > It might be a pain to have in the tree all the way to 2.6.20 opens b/c
> > it is sure to cause merge conflicts
> 
> Should be OK - the acpi tree is very slow-changing at present.  Or did you
> have big changes planned?

Okay, I've applied it, dealt with the conflicts,
and I'll send an -rc1 batch this week.

> Or I can maintain it externally along with the 10-20 other acpi patches I
> seem to be regularly stuck with (hint ;)

no need to.

If maintaining individual ACPI-related patches in -mm is a burden,
then refuse to.  While I'll never be able to match your latency,
I'm okay with it either way -- as I think either way the the
right thing happens in the long run.

> > -- and at the end of the day
> > the benefit of this patch is what?  A few less characters in the source... 
> >
> 
> yes, cleanups are a pain, and we do a lot of them.  And we merge just about
> all of them.  But I think it's best in the long run; and we are in this for
> the long run.  

Okay, thanks,
-Len
-
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/