[lkml]   [2008]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/2] elf loader support for auxvec base platform string
    > That will make it part of the kernel ABI, since the mapping depends on
    > the running kernel, doesn't it?

    Well, not the permanent ABI in the sense that AT_* et al are. This
    mapping must agree among all users sharing the same file.
    That is all. So if you were to change the meaning of a bit that was
    used before with a different string, then you could not have the
    conflicting files both installed at the same time
    (ldconfig will complain and fail). If you wanted to have two kernels
    both installed that disagree on the string for a given bit, then you'd
    have to switch the files and re-run ldconfig when you
    switch which kernel you're booting.

    There are 32 bits free now. One can anticipate that reassigning a bit
    would come up only after these are exhausted. With prudent use, this
    will take a very long time to happen. Then the oldest CPU type string
    might be retired to reuse its bit. It seems unlikely that there will
    be a single installation (root directory) that really needs to have
    installed both a kernel optimized for the oldest CPU model known and a
    kernel optimized for the newest CPU model known. If there is, we can
    worry about it then.

    At any rate, the point remains that these bit assignments are not part
    of any published userland ABI one has to think about in all the ways
    that the real ABI implies. There is nowhere that has to know them or
    will ever consider them, except the kernel with the vDSO image built
    inside and the file that goes with it.


     \ /
      Last update: 2008-07-07 11:35    [W:0.022 / U:0.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site