Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

["Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>]

On Fri, Jan 22, 2016 at 1:52 PM, Luis R. Rodriguez
<mcgrof@xxxxxxxxxxxxxxxx> wrote:
> On Fri, Jan 22, 2016 at 11:06 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>> On 01/22/2016 05:44 AM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
>>>
>>>> Something that confuses me is that gcc seems to give these sections the
>>>> "aw" attributes which makes as complain.  This might be a gcc bug.
>>>
>>> Workaround: use an (possibly empty) intializer:
>>>
>>> struct foo {int i;};
>>> const struct foo
>>> __attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0] = {};
>>>
>>
>> And indeed that works.  Awesome!  Much better than having to do an
>> assembly hack.
>
> BTW before we set these in stone given that subarch (lguest, Xen, PC)
> really does provide a split in run time code we *know* we could
> technically free code for subarchs not needed. I don't expect this to
> happen now, but its possibility to do later seems worthy for us to
> consider on architecture here on the way we define the linker tables.
> As I have it linker tables are associated associated with a struct
> (which hpa asked to enable anyone to peg *anything* not just structs),
> these structs then have a priority which uses the linker later to sort
> things for us, and it also has a subarch bitmask which tells us the
> supported subarchs.
>
> Should it be possible to resuse free_init_pages() and/or
> free_reserved_area() only for routines (members in the array in this
> case of a struct of fns) that don't meet our subarch once we're done
> iterating over the routies and know we can discard things we know we
> can drop? Through a cursory glance, *I think* its possible as-is, we
> would just need easy access to the respective start and end addresses
> and I guess there lies the challenge. Question is, is would that be
> clean enough for us? Or are there other things you can think of that
> perhaps might make this prospect cleaner later to add?
>
> I figure better ask now for architectural purposes than later after merged.

I don't think its needed we iron out in a solution *now* to be able to
free code we know we won't need at run time but having a solid
understanding adding this feature later without much impact to users
might be worthy. As such I was pursuing a very basic proof of concept
to ensure this is possible first given I didn't hear back if folks
were sure this might be possible. I don't think a proof of concept
should take long so just want to get fleshed out.

Current dev tree for making this proof of concept:

https://github.com/mcgrof/kbox

If you don't think being prudent about this in terms of architecture
is necessary let me know and I'll just respin based on existing
discussion and we can leave this for later and deal with any required
changes later.

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel