From owner-freebsd-arch@FreeBSD.ORG Wed May 7 04:48:26 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E69114A0 for ; Wed, 7 May 2014 04:48:26 +0000 (UTC) Received: from mail108.syd.optusnet.com.au (mail108.syd.optusnet.com.au [211.29.132.59]) by mx1.freebsd.org (Postfix) with ESMTP id A5757F78 for ; Wed, 7 May 2014 04:48:26 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail108.syd.optusnet.com.au (Postfix) with ESMTPS id E60BE1A2333; Wed, 7 May 2014 14:48:17 +1000 (EST) Date: Wed, 7 May 2014 14:48:14 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ryan Stone Subject: Re: RFC: PCI SR-IOV Driver interface In-Reply-To: Message-ID: <20140507141652.K1349@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=U6SrU4bu c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=dNjAHJjcj_oA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=vBoLb_oq0QFVOIqYKz8A:9 a=CjuIK1q_8ugA:10 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 04:48:27 -0000 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 % % #include % #include % #include % #include 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