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: <20151019131254.GG14956@sirena.org.uk>
Date:	Mon, 19 Oct 2015 14:12:54 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Alexander Holler <holler@...oftware.de>
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

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?

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