Re: [Xen-devel] [PATCH v2 4/6] x86/boot: Rename trampoline_{start, end} to boot_trampoline_{start, end}

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Mon, 2019-08-12 at 11:55 +0200, Jan Beulich wrote:
> On 09.08.2019 17:02, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@xxxxxxxxxxxx>
> > 
> > In preparation for splitting the boot and permanent trampolines from
> > each other. Some of these will change back, but most are boot so do the
> > plain search/replace that way first, then a subsequent patch will extract
> > the permanent trampoline code.
> 
> To be honest I don't view it as helpful to do things in this order.
> If you first re-arranged the ordering of items within the trampoline,
> we'd then not end up with an intermediate state where the labels are
> misleading. Is there a reason things can't sensibly be done the other
> way around?

Obviously I did all this in a working tree first, swore at it a lot and
finally got it working, then attempted to split it up into separate
meaningful commits which individually made sense. There is plenty of
room for subjectivity in the choices I made in that last step.

I'm not sure I quite see why you say the labels are misleading. My
intent was to apply labels based on what each object is *used* for,
despite the fact that to start with they're all actually in the same
place. And then to actually move each different type of symbol into its
separate section/location to clean things up.

Is it just the code comments at the start of trampoline.S that you find
misleading in the interim stage? Because those *don't* purely talk
about what bootsym/bootdatasym/trampsym/tramp32sym are used for; they
do say how they are (eventually) relocated. I suppose I could rip that
code comment out of patch #3 completely and add it again in a later
commit... or just just add it again. I write code comments in an
attempt to be helpful to those who come after me (especially when
that's actually myself) but if they're going to cause problems, then
maybe they're more hassle than they're worth?

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel