[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8.1 12/27] xsplice: Implement support for applying/reverting/replacing patches.
> >+static int prepare_payload(struct payload *payload, > >+ struct xsplice_elf *elf) > >+{ > >+ const struct xsplice_elf_sec *sec; > >+ unsigned int i; > >+ struct xsplice_patch_func_internal *f; > > Why is there a second ("internal") variant of this structure now? What > guarantees it to remain in sync with the non-"internal" one? The internal is gone now. > > >+ sec = xsplice_elf_sec_by_name(elf, ".xsplice.funcs"); > > Since the string literal occurs at least twice, I'd suggest having a #define > for it. OK, I also did it (in the later patches) for the .xsplice.depends and .gnu.... > > >+ ASSERT(sec); > >+ if ( sec->sec->sh_size % sizeof(*payload->funcs) ) > >+ { > >+ dprintk(XENLOG_ERR, XSPLICE "%s: Wrong size of .xsplice.funcs!\n", > >+ elf->name); > >+ return -EINVAL; > >+ } > >+ > >+ payload->funcs = sec->load_addr; > >+ payload->nfuncs = sec->sec->sh_size / sizeof(*payload->funcs); > > Following to our discussion yesterday - can't we (ab)use the section merge > flag here to report the structure size, along the lines of what relocation > sections do for their elements? In other words - the xsplice-tools.git and the test-cases (in arch/x86/xen/test) would modify the sec->sh_entsize to have the sizeof(xsplice_patch_func) aka 64 (0x40) ? [Note this could also extend to .xsplice.hooks.load and .xsplice.hooks.unload] The xsplice-tools.git could surely do it, but the built-in test-cases - not so much. I would need to do some in-place binary handrolling - unless you know of some tool or some __section modifiers? _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |