Re: [Xen-devel] [PATCH v2] public/io/netif.h: make control ring hash protocol more general

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.02.16 at 12:14, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 16 February 2016 11:11
>> To: Paul Durrant
>> Cc: Ian Campbell; Ian Jackson; xen-devel@xxxxxxxxxxxxxxxxxxxx; Keir
>> (Xen.org); Tim (Xen.org)
>> Subject: RE: [PATCH v2] public/io/netif.h: make control ring hash protocol
>> more general
>> 
>> >>> On 16.02.16 at 12:02, <Paul.Durrant@xxxxxxxxxx> wrote:
>> >> From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
>> >> Sent: 16 February 2016 10:23
>> >> On Mon, 2016-02-15 at 11:14 +0000, Paul Durrant wrote:
>> >> > + */
>> >> > +#ifdef NETIF_DEFINE_TOEPLITZ
>> >>
>> >> If we go with this then this should have an addtional XEN_ on the
>> >> front.
>> >
>> > The header is inconsistent at the moment. Some things are prefixed with
>> XEN_
>> > some are not so if you want this prefixed then I think it's best I add
>> > another patch before this to change all unqualified netif/NETIF occurrences
>> > to xen_netif/XEN_NETIF... it will also mean less post-processing when I
>> > re-import the header into Linux.
>> 
>> You'd need to be rather careful here: Any such identifiers which
>> were there already in 4.6 (or any other release) would have to
>> remain unchanged.
> 
> Is that true? The Linux header is quite different (in that everything is 
> already prefixed) and I was assuming any user of the header file would have 
> to have an explicit 'import into frontend/backend repo' step where 
> compatibility could be fixed up.

No, I don't think we can impose such a rule on our (possibly unknown)
downstreams. As an example, linux-2.6.18-xen.hg does verbatim
imports of the headers (whenever such is due).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel