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: <56261C7C.9040601@ahsoftware.de>
Date:	Tue, 20 Oct 2015 12:50:36 +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:42 schrieb Alexander Holler:
> 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
> };

Maybe I should mention that these IDs don't have to be consistent across 
kernel version.

They are only used to identify drivers at runtime. Of course, it might 
make sense to keep them consistent, but that only would make it easier 
to speak about drivers/initcalls while mentioning only their ID (which 
imho isn't that good). For debugging purposes my patches are already 
automatically generating names out of this enum.

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/