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: <1236786082.3270.20.camel@localhost.localdomain>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