[dpdk-dev] [RFC v2] bus/auxiliary: introduce auxiliary bus

Wang, Haiyue haiyue.wang at intel.com
Thu Jun 10 17:16:43 CEST 2021


> -----Original Message-----
> From: Xueming(Steven) Li <xuemingl at nvidia.com>
> Sent: Thursday, June 10, 2021 14:30
> To: Wang, Haiyue <haiyue.wang at intel.com>; NBU-Contact-Thomas Monjalon <thomas at monjalon.net>
> Cc: dev at dpdk.org; Parav Pandit <parav at nvidia.com>; Ray Kinsella <mdr at ashroe.eu>;
> andrew.rybchenko at oktetlabs.ru
> Subject: RE: [dpdk-dev] [RFC v2] bus/auxiliary: introduce auxiliary bus
> 
> 
> 
> > -----Original Message-----
> > From: Wang, Haiyue <haiyue.wang at intel.com>
> > Sent: Tuesday, June 8, 2021 4:41 PM
> > To: NBU-Contact-Thomas Monjalon <thomas at monjalon.net>; Xueming(Steven) Li <xuemingl at nvidia.com>
> > Cc: dev at dpdk.org; Parav Pandit <parav at nvidia.com>; Ray Kinsella <mdr at ashroe.eu>;
> andrew.rybchenko at oktetlabs.ru
> > Subject: RE: [dpdk-dev] [RFC v2] bus/auxiliary: introduce auxiliary bus
> >
> > Hi Andrew,
> >
> > > -----Original Message-----
> > > From: Thomas Monjalon <thomas at monjalon.net>
> > > Sent: Tuesday, June 8, 2021 15:53
> > > To: Xueming Li <xuemingl at nvidia.com>
> > > Cc: dev at dpdk.org; Parav Pandit <parav at nvidia.com>; Ray Kinsella
> > > <mdr at ashroe.eu>; Wang, Haiyue <haiyue.wang at intel.com>;
> > > andrew.rybchenko at oktetlabs.ru
> > > Subject: Re: [dpdk-dev] [RFC v2] bus/auxiliary: introduce auxiliary
> > > bus
> > >
> >
> >
> > > > +
> > > > +/**
> > > > + * Match function for the driver to decide if device can be handled.
> > > > + *
> > > > + * @param name
> > > > + *   Pointer to the auxiliary device name.
> > > > + * @return
> > > > + *   Whether the driver can handle the auxiliary device.
> > > > + */
> > > > +typedef bool(*rte_auxiliary_match_t) (const char *name);
> > >
> > > I disagree with the earlier comment asking for typedef pointer (based
> > > on one of my patches).
> > > Actually Andrew's suggestion makes sense:
> > > 	http://mails.dpdk.org/archives/dev/2021-June/210665.html
> > >
> >
> > I didn't get the error, but the same warning, I missed something ? ;-)
> >
> > 1. w/o pointer
> >
> > #include <stdio.h>
> >
> > typedef int (gpu_malloc_t)(void *dev, size_t size, void **ptr);
> >
> > static gpu_malloc_t *mlx5_gpu_malloc_fn;
> >
> > static int
> > mlx5_gpu_malloc(size_t size, void **ptr) {
> > 	return 0;
> > }
> >
> > int main()
> > {
> > 	mlx5_gpu_malloc_fn = mlx5_gpu_malloc;
> >
> > 	mlx5_gpu_malloc_fn(NULL, 0, NULL);
> >
> > 	return 0;
> > }
> >
> >
> > gcc -Wall fun.c
> > fun.c: In function 'main':
> > fun.c:15:21: warning: assignment to 'int (*)(void *, size_t,  void **)' {aka 'int (*)(void *, long
> unsigned int,  void **)'} from incompatible
> > pointer type 'int (*)(size_t,  void **)' {aka 'int (*)(long unsigned int,  void **)'} [-
> Wincompatible-pointer-types]
> >    15 |  mlx5_gpu_malloc_fn = mlx5_gpu_malloc;
> >       |                     ^
> >
> >
> >
> > 2. w pointer
> >
> > #include <stdio.h>
> >
> > typedef int (*gpu_malloc_t)(void *dev, size_t size, void **ptr);
> >
> > static gpu_malloc_t mlx5_gpu_malloc_fn;
> >
> > static int
> > mlx5_gpu_malloc(size_t size, void **ptr) {
> > 	return 0;
> > }
> >
> > int main()
> > {
> > 	mlx5_gpu_malloc_fn = mlx5_gpu_malloc;
> >
> > 	mlx5_gpu_malloc_fn(NULL, 0, NULL);
> >
> > 	return 0;
> > }
> >
> > gcc -Wall fun.c
> > fun.c: In function 'main':
> > fun.c:15:21: warning: assignment to 'gpu_malloc_t' {aka 'int (*)(void *, long unsigned int,  void
> **)'} from incompatible pointer type
> > 'int (*)(size_t,  void **)' {aka 'int (*)(long unsigned int,  void **)'} [-Wincompatible-pointer-
> types]
> >    15 |  mlx5_gpu_malloc_fn = mlx5_gpu_malloc;
> >       |                     ^
> >
> > >
> 
> I don't mind as both suggestion works.

I just want to understand what kind of error the compiler will complain about. ;-)

> From usage perspective, it's straightforward for anybody to see an pointer field and know "that's a
> pointer to a something".

> 



More information about the dev mailing list