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 Mon, 1 Jun 1998, Riccardo Facchetti wrote:

> > 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.

It looks like someone's begging for a multi-forked filesystem
ala HFS (Mac) or HPFS (OS/2).

That sure would make adminstration a lot simpler for CAP, but
forks (thankfully) aren't The Unix Way!

> 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).

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).

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.

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


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