[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
