* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > urgh, well, thanks for trying. If there's significant risk factor
> > > (or hassle) in fixing the macros then I'd suggest we not do it for
> > > now - it's a separate project.
> >
> > I'm still at it. I does make sense to convert the damn macro
On Wed, 06 Feb 2008 10:06:18 +0100 Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-02-05 at 10:46 -0800, Andrew Morton wrote:
> > > I got x86-64 compiled by removing the #include from
> > > asm-generic/tlb.h. But who knows what will break if the include is
> > > missing .. I'll cross
On Tue, 2008-02-05 at 10:46 -0800, Andrew Morton wrote:
> > I got x86-64 compiled by removing the #include from
> > asm-generic/tlb.h. But who knows what will break if the include is
> > missing .. I'll cross compile some of the other architectures next.
> >
>
> urgh, well, thanks for trying. I
On Tue, 05 Feb 2008 15:39:47 +0100 Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-02-04 at 02:51 -0800, Andrew Morton wrote:
> > > > Look: I can't fix *everyone's* stuff. This was a consequence of ongoing
> > > > unbounded churn in the x86 tree. If we can find a way of preventing
On Mon, 2008-02-04 at 02:51 -0800, Andrew Morton wrote:
> > > Look: I can't fix *everyone's* stuff. This was a consequence of ongoing
> > > unbounded churn in the x86 tree. If we can find a way of preventing those
> > > guys (and everyone else) from trashing everyone else's stuff then we'd
> > >
On Mon, 4 Feb 2008 11:02:38 + Russell King <[EMAIL PROTECTED]> wrote:
> I don't see any end to these bun fights at the start of the merge window.
> I believe it's inevitable given the work flow that we're now using.
I'm trying to find someone who will run an merged tree of all the
subsystems
On Mon, Feb 04, 2008 at 02:51:33AM -0800, Andrew Morton wrote:
> If this situation (conflicting changes and poor code quality) persists into
> the 2.6.25 cycle I will toss all the subsystem trees out of -mm, shall
> rebase -mm on mainline and shall merge first. I had decided today to
> actually ju
On Mon, 04 Feb 2008 11:36:49 +0100 Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> On Sat, 2008-02-02 at 21:53 -0800, Andrew Morton wrote:
> > On Sun, 03 Feb 2008 16:37:00 +1100 Benjamin Herrenschmidt <[EMAIL
> > PROTECTED]> wrote:
> >
> > > Why dropping add-mm-argument-to-pte-pmd-pud-pgd_free.p
On Sat, 2008-02-02 at 21:53 -0800, Andrew Morton wrote:
> On Sun, 03 Feb 2008 16:37:00 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> wrote:
>
> > Why dropping add-mm-argument-to-pte-pmd-pud-pgd_free.patch though ?
>
> I dropped the whole series.
Sniff .. my patches .. ;-)
> > It's a sane
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > It's a sane patch and a helps going further, and a total pain to
> > re-do later on. Besides, I may have some use for it on powerpc at
> > some point too...
>
> OK, I'll try to reestablish it.
>
> Look: I can't fix *everyone's* stuff. This was a
On Sun, 03 Feb 2008 16:37:00 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> Why dropping add-mm-argument-to-pte-pmd-pud-pgd_free.patch though ?
I dropped the whole series.
> It's a sane patch and a helps going further, and a total pain to re-do
> later on. Besides, I may have some us
Why dropping add-mm-argument-to-pte-pmd-pud-pgd_free.patch though ?
It's a sane patch and a helps going further, and a total pain to re-do
later on. Besides, I may have some use for it on powerpc at some point
too...
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On Mon, 12 Nov 2007 15:30:11 +0100
[EMAIL PROTECTED] wrote:
> From: Martin Schwidefsky <[EMAIL PROTECTED]>
>
> Background: I've implemented 1K/2K page tables for s390. These sub-page
> page tables are required to properly support the s390 virtualization
> instruction with KVM. The SIE instruction
On Thu, Jan 03 2008 at 15:12 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
>> Can we please just nuke CONFIG_HIGHPTE? There's only been a small
>> amount of 32bit machines
>
> It's unfortunately a larger amount :/ And for unknown reasons a lot of
> people still install 32bit kernels on new perfec
> Can we please just nuke CONFIG_HIGHPTE? There's only been a small
> amount of 32bit machines
It's unfortunately a larger amount :/ And for unknown reasons a lot of
people still install 32bit kernels on new perfectly capable 64bit systems
even if they have a lot of memory.
I don't think remov
> > Can we please just nuke CONFIG_HIGHPTE? There's only been a small
> > amount of 32bit machines with so much memory that they'd need it
> > and they can happily stay on the currently supported enterprise
> > distro releases instead of dragging this cruft around forever.
>
> And all MMU-equipp
On Wed, 2 Jan 2008, Christoph Hellwig wrote:
> On Mon, Nov 12, 2007 at 03:30:11PM +0100, [EMAIL PROTECTED] wrote:
> > From: Martin Schwidefsky <[EMAIL PROTECTED]>
> > Solution: The only solution I found to this dilemma is a new typedef:
> > a pgtable_t. For s390 pgtable_t will be a (pte *) - to be
On Mon, Nov 12, 2007 at 03:30:11PM +0100, [EMAIL PROTECTED] wrote:
> From: Martin Schwidefsky <[EMAIL PROTECTED]>
> Solution: The only solution I found to this dilemma is a new typedef:
> a pgtable_t. For s390 pgtable_t will be a (pte *) - to be introduced
> with a later patch. For everybody else i
18 matches
Mail list logo
