Date: Sat, 18 Jul 2020 14:34:57 +0200 From: Oscar Carter <oscar.carter@....com> To: Kees Cook <keescook@...omium.org>, Allen <allen.lkml@...il.com> Cc: Oscar Carter <oscar.carter@....com>, Kernel Hardening <kernel-hardening@...ts.openwall.com> Subject: Re: Clarification about the series to modernize the tasklet api 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.