Re: [PATCH] Cosmetic:Partially remove deprecated __initcall() and change to

On 03/19/10 16:24, Justin P. Mattock wrote: > On 03/19/2010 03:56 PM, Randy Dunlap wrote: >> On 03/19/10 12:51, Justin P. Mattock wrote: >>> After doing some things on a small issue, >>> I noticed through web surfing, that there were patches >>> submitted pertaining that __initcall is deprecated, >>> and device_initcall should be used. >> >> Where was this discussion? Do you have any pointers to it? >> > > The best info on this is scripts/checkpatch.pl > line #2664 > > when I found this I just did a quick search of __initcall > (which gives hits here and there) > https://patchwork.kernel.org/patch/23344/ > (also found others at around 2008 or so) Thanks. IMO there should be something in the kernel source tree that says explicitly that __initcall is deprecated and should be replaced by using<whatever should be used>. That's missing.

>> I don't see any mention of __initcall being deprecated in >> Linus' mainline git tree, or in linux-next, or in mmotm. >> Where are those patches? >> > > I don't know(I'm out of the social pipeline when it comes to Linux news, > and updates).. > like in the explanation part of the patch > I was looking into something else, then ran into this, > so as a break(from what I was originally doing) > decided to do this and submit. > >> >>> So as a change of subject(since what I was looking at >>> was frustrating me),I decided to grep the whole tree >>> and make the change(partially). >>> >>> Currently I'm running this patch on my system, kernel compiles >>> without any errors or warnings.(thought there would be a speed increase >>> but didn't see much(if any)). >> >> No, __initcall(x) is just a shorthand version of typing >> device_initcall(x). They do the same thing. >> > > yep, that's what I found out as well(reason for the cosmetic > in the subject line). > >>> Biggest problem I have though is testing this on other hardware types >>> (I only have a macbook,and an iMac). >>> So please if you have the access to other arch/hardware types please >>> test. >>> >>> Now what I mean by partially is the __initcall function is still >>> there, so(if any) userspace apps/libs depend on this it's there >>> so they dont break and/or any other subsystem, that needs time >>> to make the changes. >> >> The only thing that might be affected is building out-of-tree drivers, >> but those are easy to fix. >> > > alright..main concern is making sure things don't break in the > kernel(even though things do). > > I can have a go at the header files, submit > then if it's something people agree they want to do, then they > can go from there(if not it's fine as well). > >>> Note: >>> the remaining files that still have __initcall in them are: >>> (according to grep) >>> >>> arch/um/include/shared/init.h >>> include/linux/init.h >>> scripts/checkpatch.pl >>> >>> either I or somebody else, can change this(although a bit >>> concerned about breaking things). >>> >>> Signed-off-by: Justin P. Mattock&lt;justinmattock(a)gmail.com&gt; >>> ---