On Tue, 2008-07-08 at 10:48 +1000, Benjamin Herrenschmidt wrote:
> Adding Steve to the CC list as I'd like his input from the
> glibc/powerpc side as he's the requester of that feature in the first
> place.
>
> Steve: Roland is proposing to ues dsocaps instead of AT_BASE_PLATFORM.
>
I am will to
Adding Steve to the CC list as I'd like his input from the
glibc/powerpc side as he's the requester of that feature in the first
place.
Steve: Roland is proposing to ues dsocaps instead of AT_BASE_PLATFORM.
Cheers,
Ben.
On Mon, 2008-07-07 at 17:31 -0700, Roland McGrath wrote:
> > > The kernel do
> > The kernel does not have to come from the same place as the root
> > filesystem. You may want to run a new kernel with an old filesystem, or
> > vice-versa.
Well, it's not like these bits are really going to change in practice. My
point was just that this is a far "softer" ABI than the gener
On Mon, 2008-07-07 at 17:17 -0500, Nathan Lynch wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2008-07-03 at 19:19 -0700, Roland McGrath wrote:
> > > Why not just use ELF_HWCAP for this? It looks like powerpc only has 3
> > > bits
> > > left there (keeping it to 32), but 3 is not 0. If not t
On Mon, 2008-07-07 at 12:01 +0200, Andreas Schwab wrote:
> Roland McGrath <[EMAIL PROTECTED]> writes:
>
> > 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. Th
Benjamin Herrenschmidt wrote:
> On Thu, 2008-07-03 at 19:19 -0700, Roland McGrath wrote:
> > Why not just use ELF_HWCAP for this? It looks like powerpc only has 3 bits
> > left there (keeping it to 32), but 3 is not 0. If not that, why not use
> > dsocaps? That is, some magic in the vDSO, which
Roland McGrath wrote:
> > Well, we use strings to represent the platforms already (ie, the actual
> > CPU microarchitecture). Fitting those into bits would be annoying, it
>
> Then use dsocaps.
>
> > makes sense to have AT_BASE_PLATFORM to be the "base" variant of
> > AT_PLATFORM.
>
> I understa
Roland McGrath writes:
> I understand why you think so. But let's not be too abstract. The
> purpose of the addition is to drive ld.so's selection of libraries, yes?
The is one possible usage of this AT_BASE_PLATFORM. There is also a
requirement from performance tools and large applications to
Mikael Pettersson wrote:
> Nathan Lynch writes:
> > Some IBM POWER-based platforms have the ability to run in a
> > mode which mostly appears to the OS as a different processor from the
> > actual hardware. For example, a Power6 system may appear to be a
> > Power5+, which makes the AT_PLATFOR
Roland McGrath <[EMAIL PROTECTED]> writes:
> 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.
> 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 ld.so.cache file.
That is all. So if you were to change the meaning of
Roland McGrath <[EMAIL PROTECTED]> writes:
>> I'm not sure... if ld.conf.d isn't parse of the kernel source tree then
>> it -will- end in tears...
>
> Of course, you should include the file you want people to install
> as part of the kernel source or build. You can copy it into
> place in make in
On Sun, 2008-07-06 at 23:35 -0700, Roland McGrath wrote:
> > I'm not sure... if ld.conf.d isn't parse of the kernel source tree then
> > it -will- end in tears...
>
> Of course, you should include the file you want people to install
> as part of the kernel source or build. You can copy it into
>
> I'm not sure... if ld.conf.d isn't parse of the kernel source tree then
> it -will- end in tears...
Of course, you should include the file you want people to install
as part of the kernel source or build. You can copy it into
place in make install or something if you like (convention is to
call
On Sun, 2008-07-06 at 23:18 -0700, Roland McGrath wrote:
>
> Using dsocaps gives you the best of both worlds. You can freely choose
> new strings in the kernel without the ld.so code having to know about
> them (which is not true of AT_PLATFORM, but may be true of how you are
> thinking about "st
> Well, we use strings to represent the platforms already (ie, the actual
> CPU microarchitecture). Fitting those into bits would be annoying, it
Then use dsocaps.
> makes sense to have AT_BASE_PLATFORM to be the "base" variant of
> AT_PLATFORM.
I understand why you think so. But let's not be t
On Thu, 2008-07-03 at 19:19 -0700, Roland McGrath wrote:
> Why not just use ELF_HWCAP for this? It looks like powerpc only has 3 bits
> left there (keeping it to 32), but 3 is not 0. If not that, why not use
> dsocaps? That is, some magic in the vDSO, which glibc already supports on
> all machin
Nathan Lynch writes:
> Some IBM POWER-based platforms have the ability to run in a
> mode which mostly appears to the OS as a different processor from the
> actual hardware. For example, a Power6 system may appear to be a
> Power5+, which makes the AT_PLATFORM value "power5+".
>
> However,
Why not just use ELF_HWCAP for this? It looks like powerpc only has 3 bits
left there (keeping it to 32), but 3 is not 0. If not that, why not use
dsocaps? That is, some magic in the vDSO, which glibc already supports on
all machines where it uses the vDSO. (For how it works, see the use in
arc
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value "power5+".
However, some applications (virtual machines, op
20 matches
Mail list logo
