mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Aleksander Morgado <aleksander@aleksander.es>
Cc: barebox@lists.infradead.org
Subject: Re: RFC: barebox RATP C library?
Date: Tue, 6 Jun 2017 08:49:21 +0200	[thread overview]
Message-ID: <20170606064921.7jebs4phfdemombf@pengutronix.de> (raw)
In-Reply-To: <CAAP7ucJ9m2SvZ29nNbQF7HRKcGSQ0O_RVFKF63Xv79CCR=uA_g@mail.gmail.com>

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

      reply	other threads:[~2017-06-06  6:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-05 17:17 Aleksander Morgado
2017-06-06  6:49 ` Sascha Hauer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170606064921.7jebs4phfdemombf@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=aleksander@aleksander.es \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox