All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Kees Cook <keescook@chromium.org>
Cc: ulf.hansson@linaro.org, linux-atm-general@lists.sourceforge.net,
	manohar.vanga@gmail.com, airlied@linux.ie,
	Allen Pais <allen.lkml@gmail.com>,
	linux-hyperv@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, kys@microsoft.com,
	anton.ivanov@cambridgegreys.com, devel@driverdev.osuosl.org,
	linux-s390@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net, maximlevitsky@gmail.com,
	richard@nod.at, deller@gmx.de, jassisinghbrar@gmail.com,
	3chas3@gmail.com, intel-gfx@lists.freedesktop.org,
	kuba@kernel.org, mporter@kernel.crashing.org, jdike@addtoit.com,
	oakad@yahoo.com, s.hauer@pengutronix.de,
	linux-input@vger.kernel.org, linux-um@lists.infradead.org,
	linux-block@vger.kernel.org, broonie@kernel.org,
	openipmi-developer@lists.sourceforge.net, mitch@sfgoth.com,
	linux-arm-kernel@lists.infradead.org,
	Jens Axboe <axboe@kernel.dk>,
	linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
	martyn@welchs.me.uk, dmitry.torokhov@gmail.com,
	linux-mmc@vger.kernel.org, sre@kernel.org,
	linux-spi@vger.kernel.org, alex.bou9@gmail.com,
	Allen Pais <allen.cryptic@gmail.com>,
	stefanr@s5r6.in-berlin.de, linux-ntb@googlegroups.com,
	Romain Perier <romain.perier@gmail.com>,
	shawnguo@kernel.org, davem@davemloft.net
Subject: Re: [Intel-gfx] [PATCH] block: convert tasklets to use new tasklet_setup() API
Date: Tue, 18 Aug 2020 14:00:38 -0700	[thread overview]
Message-ID: <1597784438.3978.6.camel@HansenPartnership.com> (raw)
In-Reply-To: <202008181309.FD3940A2D5@keescook>

On Tue, 2020-08-18 at 13:10 -0700, Kees Cook wrote:
> On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote:
> > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> > > On 8/17/20 12:48 PM, Kees Cook wrote:
> > > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
> > > > > On 8/17/20 12:29 PM, Kees Cook wrote:
> > > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
> > > > > > > On 8/17/20 2:15 AM, Allen Pais wrote:
> > > > > > > > From: Allen Pais <allen.lkml@gmail.com>
> > > > > > > > 
> > > > > > > > In preparation for unconditionally passing the
> > > > > > > > struct tasklet_struct pointer to all tasklet
> > > > > > > > callbacks, switch to using the new tasklet_setup()
> > > > > > > > and from_tasklet() to pass the tasklet pointer
> > > > > > > > explicitly.
> > > > > > > 
> > > > > > > Who came up with the idea to add a macro 'from_tasklet'
> > > > > > > that
> > > > > > > is just container_of? container_of in the code would be
> > > > > > > _much_ more readable, and not leave anyone guessing wtf
> > > > > > > from_tasklet is doing.
> > > > > > > 
> > > > > > > I'd fix that up now before everything else goes in...
> > > > > > 
> > > > > > As I mentioned in the other thread, I think this makes
> > > > > > things
> > > > > > much more readable. It's the same thing that the
> > > > > > timer_struct
> > > > > > conversion did (added a container_of wrapper) to avoid the
> > > > > > ever-repeating use of typeof(), long lines, etc.
> > > > > 
> > > > > But then it should use a generic name, instead of each sub-
> > > > > system 
> > > > > using some random name that makes people look up exactly what
> > > > > it
> > > > > does. I'm not huge fan of the container_of() redundancy, but
> > > > > adding private variants of this doesn't seem like the best
> > > > > way
> > > > > forward. Let's have a generic helper that does this, and use
> > > > > it
> > > > > everywhere.
> > > > 
> > > > I'm open to suggestions, but as things stand, these kinds of
> > > > treewide
> > > 
> > > On naming? Implementation is just as it stands, from_tasklet() is
> > > totally generic which is why I objected to it. from_member()? Not
> > > great with naming... But I can see this going further and then
> > > we'll
> > > suddenly have tons of these. It's not good for readability.
> > 
> > Since both threads seem to have petered out, let me suggest in
> > kernel.h:
> > 
> > #define cast_out(ptr, container, member) \
> > 	container_of(ptr, typeof(*container), member)
> > 
> > It does what you want, the argument order is the same as
> > container_of with the only difference being you name the containing
> > structure instead of having to specify its type.
> 
> I like this! Shall I send this to Linus to see if this can land in
> -rc2 for use going forward?

Sure ... he's probably been lurking on this thread anyway ... it's
about time he got off his arse^Wthe fence and made an executive
decision ...

James

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Kees Cook <keescook@chromium.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	Allen Pais <allen.cryptic@gmail.com>,
	jdike@addtoit.com, richard@nod.at,
	anton.ivanov@cambridgegreys.com, 3chas3@gmail.com,
	stefanr@s5r6.in-berlin.de, airlied@linux.ie, daniel@ffwll.ch,
	sre@kernel.org, kys@microsoft.com, deller@gmx.de,
	dmitry.torokhov@gmail.com, jassisinghbrar@gmail.com,
	shawnguo@kernel.org, s.hauer@pengutronix.de,
	maximlevitsky@gmail.com, oakad@yahoo.com, ulf.hansson@linaro.org,
	mporter@kernel.crashing.org, alex.bou9@gmail.com,
	broonie@kernel.org, martyn@welchs.me.uk, manohar.vanga@gmail.com,
	mitch@sfgoth.com, davem@davemloft.net, kuba@kernel.org,
	linux-um@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-atm-general@lists.sourceforge.net, netdev@vger.kernel.org,
	linux-block@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	openipmi-developer@lists.sourceforge.net,
	linux1394-devel@lists.sourceforge.net,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-hyperv@vger.kernel.org, linux-parisc@vger.kernel.org,
	linux-input@vger.kernel.org, linux-mmc@vger.kernel.org,
	linux-ntb@googlegroups.com, linux-s390@vger.kernel.org,
	linux-spi@vger.kernel.org, devel@driverdev.osuosl.org,
	Allen Pais <allen.lkml@gmail.com>,
	Romain Perier <romain.perier@gmail.com>
Subject: Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
Date: Tue, 18 Aug 2020 14:00:38 -0700	[thread overview]
Message-ID: <1597784438.3978.6.camel@HansenPartnership.com> (raw)
In-Reply-To: <202008181309.FD3940A2D5@keescook>

On Tue, 2020-08-18 at 13:10 -0700, Kees Cook wrote:
> On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote:
> > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> > > On 8/17/20 12:48 PM, Kees Cook wrote:
> > > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
> > > > > On 8/17/20 12:29 PM, Kees Cook wrote:
> > > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
> > > > > > > On 8/17/20 2:15 AM, Allen Pais wrote:
> > > > > > > > From: Allen Pais <allen.lkml@gmail.com>
> > > > > > > > 
> > > > > > > > In preparation for unconditionally passing the
> > > > > > > > struct tasklet_struct pointer to all tasklet
> > > > > > > > callbacks, switch to using the new tasklet_setup()
> > > > > > > > and from_tasklet() to pass the tasklet pointer
> > > > > > > > explicitly.
> > > > > > > 
> > > > > > > Who came up with the idea to add a macro 'from_tasklet'
> > > > > > > that
> > > > > > > is just container_of? container_of in the code would be
> > > > > > > _much_ more readable, and not leave anyone guessing wtf
> > > > > > > from_tasklet is doing.
> > > > > > > 
> > > > > > > I'd fix that up now before everything else goes in...
> > > > > > 
> > > > > > As I mentioned in the other thread, I think this makes
> > > > > > things
> > > > > > much more readable. It's the same thing that the
> > > > > > timer_struct
> > > > > > conversion did (added a container_of wrapper) to avoid the
> > > > > > ever-repeating use of typeof(), long lines, etc.
> > > > > 
> > > > > But then it should use a generic name, instead of each sub-
> > > > > system 
> > > > > using some random name that makes people look up exactly what
> > > > > it
> > > > > does. I'm not huge fan of the container_of() redundancy, but
> > > > > adding private variants of this doesn't seem like the best
> > > > > way
> > > > > forward. Let's have a generic helper that does this, and use
> > > > > it
> > > > > everywhere.
> > > > 
> > > > I'm open to suggestions, but as things stand, these kinds of
> > > > treewide
> > > 
> > > On naming? Implementation is just as it stands, from_tasklet() is
> > > totally generic which is why I objected to it. from_member()? Not
> > > great with naming... But I can see this going further and then
> > > we'll
> > > suddenly have tons of these. It's not good for readability.
> > 
> > Since both threads seem to have petered out, let me suggest in
> > kernel.h:
> > 
> > #define cast_out(ptr, container, member) \
> > 	container_of(ptr, typeof(*container), member)
> > 
> > It does what you want, the argument order is the same as
> > container_of with the only difference being you name the containing
> > structure instead of having to specify its type.
> 
> I like this! Shall I send this to Linus to see if this can land in
> -rc2 for use going forward?

