> Don't you feel a bit uneasy with this ? After all, someone cut here just
> to see that some other one bloats there !
Hmm... I see a definate difference between adding a feature and moving a
feature. With /proc/pci -> /proc/bus/pci/, we moved somthing that could be
implemented partily into userspace into (partial) userspace. With
/proc/config[.gz], we can't get equivlent features without being in
kernelspace, because the whole point is that kernelspace knows the options.
> This is just a comment: I am conscious that we should have a way to
> associate the System.map and may be the .config with their image, but the
> answer must NOT be kernel bloat !
I really don't see an alternitive -- your proposal simply makes the config
options easyer to find, it dosn't properly associate them with the kernel.
Think about boot-floppies and network-booting a second. In general, if you
can't always find the boot options of the kernel that you are running
without any knowledge about the source of the kernel then the fact that you
are running it right now, then it isn't a real solution.
> The principle of this thing is really simple:
>
> 1) make zImage (make bzImage)
> 2) cat System.map >> zImage (bzImage)
> 3) boot the new image
OK, that's already quite possible now. (AFIAK)
> 4) cat /proc/ksyms_internal will open the zImage (bzImage) file, read the
> data at the end of image and show it.
How is this any better then making a userspace program to read the size byte
in the zImage, seek forward that far, then show the remainder of the file?
This fails the userspace test. ("Can you have equivlent functionality by
putting [more of] this in userspace?")
> - Data is NOT linked into the kernel (~ 130 Kb of data), so NO kernel
> bloat, except of course for the /proc code.
# cd /usr/src/linux
# cat .config | grep -v ^# | grep -v ^$ | cut -f2- -d_ | gzip -c | wc -c
679 on my system. I'm guessing that that's about average. If you want the
non-gziped size, it's 1749 on my system. Where are you getting 130 KB?
> - Data is associated with the kernel at link time so there is no way to
> make mistakes: the System.map is associated with its kernel image
But only if you have the kernel image that you booted from around. What
about network-boots or floppy-boots or when you don't know where/if you will
mount the filesystem that has it on there (if there is indeed a filesystem
and not a raw device.)
> - /proc support to read the symbols from the kernel image and show them
> catting /proc/ksyms_internal
Why? You could do that in userspace (parse /proc/cmdline if you insist on
having the kernel image location as a boot-paramater). Zero kernel bloat
that way.
> - I don't know how to handle network boot, I don't boot this way so I have
> no way to know how to make it right
Not possible without some _very_ nice support from the network-drivers, I'm
guessing.
> Alan, Martin, David, Linus, Bill, all others ... is this just another
> piece of ... err ... ehm ... shit ?
I'm no ueber-hacker, but I hope that you care about the thoughts of us
Little People too. <G>
-=- James Mastros
-- True mastery is knowing enough to bullshit the rest. -=- Me http://www.rtweb.net/theorb coming soon (or when I get around to it).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu