linux-kernel - Re: [PATCH 01/31] cpumask: Documentation

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: <48E4C488.9020408@sgi.com>
Date:	Thu, 02 Oct 2008 05:54:32 -0700
From:	Mike Travis <travis@....com>
To:	Rusty Russell <rusty@...tcorp.com.au>
CC:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jack Steiner <steiner@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/31] cpumask: Documentation

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/