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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8531C00140 for ; Wed, 10 Aug 2022 09:26:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232060AbiHJJ0n (ORCPT ); Wed, 10 Aug 2022 05:26:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232066AbiHJJ0m (ORCPT ); Wed, 10 Aug 2022 05:26:42 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C4C5F60539 for ; Wed, 10 Aug 2022 02:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660123596; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=REovcAc0irul9Otc+DHjiNYKhgyWXaWXdC+TCEPnc/U=; b=IFu79W3O9X4h8A0hQntdnluZjtYEYAINmzoLY69O10ZQ+uC0mcyxG0sSUfR7bECdl78MKs 6nOV+BPZnNiyfbWo8VPTPJ2rsora3RzjzgKUDb3DuNBELkJqWIXY/rX6ELhIyXq4dZJRR6 nkqclZc+h6GVALpFmPHhoPBji1qIXpU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-638-V-viqhV2OyKPRUEj6RfDPg-1; Wed, 10 Aug 2022 05:26:33 -0400 X-MC-Unique: V-viqhV2OyKPRUEj6RfDPg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7707118A6585; Wed, 10 Aug 2022 09:26:33 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.75]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2352A400DFD7; Wed, 10 Aug 2022 09:26:31 +0000 (UTC) From: Florian Weimer To: David Howells Cc: linux-fsdevel@vger.kernel.org, Ian Kent , Alexander Viro , Christian Brauner , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH] uapi: Remove the inclusion of linux/mount.h from uapi/linux/fs.h References: <163410.1659964655@warthog.procyon.org.uk> Date: Wed, 10 Aug 2022 11:26:30 +0200 In-Reply-To: <163410.1659964655@warthog.procyon.org.uk> (David Howells's message of "Mon, 08 Aug 2022 14:17:35 +0100") Message-ID: <87zggce9fd.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org * David Howells: > We're seeing issues in autofs and xfstests whereby linux/mount.h (the UAPI > version) as included indirectly by linux/fs.h is conflicting with > sys/mount.h (there's a struct and an enum). > > Would it be possible to just remove the #include from linux/fs.h (as patch > below) and rely on those hopefully few things that need mount flags that don't > use the glibc header for them working around it by configuration? Wasn't split from relatively recently, and userspace is probably using to get the mount flag definitions? In retrospect, it would have been better to add the new fsmount stuff to a separate header file, so that we could include that easily from on the glibc side. Adhemerval posted a glibc patch to fake that (for recent compilers): [PATCH] linux: Fix sys/mount.h usage with kernel headers I think it should work reliably, so that's probably the direction we are going to move in. We'll backport this to 2.36, and distributions will pick it up. Thanks, Florian