RFC: PCI SR-IOV Driver interface

[Bruce Evans]

On Tue, 6 May 2014, Ryan Stone wrote:

> ...
> PF drivers implement the following method to advertise their
> configuration schema:
>
> METHOD void get_iov_config_schema {
>        device_t        dev;
>        nvlist_t        *pf_schema;
>        nvlist_t        *vf_schema;
> }
>
> The use of the nvlist_t in the interface is somewhat unfortunate.  The
> problem is that now every driver that includes "pci_if.h" needs to
> have the typedef nvlist_t defined (and I *really* don't want to modify
> every PCI driver in the tree...).  I have a somewhat hacky workaround
> for the problem in my tree right now but I thought that I would
> highlight the issue in case people had opinions on the issue.

Hrmph.  style(9) explicitly forbids typedefs like nvlist_t.  It is just
a pointer to a struct.  But since it is just that, it is easy to
declare it in several headers.  The struct type is not needed.

The user nv.h begins with massive namespace pollution:

% #include <sys/cdefs.h>
% 
% #include <stdarg.h>
% #include <stdbool.h>
% #include <stdint.h>
% #include <stdio.h>

Why bother hiding the struct type when you expose all this?  The API
does use FILE.  FILE exposes its struct too.

The string 'FILE *'now occurs in 24 headers in /usr/include/*.h and
in 31 headers in /usr/include/*/*.h :-(.  stdio.h is referenced in about
half of these.

Such mistakes shouldn't be repeated in new APIs.

% 
% #ifndef	_NVLIST_T_DECLARED
% #define	_NVLIST_T_DECLARED
% struct nvlist;

Bogus forward declaration (not needed).

% 
% typedef struct nvlist nvlist_t;
% #endif

The polluting symbols are of course undocumented in nv's man page (except
indirectly, by having a prototype that uses FILE, and many that use va_list
bool or uint64_t).

Bruce