Messages in this thread | | | Date | Wed, 3 Jun 1998 00:02:11 +1000 (EST) | From | Nathan Hand <> | Subject | Re: [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
| |