| Message ID | 1442761327-18830-1-git-send-email-yba@tkos.co.il |
|---|---|
| State | Changes Requested |
| Headers | show |
Dear Jonathan Ben-Avraham, On Sun, 20 Sep 2015 18:02:07 +0300, Jonathan Ben-Avraham wrote: > From: Jonathan Ben Avraham <yba@tkos.co.il> > > lxc executables such as lxc-checkconfig require scripts provided by > gzip such as zgrep. > > Signed-off-by: Jonathan Ben Avraham <yba@tkos.co.il> > --- > package/lxc/Config.in | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/package/lxc/Config.in b/package/lxc/Config.in > index ffd9b4a..5377977 100644 > --- a/package/lxc/Config.in > +++ b/package/lxc/Config.in > @@ -1,6 +1,7 @@ > config BR2_PACKAGE_LXC > bool "lxc" > select BR2_PACKAGE_LIBCAP > + select BR2_PACKAGE_GZIP # runtime, for lxc-checkconfig BR2_PACKAGE_GZIP depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS, so you should select it as well. Thanks! Thomas
Hi Thomas, On Sun, 20 Sep 2015, Thomas Petazzoni wrote: > Date: Sun, 20 Sep 2015 19:06:22 +0200 > From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > To: Jonathan Ben-Avraham <yba@tkos.co.il> > Cc: buildroot@buildroot.org > Subject: Re: [Buildroot] [PATCH 1/1] lxc needs gzip scripts for > lxc-checkconfig runtime > > Dear Jonathan Ben-Avraham, > > On Sun, 20 Sep 2015 18:02:07 +0300, Jonathan Ben-Avraham wrote: >> From: Jonathan Ben Avraham <yba@tkos.co.il> >> >> lxc executables such as lxc-checkconfig require scripts provided by >> gzip such as zgrep. >> >> Signed-off-by: Jonathan Ben Avraham <yba@tkos.co.il> >> --- >> package/lxc/Config.in | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/package/lxc/Config.in b/package/lxc/Config.in >> index ffd9b4a..5377977 100644 >> --- a/package/lxc/Config.in >> +++ b/package/lxc/Config.in >> @@ -1,6 +1,7 @@ >> config BR2_PACKAGE_LXC >> bool "lxc" >> select BR2_PACKAGE_LIBCAP >> + select BR2_PACKAGE_GZIP # runtime, for lxc-checkconfig > > BR2_PACKAGE_GZIP depends on BR2_PACKAGE_BUSYBOX_SHOW_OTHERS, so you > should select it as well. > > Thanks! > > Thomas I wondered whether to send a patch for each 'select' individually or to wait until I complete my testing and submit a single patch with all of the lxc selects. What do you prefer? - yba
Jonathan, On Sun, 20 Sep 2015 20:15:02 +0300 (IDT), Jonathan Ben Avraham wrote: > I wondered whether to send a patch for each 'select' individually or to > wait until I complete my testing and submit a single patch with all of the > lxc selects. What do you prefer? Both solutions are fine with me. You can send patches as you progressively discover the issues, or send a single patch fixing all problems at once. I'm just wondering if we want to make all these dependencies actually mandatory or not. It seems some of these dependencies are only used for one specific tool in LXC. If the tool is not crucial in LXC usage, maybe we should make it optional via a sub-option? I'm not sure here, just thinking out loud. Thomas
Thomas, Jonathan, All, On 2015-09-20 23:01 +0200, Thomas Petazzoni spake thusly: > On Sun, 20 Sep 2015 20:15:02 +0300 (IDT), Jonathan Ben Avraham wrote: > > > I wondered whether to send a patch for each 'select' individually or to > > wait until I complete my testing and submit a single patch with all of the > > lxc selects. What do you prefer? > > Both solutions are fine with me. You can send patches as you > progressively discover the issues, or send a single patch fixing all > problems at once. > > I'm just wondering if we want to make all these dependencies actually > mandatory or not. It seems some of these dependencies are only used for > one specific tool in LXC. If the tool is not crucial in LXC usage, > maybe we should make it optional via a sub-option? I'm not sure here, > just thinking out loud. Well, lxc is already in the 'server-class' software, probably to run a bunch of containers, themselves in the 'bloatware-class'. So, the overhead of having gzip is probably insignifiant in the face of the size of the rest of the system. So, I'm OK with selecting gzip unconditionally. However, I would not want to force-select BB_SHOW_OTHERS, even though we already do it in three locations. Well, damn be it, just select both. Jonathan, care to fix and respin, please? Regards, Yann E. MORIN.
Hi Yann, My current use case for lxc in Buildroot is for mobile SoC's such as the Qualcomm Snapdragon 805 and 810 that have IP blocks such as DSP's, VPU's and GPU's for which Qualcomm only releases Android drivers and libraries. In order to use these IP blocks, I run Android in an lxc and pass CNN kernels from Linux to adsprpcd running in Android that passes the CNN kernels through the Linux kernel to the Hexagon DSP. Admittedly this adds new meaning to the term "Convoluted Neural Networks" but it provides an interim solution to the application developers until we can reverse engineer Qualcomm's FastRPC interface. I will re-spin the patch but before that I have yp-tools, ypbind-mt, sphinxbase and pocketsphinx to finish. Thanks, - yba On Sun, 10 Jan 2016, Yann E. MORIN wrote: > Date: Sun, 10 Jan 2016 18:09:23 +0100 > From: Yann E. MORIN <yann.morin.1998@free.fr> > To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > Cc: Jonathan Ben Avraham <yba@tkos.co.il>, buildroot@buildroot.org > Subject: Re: [Buildroot] [PATCH 1/1] lxc needs gzip scripts for > lxc-checkconfig runtime > > Thomas, Jonathan, All, > > On 2015-09-20 23:01 +0200, Thomas Petazzoni spake thusly: >> On Sun, 20 Sep 2015 20:15:02 +0300 (IDT), Jonathan Ben Avraham wrote: >> >>> I wondered whether to send a patch for each 'select' individually or to >>> wait until I complete my testing and submit a single patch with all of the >>> lxc selects. What do you prefer? >> >> Both solutions are fine with me. You can send patches as you >> progressively discover the issues, or send a single patch fixing all >> problems at once. >> >> I'm just wondering if we want to make all these dependencies actually >> mandatory or not. It seems some of these dependencies are only used for >> one specific tool in LXC. If the tool is not crucial in LXC usage, >> maybe we should make it optional via a sub-option? I'm not sure here, >> just thinking out loud. > > Well, lxc is already in the 'server-class' software, probably to run a > bunch of containers, themselves in the 'bloatware-class'. > > So, the overhead of having gzip is probably insignifiant in the face of > the size of the rest of the system. > > So, I'm OK with selecting gzip unconditionally. > > However, I would not want to force-select BB_SHOW_OTHERS, even though we > already do it in three locations. Well, damn be it, just select both. > > Jonathan, care to fix and respin, please? > > Regards, > Yann E. MORIN. > >
Jonathan, All, On 2016-01-11 08:32 +0200, Jonathan Ben Avraham spake thusly: > My current use case for lxc in Buildroot is for mobile SoC's such as the > Qualcomm Snapdragon 805 and 810 that have IP blocks such as DSP's, VPU's and > GPU's for which Qualcomm only releases Android drivers and libraries. In > order to use these IP blocks, I run Android in an lxc and pass CNN kernels > from Linux to adsprpcd running in Android that passes the CNN kernels > through the Linux kernel to the Hexagon DSP. Admittedly this adds new > meaning to the term "Convoluted Neural Networks" Aha! :-) > but it provides an interim > solution to the application developers until we can reverse engineer > Qualcomm's FastRPC interface. Yeah, I can see how containers can come handy in this situation (not unlike somethig I've had too, btw). > I will re-spin the patch but before that I have yp-tools, ypbind-mt, > sphinxbase and pocketsphinx to finish. Great, thanks! Regards, Yann E. MORIN.
diff --git a/package/lxc/Config.in b/package/lxc/Config.in index ffd9b4a..5377977 100644 --- a/package/lxc/Config.in +++ b/package/lxc/Config.in @@ -1,6 +1,7 @@ config BR2_PACKAGE_LXC bool "lxc" select BR2_PACKAGE_LIBCAP + select BR2_PACKAGE_GZIP # runtime, for lxc-checkconfig depends on BR2_TOOLCHAIN_HAS_THREADS depends on BR2_USE_MMU # fork() # build system forcefully builds a shared library