[PATCH] powerpc/64s: POWER10 CPU Kconfig build option
Segher Boessenkool
segher at kernel.crashing.org
Sat Oct 8 01:57:25 AEDT 2022
On Fri, Oct 07, 2022 at 10:03:38AM +1000, Nicholas Piggin wrote:
> On Fri Oct 7, 2022 at 9:23 AM AEST, Segher Boessenkool wrote:
> > > For pcrel addressing? Bootstrapping the C environment is one, the
> > > module dynamic linker is another.
> >
> > I don't know what either of those mean.
>
> arch/powerpc/kernel/head_64.S and arch/powerpc/kernel/module_64.c
>
> Can discuss in the pcrel patch series thread if you would like to know
> more.
So "bootstrapping the C environment" is meant to mean "initialising it",
like *rt*.o ("C runtime") does normally?
And "module dynamic linker" is "module loader" here?
Yes, those things probably need some attention for pcrel, but
"bootstrapping" and "dynamic" had me scratch my head: there is nothing
that pulls itself up by its bootstraps (like, the initialisation itself
would be done in C code), and module loading is much closer to static
loading than to dynamic loading :-)
> > Just say in a comment where you disable stuff that it is to prevent
> > possible problems, this is a WIP, that kind of thing? Otherwise other
> > people (like me :-) ) will read it and think there must be some deeper
> > reason. Like, changing code to work with pcrel is hard or a lot of
> > work -- it isn't :-) As you say in 0/7 yourself btw!
>
> I will describe limitations and issues a bit more in changelog of patches
> to enable prefix and pcrel when I submit as non-RFC candidate. It would
> probably not be too hard to get things to a workable state that could be
> merged.
Looking forward to it!
> > VMX and VSX are disabled here because the compiler *will* use those
> > registers if it feels like it (that is, if it thinks that will be
> > faster). MMA is a very different beast: the compiler can never know if
> > it will be faster, to start with.
>
> True, but now I don't have to find the exact clause and have my lawyer
> confirm that it definitely probably won't change in future and break
> things.
Your lawyer won't be able to tell you, but I can. And I did already.
The reason I care about these things is that very often people look at
what the kernel does as a "best practices" example. And then copy this
stuff as some cargo cult incantations :-/
Segher
More information about the Linuxppc-dev
mailing list