From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] siteinfo: Add mechanism to extend siteinfo information from BSP layer
Date: Fri, 22 Jul 2016 16:55:30 +0100 [thread overview]
Message-ID: <1469202930.23580.73.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAMKF1spXDX=C9miFBi5DjRgzCKk7esdNZWH0QgakDjgU_9bT6A@mail.gmail.com>
On Fri, 2016-07-22 at 08:47 -0700, Khem Raj wrote:
> Whats the motivation here. This looks like a backdoor for bsps. To
> user it will make inconsistent behaviour. Even now its quite hard to
> root cause errors due to siteinfo
Right now if you have some new target, your only option is to either
patch OE-Core, or copy the class into your new BSP. This is
particularly problematic if you're working on hardware that isn't
supported by core OE or that is in active development.
Having hooks to allow you to write a new BSP without having to make
changes to the core would seem to be a good thing.
I'm not expecting users to regularly use this, just those writing more
exotic BSPs or doing baremetal work for example.
I can sympathise with the problem as I've run into it several times now
myself. We can't really demand that every time this happens, people
send a patch for OE-Core (although if something is commonly used we'd
obviously then encourage it).
Cheers,
Richard
next prev parent reply other threads:[~2016-07-22 15:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-22 14:25 [PATCH] siteinfo: Add mechanism to extend siteinfo information from BSP layer Richard Purdie
[not found] ` <CAMKF1srw4bVtAHrq6uOVU__WueXjoNwKRsvxLNLudt_zFyzrzQ@mail.gmail.com>
[not found] ` <CAMKF1sqzsoR=+FyXL99f+SZts6gxnNOfH0_MpX_y2M1FP-gbdA@mail.gmail.com>
2016-07-22 15:47 ` Khem Raj
2016-07-22 15:55 ` Richard Purdie [this message]
2016-07-22 18:20 ` Khem Raj
2016-07-22 22:16 ` Richard Purdie
2016-07-23 1:28 ` Khem Raj
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=1469202930.23580.73.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/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.