From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752037AbbJTKmd (ORCPT ); Tue, 20 Oct 2015 06:42:33 -0400 Received: from h1446028.stratoserver.net ([85.214.92.142]:44717 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751803AbbJTKmb (ORCPT ); Tue, 20 Oct 2015 06:42:31 -0400 Subject: Re: [PATCH 10/14] init: deps: IDs for annotated initcalls To: Mark Brown References: <1445102067-11519-1-git-send-email-holler@ahsoftware.de> <1445102067-11519-11-git-send-email-holler@ahsoftware.de> <20151017174550.GD27013@kroah.com> <56228B85.9040309@ahsoftware.de> <20151017182911.GB28072@kroah.com> <56229794.3070402@ahsoftware.de> <20151019131254.GG14956@sirena.org.uk> <562617C5.2050706@ahsoftware.de> Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Linus Torvalds , Andrew Morton , Russell King , Grant Likely From: Alexander Holler Message-ID: <56261A8E.1080808@ahsoftware.de> Date: Tue, 20 Oct 2015 12:42:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <562617C5.2050706@ahsoftware.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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