"A month of sundays ago Bernd Strieder wrote:"
> after having read the announcement in comp.os.linux.announce and the
> homepage about this /proc/config stuff, I have some comments:
Hi.
>
> - I would advise against any solution with possible collisions, this
> cannot be afforded. This /proc/config stuff is needed to get clear
> evidence without any questions left. If the collision depends on the
> name of some CONFIG option to be included, then it is somehow cumbersome
> if you have to find another name for it, if it collides.
Interesting comment. Well, of course all the CONFIG options have
distinct names. That's a given.
The question is whether they have distinct keys. That's also true, as of
now.
The next question that arises is whether they will have distinct keys in
the future. The answer to that is "probably". You can predict that by
the time we have 2^32+1 config options (and we presently have somewhere
beween 600 and 1500), by the pigeonhole principle two of the 32 bit
keys will collide.
I don't know what names will be invented, but if you regard each
new name as a random experiment, and you invent 1000 new names, then
the chance of a collision is 1-(1-1/2^32)(1-2/2^32)...(1-1000/2^32)
or approximately 1000^2/2 / 2^32. Or 2^19 / 2^32 = 1/2^13 = 1/8000.
I.e. you would have to completely rename all the config options
8000 times before you could reasonably expect to come up with a
conflicting pair. That's not merely ridiculous, it's impossible. We do
not expect 8000 issues of the kernel, let alone issues of the kernel
with all new option names in!
If you are adding a single new option to a kernel with 1000 options
already named, then your chances of a conflict are something like
1000/ 2^32 = 1 / 2^22 = 1 / 4,000,000. So we would expect 4,000,000
new options (approx, and I realize this calc. should be
modified ..) to be added before even a single collision is detected.
I feel safe. And if someone does cause a conflict, I will ask them
politely to rename.
> - If you use those checksums/hash values to identify the CONFIG
> parameters, then you need at runtime somehow the real names of the
> parameters, what is your config_data.o module.
>
> There are the basic choices, that you can get this information purely
True.
> from the kernel, with the help of modules, or by the help of userland
> utilities. Another point is, if you can get this info only from a
> running kernel, or if you can retreive it from just a kernel image
> floating around.
>
> If you compress this data somehow, then you have to provide the
> decompression within the kernel, or you have to rely on userland
> utilities. In some circumstances it might be good to get the information
> without any special userland utilities. If you also want it from a
> kernel image, not running, then the .config File should be included just
> plain text. This seems to be less than 5% of the kernel anyway, so no
> major problem by itself. An optimisation would be, to include a gzipped
> image of .config. In both cases the /proc/config file could include just
> the plain text or the gzipped version of .config. If somebody views
> /proc/config and finds just garbage, then it should be a convention that
> the data is gzipped in this case.
I liked the solution with gzipped data myself. It seemed to be simple
and elegant. But it was not liked by the kernel deities, as I recall,
because it would not guarantee to stay below 4KB. We have now solved
that problem. I routinely produce ~12KB of output in /proc, but the
dislike lingers. There are other reasons too ...
> All other solutions with these extra modules config_data.o need more
> code and perhaps more space, without guarantee that the true config data
> used to compile a certain kernel can be retreived. What I find sometimes
> a little bit difficult is facing some kernels of the same release where
> some configuration options have been changed, influencing the modules as
> well. If you switch between those kernels, then you have to keep track
Yes. Another problem is switching between, say 2.0.* and 2.2.*, where
the names of the modules and their options have changed. This is a
reason for having /proc/config* info too.
> of your modules. And this could be made more easy with this config
> information retreivable from just the particular kernel image, without
Unfortunately, when you are in a running machine, you do not
necessarily know which image was booted (the lilo options linger,
but there is no guarantee that lilo was used or that the image has
remained). Some of my machines have 200 days uptime (and I have one
machine which was at 2 years ..). The implications are obvious.
> special utilities or kernel modules depending on the kernel release.
> Perhaps it is possible to add some little option into rdev to retreive
> the kernel config data from a kernel image, if available. This would be
> good for those dealing with some kernels, to get out all necessary
> things, without having to boot a kernel. If you can read the data from
> the kernel image, then there should also be a way to read it from /proc
> if the kernel is running.
Reading it from the image doesn't waste space. OTOH you can't rely on
it. And if you don't like wasting space, well, I can allow one to
wipe /proc/config with a echo 1.
> I'm not a kernel hacker, but I hope I could gave you some idea, what I
> would like. And I hope I could give some arguments in favor of the
> technically easier solution, just including the .config file perhaps
> somehow compressed.
I liked that too.
> What could be the cons? This has to be asked to be fair.
There is a general dislike of including what is apparently a large and
meaningless string into the kernel space.
> - Security: It could become easier to find what could be included by
> modules. To use this information you have to be almost root on the
> particular system. Kernel images, and modules should be root-only stuff
> anyways. So this is not a major concern.
Root should be able to switch off /proc/config anytime. I'll include
that next.
> - Kernel size: Oh well, to have some index of a book is standard, if it
> contains just all key words we could be interested to know about, it is
> just the optimal thing. It is no error to sacrifice some percent of the
> overall opus to a usable index. This holds for kernels even better,
> because it could help you to avoid writing a new book (compiling a new
> kernel). Well, the time to compile a kernel has reduced to a few
> minutes. What about the situation that you have to choose a precompiled
> kernel, without a chance to compile your own. And we have bzImage these
> days.
I agree mostly, but it is running size that that is important to many
people.
> - You could ask: Why don't you just copy your .config along with your
> kernel image as you do with System.map anyway? Then I will ask: Why has
> System.map not been included the same way I proposed to do with .config?
You can recreate System.map (mostly) from /proc/ksyms. Statics
are the problem.
> This is a major annoyance. If you play with some kernels, some releases,
> some patches, you have to backup over and over those files floating
> around, and before every try you have to look closely what to do about
> them. Which one to rename, to not have to edit init scripts.
It would be useful to have the full map available, I agree.
> Conclusion: There is a chance to make it significantly easier for beta
> testers of kernels by just creating an infrastructure to include data
> directly associated into the kernel like System.map or .config, making
> them accessible via /proc and/or utilities applied to the kernel image.
This is why I created a structure, rather than a string.
> BTW If you know somebody who might be interested about this, feel free
> to forward.
>
> Bernd Strieder
I'll forward to the kernel list, for discussion at least.
Peter
-
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/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:10 EST