linux-kernel - RE: [PATCH 00/56] staging: comedi: introduce comedi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Mar 2015 18:26:46 +0000
From:	Hartley Sweeten <HartleyS@...ionengravers.com>
To:	Joe Perches <joe@...ches.com>, Ian Abbott <abbotti@....co.uk>
CC:	"driverdev-devel@...uxdriverproject.org" 
	<driverdev-devel@...uxdriverproject.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 00/56] staging: comedi: introduce comedi_pci.h header

On Tuesday, March 10, 2015 9:25 AM, Joe Perches wrote:
> On Tue, 2015-03-10 at 16:10 +0000, Ian Abbott wrote:
>> "comedidev.h" includes PCI-specific stuff that gets included by all
>> comedi drivers including non-PCI ones.  Separate it out into its own
>> header "comedi_pci.h".  Make the new header include <linux/pci.h> and
>> "comedidev.h" so that comedi PCI drivers do not need to include them
>> explicitly.
>
> Isn't the kernel progressing to avoid indirect includes?

It appears so, and in general I agree. But, I also agree with what Ian has
done here.

> Perhaps it'd be nicer to move generic comedi .h files into
> a more common location and change the include path so that
> the include statements don't have to be relative?
>
> Maybe add an include/comedi/ directory?

Ian already submitted similar patches for the comedi USB and PCMCIA
drivers. Those patches have been applied.

The comedi PCI/PCMCIA/USB (i.e. "bus") drivers now just need to include
the "bus"  specific comedi driver header to get the bus specific interface
functions. These functions include the:

module_comedi_"bus"_driver		
	helper macro for the module_init/module_exit boilerplate
comedi_"bus"_driver_register()	
comedi_"bus"_driver_unregister()	
	helper functions to register and unregister the "bus" and comedi drivers
comedi_"bus"_auto_config()
comedi_"bus"_auto_unconfig()
	helper functions for the "bus" driver to probe/remove the comedi driver
comedi_"bus"_enable()
comedi_"bus"_disable()
	helper functions to request and enable/disable and release the I/O
comedi_to_"bus"_dev()
	helper function to get the "bus" device from the comedi device

These comedi_"bus" headers keep the drivers clean and easy to maintain.
The drivers are still responsible for including any headers that are not specifically
needed for the "bus".

When comedi gets moved out of staging we will need to decide where the
headers go. The only one I know for sure is comedi.h. That one is the UAPI
header (include/uapi/comedi.h). The rest in drivers/staging/comedi will need
to either go into include/linux/*.h or include/linux/comedi/*.h.

There are still a couple headers in the comedi/drivers directory. Those do not
need to be exposed so I think the relative include is fine.

Just my two cents....

Regards,
Hartley

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/