lkml.org 
[lkml]   [1998]   [Jun]   [2]   [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 Wed, 3 Jun 1998, Nathan Hand wrote:

[...]
> > Of course, I may be wrong, but this way seems to me better than linking
> > the data in some kernel-memory data structure.
>
> I think your vmlinuz+System.map patch is neat, and manages to
> avoid the typical complaints (bloating the kernel image for a
> useless feature or better suited for userspace).

Yes. This is my first issue writing that patch: avoid the typical
complaints, and I think I have reached the objective :)

> Though I personally would prefer to lose /proc/ksyms_internal
> and go for a /proc/sys/kernel/location. Cat'ing this variable
> would provide a fully qualified path for the kernel image (as
> it was last known during the boot sequence).

Yes. This was a thing I have tought about me too. I think an administrator
is not going to move around the kernel image so fequently, and when it do
it, he/she must only remember to edit the lilo.conf and/or edit a boot
rcfile to cat "kpath" > /proc/sys/kernel/boot_image_path and then change
on the fly the kpath into the kernel: no reboot needed.

> Then all the information about ksyms can be retrieved in user
> space, either from a library or a utility program. This makes
> even less kernel bloat, and allows the feature to be extended
> willy-nilly by changing the userspace binaries.

Yes. For now I prefer mantain the two ways: kernelspace and userspace
reading routines. I feel that someone may be preferring one over the other
and I don't want to make a choice just right now (and remember that for
now the patch is supporting only i386 architecture).

Another thing I want to do is to extend the data saved in a extensible way
(hoho): an header may be a bit-field of presence just like this:

struct data_head {
unsigned int system_map : 1;
unsigned int config : 1;
unsigned int modules : 1;
unsigned int reserver : 29;
unsigned int system_map_size;
unsigned int config_size;
unsigned int modules_size;
};

then data will be saved in that order: sysmap, config, modules and for
every object, the size of the object is recorded into the header and you
have just to read every data chunk from the image.
Then all the data (if available) will be read with the same userspace
program, or different /proc entries.

> The only issue is that the kernel image might move, after the
> kernel has booted, and this invalidates the variable.

See above.

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:0.087 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site