On Nov 25 2020, Carlos O'Donell via Libc-alpha wrote:
> We might write a syscall interception framework using seccomp
> and SECCOMP_RET_TRACE, but that involves ptrace'ing the process
> under test, and is equivalent to a micro-sandbox. I'm not against
> that idea for testing; we would test what
On 11/25/20 7:17 PM, Thomas Gleixner wrote:
> Carlos, Petr,
>
> On Wed, Nov 25 2020 at 15:37, Carlos O'Donell wrote:
>> On 11/19/20 7:14 PM, Thomas Gleixner wrote:
>>> So from my point of view asking for distorted time still _is_ a request
>>> for ponies.
>>
>> I'm happy if you say it's more work
Carlos, Petr,
On Wed, Nov 25 2020 at 15:37, Carlos O'Donell wrote:
> On 11/19/20 7:14 PM, Thomas Gleixner wrote:
>> So from my point of view asking for distorted time still _is_ a request
>> for ponies.
>
> I'm happy if you say it's more work than the value it provides.
Thinking more about it.
On 11/19/20 7:14 PM, Thomas Gleixner wrote:
> I hope you are aware that the time namespace offsets have to be set
> _before_ the process starts and can't be changed afterwards,
> i.e. settime() is not an option.
I not interested in settime(). I saw Petr's request and forwarded it on
here to
On 20. 11. 20 1:14, Thomas Gleixner wrote:
On Thu, Nov 19 2020 at 13:37, Carlos O'Donell wrote:
On 11/6/20 7:47 PM, Thomas Gleixner wrote:
Would CONFIG_DEBUG_DISTORTED_CLOCK_REALTIME be a way to go? IOW,
something which is clearly in the debug section of the kernel which wont
get turned on by
On Thu, Nov 19 2020 at 13:37, Carlos O'Donell wrote:
> On 11/6/20 7:47 PM, Thomas Gleixner wrote:
>> Would CONFIG_DEBUG_DISTORTED_CLOCK_REALTIME be a way to go? IOW,
>> something which is clearly in the debug section of the kernel which wont
>> get turned on by distros (*cough*) and comes with a
On 11/6/20 7:47 PM, Thomas Gleixner wrote:
> On Thu, Nov 05 2020 at 12:25, Carlos O'Donell wrote:
>> On 10/30/20 9:38 PM, Thomas Gleixner wrote:
>> If kata grows up quickly perhaps this entire problem becomes solved, but
>> until
>> then I continue to have a testing need for a distinct
Hi!
> I do have a question regarding the Linux time namespaces in respect of
> adding support for virtualizing the CLOCK_REALTIME.
>
> According to patch description [1] and time_namespaces documentation
> [2] the CLOCK_REALTIME is not supported (for now?) to avoid complexity
> and overhead in
On Thu, Nov 05 2020 at 12:25, Carlos O'Donell wrote:
> On 10/30/20 9:38 PM, Thomas Gleixner wrote:
> If kata grows up quickly perhaps this entire problem becomes solved, but until
> then I continue to have a testing need for a distinct CLOCK_REALTIME in a
> time namespace (and it need not be
On 10/30/20 9:38 PM, Thomas Gleixner wrote:
> Coming back to your test coverage argument. I really don't see a problem
> with the requirement of having qemu installed in order to run 'make
> check'.
Cost. It's is cheaper and easier to maintain and deploy containers.
A full VM requires
Hi!
> Virtualization is the right answer to the testing problem and if people
> really insist on running their broken legacy apps past 2038, then stick
> them into a VM and charge boatloads of money for that service.
Let me just emphasise this with a short story. Before I release LTP I do
a lot
Carlos,
On Fri, Oct 30 2020 at 18:19, Carlos O'Donell wrote:
> On 10/30/20 4:06 PM, Thomas Gleixner wrote:
>> On Fri, Oct 30 2020 at 12:58, Carlos O'Donell wrote:
>>> I expect that more requests for further time isolation will happen
>>> given the utility of this in containers.
>>
>> There was a
On 10/30/20 4:06 PM, Thomas Gleixner wrote:
> On Fri, Oct 30 2020 at 12:58, Carlos O'Donell wrote:
>> I expect that more requests for further time isolation will happen
>> given the utility of this in containers.
>
> There was a lengthy discussion about this and the only "usecase" which
> was
On Fri, Oct 30 2020 at 12:58, Carlos O'Donell wrote:
> On 10/30/20 11:10 AM, Thomas Gleixner via Libc-alpha wrote:
>> That's what virtual machines are for.
>
> Certainly, that is always an option, just like real hardware.
>
> However, every requirement we add to testing reduces the number of
>
On 10/30/20 11:10 AM, Thomas Gleixner via Libc-alpha wrote:
> On Fri, Oct 30 2020 at 10:02, Zack Weinberg wrote:
>> On Fri, Oct 30, 2020 at 9:57 AM Cyril Hrubis wrote:
According to patch description [1] and time_namespaces documentation
[2] the CLOCK_REALTIME is not supported (for now?)
Hi Thomas,
> Lukasz,
>
> On Fri, Oct 30 2020 at 11:02, Lukasz Majewski wrote:
> > I do have a question regarding the Linux time namespaces in respect
> > of adding support for virtualizing the CLOCK_REALTIME.
> >
> > According to patch description [1] and time_namespaces documentation
> > [2]
On Fri, Oct 30 2020 at 10:02, Zack Weinberg wrote:
> On Fri, Oct 30, 2020 at 9:57 AM Cyril Hrubis wrote:
>> > According to patch description [1] and time_namespaces documentation
>> > [2] the CLOCK_REALTIME is not supported (for now?) to avoid complexity
>> > and overhead in the kernel.
> ...
>>
On Fri, Oct 30, 2020 at 9:57 AM Cyril Hrubis wrote:
> > According to patch description [1] and time_namespaces documentation
> > [2] the CLOCK_REALTIME is not supported (for now?) to avoid complexity
> > and overhead in the kernel.
...
> > To be more specific - [if this were supported] it would
Hi!
> I do have a question regarding the Linux time namespaces in respect of
> adding support for virtualizing the CLOCK_REALTIME.
>
> According to patch description [1] and time_namespaces documentation
> [2] the CLOCK_REALTIME is not supported (for now?) to avoid complexity
> and overhead in
Lukasz,
On Fri, Oct 30 2020 at 11:02, Lukasz Majewski wrote:
> I do have a question regarding the Linux time namespaces in respect of
> adding support for virtualizing the CLOCK_REALTIME.
>
> According to patch description [1] and time_namespaces documentation
> [2] the CLOCK_REALTIME is not
Hi Andrei, Dmitry,
I do have a question regarding the Linux time namespaces in respect of
adding support for virtualizing the CLOCK_REALTIME.
According to patch description [1] and time_namespaces documentation
[2] the CLOCK_REALTIME is not supported (for now?) to avoid complexity
and overhead
21 matches
Mail list logo
