Re: [Xen-devel] [RFC v2] xSplice design

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.06.15 at 18:00, <konrad.wilk@xxxxxxxxxx> wrote:
> On Fri, Jun 05, 2015 at 04:16:59PM +0100, Jan Beulich wrote:
>> >>> On 05.06.15 at 16:49, <konrad.wilk@xxxxxxxxxx> wrote:
>> > On Mon, May 18, 2015 at 01:41:34PM +0100, Jan Beulich wrote:
>> >> >>> On 15.05.15 at 21:44, <konrad.wilk@xxxxxxxxxx> wrote:
>> >> A general remark: Having worked on ELF on different occasions,
>> >> UNIX'es (and hence Linux'es) use of section names to identify the
>> >> sections' purposes is pretty contrary to ELF's original intentions.
>> >> Section types (and architecture as well as OS extensions to them)
>> >> exist for a reason. Of course from the following sections it's not
>> >> really clear in how far you intended this to be done. If you did
>> >> and just didn't explicitly say so, pointing out that relations
>> >> between sections should then also be expressed suitably via ELF
>> >> mechanisms (sh_link, sh_info) would then be unnecessary too. If
>> >> you didn't, then I'd strongly suggest switching to a formally more
>> >> correct model, which would then include specifying section types
>> >> and section attributes (and optional other relevant aspects)
>> >> along with their (then no longer mandatory) names.
>> > 
>> > 
>> > Something like:
>> > http://docs.oracle.com/cd/E23824_01/html/819-0690/chapter7-1.html 
>> 
>> Yes, the SHT_SUNW_* ones are examples of what I mean.
>> 
>> > With (for example) an pointer to a specific section:
>> > http://docs.oracle.com/cd/E23824_01/html/819-0690/chapter7-28.html#scrolltoc
>> >  
>> > ?
>> 
>> Not sure what part of that page you mean to refer to.
> 
> The whole page - with the:
> 
> typedef struct {
>         Elf32_Word      c_tag;
>         union {
>                 Elf32_Word      c_val;
>                 Elf32_Addr      c_ptr;
>         } c_un;
> } Elf32_Cap;
> 
> .. and such.

But where's the section reference that I thought you meant to use
as an example?

>> >> > #define XSPLICE_HOWTO_BUG           4 /* BUG_ON being replaced.*/  
>> >> > #define XSPLICE_HOWTO_EXTABLE       5 /* exception_table change. */  
>> >> > #define XSPLICE_HOWTO_SYMBOL        6 /* change in symbol table. */  
>> >> 
>> >> For none of these I really understand their purpose.
>> > 
>> > This is to help the hypervisor to figure out which of the lookup
>> > mechanisms to use to find the relevant section. As in if we need
>> > to update (as part of the patch) a normal function, but also
>> > the exception table (because the new function is at a new virtual
>> > address) we want to search in the exception table for the old 
>> > one and replace it with the new virtual address.
>> 
>> I think this gets too specific. Telling apart code and data may make
>> sense, but I think beyond that thing should be expressed as
>> generically as possible. Imagine new special data kinds showing up
>> - do you envision adding a special type (and hence special handling)
>> for all of them?
> 
> Yes and then updating the design document to include it.
> 
> Would there be an more relaxed way to go about this?

This isn't a question of relaxed or strict, but of being generic or
specific. And I think keeping things generic will make the whole
thing better maintainable.

Jan


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