Re: [Xen-devel] [RFC v3 2/4] xen/linux_compat: Add a Linux compat header

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 15/12/2017 22:32, Goel, Sameer wrote:
> On 12/5/2017 5:31 AM, Julien Grall wrote:
> > Hi Sameer,
> >
> > On 05/12/17 03:59, Sameer Goel wrote:
> > > For porting files from Linux it is useful to have a Linux API to Xen API
> > > mapping header at a common location.
> > > This file adds common API functions and other defines that are needed for
> > > porting arm SMMU drivers.
> > >
> > > ---
> > >    xen/include/xen/linux_compat.h | 106 
> > > +++++++++++++++++++++++++++++++++++++++++
> > >    1 file changed, 106 insertions(+)
> > >    create mode 100644 xen/include/xen/linux_compat.h
> > >
> > > diff --git a/xen/include/xen/linux_compat.h b/xen/include/xen/linux_compat.h
> > > new file mode 100644
> > > index 0000000..217e0cc
> > > --- /dev/null
> > > +++ b/xen/include/xen/linux_compat.h
> > > @@ -0,0 +1,106 @@
> > > +/******************************************************************************
> > > + * include/xen/linux_compat.h
> > > + *
> > > + * Compatibility defines for porting code from Linux to Xen
> > > + *
> > > + * Copyright (c) 2017 Linaro Limited
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License, or
> > > + * (at your option) any later version.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > + * GNU General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU General Public License
> > > + * along with this program; If not, see <http://www.gnu.org/licenses/>.
> > > + */
> > > +
> > > +#ifndef __XEN_LINUX_COMPAT_H__
> > > +#define __XEN_LINUX_COMPAT_H__
> > > +
> > > +#include <asm/types.h>
> > > +
> > > +typedef paddr_t phys_addr_t;
> > > +typedef paddr_t dma_addr_t;
> > > +
> > > +/* Alias to Xen device tree helpers */
> > > +#define device_node dt_device_node
> > > +#define of_phandle_args dt_phandle_args
> > > +#define of_device_id dt_device_match
> > > +#define of_match_node dt_match_node
> > > +#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
> > > out))
> > > +#define of_property_read_bool dt_property_read_bool
> > > +#define of_parse_phandle_with_args dt_parse_phandle_with_args
> > > +/* The user should consider if it is safe to treat mutex as a spinlock */
> > I am against defining mutex as spinlock in a generic header. People will 
> > overlook it and it is hardly going to be detected in a verbatim port.
> >
> > This should be done on the case by case basis.
> >
> > > +#define mutex spinlock_t
> > > +#define mutex_init spin_lock_init
> > > +#define mutex_lock spin_lock
> > > +#define mutex_unlock spin_unlock
> > > +
> > > +#define ilog2 LOG_2
> > There is only one user of LOG_2 in Xen. So wouldn't it be better to rename 
> > directly to ilog2?
> Its used in a couple of places (x86_64/asm-offsets.c). I can change that file 
> too, let me know what you think. I am keeping this for now.
There are exactly one place in x86_64/asm-offsets.c. So please rename it 
rather than adding yet another alias.
Cheers,

--
Julien Grall

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