From: Eugeniu Rosca <roscaeugeniu@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 3/7] common: Implement A/B metadata
Date: Sun, 7 Apr 2019 18:51:46 +0200 [thread overview]
Message-ID: <20190407165146.GA29940@x230> (raw)
In-Reply-To: <CAH3KO=3uXtJ0jRaZ7atgmagRcUXEKXNUD+cLoSe+fxH_jsBWQg@mail.gmail.com>
Hi Simon, Igor, All,
On Wed, Apr 03, 2019 at 07:55:30PM +0200, Eugeniu Rosca wrote:
> Hi Simon, Igor, Ruslan,
>
> On Thu, Dec 6, 2018 at 4:05 AM Simon Glass <sjg@chromium.org> wrote:
> > Hi Ruslan,
> >
> > On Tue, 27 Nov 2018 at 12:57, Ruslan Trofymenko
> > <ruslan.trofymenko@linaro.org> wrote:
> > >
> [..]
> > > +struct android_bootloader_message {
> >
> > How about andr_bl_msg ? Similarly below
>
> Simon, I am currently working on a new U-Boot command which requires
> the same AOSP header in-tree. Since the v4 of the whole "A/B support"
> series is still WIP by Igor (Ruslan?), may I kindly ask you whether
> you feel strong about these specific header and struct renames? We've
> recently got some feedback from Tom [1] that it should be OK to keep
> the out-of-tree headers untouched. My main motivation is 1) minimizing
> the effort of updating this specific header from upstream and 2) using
> the U-Boot-compliant header/struct names in my WIP changes. I am open
> minded if the original filename is not preserved, but the struct
> renames imply some amount of changes in the comments (see [2]). Also,
> renaming the structs will imply parsing and verifying the comments
> each time the header is updated. It's this kind of tiny bit of
> integration effort which you always want to avoid, since it doesn't
> require any creativity and can't be automated easily. I am looking
> forward for your feedback.
>
> Dear Igor, Ruslan,
>
> How should we handle the import of
> bootloader_message/include/bootloader_message/bootloader_message.h ?
> If it takes more time for you to submit the next version of A/B
> support, would it be fine for you if I do the importing of the header
> myself along with my other patches which depend on it?
>
> [1] https://patchwork.ozlabs.org/patch/1044158/#2129429
> [2] https://patchwork.ozlabs.org/patch/1044158/#2109299
Apologize for making another iteration on this, but what about below
solution WRT struct renames upon importing bootloader_message.h in-tree.
The following typedef statements (placed in the imported header) would
allow keeping the original structures and the associated comments
untouched (hence speeding up the updates from the source), while U-Boot
would use use the new/rightmost types mirroring the upstream ones.
typedef struct bootloader_message andr_bl_msg;
typedef struct bootloader_message_ab andr_bl_msg_ab;
typedef struct bootloader_control andr_bl_control;
>
> Many thanks,
> Eugeniu.
next prev parent reply other threads:[~2019-04-07 16:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-27 19:57 [U-Boot] [PATCH 0/7] android: Implement A/B boot process Ruslan Trofymenko
2018-11-27 19:57 ` [U-Boot] [PATCH 1/7] cmd: part: Add 'number' sub-command Ruslan Trofymenko
2018-12-06 1:31 ` Simon Glass
2018-11-27 19:57 ` [U-Boot] [PATCH 2/7] disk: part: Extend API to get partition info Ruslan Trofymenko
2018-12-06 1:31 ` Simon Glass
2018-11-27 19:57 ` [U-Boot] [PATCH 3/7] common: Implement A/B metadata Ruslan Trofymenko
2018-12-06 1:31 ` Simon Glass
2019-04-03 17:55 ` Eugeniu Rosca
2019-04-07 16:51 ` Eugeniu Rosca [this message]
2019-04-07 19:11 ` Igor Opaniuk
2019-04-07 22:22 ` Eugeniu Rosca
2018-11-27 19:57 ` [U-Boot] [PATCH 4/7] cmd: Add 'android_ab_select' command Ruslan Trofymenko
2018-11-27 19:57 ` [U-Boot] [PATCH 5/7] test/py: Add base test case for A/B updates Ruslan Trofymenko
2018-12-06 1:31 ` Simon Glass
2018-11-27 19:57 ` [U-Boot] [PATCH 6/7] doc: android: Add simple guide " Ruslan Trofymenko
2018-12-06 1:31 ` Simon Glass
2018-12-10 19:10 ` Ruslan Trofymenko
2018-12-11 0:00 ` Simon Glass
2018-11-27 19:57 ` [U-Boot] [PATCH 7/7] env: am57xx: Implement A/B boot process Ruslan Trofymenko
2018-11-27 20:09 ` [U-Boot] [PATCH 0/7] android: " Alistair Strachan
2018-11-28 14:38 ` Sam Protsenko
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=20190407165146.GA29940@x230 \
--to=roscaeugeniu@gmail.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.