| Message ID | 20180530004520.qnqnainaevyrcoae@smtp.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, May 29, 2018 at 09:45:20PM -0300, Rodrigo Siqueira wrote: > This patch adds a new option to force the use of a module specified from > the command line. The force command expects a module name which will be > used on the target test (changing the standard behavior). This feature > can be useful for developers that have to create a new module since it > is possible to use some of the tests already provided by IGT (e.g., > kms_color, core, etc.) as a start point. Additionally, it can > also be useful for someone that wants to implement a new set of tests > for a specific driver because the developer can first check the behavior > of any test in the target module. It is important to highlight, that a > force option can produce unexpected results and developers should be > aware of that. Is this meant for testing replacement drivers for hardware with already existing drivers? If not, I'm not sure what the goal is here. Setting a forced module target in this patch changes which module is loaded by the kernel, but the driver that's opened by IGT is unchanged. Force-loading my-fancy-driver.ko still makes drm_open_driver(DRIVER_INTEL) open the one driven by i915.ko, and drm_open_driver(DRIVER_ANY) still opens the first one that is recognized. If this is for testing new drivers for not-already-supported devices, you need to instead force what drm_open_driver(DRIVER_ANY) will open, and not reject unknown devices. Some additional drive-by feedback below. > diff --git a/lib/drmtest.c b/lib/drmtest.c > index fae6f86f..1d2ba178 100644 > --- a/lib/drmtest.c > +++ b/lib/drmtest.c > @@ -258,6 +258,7 @@ static int __open_device(const char *base, int offset, unsigned int chipset) > static int __open_driver(const char *base, int offset, unsigned int chipset) > { > static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; > + const char* target; > static const struct module { > unsigned int bit; > const char *module; > @@ -276,13 +277,19 @@ static int __open_driver(const char *base, int offset, unsigned int chipset) > if (fd != -1) > return fd; > > + target = get_target_module(); > + > pthread_mutex_lock(&mutex); > - for (const struct module *m = modules; m->module; m++) { > - if (chipset & m->bit) { > - if (m->modprobe) > - m->modprobe(m->module); > - else > - modprobe(m->module); > + if (target) { > + modprobe(target); > + } else { > + for (const struct module *m = modules; m->module; m++) { > + if (chipset & m->bit) { > + if (m->modprobe) > + m->modprobe(m->module); > + else > + modprobe(m->module); > + } > } > } > pthread_mutex_unlock(&mutex); > diff --git a/lib/igt_core.c b/lib/igt_core.c > index 5092a3f0..ed66eae1 100644 > --- a/lib/igt_core.c > +++ b/lib/igt_core.c > @@ -286,6 +286,7 @@ enum { > OPT_DESCRIPTION, > OPT_DEBUG, > OPT_INTERACTIVE_DEBUG, > + OPT_FORCE_MODULE, > OPT_HELP = 'h' > }; > > @@ -303,6 +304,20 @@ static pthread_mutex_t log_buffer_mutex = PTHREAD_MUTEX_INITIALIZER; > GKeyFile *igt_key_file; > #endif > > +char *target_module; > + > +void set_target_module(char *target) > +{ > + if (!target) > + igt_warn("No module specified, keep default behaviour"); > + target_module = target; > +} > + > +const char *get_target_module(void) > +{ > + return target_module; > +} > + > char *igt_frame_dump_path; > > const char *igt_test_name(void) > @@ -555,6 +570,7 @@ static void print_usage(const char *help_str, bool output_on_stderr) > " --debug[=log-domain]\n" > " --interactive-debug[=domain]\n" > " --help-description\n" > + " --force-module <module>\n" > " --help\n"); > if (help_str) > fprintf(f, "%s\n", help_str); > @@ -666,6 +682,7 @@ static int common_init(int *argc, char **argv, > {"debug", optional_argument, 0, OPT_DEBUG}, > {"interactive-debug", optional_argument, 0, OPT_INTERACTIVE_DEBUG}, > {"help", 0, 0, OPT_HELP}, > + {"force-module", required_argument, 0, OPT_FORCE_MODULE}, > {0, 0, 0, 0} > }; > char *short_opts; > @@ -763,6 +780,9 @@ static int common_init(int *argc, char **argv, > print_test_description(); > ret = -1; > goto out; > + case OPT_FORCE_MODULE: > + set_target_module(strdup(optarg)); > + break; > case OPT_HELP: > print_usage(help_str, false); > ret = -1; > diff --git a/lib/igt_core.h b/lib/igt_core.h > index bf8cd66c..6d635ebd 100644 > --- a/lib/igt_core.h > +++ b/lib/igt_core.h > @@ -50,6 +50,10 @@ extern const char* __igt_test_description __attribute__((weak)); > extern bool __igt_plain_output; > extern char *igt_frame_dump_path; > > +extern char *target_module; > +void set_target_module(char *target); > +const char *get_target_module(void); > + > /** > * IGT_TEST_DESCRIPTION: > * @str: description string > diff --git a/scripts/run-tests.sh b/scripts/run-tests.sh > index 4209dd8c..c810a8dd 100755 > --- a/scripts/run-tests.sh > +++ b/scripts/run-tests.sh > @@ -80,6 +80,7 @@ function print_help { > echo " (can be used more than once)" > echo " -T <filename> run tests listed in testlist" > echo " (overrides -t and -x)" > + echo " -m <module> force load a specific module" > echo " -v enable verbose mode" > echo " -x <regex> exclude tests that match the regular expression" > echo " (can be used more than once)" > @@ -91,7 +92,7 @@ function print_help { > echo "Useful patterns for test filtering are described in the API documentation." > } > > -while getopts ":dhlr:st:T:vx:Rn" opt; do > +while getopts ":dhlr:st:T:m:vx:Rn" opt; do > case $opt in > d) download_piglit; exit ;; > h) print_help; exit ;; > @@ -100,6 +101,7 @@ while getopts ":dhlr:st:T:vx:Rn" opt; do > s) SUMMARY="html" ;; > t) FILTER="$FILTER -t $OPTARG" ;; > T) FILTER="$FILTER --test-list $OPTARG" ;; > + m) FILTER="$FILTER -m $OPTARG" ;; This will change what is passed to _piglit_ command line, not the test command line. Above, you added --force-module long option, but didn't add the -m short option, so this wouldn't do anything anyway. Consider if passing the force option through the environment would be easier instead.
Hi, First of all, thanks for your feedback :) On 06/13, Petri Latvala wrote: > On Tue, May 29, 2018 at 09:45:20PM -0300, Rodrigo Siqueira wrote: > > This patch adds a new option to force the use of a module specified from > > the command line. The force command expects a module name which will be > > used on the target test (changing the standard behavior). This feature > > can be useful for developers that have to create a new module since it > > is possible to use some of the tests already provided by IGT (e.g., > > kms_color, core, etc.) as a start point. Additionally, it can > > also be useful for someone that wants to implement a new set of tests > > for a specific driver because the developer can first check the behavior > > of any test in the target module. It is important to highlight, that a > > force option can produce unexpected results and developers should be > > aware of that. > > > Is this meant for testing replacement drivers for hardware with > already existing drivers? If not, I'm not sure what the goal is here. Just for provide some additional information, follows my context and motivation for this patch: We are working on a new module named VKMS [1,2]. In some way, our development approach is similar to Test-Driven Development (TDD), since we use IGT tests to support our development process. For example, at the beginning of the VKMS development we focused on making core_* tests pass, and now we are using kms_flip and others to help us to implement new features. For doing it, we changed IGT code to load our module. After thinking about the changes we made in the IGT, I realize that force a particular module via command line could be useful for other users because they can utilize the available tests to help them to create their modules (as we are doing). Additionally, I think this feature could be used for test some basic features on modules that currently aren't part of the IGT. So, what do you think about that? Do you think that makes sense to have this feature in the IGT? > Setting a forced module target in this patch changes which module is > loaded by the kernel, but the driver that's opened by IGT is > unchanged. Force-loading my-fancy-driver.ko still makes > drm_open_driver(DRIVER_INTEL) open the one driven by i915.ko, and > drm_open_driver(DRIVER_ANY) still opens the first one that is > recognized. I think it is better to force open and load, right? > If this is for testing new drivers for not-already-supported devices, > you need to instead force what drm_open_driver(DRIVER_ANY) will open, > and not reject unknown devices. > > Some additional drive-by feedback below. > > > > diff --git a/lib/drmtest.c b/lib/drmtest.c > > index fae6f86f..1d2ba178 100644 > > --- a/lib/drmtest.c > > +++ b/lib/drmtest.c > > @@ -258,6 +258,7 @@ static int __open_device(const char *base, int offset, unsigned int chipset) > > static int __open_driver(const char *base, int offset, unsigned int chipset) > > { > > static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; > > + const char* target; > > static const struct module { > > unsigned int bit; > > const char *module; > > @@ -276,13 +277,19 @@ static int __open_driver(const char *base, int offset, unsigned int chipset) > > if (fd != -1) > > return fd; > > > > + target = get_target_module(); > > + > > pthread_mutex_lock(&mutex); > > - for (const struct module *m = modules; m->module; m++) { > > - if (chipset & m->bit) { > > - if (m->modprobe) > > - m->modprobe(m->module); > > - else > > - modprobe(m->module); > > + if (target) { > > + modprobe(target); > > + } else { > > + for (const struct module *m = modules; m->module; m++) { > > + if (chipset & m->bit) { > > + if (m->modprobe) > > + m->modprobe(m->module); > > + else > > + modprobe(m->module); > > + } > > } > > } > > pthread_mutex_unlock(&mutex); > > diff --git a/lib/igt_core.c b/lib/igt_core.c > > index 5092a3f0..ed66eae1 100644 > > --- a/lib/igt_core.c > > +++ b/lib/igt_core.c > > @@ -286,6 +286,7 @@ enum { > > OPT_DESCRIPTION, > > OPT_DEBUG, > > OPT_INTERACTIVE_DEBUG, > > + OPT_FORCE_MODULE, > > OPT_HELP = 'h' > > }; > > > > @@ -303,6 +304,20 @@ static pthread_mutex_t log_buffer_mutex = PTHREAD_MUTEX_INITIALIZER; > > GKeyFile *igt_key_file; > > #endif > > > > +char *target_module; > > + > > +void set_target_module(char *target) > > +{ > > + if (!target) > > + igt_warn("No module specified, keep default behaviour"); > > + target_module = target; > > +} > > + > > +const char *get_target_module(void) > > +{ > > + return target_module; > > +} > > + > > char *igt_frame_dump_path; > > > > const char *igt_test_name(void) > > @@ -555,6 +570,7 @@ static void print_usage(const char *help_str, bool output_on_stderr) > > " --debug[=log-domain]\n" > > " --interactive-debug[=domain]\n" > > " --help-description\n" > > + " --force-module <module>\n" > > " --help\n"); > > if (help_str) > > fprintf(f, "%s\n", help_str); > > @@ -666,6 +682,7 @@ static int common_init(int *argc, char **argv, > > {"debug", optional_argument, 0, OPT_DEBUG}, > > {"interactive-debug", optional_argument, 0, OPT_INTERACTIVE_DEBUG}, > > {"help", 0, 0, OPT_HELP}, > > + {"force-module", required_argument, 0, OPT_FORCE_MODULE}, > > {0, 0, 0, 0} > > }; > > char *short_opts; > > @@ -763,6 +780,9 @@ static int common_init(int *argc, char **argv, > > print_test_description(); > > ret = -1; > > goto out; > > + case OPT_FORCE_MODULE: > > + set_target_module(strdup(optarg)); > > + break; > > case OPT_HELP: > > print_usage(help_str, false); > > ret = -1; > > diff --git a/lib/igt_core.h b/lib/igt_core.h > > index bf8cd66c..6d635ebd 100644 > > --- a/lib/igt_core.h > > +++ b/lib/igt_core.h > > @@ -50,6 +50,10 @@ extern const char* __igt_test_description __attribute__((weak)); > > extern bool __igt_plain_output; > > extern char *igt_frame_dump_path; > > > > +extern char *target_module; > > +void set_target_module(char *target); > > +const char *get_target_module(void); > > + > > /** > > * IGT_TEST_DESCRIPTION: > > * @str: description string > > diff --git a/scripts/run-tests.sh b/scripts/run-tests.sh > > index 4209dd8c..c810a8dd 100755 > > --- a/scripts/run-tests.sh > > +++ b/scripts/run-tests.sh > > @@ -80,6 +80,7 @@ function print_help { > > echo " (can be used more than once)" > > echo " -T <filename> run tests listed in testlist" > > echo " (overrides -t and -x)" > > + echo " -m <module> force load a specific module" > > echo " -v enable verbose mode" > > echo " -x <regex> exclude tests that match the regular expression" > > echo " (can be used more than once)" > > @@ -91,7 +92,7 @@ function print_help { > > echo "Useful patterns for test filtering are described in the API documentation." > > } > > > > -while getopts ":dhlr:st:T:vx:Rn" opt; do > > +while getopts ":dhlr:st:T:m:vx:Rn" opt; do > > case $opt in > > d) download_piglit; exit ;; > > h) print_help; exit ;; > > @@ -100,6 +101,7 @@ while getopts ":dhlr:st:T:vx:Rn" opt; do > > s) SUMMARY="html" ;; > > t) FILTER="$FILTER -t $OPTARG" ;; > > T) FILTER="$FILTER --test-list $OPTARG" ;; > > + m) FILTER="$FILTER -m $OPTARG" ;; > > > This will change what is passed to _piglit_ command line, not the test > command line. Above, you added --force-module long option, but didn't > add the -m short option, so this wouldn't do anything anyway. I got it. I can fix it. > Consider if passing the force option through the environment would be > easier instead. I did not completely understand the idea, what do you mean by force option through the environment? Make the force command set a flag and change the code to check it? Thanks Rodrigo Siqueira [1,2] https://cgit.freedesktop.org/drm-misc/log/?h=topic/vkms, https://www.kernel.org/doc/html/v4.12/gpu/todo.html#create-a-virtual-kms-driver-for-testing-vkms > -- > Petri Latvala
On Sat, Jun 16, 2018 at 09:26:31PM -0300, Rodrigo Siqueira wrote: > Hi, > > First of all, thanks for your feedback :) > > On 06/13, Petri Latvala wrote: > > On Tue, May 29, 2018 at 09:45:20PM -0300, Rodrigo Siqueira wrote: > > > This patch adds a new option to force the use of a module specified from > > > the command line. The force command expects a module name which will be > > > used on the target test (changing the standard behavior). This feature > > > can be useful for developers that have to create a new module since it > > > is possible to use some of the tests already provided by IGT (e.g., > > > kms_color, core, etc.) as a start point. Additionally, it can > > > also be useful for someone that wants to implement a new set of tests > > > for a specific driver because the developer can first check the behavior > > > of any test in the target module. It is important to highlight, that a > > > force option can produce unexpected results and developers should be > > > aware of that. > > > > > > Is this meant for testing replacement drivers for hardware with > > already existing drivers? If not, I'm not sure what the goal is here. > > Just for provide some additional information, follows my context and > motivation for this patch: > > We are working on a new module named VKMS [1,2]. In some way, our > development approach is similar to Test-Driven Development (TDD), since > we use IGT tests to support our development process. For example, at the > beginning of the VKMS development we focused on making core_* tests > pass, and now we are using kms_flip and others to help us to implement > new features. For doing it, we changed IGT code to load our > module. After thinking about the changes we made in the IGT, I realize > that force a particular module via command line could be useful for > other users because they can utilize the available tests to help them to > create their modules (as we are doing). Additionally, I think this > feature could be used for test some basic features on modules that > currently aren't part of the IGT. > > So, what do you think about that? Do you think that makes sense to have > this feature in the IGT? Yes! The devil is in the details though. Forcing the use of a specific driver, that's what we're going to need in IGT in some form. After discussing this with you on IRC, I learned that you're running a VM without any other DRM drivers (loaded). That's why you have this system working at this time. When the tests want an fd to a DRM device, drmtest.c tries to open the first /dev/dri/card<num> that matches what is requested. If everything fails, it loads all modules it knows about and tries another time, again opening the first /dev/dri/card<num> that matches the request. If you had, say, i915 loaded or builtin, you'd have /dev/dri/card0 already, and it would be used for DRIVER_ANY opens regardless of whether you modprobe vkms. If vkms was builtin, modprobe would change nothing. One force option that we absolutely need is selecting what DRIVER_ANY means, in a device that has multiple DRM drivers available. Another is forcing which /dev/dri/card<num> to use, with or without overriding what DRIVER_ANY means. Forcing a modprobe on a particular driver isn't strictly speaking a third option, but tied to the two. (One could argue that modprobing a driver can also be done from one's testing scripts, but drivers can be left unloaded by e.g. a test that checks module unloading.) An approach I came up with is setting a string and in drmtest.c, __open_device(), if (force_string && chipset == DRIVER_ANY && __is_device(fd, force_string)) return fd; That would force vkms to be used by setting force_string to "vkms", assuming DRM_IOCTL_VERSION gives that as its name. That allows vkms to be builtin, and other drivers to be loaded. In addition to that, setting another force string could be used to modprobe a specific module. In addition to what is already loaded by the modprobe loop, forcing the device name in the above code would mean other drivers won't be used. > > > Setting a forced module target in this patch changes which module is > > loaded by the kernel, but the driver that's opened by IGT is > > unchanged. Force-loading my-fancy-driver.ko still makes > > drm_open_driver(DRIVER_INTEL) open the one driven by i915.ko, and > > drm_open_driver(DRIVER_ANY) still opens the first one that is > > recognized. > > I think it is better to force open and load, right? > > > If this is for testing new drivers for not-already-supported devices, > > you need to instead force what drm_open_driver(DRIVER_ANY) will open, > > and not reject unknown devices. For those following along at home, correction to this: drm_open_driver does not reject unknown devices, I misread the code. > I did not completely understand the idea, what do you mean by force > option through the environment? Make the force command set a flag and > change the code to check it? As you might have learned now, the command line piglit (or the new runner currently in review phase) uses to launch IGT tests is hardcoded. What I meant was setting force options through the environment, and then launching piglit or the tests themselves.
Hi, Thanks a lot for your feedback. I believe that I understood all of your comments. I will start the first version of the patch. Best Regards Rodrigo Siqueira On 06/18, Petri Latvala wrote: > On Sat, Jun 16, 2018 at 09:26:31PM -0300, Rodrigo Siqueira wrote: > > Hi, > > > > First of all, thanks for your feedback :) > > > > On 06/13, Petri Latvala wrote: > > > On Tue, May 29, 2018 at 09:45:20PM -0300, Rodrigo Siqueira wrote: > > > > This patch adds a new option to force the use of a module specified from > > > > the command line. The force command expects a module name which will be > > > > used on the target test (changing the standard behavior). This feature > > > > can be useful for developers that have to create a new module since it > > > > is possible to use some of the tests already provided by IGT (e.g., > > > > kms_color, core, etc.) as a start point. Additionally, it can > > > > also be useful for someone that wants to implement a new set of tests > > > > for a specific driver because the developer can first check the behavior > > > > of any test in the target module. It is important to highlight, that a > > > > force option can produce unexpected results and developers should be > > > > aware of that. > > > > > > > > > Is this meant for testing replacement drivers for hardware with > > > already existing drivers? If not, I'm not sure what the goal is here. > > > > Just for provide some additional information, follows my context and > > motivation for this patch: > > > > We are working on a new module named VKMS [1,2]. In some way, our > > development approach is similar to Test-Driven Development (TDD), since > > we use IGT tests to support our development process. For example, at the > > beginning of the VKMS development we focused on making core_* tests > > pass, and now we are using kms_flip and others to help us to implement > > new features. For doing it, we changed IGT code to load our > > module. After thinking about the changes we made in the IGT, I realize > > that force a particular module via command line could be useful for > > other users because they can utilize the available tests to help them to > > create their modules (as we are doing). Additionally, I think this > > feature could be used for test some basic features on modules that > > currently aren't part of the IGT. > > > > So, what do you think about that? Do you think that makes sense to have > > this feature in the IGT? > > Yes! The devil is in the details though. > > Forcing the use of a specific driver, that's what we're going to need > in IGT in some form. > > After discussing this with you on IRC, I learned that you're running a > VM without any other DRM drivers (loaded). That's why you have this > system working at this time. > > When the tests want an fd to a DRM device, drmtest.c tries to open the > first /dev/dri/card<num> that matches what is requested. If everything > fails, it loads all modules it knows about and tries another time, > again opening the first /dev/dri/card<num> that matches the request. > > If you had, say, i915 loaded or builtin, you'd have /dev/dri/card0 > already, and it would be used for DRIVER_ANY opens regardless of > whether you modprobe vkms. If vkms was builtin, modprobe would change > nothing. > > One force option that we absolutely need is selecting what DRIVER_ANY > means, in a device that has multiple DRM drivers available. Another is > forcing which /dev/dri/card<num> to use, with or without overriding > what DRIVER_ANY means. Forcing a modprobe on a particular driver isn't > strictly speaking a third option, but tied to the two. > > (One could argue that modprobing a driver can also be done from one's > testing scripts, but drivers can be left unloaded by e.g. a test that > checks module unloading.) > > An approach I came up with is setting a string and in drmtest.c, > __open_device(), > > if (force_string && chipset == DRIVER_ANY && __is_device(fd, > force_string)) > return fd; > > That would force vkms to be used by setting force_string to "vkms", > assuming DRM_IOCTL_VERSION gives that as its name. That allows vkms to > be builtin, and other drivers to be loaded. > > In addition to that, setting another force string could be used to > modprobe a specific module. In addition to what is already loaded by > the modprobe loop, forcing the device name in the above code would > mean other drivers won't be used. > > > > > > > Setting a forced module target in this patch changes which module is > > > loaded by the kernel, but the driver that's opened by IGT is > > > unchanged. Force-loading my-fancy-driver.ko still makes > > > drm_open_driver(DRIVER_INTEL) open the one driven by i915.ko, and > > > drm_open_driver(DRIVER_ANY) still opens the first one that is > > > recognized. > > > > I think it is better to force open and load, right? > > > > > If this is for testing new drivers for not-already-supported devices, > > > you need to instead force what drm_open_driver(DRIVER_ANY) will open, > > > and not reject unknown devices. > > > For those following along at home, correction to this: drm_open_driver > does not reject unknown devices, I misread the code. > > > > I did not completely understand the idea, what do you mean by force > > option through the environment? Make the force command set a flag and > > change the code to check it? > > As you might have learned now, the command line piglit (or the new > runner currently in review phase) uses to launch IGT tests is > hardcoded. What I meant was setting force options through the > environment, and then launching piglit or the tests themselves. > > > -- > Petri Latvala
diff --git a/lib/drmtest.c b/lib/drmtest.c index fae6f86f..1d2ba178 100644 --- a/lib/drmtest.c +++ b/lib/drmtest.c @@ -258,6 +258,7 @@ static int __open_device(const char *base, int offset, unsigned int chipset) static int __open_driver(const char *base, int offset, unsigned int chipset) { static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; + const char* target; static const struct module { unsigned int bit; const char *module; @@ -276,13 +277,19 @@ static int __open_driver(const char *base, int offset, unsigned int chipset) if (fd != -1) return fd; + target = get_target_module(); + pthread_mutex_lock(&mutex); - for (const struct module *m = modules; m->module; m++) { - if (chipset & m->bit) { - if (m->modprobe) - m->modprobe(m->module); - else - modprobe(m->module); + if (target) { + modprobe(target); + } else { + for (const struct module *m = modules; m->module; m++) { + if (chipset & m->bit) { + if (m->modprobe) + m->modprobe(m->module); + else + modprobe(m->module); + } } } pthread_mutex_unlock(&mutex); diff --git a/lib/igt_core.c b/lib/igt_core.c index 5092a3f0..ed66eae1 100644 --- a/lib/igt_core.c +++ b/lib/igt_core.c @@ -286,6 +286,7 @@ enum { OPT_DESCRIPTION, OPT_DEBUG, OPT_INTERACTIVE_DEBUG, + OPT_FORCE_MODULE, OPT_HELP = 'h' }; @@ -303,6 +304,20 @@ static pthread_mutex_t log_buffer_mutex = PTHREAD_MUTEX_INITIALIZER; GKeyFile *igt_key_file; #endif +char *target_module; + +void set_target_module(char *target) +{ + if (!target) + igt_warn("No module specified, keep default behaviour"); + target_module = target; +} + +const char *get_target_module(void) +{ + return target_module; +} + char *igt_frame_dump_path; const char *igt_test_name(void) @@ -555,6 +570,7 @@ static void print_usage(const char *help_str, bool output_on_stderr) " --debug[=log-domain]\n" " --interactive-debug[=domain]\n" " --help-description\n" + " --force-module <module>\n" " --help\n"); if (help_str) fprintf(f, "%s\n", help_str); @@ -666,6 +682,7 @@ static int common_init(int *argc, char **argv, {"debug", optional_argument, 0, OPT_DEBUG}, {"interactive-debug", optional_argument, 0, OPT_INTERACTIVE_DEBUG}, {"help", 0, 0, OPT_HELP}, + {"force-module", required_argument, 0, OPT_FORCE_MODULE}, {0, 0, 0, 0} }; char *short_opts; @@ -763,6 +780,9 @@ static int common_init(int *argc, char **argv, print_test_description(); ret = -1; goto out; + case OPT_FORCE_MODULE: + set_target_module(strdup(optarg)); + break; case OPT_HELP: print_usage(help_str, false); ret = -1; diff --git a/lib/igt_core.h b/lib/igt_core.h index bf8cd66c..6d635ebd 100644 --- a/lib/igt_core.h +++ b/lib/igt_core.h @@ -50,6 +50,10 @@ extern const char* __igt_test_description __attribute__((weak)); extern bool __igt_plain_output; extern char *igt_frame_dump_path; +extern char *target_module; +void set_target_module(char *target); +const char *get_target_module(void); + /** * IGT_TEST_DESCRIPTION: * @str: description string diff --git a/scripts/run-tests.sh b/scripts/run-tests.sh index 4209dd8c..c810a8dd 100755 --- a/scripts/run-tests.sh +++ b/scripts/run-tests.sh @@ -80,6 +80,7 @@ function print_help { echo " (can be used more than once)" echo " -T <filename> run tests listed in testlist" echo " (overrides -t and -x)" + echo " -m <module> force load a specific module" echo " -v enable verbose mode" echo " -x <regex> exclude tests that match the regular expression" echo " (can be used more than once)" @@ -91,7 +92,7 @@ function print_help { echo "Useful patterns for test filtering are described in the API documentation." } -while getopts ":dhlr:st:T:vx:Rn" opt; do +while getopts ":dhlr:st:T:m:vx:Rn" opt; do case $opt in d) download_piglit; exit ;; h) print_help; exit ;; @@ -100,6 +101,7 @@ while getopts ":dhlr:st:T:vx:Rn" opt; do s) SUMMARY="html" ;; t) FILTER="$FILTER -t $OPTARG" ;; T) FILTER="$FILTER --test-list $OPTARG" ;; + m) FILTER="$FILTER -m $OPTARG" ;; v) VERBOSE="-v" ;; x) EXCLUDE="$EXCLUDE -x $OPTARG" ;; R) RESUME="true" ;;
This patch adds a new option to force the use of a module specified from the command line. The force command expects a module name which will be used on the target test (changing the standard behavior). This feature can be useful for developers that have to create a new module since it is possible to use some of the tests already provided by IGT (e.g., kms_color, core, etc.) as a start point. Additionally, it can also be useful for someone that wants to implement a new set of tests for a specific driver because the developer can first check the behavior of any test in the target module. It is important to highlight, that a force option can produce unexpected results and developers should be aware of that. Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> --- lib/drmtest.c | 19 +++++++++++++------ lib/igt_core.c | 20 ++++++++++++++++++++ lib/igt_core.h | 4 ++++ scripts/run-tests.sh | 4 +++- 4 files changed, 40 insertions(+), 7 deletions(-)