* Andi Kleen <[email protected]> wrote:
> > Basically, non-atomic setup of basic architecture state _is_ going to be
> > a nightmare, lockdep or not, especially if it uses common infrastructure
> > like 'current', spin_lock() or even something as simple as C functions.
> > (for example the stack-footprint tracer was once hit by this weakness of
> > the x86_64 code)
>
> I disagree with that. The nightmare is putting stuff that needs so
> much infrastructure into the most basic operations.
ugh, "having a working current" is "so much infrastructure" ?? Lockdep
uses a very low amount of infrastructure, considering its complexity: it
has its own allocator, uses raw spinlocks, raw irq flags ops, it
basically implements its own infrastructure for everything. Being able
to access a per-task data area (current) is a quite fundamental thing
for kernel code.
the i686 PDA patches introduce tons of early_current() uses. While i
like the new PDA code, its bootstrap (like x86_64's PDA bootstrap) is
too fragile in my opinion, and it will regularly hit instrumenting
patches.
Perhaps the early setup code (if we really want to do it all in C)
should be moved into 32-bit early boot userspace code (like
compressed/misc.c) and it will thus not depend on any kernel
infrastructure.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
