07:15:15 * ** rajm has joined #cip
07:54:04 * rajm runs a successful BBB health check with email to the list
07:54:07 * ** toscalix has joined #cip
08:46:04 * ** vidda_ has joined #cip
08:51:51 * ** moxavictor has joined #cip
08:55:23 <szlin> The meeting will be started after 5 minutes
08:55:26 * ** Tzongyen_Lin has joined #cip
09:00:17 <szlin> #startmeeting
09:00:20 <szlin> #topic roll call
09:00:28 <gavinlai> hi
09:00:29 <szlin> please say hi if you're in this meeting
09:00:34 <moxavictor> hi
09:00:35 <szlin> ._./~\
09:00:37 <vidda_> hi
09:00:38 <Tzongyen_Lin> hi
09:00:45 <bwh> hi
09:01:36 <szlin> #topic kernel patch review update
09:01:49 <weshuang> hi
09:02:13 <szlin> Moxa team is still reviewing patch 4.4.130
09:02:20 <toscalix> hi
09:02:51 <szlin> we do have some questions while reivewing it
09:03:12 <szlin> gavinlai: please go ahead
09:03:31 <gavinlai> I have two questions
09:03:36 <rajm> hi (sorry I'm late)
09:04:24 <gavinlai> when we review the code, do we need to write some code to test them? I'm not very confident to just 'review' it
09:04:59 <gavinlai> the second question is: If a bug needs time to reproduce or hard to reproduce, how do we make sure the bug is fixed correctly?
09:05:31 <bwh> gavinlai: If you want to, you could write a test. In some cases there is a relevant selftest in the kernel (maybe only upstream, not in 4.4)
09:06:41 <szlin> sometime we need to backport the selftest first if there are not in the 4.4
09:06:51 <bwh> Generally I think we should assume that the fix was tested when the patch was originally applied. And we are looking for reasons why that fix might not be valid for 4.4, or might cause regressions.
09:08:44 <gavinlai> A friend told me I can put functions into userspace. And, input all kinds of input to function to verify the function is robust.
09:08:46 <bwh> szlin: Well maybe, but that isn't being done consistently. I generally use the selftests from the current upstream kernel with minimal changes
09:09:08 <gavinlai> Is that a good way to test the functions?
09:09:17 <bwh> Those will produce lots of failures due to missing features in the older version I'm looking at, but I can still test for regressions
09:09:39 <bwh> gavinlai: It really depends on what is being fixed. Only a few parts of the kernel have good selftests.
09:11:05 <szlin> bwh: I see, thanks.
09:11:10 <bwh> gavinlai: Sorry, I missed your previous comment ("A friend tod me ...")
09:11:53 <bwh> Yes, that can work for some functions where you can easily isolate inputs and outputs
09:11:53 <gavinlai> A friend told me I can put functions into userspace.
09:11:58 <gavinlai> And, input all kinds of input to function to verify the function is robust.
09:13:31 * ** HarryYJ_Jhou has joined #cip
09:14:08 <gavinlai> If a feature is lack of selftests, is there any good way to verify them?
09:14:50 <bwh> In some cases there are external tests like LTP and xfstests (which is for all filesystems, not just xfs)
09:15:01 <bwh> But those can take a long time to set up and run
09:15:10 <moxavictor> I have a question. Now we review kernel foundation to CIP. Some day foundation does not maintion version 4.4. How we review the applied code OK or fail ?
09:16:30 <bwh> moxavictor: It's really just Greg, not the Linux Foundation (even though they employ him). CIP will have to take over Greg's role too.
09:17:29 <bwh> There are scripts for maintaining stable branches - Greg K-H, Alexander Levin and I have published ours
09:18:03 <moxavictor> Do we need to test CIP kernel ?
09:18:13 <toscalix> yes
09:18:31 <toscalix> moxavictor: you will catch bugs
09:18:32 <szlin> Now rajm is testing CIP kernel via kernelci & lava
09:18:53 <szlin> https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting
09:19:00 <toscalix> some of them due to platform specific patches applied only to the CIP kernel but other also affecting 4.4 or even other versions
09:19:06 <rajm> indeed - we've just had a fire practice - sorry if there was a delay here!
09:19:09 <bwh> Right, but rajm is mostly occupied just keeping the automation going. We need to add test cases/test suites
09:19:51 <toscalix> bwh: is correct, we are in need to adding tests and inspecting results for CIP specific platforms
09:20:16 <toscalix> I would love to see us also helping upstream in evaluating the bugs out of kernelci
09:20:29 <toscalix> in kernelci.org for 4.4-stable on BBB
09:20:44 <toscalix> or even add renesas board to that pull
09:21:09 <toscalix> Renesas is working with the Linux Foundation in our own kernelci set up
09:21:22 <toscalix> we can do it there and help upstream at the same time
09:21:33 <szlin> AFAIK, Daniel from Toshiba had used LTP to test kernel
09:21:39 <toscalix> having a lab in Moxa facilities
09:21:43 <moxavictor> The testing need hardware. Could we offer some hardware and let tester remote to test it ?
09:21:44 <toscalix> with CIP platforms
09:21:44 <szlin> and he had sent some patches afterwards.
09:22:08 <toscalix> moxavictor: the first point is to include your hardware as CIP hardware
09:22:43 <toscalix> which will require that you include the hardware support updtream
09:22:52 <toscalix> we had a meeting a while back about it
09:23:47 <toscalix> we would love to have Moxa hardware as an official CIP platform. I assume that is a great movivation for Moxa to join as well
09:24:05 <toscalix> there is just some homework to be done to reach that point
09:24:11 <toscalix> just like Renesas did
09:24:16 <moxavictor> Good. We also like to be a CIP hardware.
09:24:53 <szlin> any questions?
09:25:13 <moxavictor> I have a question
09:26:31 <szlin> bwh: How do you think with Kernel Self Protection Project?
09:26:42 <moxavictor> I mean if Moxa platform is a CIP hardware, and put it In Taiwan, can you remote to control and test it ?
09:27:37 <bwh> szlin: It's good, but hard to backport the features it's adding so it will be more useful to the next CIP kernel branch
09:27:56 <toscalix> rajm: is the LAVA guy, I will let him answer the question
09:29:18 <rajm> the question - abt remote control? the existing setup with b@d is very much a local environment
09:29:36 <szlin> bwh: thanks.
09:29:40 <moxavictor> yes
09:30:08 <toscalix> but the set up Renesas is building for CIP is similar to AGL one, based on kernelci.org
09:30:25 <toscalix> in that set up, labs are distributed
09:30:40 <toscalix> and developers can access those labs remotely and execute tests
09:31:05 <moxavictor> yes, do we want to create it ?
09:31:15 <toscalix> so yes, you will be able to have the hardware at your office and have developers around the world accessing to it to test
09:31:59 <toscalix> it will be up to Moxa to decide if you want to create your own lab or not and report results to the CIP dashboard
09:32:49 <toscalix> at Codethink, we will try to work on adapting B@D to the CIP set up so you ca publish the results you get locally without needing to set up a lab
09:32:52 <moxavictor> you can remote to get the testing report
09:33:01 <toscalix> yes you can
09:33:13 <toscalix> but you can also restrict what you share
09:33:32 <szlin> Next step we will setup the B@D.
09:34:11 <toscalix> B@D is meant to be cheap and easy to maintain, a development resource, not a delivery (QA) resource
09:34:45 <toscalix> but you guys are used to the concept of a lab since you manufacture hardware, so I guess you will welcome both
09:35:32 <szlin> Indeed
09:35:36 <toscalix> It will not surprise me if you end up setting your own internal kernelci service, like other big companies have
09:36:12 <szlin> any questions?
09:36:27 <szlin> #topic Miscellaneous
09:36:36 <moxavictor> I want to offer some hardware to let some people to test it.
09:37:14 <szlin> toscalix: as victor mentioned, we will follow the procedure and to let our board become CIP board.
09:37:34 <moxavictor> Could I ask a question about kernel graphic device driver ?
09:39:19 <moxavictor> Now I try i.MX8MQ EVK to start XWindows. But I run startx to get a error "No screen found". What happens it ?
09:40:11 <moxavictor> I can enable text mode login terminal by HDMI monitor.
09:40:51 <bwh> moxavictor: There are many reasons why they could happen. I don't think it makes sense to debug in this meeting
09:41:14 <szlin> any questions?
09:41:25 <moxavictor> yes, I know, Could I talk with you some where ?
09:41:50 <moxavictor> Thanks
09:42:01 <bwh> moxavictor: After the meeting
09:42:02 <bwh> hjere
09:42:05 <szlin> #endmeeting