Sure ... he's probably been lurking on this thread anyway ... it's
about time he got off his arse^Wthe fence and made an executive
decision ...

James


WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Kees Cook <keescook@chromium.org>
Cc: ulf.hansson@linaro.org, linux-atm-general@lists.sourceforge.net,
	manohar.vanga@gmail.com, airlied@linux.ie,
	Allen Pais <allen.lkml@gmail.com>,
	linux-hyperv@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, kys@microsoft.com,
	anton.ivanov@cambridgegreys.com, devel@driverdev.osuosl.org,
	linux-s390@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net, maximlevitsky@gmail.com,
	richard@nod.at, deller@gmx.de, jassisinghbrar@gmail.com,
	3chas3@gmail.com, intel-gfx@lists.freedesktop.org,
	kuba@kernel.org, mporter@kernel.crashing.org, jdike@addtoit.com,
	oakad@yahoo.com, s.hauer@pengutronix.de,
	linux-input@vger.kernel.org, linux-um@lists.infradead.org,
	linux-block@vger.kernel.org, broonie@kernel.org,
	openipmi-developer@lists.sourceforge.net, mitch@sfgoth.com,
	linux-arm-kernel@lists.infradead.org,
	Jens Axboe <axboe@kernel.dk>,
	linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
	martyn@welchs.me.uk, dmitry.torokhov@gmail.com,
	linux-mmc@vger.kernel.org, sre@kernel.org,
	linux-spi@vger.kernel.org, alex.bou9@gmail.com,
	Allen Pais <allen.cryptic@gmail.com>,
	stefanr@s5r6.in-berlin.de, daniel@ffwll.ch,
	linux-ntb@googlegroups.com,
	Romain Perier <romain.perier@gmail.com>,
	shawnguo@kernel.org, davem@davemloft.net
Subject: Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
Date: Tue, 18 Aug 2020 14:00:38 -0700	[thread overview]
Message-ID: <1597784438.3978.6.camel@HansenPartnership.com> (raw)
In-Reply-To: <202008181309.FD3940A2D5@keescook>

On Tue, 2020-08-18 at 13:10 -0700, Kees Cook wrote:
> On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote:
> > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> > > On 8/17/20 12:48 PM, Kees Cook wrote:
> > > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
> > > > > On 8/17/20 12:29 PM, Kees Cook wrote:
> > > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
> > > > > > > On 8/17/20 2:15 AM, Allen Pais wrote:
> > > > > > > > From: Allen Pais <allen.lkml@gmail.com>
> > > > > > > > 
> > > > > > > > In preparation for unconditionally passing the
> > > > > > > > struct tasklet_struct pointer to all tasklet
> > > > > > > > callbacks, switch to using the new tasklet_setup()
> > > > > > > > and from_tasklet() to pass the tasklet pointer
> > > > > > > > explicitly.
> > > > > > > 
> > > > > > > Who came up with the idea to add a macro 'from_tasklet'
> > > > > > > that
> > > > > > > is just container_of? container_of in the code would be
> > > > > > > _much_ more readable, and not leave anyone guessing wtf
> > > > > > > from_tasklet is doing.
> > > > > > > 
> > > > > > > I'd fix that up now before everything else goes in...
> > > > > > 
> > > > > > As I mentioned in the other thread, I think this makes
> > > > > > things
> > > > > > much more readable. It's the same thing that the
> > > > > > timer_struct
> > > > > > conversion did (added a container_of wrapper) to avoid the
> > > > > > ever-repeating use of typeof(), long lines, etc.
> > > > > 
> > > > > But then it should use a generic name, instead of each sub-
> > > > > system 
> > > > > using some random name that makes people look up exactly what
> > > > > it
> > > > > does. I'm not huge fan of the container_of() redundancy, but
> > > > > adding private variants of this doesn't seem like the best
> > > > > way
> > > > > forward. Let's have a generic helper that does this, and use
> > > > > it
> > > > > everywhere.
> > > > 
> > > > I'm open to suggestions, but as things stand, these kinds of
> > > > treewide
> > > 
> > > On naming? Implementation is just as it stands, from_tasklet() is
> > > totally generic which is why I objected to it. from_member()? Not
> > > great with naming... But I can see this going further and then
> > > we'll
> > > suddenly have tons of these. It's not good for readability.
> > 
> > Since both threads seem to have petered out, let me suggest in
> > kernel.h:
> > 
> > #define cast_out(ptr, container, member) \
> > 	container_of(ptr, typeof(*container), member)
> > 
> > It does what you want, the argument order is the same as
> > container_of with the only difference being you name the containing
> > structure instead of having to specify its type.
> 
> I like this! Shall I send this to Linus to see if this can land in
> -rc2 for use going forward?

