linux-kernel - Re: [PATCH 10/14] init: deps: IDs for annotated initcalls

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: <56261A8E.1080808@ahsoftware.de>
Date:	Tue, 20 Oct 2015 12:42:22 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Mark Brown <broonie@...nel.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Russell King <linux@....linux.org.uk>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH 10/14] init: deps: IDs for annotated initcalls

Am 20.10.2015 um 12:30 schrieb Alexander Holler:
> Am 19.10.2015 um 15:12 schrieb Mark Brown:
>> On Sat, Oct 17, 2015 at 08:46:44PM +0200, Alexander Holler wrote:
>>> Am 17.10.2015 um 20:29 schrieb Greg Kroah-Hartman:
>>>> On Sat, Oct 17, 2015 at 07:55:17PM +0200, Alexander Holler wrote:
>>>>> Am 17.10.2015 um 19:45 schrieb Greg Kroah-Hartman:
>>
>>>>>> A file like this is going to be a nightmare to maintain and ensure
>>>>>> that
>>>>>> it actually is correct, I don't see it as a viable solution, sorry.
>>
>>>>> How often will drivers be added? The only changes on this file will
>>>>> happen
>>>>> if a driver will be added and then just one ID will be added.
>>
>>>> Look at how many drivers we add every kernel release, it's a
>>>> non-trivial
>>>> amount.
>>
>>> I still don't see your problem. As long as the IDs in the enum are
>>> ordered
>>> according to the directories, there won't be more merge conflicts
>>> than in
>>> the Makefile or Kconfig for that directory. And as mentioned, it's e.g.
>>> possible to split the one file into multiple ones, e.g.
>>>
>>> enum driver_ids {
>>>
>>> #include "foo"
>>> #include "bar"
>>>
>>> };
>>>
>>> Of cource, the content of foo and bar might look a bit unusual.
>>
>> If it's a purely mechanical thing we really ought to be able to arrange
>> for it to be generated during the build rather than have to have more
>> typing.  If the values matter then people have to think about what they
>> are which is more effort and rather indirect.
>>
>>> It's just that I didn't thought much about another solution, and the
>>> time
>>> I've spend to think about something else which provides a usable ID,
>>> didn't
>>> end in a solution. So I would be happy if someone else would offer an
>>> idea.
>>
>> A checksum of the driver name?
>
> That requires the driver name, which is only available if the struct
> device_driver is available (which isn't always the case). And it would
> require time to build the checksums.
>
> Another idea to split this one file into multiple ones would be to
> reserve blocks of IDs. E.g. use 10000-20000 for networking stuff,
> 1000-1200 for I2C and so on.

In detail it could look like

driver_ids_base.h:

enum {
	drvid_i2c_base = 1000,
	drvid_networking_base = 1200,
	drvid_usb_base = 3000,
};

driver_ids_i2c.h:

# include "driver_ids_base.h"

enum {
	drvid_i2c_start = drvid_i2c_base,

	/* drivers/i2c */
	drvid_i2c,
	drvid_i2c_dev,
	drvid_i2c_busses_start,
	/* drivers/i2c/busses */
	drvid_i2c_gpio,
	(...)

	drvid_i2c_end
};

> Regards,
>
> Alexander Holler

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