[PATCH 1/3] staging: comedi: don't rely on comedidev.h to include headers
abbotti at mev.co.uk
Thu Jun 27 13:31:11 UTC 2013
[Originally posted 2013-06-25. Reposting to new driverdev-devel list.]
On 2013-06-25 01:04, H Hartley Sweeten wrote:
> comedidev.h is the main kernel header for comedi. Every comedi
> driver includes this header which then includes a number of
> <linux/*> headers. All the drivers need <linux/module.h> and some
> of them need <linux/delay.h>. The rest are not needed by any of
> the drivers.
> Remove all the includes in comedidev.h except for <linux/dma-mapping.h>,
> which is needed to pick up the enum dma_data_direction for the
> comedi_subdevice definition, and "comedi.h", which is the uapi
> header for comedi.
> Add <linux/module.h> to all the comedi drivers and <linux/delay.h>
> to the couple that need it.
> Signed-off-by: H Hartley Sweeten <hsweeten at visionengravers.com>
> Cc: Ian Abbott <abbotti at mev.co.uk>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
The big test is whether it still compiles if you put #include
<comedidev.h> at the top of a .c file. I suspect it doesn't (e.g. the
use of spinlock_t would require #include <linux/spinlock.h>). Generally,
include files should include enough headers to compile themselves in
order to avoid relying on the order of inclusion.
As it happens, it does still compile, although I think that is because
it is relying on #include <linux/dma-mapping.h> pulling in a load of
Since comedidev.h includes objects of type spinlock_t, struct mutex, and
wait_queue_head_t, it ought to include the following headers:
We could probably rely on those headers to pull in the typedefs for
integer types such as size_t and u8, and we don't really care about
fully defining structs that are only used in pointer types.
It's still good for the comedi driver .c files not to rely on
comedidev.h including header files for them.
One of the headers pulled in by #include <linux/dma-mapping.h> is
<linux/device.h> which defines functions such dev_warn(), dev_err(),
dev_dbg() and dev_printk(). So drivers using those functions should
probably have a #include <linux/device.h> line. Similarly, drivers
still using printk() should probably have a #include <linux/printk.h> line.
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti at mev.co.uk> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
More information about the devel