Sure ... he's probably been lurking on this thread anyway ... it's
about time he got off his arse^Wthe fence and made an executive
decision ...

James


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Kees Cook <keescook@chromium.org>
Cc: ulf.hansson@linaro.org, linux-atm-general@lists.sourceforge.net,
	manohar.vanga@gmail.com, airlied@linux.ie,
	Allen Pais <allen.lkml@gmail.com>,
	linux-hyperv@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, kys@microsoft.com,
	anton.ivanov@cambridgegreys.com, devel@driverdev.osuosl.org,
	linux-s390@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net, maximlevitsky@gmail.com,
	richard@nod.at, deller@gmx.de, jassisinghbrar@gmail.com,
	3chas3@gmail.com, intel-gfx@lists.freedesktop.org,
	kuba@kernel.org, mporter@kernel.crashing.org, jdike@addtoit.com,
	oakad@yahoo.com, s.hauer@pengutronix.de,
	linux-input@vger.kernel.org, linux-um@lists.infradead.org,
	linux-block@vger.kernel.org, broonie@kernel.org,
	openipmi-developer@lists.sourceforge.net, mitch@sfgoth.com,
	linux-arm-kernel@lists.infradead.org,
	Jens Axboe <axboe@kernel.dk>,
	linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
	martyn@welchs.me.uk, dmitry.torokhov@gmail.com,
	linux-mmc@vger.kernel.org, sre@kernel.org,
	linux-spi@vger.kernel.org, alex.bou9@gmail.com,
	Allen Pais <allen.cryptic@gmail.com>,
	stefanr@s5r6.in-berlin.de, daniel@ffwll.ch,
	linux-ntb@googlegroups.com,
	Romain Perier <romain.perier@gmail.com>,
	shawnguo@kernel.org, davem@davemloft.net
Subject: Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
Date: Tue, 18 Aug 2020 14:00:38 -0700	[thread overview]
Message-ID: <1597784438.3978.6.camel@HansenPartnership.com> (raw)
In-Reply-To: <202008181309.FD3940A2D5@keescook>

