From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58928 invoked by alias); 4 May 2017 16:32:09 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 58896 invoked by uid 89); 4 May 2017 16:32:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=politics, blame X-HELO: mail-qk0-f178.google.com 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=zdJZ1YtROLDIpXonkHu+/3FOzehYRHS3+IB0mm/rF6A=; b=rZEylR3PQMmV6IuB7JBxJ+OeTZww4S0xrZcUtXta9IhQqrewP6QAWGCsM3hnGG2U5f s6ngBY9IkRpsIIBe7qcpfeNeYjqoo/eojZH3r2MZR7Bsf7pItqw2x8tyM5hoQ9lvgCtO cmF62cfMta63WKMF/lbp35V0GnTuL4ABiDNA27Uxk6VFS4OHIhRRqOUtlx8iQ3Wjg03m zWU/q4PGg4WL65Uz7EKehoilZSojEObzBckGqINHwD22CdiNOfq7p3GQde5gkTftZdZy wJ5jGIxpaZ2onWBh2C1XLrZU4B75z+wjZ0QO1z6IErUGnw1VJezRgidZAEfMmbDs95qn r1YA== X-Gm-Message-State: AODbwcCSJaD8n2VWIuCoXDLjbTUbYiK6SSJBiAmPt+s518oQv+pExO+6 NJSKlSqK00+mm+Js3Q4O2Q== X-Received: by 10.55.33.70 with SMTP id h67mr9480243qkh.163.1493915525762; Thu, 04 May 2017 09:32:05 -0700 (PDT) Subject: Re: Requiring Linux 3.2, again To: Joseph Myers Cc: libc-alpha@sourceware.org References: <31ee8964-e944-0288-55b1-fb92fa6e9b4f@redhat.com> From: Carlos O'Donell Message-ID: Date: Thu, 04 May 2017 16:32:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00089.txt.bz2 On 05/04/2017 07:47 AM, Joseph Myers wrote: > On Thu, 4 May 2017, Carlos O'Donell wrote: > >> At a high level I worry about container technology (regardless of the >> choice of framework around namespaces) and the pressure we apply to users >> by moving glibc to require a newer kernel. >> >> Every time we move glibc to require a newer linux kernel that creates an >> inflection point where users have to upgrade their container host to run >> the newer distribution containers. > > Even without glibc requiring a newer kernel, it's entirely plausible that > some userspace software on new distributions will in fact be relying on > new kernel features and so fail to work on containers with old host > kernels unless those features have been backported. E.g., if it uses > getrandom (Linux 3.17) and doesn't have a runtime fallback for it being > unavailable (only maybe e.g. a configure-time fallback for being linked > with old glibc without the function). Yes, but in that case it's just *one* application which fails at runtime, and the application author is considered at fault. If glibc causes the container to even boot before allowing applications to run, then we get blamed, and the politics of the situation are different. What stops us from simply allowing individual interfaces to fail according to the results of the syscalls they make? Or in some cases just calling abort if the syscall is critical for operation of glibc? This would move glibc out of the path of blame, and make it the fault of the developer? Assume your application only used memset. With a bumped up minimum kernel version we would no longer run that application on an older host. Shouldn't we just allow it to run? Now that the minimum kernel version is moving forward smoothly and we all like the cleanups. Perhaps it's time to question the "FATAL: too old" warning and remove it? -- Cheers, Carlos.