From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 0A24B3842423 for ; Thu, 5 Nov 2020 17:25:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0A24B3842423 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-182-Y5RN2D73OFmw18cOQP5oZQ-1; Thu, 05 Nov 2020 12:25:12 -0500 X-MC-Unique: Y5RN2D73OFmw18cOQP5oZQ-1 Received: by mail-qk1-f198.google.com with SMTP id y8so1345646qki.12 for ; Thu, 05 Nov 2020 09:25:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=WPEI/FFuYpiP56PpQA6lk3angxPYKQdyFb9K5UKth0s=; b=XCTBd11ddEdujgoS8TapDjfyIFlRsvd5y0O9dcErMvr5WaqBFX/TQMyfNelSEBSR5O aq5mNlWsgWJybBMxCNXxqu6X39ym3F+6deoxNnBodCfHrD42qKLakJ+PdaKtHsOdvOhk NEtmEUN4Fv85Xf+o7ANc60LXioe8A75kiIaDhGDrX+PsogWstNojDUR2eh+hBXKz70dD LBvYZiZWaZXMEoVF9xc3MdDj7yNvPlt/n/RAoFx0g793sizu2Xykw80ka0rS7kQg66w0 Tldel1Wb+T+EPe5L5jTllWzQfIHvoQCnmrQ4TQV1sPe+gdrjaykUBFw7RoFXeLW9MjHM LN4Q== X-Gm-Message-State: AOAM533QOTcNu/NiYGVIzJrD4Z3/zDKnPIj+UY3xVEPQKw4iBycklXQl a4X4xM7VXFLYaiTfzXQmkypUD++XpINHuH8fyemNXvl08KWY7f3UXZcKInk0mhqBPqhUXYJBxFf IDK8PBtvFjJfqXGVvHz2+ X-Received: by 2002:a05:6214:146e:: with SMTP id c14mr3309906qvy.22.1604597112249; Thu, 05 Nov 2020 09:25:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJxtmeXVAB1aAnOhzStHrZkBLVBdXifGyhRwR1oX2R19i3a1RqfwAioUGSo4+qVHDn8RU39ntQ== X-Received: by 2002:a05:6214:146e:: with SMTP id c14mr3309882qvy.22.1604597111984; Thu, 05 Nov 2020 09:25:11 -0800 (PST) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id n3sm1226750qta.10.2020.11.05.09.25.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Nov 2020 09:25:11 -0800 (PST) Subject: Re: [Y2038][time namespaces] Question regarding CLOCK_REALTIME support plans in Linux time namespaces To: Thomas Gleixner , Zack Weinberg , Cyril Hrubis Cc: Dmitry Safonov , Andrei Vagin , GNU C Library , Linux Kernel Mailing List References: <20201030110229.43f0773b@jawa> <20201030135816.GA1790@yuki.lan> <87sg9vn40t.fsf@nanos.tec.linutronix.de> <72bbb207-b041-7710-98ad-b08579fe17e4@redhat.com> <87h7qbmqc3.fsf@nanos.tec.linutronix.de> <7bb5837f-1ff6-2b2c-089e-e2441d31ddb2@redhat.com> <87k0v7kwdc.fsf@nanos.tec.linutronix.de> From: Carlos O'Donell Organization: Red Hat Message-ID: <7a4d7b14-1f0b-4c40-2bd1-2582d8b71868@redhat.com> Date: Thu, 5 Nov 2020 12:25:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <87k0v7kwdc.fsf@nanos.tec.linutronix.de> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 17:25:16 -0000 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 maintaining and updating images, and kernel builds independent of what the developer is using for their development system. This goes out of date quickly and needs a lot of resources to maintain. When you get away from a VM you can then engage the entire developer community to just run your userspace testing on *their* hardware on *their* kernels. So I can go to Arm, Intel, AMD, IBM, SUSE, Red Hat, etc. and say: "All you need to do is run 'make check' and the tests will verify your hardware and kernel are working correctly." Those developers don't want their system clocks adjusted during testing, and they are as busy as you and I are. Container registries and tooling are much lighter weight and support layering changes on top of base images in ways which allow different testing scenarios. I don't have any desire to build a similar ecosystem for VM images or wait for VM+container (kata) tooling to grow up. 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 unconditional, if I have to engage magic then I'm happy to do that). > If you can't ask that from your contributors, then asking me to provide > you a namespace magic is just hillarious. The contributor who refuses to > install qemu will also insist to run on some last century kernel which > does not even know about name spaces at all. I don't disagree with you, it is *absolutely* a VM tooling issue, and that containers are easier to maintain, and deploy. With namespaces I can build glibc, a sysroot, and run it in isolation very quickly. Just so I understand, let me reiterate your position: * Adding CLOCK_REALTIME to the kernel is a lot of work given the expected guarantees for a local system. * CLOCK_REALTIME is an expensive resource to maintain, even more expensive than other resources where the kernel can balance their usage. * On balance it would be better to use vm or vm+containers e.g. kata as a solution to having CLOCK_REALTIME distinct in the container. Thanks for your feedback. -- Cheers, Carlos.