On Tue, Oct 23, 2018 at 01:09:23PM -0700, Matthew Wilcox wrote: > On Tue, Oct 23, 2018 at 01:48:32PM -0600, Shuah Khan wrote: > > On 10/23/2018 01:30 PM, Joel Fernandes wrote: > > > On Tue, Oct 23, 2018 at 11:13:36AM -0600, Shuah Khan wrote: > > >> I like this proposal. I think we will open up lot of test opportunities > > >> with > > >> this approach. > > >> > > >> Maybe we can use this stress test as a pilot and see where it takes us. > > > > > > I am a bit worried that such an EXPORT_SYMBOL_KSELFTEST mechanism can be > > > abused by > > > out-of-tree module writers to call internal functionality. > > > > That is valid concern to consider before we go forward with the proposal. > > > > We could wrap EXPORT_SYMBOL_KSELFTEST this in an existing debug option. > > This could > > be fine grained for each sub-system for its debug option. We do have a few > > of these > > now > > This all seems far more complicated than my proposed solution.
Matthew's solution seems Ok to me where it works. A problem could be that it will not always work. As an example, recently I wanted to directly set the sysctl_sched_rt_runtime variable from the rcutorture test, just for forcing some conditions. This symbol is internal and inaccessible from modules. This can also be done by calling the internal sched_rt_handler with some parameters. However I don't think including an internal source file in a test source file can achieve the objective of setting it since access to the internal symbol is not possible without exporting it somehow. This could be a "special" case too but is an example where the include trick may fall apart. I do think its a cool trick though ;-) - Joel
