kernel module parameter API ala drm.debug
so as a proof of concept, Ive converted drm to use dynamic-debug
drm has ~dozen categories of debug messages, mapped to bits
in drm.debug, aka /sys/module/drm/parameters/debug
these bits are checked at runtime by drm_debug_enabled()
to do drm debug printing.
my patchset updates users of drm_debug_enabled()
to call pr_debug instead, avoiding lots of bit-checking.
it maps bits of drm.debug using dynamic_debug_exec_queries(),
a recently exported function to support this sort of thing.
you can see it here
https://github.com/jimc/linux/tree/dd-drm
A narrower interface than dynamic_debug_exec_queries() is possible:
+static char *format_prefix_classes[] = {
+ "gvt: cmd: ",
+ "gvt: core: ",
+ "gvt: dpy: ",
+ "gvt: el: ",
+ "gvt: irq: ",
+ "gvt: mm: ",
+ "gvt: mmio: ",
+ "gvt: render: ",
+ "gvt: sched: "
+};
+static const struct kernel_param_ops param_ops_dyndbg = {
+ .set = param_set_dyndbg,
+ .get = param_get_dyndbg,
+};
+
+#define info_ln(hexi, prefix) "\n\t0x" __stringify(hexi) "\t" prefix
+
+MODULE_PARM_DESC(debug_gvt, " gvt debug categories:"
+info_ln(1, "gvt: cmd:")
+info_ln(2, "gvt: core:")
+info_ln(4, "gvt: dpy:")
+info_ln(8, "gvt: el:")
+info_ln(10, "gvt: irq:")
+info_ln(20, "gvt: mm:")
+info_ln(40, "gvt: mmio:")
+info_ln(80, "gvt: render:")
+info_ln(100, "gvt: sched:"));
+
+module_param_cb(debug_gvt, _ops_dyndbg, &__gvt_debug, 0644);
this is useful in that it shows up in modinfo output
but there could be better presentation,
maybe /sys/module/drm/parameters/debug.help
param_set_dyndbg could be moved into dynamic-debug proper,
instead of reimplemented everywhere debug bits control debug prints
(currently drm, maybe others, could be i915/gvt)
the point is that this integer parameter maps consecutive bits to "classes"
named in an input vector. these "classes" are just format ^prefix queries
clearly we shouldnt need the 1,2,4...
whats a good interface design for this module-param-bitmap ?
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Does FreeRTOS works on Linux?
On Sun, 09 May 2021 08:40:56 +0200, lo�c tourlonias said: > related to our architecture. We are working on a ARM Cortex-A7 which > have an isolation between a normal world and a secure world. Linux is > working on the normal world for the UI and FreeRTOS is running on the > secure world. Is there a easily comprehensible explanation of how that whole ARM normal/secure stuff is supposed to work? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Does FreeRTOS works on Linux?
On Sun, May 9, 2021 at 12:41 AM loïc tourlonias wrote: > > > if using a posix thread full fills the requirement of RTOS. The reason > > I want to use RTOS is , I am porting a Microcontroller code using RTOS > > (free RTOS) to Linux and > > afaik FreeRTOS doesnt work on Linux. > > > FreeRTOS is a standalone OS and depending on your system there may be > > > an example running on your architecture in parallel of your embedded > > > Linux. For example, on one of my project with have an ARM Cortex-A7 > > > with Linux running in Normal World and FreeRTOS running in Trusted > > > world. > > This is interesting , do you have something to share? > Sorry, this is intellectual property from my company so I can't share > source code but we have started from the FreeRTOS porting sample > related to our architecture. We are working on a ARM Cortex-A7 which > have an isolation between a normal world and a secure world. Linux is > working on the normal world for the UI and FreeRTOS is running on the > secure world. Communication between the two worlds is made by SMC. > > Regards > Loïc > You should look at Xenomai it uses the Adeos interrupt pipeline to pick off and handle certain interrupts and events in real-time, and pass the rest off to the linux kernel that does all setup and housekeeping they have API interfaces for VXworks, and other commercial RTOSs one of those APIs is probably your path of least portage. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
