[OpenWrt-Devel] libnl: split into smaller libraries

From: Alexandru Ardelean <aa@ocedo.com>

The idea is that we may only need the libnl core, 
or libnl-route or libnl-nf libs, but maybe not all of them.

This way we can select which ones we need without bloating the
firmware image too much.

Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
---
 package/libs/libnl/Makefile | 62 ++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 56 insertions(+), 6 deletions(-)

On 2015-09-17 15:05, Alexandru Ardelean wrote:
> From: Alexandru Ardelean <aa@ocedo.com>
> 
> The idea is that we may only need the libnl core, 
> or libnl-route or libnl-nf libs, but maybe not all of them.
> 
> This way we can select which ones we need without bloating the
> firmware image too much.
> 
> Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Maybe it would be better to have libnl as a metapackage selecting
libnl-core + the other ones. The way you split the package, you might be
breaking some packages that depend on it.

Or did you review all of the packages to ensure that they only need the
core?

- Felix

On Thu, Sep 17, 2015 at 4:50 PM, Felix Fietkau <nbd@openwrt.org> wrote:

> On 2015-09-17 15:05, Alexandru Ardelean wrote:
> > From: Alexandru Ardelean <aa@ocedo.com>
> >
> > The idea is that we may only need the libnl core,
> > or libnl-route or libnl-nf libs, but maybe not all of them.
> >
> > This way we can select which ones we need without bloating the
> > firmware image too much.
> >
> > Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
> Maybe it would be better to have libnl as a metapackage selecting
> libnl-core + the other ones. The way you split the package, you might be
> breaking some packages that depend on it.
>
> Or did you review all of the packages to ensure that they only need the
> core?
>
> - Felix
>

Good point.
I only took a look at base packages.

Looking through the packages feed, there's keepalived , ibrcommon, kismet,
bmon and aircrack-ng that depend on libnl.
Other feeds don't have libnl deps.

I'll check if libnl is sufficient and if not, implement your suggestion.

Thanks

On Thu, Sep 17, 2015 at 5:13 PM, Alexandru Ardelean <ardeleanalex@gmail.com>
wrote:

>
>
> On Thu, Sep 17, 2015 at 4:50 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>
>> On 2015-09-17 15:05, Alexandru Ardelean wrote:
>> > From: Alexandru Ardelean <aa@ocedo.com>
>> >
>> > The idea is that we may only need the libnl core,
>> > or libnl-route or libnl-nf libs, but maybe not all of them.
>> >
>> > This way we can select which ones we need without bloating the
>> > firmware image too much.
>> >
>> > Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
>> Maybe it would be better to have libnl as a metapackage selecting
>> libnl-core + the other ones. The way you split the package, you might be
>> breaking some packages that depend on it.
>>
>> Or did you review all of the packages to ensure that they only need the
>> core?
>>
>> - Felix
>>
>
> Good point.
> I only took a look at base packages.
>
> Looking through the packages feed, there's keepalived , ibrcommon, kismet,
> bmon and aircrack-ng that depend on libnl.
> Other feeds don't have libnl deps.
>
> I'll check if libnl is sufficient and if not, implement your suggestion.
>
> Thanks
>
>
Seems I'll have to re-spin this patch.
There are a few things that need updating on it. They came up once I did a
full clean + rebuild.
I forgot about the staging dir stuff that piles up and causes
false-successes.

So,
- bmon requires libnl-route
- aircrack-ng requires libnl-genl
- kismet i am not sure 100% ; maybe libnl-genl ; I did not want to
investigate much deeper
- ibrcommon requires libnl-genl and libnl-route
- keepalived requires libnl-genl

Hopefully I got most of this right.

Now, here's the bloat for libnl:
- 86856 Sep 22 14:00 libnl-3.so.200.16.1
- 244304 Sep 22 14:00 libnl-route-3.so.200.16.1
- 16096 Sep 22 14:00 libnl-genl-3.so.200.16.1
- Seems libnl-nf is not needed. That's around 80k.
- libnl-tiny is 30k

Maybe aircrack-ng and keepalived could also work with [just] libnl-tiny,
but that's another discussion.

I need libnl-route for an upcoming new lldpd version, which will require
libnl-route.

The main reason I started this split, is because I need libnl-route, and I
am trying to minimise the bloat wherever I can.
I'll also see about pulling libnl-tiny out [in my case], since I'll be
stuck with needing libnl anyway.

