Re: [PATCH 01/31] cpumask: Documentation

[Mike Travis]

Rusty Russell wrote:
> On Wednesday 01 October 2008 19:13:25 Ingo Molnar wrote:
>> that looks very sane to me.
> 
> Thanks, it's reasonably nice.  The task of hitting all those cpumask_t users 
> is big, and I don't think we can do it in one hit.
> 
>> one small request:
>>> I'll commit these to my quilt series today.
>> IMHO, an infrastructure change of this magnitude should absolutely be
>> done via the Git space. This needs a ton of testing and needs bisection,
>> a real Git track record, etc.
> 
> Not yet.  Committing untested patches into git is the enemy of bisection; if 
> one of my patches breaks an architecture, they lose the ability to bisect 
> until its fixed.  If it's a series of patches, we can go back and fix it.
> 
> Now, once it's been tested a little, it's better for you to git-ize it and 
> I'll send you patches instead.  But I want some more people banging on it, 
> and a run through linux-next first...
> 
> If Mike's happy to work on these as a basis, we should be able to get there 
> soon; the patches are sitting in my tree at http://ozlabs.org/~rusty/kernel/ 
> (see rr-latest symlink).

Absolutely!  I may have my own concerns and preferences but the end goal is
far more important.  I'll take a look at it today.  [My only other pressing
matter is convincing Ingo to accept the SCIR driver (or tell me how I need
to change it so it is acceptable), so my management is happy... ;-)]

> 
> Thanks,
> Rusty.
> PS.  To emphasize, I haven't actually *booted* this kernel.  My test machines 
> are still in transit as I move (and ADSL not connected yet... Grr...)

Since our approaches are not different in concept, I can assure you that it
works... ;-)  And as Ingo and others have noted, the infrastructure is easy
to verify, it's the allocation of the temporary cpumasks that will be more
difficult to test.

Cheers,
Mike

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