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