From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 278B3C433B4 for ; Mon, 3 May 2021 16:09:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DC2CC61183 for ; Mon, 3 May 2021 16:09:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231272AbhECQKn convert rfc822-to-8bit (ORCPT ); Mon, 3 May 2021 12:10:43 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]:22108 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231182AbhECQKm (ORCPT ); Mon, 3 May 2021 12:10:42 -0400 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-255-kFw4Vq1gOwC5lu5CIeuZOg-1; Mon, 03 May 2021 17:09:46 +0100 X-MC-Unique: kFw4Vq1gOwC5lu5CIeuZOg-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) by AcuMS.aculab.com (fd9f:af1c:a25b:0:994c:f5c2:35d6:9b65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 3 May 2021 17:09:45 +0100 Received: from AcuMS.Aculab.com ([fe80::994c:f5c2:35d6:9b65]) by AcuMS.aculab.com ([fe80::994c:f5c2:35d6:9b65%12]) with mapi id 15.00.1497.015; Mon, 3 May 2021 17:09:45 +0100 From: David Laight To: 'Theodore Ts'o' , "Maciej W. Rozycki" CC: Linus Torvalds , Tom Stellard , Nick Desaulniers , "Masahiro Yamada" , Nathan Chancellor , "Linux Kernel Mailing List" , clang-built-linux , Fangrui Song , Serge Guelton , Sylvestre Ledru Subject: RE: Very slow clang kernel config .. Thread-Topic: Very slow clang kernel config .. Thread-Index: AQHXQCnxH46G91tEpEmd7WaoBDaEqarR6NJg Date: Mon, 3 May 2021 16:09:45 +0000 Message-ID: <71e42d2a3c9d415188984f34f602425c@AcuMS.aculab.com> References: <1c5e05fa-a246-9456-ff4e-287960acb18c@redhat.com> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Theodore Ts'o > Sent: 03 May 2021 15:38 ... > If people could actually guarantee stable ABI's, then shared libraries > might make sense. E2fsprogs hasn't had a major version bump in shared > libraries for over a decade (although some developers whine and > complain about how I reject function signature changes in the > libext2fs library to provide that ABI stability). But how many > userspace packages can make that claim? Indeed. Stable ABIs are really mandatory for anything released as a shared library. You can add new functions, and (if careful) new features to existing functions (if you remembered to check all those unused fields and flags), but the function signatures must not change. You also can't change the exported data area. We've got some simple drivers, they don't do anything complex. Just hardware interrupts and PCIe accesses. It wouldn't require many structure to be fixed, and a few non-inlined versions of some access functions to make these reasonably binary compatible. At least to the point that they don't need rebuilding when a distribution releases a new minor kernel version. Solaris had stable kernel ABIs. The windows version of our drivers installs on everything from Windows 7 (maybe even Vista) through to the latest Windows 10 (apart from the 'driver signing' fiasco). With multiple symbol namespaces it ought to be possible to keep them separately stable - so that drivers that only use some symbols are portable. Of course, there are the people who only want to support in-tree source drivers. They clearly exist outside the commercial world. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)