linux-kernel - Re: [PATCH 00/13] convert voyager over to the x86 quirks model

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:	Wed, 11 Mar 2009 10:41:22 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: [PATCH 00/13] convert voyager over to the x86 quirks model

On Tue, 2009-03-10 at 23:37 +0100, Ingo Molnar wrote: 
> * James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> 
> > Given the lack of feedback, I went ahead and implemented the 
> > additions to smp_ops and x86_quirks (and a dynamic mca NMI 
> > hook) to allow voyager to be plumbed in.
> > 
> > There also needs to be changes in the boot setup to make 
> > voyager work dynamically: It has to be detected first, so the 
> > a20 gate check is only executed if a voyager is not found.
> > 
> > I also completed some of the subarchitecture eliminations, so 
> > all the include file infrastructure should be gone.
> > 
> > The result is that I can boot both my PC SMP x86 boxes and 
> > voyager with the same kernel.
> > 
> > This patch series applies on the x86/apic branch of the x86 
> > tree (obviously with 965c7ecaf2e2b083d711a01ab33735a4bdeee1a4 
> > reverted)
> 
> The question is, why would we want to merge Voyager back ever 
> again?

What do you mean merge back?  It's an existing and supported
architecture in git head.

> The hardware is obsolete and is not being produced anymore,

That goes for a huge number of drivers we have in the kernel currently,
and several whole architectures, so it's not a barrier to keeping
something maintained.

> nobody but you uses development kernels on it,

I don't think we've ever had a problem with a downstream community being
supported by a single upstream developer.

>  and it caused all 
> sorts of x86 maintenance overhead all along. It did not even 
> build since August 2008, up until the point we removed it - 
> 2.6.26.0 was the last time it built.

2.6.29-rc7 builds and boots just fine from git head.

Your prior statement was that you wanted it moved to the x86 quirks
infrastructure to make it easily maintainable, which this patch series
does ... I don't quite see what your problem is now ... are you saying
that x86 quirks isn't as maintainable as you previously thought?  In
which case, how can I help?

James


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