[Buildroot] [uclinux-dist-devel] [Announcement] The 2012R2 buildroot Linux release for Blackfin

[Buildroot] [uclinux-dist-devel] [Announcement] The 2012R2 buildroot Linux release for Blackfin

[Thomas Petazzoni]

Dear Sonic Zhang,

On Mon, 4 Feb 2013 05:03:22 -0500, Zhang, Sonic wrote:
> The 2012R2 buildroot Linux release for Blackfin
> 
> The new buildroot distribution was introduced in the 2012R1 Linux
> release for BF60x in Aug. 2012. To help BF5xx customers to leverage
> new features in the buildroot distribution, we are pleased to
> announce the 2012R2 buildroot Linux release for both BF5xx and BF60x
> families. Although the uClinux related issues in 2011R1 and former
> releases are still supported via the Linux community on the ADI
> Engineering Zone, the uClinux distribution for BF5xx is discontinued
> since the 2012R2 release. Please upgrade to the buildroot
> distribution in the 2012R2 release for latest features in Linux
> kernel and middle wares. An overview and basic development guide for
> the buildroot can be found at
> http://docs.blackfin.uclinux.org/doku.php?id=buildroot_on_blackfin .

As a Buildroot developer, I'm glad to hear that Analog Devices is now
using it as its official build system.

However, I can only find regrettable that none of the Blackfin changes
that you and your team has made have gotten upstream. This means that
you're now working on a fork of Buildroot that has significantly
derived from the original project. It means that it will be a pain for
you and your team to upgrade to new Buildroot versions, and it removes
the possibility for your users to easily benefit from all the package
updates and new packages that are introduced regularly in the upstream
Buildroot project (where the level of activity is very good).

Could we find a way of getting your changes upstream, so that your
Buildroot is closer to the upstream version?

Also, your page
http://docs.blackfin.uclinux.org/doku.php?id=buildroot:build-system is
incorrect. It says "The buildroot build system is based on GNU
configure and build system". This is completely false: it is based on
the kernel kconfig configuration system, and GNU make.

Then your Wiki page goes on with " The top level Makefile builds the
GNU configuration utility under package/config at first". This is not
true, it is *not* the GNU configuration utility, but the Linux kernel
kconfig system.

The Wiki page then describes a number of Config.in files, as if
modifying them was necessary to change the configuration. This is
obviously completely wrong: users should change the configuration using
'make menuconfig', 'make xconfig, 'make gconfig', and certainly not by
editing Config.in files, whose purpose is to *describe* configuration
options, not to *define* the value of configuration options.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [uclinux-dist-devel] [Announcement] The 2012R2 buildroot Linux release for Blackfin

[Thomas Petazzoni]

Dear Zhang, Sonic,

On Thu, 7 Mar 2013 05:40:26 -0500, Zhang, Sonic wrote:

> >Could we find a way of getting your changes upstream, so that your
> >Buildroot is closer to the upstream version?
> 
> I sent some initial Blackfin supporting patches against 2012.08
> upstream release to the buildroot mailing list last Aug. But, I got
> no response.

This is not true. You got some response precisely from me:

 http://lists.busybox.net/pipermail/buildroot/2012-August/057117.html
 http://lists.busybox.net/pipermail/buildroot/2012-August/057116.html
 http://lists.busybox.net/pipermail/buildroot/2012-August/057118.html
 http://lists.busybox.net/pipermail/buildroot/2012-August/057157.html
 http://lists.busybox.net/pipermail/buildroot/2012-August/057471.html
 http://lists.busybox.net/pipermail/buildroot/2012-August/057253.html
 http://lists.busybox.net/pipermail/buildroot/2012-August/057448.html
 http://lists.busybox.net/pipermail/buildroot/2012-August/057254.html
 http://lists.busybox.net/pipermail/buildroot/2012-August/057255.html
 http://lists.busybox.net/pipermail/buildroot/2012-August/057256.html
 http://lists.busybox.net/pipermail/buildroot/2012-August/057252.html
 http://lists.busybox.net/pipermail/buildroot/2012-August/057172.html

For sure, some of your patches regarding override source directory
didn't get any response. I'm currently working on the out-of-tree
support to build packages, which should solve the original problem you
reported.

> So, we can't sent more patches on top. I may sent out
> these patches against for comments after we update to your 2013.02
> release.

Great.

The thing is that your patches didn't take into account that there is a
life beyond Blackfin in Buildroot. While in your own fork you can do a
Blackfin-specific hack, we have to make it generic and maintainable in
Buildroot upstream.

Also, you started with the most complicated patches (such as patches
making modifications to the core infrastructure). I would suggest to
first start to upstream all the fixes you did to get the different
packages build on non-MMU platforms. However, even here, we might ask
you to make some changes compared to your patches. For example,
http://blackfin.uclinux.org/git/?p=buildroot;a=blob;f=package/libglib2/libglib2-nommu.patch;h=3979aa79195cf28876a45e7ed7c884bfaeadb5ad;hb=HEAD
isn't acceptable, because the __NOMMU__ is something that has been
invented specifically in your Buildroot fork.

The right way of handling this specific patch is to add a configure.ac
check for the fork() function, which will define HAVE_FORK if fork() is
available, and then we can use HAVE_FORK in the glib code. This way,
the patch has a chance of getting merged upstream.

> >The Wiki page then describes a number of Config.in files, as if
> >modifying them was necessary to change the configuration. This is
> >obviously completely wrong: users should change the configuration
> >using 'make menuconfig', 'make xconfig, 'make gconfig', and
> >certainly not by editing Config.in files, whose purpose is to
> >*describe* configuration options, not to *define* the value of
> >configuration options.
> 
> The explanation to these Config.in files are aimed to give developers
> a basic concept on how the configure options are generated. Yes,
> developers should only use the make xxxconfig command to change any
> option.

I still find the entire wording still very confusing. "When done, the
saved selections will be written to .config and autoconf.h." This is
not true: only .config is important here, autoconf.h is just generated
from it.

Also, "Default buildroot settings are passed to make as a text file
configs/xxxxx_defconfig." This doesn't mean anything. The
configs/xxxx_defconfig files are minimal defconfig describing a
particular configuration, that one can use as a sample to start a new
configuration:

	make <foobar>_defconfig
	make menuconfig
	make

BTW, the title of the section is still "GNU configure Overview",
which is wrong.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [uclinux-dist-devel] [Announcement] The 2012R2 buildroot Linux release for Blackfin

[Thomas Petazzoni]

Dear Zhang, Sonic,

On Fri, 8 Mar 2013 02:19:01 -0500, Zhang, Sonic wrote:

> I mean my new patches to address some of your feedbacks in former patches got no response.
> http://lists.busybox.net/pipermail/buildroot/2012-August/057505.html
> http://lists.busybox.net/pipermail/buildroot/2012-August/057506.html
> http://lists.busybox.net/pipermail/buildroot/2012-August/057668.html
> http://lists.busybox.net/pipermail/buildroot/2012-August/057669.html

Yes, just like with any project, it is not easy to get core changes
merged, especially when those are the first contributions from a
developer. It requires time, patience and perseverance.

That's also why I was proposing you to get started with all the package
changes first. They are a lot easier to handle, less intrusive, and
therefore easier to get merged.

> >The thing is that your patches didn't take into account that there is a life beyond
> >Blackfin in Buildroot. While in your own fork you can do a Blackfin-specific hack,
> >we have to make it generic and maintainable in Buildroot upstream.
> 
> Which part of the source override patches are not generic enough? I didn't get any feedback.

Honestly, I don't remember off-hand, I'd have to go through the patches
again.

> >The right way of handling this specific patch is to add a configure.ac check for the
> >fork() function, which will define HAVE_FORK if fork() is available, and then we
> >can use HAVE_FORK in the glib code. This way, the patch has a chance of
> >getting merged upstream.
> 
> How to do deal with packages which are not generated by GNU autotools?

