[Buildroot] crda and m2crypto

[Buildroot] crda and m2crypto

[Dimitrios Siganos]

Hi,

I am integrating crda with buildroot and I have run into a problem that
I'd like some feedback on.

The crda makefile depends on python-m2crypto to translate a key to a C
file representation. However, when I run the crda makefile using
TARGET_CONFIGURE_OPTS like this:

$(TARGET_CONFIGURE_OPTS) $(MAKE) all_noverify -C $(@D)

It fails.

It fails because TARGET_CONFIGURE_OPTS places the HOST_BIN directory in
the PATH and the python installed there doesn't have the m2crypto
library, which is needed during compilation.

I can workaround the problem by not using TARGET_CONFIGURE_OPTS and
hence not using the python interpreter in HOST_DIR. Instead the
workaround can use the python installed on the host computer where it is
easy to install the m2python library (apt-get install pyhton-m2crypto).
For example:

CC="$(TARGET_CC)" LD="$(TARGET_LD)" \
CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" \
LDFLAGS="$(TARGET_LDFLAGS)" $(MAKE) all_noverify -C $(@D)

Is such a solution acceptable?

In general what is the buildroot approach to such problems? Should all
the resources needed to build a package exist in the HOST_DIR?

Regards,
Dimitris

[Buildroot] crda and m2crypto

[Thomas Petazzoni]

Dear Dimitrios Siganos,

On Fri, 08 Feb 2013 09:03:07 +0000, Dimitrios Siganos wrote:

> I am integrating crda with buildroot and I have run into a problem that
> I'd like some feedback on.
> 
> The crda makefile depends on python-m2crypto to translate a key to a C
> file representation.

Argh.

> However, when I run the crda makefile using
> TARGET_CONFIGURE_OPTS like this:
> 
> $(TARGET_CONFIGURE_OPTS) $(MAKE) all_noverify -C $(@D)
> 
> It fails.
> 
> It fails because TARGET_CONFIGURE_OPTS places the HOST_BIN directory in
> the PATH and the python installed there doesn't have the m2crypto
> library, which is needed during compilation.
> 
> I can workaround the problem by not using TARGET_CONFIGURE_OPTS and
> hence not using the python interpreter in HOST_DIR. Instead the
> workaround can use the python installed on the host computer where it is
> easy to install the m2python library (apt-get install pyhton-m2crypto).
> For example:
> 
> CC="$(TARGET_CC)" LD="$(TARGET_LD)" \
> CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" \
> LDFLAGS="$(TARGET_LDFLAGS)" $(MAKE) all_noverify -C $(@D)
> 
> Is such a solution acceptable?
> 
> In general what is the buildroot approach to such problems? Should all
> the resources needed to build a package exist in the HOST_DIR?

Yes. Generally, we don't like to depend on specific things installed on
the build machine. The only thing that we expect to be installed are
checked by the support/dependencies/dependencies.sh script, and should
be only "global" stuff: wget, rsync, etc. We don't really like to add a
dependency on something like python-m2crypto that is used by only one
package.

Normally, we solve this problem by creating a Buildroot package for a
host variant of python-m2crypto, package that would depend on
host-python. This python-m2crypto package would install this Python
module in $(HOST_DIR), so that the host-python finds it. And finally
your crda package depends on it.

That's one approach.

The other approach that we sometimes look at is to see if the
dependency can be avoided in one way or another, or replaced by a
simpler dependency. Is this key -> C tool replaceable by something
else?

Best regards,

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

[Buildroot] crda and m2crypto

[Gustavo Zacarias]

On 02/08/2013 06:03 AM, Dimitrios Siganos wrote:

> Hi,
> 
> I am integrating crda with buildroot and I have run into a problem that
> I'd like some feedback on.

Any particular reason you don't want the static db integrated in the kernel?
Basically copy db.txt from wireless-regdb to linux-*/net/wireless/db.txt
and enable CONFIG_CFG80211_INTERNAL_REGDB=y.
Bam! No need for CRDA and all that.
Making a kernel extension for this should be relatively simple, or
alternatively just provide a patch for the kernel you're using.
Regards.

[Buildroot] crda and m2crypto

[Dimitrios Siganos]

On 08/02/13 10:17, Gustavo Zacarias wrote:
> On 02/08/2013 06:03 AM, Dimitrios Siganos wrote:
> 
>> Hi,
>>
>> I am integrating crda with buildroot and I have run into a problem that
>> I'd like some feedback on.
> 
> Any particular reason you don't want the static db integrated in the kernel?
> Basically copy db.txt from wireless-regdb to linux-*/net/wireless/db.txt
> and enable CONFIG_CFG80211_INTERNAL_REGDB=y.
> Bam! No need for CRDA and all that.
> Making a kernel extension for this should be relatively simple, or
> alternatively just provide a patch for the kernel you're using.
> Regards.
> 

Hi Gustavo,

There is no particular reason for going with crda other than it is the
recommended way. I am a consultant working a with a module provider who
provides modules to third parties. The third parties make the final call
on everything but we want to deliver the recommended setup by default.

For us, as a business, bypassing the HOST_DIR and forcing the user to
install python-m2crypto is an acceptable solution. This is a nice
example that shows why upstreaming is sometimes not a simple matter
because of differing priorities between upstream/downstream.

We would like to work closer with buildroot so I'll make an effort to
upstream these changes. I have had a look at m2crypto and it seems
simple enough to integrate with buildroot. However, m2crypto now needs
'swig'.

If I fail to integrate m2crypto and dependencies within a reasonable
amount of time, I will go to plan to B. There seems to exist an easy
alternative. The key files produced are not likely to change because
they are the C representation of the public key that guarantees the
authenticity of the data. So I could just add to them to the buildroot
package to remove the need to build them and hence not need m2crypto.
From Thomas' reply, it sounds like that would be an acceptable workaround.

But for now, I will attempt to bring in m2crypto and dependencies as a
learning exercise.

Regards,
Dimitris