[Buildroot] busybox, hardcoded config

[Buildroot] busybox, hardcoded config

[Heiko Zuerker]

Hey,

there was recently a discussion on the topic of automatically turning  
on specific kernel features, which can cause some problems.

This is very heavily done in busybox, i.e. nfs support for mount keeps  
being turned on by the makefile. At least in my case this is causing  
me some grief.

I think we really should keep this automatically setting of  
configurations to an absolute minimum. Can't we rely on the person  
configuring buildroot, to set the correct options he or she needs for  
example in busybox or the kernel?

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Buildroot] busybox, hardcoded config

[Thomas Petazzoni]

On Thu, 23 Dec 2010 07:33:18 -0600
Heiko Zuerker <heiko@zuerker.org> wrote:

> there was recently a discussion on the topic of automatically turning  
> on specific kernel features, which can cause some problems.
> 
> This is very heavily done in busybox, i.e. nfs support for mount keeps  
> being turned on by the makefile. At least in my case this is causing  
> me some grief.

Could you detail why that specific behaviour on NFS is causing
problems ?

> I think we really should keep this automatically setting of  
> configurations to an absolute minimum. Can't we rely on the person  
> configuring buildroot, to set the correct options he or she needs for  
> example in busybox or the kernel?

There's no one-size-fits-all answer to this question. On the one hand,
we can't make everything automatic and we have to rely on the user to
make sane choices. On the other hand, we also want configurations built
by default to make sense as much as possible.

I'm not terribly happy about the BR2_PACKAGE_BUSYBOX_DONT_CHANGE_CONFIG
you proposed, but it's true I don't really have a better proposal.
Maybe we should automatically disable the automatic tuning if the
Busybox configuration file is not in package/busybox/ (i.e when it's a
non-Buildroot provided configuration file) ? But maybe this behaviour
is a bit tricky.

Regards,

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

[Buildroot] busybox, hardcoded config

[Heiko Zuerker]

Hey,

Quoting Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> On Thu, 23 Dec 2010 07:33:18 -0600
> Heiko Zuerker <heiko@zuerker.org> wrote:
>
>> there was recently a discussion on the topic of automatically turning
>> on specific kernel features, which can cause some problems.
>>
>> This is very heavily done in busybox, i.e. nfs support for mount keeps
>> being turned on by the makefile. At least in my case this is causing
>> me some grief.
>
> Could you detail why that specific behaviour on NFS is causing
> problems ?

(A rather lengthy explanation)

My situation is a bit different than most people using buildroot.
I'm trying to use buildroot for a full blown, security focused distribution.
Since Devil-Linux is already well established, I have to reproduce the  
current features.

Busybox is only used as a static binary in the initramfs to initialize  
the system, find the configuration and the distribution media.

We're using the full blown glibc and busybox can't be statically  
compiled if nfs support is on, since it needs it for dns resolution.

>> I think we really should keep this automatically setting of
>> configurations to an absolute minimum. Can't we rely on the person
>> configuring buildroot, to set the correct options he or she needs for
>> example in busybox or the kernel?
>
> There's no one-size-fits-all answer to this question. On the one hand,
> we can't make everything automatic and we have to rely on the user to
> make sane choices. On the other hand, we also want configurations built
> by default to make sense as much as possible.
>
> I'm not terribly happy about the BR2_PACKAGE_BUSYBOX_DONT_CHANGE_CONFIG
> you proposed, but it's true I don't really have a better proposal.
> Maybe we should automatically disable the automatic tuning if the
> Busybox configuration file is not in package/busybox/ (i.e when it's a
> non-Buildroot provided configuration file) ? But maybe this behaviour
> is a bit tricky.

This may cause other people more issues. I'm sure not everybody can  
used the provided config files and has to do some minor adjustments,  
but still relies on some of the auto-config features.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Buildroot] busybox, hardcoded config

[Peter Korsgaard]

>>>>> "Heiko" == Heiko Zuerker <heiko@zuerker.org> writes:

Hi,

 >> Could you detail why that specific behaviour on NFS is causing
 >> problems ?

 Heiko> (A rather lengthy explanation)

 Heiko> My situation is a bit different than most people using buildroot.
 Heiko> I'm trying to use buildroot for a full blown, security focused distribution.
 Heiko> Since Devil-Linux is already well established, I have to reproduce the
 Heiko> current features.

 Heiko> Busybox is only used as a static binary in the initramfs to initialize
 Heiko> the system, find the configuration and the distribution media.

 Heiko> We're using the full blown glibc and busybox can't be statically
 Heiko> compiled if nfs support is on, since it needs it for dns resolution.

So your problem is basically that you're trying to do static linking
with glibc, which is known to not work very well, and is considered
deprecated by the glibc developers
(http://www.akkadia.org/drepper/no_static_linking.html). Wouldn't it
make more sense to use uclibc for the initramfs, or alternatively use
dynamic linking?

 Heiko> This may cause other people more issues. I'm sure not everybody can
 Heiko> used the provided config files and has to do some minor adjustments,
 Heiko> but still relies on some of the auto-config features.

Yes, I don't like extra (inconsistent) magic.

-- 
Bye, Peter Korsgaard

[Buildroot] busybox, hardcoded config

[Heiko Zuerker]

Hey,

Quoting Peter Korsgaard <jacmet@uclibc.org>:
>>>>>> "Heiko" == Heiko Zuerker <heiko@zuerker.org> writes:
>  >> Could you detail why that specific behaviour on NFS is causing
>  >> problems ?
>
>  Heiko> (A rather lengthy explanation)
>
>  Heiko> My situation is a bit different than most people using buildroot.
>  Heiko> I'm trying to use buildroot for a full blown, security  
> focused distribution.
>  Heiko> Since Devil-Linux is already well established, I have to  
> reproduce the
>  Heiko> current features.
>
>  Heiko> Busybox is only used as a static binary in the initramfs to  
> initialize
>  Heiko> the system, find the configuration and the distribution media.
>
>  Heiko> We're using the full blown glibc and busybox can't be statically
>  Heiko> compiled if nfs support is on, since it needs it for dns resolution.
>
> So your problem is basically that you're trying to do static linking
> with glibc, which is known to not work very well, and is considered
> deprecated by the glibc developers
> (http://www.akkadia.org/drepper/no_static_linking.html). Wouldn't it
> make more sense to use uclibc for the initramfs, or alternatively use
> dynamic linking?

It wouldn't be possible too just compile busybox with uclibc and the  
rest of the apps with glibc, correct?
I could rewrite the initramfs support to work with shared libs. All it  
takes is a little routine to find all the required libraries and copy  
them over. I'll take a look at this later today.

>  Heiko> This may cause other people more issues. I'm sure not everybody can
>  Heiko> used the provided config files and has to do some minor adjustments,
>  Heiko> but still relies on some of the auto-config features.
>
> Yes, I don't like extra (inconsistent) magic.

:-)

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Buildroot] busybox, hardcoded config

[Peter Korsgaard]

>>>>> "Heiko" == Heiko Zuerker <heiko@zuerker.org> writes:

Hi,

 Heiko> It wouldn't be possible too just compile busybox with uclibc and the
 Heiko> rest of the apps with glibc, correct?

Why not? As long as you are linking statically it doesn't matter what C
library the rest of the system is using.

 Heiko> I could rewrite the initramfs support to work with shared libs. All it
 Heiko> takes is a little routine to find all the required libraries and copy
 Heiko> them over. I'll take a look at this later today.

Ok, great.

-- 
Bye, Peter Korsgaard

[Buildroot] busybox, hardcoded config

[Heiko Zuerker]

Quoting Peter Korsgaard <jacmet@uclibc.org>:
>>>>>> "Heiko" == Heiko Zuerker <heiko@zuerker.org> writes:
>
> Hi,
>
>  Heiko> It wouldn't be possible too just compile busybox with uclibc and the
>  Heiko> rest of the apps with glibc, correct?
>
> Why not? As long as you are linking statically it doesn't matter what C
> library the rest of the system is using.

I didn't phrase my question right: does buildroot support it?
End-state I need to be able to just run "make" and everything is being  
build without any interaction.
I assume it's probably a lot easier to just use shared libs.

>  Heiko> I could rewrite the initramfs support to work with shared  
> libs. All it
>  Heiko> takes is a little routine to find all the required libraries and copy
>  Heiko> them over. I'll take a look at this later today.
>
> Ok, great.

Obviously I didn't get a chance to look into it. My house decided it  
wanted me to fix leaking water valves...

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Buildroot] busybox, hardcoded config

[Peter Korsgaard]

>>>>> "Heiko" == Heiko Zuerker <heiko@zuerker.org> writes:

Hi,

 >> Why not? As long as you are linking statically it doesn't matter
 >> what C library the rest of the system is using.

 Heiko> I didn't phrase my question right: does buildroot support it?
 Heiko> End-state I need to be able to just run "make" and everything is being
 Heiko> build without any interaction.

You are only using buildroot for the initramfs, right? If so, yes that
works.

 Heiko> Obviously I didn't get a chance to look into it. My house decided it
 Heiko> wanted me to fix leaking water valves...

Priorities, priorities ;)

-- 
Bye, Peter Korsgaard

[Buildroot] busybox, hardcoded config

[Peter Korsgaard]

>>>>> "Heiko" == Heiko Zuerker <heiko@zuerker.org> writes:

 Heiko> Hey,
 Heiko> there was recently a discussion on the topic of automatically turning
 Heiko> on specific kernel features, which can cause some problems.

 Heiko> This is very heavily done in busybox, i.e. nfs support for mount keeps
 Heiko> being turned on by the makefile. At least in my case this is causing
 Heiko> me some grief.

Hmm, why is that? Presumably you want to be able to mount NFS shares if
you enable RPC support in the toolchain?

We could remove the enable part of the NFS setting though (so only
disable if no RPC support to not get a build error), and just enable it
in the default config.

 Heiko> I think we really should keep this automatically setting of
 Heiko> configurations to an absolute minimum. Can't we rely on the person
 Heiko> configuring buildroot, to set the correct options he or she needs for
 Heiko> example in busybox or the kernel?

Agreed. We shouldn't tweak configs behind the users back more than
absolutely necessary. Busybox is a bit special in the sense that we want
to use a single default config, but some options depends on how the
toolchain is configured.

-- 
Bye, Peter Korsgaard