Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include linux/init.h
On 14-01-27 10:13 PM, Benjamin Herrenschmidt wrote:
On Wed, 2014-01-22 at 19:38 -0500, Paul Gortmaker wrote:
Thanks, it was a great help as it uncovered a few issues in fringe arch
that I didn't have toolchains for, and I've fixed all of those up.
I've noticed that powerpc has been un-buildable for a while now; I have
used this hack patch locally so I could run the ppc defconfigs to check
that I didn't break anything. Maybe useful for linux-next in the
interim? It is a hack patch -- Not-Signed-off-by: Paul Gortmaker. :)
Can you and/or Aneesh submit that as a proper patch (with S-O-B
etc...) ?
I'd updated toolchains and didn't realize it was still broken. Patch sent.
http://patchwork.ozlabs.org/patch/314749/
Paul.
--
Thanks !
Cheers,
Ben.
Paul.
--
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index d27960c89a71..d0f070a2b395 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma,
unsigned long address,
pmd_t *pmdp);
#define pmd_move_must_withdraw pmd_move_must_withdraw
-typedef struct spinlock spinlock_t;
-static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
- spinlock_t *old_pmd_ptl)
+struct spinlock;
+static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
+ struct spinlock *old_pmd_ptl)
{
/*
* Archs like ppc64 use pgtable to store per pmd
___
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include linux/init.h
On Wed, 2014-01-22 at 19:38 -0500, Paul Gortmaker wrote:
Thanks, it was a great help as it uncovered a few issues in fringe arch
that I didn't have toolchains for, and I've fixed all of those up.
I've noticed that powerpc has been un-buildable for a while now; I have
used this hack patch locally so I could run the ppc defconfigs to check
that I didn't break anything. Maybe useful for linux-next in the
interim? It is a hack patch -- Not-Signed-off-by: Paul Gortmaker. :)
Can you and/or Aneesh submit that as a proper patch (with S-O-B
etc...) ?
Thanks !
Cheers,
Ben.
Paul.
--
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index d27960c89a71..d0f070a2b395 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma,
unsigned long address,
pmd_t *pmdp);
#define pmd_move_must_withdraw pmd_move_must_withdraw
-typedef struct spinlock spinlock_t;
-static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
- spinlock_t *old_pmd_ptl)
+struct spinlock;
+static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
+ struct spinlock *old_pmd_ptl)
{
/*
* Archs like ppc64 use pgtable to store per pmd
___
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include linux/init.h
[Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include
linux/init.h] On 22/01/2014 (Wed 18:00) Stephen Rothwell wrote:
Hi Paul,
On Tue, 21 Jan 2014 16:22:03 -0500 Paul Gortmaker
paul.gortma...@windriver.com wrote:
Where: This work exists as a queue of patches that I apply to
linux-next; since the changes are fixing some things that currently
can only be found there. The patch series can be found at:
http://git.kernel.org/cgit/linux/kernel/git/paulg/init.git
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/init.git
I've avoided annoying Stephen with another queue of patches for
linux-next while the development content was in flux, but now that
the merge window has opened, and new additions are fewer, perhaps he
wouldn't mind tacking it on the end... Stephen?
OK, I have added this to the end of linux-next today - we will see how we
go. It is called init.
Thanks, it was a great help as it uncovered a few issues in fringe arch
that I didn't have toolchains for, and I've fixed all of those up.
I've noticed that powerpc has been un-buildable for a while now; I have
used this hack patch locally so I could run the ppc defconfigs to check
that I didn't break anything. Maybe useful for linux-next in the
interim? It is a hack patch -- Not-Signed-off-by: Paul Gortmaker. :)
Paul.
--
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index d27960c89a71..d0f070a2b395 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma,
unsigned long address,
pmd_t *pmdp);
#define pmd_move_must_withdraw pmd_move_must_withdraw
-typedef struct spinlock spinlock_t;
-static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
-spinlock_t *old_pmd_ptl)
+struct spinlock;
+static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
+struct spinlock *old_pmd_ptl)
{
/*
* Archs like ppc64 use pgtable to store per pmd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 00/73] tree-wide: clean up some no longer required #include linux/init.h
TL;DR - We removed cpuinit and devinit, which left ~2000 instances of include linux/init.h that were no longer needed. To fully enable this removal/cleanup, we relocate module_init() from init.h into module.h. Multi arch/multi config build testing on linux-next has been used to find and fix any implicit header dependencies prior to deploying the actual init.h -- module.h move, to preserve bisection. Additional details beyond TL;DR: module_init/module_exit and friends moved to module.h = Aside from enabling this init.h cleanup to extend into modular files, it actually does make sense. For all modules will use some form of our initfunc processing/categorization, but not all initfunc users will be necessarily using modular functionality. So we move these module related macros to module.h and ensure module.h sources init.h module_init in non modular code: This series uncovered that we are enabling people to use module_init in non-modular code. While that works fine, there are at least three reasons why it probably should not be encouraged: 1) it makes a casual reader of the code assume the code is modular even though it is obj-y (builtin) or controlled by a bool Kconfig. 2) it makes it too easy to add dead code in a function that is handed to module_exit() -- [more on that below] 3) it breaks our ability to use priority sorted initcalls properly [more on that below.] After this change, a new coder who tries to make use of module_init in non modular code would find themselves also needing to include the module.h header. At which point the odds are greater that they would ask themselves Am I doing this right? I shouldn't need this. Note that existing non-modular code that already includes module.h and uses module_init doesn't get fixed here, since they already build w/o errors triggered by this change; we'll have to hunt them down later. module_init and initcall ordering: == We have a group of about ten priority sorted initcalls, that are called in init/main.c after most of the hard coded/direct calls have been processed. These serve the purpose of avoiding everyone poking at init/main.c to hook in their init sequence. The bins are: pure_initcall 0 core_initcall 1 postcore_initcall 2 arch_initcall 3 subsys_initcall 4 fs_initcall 5 device_initcall 6 late_initcall 7 These are meant to eventually replace users of the non specific priority __initcall which currently maps onto device_initcall. This is of interest, because in non-modular code, cpp does this: module_init -- __initcall -- device_initcall So all module_init() land in the device_initcall bucket, rather late in the sequence. That makes sense, since if it was a module, the init could be real late (days, weeks after boot). But now imagine you add support for some non-modular bus/arch/infrastructure (say for e.g. PCI) and you use module_init for it. That means anybody else who wants to use your subsystem can't do so if they use an initcall of 0 -- 5 priority. For a real world example of this, see patch #1 in this series: https://lkml.org/lkml/2014/1/14/809 We don't want to force code that is clearly arch or subsys or fs specific to have to use the device_initcall just because something else has been mistakenly put (or left) in that bucket. So a couple of changes do actually change the initcall level where it is inevitably appropriate to do so. Those are called out explicitly in their respective commit logs. module_exit and dead code = Built in code will never have an opportunity to call functions that are registered with module_exit(), so any cases of that uncovered in this series delete that dead code. Note that any built-in code that was already including module.h and using module_exit won't have shown up as breakage on the build coverage of this series, so we'll have to find those independently later. It looks like there may be quite a few that are invisibly created via module_platform_driver -- a macro that creates module_init and module_exit automatically. We may want to consider relocating module_platform_driver into module.h later... cpuinit === To finalize the removal of cpuinit, which was done several releases ago, we remove the remaining stub functions from init.h in this series. We've seen one or two users try to creep back in, so this will close the door on that chapter and prevent creep. When, what and where? = When: Ideally, barring any objections or massive oversights on my part, this will go in at or around rc1, i.e. in about 2wks. In the meantime I will continue daily re-test on linux-next across ~10 different arch, using allyesconfig,
Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include linux/init.h
Hi Paul, On Tue, 21 Jan 2014 16:22:03 -0500 Paul Gortmaker paul.gortma...@windriver.com wrote: Where: This work exists as a queue of patches that I apply to linux-next; since the changes are fixing some things that currently can only be found there. The patch series can be found at: http://git.kernel.org/cgit/linux/kernel/git/paulg/init.git git://git.kernel.org/pub/scm/linux/kernel/git/paulg/init.git I've avoided annoying Stephen with another queue of patches for linux-next while the development content was in flux, but now that the merge window has opened, and new additions are fewer, perhaps he wouldn't mind tacking it on the end... Stephen? OK, I have added this to the end of linux-next today - we will see how we go. It is called init. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au Legal Stuff: By participating in linux-next, your subsystem tree contributions are public and will be included in the linux-next trees. You may be sent e-mail messages indicating errors or other issues when the patches/commits from your subsystem tree are merged and tested in linux-next. These messages may also be cross-posted to the linux-next mailing list, the linux-kernel mailing list, etc. The linux-next tree project and IBM (my employer) make no warranties regarding the linux-next project, the testing procedures, the results, the e-mails, etc. If you don't agree to these ground rules, let me know and I'll remove your tree from participation in linux-next. pgp3YkmBevRNl.pgp Description: PGP signature
