> On Sun, 31 May 1998, Riccardo Facchetti wrote:
> > informations into the kernel ? We can do this way: make a structure and
> > link it into the kernel.
> There is one really important distinction here: the /proc/pci database
> needed to be updated regularly, the /proc/config[.gz] dosn't need to be.
Yes ... and there are mantainers of pci database and they could post
patches on a regular basis to Linus, but this option was discarded.
> > 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.
Why ? If you make sure to associate (in some secure way) the running
kernel with a file containing the infos, you can have no kernelspace
bloating.
> > 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.
Yes. I know. This is the bigger point against my idea. How to associate in
a secure way a running kernel with its image file, and in any kind of boot
setup. Having an answer to this question will resolve the bloating
problem.
> > 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?")
Another interesting question. I have a /proc driver and an user-space
utility too. Choose one ... they both work well :)
User-space is better: no kernel bloating at all, even no /proc driver.
Kernel-space is ... hmm ... was just a good exercise ... I feel kernel
space driver is less than interesting ... we can do all within user space.
> > - 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?
I am talking about System.map, not .config :)
Anyway okay okay ... the real problem is that the idea of cat data at the
end of kernel image apply to both.
> > - 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.)
Yes ... as I have alredy admitted, this is the main point against my idea.
> > - /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.
Yes. So if we find a solution for one or two other problems, we can do
whatever we want with zero kernel bloat (first of all how to gain access
to the kernel image when booting from network or raw devices :)
> > 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>
I'm Little People me too. Of course I care about any good thought. I only
don't care flames and long-living threads (like that one about 'C' and
operator precedences, with people launching pieces of shit in the face of
one to the other ... funny, but not for me :)
Ciao,
Riccardo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu