<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <p><br>

    </p>

    <div class="moz-cite-prefix">On 10/07/19 3:05 PM, Oliver O'Halloran

      wrote:<br>

    </div>

    <blockquote type="cite"

cite="mid:CAOSf1CE9tm5fjSmZwOqfqryoqMN7k_JxA1MWms84FNg8rrgNzw@mail.gmail.com">

      <pre class="moz-quote-pre" wrap="">On Wed, Jul 10, 2019 at 5:11 PM Hari Bathini <a class="moz-txt-link-rfc2396E" href="mailto:hbathini@linux.ibm.com"><hbathini@linux.ibm.com></a> wrote:

</pre>

      <blockquote type="cite">

        <pre class="moz-quote-pre" wrap="">

Sorry, if I was not clear but that is how it is. Metadata is setup by

production kernel based on user configuration and after crash, petitboot kernel

looks for this metadata to work out how much memory it is allowed to trash

(<a class="moz-txt-link-freetext" href="https://patchwork.ozlabs.org/patch/1122300/">https://patchwork.ozlabs.org/patch/1122300/</a>).

As for the type field in the metadata, that requirement comes from the need to

keep metadata retrieval simple. Without a type field, we need to have a predefined

ordering or kernel has to remember which tag no. corresponds to which data type.

While the former seems naive, the later, brings with it a need to handle kernel

metadata separately as we need to get that data before processing tags.

</pre>

      </blockquote>

      <pre class="moz-quote-pre" wrap="">

I don't see a problem with either approach. Say we do the "naive"

thing and change the API to this:

enum opal_mpipl_tag {

OPAL_MPIPL_TAG_PROC_DATA,

OPAL_MPIPL_TAG_CORE,

OPAL_MPIPL_TAG_KERNEL,

}

And fetch the tags with:

int64_t opal_mpipl_query_tag(enum opal_mpipl_tag tag, uint64_t *tag_value);</pre>

    </blockquote>

    <pre>

Actually, I would love to have it this way but I remember Nick was not for having a

type field in the opal call..

Thanks

Hari

</pre>

  </body>

</html>