Re: linux not getting gpio interrupts on xenomai 3.0.8 on raspberrypi raspbian/stretch kernel 4.9
Op 19/06/2019 om 17:00 schreef Greg Gallagher: On Wed, Jun 19, 2019 at 8:44 AM Harco Kuppens wrote: The ipipe patched not entirely cleanly on the rpi kernel source; I had to make little changes in the patch, but not anything really seriously. So I expect it to be fine. I used the rasbpian kernel source because it has better support for the raspberry pi's and mainly because it has better support for the gpio pins in its kernel. However to help you debug I did a similar install using the mainline kernel source. The ipipe patch just worked smoothly, however to get the gpio pins running in xenomai I had to still port some code of the file ./drivers/pinctrl/bcm/pinctrl-bcm2835.c What did you have to change here to get the pins to work with Xenomai? You shouldn't need to change anything here. If you did then it may be a bug in the ipipe. Can you try with 4.14 ipipe ? I did try with ipipe 4.19 and when compiling the kernel I got lot of errors. Some I could solve, but at the end I gave up. See my notes on https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/__INSTALL_FAILURES__/install__compile_vanilla_kernel_4.19_with_xenomai_3.0.8__assert_error.txt Maybe this is also interesting for you. I shall try 4.14, maybe that works... So I did, the description you can find at: https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/installation_of_xenomai_3.0.8_on_mainline_kernel_branch_v4.14.110_from_kernel.org__problem_linux_gpio.md However the results are exactly the same. I need the extra patch for pinctrl-bcm2835.c from the raspbian kernel source to have the rtdm gpio pins working in xenomai. Then xenomai gpio examples work fine, however in linux gpio doesn't work. So because we get the same result for two different kernels, I suspect that the problem is somewhere in pinctrl-bcm2835.c which is the same for both. to the mainline kernel source. With this kernel I get the same problem : gpio pins work find with rtdm in xenomai, but they don't work with linux anymore. Unclear to me why? The description of this mainline installation and how to get my example scripts which show you that the linux gpio pins are not working are described in: https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/installation_of_xenomai_3.0.8_on_mainline_kernel_branch_v4.9.51_from_kernel.org__problem_linux_gpio.md Hope you can help me solving this problem? Xenomai gpio seems to work ok, and the image seems to be fine to be used in our course at the Radboud university. However because the fact that in linux the gpio pins don't work anymore does me little bit worry if it is really ok??? Is suspect something is wrong in ./drivers/pinctrl/bcm/pinctrl-bcm2835.c . Can you post a diff of the changes you made (as mentioned above)? I made a diff/patch for ./drivers/pinctrl/bcm/pinctrl-bcm2835.c from the version v4.9.51 after the ipipe patch is applied to the raspbian kernel version 4.9.y after the ipipe patch is applied. You can download that patch at : https://raw.githubusercontent.com/harcokuppens/xenomai3_rpi_gpio/master/install/how_pinctrl-bcm2835_patch_for_rpi-4.9_is_derived/pinctrl-bcm2835.c.after-ipipe-patch-extra-rpi-4.9.patch So after applying the ipipe patch on the v4.9.51 mainline kernel, you must apply this patch to get the latest raspbian patches to this file. I needed it to get the rtdm gpio pin numbers correct. (see the problems in my installation description). You get then the version of pinctrl-bcm2835.c which I used in my installation description. In my previous email I already described points where this file differs from the version in my previous raspian/rpi/xenomai image for which everything worked fine. So take a look at that. I think to test you don't need an raspberry pi 3b+, byt an older raspberry pi 2 or a raspberry 3 would also suffice. Hopefully somebody can help me? I can try this on a rpi 2b this week, when I did this last i was able to use the gpio from sysfs and rtdm. How are you confirming that Linux doesn't see the interrupt? I use python test scripts using the piwire library in linux to test the gpio ports. On a normal raspbian image they just work fine. But with the patched kernel they just don't work anymore. So my conclusion is that linux doesn't get the interrupts anymore. How to fetch these scripts is explained at: https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/installation_of_xenomai_3.0.8_on_mainline_kernel_branch_v4.9.51_from_kernel.org__problem_linux_gpio.md#user-content-test-code I also described a whole procedure to test whether everything is working at: |https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/test_xenomai_installation_and_test_gpio_pins_are_working_correct.txt| | |If you want to try these scripts then you also need some hardware setup. Otherwise the gpio ports cannot be tested. The hardware setup is shown in
RE: Commands for reading, loading and unloading drivers on BeagleBone Black?
Use sysfs- # unbind the current driver for those devices for sio in 1-2:1.0 1-2:1.1 1-2:1.2 1-2:1.3; do echo "$sio" > /sys/bus/usb/devices/"$sio"/driver/unbind done # use a specific driver 'ftdi_sio' for a device echo "1-2:1.0" > /sys/bus/usb/drivers/ftdi_sio/bind # let linux pick a driver for a device echo '1-2:1.0' > /sys/bus/usb/drivers_probe works similar with other busses. regards, Norbert Lange > -Original Message- > From: Xenomai On Behalf Of danwe via > Xenomai > Sent: Mittwoch, 19. Juni 2019 10:19 > To: xenomai@xenomai.org > Subject: Commands for reading, loading and unloading drivers on > BeagleBone Black? > > E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE > EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR > ATTACHMENTS. > > > Hello, > > I am using a BeagleBone Black with Xenomai and RTnet on top. As some real- > time programs are not working it could be that the installed drivers on my > BeagleBone Black are still the standard drivers and not the real-time drivers. > > As I did not find anything on internet (only how to install drivers for > Windows > when using BeagleBone Black) I would like to ask you if anyobdy knows > commands for BeagleBone Black to read, load and unload installed drivers on > BBB? > > Regards > > Daniel This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. ANDRITZ HYDRO GmbH Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation Firmensitz/ Registered seat: Wien Firmenbuchgericht/ Court of registry: Handelsgericht Wien Firmenbuchnummer/ Company registration: FN 61833 g DVR: 0605077 UID-Nr.: ATU14756806 Thank You
[PATCH] cobalt/posix/signal: Fix iteration over sigwaiters
From: Jan Kiszka
Using thread both as the iteration variable and the source of the list
causes list_for_each_entry to derail after the first thread that has no
hit. This could be triggered by sending a process a signal that was in
sigwait, but not for that signal.
Fix this by using a stable list pointer.
Signed-off-by: Jan Kiszka
---
I had already tagged 3.0.9, just not pushed yet - tag deleted again.
kernel/cobalt/posix/signal.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/cobalt/posix/signal.c b/kernel/cobalt/posix/signal.c
index 7e0eb52e99..e75ce2b693 100644
--- a/kernel/cobalt/posix/signal.c
+++ b/kernel/cobalt/posix/signal.c
@@ -46,6 +46,7 @@ static int cobalt_signal_deliver(struct cobalt_thread *thread,
{ /* nklocked, IRQs off */
struct cobalt_sigwait_context *swc;
struct xnthread_wait_context *wc;
+ struct list_head *sigwaiters;
int sig, ret;
sig = sigp->si.si_signo;
@@ -67,10 +68,11 @@ static int cobalt_signal_deliver(struct cobalt_thread
*thread,
* group, try to deliver to any thread from the same process
* waiting for that signal.
*/
- if (!group || list_empty(>process->sigwaiters))
+ sigwaiters = >process->sigwaiters;
+ if (!group || list_empty(sigwaiters))
return 0;
- list_for_each_entry(thread, >process->sigwaiters, signext) {
+ list_for_each_entry(thread, sigwaiters, signext) {
wc = xnthread_get_wait_context(>threadbase);
swc = container_of(wc, struct cobalt_sigwait_context, wc);
if (sigismember(swc->set, sig))
--
2.16.4
Re: Commands for reading, loading and unloading drivers on BeagleBone Black?
Hi, On Wed, Jun 19, 2019 at 4:18 AM danwe via Xenomai wrote: > > Hello, > > I am using a BeagleBone Black with Xenomai and RTnet on top. As some > real-time programs are not working it could be that the installed drivers > on my BeagleBone Black are still the standard drivers and not the real-time > drivers. > Can you explain what's not working? What are you trying to achieve? Quick details of what you are expecting and the actual results will help. > As I did not find anything on internet (only how to install drivers for > Windows when using BeagleBone Black) I would like to ask you if anyobdy > knows commands for BeagleBone Black to read, load and unload installed > drivers on BBB? > Are you talking about RTDM drivers? What RTDM drivers are you trying to load? Have you configured them when you built the kernel. > Regards > > Daniel -Greg
Re: linux not getting gpio interrupts on xenomai 3.0.8 on raspberrypi raspbian/stretch kernel 4.9
On Wed, Jun 19, 2019 at 8:44 AM Harco Kuppens wrote: > > The ipipe patched not entirely cleanly on the rpi kernel source; I had to > make little changes in the patch, but not anything really seriously. So I > expect it to be fine. > > I used the rasbpian kernel source because it has better support for the > raspberry pi's and mainly because it has better support for the gpio pins in > its kernel. > > However to help you debug I did a similar install using the mainline kernel > source. The ipipe patch just worked smoothly, however to get the gpio pins > running in xenomai I had to still port some code of the file > > ./drivers/pinctrl/bcm/pinctrl-bcm2835.c > What did you have to change here to get the pins to work with Xenomai? You shouldn't need to change anything here. If you did then it may be a bug in the ipipe. Can you try with 4.14 ipipe ? > to the mainline kernel source. > > With this kernel I get the same problem : gpio pins work find with rtdm in > xenomai, but they don't work with linux anymore. > Unclear to me why? > > The description of this mainline installation and how to get my example > scripts which show you that the linux gpio pins are not working > are described in: > > https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/installation_of_xenomai_3.0.8_on_mainline_kernel_branch_v4.9.51_from_kernel.org__problem_linux_gpio.md > > Hope you can help me solving this problem? > Xenomai gpio seems to work ok, and the image seems to be fine to be used in > our course at the Radboud university. > > However because the fact that in linux the gpio pins don't work anymore does > me little bit worry if it is really ok??? > Is suspect something is wrong in ./drivers/pinctrl/bcm/pinctrl-bcm2835.c . Can you post a diff of the changes you made (as mentioned above)? > In my previous email I already described points where this file differs from > the version in my previous raspian/rpi/xenomai image for which everything > worked fine. So take a look at that. > > I think to test you don't need an raspberry pi 3b+, byt an older raspberry pi > 2 or a raspberry 3 would also suffice. > > Hopefully somebody can help me? > I can try this on a rpi 2b this week, when I did this last i was able to use the gpio from sysfs and rtdm. How are you confirming that Linux doesn't see the interrupt? We'll need to track down where in the pipeline the interrupt is lost. > Best regards, > > Harco Kuppens > > > -Greg > > Op 13/06/2019 om 16:13 schreef Greg Gallagher: > > On Wed, Jun 12, 2019 at 5:40 PM Harco Kuppens via Xenomai > wrote: > > I put the raspberry pi image with xenomai2 I build for the raspberry pi > 2 and 3, also supporting the latest raspberry pi3b+ online at: > >http://www.cs.ru.nl/lab/xenomai/raspberrypi.html > > I'm still wondering what the reason is that I don't receive the gpio > interrupts in linux. Unfortunately nobody could answer my questions so > far. If somebody knows the problem, then I will fix the image. > > Except for this linux gpio interrupt problem the above image seems to > work of for realtime xenomai gpio interrupts. > > Best regards, > Harco Kuppens > > Op 07/06/2019 om 12:34 schreef Harco Kuppens via Xenomai: > > Hi, > > In juli 2017 I managed to port xenomai 3.0.5 to rasbpian jessie on the > rpi3b. See https://xenomai.org/pipermail/xenomai/2017-July/037515.html > > But this image doesn't boot on the new raspberrypi 3b+ board. So I had > to build a new image. I succeeded to build this image. The > instructions are at: > > https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/install_xenomai-3.0.8_on_rpi2_3_3B%2B.txt > > > Xenomai and handling gpio interrupts in realtime work fine on this > image, however somehow handling gpio interrupts in linux don't work > anymore. I have several test scripts using the wiringpi library within > linux. Writing and reading gpio pins works fine, but somehow we don't > get any interrupts. > > Even if do not load the xeno_gpio_bcm2835 module, then xenomai doesn't > use the gpio pins, but still then in linux with wiringpi examples we > don't get any gpio interrupts. > > However if I boot the standard raspbian image with the standard > raspbian kernel which does not support xenomai/cobalt then the > wiringpi examples work fine, and we get the gpio interrupts. > > In my older image from juli 2017 both in a realtime xenomai program or > in a wiringpi linux program I received interrupts. (when run > separately at different times, so they cannot influence each other; so > they are not sharing interrupts!) > > So I wonder why do the interrupts only work in xenomai realtime, and > not in linux anymore? > > Or is there something maybe changed because we now use > > * newer kernel version 4.9 instead of 4.1 > * xenomai 3.08 instead of xenomai 3.05 > > I would expect that it just should work, they are different points at > the pipeline, and either of them is only watching for interrupt it > should just
Re: linux not getting gpio interrupts on xenomai 3.0.8 on raspberrypi raspbian/stretch kernel 4.9
The ipipe patched not entirely cleanly on the rpi kernel source; I had to make little changes in the patch, but not anything really seriously. So I expect it to be fine. I used the rasbpian kernel source because it has better support for the raspberry pi's and mainly because it has better support for the gpio pins in its kernel. However to help you debug I did a similar install using the mainline kernel source. The ipipe patch just worked smoothly, however to get the gpio pins running in xenomai I had to still port some code of the file |./drivers/pinctrl/bcm/pinctrl-bcm2835.c| to the mainline kernel source. With this kernel I get the same problem : gpio pins work find with rtdm in xenomai, but they don't work with linux anymore. Unclear to me why? The description of this mainline installation and how to get my example scripts which show you that the linux gpio pins are not working are described in: https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/installation_of_xenomai_3.0.8_on_mainline_kernel_branch_v4.9.51_from_kernel.org__problem_linux_gpio.md Hope you can help me solving this problem? Xenomai gpio seems to work ok, and the image seems to be fine to be used in our course at the Radboud university. However because the fact that in linux the gpio pins don't work anymore does me little bit worry if it is really ok??? Is suspect something is wrong in|||./drivers/pinctrl/bcm/pinctrl-bcm2835.c . In my previous email I already described points where this file differs from the version in my previous raspian/rpi/xenomai image for which everything worked fine. So take a look at that. | I think to test you don't need an raspberry pi 3b+, byt an older raspberry pi 2 or a raspberry 3 would also suffice. Hopefully somebody can help me? Best regards, Harco Kuppens Op 13/06/2019 om 16:13 schreef Greg Gallagher: On Wed, Jun 12, 2019 at 5:40 PM Harco Kuppens via Xenomai wrote: I put the raspberry pi image with xenomai2 I build for the raspberry pi 2 and 3, also supporting the latest raspberry pi3b+ online at: http://www.cs.ru.nl/lab/xenomai/raspberrypi.html I'm still wondering what the reason is that I don't receive the gpio interrupts in linux. Unfortunately nobody could answer my questions so far. If somebody knows the problem, then I will fix the image. Except for this linux gpio interrupt problem the above image seems to work of for realtime xenomai gpio interrupts. Best regards, Harco Kuppens Op 07/06/2019 om 12:34 schreef Harco Kuppens via Xenomai: Hi, In juli 2017 I managed to port xenomai 3.0.5 to rasbpian jessie on the rpi3b. See https://xenomai.org/pipermail/xenomai/2017-July/037515.html But this image doesn't boot on the new raspberrypi 3b+ board. So I had to build a new image. I succeeded to build this image. The instructions are at: https://github.com/harcokuppens/xenomai3_rpi_gpio/blob/master/install/install_xenomai-3.0.8_on_rpi2_3_3B%2B.txt Xenomai and handling gpio interrupts in realtime work fine on this image, however somehow handling gpio interrupts in linux don't work anymore. I have several test scripts using the wiringpi library within linux. Writing and reading gpio pins works fine, but somehow we don't get any interrupts. Even if do not load the xeno_gpio_bcm2835 module, then xenomai doesn't use the gpio pins, but still then in linux with wiringpi examples we don't get any gpio interrupts. However if I boot the standard raspbian image with the standard raspbian kernel which does not support xenomai/cobalt then the wiringpi examples work fine, and we get the gpio interrupts. In my older image from juli 2017 both in a realtime xenomai program or in a wiringpi linux program I received interrupts. (when run separately at different times, so they cannot influence each other; so they are not sharing interrupts!) So I wonder why do the interrupts only work in xenomai realtime, and not in linux anymore? Or is there something maybe changed because we now use * newer kernel version 4.9 instead of 4.1 * xenomai 3.08 instead of xenomai 3.05 I would expect that it just should work, they are different points at the pipeline, and either of them is only watching for interrupt it should just get it. So instead maybe I did do something wrong when patching the rpi 4.9 kernel during the installation? Patching was not so easy because the raspbian os on the raspberry pi comes with a customized kernel specificly tuned for the raspberry pi hardware. I call this the rpi kernel. This kernel is little bit different then the standard kernel from kernel.org. I call this the kernel.org kernel. The ipipe patches for the kernel are made for the kernel.org kernels. However I managed pretty easily to patch the rpi 4.9 kernel with the the ipipe patch for the kernel.org 4.9 kernel. Except for the file pinctrl-bcm2835.c which is the driver for gpio interrupts. In my installation patching this file for the rpi 4.9 kernel was difficult,
Commands for reading, loading and unloading drivers on BeagleBone Black?
Hello, I am using a BeagleBone Black with Xenomai and RTnet on top. As some real-time programs are not working it could be that the installed drivers on my BeagleBone Black are still the standard drivers and not the real-time drivers. As I did not find anything on internet (only how to install drivers for Windows when using BeagleBone Black) I would like to ask you if anyobdy knows commands for BeagleBone Black to read, load and unload installed drivers on BBB? Regards Daniel
[PATCH] prepare-kernal.sh: Add --copylinks option
The prepare-kernal.sh script by default adds the xenomai kernel
components to the kernel source using soft links.
If you move/remove the xenomai source or move the patched kernel
source to another workstation, you must change all this links or even
replace them by the actual files.
To simplify the deployment of the patched kernel source to our
coworkers, we added the –copylinks option to the prepare-kernal.sh.
The option causes the prepare-kernal.sh to copy the xenomai kernel
components instead of linking them.
This makes it easy to move the patched kernel source to different locations.
Further, having the actual files in the kernel source makes the use of
tools like git grep that do not follow symbolic links by default more
convenient.
E.g. it gets harder to miss symbols searched with git grep by accident.
Signed-off-by: Johannes Kirchmair
---
scripts/prepare-kernel.sh | 47 +--
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/scripts/prepare-kernel.sh b/scripts/prepare-kernel.sh
index e88a9a757..b8cc5f6c1 100755
--- a/scripts/prepare-kernel.sh
+++ b/scripts/prepare-kernel.sh
@@ -84,6 +84,14 @@ patch_link() {
target_dir="$3"
link_dir="$4"
+
+ if test "x$5" = "x"
+ then
+ ln_cmd="ln -sf"
+ else
+ ln_cmd="cp -f"
+ fi
+
(
if test \! \( x$link_file = xm -o x$link_file = xn \); then
find_clean_opt="-name $link_file"
@@ -122,7 +130,7 @@ patch_link() {
if test x$forcelink = x1 -o \
! $xenomai_root/$target_dir/$f -ef $linux_tree/$link_dir/$f;
then
-ln -sf $xenomai_root/$target_dir/$f
$linux_tree/$link_dir/$f
+$ln_cmd $xenomai_root/$target_dir/$f
$linux_tree/$link_dir/$f
fi
else
if test `check_filter $link_dir/$f` = "ok"; then
@@ -150,6 +158,8 @@ generate_patch() {
usage='usage: prepare-kernel --linux= --ipipe=
[--arch=] [--outpatch= [--filterkvers=y|n] [--filterarch=y|n]]
[--forcelink] [--default] [--verbose]'
me=`basename $0`
+copylinks=""
+
while test $# -gt 0; do
case "$1" in
--linux=*)
@@ -182,6 +192,9 @@ while test $# -gt 0; do
--default)
usedefault=1
;;
+ --copylinks)
+ copylinks="1"
+ ;;
--verbose)
verbose=1
;;
@@ -416,23 +429,23 @@ esac
patch_kernelversion_specific="n"
patch_architecture_specific="y"
-patch_link r m kernel/cobalt/arch/$linux_arch arch/$linux_arch/xenomai
-patch_link n n kernel/cobalt/include/ipipe arch/$linux_arch/include/ipipe
+patch_link r m kernel/cobalt/arch/$linux_arch arch/$linux_arch/xenomai
$copylinks
+patch_link n n kernel/cobalt/include/ipipe arch/$linux_arch/include/ipipe
$copylinks
patch_architecture_specific="n"
-patch_link n m kernel/cobalt kernel/xenomai
-patch_link n cobalt-core.h kernel/cobalt/trace include/trace/events
-patch_link n cobalt-rtdm.h kernel/cobalt/trace include/trace/events
-patch_link n cobalt-posix.h kernel/cobalt/trace include/trace/events
-patch_link r n kernel/cobalt/include/asm-generic/xenomai
include/asm-generic/xenomai
-patch_link r n kernel/cobalt/include/linux/xenomai include/linux/xenomai
-patch_link n m kernel/cobalt/posix kernel/xenomai/posix
-patch_link n m kernel/cobalt/rtdm kernel/xenomai/rtdm
-patch_link r m kernel/drivers drivers/xenomai
-patch_link n n include/cobalt/kernel include/xenomai/cobalt/kernel
-patch_link r n include/cobalt/kernel/rtdm include/xenomai/rtdm
-patch_link r n include/cobalt/uapi include/xenomai/cobalt/uapi
-patch_link r n include/rtdm/uapi include/xenomai/rtdm/uapi
-patch_link n version.h include/xenomai include/xenomai
+patch_link n m kernel/cobalt kernel/xenomai $copylinks
+patch_link n cobalt-core.h kernel/cobalt/trace include/trace/events $copylinks
+patch_link n cobalt-rtdm.h kernel/cobalt/trace include/trace/events $copylinks
+patch_link n cobalt-posix.h kernel/cobalt/trace include/trace/events $copylinks
+patch_link r n kernel/cobalt/include/asm-generic/xenomai
include/asm-generic/xenomai $copylinks
+patch_link r n kernel/cobalt/include/linux/xenomai include/linux/xenomai
$copylinks
+patch_link n m kernel/cobalt/posix kernel/xenomai/posix $copylinks
+patch_link n m kernel/cobalt/rtdm kernel/xenomai/rtdm $copylinks
+patch_link r m kernel/drivers drivers/xenomai $copylinks
+patch_link n n include/cobalt/kernel include/xenomai/cobalt/kernel $copylinks
+patch_link r n include/cobalt/kernel/rtdm include/xenomai/rtdm $copylinks
+patch_link r n include/cobalt/uapi include/xenomai/cobalt/uapi $copylinks
+patch_link r n include/rtdm/uapi include/xenomai/rtdm/uapi $copylinks
+patch_link n version.h include/xenomai include/xenomai $copylinks
if test "x$output_patch" != "x"; then
if test x$verbose = x1; then
--
2.17.1
Re: Preview: 4.19-x86 support
On 18.06.19 23:20, Alec Ari wrote: Hi, a bit OT: How hard is it for you guys to re-write IPIPE on top of the latest entry_64.S file? I mean, every few kernel releases, especially when KAISER/RETROLINE was introduced, that file changed dramatically. Is x86 assembly programming easy for you Jan and Philippe? You're both extremely good at what you do. The Spectre/Meltdown fixes were actually widely orthogonal to I-pipe. Porting to 4.19 had a few conflicts in the entry code, but nothing that was awfully hard to resolve when looking at the old I-pipe patch and the changes to that file in mainline since then. Thanks to Philippe's rework of the patch queue, we have a functional split-up now that helps rebasing the patches. It can and will be further improved, but it is already valuable, hopefully also for other contributors: We definitely need more people on these kernel topics. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
