>
> My (DTC) plan is to apply the single patch with some
> include file fixes, and release that.
>
> I'll line the slew of patches up for the following release.
>
> jdl
And that's not at all what happened.
One of David's patches (BSD portability) was a superset of the
include-file fixes suppli
> libfdt is supposed to easy to embed in projects all and sundry.
> Often, it won't be practical to separate the embedded libfdt's
> namespace from that of the surrounding project. Which means there can
> be namespace conflicts between even libfdt's internal/static functions
> and functions or mac
>
> > On a slightly unrelated note, are you planning to sync the in-kernel
> > dtc/libfdt version with the upstream version anytime soon?
>
> I know jon put an -rc, not sure if he plans to pick up the slew of
> patches for the next -rc or the next release, but it would be good to
> resync the
On Jul 9, 2008, at 6:42 AM, Josh Boyer wrote:
On Wed, 2008-07-09 at 14:10 +1000, David Gibson wrote:
libfdt is supposed to easy to embed in projects all and sundry.
Often, it won't be practical to separate the embedded libfdt's
namespace from that of the surrounding project. Which means there
On Wed, 2008-07-09 at 14:10 +1000, David Gibson wrote:
> libfdt is supposed to easy to embed in projects all and sundry.
> Often, it won't be practical to separate the embedded libfdt's
> namespace from that of the surrounding project. Which means there can
> be namespace conflicts between even li
libfdt is supposed to easy to embed in projects all and sundry.
Often, it won't be practical to separate the embedded libfdt's
namespace from that of the surrounding project. Which means there can
be namespace conflicts between even libfdt's internal/static functions
and functions or macros coming
