lkml.org 
[lkml]   [2004]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: sched_setaffinity usability

* Helge Hafting <helgehaf@aitel.hist.no> wrote:

> Let the compile create that info file. Then handle it much like a
> module, except that it is a "module" without any code. I.e. copy it
> to /lib/modules/<kernelversion> if installing modules, or stuff the
> file into the initrd if making an initrd.
>
> Now it is in a place specific to the kernel, where a library can find
> it.

this has a couple of disadvantages:

- the kernel can pre-map the 'file' cheaper - in fact on x86 it's
zero-cost currently. Mapping a file takes 3 syscalls and at least one
pagefault. Since glibc needs a good portion of this info for
absolutely every ELF binary, why not provide it in a preconstructed
way? x86 is doing it via the VDSO. ia64 and x86-64 is doing it via a
dso-alike mechanism.

- obtaining the kernel version currently needs one more syscall
[uname()].

- the 'metadata' becomes detached from the kernel image, so it
cannot contain 'crutial' data. Testing kernels becomes harder, etc.
(until now i could just send a bzImage to someone to get it tested -
now it would have to include the metadata too.)

- it excludes non-build-time data.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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