On Tue, 2020-08-18 at 13:10 -0700, Kees Cook wrote:
> On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote:
> > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> > > On 8/17/20 12:48 PM, Kees Cook wrote:
> > > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
> > > > > On 8/17/20 12:29 PM, Kees Cook wrote:
> > > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
> > > > > > > On 8/17/20 2:15 AM, Allen Pais wrote:
> > > > > > > > From: Allen Pais <allen.lkml@gmail.com>
> > > > > > > > 
> > > > > > > > In preparation for unconditionally passing the
> > > > > > > > struct tasklet_struct pointer to all tasklet
> > > > > > > > callbacks, switch to using the new tasklet_setup()
> > > > > > > > and from_tasklet() to pass the tasklet pointer
> > > > > > > > explicitly.
> > > > > > > 
> > > > > > > Who came up with the idea to add a macro 'from_tasklet'
> > > > > > > that
> > > > > > > is just container_of? container_of in the code would be
> > > > > > > _much_ more readable, and not leave anyone guessing wtf
> > > > > > > from_tasklet is doing.
> > > > > > > 
> > > > > > > I'd fix that up now before everything else goes in...
> > > > > > 
> > > > > > As I mentioned in the other thread, I think this makes
> > > > > > things
> > > > > > much more readable. It's the same thing that the
> > > > > > timer_struct
> > > > > > conversion did (added a container_of wrapper) to avoid the
> > > > > > ever-repeating use of typeof(), long lines, etc.
> > > > > 
> > > > > But then it should use a generic name, instead of each sub-
> > > > > system 
> > > > > using some random name that makes people look up exactly what
> > > > > it
> > > > > does. I'm not huge fan of the container_of() redundancy, but
> > > > > adding private variants of this doesn't seem like the best
> > > > > way
> > > > > forward. Let's have a generic helper that does this, and use
> > > > > it
> > > > > everywhere.
> > > > 
> > > > I'm open to suggestions, but as things stand, these kinds of
> > > > treewide
> > > 
> > > On naming? Implementation is just as it stands, from_tasklet() is
> > > totally generic which is why I objected to it. from_member()? Not
> > > great with naming... But I can see this going further and then
> > > we'll
> > > suddenly have tons of these. It's not good for readability.
> > 
> > Since both threads seem to have petered out, let me suggest in
> > kernel.h:
> > 
> > #define cast_out(ptr, container, member) \
> > 	container_of(ptr, typeof(*container), member)
> > 
> > It does what you want, the argument order is the same as
> > container_of with the only difference being you name the containing
> > structure instead of having to specify its type.
> 
> I like this! Shall I send this to Linus to see if this can land in
> -rc2 for use going forward?

Sure ... he's probably been lurking on this thread anyway ... it's
about time he got off his arse^Wthe fence and made an executive
decision ...

James


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Kees Cook <keescook@chromium.org>
Cc: ulf.hansson@linaro.org, linux-atm-general@lists.sourceforge.net,
	manohar.vanga@gmail.com, airlied@linux.ie,
	Allen Pais <allen.lkml@gmail.com>,
	linux-hyperv@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, kys@microsoft.com,
	anton.ivanov@cambridgegreys.com, devel@driverdev.osuosl.org,
	linux-s390@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net, maximlevitsky@gmail.com,
	richard@nod.at, deller@gmx.de, jassisinghbrar@gmail.com,
	3chas3@gmail.com, intel-gfx@lists.freedesktop.org,
	kuba@kernel.org, mporter@kernel.crashing.org, jdike@addtoit.com,
	oakad@yahoo.com, s.hauer@pengutronix.de,
	linux-input@vger.kernel.org, linux-um@lists.infradead.org,
	linux-block@vger.kernel.org, broonie@kernel.org,
	openipmi-developer@lists.sourceforge.net, mitch@sfgoth.com,
	linux-arm-kernel@lists.infradead.org,
	Jens Axboe <axboe@kernel.dk>,
	linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
	martyn@welchs.me.uk, dmitry.torokhov@gmail.com,
	linux-mmc@vger.kernel.org, sre@kernel.org,
	linux-spi@vger.kernel.org, alex.bou9@gmail.com,
	Allen Pais <allen.cryptic@gmail.com>,
	stefanr@s5r6.in-berlin.de, linux-ntb@googlegroups.com,
	Romain Perier <romain.perier@gmail.com>,
	shawnguo@kernel.org, davem@davemloft.net
Subject: Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
Date: Tue, 18 Aug 2020 14:00:38 -0700	[thread overview]
Message-ID: <1597784438.3978.6.camel@HansenPartnership.com> (raw)
In-Reply-To: <202008181309.FD3940A2D5@keescook>

