All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jens Axboe <axboe@kernel.dk>, Kees Cook <keescook@chromium.org>
Cc: 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 13:00:33 -0700	[thread overview]
Message-ID: <1597780833.3978.3.camel@HansenPartnership.com> (raw)
In-Reply-To: <df645c06-c30b-eafa-4d23-826b84f2ff48@kernel.dk>

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.

James


WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jens Axboe <axboe@kernel.dk>, 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, 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,
	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 13:00:33 -0700	[thread overview]
Message-ID: <1597780833.3978.3.camel@HansenPartnership.com> (raw)
In-Reply-To: <df645c06-c30b-eafa-4d23-826b84f2ff48@kernel.dk>

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.

James

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jens Axboe <axboe@kernel.dk>, 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,
	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 13:00:33 -0700	[thread overview]
Message-ID: <1597780833.3978.3.camel@HansenPartnership.com> (raw)
In-Reply-To: <df645c06-c30b-eafa-4d23-826b84f2ff48@kernel.dk>

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.

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: Jens Axboe <axboe@kernel.dk>, 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,
	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 13:00:33 -0700	[thread overview]
Message-ID: <1597780833.3978.3.camel@HansenPartnership.com> (raw)
In-Reply-To: <df645c06-c30b-eafa-4d23-826b84f2ff48@kernel.dk>

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.

James

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

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jens Axboe <axboe@kernel.dk>, 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,
	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 13:00:33 -0700	[thread overview]
Message-ID: <1597780833.3978.3.camel@HansenPartnership.com> (raw)
In-Reply-To: <df645c06-c30b-eafa-4d23-826b84f2ff48@kernel.dk>

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.

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: Jens Axboe <axboe@kernel.dk>, 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,
	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 13:00:33 -0700	[thread overview]
Message-ID: <1597780833.3978.3.camel@HansenPartnership.com> (raw)
In-Reply-To: <df645c06-c30b-eafa-4d23-826b84f2ff48@kernel.dk>

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.

James


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


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

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