Re: Clarification about the series to modernize the tasklet api

[Oscar Carter <oscar.carter@gmx.com>]

On Mon, Jul 13, 2020 at 09:27:34AM -0700, Kees Cook wrote:
> On Mon, Jul 13, 2020 at 03:54:44PM +0530, Allen wrote:
> > >
> > > I have a few more things to complete, I shall have it done and pushed
> > > to github. Will write back
> > > once that's done.
> >
> > Here's the link to the list of patches so far. I should hopefully
> > complete the rest in about
> > a  week.
> >
> > https://github.com/allenpais/tasklets/commits/ref_tasklets
>
> Thanks for the update! I wonder if there is a way to collaborate better
> on this, so we're not all waiting on each other? (i.e. Romain got busy,
> Allen picked up the work, then Allen got busy, then Oscar picked up the
> work, then Allen returned, etc...)
>
> Perhaps split up testing? I'll like you and Oscar work it out. :)

Sure. If you need help give me some task. It will be a pleasure to help on
this. The only inconvenience is that my time to work on this is only a few
hours during the weekend. If the task have no timeout I will finish it as
soon as possible. Sorry, I would like to have more time to work on the linux
kernel.

> > What I have done so far is to keep patches close to the original
> > series, but with changes
> > from the feedback received to those patches.
> >
> > Patches 1-10 have been retained as is, except for DECLARE_TASKLET which has been
> > moved to patch 1 from patch 12 in the series.
>
> I think the "prepare" patches should be collapsed into the "convert"
> patches (i.e. let's just touch a given driver once with a single patch).
>
> > Patch 11 is broken down to sub-systems(as it was done for Timer
> > changes in the past).
> > Sub-systems:
> >  arch/*
> >  drivers/atm/*
> >  drivers/block/*
> >  drivers/char/ipmi/*
> >  drivers/crypto/*
> >  drivers/dma/*
> >  drivers/firewire/*
> >  drivers/gpu/drm/*
> >  drivers/hsi/*
> >  drivers/hv/*
> >  drivers/infiniband/*
> >  drivers/input/*
> >  drivers/mailbox/*
> >  drivers/media/*
> >  drivers/memstick/*
> >  drivers/misc/*
> >  drivers/mmc/*
> >  drivers/net/*
> >  drivers/net/ethernet/*
> >  drivers/net/ppp/*
> >  drivers/net/usb/*
> >  drivers/net/wireless/*
> >  drivers/ntb/*
> >  drivers/platform/*
> >  drivers/rapidio/*
> >  drivers/s390/*
> >  drivers/scsi/*
> >  drivers/spi/*
> >  drivers/tty/*
> >  drivers/usb/*
> >  drivers/vme/*
> >  net/dccp/*
> >  net/ipv4/*
> >  net/mac80211/*
> >  net/mac802154/*
> >  net/rds/*
> >  net/sched/*
> >  net/smc/*
> >  net/xfrm/*
> >  sound/core/*
> >  sound/*
> >  and ofcourse staging/*
> >
> >  Patches 12, 13 comments will be addressed and broken down.
> >  Patches 14, 15 will remain as is.
> >  Patch 16 will have it's comments addressed.
> >
> > With this approach, I think it will be a little easier to get the
> > patches into the kernel and also will be easier for maintainers to have
> > them reviewed.
>
> Yup -- it's that first patch that needs to land in a release so the rest can start
> landing too. (Timing here is the awkward part: the infrastructure change
> needs to be in -rc1 or -rc2 so the next development cycle can use it
> (i.e. subsystem maintainers effectively fork after the merge window is
> over). We can play other tricks (common merged branch) but I don't think
> that's needed here.
>
> Thanks to all three of you for poking at this!
>
> --
> Kees Cook

Thanks,
Oscar Carter