public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. J. Lu" <hjl@lucon.org>
To: linux-ia64@vger.kernel.org
Subject: Re: [Fwd: RE: elf header bits for page migration support......]
Date: Sun, 15 May 2005 19:45:28 +0000	[thread overview]
Message-ID: <20050515194528.GA17773@lucon.org> (raw)
In-Reply-To: <4287A223.6010804@sgi.com>

On Sun, May 15, 2005 at 12:25:23PM -0700, Jack Carter wrote:
> Ray Bryant wrote:
> 
> >2/2
> >
> >-------- Original Message --------
> >Subject: RE: elf header bits for page migration support......
> >Date: Fri, 13 May 2005 10:54:11 -0700
> >From: Luck, Tony <tony.luck@intel.com>
> >To: Ray Bryant <raybry@engr.sgi.com>
> >CC: <linux-ia64@vger.kernel.org>
> >
> >>The alternative being suggested is to mark the elf header of object 
> >>files
> >>that should only have shared pages migrated, or that should not be 
> >>migrated
> >>(e. g. you don't want to migrate /bin/csh all the time.)
> >
> >
> >No ... I'd like you to replicate shared pages (of /bin/bash ... I 
> >personally don't
> >care what happens to the pages of /bin/csh :-)
> >
> >>Can I use some bits (I need 2) of p_flags of Elf64_Phdr for this 
> >>purpose?
> >>If so, which bits?
> >>
> >>If not which other fields can I use?
> >
> >
> >I think H.J's suggestion of an extra section makes sense ... then you 
> >can go
> >wild with as many bits as you can dream up uses for, rather than 
> >constraining
> >yourself to squeeze into just 2 bits.
> >
> >-Tony
> >
> >
> The fun part of  this is that if you introduce a new section and
> a new segment to point to it (only segments exist at load time)
> then you need to really muck with the bits because you will be
> growing the program header (segment table) and the section header
> as well as putting in a new section.
> 
> If this information is to be used by rld it will need to be in some
> element of the bits that will be loadable and that means the new
> section needs to be either contiguous to a currently marked (PT_LOAD)
> segment with it's size increase due to the new section or the new section
> needs to be in it's own segment which means increasing the number
> of PT_LOAD segment entries.

I am not sure I understand what you are saying. As far as I know,
you don't need PT_LOAD for it. The dynamic linker will handle it in
program header just fine.


H.J.

  reply	other threads:[~2005-05-15 19:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-15 19:25 [Fwd: RE: elf header bits for page migration support......] Jack Carter
2005-05-15 19:45 ` H. J. Lu [this message]
2005-05-15 20:08 ` Jack Carter
2005-05-15 20:33 ` H. J. Lu
2005-05-16  4:29 ` Ray Bryant
2005-05-16  4:42 ` H. J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050515194528.GA17773@lucon.org \
    --to=hjl@lucon.org \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox