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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB0DAC433EF for ; Fri, 19 Nov 2021 15:09:09 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 98D96611CC for ; Fri, 19 Nov 2021 15:09:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 98D96611CC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=u8fMxcESTpgTGijz/FtRu2dFAtmj2VtVQ0yXqKxsrj8=; b=NdX5OyoWLPSn1a bk+rEvL16J+LsJLItVibBxbA7KOjGQXv0pvN6zrQddLhgd41lBwgd0oSdKxrhhdMb4X69pwlCWSeJ PWxK2S30/b73khn8J1tuu0IldihREnpId8MVLeFjbizPsk8uXdAy1tGN25NnHOR4yRhDpJlJT2bkI whuZVC3FmZCzZ4szUmTWoPeQidQ2zNp3mKUxEqLTVM4haPRu7wqqFX9ceqojYLE87jy/px96F0Gc2 B9nh3lOIrRaKuehvbAybxzMdNTqGjPcFXnYyRKszW3GDA6A+0Tn6ohVZUq8ioJrkCYcFqkW1bxXuY 4fkrpm8dap1IR5bg8PaQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mo5Tt-00Ao5N-6q; Fri, 19 Nov 2021 15:07:14 +0000 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mo5TF-00AnrZ-4C for linux-arm-kernel@lists.infradead.org; Fri, 19 Nov 2021 15:06:34 +0000 Received: by mail-wm1-x333.google.com with SMTP id f7-20020a1c1f07000000b0032ee11917ceso7784833wmf.0 for ; Fri, 19 Nov 2021 07:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=9LghidGzK5wVxoEesb/L8gTDRQW74I1XzqD+h7Ydxd8=; b=ThJg3WF09aFCTuH2nUMR2RjPEiyZEHH/Ew5m2/uZZSMAXSP+tUthdSO1fmjo2qKWeU 45Hn8Hgn91hV5q+U6rorUGLM2sMuPDHYa9LJlaaq4CGvWIdUAiWRzi7l32411ezoz7Ed UfEhsgFqn/TYVjlTQ1x6OtTfh4ZgxcGVNdiY8dyFmAyRcy8suheoHZR/1Dey0LgdcvG+ mankWsi9N4kQ6WRh+ekZfYzxKW7qeB6RN1v8FkSZ+4tesaMcXM8Cgfdtx8KejMMX8Vg5 5KEZ1IPldun0lw36a/VB9DNib6XHhQiudT9RMvJEyRiGROFsOfg9l4q11bv5IhtZMxc3 R0yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=9LghidGzK5wVxoEesb/L8gTDRQW74I1XzqD+h7Ydxd8=; b=hl2pM/kVustu+UKB9oTM6ltPRBfiXaDyN2b1CSw8K4f4rvi1If2DrO9FpoZ+7nBk5c FEZmGp0w77tZiPD6ii2ULn05cYqrkmfVlVB2CK4ZXaYzBhqIXHKuzXYOCeNX68rDqZkh oLnM4uwa27MIwBaiv+Cp36B/pPsSdm2bZTxHtIeSGB/TsV+2AgDf1fsk2bYz++/KJy+2 hu7GtcNZlI4PNici+GQ9RNnOdeV+YztGTP6GZJnD4xQUCE/Pjl83+3j5H84Us4jKbtWn Sg5tJKpWMMFKeBaVEUa+gtU/ioM9tj72XBSaw2yy4eY1dM0j3YCS10aiD5Mg08TCLKM7 E1aw== X-Gm-Message-State: AOAM5304VV+qRDp1oXpqnnkzKDcqDkQoqbYsYO+YmD9fktAPhRD+dHVK maAwhFN4cIHUaEMdLqrC13s= X-Google-Smtp-Source: ABdhPJzu9ei/pAU2yn2kzxvlKTIuV+OQKa9BIy8XnEer1U+7uUmszt8b/HqJvarFM0xoXQ8IPgXm6g== X-Received: by 2002:a1c:6a0e:: with SMTP id f14mr409487wmc.58.1637334391087; Fri, 19 Nov 2021 07:06:31 -0800 (PST) Received: from [192.168.0.160] ([170.253.36.171]) by smtp.gmail.com with ESMTPSA id u23sm29930wru.21.2021.11.19.07.06.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Nov 2021 07:06:30 -0800 (PST) Message-ID: <434296d3-8fe1-f1d2-ee9d-ea25d6c4e43e@gmail.com> Date: Fri, 19 Nov 2021 16:06:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH 00/17] Add memberof(), split some headers, and slightly simplify code Content-Language: en-US To: Arnd Bergmann Cc: LKML , Ajit Khaparde , Andrew Morton , Andy Shevchenko , Bjorn Andersson , Borislav Petkov , Corey Minyard , Chris Mason , Christian Brauner , David Sterba , Jani Nikula , Jason Wang , Jitendra Bhivare , John Hubbard , "John S . Gruber" , Jonathan Cameron , Joonas Lahtinen , Josef Bacik , Kees Cook , Ketan Mukadam , Len Brown , "Michael S. Tsirkin" , Miguel Ojeda , Mike Rapoport , Nick Desaulniers , "Rafael J. Wysocki" , Rasmus Villemoes , Rodrigo Vivi , Russell King , Somnath Kotur , Sriharsha Basavapatna , Subbu Seetharaman , intel-gfx@lists.freedesktop.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-btrfs@vger.kernel.org, linux-scsi@vger.kernel.org, netdev@vger.kernel.org, virtualization@lists.linux-foundation.org References: <20211119113644.1600-1-alx.manpages@gmail.com> From: "Alejandro Colomar (man-pages)" In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211119_070633_223179_957E13F3 X-CRM114-Status: GOOD ( 24.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Arnd, On 11/19/21 15:47, Arnd Bergmann wrote: > On Fri, Nov 19, 2021 at 12:36 PM Alejandro Colomar > wrote: >> >> Alejandro Colomar (17): >> linux/container_of.h: Add memberof(T, m) >> Use memberof(T, m) instead of explicit NULL dereference >> Replace some uses of memberof() by its wrappers >> linux/memberof.h: Move memberof() to separate header >> linux/typeof_member.h: Move typeof_member() to a separate header >> Simplify sizeof(typeof_member()) to sizeof_field() >> linux/NULL.h: Move NULL to a separate header >> linux/offsetof.h: Move offsetof(T, m) to a separate header >> linux/offsetof.h: Implement offsetof() in terms of memberof() >> linux/container_of.h: Implement container_of_safe() in terms of >> container_of() >> linux/container_of.h: Cosmetic >> linux/container_of.h: Remove unnecessary cast to (void *) > > My feeling is that this takes the separation too far: by having this many header > files that end up being included from practically every single .c file > in the kernel, > I think you end up making compile speed worse overall. > > If your goal is to avoid having to recompile as much of the kernel > after touching > a header, I think a better approach is to help untangle the dependencies, e.g. > by splitting out type definitions from headers with inline functions (most > indirect header dependencies are on type definitions) and by focusing on > linux/fs.h, linux/sched.h, linux/mm.h and how they interact with the rest of the > headers. At the moment, these are included in most .c files and they in turn > include a ton of other headers. Yes, I would like to untangle the dependencies. The main reason I started doing this splitting is because I wouldn't be able to include in some headers, because it pulled too much stuff that broke unrelated things. So that's why I started from there. I for example would like to get NULL in memberof() without puling anything else, so makes sense for that. It's clear that every .c wants NULL, but it's not so clear that every .c wants everything that pulls indirectly. But I'll note that linux/fs.h, linux/sched.h, linux/mm.h are interesting headers for further splitting. BTW, I also have a longstanding doubt about how header files are organized in the kernel, and which headers can and cannot be included from which other files. For example I see that files in samples or scripts or tools, that redefine many things such as offsetof() or ARRAY_SIZE(), and I don't know if there's a good reason for that, or if I should simply remove all that stuff and include everywhere I see offsetof() being used. Thanks, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel