Re: refactor tasklets to avoid unsigned long argument

[Kees Cook <keescook@chromium.org>]

On Thu, Aug 29, 2019 at 08:13:21PM +0200, Romain Perier wrote:
> On Mon, Aug 12, 2019 at 07:29:51PM +0200, Romain Perier wrote:
> 
> Hi !
> 
> https://salsa.debian.org/rperier-guest/linux-tree/tree/tasklet_init
> 
> It is mostly done ! I have just finished the commit for removing the data field
> ... and... I have completly forgot the macro DECLARE_TASKLET() :=D . Well, it
> is not a big issue because there are only few calls.

Heh, oops. Yeah, I kept tripping over things like that with the
timer_struct too.

> What I can do is the following:
> 
> 1. After the commit that convert all tasklet_init() to tasklet_setup(),
> I can a new commit that modifies the content of DECLARE_TASKLET()
> (pass the pointer of the callback as .data) and convert the callback of all
> DECLARE_TASKLET() for handling the argument with from_tasklet() correctly
> 
> 2. Then the commit for removing the .data field in the tasklet_struct
> structure that also removes the data field in DECLARE_TASKLET() (without
> changing the API of the macro, I just remove the field data from the
> content of the macro)

Yup, I think that's the best approach. The .data removal is basically
the last step (well, and the removal of tasklet_init() and the
TASKLET_*_TYPE macros).

Also, looking at your tree: I don't think you need to add the cocci
script to the tree (since you'll just be removing it). I just included
the script in my commit log for the bulk refactoring commit.

In the "tasklet: Prepare to change tasklet callback argument type"
commit, perhaps reference the timer_struct conversion series too, if
people want to see the earlier conversion methods.

English nit pick: "Prepare to the new tasklet API" I would phrase as
"Prepare to use the new tasklet API" or "Prepare for new tasklet API".

-- 
Kees Cook