On Tuesday 08 August 2006 03:58, Horms wrote:
> On Tue, Aug 08, 2006 at 01:23:15AM -0600, Eric W. Biederman wrote:
> > Horms <[email protected]> writes:
<snip>
> > For maintenance reasons I propose we introduce CONFIG_PHYSICAL_ALIGN.
> > Which will round our load address up to the nearest aligned address
> > and run the kernel there. That is roughly what I am doing on x86_64
> > at this point.
> >
> > s/CONFIG_PHYSICAL_START/CONFIG_PHYSICAL_ALIGN/ gives me well defined
> > behavior and allows the alignment optimization without getting into
> > weird semantics.
> >
> > Before CONFIG_PHYSICAL_START we _always_ ran the arch/i386 kernel
> > where it was loaded and I assumed we always would. Since people have
> > realized better aligned kernels can run better this assumption became
> > false. Going to CONFIG_PHYSICAL_ALIGN allows us to return to the
> > simple assumption of always running the kernel where it is loaded
> > modulo a little extra alignment.
>
> That sounds reasonable to me. Though it is a little less flexible,
> do you think that could be a problem? Perhaps we could have both,
> though that would probably be quite confusing.
More than reasonable. By changing this it seems that the kernel would still
work with older bootloaders, function properly under kexec and might actually
lead to a way to potentially recover a system from a crash without a reboot
by allowing the kexec'd kernel to reset the system.
Of course the last is only a wish... Never happen because of the complexity
involved. It would require a lot of work (I'd do this, but I'm currently
arguing with the kernel over my attempts at building a functional DRM backed
console) in having to switch back to real-mode to make the proper BIOS calls
to reset the busses et. al. before switching *back* to kernel mode to run the
standard startup.
Still, by letting a kernel run where it's loaded plus some modulo to get it
properly aligned in memory solves several problems. It removes the need for
CONFIG_PHYSICAL_START and the code involved in handling that. The kexec code
that reserves memory for the new kernel image can be tweaked to always
allocate the memory *aligned*...
Anyway, I'd better get back to the DRMCon code...
DRH
-
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]
