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. :) > 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
