On Thu, Mar 10, 2022 at 01:07:57PM -0800, Luis Chamberlain wrote: > On Wed, Mar 09, 2022 at 12:06:40PM +0000, Daniel Thompson wrote: > > On Tue, Mar 08, 2022 at 10:52:03AM +0000, Aaron Tomlin wrote: > > > Hi Luis, Christoph, Daniel, > > > > > > Is this patch ok or would you rather another iteration of the series? > > > Either way is fine for me. Thanks. > > > > Another iteration makes more sense to me. > > Iteration yes, but separating the patches no into another series no. > > > The removal of kdb_modules is semantically part of your module clean > > up patch set and should certainly be included in it. > > > > The removal of the spurious #include's in other kdb files is a > > good change but it is fully independent of the module rework. AFAICT > > those fixes are good with or without your changes. This suggests > > these changes can be separate from the main patch set. > > Small fixes get piled in first on the series. But this is not a fix. > This effort will not be merged separately too. This won't go into the > next merge window either, because: > > 1) There is no rush > 2) It is too late as all this needs proper testing and > its too late to claim enough testing > > So given this is all related to the move I see no reason to treat > this as a separate series. Your review of the v11 would be nice. The reason to suggest separation was that the changes to the other files in kernel/debug/ are entirely independent of the module rework and would usually be landed via a different tree. On the whole it doesn't really matter much... but landing the independent parts via the normal route for kgdb code reduces what I have to remember acking. Daniel.
