RFC: barebox RATP C library?

RFC: barebox RATP C library?

[Aleksander Morgado]

Hey,

I've been playing a bit with the possibility of having a C library to
talk RATP with barebox, totally equivalent to what bbremote does in
python, but as a general C lib with a stable API that may be
integrated in other C/C++ applications.

From my POV I see two options to try:
   a) build a library based on lib/ratp.c and common/ratp.c but
without directly sharing the source code; i.e. just take bits and
pieces from those implementations where necessary, and write the
library as any other userspace library.
   b) build a small library that allows including lib/ratp.c (and
maybe common/ratp.c) directly in the build, but which would require
those files to be updated in a way that allow being shared by a
separate library that isn't running in the whole barebox runtime
context.

I'm not sure if anyone has thoughts on this; I initially thought b)
would be definitely the way to go, but the current implementation
seems too tied to the actual barebox runtime, so maybe it's just
easier to setup a) and just share e.g. the barebox RATP message format
structs, enums and so on.

Comments, suggestions?

-- 
Aleksander
https://aleksander.es

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: RFC: barebox RATP C library?

[Sascha Hauer]

On Mon, Jun 05, 2017 at 07:17:27PM +0200, Aleksander Morgado wrote:
> Hey,
> 
> I've been playing a bit with the possibility of having a C library to
> talk RATP with barebox, totally equivalent to what bbremote does in
> python, but as a general C lib with a stable API that may be
> integrated in other C/C++ applications.
> 
> From my POV I see two options to try:
>    a) build a library based on lib/ratp.c and common/ratp.c but
> without directly sharing the source code; i.e. just take bits and
> pieces from those implementations where necessary, and write the
> library as any other userspace library.
>    b) build a small library that allows including lib/ratp.c (and
> maybe common/ratp.c) directly in the build, but which would require
> those files to be updated in a way that allow being shared by a
> separate library that isn't running in the whole barebox runtime
> context.
> 
> I'm not sure if anyone has thoughts on this; I initially thought b)
> would be definitely the way to go, but the current implementation
> seems too tied to the actual barebox runtime, so maybe it's just
> easier to setup a) and just share e.g. the barebox RATP message format
> structs, enums and so on.

b) should be the goal, but the way leads over a) anyway ;)

Where are the problems with sharing the code? I think the different
timers might be a problem. Anything else? Maybe you could start
modifying the code to fit to a userspace library while still trying
to keep the diff to the original files small. From the resulting diff
between the files we can decide if it's worth going to b) or
if the different APIs are just too different. We could also modify
barebox to fit more to the userspace API.

I'm not sure if it's worth sharing the build system though. We could
still copy the ratp code, but keep both versions in sync.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox