[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 4 of 4] KEXEC: Introduce new crashtables interface
>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 03/09/12 6:34 PM >>> On 09/03/12 16:11, Jan Beulich wrote: >>>> On 09.03.12 at 15:42, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: >>> --- a/xen/drivers/char/console.c >>> +++ b/xen/drivers/char/console.c >>> @@ -59,8 +59,8 @@ size_param("conring_size", opt_conring_s >>> #define _CONRING_SIZE 16384 >>> #define CONRING_IDX_MASK(i) ((i)&(conring_size-1)) >>> static char __initdata _conring[_CONRING_SIZE]; >>> -static char *__read_mostly conring = _conring; >>> -static uint32_t __read_mostly conring_size = _CONRING_SIZE; >>> +char *__read_mostly conring = _conring; >>> +uint32_t __read_mostly conring_size = _CONRING_SIZE; >> Please don't. If anything, add a call into this file to have the note >> fields filled. > >Why not? Is this about the potential safety of making the symbols >visible outside of console.o? Yes. >Having functions around the codebase to call to fill in values is not >scalable in terms of code; It would either require one function per >intended entry into the crash table, or one function per .c file which >then has to re-switch on the table id. There shouldn't be many. In particular I don't buy that this method is significantly better than having the analysis tool use the symbol table. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |