| Age | Commit message (Collapse) | Author |
|---|
|
Regenerated the parser after "genksyms: Track changes to enum
constants".
Signed-off-by: Michal Marek <mmarek@suse.cz>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
|
|
FreeBSD does not like <malloc.h> when __STDC__ is defined, use the standard
<stdlib.h> instead.
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
|
|
We are having two kinds of problems with genksyms today: fake checksum
changes without actual ABI changes, and changes which we would rather like
to ignore (such as an additional field at the end of a structure that
modules are not supposed to touch, for example).
I have thought about ways to improve genksyms and compute checksums
differently to avoid those problems, but in the end I don't see a
fundamentally better way. So here are some genksyms patches for at least
making the checksums more easily manageable, if we cannot fully fix them.
In addition to the bugfixes (the first two patches), this allows genksyms
to track checksum changes and report why a checksum changed (third patch),
and to selectively ignore changes (fourth patch).
This patch:
Gcc __attribute__ definitions may occur repeatedly, e.g.,
static int foo __attribute__((__used__))
__attribute__((aligned (16)));
The genksyms parser does not understand this, and generates a syntax error.
Fix this case.
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
This patch updates the _shipped files for genksyms.
See previous patch for actual functional changes.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
Generate _shipped files so the genksyms change in previous commit is enabled.
The files are generated with latest versions of the tools:
bison (GNU Bison) 2.0
flex version 2.5.4
GNU gperf 3.0.1
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
