[RFC] ubi-utils: improve compatibility with klibc

[RFC] ubi-utils: improve compatibility with klibc

[Andrea Adami]

Hi,

I have put together a patchset allowing to compile the ubi utils
statically against klibc.

The patches are based on today's mtd-utils master, please have a preview here:

https://github.com/andrea-adami/meta-openembedded/tree/master/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc

Please let me know if there is something to change before sending them
to the mailing list.

Thanks

Andrea

Re: [RFC] ubi-utils: improve compatibility with klibc

[Bill Pringlemeir]

On  3 Jul 2014, andrea.adami at gmail.com wrote:

> I have put together a patchset allowing to compile the ubi utils
> statically against klibc.

> The patches are based on today's mtd-utils master, please have a
> preview here:

> https://github.com/andrea-adami/meta-openembedded/tree/master/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc

> Please let me know if there is something to change before sending them
> to the mailing list.

I am no authority, but I appreciate your work.  I have tried to get the
ubi tools working with klibc and I think these patches have been around
for some time; I seem to remember seeing them.

I would suggest to modify '0001-Makefile-only-build-ubi-utils.patch' to
use the over-ride.  So we could have,

  UBI_ONLY ?= 0

And then modify the make rules on this conditional.  That way, people
using a default commandline/environment will get the full tools suite as
per normal.  It may even be best to split the functionality.  There is
'ftl', 'nand', 'jffs2' and 'ubi' and maybe the 'otp'.  So, someway to
pass a make variable through the environment or command line to change
what is built is probably better? (lacking 'configure' or 'menuconfig').

For '0003-libubi.c-add-klibc-specific-fixes.patch', why can't 'klibc'
fix the 'ioctl' definition?  I think that updating 'common.h' to handle
the peculiarities of 'klibc' and redefine the 'ioctl()' would be better,
if 'klibc' can't change.

I don't see issues with the other patches.

Fwiw,
Bill Pringlemeir.

Re: [RFC] ubi-utils: improve compatibility with klibc

[Andrea Adami]

On Fri, Jul 4, 2014 at 4:42 PM, Bill Pringlemeir <bpringlemeir@nbsps.com> wrote:
> On  3 Jul 2014, andrea.adami at gmail.com wrote:
>
>> I have put together a patchset allowing to compile the ubi utils
>> statically against klibc.
>
>> The patches are based on today's mtd-utils master, please have a
>> preview here:
>
>> https://github.com/andrea-adami/meta-openembedded/tree/master/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc
>
>> Please let me know if there is something to change before sending them
>> to the mailing list.
>
> I am no authority, but I appreciate your work.  I have tried to get the
> ubi tools working with klibc and I think these patches have been around
> for some time; I seem to remember seeing them.
>
Bill,
thanks for your review.
Yes, it's me again insisting to pack a small ubiattach in a little cpio...

> I would suggest to modify '0001-Makefile-only-build-ubi-utils.patch' to
> use the over-ride.  So we could have,
>
>   UBI_ONLY ?= 0
>
> And then modify the make rules on this conditional.  That way, people
> using a default commandline/environment will get the full tools suite as
> per normal.  It may even be best to split the functionality.  There is
> 'ftl', 'nand', 'jffs2' and 'ubi' and maybe the 'otp'.  So, someway to
> pass a make variable through the environment or command line to change
> what is built is probably better? (lacking 'configure' or 'menuconfig').
>
This is an interesting approach.
Anyhway, patch 0001 is not meant for upstream, I've marked its
Upstream-Status: Inappropriate

> For '0003-libubi.c-add-klibc-specific-fixes.patch', why can't 'klibc'
> fix the 'ioctl' definition?  I think that updating 'common.h' to handle
> the peculiarities of 'klibc' and redefine the 'ioctl()' would be better,
> if 'klibc' can't change.
>
Yes, definitely.
I'm in contact with couple of klibc developers (got patch 4 from one
of them) and will bother them...
So I'll add to patch 0003: Upstream-Status: Inappropriate

> I don't see issues with the other patches.
>
> Fwiw,
> Bill Pringlemeir.

Thanks.
I was thinking about maybe splitting patch 0005 in two parts, one for
getline() and another for rpmatch().
Or on the opposite squash 0004 and 0005 together. It's little stuff anyway.
Opinions?

Regards
Andrea