should YP docs explain "type=kmeta" and "destsuffix="?

should YP docs explain "type=kmeta" and "destsuffix="?

[Robert P. J. Day]

  i see that the meta-xilinx layer takes advantage of extending the
search path for features directories with things like:

SRC_URI = " \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=https;branch=${KBRANCH} \
                file://xilinx-base;type=kmeta;destsuffix=xilinx-base \
                file://0001-ARM64-Add-new-Xilinx-ZynqMP-SoC.patch \
  ... etc etc ...

and the above is processed from kernel-yocto.bbclass with:

# check the SRC_URI for "kmeta" type'd git repositories. Return the name of
# the repository as it will be found in WORKDIR
def find_kernel_feature_dirs(d):
    feature_dirs=[]
    fetch = bb.fetch2.Fetch([], d)
    for url in fetch.urls:
        urldata = fetch.ud[url]
        parm = urldata.parm
        if "type" in parm:
            type = parm["type"]
        if "destsuffix" in parm:
            destdir = parm["destsuffix"]
            if type == "kmeta":
                feature_dirs.append(destdir)

    return feature_dirs

i see no mention of this feature in any of the YP docs ... is it meant
to be used by normal developers, so that it should be explained?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: should YP docs explain "type=kmeta" and "destsuffix="?

[Bruce Ashfield]

On 15-03-04 10:10 AM, Robert P. J. Day wrote:
>
>    i see that the meta-xilinx layer takes advantage of extending the
> search path for features directories with things like:
>
> SRC_URI = " \
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=https;branch=${KBRANCH} \
>                  file://xilinx-base;type=kmeta;destsuffix=xilinx-base \
>                  file://0001-ARM64-Add-new-Xilinx-ZynqMP-SoC.patch \
>    ... etc etc ...
>
> and the above is processed from kernel-yocto.bbclass with:
>
> # check the SRC_URI for "kmeta" type'd git repositories. Return the name of
> # the repository as it will be found in WORKDIR
> def find_kernel_feature_dirs(d):
>      feature_dirs=[]
>      fetch = bb.fetch2.Fetch([], d)
>      for url in fetch.urls:
>          urldata = fetch.ud[url]
>          parm = urldata.parm
>          if "type" in parm:
>              type = parm["type"]
>          if "destsuffix" in parm:
>              destdir = parm["destsuffix"]
>              if type == "kmeta":
>                  feature_dirs.append(destdir)
>
>      return feature_dirs
>
> i see no mention of this feature in any of the YP docs ... is it meant
> to be used by normal developers, so that it should be explained?

It's not really a typical developer option. It is for maintaining a
separate repository of meta-data, and then allowing the tools and
kernel to use that meta data as part of the build.

Only someone maintaining (and sharing) a large set of their own
kernel fragments would be interested in this.

So I'm on the fence if it is worth documenting, but lean towards
at least mentioning it and offering a simple use case.

Bruce

>
> rday
>

Re: should YP docs explain "type=kmeta" and "destsuffix="?

[Robert P. J. Day]

On Wed, 4 Mar 2015, Bruce Ashfield wrote:

> On 15-03-04 10:10 AM, Robert P. J. Day wrote:
> >
> >    i see that the meta-xilinx layer takes advantage of extending the
> > search path for features directories with things like:
> >
> > SRC_URI = " \
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=https;branch=${KBRANCH}
> > \
> > file://xilinx-base;type=kmeta;destsuffix=xilinx-base \
> > file://0001-ARM64-Add-new-Xilinx-ZynqMP-SoC.patch \
> >    ... etc etc ...
> >
> > and the above is processed from kernel-yocto.bbclass with:
> >
> > # check the SRC_URI for "kmeta" type'd git repositories. Return the name of
> > # the repository as it will be found in WORKDIR
> > def find_kernel_feature_dirs(d):
> >      feature_dirs=[]
> >      fetch = bb.fetch2.Fetch([], d)
> >      for url in fetch.urls:
> >          urldata = fetch.ud[url]
> >          parm = urldata.parm
> >          if "type" in parm:
> >              type = parm["type"]
> >          if "destsuffix" in parm:
> >              destdir = parm["destsuffix"]
> >              if type == "kmeta":
> >                  feature_dirs.append(destdir)
> >
> >      return feature_dirs
> >
> > i see no mention of this feature in any of the YP docs ... is it meant
> > to be used by normal developers, so that it should be explained?
>
> It's not really a typical developer option. It is for maintaining a
> separate repository of meta-data, and then allowing the tools and
> kernel to use that meta data as part of the build.
>
> Only someone maintaining (and sharing) a large set of their own
> kernel fragments would be interested in this.
>
> So I'm on the fence if it is worth documenting, but lean towards at
> least mentioning it and offering a simple use case.

  if it's not a normal developer option, then i wouldn't want it to be
presented as *regular* kernel dev content, so as not to break up the
flow of presentation -- one of my pet peeves in documentation is
distraction from normal content with a topic that's obscure or meant
for only 1 per cent of the readership, that just throws off the rhythm
of the presentation.

  however, it might fit in a section on, say, "advanced kernel
workflow concepts", or something like that. appendix, perhaps?

  also, i only ask about this as i tripped across it perusing the
meta-xilinx layer, and thought, "wait a minute, what's this?" but
nothing says that it's being used properly in the meta-xilinx layer
... i think it's worth documenting but only if it's accompanied by a
use case that clearly shows its value over the standard technique
involving regular .cfg and .scc files.

  anyway, movin' on ...

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: should YP docs explain "type=kmeta" and "destsuffix="?

[Robert P. J. Day]

On Wed, 4 Mar 2015, Bruce Ashfield wrote:

... snip my stuff ...

> It's not really a typical developer option. It is for maintaining a
> separate repository of meta-data, and then allowing the tools and
> kernel to use that meta data as part of the build.
>
> Only someone maintaining (and sharing) a large set of their own
> kernel fragments would be interested in this.
>
> So I'm on the fence if it is worth documenting, but lean towards at
> least mentioning it and offering a simple use case.

  just FYI, of all the layers i have checked out and try to keep up
with, the meta-xilinx layer is the only one that takes advantage of
that "type=kmeta" feature and nathan rossi on that list suggested that
he did that just to get something working and out the door, so it's
entirely possible that that really *isn't* a normal developer option
that needs to be documented.

  so i'll leave this with people higher up the food chain ... perhaps
it really is something that needs explanation only in an advanced
kernel workflow section or something like that.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================