Anyway, moving forward with the split:
1) Do I rename the libnl package to libnl-core and make libnl a metapackage
that pulls in everything ? or
2) Do I leave this structure as is (with the fixes/updates I'll add later)
and update those packages to pull only the libfiles that are needed ?
For 2), I'd of-course need the approval/blessing of the package maintainers
above.

From my point of view any of these 2 approaches is fine, because I can just
pull whichever libnl-xxx package I need.

Thanks
Alex

On 2015-09-22 14:42, Alexandru Ardelean wrote:
> Anyway, moving forward with the split:
> 1) Do I rename the libnl package to libnl-core and make libnl a
> metapackage that pulls in everything ? or
> 2) Do I leave this structure as is (with the fixes/updates I'll add
> later) and update those packages to pull only the libfiles that are
> needed ?
> For 2), I'd of-course need the approval/blessing of the package
> maintainers above.
> 
> From my point of view any of these 2 approaches is fine, because I can
> just pull whichever libnl-xxx package I need.
I prefer 1), and then start updating packages individually to only pull
in what they need.

- Felix

On Tue, Sep 22, 2015 at 03:42:26PM +0300, Alexandru Ardelean wrote:
> So,
> - bmon requires libnl-route
> - aircrack-ng requires libnl-genl
> - kismet i am not sure 100% ; maybe libnl-genl ; I did not want to
> investigate much deeper
> - ibrcommon requires libnl-genl and libnl-route
> - keepalived requires libnl-genl
> 
> Hopefully I got most of this right.
> 
> Now, here's the bloat for libnl:
> - 86856 Sep 22 14:00 libnl-3.so.200.16.1
> - 244304 Sep 22 14:00 libnl-route-3.so.200.16.1
> - 16096 Sep 22 14:00 libnl-genl-3.so.200.16.1
> - Seems libnl-nf is not needed. That's around 80k.
> - libnl-tiny is 30k

As far as I understood this, libnl-tiny is a drop-in replacement for
libnl-core.  Or is there a difference in functionality or API/ABI?

Is it possible for instance to depend on libnl-tiny and libnl-route?
(instead of libnl-core and libnl-route)

Thanks,
Baptiste (maintainer of bmon)

On 2015-10-03 10:52, Baptiste Jonglez wrote:
> On Tue, Sep 22, 2015 at 03:42:26PM +0300, Alexandru Ardelean wrote:
>> So,
>> - bmon requires libnl-route
>> - aircrack-ng requires libnl-genl
>> - kismet i am not sure 100% ; maybe libnl-genl ; I did not want to
>> investigate much deeper
>> - ibrcommon requires libnl-genl and libnl-route
>> - keepalived requires libnl-genl
>> 
>> Hopefully I got most of this right.
>> 
>> Now, here's the bloat for libnl:
>> - 86856 Sep 22 14:00 libnl-3.so.200.16.1
>> - 244304 Sep 22 14:00 libnl-route-3.so.200.16.1
>> - 16096 Sep 22 14:00 libnl-genl-3.so.200.16.1
>> - Seems libnl-nf is not needed. That's around 80k.
>> - libnl-tiny is 30k
> 
> As far as I understood this, libnl-tiny is a drop-in replacement for
> libnl-core.  Or is there a difference in functionality or API/ABI?
libnl-tiny replaces the most commonly used parts of libnl-core + -genl.
The API is a bit more limited, but compatible for most applications.
The ABI is different, but that doesn't matter much.

Any package that can easily work with libnl-tiny instead of libnl should
be changed to make use of it, since libnl-tiny is usually part of the
default package set.

> Is it possible for instance to depend on libnl-tiny and libnl-route?
> (instead of libnl-core and libnl-route)
Mixing libnl based libraries with libnl-tiny does not work.

- Felix

On Sat, Oct 03, 2015 at 01:10:18PM +0200, Felix Fietkau wrote:
> > As far as I understood this, libnl-tiny is a drop-in replacement for
> > libnl-core.  Or is there a difference in functionality or API/ABI?
> libnl-tiny replaces the most commonly used parts of libnl-core + -genl.
> The API is a bit more limited, but compatible for most applications.
> The ABI is different, but that doesn't matter much.
> 
> Any package that can easily work with libnl-tiny instead of libnl should
> be changed to make use of it, since libnl-tiny is usually part of the
> default package set.
> 
> > Is it possible for instance to depend on libnl-tiny and libnl-route?
> > (instead of libnl-core and libnl-route)
> Mixing libnl based libraries with libnl-tiny does not work.

Thanks for the information.

I've drafted some documentation based on this, feel free to improve:

  http://wiki.openwrt.org/doc/techref/libnl

Baptiste