On Thu, Jul 24, 2008 at 10:42:11AM +1000, David Gibson wrote:
> On Wed, Jul 23, 2008 at 04:33:40PM +0100, Andy Whitcroft wrote:
> > Add control over remap via the --text, --data, --bss, and --disable
> > options.  The first three request mapping of those segments, the last
> > disables all remap.  Where the combinations requested cannot be exactly
> > handled then the request is "widened" to get that segment remapped,
> > for example if you request --data or --bss in isolation then both are
> > remapped and a warning emitted.
> 
> Here's one idea I thought about when the new remapping technique was
> introduced.  We could add a secondary way of specifying what to remap
> in elflink.c where the segments to remapped are explicitly listed (by
> program header index, presumably).  hugectl could in theory use more
> information than just the segment permissions to deduce which segments
> are the data/bss/etc, then use this mode to specify this to the
> library.
> 
> I doubt it's actually all that useful in practice, but it's an option
> to bear in mind if we do find the read-only/read-write distinction
> insufficient.

It is funny you should say that right now as I was thinking about this
myself.  I think we can handle that in the same variable, and essentially
in the same format.  If we were to define the current format as something
like:

        "a comma separated list of segments to remap, where unambigious
        the comma is optional"

Then the current valid options of (left) are trivially detectable
degenerate forms of (right):

        R               R
        W               W
        RW              R,W

ie. if we see RW, assume R,W.  Then we can also later support per
segment mapping using their segment numbers:

        0,2,5

I also strongly agree that at this point we should consider it, and make
sure any change to this format does not preclude simple introduction of
segment number based mapping.

-apw

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel

Reply via email to