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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox