On Fri, May 8, 2009 at 10:49 AM, Artem Bityutskiy
<dedekind@infradead.org> wrote:
> Hi,>> thanks for patches. Could you please avoid synchronizing> include/mtd/ubi-user.h for now? There is nothing new there> except of this insane s/int32_t/__s32/ type change, right?
Ho, I believed that new ioctl weren't in ubi-user.h .. So it's ok to
keep the old one.
> On Thu, 2009-05-07 at 12:21 +0200, Corentin Chary wrote:>> include/mtd/ubi-user.h | 72 ++-->> include/ubi.h | 192 +++++++++>> mkfs.ubifs/libubiio.c | 936 +++++++++++++++++++++++++++++++++++++++++++++>> mkfs.ubifs/libubiio.h | 47 +++>> mkfs.ubifs/libubiio_int.h | 187 +++++++++>> 5 files changed, 1399 insertions(+), 35 deletions(-)>> create mode 100644 include/ubi.h>> create mode 100644 mkfs.ubifs/libubiio.c>> create mode 100644 mkfs.ubifs/libubiio.h>> create mode 100644 mkfs.ubifs/libubiio_int.h>> What is the point of making a second copy of libubi?> AFAICS, libubio is libubi + other stuff, right?> Why not to just improve libubi instead of having yet> another copy? How much sense does it make?
No, not really, libubiio provide what you can find in ubi.h, nothing
more (open/close/read/write/change/erase/map/unmap).
There some code in common to read sysfs properties, it's all.
There is libubiio_int.h with some duplicate code from
ubi-utils/src/common.h which could be removed.
libubi on the other hand provide functions to manipulate volume and
devices (rename, create, etc..).
Another way to teach ubifs to write on UBI volume could be libubi +
direct pread/pwrite/ioctl but it seems a lot less clean
to me. libubiio could be used later for fsck.ubifs or tuneubifs programs =).
But the current tree/build system make it hard to share code between
ubi-utils/mtd-utils/mkfs. It what
If you check, there is also three crc32.c/h in mtd-utils ...
(See http://git.iksaif.net/?p=users/iksaif/mtd-utils.git;a=tree;hb=HEAD
to check what a clean tree could be)

