Re: [Xen-devel] [PATCH v10 2/6] xen: introduce DEFINE_SYMBOL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.02.19 at 19:54, <sstabellini@xxxxxxxxxx> wrote:
> On Tue, 26 Feb 2019, Jan Beulich wrote:
>> >>> On 25.02.19 at 21:50, <sstabellini@xxxxxxxxxx> wrote:
>> > --- a/xen/include/xen/compiler.h
>> > +++ b/xen/include/xen/compiler.h
>> > @@ -99,6 +99,38 @@
>> >      __asm__ ("" : "=r"(__ptr) : "0"(ptr));      \
>> >      (typeof(ptr)) (__ptr + (off)); })
>> >  
>> > +
>> > +/*
>> > + * Declare start and end array variables in C corresponding to existing
>> > + * linker symbols.
>> 
>> You validly say "declare" here, so why ...
>> 
>> > + * Two static inline functions are declared to do comparisons and
>> > + * subtractions between these variables.
>> > + *
>> > + * The end variable is declared with a different type to make sure that
>> > + * the static inline functions cannot be misused.
>> > + */
>> > +#define DEFINE_SYMBOL(type, name, start_name, end_name)                   
>> >  
>    \
>> 
>> ... do you use DEFINE here?
>> 
>> How about DECLARE_ARRAY_BOUNDS(tag, name) using
>> tag ## _t as type, tag ## _lt etc as function names, and
>> name ## _start / name ## _end as start / end symbols. To
>> accommodate things like _etext, the above could in fact expand
>> to DECLARE_BOUNDS(tag, name ## _start, name ## _end)
>> allowing this second macro then to also be used like
>> DECLARE_BOUNDS(text, _stext, _etext).
> 
> I am fine with renaming the macro. It is also fine to provide a wrapper
> macro which automatically sets the most common variable names.
> 
> However, in your example both DECLARE_BOUNDS and DECLARE_ARRAY_BOUNDS
> end up assuming that the type is tag ## _t. Currently many of our
> variable types don't follow this naming pattern (struct alt_instr,
> struct device_desc, struct acpi_device_desc, just to name the first
> three I found). I don't think it is a good idea to introduce even more
> renaming as part of this series.

I didn't suggest renaming anything. Instead I've suggested to add
typedef-s as needed.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel