lkml.org 
[lkml]   [1998]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [IDEA] Developers: your opinion badly needed ! (Was: [PATCH] /proc/config.gz)
On Sun, 31 May 1998, James Mastros wrote:

[...]
> > 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 patch is missing the "secure way" part (as you noted in the snipped
> part below <G>). At the moment, it isn't really any better then just saying
> "keep kernels in /boot/kernel/foo and System.maps in /boot/System.map-foo,
> where foo=foo". That's the system I use, and it very rarely fails for me
> (on occasion I forget to copy the System.map -- I could just create a
> makefile target for it, and have essentially your solution, except leaving
> out the fooling around with object files.)

This is the problem. You forget to copy System.map (I forget me too,
really often!!) and then, when you are facing an oops you just say ... ohh
how silly I am, now I have no infos about what's going wrong :(
A makefile target is not so useful since you have to edit it by hand if
you want to install the image and related files in "your" preferred
location. I use /boot for all files, but someone use / and /etc for
System.map, and who knows how many variations on this theme exist :)
The "secure way" ... we should think hard about it because I feel that if
we resolve this problem, we can save whatever we want into the kernel
file.

[...]
> > 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.
>
> If we can do all within user space, we generaly should. (I realize you
> meant "we can all do it within user space", but it works both ways.)

Yep :)
See the patch I have posted this evening (actually, right now :). It
contains the /proc/ksyms_internal routines and a program in
scripts/readksyms.c that do the same thing :)

[...]
> > I am talking about System.map, not .config :)
> Whops. Anyway, that's 43 KB for the largest System.map I have on file,
> after gziping.

Yes, but keep in mind that any concatenated data (to the kernel image) is
not loaded in memory, so we can cat the data without compressing. gzip is
not a concern for me :)

> > Anyway okay okay ... the real problem is that the idea of cat data at the
> > end of kernel image apply to both.
> Yeha, it's an interesting idea. I generaly prefer filesystems though --
> that is kind of why they were invented. A place for everything and
> everything in it's place. And the place for the system.map is, IMHO, not
> tacked after the end of the zImage.

Yes of course, but my point is having in a single file (on the filesystem
that were invented for placing files :) the boot image with all the
relevant data that belongs to that particular boot image. The only secure
way to mantain all synced and without doubt coherent, is to cat the data
at the end of the zImage.
Of course, I may be wrong, but this way seems to me better than linking
the data in some kernel-memory data structure.

Ciao,
Riccardo.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:2.118 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site