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

[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
};

> Regards,
>
> Alexander Holler

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/