On 09/18/2013 06:38 AM, David Howells wrote:
danielfsantos@xxxxxxx wrote:
This is a simple bash script that parses our errno*.h files and formats
them into the error_strings.h header that our strerror and strerror_name
functions will use later.
I presume you haven't tried building with a "make O=foo" build directory? I
see:
/bin/sh: /data/fs/linux-2.6-fscache/include/generated/error_strings.h: No such file or directory
when I try it.
No, indeed I haven't, thanks. I'm going to need help figuring out the
correct way to put this in the build because the current definitely
isn't correct. From what I could tell from digging into the build last
night (which I've never carefully analyzed), this should be added
somewhere in one of the scripts/Makefile*s and not in the root makefile
(as I have done), or maybe even in lib/Makefile.
(2) Storing the leading 'E' for each symbol is redundant as you can add that
later so you might want to discard it.
This is a good thought, that's 150-ish bytes, but it will introduce some
new challenges. Currently, strerror() functions exactly like "man 3p
strerror", except that it returns a pointer to a const string like the
POSIX specification should have done. :) So I directly return a pointer
to the string within the .rodata section of the object file (same for
strerror_name). Omitting the 'E' would require I work up another
solution requiring a return buffer or some such, thus increasing
complexity and possibly loosing that savings to code.
However, if we wanted to squeze that much more out of it, then we could
7-th bit terminate the strings and save another 150-ish bytes on null
terminators or go even further and use some encoding scheme (maybe 32
bits per character)? At 2k for both the error names and the code, I
figured it was already pretty low, but if there are some existing
libraries in the kernel we could use to do this and not further bloat
the text size for decompression then I wouldn't be opposed, so long as
it makes sense. And since we're dealing with error conditions which
don't happen often, speed shouldn't be a concern.
Thanks!
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
