On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote:
> Wouldn't the vdso get mapped already and could be mremap()'d. If we really
> need more control I'd almost push for a device/filesystem node that could be
> mmapped the usual way.
Hmm. That may work, but it'll still break ABI. I'm not s
Wouldn't the vdso get mapped already and could be mremap()'d. If we really
need more control I'd almost push for a device/filesystem node that could be
mmapped the usual way.
Andy Lutomirski wrote:
>On Thu, Dec 13, 2012 at 5:49 PM, H. Peter Anvin wrote:
>> On 12/13/2012 05:42 PM, Andy Lutomi
On Thu, Dec 13, 2012 at 5:49 PM, H. Peter Anvin wrote:
> On 12/13/2012 05:42 PM, Andy Lutomirski wrote:
>>
>> The 64-bit/x32 case is currently very simple and fast because it uses
>> absolute addressing. Admittedly, pcrel references are free, so
>> changing this wouldn't cost much. For native, i
On 12/13/2012 05:42 PM, Andy Lutomirski wrote:
>
> The 64-bit/x32 case is currently very simple and fast because it uses
> absolute addressing. Admittedly, pcrel references are free, so
> changing this wouldn't cost much. For native, it'll be slower, but
> maybe no one cares. I seem to care abo
On Thu, Dec 13, 2012 at 5:32 PM, H. Peter Anvin wrote:
> On 12/13/2012 04:20 PM, Andy Lutomirski wrote:
>>
>>
>> What you could do is probably arrange (using some linker script magic)
>> for a symbol to exist that points at the page *before* the vdso
>> starts. Then just map the vvar page there w
On 12/13/2012 04:20 PM, Andy Lutomirski wrote:
What you could do is probably arrange (using some linker script magic)
for a symbol to exist that points at the page *before* the vdso
starts. Then just map the vvar page there when starting a compat
task. You could then address it using a normal
On 12/13/2012 04:20 PM, Andy Lutomirski wrote:
Whatever data you need you can just map it into the vdso range. There
really shouldn't be anything special about that at all.
The fixmap stuff is an x86-64 legacy that you don't have to worry about,
obviously.
The fixmap page is new. It's not A
On Thu, Dec 13, 2012 at 4:09 PM, H. Peter Anvin wrote:
> On 12/13/2012 11:32 AM, Andy Lutomirski wrote:
>>
>>
>> x32's vdso cheats -- x32 code can see high addresses just fine. The
>> toolchain just makes it difficult.
>>
>> Your best bet is probably to just map the vvar page twice -- once at
>>
On 12/13/2012 11:32 AM, Andy Lutomirski wrote:
x32's vdso cheats -- x32 code can see high addresses just fine. The
toolchain just makes it difficult.
Your best bet is probably to just map the vvar page twice -- once at
the same address as native 32-bit mode (but only for compat tasks)
would us
On Wed, Dec 12, 2012 at 11:17 PM, Stefani Seibold wrote:
> Am Mittwoch, den 12.12.2012, 22:47 -0800 schrieb H. Peter Anvin:
>> Should be a simple matter of sharing pages. Look perhaps at the x32 vdso
>> for a hint.
>>
>
>
>> >
>> >Any idea or clean solution how i can map the 64 bit vgtod into th
Am Mittwoch, den 12.12.2012, 22:47 -0800 schrieb H. Peter Anvin:
> Should be a simple matter of sharing pages. Look perhaps at the x32 vdso for
> a hint.
>
> >
> >Any idea or clean solution how i can map the 64 bit vgtod into the 32
> >bit address space? Thats the only problem i see.
> >
No,
Should be a simple matter of sharing pages. Look perhaps at the x32 vdso for a
hint.
Stefani Seibold wrote:
>Am Mittwoch, den 12.12.2012, 22:14 -0800 schrieb H. Peter Anvin:
>> This is too late for 3.8 anyway, so there is time to make it work
>correctly before tge 3.9 merge window anyway. Aft
Am Mittwoch, den 12.12.2012, 22:14 -0800 schrieb H. Peter Anvin:
> This is too late for 3.8 anyway, so there is time to make it work correctly
> before tge 3.9 merge window anyway. After this merge window is over I may
> pull tjis into a testing branch, but compat support is a precondition.
>
>
This is too late for 3.8 anyway, so there is time to make it work correctly
before tge 3.9 merge window anyway. After this merge window is over I may pull
tjis into a testing branch, but compat support is a precondition.
The vdso is only optional if you build in backwards compatibility anyway,
No, let's not. Why? Because if we do that we may inadvertently create an ABI
which is hard to support across the board.
Stefani Seibold wrote:
>Am Mittwoch, den 12.12.2012, 15:34 -0800 schrieb H. Peter Anvin:
>> On 12/12/2012 12:19 PM, stef...@seibold.net wrote:
>> > diff --git a/arch/x86/vds
Am Mittwoch, den 12.12.2012, 15:34 -0800 schrieb H. Peter Anvin:
> On 12/12/2012 12:19 PM, stef...@seibold.net wrote:
> > diff --git a/arch/x86/vdso/vdso32/vclock_gettime.c
> > b/arch/x86/vdso/vdso32/vclock_gettime.c
> > new file mode 100644
> > index 000..c9a1909
> > --- /dev/null
> > +++ b/a
On 12/12/2012 12:19 PM, stef...@seibold.net wrote:
diff --git a/arch/x86/vdso/vdso32/vclock_gettime.c
b/arch/x86/vdso/vdso32/vclock_gettime.c
new file mode 100644
index 000..c9a1909
--- /dev/null
+++ b/arch/x86/vdso/vdso32/vclock_gettime.c
@@ -0,0 +1,7 @@
+/*
+ * since vgtod layout differs b
[cc: Jeremy Fitzhardinge -- you wrote some of this]
On Tue, Dec 11, 2012 at 12:40 PM, Stefani Seibold wrote:
> Am Dienstag, den 11.12.2012, 11:37 -0800 schrieb Andy Lutomirski:
>> On Tue, Dec 11, 2012 at 8:11 AM, wrote:
>> > --- a/arch/x86/vdso/vclock_gettime.c
>> > +++ b/arch/x86/vdso/vclock_g
Am Dienstag, den 11.12.2012, 13:18 -0800 schrieb Andy Lutomirski:
> On Tue, Dec 11, 2012 at 12:54 PM, Stefani Seibold wrote:
> > Am Dienstag, den 11.12.2012, 11:27 -0800 schrieb John Stultz:
> >> On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
> >> > From: Stefani Seibold
> >> >
> >> > This sm
On Tue, Dec 11, 2012 at 12:54 PM, Stefani Seibold wrote:
> Am Dienstag, den 11.12.2012, 11:27 -0800 schrieb John Stultz:
>> On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
>> > From: Stefani Seibold
>> >
>> > This small patch add the functions vdso_gettimeofday(),
>> > vdso_clock_gettime()
>>
Am Dienstag, den 11.12.2012, 11:27 -0800 schrieb John Stultz:
> On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
> > From: Stefani Seibold
> >
> > This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
> > and vdso_time() support to the VDSO for x86 32-bit kernels.
> >
> >
Am Dienstag, den 11.12.2012, 11:37 -0800 schrieb Andy Lutomirski:
> On Tue, Dec 11, 2012 at 8:11 AM, wrote:
> > From: Stefani Seibold
> >
> > This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
> > and vdso_time() support to the VDSO for x86 32-bit kernels.
> >
> > The r
On Tue, Dec 11, 2012 at 11:27 AM, John Stultz wrote:
> On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
>>
>> From: Stefani Seibold
>>
>> This small patch add the functions vdso_gettimeofday(),
>> vdso_clock_gettime()
>> and vdso_time() support to the VDSO for x86 32-bit kernels.
>>
>> The reas
On Tue, Dec 11, 2012 at 8:11 AM, wrote:
> From: Stefani Seibold
>
> This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
> and vdso_time() support to the VDSO for x86 32-bit kernels.
>
> The reason to do this was to get a fast reliable time stamp. Many developers
> uses T
On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
From: Stefani Seibold
This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
and vdso_time() support to the VDSO for x86 32-bit kernels.
The reason to do this was to get a fast reliable time stamp. Many developers
uses TS
25 matches
Mail list logo
