On 03.12.2021 14:34, Andrew Cooper wrote:
> Hello,
>
> Following the __ro_after_init work, I tried to complete a few pieces of
> cleanup that I'd accrued, and everything has unravelled.
>
> On x86, the __2M_* symbols haven't really been 2M aligned since their
> introduction, and the utter mess that was _stext starting at 1M has long
> since been cleared up. Dropping the 2M prefix reveals that we have both
> __init_{start,begin} and identifying that lead to discovering that
>
> /* Destroy Xen's mappings, and reuse the pages. */
> if ( using_2M_mapping() )
> {
> start = (unsigned long)&__2M_init_start,
> end = (unsigned long)&__2M_init_end;
> }
> else
> {
> start = (unsigned long)&__init_begin;
> end = (unsigned long)&__init_end;
> }
>
> is a tautology that nothing is capable of optimising.
Interesting. I would assume it wasn't always that way, but clearly it
is now.
> So I set about trying to simply both x86 and ARM down to a single sets
> of bounding variables, with a requirement that these would be expected
> to be common across all architectures.
>
> I'm intending to use __$FOO_{start,end} because we're semi-consistent on
> this already, and get rid of the ones such as _{s,e}$FOO because they're
> unnecessarily obscure, and complicated to read for a compound foo.
>
> At this point (as I haven't really started yet), I could be persuaded on
> a different naming scheme if anyone has any strong views.
Imo that scheme is fine. _{s,e}$FOO have always seemed risky in terms
of name clashes / confusion to me, but I've assumed we use them for
being pretty standard and hence recognized by certain tools.
> But that's only the start of the fun. The is_kernel() predicate is
> broken (or at least problematic) because it covers the init section.
I'd say problematic. We may want to have is_active_kernel()
paralleling other is_active_...(); whether a need for is_kernel()
would then remain is to be seen.
Jan
