Re: [PATCH] Cast removal

[Len Brown]

On Thursday 05 October 2006 00:12, Andrew Morton wrote:
> On Wed, 4 Oct 2006 23:56:02 -0400
> Len Brown <len.brown@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/