On 12/17/2012 10:56 AM, Pavel Emelyanov wrote:
> On 12/17/2012 07:21 PM, H. Peter Anvin wrote:
>> Because it is almost impossible to do right?
>
> In the generic case -- I tend to agree. But it's possible to describe
> how a library should communicate to crtools to make it possible.
>
> Anyway,
On 12/17/2012 07:21 PM, H. Peter Anvin wrote:
> Because it is almost impossible to do right?
In the generic case -- I tend to agree. But it's possible to describe
how a library should communicate to crtools to make it possible.
Anyway, what I wanted to say -- we didn't have this scenario in our
Because it is almost impossible to do right?
Pavel Emelyanov wrote:
>On 12/14/2012 10:44 PM, Andy Lutomirski wrote:
>> On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin
>wrote:
>>> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
> On Thu,
On 12/14/2012 10:44 PM, Andy Lutomirski wrote:
> On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin wrote:
>> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
>>> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin wrote:
> Wouldn't the vdso get
On 12/17/2012 07:21 PM, H. Peter Anvin wrote:
Because it is almost impossible to do right?
In the generic case -- I tend to agree. But it's possible to describe
how a library should communicate to crtools to make it possible.
Anyway, what I wanted to say -- we didn't have this scenario in our
On 12/17/2012 10:56 AM, Pavel Emelyanov wrote:
On 12/17/2012 07:21 PM, H. Peter Anvin wrote:
Because it is almost impossible to do right?
In the generic case -- I tend to agree. But it's possible to describe
how a library should communicate to crtools to make it possible.
Anyway, what I
On 12/14/2012 10:44 PM, Andy Lutomirski wrote:
On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin h...@zytor.com wrote:
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com wrote:
Wouldn't
Because it is almost impossible to do right?
Pavel Emelyanov xe...@parallels.com wrote:
On 12/14/2012 10:44 PM, Andy Lutomirski wrote:
On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin h...@zytor.com
wrote:
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski
On 12/14/2012 03:48 PM, John Stultz wrote:
> On 12/14/2012 02:48 PM, H. Peter Anvin wrote:
>> On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
>>> On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
>>>
>>>
>>> This won't help in case of scenario you've been pointing in
>>> previous
On 12/14/2012 02:48 PM, H. Peter Anvin wrote:
On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
This won't help in case of scenario you've been pointing in
previous email (where c/r happens in a middle of vdso),
would it? Because we
On 12/14/2012 03:09 PM, Stefani Seibold wrote:
>
> Sorry for not following the discussion, but im am currently trying to
> compile the vclocktime.c as a 32 bit object. Most of the (clever) work
> is done.
>
> After this the next step is to map the needed fixmaps into the 32 bit
> address space.
Am Freitag, den 14.12.2012, 14:46 -0800 schrieb H. Peter Anvin:
> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
> > On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
> >> 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
On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
> On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
>> On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
>>>
>>> this would allow us to defer checkpoint until task finish vdso code. Peter,
>>> if I understand you correctly you propose we
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
>> 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
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
> On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
> >
> > this would allow us to defer checkpoint until task finish vdso code. Peter,
> > if I understand you correctly you propose we provide some own proxy-vdso
> > which would
On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
>
> this would allow us to defer checkpoint until task finish vdso code. Peter,
> if I understand you correctly you propose we provide some own proxy-vdso
> which would redirect calls to real ones, right? But the main problem
> is that is exactly the
On Fri, Dec 14, 2012 at 02:00:17PM -0800, H. Peter Anvin wrote:
> On 12/14/2012 01:27 PM, Andy Lutomirski wrote:
> >
> > I don't know all that much about the linux vm. Can we create a
> > special vdso address_space or struct inode or something so that a
> > single vma can contain pages with
On 12/14/2012 01:27 PM, Andy Lutomirski wrote:
>
> I don't know all that much about the linux vm. Can we create a
> special vdso address_space or struct inode or something so that a
> single vma can contain pages with different flags?
>
No, that is still different vmas, but it probably isn't a
On Fri, Dec 14, 2012 at 1:08 PM, H. Peter Anvin wrote:
> On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
>>> The real issue is that happens if the process is checkpointed while
>>> inside the vdso and now eip/rip or a stack frame points into the vdso.
>>> This is not impossible or even
On 12/14/2012 01:20 PM, Cyrill Gorcunov wrote:
> On Fri, Dec 14, 2012 at 01:08:35PM -0800, H. Peter Anvin wrote:
>> On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
>
The real issue is that happens if the process is checkpointed while
inside the vdso and now eip/rip or a stack frame
On Fri, Dec 14, 2012 at 01:08:35PM -0800, H. Peter Anvin wrote:
> On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
> >>>
> >> The real issue is that happens if the process is checkpointed while
> >> inside the vdso and now eip/rip or a stack frame points into the vdso.
> >> This is not impossible or
On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
>>>
>> The real issue is that happens if the process is checkpointed while
>> inside the vdso and now eip/rip or a stack frame points into the vdso.
>> This is not impossible or even unlikely, especially on 32 bits it is
>> downright likely.
>
> I
On Fri, Dec 14, 2012 at 10:47:53AM -0800, H. Peter Anvin wrote:
> On 12/14/2012 10:44 AM, Andy Lutomirski wrote:
> >>
> >> mremap() should work. At the same time, the code itself is not going to
> >> have any stability guarantees between kernel versions -- it obviously
> >> cannot.
> >
> > We
On 12/14/2012 10:44 AM, Andy Lutomirski wrote:
>>
>> mremap() should work. At the same time, the code itself is not going to
>> have any stability guarantees between kernel versions -- it obviously
>> cannot.
>
> We could guarantee that the symbols in the vdso resolve to particular
> offsets
On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin wrote:
> On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
>> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
>>> 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
>>>
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
> On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
>> 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
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
> 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.
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com 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.
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com 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
On Fri, Dec 14, 2012 at 10:35 AM, H. Peter Anvin h...@zytor.com wrote:
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com wrote:
Wouldn't the vdso get mapped already and could be
On 12/14/2012 10:44 AM, Andy Lutomirski wrote:
mremap() should work. At the same time, the code itself is not going to
have any stability guarantees between kernel versions -- it obviously
cannot.
We could guarantee that the symbols in the vdso resolve to particular
offsets within the
On Fri, Dec 14, 2012 at 10:47:53AM -0800, H. Peter Anvin wrote:
On 12/14/2012 10:44 AM, Andy Lutomirski wrote:
mremap() should work. At the same time, the code itself is not going to
have any stability guarantees between kernel versions -- it obviously
cannot.
We could guarantee
On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
The real issue is that happens if the process is checkpointed while
inside the vdso and now eip/rip or a stack frame points into the vdso.
This is not impossible or even unlikely, especially on 32 bits it is
downright likely.
I fear if there
On Fri, Dec 14, 2012 at 01:08:35PM -0800, H. Peter Anvin wrote:
On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
The real issue is that happens if the process is checkpointed while
inside the vdso and now eip/rip or a stack frame points into the vdso.
This is not impossible or even
On 12/14/2012 01:20 PM, Cyrill Gorcunov wrote:
On Fri, Dec 14, 2012 at 01:08:35PM -0800, H. Peter Anvin wrote:
On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
The real issue is that happens if the process is checkpointed while
inside the vdso and now eip/rip or a stack frame points into the
On Fri, Dec 14, 2012 at 1:08 PM, H. Peter Anvin h...@zytor.com wrote:
On 12/14/2012 12:12 PM, Cyrill Gorcunov wrote:
The real issue is that happens if the process is checkpointed while
inside the vdso and now eip/rip or a stack frame points into the vdso.
This is not impossible or even
On 12/14/2012 01:27 PM, Andy Lutomirski wrote:
I don't know all that much about the linux vm. Can we create a
special vdso address_space or struct inode or something so that a
single vma can contain pages with different flags?
No, that is still different vmas, but it probably isn't a big
On Fri, Dec 14, 2012 at 02:00:17PM -0800, H. Peter Anvin wrote:
On 12/14/2012 01:27 PM, Andy Lutomirski wrote:
I don't know all that much about the linux vm. Can we create a
special vdso address_space or struct inode or something so that a
single vma can contain pages with different
On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
this would allow us to defer checkpoint until task finish vdso code. Peter,
if I understand you correctly you propose we provide some own proxy-vdso
which would redirect calls to real ones, right? But the main problem
is that is exactly the idea
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
this would allow us to defer checkpoint until task finish vdso code. Peter,
if I understand you correctly you propose we provide some own proxy-vdso
which would redirect calls
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com 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
On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
On 12/14/2012 02:25 PM, Cyrill Gorcunov wrote:
this would allow us to defer checkpoint until task finish vdso code. Peter,
if I understand you correctly you propose we provide some
Am Freitag, den 14.12.2012, 14:46 -0800 schrieb H. Peter Anvin:
On 12/14/2012 12:34 AM, Pavel Emelyanov wrote:
On 12/14/2012 06:20 AM, Andy Lutomirski wrote:
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com wrote:
Wouldn't the vdso get mapped already and could be mremap()'d.
On 12/14/2012 03:09 PM, Stefani Seibold wrote:
Sorry for not following the discussion, but im am currently trying to
compile the vclocktime.c as a 32 bit object. Most of the (clever) work
is done.
After this the next step is to map the needed fixmaps into the 32 bit
address space. Maybe
On 12/14/2012 02:48 PM, H. Peter Anvin wrote:
On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
This won't help in case of scenario you've been pointing in
previous email (where c/r happens in a middle of vdso),
would it? Because we
On 12/14/2012 03:48 PM, John Stultz wrote:
On 12/14/2012 02:48 PM, H. Peter Anvin wrote:
On 12/14/2012 02:43 PM, Cyrill Gorcunov wrote:
On Fri, Dec 14, 2012 at 02:27:08PM -0800, H. Peter Anvin wrote:
This won't help in case of scenario you've been pointing in
previous email (where c/r
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
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
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,
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
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
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
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
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
On Wed, Dec 12, 2012 at 11:17 PM, Stefani Seibold stef...@seibold.net 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
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
On Thu, Dec 13, 2012 at 4:09 PM, H. Peter Anvin h...@zytor.com 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 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
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 Thu, Dec 13, 2012 at 5:32 PM, H. Peter Anvin h...@zytor.com 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
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 about
On Thu, Dec 13, 2012 at 5:49 PM, H. Peter Anvin h...@zytor.com 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
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 l...@amacapital.net wrote:
On Thu, Dec 13, 2012 at 5:49 PM, H. Peter Anvin h...@zytor.com wrote:
On
On Thu, Dec 13, 2012 at 6:18 PM, H. Peter Anvin h...@zytor.com 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
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.
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
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
> > +++
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
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 TSC to get a fast time time stamp, without knowing the
From: Stefani Seibold stef...@seibold.net
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 TSC to get a fast time time stamp,
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
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
+++
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 stef...@seibold.net 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
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,
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.
The
Should be a simple matter of sharing pages. Look perhaps at the x32 vdso for a
hint.
Stefani Seibold stef...@seibold.net 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
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, i see no
[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
>> > +++
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
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
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
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
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
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 TSC to get a fast time time stamp, without knowing the
From: Stefani Seibold stef...@seibold.net
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 TSC to get a fast time time stamp,
On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
From: Stefani Seibold stef...@seibold.net
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.
On Tue, Dec 11, 2012 at 8:11 AM, stef...@seibold.net wrote:
From: Stefani Seibold stef...@seibold.net
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
On Tue, Dec 11, 2012 at 11:27 AM, John Stultz john.stu...@linaro.org wrote:
On 12/11/2012 08:11 AM, stef...@seibold.net wrote:
From: Stefani Seibold stef...@seibold.net
This small patch add the functions vdso_gettimeofday(),
vdso_clock_gettime()
and vdso_time() support to the VDSO for x86
Am Dienstag, den 11.12.2012, 11:37 -0800 schrieb Andy Lutomirski:
On Tue, Dec 11, 2012 at 8:11 AM, stef...@seibold.net wrote:
From: Stefani Seibold stef...@seibold.net
This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
and vdso_time() support to the VDSO for x86
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 stef...@seibold.net
This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
and vdso_time() support to the VDSO for x86 32-bit
On Tue, Dec 11, 2012 at 12:54 PM, Stefani Seibold stef...@seibold.net 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 stef...@seibold.net
This small patch add the functions vdso_gettimeofday(),
Am Dienstag, den 11.12.2012, 13:18 -0800 schrieb Andy Lutomirski:
On Tue, Dec 11, 2012 at 12:54 PM, Stefani Seibold stef...@seibold.net 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
[cc: Jeremy Fitzhardinge -- you wrote some of this]
On Tue, Dec 11, 2012 at 12:40 PM, Stefani Seibold stef...@seibold.net wrote:
Am Dienstag, den 11.12.2012, 11:37 -0800 schrieb Andy Lutomirski:
On Tue, Dec 11, 2012 at 8:11 AM, stef...@seibold.net wrote:
--- a/arch/x86/vdso/vclock_gettime.c
100 matches
Mail list logo
