Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp994308pxa; Fri, 28 Aug 2020 00:08:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxiweLmJTfjLl9fbgSCsSk4096sSOl1MprwOScXKsKOSBeXqZxQMjgPct0o6J/omgw7cfvj X-Received: by 2002:a05:6402:1443:: with SMTP id d3mr483777edx.40.1598598509028; Fri, 28 Aug 2020 00:08:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598598509; cv=none; d=google.com; s=arc-20160816; b=JuwKQK+PEpnWP8zEZC9tfgrfmVALxy2OnRVcraUsEZM2xoLI6KeudvCbhm6V84Dcyl Ez8Mev/JLIZg6XfnpmxH8zA7y76+kEL85x7SdEn6AUZUg2FD4YIPOpNi52GP8lbqH6Ok MN5LPIPWVK+e2Zjv9wGoF1chlHysirdphw+P/BAp5yEmrWqWlXJ0DhStx0NS8iB/8ePx YAf9mUOHqEcGdVVR5ni4C9C5dWjcrdYWWRb6ddJYtc/cylXXute/7EpK3LTCUGDmAmQ2 Z3D+AjRQJD6vBzybhLClKx9R93O1Q4Ge5i69zE69oj7aZ0qvXeTahrY2jH6FeS46Fd3s 0duQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0pgztyPJ+HoTFkAXRpIdttagMgd+kIjYcrjfVyLosO0=; b=Rw6v15HVhVtXKTxuwO9u/Wxsqwci1IO1gL3oMmTMETycMj2pDhtbG1kil+z8BnQBYG CbZ24IbQo0h7gI7WtlC/nL2Jzj14D2z8rPHCw6WOvY3u1EYzYyCEey5138qzibjznsrF OIEKjuR06OhA0VOH6lfQDnwZoxopj8CEcqHJa/4R1TAQBNeRIvhfeccEpDnDWGNBLh9i Xg0kGt9qIXtqYWDqwTQpkWm9nBus2/yM0TMMF3arNMUXVivcuY6oO+Rqub85HJlC6lE9 IJqfCbVFGQ5SWaLPNVCuAQ283ltbRbN1GW1RM4tB3Uus/MoBKIgjvacHzP2S/4qd7TP7 MyGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=brkXHNfW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u5si88523ejn.410.2020.08.28.00.08.06; Fri, 28 Aug 2020 00:08:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=brkXHNfW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728092AbgH1HHY (ORCPT + 99 others); Fri, 28 Aug 2020 03:07:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726219AbgH1HHX (ORCPT ); Fri, 28 Aug 2020 03:07:23 -0400 Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7FA1BC061264 for ; Fri, 28 Aug 2020 00:07:23 -0700 (PDT) Received: by mail-oi1-x244.google.com with SMTP id v13so14184oiv.13 for ; Fri, 28 Aug 2020 00:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0pgztyPJ+HoTFkAXRpIdttagMgd+kIjYcrjfVyLosO0=; b=brkXHNfWnNhZJaUoSEwoddkP1PZyGs5tC9d9Glaz5ACKAaLR+ATB6lPjc3kJsproCB JNj3xuFGNIoNSrL/xlnLyPH89U9xlDfTj6yBsxQXt1JE42B8g+WeyrMSISKnocnfe2mS 86D9afCAdLCF+xNbZTYOFutqpZysrtWcakhiQb+TiRIqDBR9WZS8fbOhmPWJes4yDDiK 8Mw79WWH6VY60D1zQso30t+ULMY5SN5/7k8iCVyyZE1fCykfGb7wtBxA5BC0S3vUYPSe 2tZxR0UmmL5ISEqJ7bm3wuQY48HeFejrYGBR29EO6hGPoUgQBHpjqv4PPd3El3Oq1oXB F3rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0pgztyPJ+HoTFkAXRpIdttagMgd+kIjYcrjfVyLosO0=; b=iwD3k93Ut7bOzn4nK7xyBGF7vf8CwY9SPmmifYxkzsvKqU0UFwBsCLQLMW3vllcULH jy0h5r6B+Fwpjo8KUiKZYLr36JC+Tsz2SrP85N56ZXZl/UVlbV8Xg8vtSL3iR+vsivxy K8+wU5jgTkOQkM944MwCYdRVpukx4iP4mR+0MwpuTCnVsf/3aaEhwXP5zVzVLwsTAVKs 90xxLFS3VPcVd8P4teijLdAaykCRxG6fjl2WS97mOf0mMGsWhaIgBX/v66nXNX3gjGFX 86igOHPaKhQoxpES2O4VRWh8nHGy2ENKdrRmqAEAMUinuyC3FeYYNOqe4gZvRQJJKTeM LPLA== X-Gm-Message-State: AOAM530+WHV/ry/IQjw4Doz/wIojif/G3StWBj8Gwyl1A0lB5y6dI4Wv 4J4A0pbWAeokqzOHPTQ2h/6ml9rN08sV2t2SZE0= X-Received: by 2002:aca:ec95:: with SMTP id k143mr178854oih.76.1598598442889; Fri, 28 Aug 2020 00:07:22 -0700 (PDT) MIME-Version: 1.0 References: <20200827013636.149307-1-allen.lkml@gmail.com> <1598553133.4237.8.camel@HansenPartnership.com> <202008271150.7231B901@keescook> In-Reply-To: From: Allen Date: Fri, 28 Aug 2020 12:37:11 +0530 Message-ID: Subject: Re: [PATCH] linux/kernel.h: add container_from() To: Linus Torvalds Cc: Kees Cook , James Bottomley , Andrew Morton , Thomas Gleixner , Linux Kernel Mailing List , Greg Kroah-Hartman , Jens Axboe Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > I don't see that kind of redundancy being a _problem_, though. "So > much redundancy" is just over-stating the issue completely. > > In fact, we often encourage people to split declaration from > initialization exactly because it results in simpler expressions and > more legible code, even if that name is now redundant. So it's a small > extra typing of the type. Big deal. > > The above is also a common pattern that once you know how > container_of() works, it's very legible. > > Sure, if you're new to the kernel, and haven't seen "container_of()" > in other projects, it might initially be a bit of an odd pattern, but > that's the advantage of having one single standardized model: it > becomes a pattern, and you don't have to think about it. > > And particularly with that argument-type pattern, you really have to > work at making over-long lines, since the indentation level will by > definition be just one. > > Looking around, I do see a lot of people doing line-breaks, but that > tends to be when they insist on putting the variable initialization in > the declaration. And even then, it often seems pointless (eg > > struct idp_led *led = container_of(cdev, > struct idp_led, cdev); > > was split for no good reason I can see, but it seems to be a pattern > in that file). > > You really have to pick some pretty excessive type names (or variable > names) to get close to 80 characters. Again, to pick an example: > > struct timer_group_priv *priv = container_of(handle, > struct timer_group_priv, timer[handle->num]); > > ends up being long even if you were to split it, but that funky > container_from() wouldn't have helped the real problem - the fact that > the above is complex and nasty. > An example with a really long member name is +struct nokia_modem_device *modem = from_tasklet(modem, t, + nokia_modem_rst_ind_tasklet); With container_of() one can imagine how long it would end up. And am sure we have many more examples in the kernel. I agree, It would have been simpler to use container_of() as it's been widely used, but as mentioned by Kees, for 1-to-many conversions it does not work well. I guess container_from() is a NAK, if you would want us to just use container_of() to keep the code clean and simple instead of using wrappers, or any other method, we are open to suggestions. Thanks, - Allen