On Tue, 2020-08-18 at 13:10 -0700, Kees Cook wrote:
> On Tue, Aug 18, 2020 at 01:00:33PM -0700, James Bottomley wrote:
> > On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
> > > On 8/17/20 12:48 PM, Kees Cook wrote:
> > > > On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
> > > > > On 8/17/20 12:29 PM, Kees Cook wrote:
> > > > > > On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
> > > > > > > On 8/17/20 2:15 AM, Allen Pais wrote:
> > > > > > > > From: Allen Pais <allen.lkml@gmail.com>
> > > > > > > > 
> > > > > > > > In preparation for unconditionally passing the
> > > > > > > > struct tasklet_struct pointer to all tasklet
> > > > > > > > callbacks, switch to using the new tasklet_setup()
> > > > > > > > and from_tasklet() to pass the tasklet pointer
> > > > > > > > explicitly.
> > > > > > > 
> > > > > > > Who came up with the idea to add a macro 'from_tasklet'
> > > > > > > that
> > > > > > > is just container_of? container_of in the code would be
> > > > > > > _much_ more readable, and not leave anyone guessing wtf
> > > > > > > from_tasklet is doing.
> > > > > > > 
> > > > > > > I'd fix that up now before everything else goes in...
> > > > > > 
> > > > > > As I mentioned in the other thread, I think this makes
> > > > > > things
> > > > > > much more readable. It's the same thing that the
> > > > > > timer_struct
> > > > > > conversion did (added a container_of wrapper) to avoid the
> > > > > > ever-repeating use of typeof(), long lines, etc.
> > > > > 
> > > > > But then it should use a generic name, instead of each sub-
> > > > > system 
> > > > > using some random name that makes people look up exactly what
> > > > > it
> > > > > does. I'm not huge fan of the container_of() redundancy, but
> > > > > adding private variants of this doesn't seem like the best
> > > > > way
> > > > > forward. Let's have a generic helper that does this, and use
> > > > > it
> > > > > everywhere.
> > > > 
> > > > I'm open to suggestions, but as things stand, these kinds of
> > > > treewide
> > > 
> > > On naming? Implementation is just as it stands, from_tasklet() is
> > > totally generic which is why I objected to it. from_member()? Not
> > > great with naming... But I can see this going further and then
> > > we'll
> > > suddenly have tons of these. It's not good for readability.
> > 
> > Since both threads seem to have petered out, let me suggest in
> > kernel.h:
> > 
> > #define cast_out(ptr, container, member) \
> > 	container_of(ptr, typeof(*container), member)
> > 
> > It does what you want, the argument order is the same as
> > container_of with the only difference being you name the containing
> > structure instead of having to specify its type.
> 
> I like this! Shall I send this to Linus to see if this can land in
> -rc2 for use going forward?

Sure ... he's probably been lurking on this thread anyway ... it's
about time he got off his arse^Wthe fence and made an executive
decision ...

James

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-08-18 21:00 UTC|newest]

