From: Allen Pais <hidden> Date: 2020-08-17 09:16:45
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
arch/um/drivers/vector_kern.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:16:59
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/block/umem.c | 6 +++---
drivers/block/xsysace.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
@@ -405,7 +405,7 @@ static int add_bio(struct cardinfo *card)return1;}-staticvoidprocess_page(unsignedlongdata)+staticvoidprocess_page(structtasklet_struct*t){/* check if any of the requests in the page are DMA_COMPLETE,*anddealwiththemappropriately.
@@ -415,7 +415,7 @@ static void process_page(unsigned long data)*/structmm_page*page;structbio*return_bio=NULL;-structcardinfo*card=(structcardinfo*)data;+structcardinfo*card=from_tasklet(card,t,tasklet);unsignedintdma_status=card->dma_status;spin_lock(&card->lock);
From: Allen Pais <hidden> Date: 2020-08-17 09:17:11
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/char/ipmi/ipmi_msghandler.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:17:26
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/hv/channel_mgmt.c | 3 +--
drivers/hv/connection.c | 4 ++--
drivers/hv/hv.c | 3 +--
drivers/hv/hyperv_vmbus.h | 4 ++--
drivers/hv/vmbus_drv.c | 4 ++--
5 files changed, 8 insertions(+), 10 deletions(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:17:39
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/atm/eni.c | 9 +++++----
drivers/atm/fore200e.c | 14 +++++++-------
drivers/atm/he.c | 8 ++++----
drivers/atm/solos-pci.c | 8 ++++----
4 files changed, 20 insertions(+), 19 deletions(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:17:50
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/ntb/ntb_transport.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:18:03
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/rapidio/devices/tsi721_dma.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
@@ -230,10 +230,10 @@ static inline void ctcmpc_dump32(char *buf, int len)intctcmpc_open(structnet_device*);voidctcm_ccw_check_rc(structchannel*,int,char*);-voidmpc_group_ready(unsignedlongadev);+voidmpc_group_ready(structtasklet_struct*t);voidmpc_channel_action(structchannel*ch,intdirection,intaction);-voidmpc_action_send_discontact(unsignedlongthischan);+voidmpc_action_send_discontact(structtasklet_struct*t);voidmpc_action_discontact(fsm_instance*fi,intevent,void*arg);-voidctcmpc_bh(unsignedlongthischan);+voidctcmpc_bh(structtasklet_struct*t);#endif/* --- This is the END my friend --- */
From: Allen Pais <hidden> Date: 2020-08-17 09:18:32
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/vme/bridges/vme_fake.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:18:45
From: Allen Pais <redacted>
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
and remove the .data field.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 31 ++++++++++---------
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 +++--
2 files changed, 22 insertions(+), 17 deletions(-)
@@ -4306,9 +4307,10 @@ static void execlists_reset_rewind(struct intel_engine_cs *engine, bool stalled)spin_unlock_irqrestore(&engine->active.lock,flags);}-staticvoidnop_submission_tasklet(unsignedlongdata)+staticvoidnop_submission_tasklet(structtasklet_struct*t){-structintel_engine_cs*constengine=(structintel_engine_cs*)data;+structintel_engine_cs*constengine=from_tasklet(engine,t,+execlists.tasklet);/* The driver is wedged; don't process any more events. */WRITE_ONCE(engine->execlists.queue_priority_hint,INT_MIN);
@@ -591,7 +592,8 @@ static void guc_set_default_submission(struct intel_engine_cs *engine)*/intel_execlists_set_default_submission(engine);-engine->execlists.tasklet.func=guc_submission_tasklet;+engine->execlists.tasklet.func=+(void(*)(unsignedlong))guc_submission_tasklet;/* do not use execlists park/unpark */engine->park=engine->unpark=NULL;
From: Allen Pais <hidden> Date: 2020-08-17 09:19:00
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/firewire/ohci.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:19:11
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/hsi/clients/nokia-modem.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:19:21
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/input/serio/hp_sdc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:19:38
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/mailbox/bcm-pdc-mailbox.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:19:50
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/memstick/host/jmb38x_ms.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:20:06
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/misc/ibmvmc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:20:22
From: Allen Pais <redacted>
Update all the callbacks of all tasklets by using
from_tasklet() and remove .data field.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
net/atm/pppoatm.c | 1 -
1 file changed, 1 deletion(-)
From: Allen Pais <hidden> Date: 2020-08-17 09:20:47
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
drivers/platform/goldfish/goldfish_pipe.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
@@ -577,10 +577,10 @@ static struct goldfish_pipe *signalled_pipes_pop_front(returnpipe;}-staticvoidgoldfish_interrupt_task(unsignedlongdev_addr)+staticvoidgoldfish_interrupt_task(structtasklet_struct*t){/* Iterate over the signalled pipes and wake them one by one */-structgoldfish_pipe_dev*dev=(structgoldfish_pipe_dev*)dev_addr;+structgoldfish_pipe_dev*dev=from_tasklet(dev,t,irq_tasklet);structgoldfish_pipe*pipe;intwakes;
@@ -811,8 +811,7 @@ static int goldfish_pipe_device_init(struct platform_device *pdev,{interr;-tasklet_init(&dev->irq_tasklet,&goldfish_interrupt_task,-(unsignedlong)dev);+tasklet_setup(&dev->irq_tasklet,&goldfish_interrupt_task);err=devm_request_irq(&pdev->dev,dev->irq,goldfish_pipe_interrupt,
On Mon, Aug 17, 2020 at 02:45:57PM +0530, Allen Pais wrote:
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
This looks good to me.
Reviewed-by: Corey Minyard <redacted>
Are you planning to push this, or do you want me to take it? If you
want me to take it, what is the urgency?
-corey
From: Allen Pais <redacted>
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...
--
Jens Axboe
On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
On 8/17/20 2:15 AM, Allen Pais wrote:
quoted
From: Allen Pais <redacted>
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.
--
Kees Cook
On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
quoted
On 8/17/20 2:15 AM, Allen Pais wrote:
quoted
From: Allen Pais <redacted>
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.
--
Jens Axboe
On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
On 8/17/20 12:29 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
quoted
On 8/17/20 2:15 AM, Allen Pais wrote:
quoted
From: Allen Pais <redacted>
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
changes end up getting whole-release delays because of the need to have
the API in place for everyone before patches to do the changes can be
sent to multiple maintainers, etc.
--
Kees Cook
On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:29 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
quoted
On 8/17/20 2:15 AM, Allen Pais wrote:
quoted
From: Allen Pais <redacted>
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.
changes end up getting whole-release delays because of the need to have
the API in place for everyone before patches to do the changes can be
sent to multiple maintainers, etc.
Sure, that's always true of treewide changes like that.
--
Jens Axboe
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
This looks good to me.
Reviewed-by: Corey Minyard <redacted>
Are you planning to push this, or do you want me to take it? If you
want me to take it, what is the urgency?
Thanks. Well, not hurry, as long as it goes into 5.9 with all other
changes.
On Tue, Aug 18, 2020 at 02:46:23PM +0530, Allen wrote:
quoted
quoted
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
This looks good to me.
Reviewed-by: Corey Minyard <redacted>
Are you planning to push this, or do you want me to take it? If you
want me to take it, what is the urgency?
Thanks. Well, not hurry, as long as it goes into 5.9 with all other
changes.
From: James Bottomley <James.Bottomley@HansenPartnership.com> Date: 2020-08-18 20:00:46
On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
On 8/17/20 12:48 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:29 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
quoted
On 8/17/20 2:15 AM, Allen Pais wrote:
quoted
From: Allen Pais <redacted>
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
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:
quoted
On 8/17/20 12:48 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:29 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
quoted
On 8/17/20 2:15 AM, Allen Pais wrote:
quoted
From: Allen Pais <redacted>
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?
--
Kees Cook
From: James Bottomley <James.Bottomley@HansenPartnership.com> Date: 2020-08-18 21:00:52
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:
quoted
On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:48 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:29 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
quoted
On 8/17/20 2:15 AM, Allen Pais wrote:
quoted
From: Allen Pais <redacted>
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
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
On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:48 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:29 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
quoted
On 8/17/20 2:15 AM, Allen Pais wrote:
quoted
From: Allen Pais <redacted>
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.
Not to incessantly bike shed on the naming, but I don't like cast_out,
it's not very descriptive. And it has connotations of getting rid of
something, which isn't really true.
FWIW, I like the from_ part of the original naming, as it has some clues
as to what is being done here. Why not just from_container()? That
should immediately tell people what it does without having to look up
the implementation, even before this becomes a part of the accepted
coding norm.
--
Jens Axboe
On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote:
On 8/18/20 1:00 PM, James Bottomley wrote:
quoted
On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:48 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:29 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
quoted
On 8/17/20 2:15 AM, Allen Pais wrote:
quoted
From: Allen Pais <redacted>
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.
Not to incessantly bike shed on the naming, but I don't like cast_out,
it's not very descriptive. And it has connotations of getting rid of
something, which isn't really true.
I agree, if we want to bike shed, I don't like this color either.
FWIW, I like the from_ part of the original naming, as it has some clues
as to what is being done here. Why not just from_container()? That
should immediately tell people what it does without having to look up
the implementation, even before this becomes a part of the accepted
coding norm.
Why are people hating on the well-known and used container_of()?
If you really hate to type the type and want a new macro, what about
'container_from()'? (noun/verb is nicer to sort symbols by...)
But really, why is this even needed?
thanks,
greg k-h
On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote:
quoted
On 8/18/20 1:00 PM, James Bottomley wrote:
quoted
On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:48 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:29 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
quoted
On 8/17/20 2:15 AM, Allen Pais wrote:
quoted
From: Allen Pais <redacted>
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.
Not to incessantly bike shed on the naming, but I don't like cast_out,
it's not very descriptive. And it has connotations of getting rid of
something, which isn't really true.
I agree, if we want to bike shed, I don't like this color either.
quoted
FWIW, I like the from_ part of the original naming, as it has some clues
as to what is being done here. Why not just from_container()? That
should immediately tell people what it does without having to look up
the implementation, even before this becomes a part of the accepted
coding norm.
Why are people hating on the well-known and used container_of()?
If you really hate to type the type and want a new macro, what about
'container_from()'? (noun/verb is nicer to sort symbols by...)
But really, why is this even needed?
container_from() or from_container(), either works just fine for me
in terms of naming.
I think people are hating on it because it makes for _really_ long
lines, and it's arguably cleaner/simpler to just pass in the pointer
type instead. Then you end up with lines like this:
struct request_queue *q =
container_of(work, struct request_queue, requeue_work.work);
But I'm not the one that started this addition of from_tasklet(), my
objection was adding a private macro for something that should be
generic functionality. Hence I think we either need to provide that, or
tell the from_tasklet() folks that they should just use container_of().
--
Jens Axboe
On Wed, Aug 19, 2020 at 07:17:19AM -0600, Jens Axboe wrote:
On 8/19/20 6:11 AM, Greg KH wrote:
quoted
On Wed, Aug 19, 2020 at 07:00:53AM -0600, Jens Axboe wrote:
quoted
On 8/18/20 1:00 PM, James Bottomley wrote:
quoted
On Mon, 2020-08-17 at 13:02 -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:48 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 12:44:34PM -0700, Jens Axboe wrote:
quoted
On 8/17/20 12:29 PM, Kees Cook wrote:
quoted
On Mon, Aug 17, 2020 at 06:56:47AM -0700, Jens Axboe wrote:
quoted
On 8/17/20 2:15 AM, Allen Pais wrote:
quoted
From: Allen Pais <redacted>
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.
Not to incessantly bike shed on the naming, but I don't like cast_out,
it's not very descriptive. And it has connotations of getting rid of
something, which isn't really true.
I agree, if we want to bike shed, I don't like this color either.
quoted
FWIW, I like the from_ part of the original naming, as it has some clues
as to what is being done here. Why not just from_container()? That
should immediately tell people what it does without having to look up
the implementation, even before this becomes a part of the accepted
coding norm.
Why are people hating on the well-known and used container_of()?
If you really hate to type the type and want a new macro, what about
'container_from()'? (noun/verb is nicer to sort symbols by...)
But really, why is this even needed?
container_from() or from_container(), either works just fine for me
in terms of naming.
I think people are hating on it because it makes for _really_ long
lines, and it's arguably cleaner/simpler to just pass in the pointer
type instead. Then you end up with lines like this:
struct request_queue *q =
container_of(work, struct request_queue, requeue_work.work);
But I'm not the one that started this addition of from_tasklet(), my
objection was adding a private macro for something that should be
generic functionality.
Agreed.
Hence I think we either need to provide that, or
tell the from_tasklet() folks that they should just use container_of().
From: James Bottomley <James.Bottomley@HansenPartnership.com> Date: 2020-08-19 14:59:58
On Wed, 2020-08-19 at 07:00 -0600, Jens Axboe wrote:
On 8/18/20 1:00 PM, James Bottomley wrote:
[...]
quoted
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.
Not to incessantly bike shed on the naming, but I don't like
cast_out, it's not very descriptive. And it has connotations of
getting rid of something, which isn't really true.
Um, I thought it was exactly descriptive: you're casting to the outer
container. I thought about following the C++ dynamic casting style, so
out_cast(), but that seemed a bit pejorative. What about outer_cast()?
FWIW, I like the from_ part of the original naming, as it has some
clues as to what is being done here. Why not just from_container()?
That should immediately tell people what it does without having to
look up the implementation, even before this becomes a part of the
accepted coding norm.
I'm not opposed to container_from() but it seems a little less
descriptive than outer_cast() but I don't really care. I always have
to look up container_of() when I'm using it so this would just be
another macro of that type ...
James
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.
Not to incessantly bike shed on the naming, but I don't like
cast_out, it's not very descriptive. And it has connotations of
getting rid of something, which isn't really true.
Um, I thought it was exactly descriptive: you're casting to the outer
container. I thought about following the C++ dynamic casting style, so
out_cast(), but that seemed a bit pejorative. What about outer_cast()?
quoted
FWIW, I like the from_ part of the original naming, as it has some
clues as to what is being done here. Why not just from_container()?
That should immediately tell people what it does without having to
look up the implementation, even before this becomes a part of the
accepted coding norm.
I'm not opposed to container_from() but it seems a little less
descriptive than outer_cast() but I don't really care. I always have
to look up container_of() when I'm using it so this would just be
another macro of that type ...
So far we have a few which have been suggested as replacement
for from_tasklet()
- out_cast() or outer_cast()
- from_member().
- container_from() or from_container()
from_container() sounds fine, would trimming it a bit work? like from_cont().
--
- Allen
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.
Not to incessantly bike shed on the naming, but I don't like
cast_out, it's not very descriptive. And it has connotations of
getting rid of something, which isn't really true.
Um, I thought it was exactly descriptive: you're casting to the outer
container. I thought about following the C++ dynamic casting style, so
out_cast(), but that seemed a bit pejorative. What about outer_cast()?
quoted
FWIW, I like the from_ part of the original naming, as it has some
clues as to what is being done here. Why not just from_container()?
That should immediately tell people what it does without having to
look up the implementation, even before this becomes a part of the
accepted coding norm.
I'm not opposed to container_from() but it seems a little less
descriptive than outer_cast() but I don't really care. I always have
to look up container_of() when I'm using it so this would just be
another macro of that type ...
So far we have a few which have been suggested as replacement
for from_tasklet()
- out_cast() or outer_cast()
- from_member().
- container_from() or from_container()
from_container() sounds fine, would trimming it a bit work? like from_cont().
I like container_from() the most, since it's the closest to contain_of()
which is a well known idiom for years. The lines will already be shorter
without the need to specify the struct, so don't like the idea of
squeezing container into cont for any of them. For most people, cont is
usually short for continue, not container.
--
Jens Axboe
From: James Bottomley <James.Bottomley@HansenPartnership.com> Date: 2020-08-19 21:39:44
On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
quoted
[...]
quoted
quoted
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.
Not to incessantly bike shed on the naming, but I don't like
cast_out, it's not very descriptive. And it has connotations of
getting rid of something, which isn't really true.
Um, I thought it was exactly descriptive: you're casting to the
outer container. I thought about following the C++ dynamic casting
style, so out_cast(), but that seemed a bit pejorative. What about
outer_cast()?
quoted
FWIW, I like the from_ part of the original naming, as it has
some clues as to what is being done here. Why not just
from_container()? That should immediately tell people what it
does without having to look up the implementation, even before
this becomes a part of the accepted coding norm.
I'm not opposed to container_from() but it seems a little less
descriptive than outer_cast() but I don't really care. I always
have to look up container_of() when I'm using it so this would just
be another macro of that type ...
So far we have a few which have been suggested as replacement
for from_tasklet()
- out_cast() or outer_cast()
- from_member().
- container_from() or from_container()
from_container() sounds fine, would trimming it a bit work? like
from_cont().
I'm fine with container_from(). It's the same form as container_of()
and I think we need urgent agreement to not stall everything else so
the most innocuous name is likely to get the widest acceptance.
James
From: Allen Pais <hidden> Date: 2020-08-26 01:51:53
On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
[off-list ref] wrote:
On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
quoted
quoted
[...]
quoted
quoted
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.
Not to incessantly bike shed on the naming, but I don't like
cast_out, it's not very descriptive. And it has connotations of
getting rid of something, which isn't really true.
Um, I thought it was exactly descriptive: you're casting to the
outer container. I thought about following the C++ dynamic casting
style, so out_cast(), but that seemed a bit pejorative. What about
outer_cast()?
quoted
FWIW, I like the from_ part of the original naming, as it has
some clues as to what is being done here. Why not just
from_container()? That should immediately tell people what it
does without having to look up the implementation, even before
this becomes a part of the accepted coding norm.
I'm not opposed to container_from() but it seems a little less
descriptive than outer_cast() but I don't really care. I always
have to look up container_of() when I'm using it so this would just
be another macro of that type ...
So far we have a few which have been suggested as replacement
for from_tasklet()
- out_cast() or outer_cast()
- from_member().
- container_from() or from_container()
from_container() sounds fine, would trimming it a bit work? like
from_cont().
I'm fine with container_from(). It's the same form as container_of()
and I think we need urgent agreement to not stall everything else so
the most innocuous name is likely to get the widest acceptance.
Kees,
Will you be sending the newly proposed API to Linus? I have V2
which uses container_from()
ready to be sent out.
Thanks.
From: Dan Carpenter <hidden> Date: 2020-08-26 10:01:31
On Wed, Aug 26, 2020 at 07:21:35AM +0530, Allen Pais wrote:
On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
[off-list ref] wrote:
quoted
On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
quoted
quoted
[...]
quoted
quoted
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.
Not to incessantly bike shed on the naming, but I don't like
cast_out, it's not very descriptive. And it has connotations of
getting rid of something, which isn't really true.
Um, I thought it was exactly descriptive: you're casting to the
outer container. I thought about following the C++ dynamic casting
style, so out_cast(), but that seemed a bit pejorative. What about
outer_cast()?
quoted
FWIW, I like the from_ part of the original naming, as it has
some clues as to what is being done here. Why not just
from_container()? That should immediately tell people what it
does without having to look up the implementation, even before
this becomes a part of the accepted coding norm.
I'm not opposed to container_from() but it seems a little less
descriptive than outer_cast() but I don't really care. I always
have to look up container_of() when I'm using it so this would just
be another macro of that type ...
So far we have a few which have been suggested as replacement
for from_tasklet()
- out_cast() or outer_cast()
- from_member().
- container_from() or from_container()
from_container() sounds fine, would trimming it a bit work? like
from_cont().
I'm fine with container_from(). It's the same form as container_of()
and I think we need urgent agreement to not stall everything else so
the most innocuous name is likely to get the widest acceptance.
Kees,
Will you be sending the newly proposed API to Linus? I have V2
which uses container_from()
ready to be sent out.
I liked that James swapped the first two arguments so that it matches
container_of(). Plus it's nice that when you have:
struct whatever *foo = container_from(ptr, foo, member);
Then it means that "ptr == &foo->member".
regards,
dan carpenter
On Wed, Aug 26, 2020 at 12:55:28PM +0300, Dan Carpenter wrote:
On Wed, Aug 26, 2020 at 07:21:35AM +0530, Allen Pais wrote:
quoted
On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
[off-list ref] wrote:
quoted
On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
quoted
quoted
[...]
quoted
quoted
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.
Not to incessantly bike shed on the naming, but I don't like
cast_out, it's not very descriptive. And it has connotations of
getting rid of something, which isn't really true.
Um, I thought it was exactly descriptive: you're casting to the
outer container. I thought about following the C++ dynamic casting
style, so out_cast(), but that seemed a bit pejorative. What about
outer_cast()?
quoted
FWIW, I like the from_ part of the original naming, as it has
some clues as to what is being done here. Why not just
from_container()? That should immediately tell people what it
does without having to look up the implementation, even before
this becomes a part of the accepted coding norm.
I'm not opposed to container_from() but it seems a little less
descriptive than outer_cast() but I don't really care. I always
have to look up container_of() when I'm using it so this would just
be another macro of that type ...
So far we have a few which have been suggested as replacement
for from_tasklet()
- out_cast() or outer_cast()
- from_member().
- container_from() or from_container()
from_container() sounds fine, would trimming it a bit work? like
from_cont().
I'm fine with container_from(). It's the same form as container_of()
and I think we need urgent agreement to not stall everything else so
the most innocuous name is likely to get the widest acceptance.
Kees,
Will you be sending the newly proposed API to Linus? I have V2
which uses container_from()
ready to be sent out.
I liked that James swapped the first two arguments so that it matches
container_of(). Plus it's nice that when you have:
struct whatever *foo = container_from(ptr, foo, member);
Then it means that "ptr == &foo->member".
I'm a bit stalled right now -- the merge window was keeping me busy, and
this week is the Linux Plumbers Conference. This is on my list, but I
haven't gotten back around to it. If you want, feel free to send the
container_from() patch; you might be able to unblock this faster than me
right now. :)
-Kees
--
Kees Cook
On Wed, Aug 26, 2020 at 8:43 PM Kees Cook [off-list ref] wrote:
On Wed, Aug 26, 2020 at 12:55:28PM +0300, Dan Carpenter wrote:
quoted
On Wed, Aug 26, 2020 at 07:21:35AM +0530, Allen Pais wrote:
quoted
On Thu, Aug 20, 2020 at 3:09 AM James Bottomley
[off-list ref] wrote:
quoted
On Wed, 2020-08-19 at 21:54 +0530, Allen wrote:
quoted
quoted
[...]
quoted
quoted
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.
Not to incessantly bike shed on the naming, but I don't like
cast_out, it's not very descriptive. And it has connotations of
getting rid of something, which isn't really true.
Um, I thought it was exactly descriptive: you're casting to the
outer container. I thought about following the C++ dynamic casting
style, so out_cast(), but that seemed a bit pejorative. What about
outer_cast()?
quoted
FWIW, I like the from_ part of the original naming, as it has
some clues as to what is being done here. Why not just
from_container()? That should immediately tell people what it
does without having to look up the implementation, even before
this becomes a part of the accepted coding norm.
I'm not opposed to container_from() but it seems a little less
descriptive than outer_cast() but I don't really care. I always
have to look up container_of() when I'm using it so this would just
be another macro of that type ...
So far we have a few which have been suggested as replacement
for from_tasklet()
- out_cast() or outer_cast()
- from_member().
- container_from() or from_container()
from_container() sounds fine, would trimming it a bit work? like
from_cont().
I'm fine with container_from(). It's the same form as container_of()
and I think we need urgent agreement to not stall everything else so
the most innocuous name is likely to get the widest acceptance.
Kees,
Will you be sending the newly proposed API to Linus? I have V2
which uses container_from()
ready to be sent out.
I liked that James swapped the first two arguments so that it matches
container_of(). Plus it's nice that when you have:
struct whatever *foo = container_from(ptr, foo, member);
Then it means that "ptr == &foo->member".
I'm a bit stalled right now -- the merge window was keeping me busy, and
this week is the Linux Plumbers Conference. This is on my list, but I
haven't gotten back around to it. If you want, feel free to send the
container_from() patch; you might be able to unblock this faster than me
right now. :)
From: Richard Weinberger <hidden> Date: 2020-10-18 21:50:17
On Mon, Aug 17, 2020 at 11:17 AM Allen Pais [off-list ref] wrote:
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
arch/um/drivers/vector_kern.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Anton, can you please review this patch?
--
Thanks,
//richard
From: Anton Ivanov <anton.ivanov@cambridgegreys.com> Date: 2020-10-19 07:39:46
On 17/08/2020 10:15, Allen Pais wrote:
quoted hunk
From: Allen Pais <redacted>
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.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <redacted>
---
arch/um/drivers/vector_kern.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/