On Mon, 2007-12-10 at 10:45 -0500, Daniel Gryniewicz wrote:
> On Sat, 2007-12-08 at 09:17 -0500, Jeff Dike wrote:
> > A skas3 patch which works on 2.6.23 is below.
>
> BTW, it would appear that applying this patch breaks building the
> resulting kernel as a guest kernel, at least on x86_64.
> as
It turns out that if there's a panic early enough, UML will just sit
there in the LED-blinking loop because the panic notifier hadn't been
installed yet.
This patch installs it earlier.
It also fixes the problem which exposed the hang, namely that if you
give UML a zero-sized initrd, it will ask
Calculate TASK_SIZE at run-time by figuring out the host's VMSPLIT -
this is needed on i386 if UML is to run on hosts with varying VMSPLITs
without recompilation.
TASK_SIZE is now defined in terms of a variable, task_size. This gets
rid of an include of pgtable.h from processor.h, which can cause
This is a resend of the tlb.h patch from last week, plus four more
small fixes and cleanups.
They should wait for 2.6.25.
Jeff
--
Work email - jdike at linux dot intel dot com
-
SF.Net email
signals_enabled and pending have requirements on the order in which
they are modified. This used to be done by declaring them volatile
and putting an mb() where the ordering requirements were in effect.
After getting a better (I hope) understanding of how to do this
correctly, the volatile declar
[ Removed the check of mm_users which can't succeed and gave tlb.h an
include of percpu.h ]
Customize the hooks in tlb.h to optimize TLB flushing some more.
Add start and end fields to tlb_gather_mmu, which are used to limit
the address space range scanned when a region is unmapped.
The interfac
setjmp_wrapper existed to provide setjmp to kernel code when UML used
libc's setjmp and longjmp. Now that UML has its own implementation,
this isn't needed and kernel code can invoke setjmp directly.
do_buffer_op is massively cleaned up since it is no longer a callback
from setjmp_wrapper and giv
On Sun, Dec 09, 2007 at 12:58:33PM -0800, John Reiser wrote:
> The actual bug is unnecessary complexity, which slows down development.
We live in an imperfect world. I'd like to be able to call getpid and
know that I'm always going to get the right answer. However, I don't
want to have to debug
On Sat, 2007-12-08 at 09:17 -0500, Jeff Dike wrote:
> A skas3 patch which works on 2.6.23 is below.
BTW, it would appear that applying this patch breaks building the
resulting kernel as a guest kernel, at least on x86_64.
asm-x86_64/proc_mm.h doesn't end up in asm/, and the #includes don't use
as