For these, using the -D__NO_MMU__ solution is probably acceptable.
Generally speaking, we try to carry package patches that could
potentially have a chance to go upstream. It's not always possible for
all changes, but we try to do it.

> >I still find the entire wording still very confusing. "When done, the saved selections
> >will be written to .config and autoconf.h." This is not true: only .config is important
> >here, autoconf.h is just generated from it.
> 
> 
> Thanks. Fixed.

> >Also, "Default buildroot settings are passed to make as a text file
> >configs/xxxxx_defconfig." This doesn't mean anything. The
> >configs/xxxx_defconfig files are minimal defconfig describing a particular
> >configuration, that one can use as a sample to start a new
> >configuration:
> >
> >       make <foobar>_defconfig
> >       make menuconfig
> >       make
> >
> 
> Ditto
> 
> >BTW, the title of the section is still "GNU configure Overview", which is wrong.
> 
> Ditto

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [uclinux-dist-devel] [Announcement] The 2012R2 buildroot Linux release for Blackfin

[Thomas De Schampheleire]

Hi,

On Fri, Mar 8, 2013 at 9:33 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Zhang, Sonic,
>
> On Fri, 8 Mar 2013 02:19:01 -0500, Zhang, Sonic wrote:
>
>> I mean my new patches to address some of your feedbacks in former patches got no response.
>> http://lists.busybox.net/pipermail/buildroot/2012-August/057505.html
>> http://lists.busybox.net/pipermail/buildroot/2012-August/057506.html
>> http://lists.busybox.net/pipermail/buildroot/2012-August/057668.html
>> http://lists.busybox.net/pipermail/buildroot/2012-August/057669.html
>
> Yes, just like with any project, it is not easy to get core changes
> merged, especially when those are the first contributions from a
> developer. It requires time, patience and perseverance.
>
> That's also why I was proposing you to get started with all the package
> changes first. They are a lot easier to handle, less intrusive, and
> therefore easier to get merged.

I fully agree with Thomas P. that integrating the Blackfin changes
into mainline buildroot would be beneficial for both the buildroot as
the Blackfin community. As Thomas indicated, the buildroot community
is now more alive than ever, and I'm sure that a new series of
buildroot patches from the Blackfin community will not go unnoticed,
especially now that you're in the middle of our radar ;-)

I also agree with the approach Thomas suggests: let's start with the
simple patches like package changes. This will reduce the divergence
between both trees without too much effort, after which we can tackle
the bigger stuff.

What do you think?

By the way: I don't see Sonic's replies appearing on the buildroot
mailing list. Is it possible to keep that list in copy?

Best regards,
Thomas

[Buildroot] [uclinux-dist-devel] [Announcement] The 2012R2 buildroot Linux release for Blackfin

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Fri, 8 Mar 2013 15:52:12 +0100, Thomas De Schampheleire wrote:

> > That's also why I was proposing you to get started with all the package
> > changes first. They are a lot easier to handle, less intrusive, and
> > therefore easier to get merged.
> 
> I fully agree with Thomas P. that integrating the Blackfin changes
> into mainline buildroot would be beneficial for both the buildroot as
> the Blackfin community. As Thomas indicated, the buildroot community
> is now more alive than ever, and I'm sure that a new series of
> buildroot patches from the Blackfin community will not go unnoticed,
> especially now that you're in the middle of our radar ;-)

I agree. One example of a good thing you will benefit from being part
of the wider Buildroot community is for example our autobuilder
infrastructure. It tests which packages are building properly or not
building properly, and ultimately helps in improving Buildroot's
quality and therefore the user experience. Our autobuilders are already
regularly building Blackfin configurations.

> By the way: I don't see Sonic's replies appearing on the buildroot
> mailing list. Is it possible to keep that list in copy?

Sonic e-mails have the Buildroot list in Cc. I'm not sure why they
don't make it to the list. Probably because he is posting with his
@analog.com address, while he is subscribed with an @gmail.com address
on the Buildroot list.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com