[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2] xSplice design
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |