[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.