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

[Alexander Holler <holler@ahsoftware.de>]

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