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, 29 Jan 2013 17:56:46 -0600
From:	H Hartley Sweeten <hartleys@...ionengravers.com>
To:	Peter Hüwe <PeterHuewe@....de>,
	Ian Abbott <abbotti@....co.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	ian Abbott <ian.abbott@....co.uk>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>
Subject: RE: [Q]staging/comedi: Considation of *_find_boardinfo possible?

On Tuesday, January 29, 2013 4:42 PM, Peter Hüwe wrote:
> Hi,
>
> while analyzing the comedi drivers, I noticed that quite a lot of them use a 
> more or less similar find_boardinfo function.

<snip>

> The names and the exact implementation differ slightly, but in most cases it 
> boils down to:
>	unsigned int i;
>
>	for (i = 0; i < ARRAY_SIZE(__BOARD_ARRAY__); i++)
>		if (pcidev->device == __BOARD_ARRAY__[i].device_id)
>			return &__BOARD_ARRAY__[i];
>	return NULL;
>
> unfortunately the __BOARD_ARRAY__ is always of a different type (but all 
> contain the device_id field) and size.
>
>
> ---> is there a way to consolidate these functions into one function (which 
> can operate on the different types) ?  It's almost a bit like 'templates'.
> Maybe with some gcc extensions or kernel magic functions ?
>
> I already thought about passing a void pointer to the __BOARD_ARRAY__ and the 
> size of one element of the __BOARD_ARRAY__ and doing pointer calculations - 
> but I guess there must be a better way.
>
> Or is the only option to write a macro ?

As you noticed, the problem is the driver specific definition of the struct used
to hold the boardinfo.

In drivers.c, the comedi_recognize() function actually access the boardinfo
in order to support the COMEDI_DEVCONFIG ioctl. There is a comment above
it giving a description of how it works.

There might be a way to do this in a generic way. The problem is that the
drivers use different names for "common" information and the data is
packed in the structs differently so accessing it generically is a bit difficult,
if not impossible.

I have been trying to remove as much of this boardinfo stuff from the drivers
as possible. For now I think the current implementation is fairly clean.

For the PnP bus drivers that use the auto_attach mechanism I have some ideas
to get rid of the find_boardinfo functions but I need to work out the kinks first.

Please wait on "fixing" any of this until a good solution is worked out.

Thanks,
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