linux-kernel - Re: [PATCH] staging/comedi: Move comedi_pci_auto

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]

Message-ID: <51026551.7010001@mev.co.uk>
Date:	Fri, 25 Jan 2013 10:58:25 +0000
From:	Ian Abbott <abbotti@....co.uk>
To:	Peter Huewe <PeterHuewe@....de>
CC:	Ian Abbott <ian.abbott@....co.uk>,
	Mori Hess <fmhess@...rs.sourceforge.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	H Hartley Sweeten <hsweeten@...ionengravers.com>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] staging/comedi: Move comedi_pci_auto_unconfig to drivers.c

On 2013/01/24 09:30 PM, Peter Huewe wrote:
> Am Donnerstag, 24. Januar 2013, 11:02:35 schrieb Ian Abbott:
>> On 2013-01-22 23:03, Peter Huewe wrote:
>>> Since comedi_pci_auto_unconfig cannot be inlined anymore after
>>>
>>>   staging/comedi: Use comedi_pci_auto_unconfig directly for
>>>   pci_driver.remove
>>>
>>> is applied, it makes sense to move it drivers.c
>>>
>>> Signed-off-by: Peter Huewe <peterhuewe@....de>
>>> ---
>>>
> 
>> Embarassingly (for me) I submitted a patch to do the exact opposite
>> previously, but I've no problem doing it this way if it saves some code.
> 
> Hi Ian,
> ;)

Hi.

> If you think it's cleaner the way it is currently we can leave it like that. 
> Especially if you think some driver might actually do something in the remove 
> function (in the future).

Well I was only using the inlined version to eliminate a function call
overhead, but your method eliminates a function call overhead in a
different way (for the majority of drivers whose remove function
consists solely of a call to comedi_pci_auto_unconfig()) and has the
benefit of removing lots of virtually identical function definitions.

If drivers want to do something else in the remove function, they still
have the option of doing that.

> However if we could also find a way to remove all the probe function stuff as 
> well we should remove it.
> Most (comedi pci) drivers simply call comedi_pci_auto_config and not much more 
> - but I'm currently not sure how to do this ;)

I can think of a couple of ways, but I don't like either of them.  The
difficulty is passing through the comedi driver's context (the struct
comedi_driver) to the comedi core during the probe.

One way would be to use a variant of the module_comedi_pci_driver()
macro that also creates a probe function that just calls
comedi_pci_auto_config(), and define another macro to retrieve the name
of that function (for initializing the .probe entry).  This only reduces
the number of source lines a little bit, not the amount of amount of
code generated, and is a little obfuscating.

Another way would be to point the driver_data of each struct
pci_device_id to the struct comedi_driver, and have a common probe
function that gets uses that information.  That might eliminate one
small probe function from lots of modules, but makes the PCI device
table in those modules a lot uglier.

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti@....co.uk>             )=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587              )=-
--
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/