On Tue, Jan 28, 2020 at 11:35 AM <Tim.Bird@xxxxxxxx> wrote: > > > -----Original Message----- > > From: Frank Rowand on January 28, 2020 11:37 AM > > > > On 1/28/20 1:19 AM, Brendan Higgins wrote: > > > On Mon, Jan 27, 2020 at 9:40 AM Frank Rowand <frowand.list@xxxxxxxxx> wrote: > ... > > > we could add Kconfigs to control this, but the compiler nevertheless > > > complains because it doesn't know what phase KUnit runs in. > > > > > > Is there any way to tell the compiler that it is okay for non __init > > > code to call __init code? I would prefer not to have a duplicate > > > version of all the KUnit libraries with all the symbols marked __init. > > > > I'm not sure. The build messages have always been useful and valid in > > my context, so I never thought to consider that possibility. > > > > > Thoughts? > > I'm not sure there's a restriction on non __init code calling __init > code. In init/main.c arch_call_reset_init() is in __init, and it calls > rest_init which is non __init, without any special handling. > > Is the compiler complaint mentioned above related to calling > into __init code, or with some other issue? I distinctly remember having the compiler complain at me when I was messing around with the device tree unit tests because of KUnit calling code marked as __init. Maybe it's time to start converting those to KUnit to force the issue? Frank, does that work for you?
