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: >> >> On 1/23/20 4:40 PM, Brendan Higgins wrote: >>> Sorry for the late reply. I am still catching up from being on vacation. >>>>> On Mon, Jan 6, 2020 at 2:40 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote: >>>> It does beg the question if this means kunit is happy to not be a tool >>>> to test pre basic setup stuff (terminology used in init.c, meaning prior >>>> to running all init levels). I suspect this is the case. >>> >>> Not sure. I still haven't seen any cases where this is necessary, so I >>> am not super worried about it. Regardless, I don't think this patchset >>> really changes anything in that regard, we are moving from late_init >>> to after late_init, so it isn't that big of a change for most use >>> cases. >>> >>> Please share if you can think of some things that need to be tested in >>> early init. >> >> I don't have a specific need for this right now. I had not thought about >> how the current kunit implementation forces all kunit tests to run at a >> specific initcall level before reading this email thread. >> >> I can see the value of being able to have some tests run at different >> initcall levels to verify what functionality is available and working >> at different points in the boot sequence. > > Let's cross that bridge when we get there. It should be fairly easy to > add that functionality. Yes. I just wanted to add the thought to the back of your mind so that it does not get precluded by future changes to the kunit architecture. > >> But more important than early initcall levels, I do not want the >> framework to prevent using or testing code and data that are marked >> as '__init'. So it is important to retain a way to invoke the tests >> while __init code and data are available, if there is also a change >> to generally invoke the tests later. > > Definitely. For now that still works as long as you don't build KUnit > as a module, but I think Alan's new patches which allow KUnit to be > run at runtime via debugfs could cause some difficulty there. Again, Yes, Alan's patches are part of what triggered me thinking about the issues I raised. > 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? > . >