On Fri, 2009-05-08 at 14:07 +0200, Corentin Chary wrote:
> No, not really, libubiio provide what you can find in ubi.h, nothing> more (open/close/read/write/change/erase/map/unmap).> There some code in common to read sysfs properties, it's all.> There is libubiio_int.h with some duplicate code from> ubi-utils/src/common.h which could be removed.> libubi on the other hand provide functions to manipulate volume and> devices (rename, create, etc..).
Still, what's the reason to have a separate library?
Why not to add your stuff to existing one? If there
are some issues in libubi, they could be fixed. I just
see a lot of common code.
> But the current tree/build system make it hard to share code between> ubi-utils/mtd-utils/mkfs. It what> If you check, there is also three crc32.c/h in mtd-utils ...> (See http://git.iksaif.net/?p=users/iksaif/mtd-utils.git;a=tree;hb=HEAD> to check what a clean tree could be)
But surely you may try to re-arrange the tree, make it saner?

On Fri, May 8, 2009 at 2:20 PM, Artem Bityutskiy <dedekind@infradead.org> wrote:
> On Fri, 2009-05-08 at 14:07 +0200, Corentin Chary wrote:>> No, not really, libubiio provide what you can find in ubi.h, nothing>> more (open/close/read/write/change/erase/map/unmap).>> There some code in common to read sysfs properties, it's all.>> There is libubiio_int.h with some duplicate code from>> ubi-utils/src/common.h which could be removed.>> libubi on the other hand provide functions to manipulate volume and>> devices (rename, create, etc..).>> Still, what's the reason to have a separate library?> Why not to add your stuff to existing one? If there> are some issues in libubi, they could be fixed. I just> see a lot of common code.
When we made libubiio we wanted something close to the kernel API,
libubi is not.
To make mkfs.ubifs works with smaller changes, I can add the
"is_mapped" and "erase" functions to libubi, forgetting the original
UBI API.
Does that seems better to you ? If it's ok then I'll do that.
>> But the current tree/build system make it hard to share code between>> ubi-utils/mtd-utils/mkfs. It what>> If you check, there is also three crc32.c/h in mtd-utils ...>> (See http://git.iksaif.net/?p=users/iksaif/mtd-utils.git;a=tree;hb=HEAD>> to check what a clean tree could be)>> But surely you may try to re-arrange the tree, make it saner?
It's what I did on my git tree.. but it only works with CMake.
I don't know how to fix the current mess with simples Makefiles.
Maybe someone with better Make skills could help us here ?
Thanks

On Fri, 2009-05-08 at 15:58 +0200, Corentin Chary wrote:
> On Fri, May 8, 2009 at 2:20 PM, Artem Bityutskiy <dedekind@infradead.org> wrote:> > On Fri, 2009-05-08 at 14:07 +0200, Corentin Chary wrote:> >> No, not really, libubiio provide what you can find in ubi.h, nothing> >> more (open/close/read/write/change/erase/map/unmap).> >> There some code in common to read sysfs properties, it's all.> >> There is libubiio_int.h with some duplicate code from> >> ubi-utils/src/common.h which could be removed.> >> libubi on the other hand provide functions to manipulate volume and> >> devices (rename, create, etc..).> >> > Still, what's the reason to have a separate library?> > Why not to add your stuff to existing one? If there> > are some issues in libubi, they could be fixed. I just> > see a lot of common code.> > When we made libubiio we wanted something close to the kernel API,> libubi is not.
But it should not be difficult to change this. You may amend
the API to serve better your purposes.
> To make mkfs.ubifs works with smaller changes, I can add the> "is_mapped" and "erase" functions to libubi, forgetting the original> UBI API.> Does that seems better to you ? If it's ok then I'll do that.
As you wish. I just think we should try not to copy code, but
integrate to the existing code base. If the existing one is
not suitable - fix it.
> >> But the current tree/build system make it hard to share code between> >> ubi-utils/mtd-utils/mkfs. It what> >> If you check, there is also three crc32.c/h in mtd-utils ...> >> (See http://git.iksaif.net/?p=users/iksaif/mtd-utils.git;a=tree;hb=HEAD> >> to check what a clean tree could be)> >> > But surely you may try to re-arrange the tree, make it saner?> It's what I did on my git tree.. but it only works with CMake.> I don't know how to fix the current mess with simples Makefiles.> Maybe someone with better Make skills could help us here ?
You want to move headers from ubi-utils/include to include ?

On Fri, 2009-05-08 at 15:20 +0300, Artem Bityutskiy wrote:
> On Fri, 2009-05-08 at 14:07 +0200, Corentin Chary wrote:> > No, not really, libubiio provide what you can find in ubi.h, nothing> > more (open/close/read/write/change/erase/map/unmap).> > There some code in common to read sysfs properties, it's all.> > There is libubiio_int.h with some duplicate code from> > ubi-utils/src/common.h which could be removed.> > libubi on the other hand provide functions to manipulate volume and> > devices (rename, create, etc..).> > Still, what's the reason to have a separate library?> Why not to add your stuff to existing one? If there> are some issues in libubi, they could be fixed. I just> see a lot of common code.> > > But the current tree/build system make it hard to share code between> > ubi-utils/mtd-utils/mkfs. It what> > If you check, there is also three crc32.c/h in mtd-utils ...> > (See http://git.iksaif.net/?p=users/iksaif/mtd-utils.git;a=tree;hb=HEAD> > to check what a clean tree could be)> > But surely you may try to re-arrange the tree, make it saner?
In fact, I already have simple implementation of setprop/unmap
functions which I use in the ubi tests.
I've just pushed them. There are some other patches as well.
But the main change - mtd sysfs support is not pushed - but
I'll do it very soon. After this the change rate will become
low again.
Some of my changes are not very good, in a sense that they do
not fix one small thing, but contain several things. But this
is mostly because I was accustomed to be the only ubi-utils
developer. If you are going to work with the code base, I
will be more careful.

On Fri, May 8, 2009 at 4:14 PM, Artem Bityutskiy <dedekind@infradead.org> wrote:
> In fact, I already have simple implementation of setprop/unmap> functions which I use in the ubi tests.>> I've just pushed them. There are some other patches as well.> But the main change - mtd sysfs support is not pushed - but> I'll do it very soon. After this the change rate will become> low again.>> Some of my changes are not very good, in a sense that they do> not fix one small thing, but contain several things. But this> is mostly because I was accustomed to be the only ubi-utils> developer. If you are going to work with the code base, I> will be more careful.
I'll see what I can do to use libubi the way I want.
The problem of using libubi in mkfs is not the includes (we can copy
the headers in /include or add -I../ubi-utils/include).
The main problem is that ubi-utils/Makefile make a libubi.a but
mkfs.ubifs/Makefile have no way to use it (we could add
../ubi-utils/src/libubi.c to the sources, but it's ugly).
I think it's why there is 3 crc32.c in mtd-utils ...
As I'm working on my free time I don't have the time to try to make it
works with the current buildsystem.
Mike, have you got any suggestion ?
Maybe moving to autotools instead of CMake could help us ?
Thanks

On Fri, May 8, 2009 at 10:59, Corentin Chary wrote:
> I'll see what I can do to use libubi the way I want.> The problem of using libubi in mkfs is not the includes (we can copy> the headers in /include or add -I../ubi-utils/include).
why do you need to copy any files ?
> The main problem is that ubi-utils/Makefile make a libubi.a but> mkfs.ubifs/Makefile have no way to use it
what's wrong with adding -lubi and a -L path ?
> As I'm working on my free time I don't have the time to try to make it> works with the current buildsystem.> Mike, have you got any suggestion ?
i dont see the problem
> Maybe moving to autotools instead of CMake could help us ?
we arent using autotools
-mike

On Fri, May 8, 2009 at 8:58 PM, Mike Frysinger <vapier.adi@gmail.com> wrote:
> On Fri, May 8, 2009 at 10:59, Corentin Chary wrote:>> I'll see what I can do to use libubi the way I want.>> The problem of using libubi in mkfs is not the includes (we can copy>> the headers in /include or add -I../ubi-utils/include).>> why do you need to copy any files ?>>> The main problem is that ubi-utils/Makefile make a libubi.a but>> mkfs.ubifs/Makefile have no way to use it>> what's wrong with adding -lubi and a -L path ?
It'll work only if libubi is already built. You can fix that in the
root Makefile, but
- parallel builds may not work (make -j)
- "cd mkfs.ubifs && make" won't work (using only the mkfs.ubifs Makefile)
But if it's ok for you, I'll just use -L and -lubi.

On Fri, May 8, 2009 at 15:41, Corentin Chary wrote:
> On Fri, May 8, 2009 at 8:58 PM, Mike Frysinger wrote:>> On Fri, May 8, 2009 at 10:59, Corentin Chary wrote:>>> I'll see what I can do to use libubi the way I want.>>> The problem of using libubi in mkfs is not the includes (we can copy>>> the headers in /include or add -I../ubi-utils/include).>>>> why do you need to copy any files ?>>>>> The main problem is that ubi-utils/Makefile make a libubi.a but>>> mkfs.ubifs/Makefile have no way to use it>>>> what's wrong with adding -lubi and a -L path ?>> It'll work only if libubi is already built. You can fix that in the> root Makefile, but> - parallel builds may not work (make -j)
a simple dependency is easy
> - "cd mkfs.ubifs && make" won't work (using only the mkfs.ubifs Makefile)
if the .a file is added to the dependency list, then it's easy to have
a normal recursive target:
........./libubi.a:
$(MAKE) -C $(dir $@)
-mike

I didn't think of calling make here.
Thanks
On 5/8/09, Mike Frysinger <vapier.adi@gmail.com> wrote:
> On Fri, May 8, 2009 at 15:41, Corentin Chary wrote:>> On Fri, May 8, 2009 at 8:58 PM, Mike Frysinger wrote:>>> On Fri, May 8, 2009 at 10:59, Corentin Chary wrote:>>>> I'll see what I can do to use libubi the way I want.>>>> The problem of using libubi in mkfs is not the includes (we can copy>>>> the headers in /include or add -I../ubi-utils/include).>>>>>> why do you need to copy any files ?>>>>>>> The main problem is that ubi-utils/Makefile make a libubi.a but>>>> mkfs.ubifs/Makefile have no way to use it>>>>>> what's wrong with adding -lubi and a -L path ?>>>> It'll work only if libubi is already built. You can fix that in the>> root Makefile, but>> - parallel builds may not work (make -j)>> a simple dependency is easy>>> - "cd mkfs.ubifs && make" won't work (using only the mkfs.ubifs Makefile)>> if the .a file is added to the dependency list, then it's easy to have> a normal recursive target:> ........./libubi.a:> $(MAKE) -C $(dir $@)> -mike>

On Fri, May 8, 2009 at 16:32, Corentin Chary wrote:
> I didn't think of calling make here.
if you want, you can just implement things with updated build paths
and then ask someone (like me) to take a look at parallel/recursive
builds
the build system problem is that it has to be implemented in something
the active community can work with. the linux-mtd maintainers and
most people who watch it semi-actively can work fine with plain
makefiles. cmake however does not satisfy those conditions. i
personally dont mind adding cmake build files so long as someone
volunteers to maintain/update them, but i wouldnt require people
submitting changes to update/test them, only the makefiles. if the
files get orphaned over time, then they get deleted and we arent stuck
in a situation where we have to migrate back to a build system
everyone knows.
-mike