| Message ID | 20240508070412.2939015-1-mingli.yu@windriver.com |
|---|---|
| State | New |
| Headers | show |
| Series | [yocto-kernel-cache] preempt-rt: add bfp configs by default | expand |
In message: [yocto-patches] [yocto-kernel-cache][PATCH] preempt-rt: add bfp configs by default on 08/05/2024 Yu, Mingli via lists.yoctoproject.org wrote: > From: Mingli Yu <mingli.yu@windriver.com> > > Userspace functionality that requires BPF is becoming more common, > so enable it by default [1]. bpf used to have locking issues with preempt-rt, which is why it isn't already enabled. Can you show some logs for your testing that has happened with BPF enabled -rt so that we can document what has been done to prove it works now. Bruce > > [1] https://lore.kernel.org/all/20200224140131.461979697@linutronix.de/ > > Signed-off-by: Mingli Yu <mingli.yu@windriver.com> > --- > ktypes/preempt-rt/preempt-rt.scc | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/ktypes/preempt-rt/preempt-rt.scc b/ktypes/preempt-rt/preempt-rt.scc > index 7ff7c0a8..a5e345f9 100644 > --- a/ktypes/preempt-rt/preempt-rt.scc > +++ b/ktypes/preempt-rt/preempt-rt.scc > @@ -39,3 +39,4 @@ include backports/backports.scc > include features/rt/rt.scc > > kconf non-hardware preempt-rt.cfg > +include features/bpf/bpf.scc > -- > 2.25.1 > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#89): https://lists.yoctoproject.org/g/yocto-patches/message/89 > Mute This Topic: https://lists.yoctoproject.org/mt/105976633/1050810 > Group Owner: yocto-patches+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13171493/1050810/607820704/xyzzy [bruce.ashfield@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On 5/9/24 01:33, Bruce Ashfield wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > In message: [yocto-patches] [yocto-kernel-cache][PATCH] preempt-rt: add bfp configs by default > on 08/05/2024 Yu, Mingli via lists.yoctoproject.org wrote: > >> From: Mingli Yu <mingli.yu@windriver.com> >> >> Userspace functionality that requires BPF is becoming more common, >> so enable it by default [1]. > > bpf used to have locking issues with preempt-rt, which is > why it isn't already enabled. > > Can you show some logs for your testing that has happened > with BPF enabled -rt so that we can document what has been > done to prove it works now. When CONFIG_BPF_SYSCALL is't enabled, there comes below failure with rt kernel. # docker run hello-world Unable to find image 'hello-world:latest' locally latest: Pulling from library/hello-world c1ec31eb5944: Already exists Digest: sha256:a26bff933ddc26d5cdf7faa98b4ae1e3ec20c4985e6f87ac0973052224d24302 Status: Downloaded newer image for hello-world:latest docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown. ERRO[0059] error waiting for container: context canceled And the above issue is resolved once CONFIG_BPF_SYSCALL enabled. Thanks, > > Bruce > >> >> [1] https://lore.kernel.org/all/20200224140131.461979697@linutronix.de/ >> >> Signed-off-by: Mingli Yu <mingli.yu@windriver.com> >> --- >> ktypes/preempt-rt/preempt-rt.scc | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/ktypes/preempt-rt/preempt-rt.scc b/ktypes/preempt-rt/preempt-rt.scc >> index 7ff7c0a8..a5e345f9 100644 >> --- a/ktypes/preempt-rt/preempt-rt.scc >> +++ b/ktypes/preempt-rt/preempt-rt.scc >> @@ -39,3 +39,4 @@ include backports/backports.scc >> include features/rt/rt.scc >> >> kconf non-hardware preempt-rt.cfg >> +include features/bpf/bpf.scc >> -- >> 2.25.1 >> >> >> >> >> >> > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#104): https://lists.yoctoproject.org/g/yocto-patches/message/104 > Mute This Topic: https://lists.yoctoproject.org/mt/105976633/3618448 > Group Owner: yocto-patches+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13176015/3618448/1484545583/xyzzy [mingli.yu@eng.windriver.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On 5/9/24 10:14, Yu, Mingli wrote: > > > On 5/9/24 01:33, Bruce Ashfield wrote: >> CAUTION: This email comes from a non Wind River email account! >> Do not click links or open attachments unless you recognize the sender >> and know the content is safe. >> >> In message: [yocto-patches] [yocto-kernel-cache][PATCH] preempt-rt: >> add bfp configs by default >> on 08/05/2024 Yu, Mingli via lists.yoctoproject.org wrote: >> >>> From: Mingli Yu <mingli.yu@windriver.com> >>> >>> Userspace functionality that requires BPF is becoming more common, >>> so enable it by default [1]. >> >> bpf used to have locking issues with preempt-rt, which is >> why it isn't already enabled. >> >> Can you show some logs for your testing that has happened >> with BPF enabled -rt so that we can document what has been >> done to prove it works now. > > When CONFIG_BPF_SYSCALL is't enabled, there comes below failure with rt > kernel. > # docker run hello-world > Unable to find image 'hello-world:latest' locally > latest: Pulling from library/hello-world > c1ec31eb5944: Already exists > Digest: > sha256:a26bff933ddc26d5cdf7faa98b4ae1e3ec20c4985e6f87ac0973052224d24302 > Status: Downloaded newer image for hello-world:latest > docker: Error response from daemon: failed to create task for container: > failed to create shim task: OCI runtime create failed: runc create > failed: unable to start container process: error during container init: > error setting cgroup config for procHooks process: > bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: > unknown. > ERRO[0059] error waiting for container: context canceled > > And the above issue is resolved once CONFIG_BPF_SYSCALL enabled. And it seems the BPF with rt kernel issues have been fixed by Thomas as https://lore.kernel.org/all/20200224140131.461979697@linutronix.de/. Thanks, > > Thanks, > >> >> Bruce >> >>> >>> [1] https://lore.kernel.org/all/20200224140131.461979697@linutronix.de/ >>> >>> Signed-off-by: Mingli Yu <mingli.yu@windriver.com> >>> --- >>> ktypes/preempt-rt/preempt-rt.scc | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/ktypes/preempt-rt/preempt-rt.scc >>> b/ktypes/preempt-rt/preempt-rt.scc >>> index 7ff7c0a8..a5e345f9 100644 >>> --- a/ktypes/preempt-rt/preempt-rt.scc >>> +++ b/ktypes/preempt-rt/preempt-rt.scc >>> @@ -39,3 +39,4 @@ include backports/backports.scc >>> include features/rt/rt.scc >>> >>> kconf non-hardware preempt-rt.cfg >>> +include features/bpf/bpf.scc >>> -- >>> 2.25.1 >>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#106): > https://lists.yoctoproject.org/g/yocto-patches/message/106 > Mute This Topic: https://lists.yoctoproject.org/mt/105976633/3618448 > Group Owner: yocto-patches+owner@lists.yoctoproject.org > Unsubscribe: > https://lists.yoctoproject.org/g/yocto-patches/leave/13176015/3618448/1484545583/xyzzy [mingli.yu@eng.windriver.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On Wed, May 8, 2024 at 10:14 PM Yu, Mingli via lists.yoctoproject.org <mingli.yu=eng.windriver.com@lists.yoctoproject.org> wrote: > > > > On 5/9/24 01:33, Bruce Ashfield wrote: > > CAUTION: This email comes from a non Wind River email account! > > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > In message: [yocto-patches] [yocto-kernel-cache][PATCH] preempt-rt: add bfp configs by default > > on 08/05/2024 Yu, Mingli via lists.yoctoproject.org wrote: > > > >> From: Mingli Yu <mingli.yu@windriver.com> > >> > >> Userspace functionality that requires BPF is becoming more common, > >> so enable it by default [1]. > > > > bpf used to have locking issues with preempt-rt, which is > > why it isn't already enabled. > > > > Can you show some logs for your testing that has happened > > with BPF enabled -rt so that we can document what has been > > done to prove it works now. > > When CONFIG_BPF_SYSCALL is't enabled, there comes below failure with rt > kernel. > # docker run hello-world > Unable to find image 'hello-world:latest' locally > latest: Pulling from library/hello-world > c1ec31eb5944: Already exists > Digest: > sha256:a26bff933ddc26d5cdf7faa98b4ae1e3ec20c4985e6f87ac0973052224d24302 > Status: Downloaded newer image for hello-world:latest > docker: Error response from daemon: failed to create task for container: > failed to create shim task: OCI runtime create failed: runc create > failed: unable to start container process: error during container init: > error setting cgroup config for procHooks process: > bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown. > ERRO[0059] error waiting for container: context canceled > > And the above issue is resolved once CONFIG_BPF_SYSCALL enabled. Being able to run docker on preempt-rt isn't a use case that I consider high priority. Not that it is a bad use case it is that if we want -rt to have any value, we actually need to show that realtime behaviour is preserved as we enable more options and run different workloads. Getting docker to pull an image doesn't prove/show that -rt and BPF aren't going to spike latencies, or cause other issues. BPF used to cause locking issues and other latency issues. There are BPF self tests, showing that they run and pass is a good first step. Then also running the latency measurements while running both BPF tests and pulling, deleting, pulling, running, etc, containers is the second thing we need to show. If there aren't any latency spikes or locking traces we can consider it "safe enough" to enable for -rt. Bruce > > Thanks, > > > > > Bruce > > > >> > >> [1] https://lore.kernel.org/all/20200224140131.461979697@linutronix.de/ > >> > >> Signed-off-by: Mingli Yu <mingli.yu@windriver.com> > >> --- > >> ktypes/preempt-rt/preempt-rt.scc | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/ktypes/preempt-rt/preempt-rt.scc b/ktypes/preempt-rt/preempt-rt.scc > >> index 7ff7c0a8..a5e345f9 100644 > >> --- a/ktypes/preempt-rt/preempt-rt.scc > >> +++ b/ktypes/preempt-rt/preempt-rt.scc > >> @@ -39,3 +39,4 @@ include backports/backports.scc > >> include features/rt/rt.scc > >> > >> kconf non-hardware preempt-rt.cfg > >> +include features/bpf/bpf.scc > >> -- > >> 2.25.1 > >> > >> > >> > >> > >> > >> > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#106): https://lists.yoctoproject.org/g/yocto-patches/message/106 > Mute This Topic: https://lists.yoctoproject.org/mt/105976633/1050810 > Group Owner: yocto-patches+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13171493/1050810/607820704/xyzzy [bruce.ashfield@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On Wed, May 8, 2024 at 11:09 PM Yu, Mingli <mingli.yu@windriver.com> wrote: > > > > On 5/9/24 10:14, Yu, Mingli wrote: > > > > > > On 5/9/24 01:33, Bruce Ashfield wrote: > >> CAUTION: This email comes from a non Wind River email account! > >> Do not click links or open attachments unless you recognize the sender > >> and know the content is safe. > >> > >> In message: [yocto-patches] [yocto-kernel-cache][PATCH] preempt-rt: > >> add bfp configs by default > >> on 08/05/2024 Yu, Mingli via lists.yoctoproject.org wrote: > >> > >>> From: Mingli Yu <mingli.yu@windriver.com> > >>> > >>> Userspace functionality that requires BPF is becoming more common, > >>> so enable it by default [1]. > >> > >> bpf used to have locking issues with preempt-rt, which is > >> why it isn't already enabled. > >> > >> Can you show some logs for your testing that has happened > >> with BPF enabled -rt so that we can document what has been > >> done to prove it works now. > > > > When CONFIG_BPF_SYSCALL is't enabled, there comes below failure with rt > > kernel. > > # docker run hello-world > > Unable to find image 'hello-world:latest' locally > > latest: Pulling from library/hello-world > > c1ec31eb5944: Already exists > > Digest: > > sha256:a26bff933ddc26d5cdf7faa98b4ae1e3ec20c4985e6f87ac0973052224d24302 > > Status: Downloaded newer image for hello-world:latest > > docker: Error response from daemon: failed to create task for container: > > failed to create shim task: OCI runtime create failed: runc create > > failed: unable to start container process: error during container init: > > error setting cgroup config for procHooks process: > > bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: > > unknown. > > ERRO[0059] error waiting for container: context canceled > > > > And the above issue is resolved once CONFIG_BPF_SYSCALL enabled. > > And it seems the BPF with rt kernel issues have been fixed by Thomas as > https://lore.kernel.org/all/20200224140131.461979697@linutronix.de/. > We still need to do our own proofs, as I outlined in my previous email. Bruce > Thanks, > > > > > Thanks, > > > >> > >> Bruce > >> > >>> > >>> [1] https://lore.kernel.org/all/20200224140131.461979697@linutronix.de/ > >>> > >>> Signed-off-by: Mingli Yu <mingli.yu@windriver.com> > >>> --- > >>> ktypes/preempt-rt/preempt-rt.scc | 1 + > >>> 1 file changed, 1 insertion(+) > >>> > >>> diff --git a/ktypes/preempt-rt/preempt-rt.scc > >>> b/ktypes/preempt-rt/preempt-rt.scc > >>> index 7ff7c0a8..a5e345f9 100644 > >>> --- a/ktypes/preempt-rt/preempt-rt.scc > >>> +++ b/ktypes/preempt-rt/preempt-rt.scc > >>> @@ -39,3 +39,4 @@ include backports/backports.scc > >>> include features/rt/rt.scc > >>> > >>> kconf non-hardware preempt-rt.cfg > >>> +include features/bpf/bpf.scc > >>> -- > >>> 2.25.1 > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > >> > >> > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#106): > > https://lists.yoctoproject.org/g/yocto-patches/message/106 > > Mute This Topic: https://lists.yoctoproject.org/mt/105976633/3618448 > > Group Owner: yocto-patches+owner@lists.yoctoproject.org > > Unsubscribe: > > https://lists.yoctoproject.org/g/yocto-patches/leave/13176015/3618448/1484545583/xyzzy [mingli.yu@eng.windriver.com] > > -=-=-=-=-=-=-=-=-=-=-=- > > > >
On 5/9/24 11:22, Bruce Ashfield wrote: > CAUTION: This email comes from a non Wind River email account! > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > On Wed, May 8, 2024 at 10:14 PM Yu, Mingli via lists.yoctoproject.org > <mingli.yu=eng.windriver.com@lists.yoctoproject.org> wrote: >> >> >> >> On 5/9/24 01:33, Bruce Ashfield wrote: >>> CAUTION: This email comes from a non Wind River email account! >>> Do not click links or open attachments unless you recognize the sender and know the content is safe. >>> >>> In message: [yocto-patches] [yocto-kernel-cache][PATCH] preempt-rt: add bfp configs by default >>> on 08/05/2024 Yu, Mingli via lists.yoctoproject.org wrote: >>> >>>> From: Mingli Yu <mingli.yu@windriver.com> >>>> >>>> Userspace functionality that requires BPF is becoming more common, >>>> so enable it by default [1]. >>> >>> bpf used to have locking issues with preempt-rt, which is >>> why it isn't already enabled. >>> >>> Can you show some logs for your testing that has happened >>> with BPF enabled -rt so that we can document what has been >>> done to prove it works now. >> >> When CONFIG_BPF_SYSCALL is't enabled, there comes below failure with rt >> kernel. >> # docker run hello-world >> Unable to find image 'hello-world:latest' locally >> latest: Pulling from library/hello-world >> c1ec31eb5944: Already exists >> Digest: >> sha256:a26bff933ddc26d5cdf7faa98b4ae1e3ec20c4985e6f87ac0973052224d24302 >> Status: Downloaded newer image for hello-world:latest >> docker: Error response from daemon: failed to create task for container: >> failed to create shim task: OCI runtime create failed: runc create >> failed: unable to start container process: error during container init: >> error setting cgroup config for procHooks process: >> bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown. >> ERRO[0059] error waiting for container: context canceled >> >> And the above issue is resolved once CONFIG_BPF_SYSCALL enabled. > > Being able to run docker on preempt-rt isn't a use case that I > consider high priority. Not that it is a bad use case it is that if we want > -rt to have any value, we actually need to show that realtime behaviour > is preserved as we enable more options and run different workloads. > > Getting docker to pull an image doesn't prove/show that -rt and BPF > aren't going to spike latencies, or cause other issues. > > BPF used to cause locking issues and other latency issues. > > There are BPF self tests, showing that they run and pass is a good > first step. > > Then also running the latency measurements while running both > BPF tests and pulling, deleting, pulling, running, etc, containers is > the second thing we need to show. If there aren't any latency > spikes or locking traces we can consider it "safe enough" to enable > for -rt. Thanks Bruce for your clarification! I'm not familiar with BPF tests, so can't provide the test results right now. I'm okay with your concerns. Thanks, > > Bruce > >> >> Thanks, >> >>> >>> Bruce >>> >>>> >>>> [1] https://lore.kernel.org/all/20200224140131.461979697@linutronix.de/ >>>> >>>> Signed-off-by: Mingli Yu <mingli.yu@windriver.com> >>>> --- >>>> ktypes/preempt-rt/preempt-rt.scc | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/ktypes/preempt-rt/preempt-rt.scc b/ktypes/preempt-rt/preempt-rt.scc >>>> index 7ff7c0a8..a5e345f9 100644 >>>> --- a/ktypes/preempt-rt/preempt-rt.scc >>>> +++ b/ktypes/preempt-rt/preempt-rt.scc >>>> @@ -39,3 +39,4 @@ include backports/backports.scc >>>> include features/rt/rt.scc >>>> >>>> kconf non-hardware preempt-rt.cfg >>>> +include features/bpf/bpf.scc >>>> -- >>>> 2.25.1 >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> >> > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#108): https://lists.yoctoproject.org/g/yocto-patches/message/108 > Mute This Topic: https://lists.yoctoproject.org/mt/105976633/3618448 > Group Owner: yocto-patches+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13176015/3618448/1484545583/xyzzy [mingli.yu@eng.windriver.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On Thu, May 9, 2024 at 1:40 AM Yu, Mingli <mingli.yu@windriver.com> wrote: > > > > On 5/9/24 11:22, Bruce Ashfield wrote: > > CAUTION: This email comes from a non Wind River email account! > > Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > On Wed, May 8, 2024 at 10:14 PM Yu, Mingli via lists.yoctoproject.org > > <mingli.yu=eng.windriver.com@lists.yoctoproject.org> wrote: > >> > >> > >> > >> On 5/9/24 01:33, Bruce Ashfield wrote: > >>> CAUTION: This email comes from a non Wind River email account! > >>> Do not click links or open attachments unless you recognize the sender and know the content is safe. > >>> > >>> In message: [yocto-patches] [yocto-kernel-cache][PATCH] preempt-rt: add bfp configs by default > >>> on 08/05/2024 Yu, Mingli via lists.yoctoproject.org wrote: > >>> > >>>> From: Mingli Yu <mingli.yu@windriver.com> > >>>> > >>>> Userspace functionality that requires BPF is becoming more common, > >>>> so enable it by default [1]. > >>> > >>> bpf used to have locking issues with preempt-rt, which is > >>> why it isn't already enabled. > >>> > >>> Can you show some logs for your testing that has happened > >>> with BPF enabled -rt so that we can document what has been > >>> done to prove it works now. > >> > >> When CONFIG_BPF_SYSCALL is't enabled, there comes below failure with rt > >> kernel. > >> # docker run hello-world > >> Unable to find image 'hello-world:latest' locally > >> latest: Pulling from library/hello-world > >> c1ec31eb5944: Already exists > >> Digest: > >> sha256:a26bff933ddc26d5cdf7faa98b4ae1e3ec20c4985e6f87ac0973052224d24302 > >> Status: Downloaded newer image for hello-world:latest > >> docker: Error response from daemon: failed to create task for container: > >> failed to create shim task: OCI runtime create failed: runc create > >> failed: unable to start container process: error during container init: > >> error setting cgroup config for procHooks process: > >> bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown. > >> ERRO[0059] error waiting for container: context canceled > >> > >> And the above issue is resolved once CONFIG_BPF_SYSCALL enabled. > > > > Being able to run docker on preempt-rt isn't a use case that I > > consider high priority. Not that it is a bad use case it is that if we want > > -rt to have any value, we actually need to show that realtime behaviour > > is preserved as we enable more options and run different workloads. > > > > Getting docker to pull an image doesn't prove/show that -rt and BPF > > aren't going to spike latencies, or cause other issues. > > > > BPF used to cause locking issues and other latency issues. > > > > There are BPF self tests, showing that they run and pass is a good > > first step. > > > > Then also running the latency measurements while running both > > BPF tests and pulling, deleting, pulling, running, etc, containers is > > the second thing we need to show. If there aren't any latency > > spikes or locking traces we can consider it "safe enough" to enable > > for -rt. > > Thanks Bruce for your clarification! > > I'm not familiar with BPF tests, so can't provide the test results right > now. I'm okay with your concerns. If you have any issues, let me know. I'm trying to create an automated latency test image for -rt in the next few months, and running tests like these while measuring latency is a good starting point (which means I can spend some time on it as well). Bruce > > Thanks, > > > > > Bruce > > > >> > >> Thanks, > >> > >>> > >>> Bruce > >>> > >>>> > >>>> [1] https://lore.kernel.org/all/20200224140131.461979697@linutronix.de/ > >>>> > >>>> Signed-off-by: Mingli Yu <mingli.yu@windriver.com> > >>>> --- > >>>> ktypes/preempt-rt/preempt-rt.scc | 1 + > >>>> 1 file changed, 1 insertion(+) > >>>> > >>>> diff --git a/ktypes/preempt-rt/preempt-rt.scc b/ktypes/preempt-rt/preempt-rt.scc > >>>> index 7ff7c0a8..a5e345f9 100644 > >>>> --- a/ktypes/preempt-rt/preempt-rt.scc > >>>> +++ b/ktypes/preempt-rt/preempt-rt.scc > >>>> @@ -39,3 +39,4 @@ include backports/backports.scc > >>>> include features/rt/rt.scc > >>>> > >>>> kconf non-hardware preempt-rt.cfg > >>>> +include features/bpf/bpf.scc > >>>> -- > >>>> 2.25.1 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > >> > >> > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#108): https://lists.yoctoproject.org/g/yocto-patches/message/108 > > Mute This Topic: https://lists.yoctoproject.org/mt/105976633/3618448 > > Group Owner: yocto-patches+owner@lists.yoctoproject.org > > Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13176015/3618448/1484545583/xyzzy [mingli.yu@eng.windriver.com] > > -=-=-=-=-=-=-=-=-=-=-=- > > > >
On Wed, May 8, 2024 at 9:04 AM Yu, Mingli via lists.yoctoproject.org <mingli.yu=eng.windriver.com@lists.yoctoproject.org> wrote: > From: Mingli Yu <mingli.yu@windriver.com> > > Userspace functionality that requires BPF is becoming more common, > so enable it by default [1]. > > [1] https://lore.kernel.org/all/20200224140131.461979697@linutronix.de/ > > Signed-off-by: Mingli Yu <mingli.yu@windriver.com> > For a big feature (and attack vector) like bpf, I think it would make sense to create a new DISTRO_FEATURE or so. People who want bpf can enable it (probably they already do), others do not have a feature they do not need. PS. Yocto kernel options review is one of the things on my TODO list after we're done with the CVE crisis... Regards, Marta
On Thu, May 9, 2024 at 9:01 AM Marta Rybczynska via lists.yoctoproject.org <rybczynska=gmail.com@lists.yoctoproject.org> wrote: > > > > On Wed, May 8, 2024 at 9:04 AM Yu, Mingli via lists.yoctoproject.org <mingli.yu=eng.windriver.com@lists.yoctoproject.org> wrote: >> >> From: Mingli Yu <mingli.yu@windriver.com> >> >> Userspace functionality that requires BPF is becoming more common, >> so enable it by default [1]. >> >> [1] https://lore.kernel.org/all/20200224140131.461979697@linutronix.de/ >> >> Signed-off-by: Mingli Yu <mingli.yu@windriver.com> > > > For a big feature (and attack vector) like bpf, I think it would make sense to create a new > DISTRO_FEATURE or so. People who want bpf can enable it (probably they already do), > others do not have a feature they do not need. > For the kernel configuration, I'll argue against that. They should be creating their own kernel type and re-using the fragments in their own way. The base kernel configuration, in particular for large features, should not be conditional and cobbled together with distro features. The kernel tools themselves have support for conditional processing, which is where anything optional/configurable needs to be, not spread across layers, .bb files, variables, and combinations of conditionals. Bruce > PS. Yocto kernel options review is one of the things on my TODO list after we're done with > the CVE crisis... > > Regards, > Marta > _._,_._,_ > ________________________________ > Links: > > You receive all messages sent to this group. > > View/Reply Online (#113) | Reply To Group | Reply To Sender | Mute This Topic | New Topic > Your Subscription | Contact Group Owner | Unsubscribe [bruce.ashfield@gmail.com] > > _._,_._,_
diff --git a/ktypes/preempt-rt/preempt-rt.scc b/ktypes/preempt-rt/preempt-rt.scc index 7ff7c0a8..a5e345f9 100644 --- a/ktypes/preempt-rt/preempt-rt.scc +++ b/ktypes/preempt-rt/preempt-rt.scc @@ -39,3 +39,4 @@ include backports/backports.scc include features/rt/rt.scc kconf non-hardware preempt-rt.cfg +include features/bpf/bpf.scc