Thread overview: 198+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-17  9:15 [Intel-gfx] [PATCH] arch: um: convert tasklets to use new tasklet_setup() API Allen Pais
2020-08-17  9:15 ` Allen Pais
2020-08-17  9:15 ` Allen Pais
2020-08-17  9:15 ` Allen Pais
2020-08-17  9:15 ` [Intel-gfx] [PATCH] block: " Allen Pais
2020-08-17  9:15   ` Allen Pais
2020-08-17  9:15   ` Allen Pais
2020-08-17  9:15   ` Allen Pais
2020-08-17 13:56   ` [Intel-gfx] " Jens Axboe
2020-08-17 13:56     ` Jens Axboe
2020-08-17 13:56     ` Jens Axboe
2020-08-17 13:56     ` Jens Axboe
2020-08-17 13:56     ` Jens Axboe
2020-08-17 19:29     ` [Intel-gfx] " Kees Cook
2020-08-17 19:29       ` Kees Cook
2020-08-17 19:29       ` Kees Cook
2020-08-17 19:29       ` Kees Cook
2020-08-17 19:44       ` [Intel-gfx] " Jens Axboe
2020-08-17 19:44         ` Jens Axboe
2020-08-17 19:44         ` Jens Axboe
2020-08-17 19:44         ` Jens Axboe
2020-08-17 19:44         ` Jens Axboe
2020-08-17 19:48         ` [Intel-gfx] " Kees Cook
2020-08-17 19:48           ` Kees Cook
2020-08-17 19:48           ` Kees Cook
2020-08-17 19:48           ` Kees Cook
2020-08-17 20:02           ` [Intel-gfx] " Jens Axboe
2020-08-17 20:02             ` Jens Axboe
2020-08-17 20:02             ` Jens Axboe
2020-08-17 20:02             ` Jens Axboe
2020-08-17 20:02             ` Jens Axboe
2020-08-18 20:00             ` [Intel-gfx] " James Bottomley
2020-08-18 20:00               ` James Bottomley
2020-08-18 20:00               ` James Bottomley
2020-08-18 20:00               ` James Bottomley
2020-08-18 20:00               ` James Bottomley
2020-08-18 20:10               ` [Intel-gfx] " Kees Cook
2020-08-18 20:10                 ` Kees Cook
2020-08-18 20:10                 ` Kees Cook
2020-08-18 20:10                 ` Kees Cook
2020-08-18 21:00                 ` James Bottomley [this message]
2020-08-18 21:00                   ` James Bottomley
2020-08-18 21:00                   ` James Bottomley
2020-08-18 21:00                   ` James Bottomley
2020-08-18 21:00                   ` James Bottomley
2020-08-19 10:48                 ` [Intel-gfx] " Allen
2020-08-19 10:48                   ` Allen
2020-08-19 10:48                   ` Allen
2020-08-19 10:48                   ` Allen
2020-08-19 10:48                   ` Allen
2020-08-19 13:00               ` [Intel-gfx] " Jens Axboe
2020-08-19 13:00                 ` Jens Axboe
2020-08-19 13:00                 ` Jens Axboe
2020-08-19 13:00                 ` Jens Axboe
2020-08-19 13:00                 ` Jens Axboe
2020-08-19 13:11                 ` [Intel-gfx] " Greg KH
2020-08-19 13:11                   ` Greg KH
2020-08-19 13:11                   ` Greg KH
2020-08-19 13:11                   ` Greg KH
2020-08-19 13:11                   ` Greg KH
2020-08-19 13:17                   ` [Intel-gfx] " Jens Axboe
2020-08-19 13:17                     ` Jens Axboe
2020-08-19 13:17                     ` Jens Axboe
2020-08-19 13:17                     ` Jens Axboe
2020-08-19 13:17                     ` Jens Axboe
2020-08-19 13:30                     ` [Intel-gfx] " Greg KH
2020-08-19 13:30                       ` Greg KH
2020-08-19 13:30                       ` Greg KH
2020-08-19 13:30                       ` Greg KH
2020-08-19 13:30                       ` Greg KH
2020-08-19 14:59                 ` [Intel-gfx] " James Bottomley
2020-08-19 14:59                   ` James Bottomley
2020-08-19 14:59                   ` James Bottomley
2020-08-19 14:59                   ` James Bottomley
2020-08-19 14:59                   ` James Bottomley
2020-08-19 16:24                   ` [Intel-gfx] " Allen
2020-08-19 16:24                     ` Allen
2020-08-19 16:24                     ` Allen
2020-08-19 16:24                     ` Allen
2020-08-19 16:24                     ` Allen
2020-08-19 16:56                     ` [Intel-gfx] " Jens Axboe
2020-08-19 16:56                       ` Jens Axboe
2020-08-19 16:56                       ` Jens Axboe
2020-08-19 16:56                       ` Jens Axboe
2020-08-19 16:56                       ` Jens Axboe
2020-08-19 21:39                     ` [Intel-gfx] " James Bottomley
2020-08-19 21:39                       ` James Bottomley
2020-08-19 21:39                       ` James Bottomley
2020-08-19 21:39                       ` James Bottomley
2020-08-19 21:39                       ` James Bottomley
2020-08-26  1:51                       ` [Intel-gfx] " Allen Pais
2020-08-26  1:51                         ` Allen Pais
2020-08-26  1:51                         ` Allen Pais
2020-08-26  1:51                         ` Allen Pais
2020-08-26  1:51                         ` Allen Pais
2020-08-26  9:55                         ` [Intel-gfx] " Dan Carpenter
2020-08-26  9:55                           ` Dan Carpenter
2020-08-26  9:55                           ` Dan Carpenter
2020-08-26  9:55                           ` Dan Carpenter
2020-08-26  9:55                           ` Dan Carpenter
2020-08-26 15:13                           ` [Intel-gfx] " Kees Cook
2020-08-26 15:13                             ` Kees Cook
2020-08-26 15:13                             ` Kees Cook
2020-08-26 15:13                             ` Kees Cook
2020-08-27  1:37                             ` [Intel-gfx] " Allen
2020-08-27  1:37                               ` Allen
2020-08-27  1:37                               ` Allen
2020-08-27  1:37                               ` Allen
2020-08-27  1:37                               ` Allen
2020-08-17  9:15 ` [Intel-gfx] [PATCH] char: ipmi: " Allen Pais
2020-08-17  9:15   ` Allen Pais
2020-08-17  9:15   ` Allen Pais
2020-08-17  9:15   ` Allen Pais
2020-08-17 12:15   ` [Intel-gfx] " Corey Minyard
2020-08-17 12:15     ` Corey Minyard
2020-08-17 12:15     ` Corey Minyard
2020-08-17 12:15     ` Corey Minyard
2020-08-17 12:15     ` Corey Minyard
2020-08-18  9:16     ` [Intel-gfx] " Allen
2020-08-18  9:16       ` Allen
2020-08-18  9:16       ` Allen
2020-08-18  9:16       ` Allen
2020-08-18  9:16       ` Allen
2020-08-18 11:32       ` [Intel-gfx] " Corey Minyard
2020-08-18 11:32         ` Corey Minyard
2020-08-18 11:32         ` Corey Minyard
2020-08-18 11:32         ` Corey Minyard
2020-08-18 11:32         ` Corey Minyard
2020-08-17  9:15 ` [Intel-gfx] [PATCH] driver: hv: " Allen Pais
2020-08-17  9:15   ` Allen Pais
2020-08-17  9:15   ` Allen Pais
2020-08-17  9:15   ` Allen Pais
2020-08-17  9:15 ` [Intel-gfx] [PATCH] drivers: atm: " Allen Pais
2020-08-17  9:15   ` Allen Pais
2020-08-17  9:15   ` Allen Pais
2020-08-17  9:15   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH] drivers: ntb: " Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH] drivers: rapidio: " Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH] drivers: s390: " Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH] drivers: vme: " Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH] drm: i915: " Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH] firewire: ohci: " Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH 1/2] hsi: nokia-modem: " Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH] input: serio: " Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH 1/2] mailbox: bcm: " Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH 1/2] memstick: jmb38x: " Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH 1/2] misc: ibmvmc: " Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH] net: atm: convert tasklets callbacks to use from_tasklet() Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16 ` [Intel-gfx] [PATCH] platform: goldfish: convert tasklets to use new tasklet_setup() API Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-08-17  9:16   ` Allen Pais
2020-10-18 21:50 ` [Intel-gfx] [PATCH] arch: um: " Richard Weinberger
2020-10-18 21:50   ` Richard Weinberger
2020-10-18 21:50   ` Richard Weinberger
2020-10-18 21:50   ` Richard Weinberger
     [not found]   ` <7307c1ca-696f-060d-78a2-d4bf05221e71@cambridgegreys.com>
2020-10-19  8:26     ` Fwd: " Anton Ivanov
2020-10-19 20:55       ` Richard Weinberger
2020-10-19  7:39 ` [Intel-gfx] " Anton Ivanov
2020-10-19  7:39   ` Anton Ivanov
2020-10-19  7:39   ` Anton Ivanov
2020-10-19  7:39   ` Anton Ivanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1597784438.3978.6.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=3chas3@gmail.com \
    --cc=airlied@linux.ie \
    --cc=alex.bou9@gmail.com \
    --cc=allen.cryptic@gmail.com \
    --cc=allen.lkml@gmail.com \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=axboe@kernel.dk \
    --cc=broonie@kernel.org \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --cc=devel@driverdev.osuosl.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=jdike@addtoit.com \
    --cc=keescook@chromium.org \
    --cc=kuba@kernel.org \
    --cc=kys@microsoft.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-atm-general@lists.sourceforge.net \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-ntb@googlegroups.com \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=manohar.vanga@gmail.com \
    --cc=martyn@welchs.me.uk \
    --cc=maximlevitsky@gmail.com \
    --cc=mitch@sfgoth.com \
    --cc=mporter@kernel.crashing.org \
    --cc=netdev@vger.kernel.org \
    --cc=oakad@yahoo.com \
    --cc=openipmi-developer@lists.sourceforge.net \
    --cc=richard@nod.at \
    --cc=romain.perier@gmail.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=sre@kernel.org \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.