To see how big .config might be in the kernel, I stripped blanks, # prefixed
lines, and CONFIG_, and it came to 739 bytes, or 397 gzipped.
Or, for a more compact format:
[a-z][!-Z]OPTION_IN_CAPS
Where the first two chars are a tag (1500 possible options, maybe a third
char would be wise, the char set is chosen, so it might
even be possible to convey it to another human in native form. Then, after
the tag, the option in upper-cased text and numbers.
This could be parsed with either a special tool, or, perhaps more
appropriately, a module (If it's for the same kernel version, the config
options would likely be the same, so the numbers would be right)
I don't know what the number of non-conflicting config options would be,
but it's not going to be over 1024, or 4K total data, and with that number,
the kernel would bloat so much, that the increase would not be very
noticable.
The more I think of this, the more it would be handy, for very little
overhead.
I wonder if this format might even be appropriate, in even terser form
(only module settings of modules are listed, not their presence)
in /proc/version
It's already over 80 chars, would 100 more really be a problem?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
lines, and CONFIG_, and it came to 739 bytes, or 397 gzipped.
Or, for a more compact format:
[a-z][!-Z]OPTION_IN_CAPS
Where the first two chars are a tag (1500 possible options, maybe a third
char would be wise, the char set is chosen, so it might
even be possible to convey it to another human in native form. Then, after
the tag, the option in upper-cased text and numbers.
This could be parsed with either a special tool, or, perhaps more
appropriately, a module (If it's for the same kernel version, the config
options would likely be the same, so the numbers would be right)
I don't know what the number of non-conflicting config options would be,
but it's not going to be over 1024, or 4K total data, and with that number,
the kernel would bloat so much, that the increase would not be very
noticable.
The more I think of this, the more it would be handy, for very little
overhead.
I wonder if this format might even be appropriate, in even terser form
(only module settings of modules are listed, not their presence)
in /proc/version
It's already over 80 chars, would 100 more really be a problem?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/