All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Carlos O'Donell <carlos@redhat.com>,
	Zack Weinberg <zackw@panix.com>, Dmitry Safonov <dima@arista.com>,
	Andrei Vagin <avagin@gmail.com>,
	GNU C Library <libc-alpha@sourceware.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces
Date: Tue, 3 Nov 2020 13:43:23 +0100	[thread overview]
Message-ID: <20201103124323.GA8061@yuki.lan> (raw)
In-Reply-To: <87k0v7kwdc.fsf@nanos.tec.linutronix.de>

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 of pre-release testruns to make sure that all tests works well on
a different distributions and kernel versions.

Before I wrote a script that automated this[1] i.e. runs all the tests in
qemu and filters out the interesting results it took me a few days of
manual labor to finish the task. Now I just schedulle the jobs and after
a day or two I get the results. Even if the tested kernel crashes, which
happens a lot, the machine is just restarted automatically and the
testrun carries on with a next test. All in all the work that has been
put into the solution wasn't that big to begin with it took me a week to
write a first prototype from a scratch.

[1] https://github.com/metan-ucw/runltp-ng

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2020-11-03 12:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-30 10:02 [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces Lukasz Majewski
2020-10-30 13:08 ` Thomas Gleixner
2020-10-30 15:43   ` Lukasz Majewski
2020-10-30 13:58 ` Cyril Hrubis
2020-10-30 14:02   ` Zack Weinberg
2020-10-30 15:10     ` Thomas Gleixner
2020-10-30 16:58       ` Carlos O'Donell
2020-10-30 20:06         ` Thomas Gleixner
2020-10-30 22:19           ` Carlos O'Donell
2020-10-31  1:38             ` Thomas Gleixner
2020-11-03 12:43               ` Cyril Hrubis [this message]
2020-11-05 17:25               ` Carlos O'Donell
2020-11-07  0:47                 ` Thomas Gleixner
2020-11-19 18:37                   ` Carlos O'Donell
2020-11-20  0:14                     ` Thomas Gleixner
2020-11-25 17:06                       ` Petr Špaček
2020-11-25 20:37                       ` Carlos O'Donell
2020-11-26  0:17                         ` Thomas Gleixner
2020-11-26  3:05                           ` Carlos O'Donell
2020-11-26  8:21                             ` Andreas Schwab
2020-11-14 10:25 ` Pavel Machek

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=20201103124323.GA8061@yuki.lan \
    --to=chrubis@suse.cz \
    --cc=avagin@gmail.com \
    --cc=carlos@redhat.com \
    --cc=dima@arista.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=zackw@panix.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.