All of lore.kernel.org
 help / color / mirror / Atom feed
From: Allen <allen.lkml@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	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 <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, David Miller <davem@davemloft.net>,
	Jakub Kicinski <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,
	Romain Perier <romain.perier@gmail.com>
Subject: Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
Date: Wed, 19 Aug 2020 16:18:16 +0530	[thread overview]
Message-ID: <CAOMdWSLi-aUeKDN8Xn-X2uW_LmWsp2n=NL3dPGiUbQKm_MxcAg@mail.gmail.com> (raw)
In-Reply-To: <202008181309.FD3940A2D5@keescook>

> > > > > > > >
> > > > > > > > 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?
>

Cool, I shall wait for it to be accepted and then spin out V2 with cast_out()

-- 
       - Allen

WARNING: multiple messages have this Message-ID (diff)
From: Allen <allen.lkml@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	linux-atm-general@lists.sourceforge.net, manohar.vanga@gmail.com,
	airlied@linux.ie, linux-hyperv@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	James Bottomley <James.Bottomley@hansenpartnership.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,
	Jakub Kicinski <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, David Miller <davem@davemloft.net>
Subject: Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
Date: Wed, 19 Aug 2020 16:18:16 +0530	[thread overview]
Message-ID: <CAOMdWSLi-aUeKDN8Xn-X2uW_LmWsp2n=NL3dPGiUbQKm_MxcAg@mail.gmail.com> (raw)
In-Reply-To: <202008181309.FD3940A2D5@keescook>

> > > > > > > >
> > > > > > > > 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?
>

Cool, I shall wait for it to be accepted and then spin out V2 with cast_out()

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

WARNING: multiple messages have this Message-ID (diff)
From: Allen <allen.lkml@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	linux-atm-general@lists.sourceforge.net, manohar.vanga@gmail.com,
	airlied@linux.ie, linux-hyperv@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	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,
	Jakub Kicinski <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, David Miller <davem@davemloft.net>
Subject: Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
Date: Wed, 19 Aug 2020 16:18:16 +0530	[thread overview]
Message-ID: <CAOMdWSLi-aUeKDN8Xn-X2uW_LmWsp2n=NL3dPGiUbQKm_MxcAg@mail.gmail.com> (raw)
In-Reply-To: <202008181309.FD3940A2D5@keescook>

> > > > > > > >
> > > > > > > > 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?
>

Cool, I shall wait for it to be accepted and then spin out V2 with cast_out()

-- 
       - Allen

_______________________________________________
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: Allen <allen.lkml@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	linux-atm-general@lists.sourceforge.net, manohar.vanga@gmail.com,
	airlied@linux.ie, linux-hyperv@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	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,
	Jakub Kicinski <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, David Miller <davem@davemloft.net>
Subject: Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
Date: Wed, 19 Aug 2020 16:18:16 +0530	[thread overview]
Message-ID: <CAOMdWSLi-aUeKDN8Xn-X2uW_LmWsp2n=NL3dPGiUbQKm_MxcAg@mail.gmail.com> (raw)
In-Reply-To: <202008181309.FD3940A2D5@keescook>

> > > > > > > >
> > > > > > > > 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?
>

Cool, I shall wait for it to be accepted and then spin out V2 with cast_out()

-- 
       - Allen
_______________________________________________
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: Allen <allen.lkml@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	linux-atm-general@lists.sourceforge.net, manohar.vanga@gmail.com,
	airlied@linux.ie, linux-hyperv@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	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,
	Jakub Kicinski <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, David Miller <davem@davemloft.net>
Subject: Re: [Intel-gfx] [PATCH] block: convert tasklets to use new tasklet_setup() API
Date: Wed, 19 Aug 2020 16:18:16 +0530	[thread overview]
Message-ID: <CAOMdWSLi-aUeKDN8Xn-X2uW_LmWsp2n=NL3dPGiUbQKm_MxcAg@mail.gmail.com> (raw)
In-Reply-To: <202008181309.FD3940A2D5@keescook>

> > > > > > > >
> > > > > > > > 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?
>

Cool, I shall wait for it to be accepted and then spin out V2 with cast_out()

-- 
       - Allen
_______________________________________________
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: Allen <allen.lkml@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	linux-atm-general@lists.sourceforge.net, manohar.vanga@gmail.com,
	airlied@linux.ie, linux-hyperv@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	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,
	Jakub Kicinski <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, David Miller <davem@davemloft.net>
Subject: Re: [PATCH] block: convert tasklets to use new tasklet_setup() API
Date: Wed, 19 Aug 2020 16:18:16 +0530	[thread overview]
Message-ID: <CAOMdWSLi-aUeKDN8Xn-X2uW_LmWsp2n=NL3dPGiUbQKm_MxcAg@mail.gmail.com> (raw)
In-Reply-To: <202008181309.FD3940A2D5@keescook>

> > > > > > > >
> > > > > > > > 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?
>

Cool, I shall wait for it to be accepted and then spin out V2 with cast_out()

-- 
       - Allen

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


  parent reply	other threads:[~2020-08-19 10:48 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
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 [this message]
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='CAOMdWSLi-aUeKDN8Xn-X2uW_LmWsp2n=NL3dPGiUbQKm_MxcAg@mail.gmail.com' \
    --to=allen.lkml@gmail.com \
    --cc=3chas3@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=airlied@linux.ie \
    --cc=alex.bou9@gmail.com \
    --cc=allen.cryptic@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.