All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v7] libxl: provide libxl_bitmap_{or,and}
@ 2015-04-15 17:02 Linda Jacobson
  2015-04-16 14:34 ` Ian Campbell
  2015-06-03 15:24 ` clarification of xen Wiki article Linda
  0 siblings, 2 replies; 19+ messages in thread
From: Linda Jacobson @ 2015-04-15 17:02 UTC (permalink / raw)
  To: xen-devel
  Cc: wei.liu2, ian.campbell, stefano.stabellini, lars.kurth.xen,
	julien.grall, ian.jackson, lindaj

New functions to provide logical and and or of two bitmaps functions can be
used in vNUMA configuration check function. They are also generally useful, so
they have been made as public API.

Signed-off-by: Linda Jacobson <lindaj@jma3.com>

---

v.1 The new functions were added.
v.2 The comments and format were corrected.
v.3 The bitmap functions were rewritten to manipulate bytes not bits.
v.4 Several non-modified parameters, and local variables were changed to const
    Also the code formatting was fixed.
v.5 The commit subject line now has versions and is simpler.
v.6 All descriptions in the commit history are now complete sentences.
    Extraneous blank lines are gone.
v.7 Added LIBXL_BIT_HAVE_AND_OR to libxl.h; deleted extraneous comment in
    libxl_utils.h; and updated the commit log to include the uses for these
    functions
---
 tools/libxl/libxl.h       |  9 ++++++
 tools/libxl/libxl_utils.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_utils.h |  6 ++++
 3 files changed, 85 insertions(+)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 5eec092..1fb9549 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -84,6 +84,15 @@
 #define LIBXL_HAVE_CPUPOOL_QUALIFIER_TO_CPUPOOLID 1
 
 /*
+ *
+ * LIBXL_HAVE_BITMAP_AND_OR
+ *
+ * If this is defined, libxl has two libarary functions, libxl_bitmap_and
+ * and libxl_bitmap_or to compute the logical and and or of two bitmaps
+ */
+#define LIBXL_HAVE_BITMAP_AND_OR 1
+
+/*
  * LIBXL_HAVE_FIRMWARE_PASSTHROUGH indicates the feature for
  * passing in SMBIOS and ACPI firmware to HVM guests is present
  * in the library.
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 9053b27..f552700 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -691,6 +691,76 @@ void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit)
     bitmap->map[bit / 8] &= ~(1 << (bit & 7));
 }
 
+int libxl_bitmap_or(libxl_ctx *ctx, libxl_bitmap *or_map,
+                    const libxl_bitmap *map1, const libxl_bitmap *map2)
+{
+    GC_INIT(ctx);
+    int rc;
+    uint32_t i;
+    const libxl_bitmap *large_map;
+    const libxl_bitmap *small_map;
+
+    if (map1->size > map2->size) {
+        large_map = map1;
+        small_map = map2;
+    } else {
+        large_map = map2;
+        small_map = map1;
+    }
+
+    rc = libxl_bitmap_alloc(ctx, or_map, large_map->size * 8);
+    if (rc)
+        goto out;
+
+    /*
+     *  If bitmaps aren't the same size, their union (logical or) will
+     *  be size of larger bit map.  Any bit past the end of the
+     *  smaller bit map, will match the larger one.
+     */
+    for (i = 0; i < small_map->size; i++)
+        or_map->map[i] = (small_map->map[i] | large_map->map[i]);
+
+    for (i = small_map->size; i < large_map->size; i++)
+        or_map->map[i] = large_map->map[i];
+
+out:
+    GC_FREE;
+    return rc;
+}
+
+int libxl_bitmap_and(libxl_ctx *ctx, libxl_bitmap *and_map,
+                     const libxl_bitmap *map1, const libxl_bitmap *map2)
+{
+    GC_INIT(ctx);    
+    int rc;
+    uint32_t i;
+    const libxl_bitmap *large_map;
+    const libxl_bitmap *small_map;
+
+    if (map1->size > map2->size) {
+        large_map = map1;
+        small_map = map2;
+    } else {
+        large_map = map2;
+        small_map = map1;
+    }
+
+    rc = libxl_bitmap_alloc(ctx, and_map, small_map->size * 8);
+    if (rc)
+        goto out;
+
+    /* 
+     *  If bitmaps aren't same size, their 'and' will be size of
+     *  smaller bit map
+     */
+    for (i = 0; i < and_map->size; i++)
+        and_map->map[i] = (large_map->map[i] & small_map->map[i]);
+
+out: 
+    GC_FREE;
+    return rc;
+}
+
 int libxl_bitmap_count_set(const libxl_bitmap *bitmap)
 {
     int i, nr_set_bits = 0;
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index acacdd9..f5a3168 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -90,6 +90,12 @@ int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
 void libxl_bitmap_set(libxl_bitmap *bitmap, int bit);
 void libxl_bitmap_reset(libxl_bitmap *bitmap, int bit);
 int libxl_bitmap_count_set(const libxl_bitmap *cpumap);
+int libxl_bitmap_or(libxl_ctx *ctx, libxl_bitmap *or_map,
+                    const libxl_bitmap *map1, 
+                    const libxl_bitmap *map2); 
+int libxl_bitmap_and(libxl_ctx *ctx, libxl_bitmap *and_map,
+                     const libxl_bitmap *map1, 
+                     const libxl_bitmap *map2);
 char *libxl_bitmap_to_hex_string(libxl_ctx *ctx, const libxl_bitmap *cpumap);
 static inline void libxl_bitmap_set_any(libxl_bitmap *bitmap)
 {
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: [PATCH v7] libxl: provide libxl_bitmap_{or,and}
  2015-04-15 17:02 [PATCH v7] libxl: provide libxl_bitmap_{or,and} Linda Jacobson
@ 2015-04-16 14:34 ` Ian Campbell
  2015-04-16 14:40   ` Linda
  2015-06-03 15:24 ` clarification of xen Wiki article Linda
  1 sibling, 1 reply; 19+ messages in thread
From: Ian Campbell @ 2015-04-16 14:34 UTC (permalink / raw)
  To: Linda Jacobson
  Cc: wei.liu2, stefano.stabellini, lars.kurth.xen, julien.grall,
	ian.jackson, xen-devel

On Wed, 2015-04-15 at 11:02 -0600, Linda Jacobson wrote:
> New functions to provide logical and and or of two bitmaps functions can be
> used in vNUMA configuration check function.

I don't think that really justifies adding them, since we aren't
actually using them for that now, how about:

        New functions to provide logical and and or of two bitmaps.
        These are generically useful utility functions added to the
        public API for the benefit of libxl's users.
        
        In the future they may also be useful internally, e.g. in the
        vNUMA configuration check function.

If you are happy with that, and there's no other reason to resend, then
I can switch in that text as I commit.

> Signed-off-by: Linda Jacobson <lindaj@jma3.com>
> 
> ---
> 
> v.1 The new functions were added.
> v.2 The comments and format were corrected.
> v.3 The bitmap functions were rewritten to manipulate bytes not bits.
> v.4 Several non-modified parameters, and local variables were changed to const
>     Also the code formatting was fixed.
> v.5 The commit subject line now has versions and is simpler.
> v.6 All descriptions in the commit history are now complete sentences.
>     Extraneous blank lines are gone.
> v.7 Added LIBXL_BIT_HAVE_AND_OR to libxl.h; deleted extraneous comment in
>     libxl_utils.h; and updated the commit log to include the uses for these
>     functions
> ---
>  tools/libxl/libxl.h       |  9 ++++++
>  tools/libxl/libxl_utils.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_utils.h |  6 ++++
>  3 files changed, 85 insertions(+)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 5eec092..1fb9549 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -84,6 +84,15 @@
>  #define LIBXL_HAVE_CPUPOOL_QUALIFIER_TO_CPUPOOLID 1
>  
>  /*
> + *
> + * LIBXL_HAVE_BITMAP_AND_OR
> + *
> + * If this is defined, libxl has two libarary functions, libxl_bitmap_and

"library".

(again, can fix on commit)

Other than those:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v7] libxl: provide libxl_bitmap_{or,and}
  2015-04-16 14:34 ` Ian Campbell
@ 2015-04-16 14:40   ` Linda
  2015-04-16 14:45     ` Wei Liu
  0 siblings, 1 reply; 19+ messages in thread
From: Linda @ 2015-04-16 14:40 UTC (permalink / raw)
  To: Ian Campbell
  Cc: wei.liu2, stefano.stabellini, lars.kurth.xen, julien.grall,
	ian.jackson, xen-devel

On 4/16/2015 8:34 AM, Ian Campbell wrote:
> On Wed, 2015-04-15 at 11:02 -0600, Linda Jacobson wrote:
>> New functions to provide logical and and or of two bitmaps functions can be
>> used in vNUMA configuration check function.
> I don't think that really justifies adding them, since we aren't
> actually using them for that now, how about:
>
>          New functions to provide logical and and or of two bitmaps.
>          These are generically useful utility functions added to the
>          public API for the benefit of libxl's users.
>          
>          In the future they may also be useful internally, e.g. in the
>          vNUMA configuration check function.
>
> If you are happy with that, and there's no other reason to resend, then
> I can switch in that text as I commit.
I'm fine with this.  If Wei and Julien are, please go ahead.
>
>> Signed-off-by: Linda Jacobson <lindaj@jma3.com>
>>
>> ---
>>
>> v.1 The new functions were added.
>> v.2 The comments and format were corrected.
>> v.3 The bitmap functions were rewritten to manipulate bytes not bits.
>> v.4 Several non-modified parameters, and local variables were changed to const
>>      Also the code formatting was fixed.
>> v.5 The commit subject line now has versions and is simpler.
>> v.6 All descriptions in the commit history are now complete sentences.
>>      Extraneous blank lines are gone.
>> v.7 Added LIBXL_BIT_HAVE_AND_OR to libxl.h; deleted extraneous comment in
>>      libxl_utils.h; and updated the commit log to include the uses for these
>>      functions
>> ---
>>   tools/libxl/libxl.h       |  9 ++++++
>>   tools/libxl/libxl_utils.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++
>>   tools/libxl/libxl_utils.h |  6 ++++
>>   3 files changed, 85 insertions(+)
>>
>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>> index 5eec092..1fb9549 100644
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -84,6 +84,15 @@
>>   #define LIBXL_HAVE_CPUPOOL_QUALIFIER_TO_CPUPOOLID 1
>>   
>>   /*
>> + *
>> + * LIBXL_HAVE_BITMAP_AND_OR
>> + *
>> + * If this is defined, libxl has two libarary functions, libxl_bitmap_and
> "library".
>
> (again, can fix on commit)
Thanks for catching the typo.

Linda Jacobson
>
> Other than those:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
>
>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v7] libxl: provide libxl_bitmap_{or,and}
  2015-04-16 14:40   ` Linda
@ 2015-04-16 14:45     ` Wei Liu
  2015-04-16 16:49       ` Linda
  0 siblings, 1 reply; 19+ messages in thread
From: Wei Liu @ 2015-04-16 14:45 UTC (permalink / raw)
  To: Linda
  Cc: wei.liu2, Ian Campbell, stefano.stabellini, lars.kurth.xen,
	julien.grall, ian.jackson, xen-devel

On Thu, Apr 16, 2015 at 08:40:52AM -0600, Linda wrote:
> On 4/16/2015 8:34 AM, Ian Campbell wrote:
> >On Wed, 2015-04-15 at 11:02 -0600, Linda Jacobson wrote:
> >>New functions to provide logical and and or of two bitmaps functions can be
> >>used in vNUMA configuration check function.
> >I don't think that really justifies adding them, since we aren't
> >actually using them for that now, how about:
> >
> >         New functions to provide logical and and or of two bitmaps.
> >         These are generically useful utility functions added to the
> >         public API for the benefit of libxl's users.
> >         In the future they may also be useful internally, e.g. in the
> >         vNUMA configuration check function.
> >
> >If you are happy with that, and there's no other reason to resend, then
> >I can switch in that text as I commit.
> I'm fine with this.  If Wei and Julien are, please go ahead.

Julien is away now. I'm of course fine with this -- it's your
contribution after all, you have the final say. :-)

And congratulations to you for getting first patch accepted!

Wei.

> >
> >>Signed-off-by: Linda Jacobson <lindaj@jma3.com>
> >>
> >>---
> >>
> >>v.1 The new functions were added.
> >>v.2 The comments and format were corrected.
> >>v.3 The bitmap functions were rewritten to manipulate bytes not bits.
> >>v.4 Several non-modified parameters, and local variables were changed to const
> >>     Also the code formatting was fixed.
> >>v.5 The commit subject line now has versions and is simpler.
> >>v.6 All descriptions in the commit history are now complete sentences.
> >>     Extraneous blank lines are gone.
> >>v.7 Added LIBXL_BIT_HAVE_AND_OR to libxl.h; deleted extraneous comment in
> >>     libxl_utils.h; and updated the commit log to include the uses for these
> >>     functions
> >>---
> >>  tools/libxl/libxl.h       |  9 ++++++
> >>  tools/libxl/libxl_utils.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++
> >>  tools/libxl/libxl_utils.h |  6 ++++
> >>  3 files changed, 85 insertions(+)
> >>
> >>diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> >>index 5eec092..1fb9549 100644
> >>--- a/tools/libxl/libxl.h
> >>+++ b/tools/libxl/libxl.h
> >>@@ -84,6 +84,15 @@
> >>  #define LIBXL_HAVE_CPUPOOL_QUALIFIER_TO_CPUPOOLID 1
> >>  /*
> >>+ *
> >>+ * LIBXL_HAVE_BITMAP_AND_OR
> >>+ *
> >>+ * If this is defined, libxl has two libarary functions, libxl_bitmap_and
> >"library".
> >
> >(again, can fix on commit)
> Thanks for catching the typo.
> 
> Linda Jacobson
> >
> >Other than those:
> >Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >
> >
> >

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v7] libxl: provide libxl_bitmap_{or,and}
  2015-04-16 14:45     ` Wei Liu
@ 2015-04-16 16:49       ` Linda
  2015-04-22 14:21         ` Ian Campbell
  0 siblings, 1 reply; 19+ messages in thread
From: Linda @ 2015-04-16 16:49 UTC (permalink / raw)
  To: Wei Liu
  Cc: Ian Campbell, stefano.stabellini, lars.kurth.xen, julien.grall,
	ian.jackson, xen-devel

On 4/16/2015 8:45 AM, Wei Liu wrote:
> On Thu, Apr 16, 2015 at 08:40:52AM -0600, Linda wrote:
>> On 4/16/2015 8:34 AM, Ian Campbell wrote:
>>> On Wed, 2015-04-15 at 11:02 -0600, Linda Jacobson wrote:
>>>> New functions to provide logical and and or of two bitmaps functions can be
>>>> used in vNUMA configuration check function.
>>> I don't think that really justifies adding them, since we aren't
>>> actually using them for that now, how about:
>>>
>>>          New functions to provide logical and and or of two bitmaps.
>>>          These are generically useful utility functions added to the
>>>          public API for the benefit of libxl's users.
>>>          In the future they may also be useful internally, e.g. in the
>>>          vNUMA configuration check function.
>>>
>>> If you are happy with that, and there's no other reason to resend, then
>>> I can switch in that text as I commit.
>> I'm fine with this.  If Wei and Julien are, please go ahead.
> Julien is away now. I'm of course fine with this -- it's your
> contribution after all, you have the final say. :-)
Then, Ian, please, go ahead.
>
> And congratulations to you for getting first patch accepted!

Why, thank you.

Linda
>
> Wei.
>
>>>> Signed-off-by: Linda Jacobson <lindaj@jma3.com>
>>>>
>>>> ---
>>>>
>>>> v.1 The new functions were added.
>>>> v.2 The comments and format were corrected.
>>>> v.3 The bitmap functions were rewritten to manipulate bytes not bits.
>>>> v.4 Several non-modified parameters, and local variables were changed to const
>>>>      Also the code formatting was fixed.
>>>> v.5 The commit subject line now has versions and is simpler.
>>>> v.6 All descriptions in the commit history are now complete sentences.
>>>>      Extraneous blank lines are gone.
>>>> v.7 Added LIBXL_BIT_HAVE_AND_OR to libxl.h; deleted extraneous comment in
>>>>      libxl_utils.h; and updated the commit log to include the uses for these
>>>>      functions
>>>> ---
>>>>   tools/libxl/libxl.h       |  9 ++++++
>>>>   tools/libxl/libxl_utils.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++
>>>>   tools/libxl/libxl_utils.h |  6 ++++
>>>>   3 files changed, 85 insertions(+)
>>>>
>>>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>>>> index 5eec092..1fb9549 100644
>>>> --- a/tools/libxl/libxl.h
>>>> +++ b/tools/libxl/libxl.h
>>>> @@ -84,6 +84,15 @@
>>>>   #define LIBXL_HAVE_CPUPOOL_QUALIFIER_TO_CPUPOOLID 1
>>>>   /*
>>>> + *
>>>> + * LIBXL_HAVE_BITMAP_AND_OR
>>>> + *
>>>> + * If this is defined, libxl has two libarary functions, libxl_bitmap_and
>>> "library".
>>>
>>> (again, can fix on commit)
>> Thanks for catching the typo.
>>
>> Linda Jacobson
>>> Other than those:
>>> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>>>
>>>
>>>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH v7] libxl: provide libxl_bitmap_{or,and}
  2015-04-16 16:49       ` Linda
@ 2015-04-22 14:21         ` Ian Campbell
  0 siblings, 0 replies; 19+ messages in thread
From: Ian Campbell @ 2015-04-22 14:21 UTC (permalink / raw)
  To: Linda
  Cc: Wei Liu, stefano.stabellini, lars.kurth.xen, julien.grall,
	ian.jackson, xen-devel

On Thu, 2015-04-16 at 10:49 -0600, Linda wrote:
> On 4/16/2015 8:45 AM, Wei Liu wrote:
> > On Thu, Apr 16, 2015 at 08:40:52AM -0600, Linda wrote:
> >> On 4/16/2015 8:34 AM, Ian Campbell wrote:
> >>> On Wed, 2015-04-15 at 11:02 -0600, Linda Jacobson wrote:
> >>>> New functions to provide logical and and or of two bitmaps functions can be
> >>>> used in vNUMA configuration check function.
> >>> I don't think that really justifies adding them, since we aren't
> >>> actually using them for that now, how about:
> >>>
> >>>          New functions to provide logical and and or of two bitmaps.
> >>>          These are generically useful utility functions added to the
> >>>          public API for the benefit of libxl's users.
> >>>          In the future they may also be useful internally, e.g. in the
> >>>          vNUMA configuration check function.
> >>>
> >>> If you are happy with that, and there's no other reason to resend, then
> >>> I can switch in that text as I commit.
> >> I'm fine with this.  If Wei and Julien are, please go ahead.
> > Julien is away now. I'm of course fine with this -- it's your
> > contribution after all, you have the final say. :-)
> Then, Ian, please, go ahead.

Done, thanks.

I had to apply with "git am --whitespace=fixup" due to the trailing
whitespace which the patches added.

Ian

^ permalink raw reply	[flat|nested] 19+ messages in thread

* clarification of xen Wiki article
  2015-04-15 17:02 [PATCH v7] libxl: provide libxl_bitmap_{or,and} Linda Jacobson
  2015-04-16 14:34 ` Ian Campbell
@ 2015-06-03 15:24 ` Linda
  2015-06-04  9:58   ` Ian Campbell
  2015-06-11  1:45   ` grant tables and driver handshaking Linda
  1 sibling, 2 replies; 19+ messages in thread
From: Linda @ 2015-06-03 15:24 UTC (permalink / raw)
  To: xen-devel; +Cc: julien.grall, lars.kurth.xen, Wei Liu

Hi all,
     I was reading

http://wiki.xen.org/wiki/XenBus

In the section on Store Organization, there is the statement "Information should not be replicated in the store and required to be consistent "  I'm not sure what that means.

Can anybody clarify this for me, please?

Thanks.

linda

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: clarification of xen Wiki article
  2015-06-03 15:24 ` clarification of xen Wiki article Linda
@ 2015-06-04  9:58   ` Ian Campbell
  2015-06-04 10:35     ` Wei Liu
  2015-06-04 11:15     ` Linda
  2015-06-11  1:45   ` grant tables and driver handshaking Linda
  1 sibling, 2 replies; 19+ messages in thread
From: Ian Campbell @ 2015-06-04  9:58 UTC (permalink / raw)
  To: Linda; +Cc: julien.grall, xen-devel, Wei Liu, lars.kurth.xen

On Wed, 2015-06-03 at 09:24 -0600, Linda wrote:
> Hi all,
>      I was reading
> 
> http://wiki.xen.org/wiki/XenBus
> 
> In the section on Store Organization, there is the statement
> "Information should not be replicated in the store and required to be
> consistent "  I'm not sure what that means.
> 
> Can anybody clarify this for me, please?

This came from the old wiki, so the history is unclear.

I suppose it could mean either:

        If you replicate information in xenstore then you should not
        expect it to be consistent

or

        Do not replicate information, do not require information to be
        consistent.

But let me turn the question around: What are you actually trying to
achieve? i.e. what is causing this ambiguous and confusing statement to
be a concern for you.

Unless the author or someone else in the know speaks up I would propose
to remove this text from the wiki.

Ian.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: clarification of xen Wiki article
  2015-06-04  9:58   ` Ian Campbell
@ 2015-06-04 10:35     ` Wei Liu
  2015-06-04 11:31       ` Wei Liu
  2015-06-04 11:15     ` Linda
  1 sibling, 1 reply; 19+ messages in thread
From: Wei Liu @ 2015-06-04 10:35 UTC (permalink / raw)
  To: Ian Campbell; +Cc: julien.grall, xen-devel, lars.kurth.xen, Wei Liu, Linda

On Thu, Jun 04, 2015 at 10:58:18AM +0100, Ian Campbell wrote:
> Unless the author or someone else in the know speaks up I would propose
> to remove this text from the wiki.
> 

+1 for this.

Wei.

> Ian.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: clarification of xen Wiki article
  2015-06-04  9:58   ` Ian Campbell
  2015-06-04 10:35     ` Wei Liu
@ 2015-06-04 11:15     ` Linda
  1 sibling, 0 replies; 19+ messages in thread
From: Linda @ 2015-06-04 11:15 UTC (permalink / raw)
  To: Ian Campbell; +Cc: julien.grall, xen-devel, Wei Liu, lars.kurth.xen

On 6/4/2015 3:58 AM, Ian Campbell wrote:
> On Wed, 2015-06-03 at 09:24 -0600, Linda wrote:
>> Hi all,
>>       I was reading
>>
>> http://wiki.xen.org/wiki/XenBus
>>
>> In the section on Store Organization, there is the statement
>> "Information should not be replicated in the store and required to be
>> consistent "  I'm not sure what that means.
>>
>> Can anybody clarify this for me, please?
> This came from the old wiki, so the history is unclear.
>
> I suppose it could mean either:
>
>          If you replicate information in xenstore then you should not
>          expect it to be consistent
>
> or
>
>          Do not replicate information, do not require information to be
>          consistent.
>
> But let me turn the question around: What are you actually trying to
> achieve? i.e. what is causing this ambiguous and confusing statement to
> be a concern for you.
Sometime soon I will be writing a front- and back- end for the 9p fs 
protocol.  (My Outreachy project).  My goall is
to understand where drivers sit logically and physically, so I know what 
I'm doing.  Part of this is to understand Xenbus and Xenstore.

When I know too little, I read carefully, and flag anything I don't 
understand.  For now, I'll ignore this statement.

Thanks, Ian.

Linda Jacobson
>
> Unless the author or someone else in the know speaks up I would propose
> to remove this text from the wiki.
>
> Ian.
>
>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: clarification of xen Wiki article
  2015-06-04 10:35     ` Wei Liu
@ 2015-06-04 11:31       ` Wei Liu
  2015-06-04 11:35         ` Ian Campbell
  0 siblings, 1 reply; 19+ messages in thread
From: Wei Liu @ 2015-06-04 11:31 UTC (permalink / raw)
  To: Ian Campbell; +Cc: julien.grall, xen-devel, lars.kurth.xen, Wei Liu, Linda

On Thu, Jun 04, 2015 at 11:35:23AM +0100, Wei Liu wrote:
> On Thu, Jun 04, 2015 at 10:58:18AM +0100, Ian Campbell wrote:
> > Unless the author or someone else in the know speaks up I would propose
> > to remove this text from the wiki.
> > 
> 
> +1 for this.
> 

Ian, I looked at the history of that page. It looks like it was you who
created that page. Since you as the original author doesn't have idea
what that sentence means I've removed that sentence.

Wei.

> Wei.
> 
> > Ian.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: clarification of xen Wiki article
  2015-06-04 11:31       ` Wei Liu
@ 2015-06-04 11:35         ` Ian Campbell
  2015-06-04 11:46           ` Wei Liu
  0 siblings, 1 reply; 19+ messages in thread
From: Ian Campbell @ 2015-06-04 11:35 UTC (permalink / raw)
  To: Wei Liu; +Cc: julien.grall, xen-devel, lars.kurth.xen, Linda

On Thu, 2015-06-04 at 12:31 +0100, Wei Liu wrote:
> On Thu, Jun 04, 2015 at 11:35:23AM +0100, Wei Liu wrote:
> > On Thu, Jun 04, 2015 at 10:58:18AM +0100, Ian Campbell wrote:
> > > Unless the author or someone else in the know speaks up I would propose
> > > to remove this text from the wiki.
> > > 
> > 
> > +1 for this.
> > 
> 
> Ian, I looked at the history of that page. It looks like it was you who
> created that page.

No, I imported it from the old wiki, for which wee don't have history
(AFAIK). "This came from the old wiki, so the history is unclear." was
in my reply.

> Since you as the original author doesn't have idea
> what that sentence means I've removed that sentence.
> 
> Wei.
> 
> > Wei.
> > 
> > > Ian.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: clarification of xen Wiki article
  2015-06-04 11:35         ` Ian Campbell
@ 2015-06-04 11:46           ` Wei Liu
  0 siblings, 0 replies; 19+ messages in thread
From: Wei Liu @ 2015-06-04 11:46 UTC (permalink / raw)
  To: Ian Campbell; +Cc: julien.grall, xen-devel, lars.kurth.xen, Wei Liu, Linda

On Thu, Jun 04, 2015 at 12:35:22PM +0100, Ian Campbell wrote:
> On Thu, 2015-06-04 at 12:31 +0100, Wei Liu wrote:
> > On Thu, Jun 04, 2015 at 11:35:23AM +0100, Wei Liu wrote:
> > > On Thu, Jun 04, 2015 at 10:58:18AM +0100, Ian Campbell wrote:
> > > > Unless the author or someone else in the know speaks up I would propose
> > > > to remove this text from the wiki.
> > > > 
> > > 
> > > +1 for this.
> > > 
> > 
> > Ian, I looked at the history of that page. It looks like it was you who
> > created that page.
> 
> No, I imported it from the old wiki, for which wee don't have history
> (AFAIK). "This came from the old wiki, so the history is unclear." was
> in my reply.
> 

Ah, OK. My change can be reverted if it turns out to be problematic.

Wei.

> > Since you as the original author doesn't have idea
> > what that sentence means I've removed that sentence.
> > 
> > Wei.
> > 
> > > Wei.
> > > 
> > > > Ian.
> 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* grant tables and driver handshaking
  2015-06-03 15:24 ` clarification of xen Wiki article Linda
  2015-06-04  9:58   ` Ian Campbell
@ 2015-06-11  1:45   ` Linda
  2015-06-11 10:43     ` Wei Liu
  1 sibling, 1 reply; 19+ messages in thread
From: Linda @ 2015-06-11  1:45 UTC (permalink / raw)
  To: xen-devel; +Cc: julien.grall, lars.kurth.xen, Wei Liu

Hello all,
     I will be writing a xen front and back-end pair for a 9p 
transport.  I have two areas where I'm still a little more muddled than 
I'd like to be.
     Can anyone please recommend a good article on either grant tables 
or the handshaking between the front and back-end drivers, or both?
     I have looked at the code, but could use more verbiage.
Thanks.

Linda

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: grant tables and driver handshaking
  2015-06-11  1:45   ` grant tables and driver handshaking Linda
@ 2015-06-11 10:43     ` Wei Liu
  2015-06-11 12:32       ` Linda
  0 siblings, 1 reply; 19+ messages in thread
From: Wei Liu @ 2015-06-11 10:43 UTC (permalink / raw)
  To: Linda; +Cc: julien.grall, xen-devel, Wei Liu, lars.kurth.xen

On Wed, Jun 10, 2015 at 07:45:15PM -0600, Linda wrote:
> Hello all,
>     I will be writing a xen front and back-end pair for a 9p transport.  I
> have two areas where I'm still a little more muddled than I'd like to be.
>     Can anyone please recommend a good article on either grant tables or the
> handshaking between the front and back-end drivers, or both?

The handshake protocol needs to be designed by you. Generally speaking
you need to at least advertise the event channel and grant table
references. You also need to advertise other information that you
identify as part of the handshake process.

There is a wiki page on grant table

http://wiki.xenproject.org/wiki/Grant_Table

Wei.

>     I have looked at the code, but could use more verbiage.
> Thanks.
> 
> Linda

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: grant tables and driver handshaking
  2015-06-11 10:43     ` Wei Liu
@ 2015-06-11 12:32       ` Linda
  2015-06-11 16:24         ` Wei Liu
  0 siblings, 1 reply; 19+ messages in thread
From: Linda @ 2015-06-11 12:32 UTC (permalink / raw)
  To: Wei Liu; +Cc: julien.grall, xen-devel, lars.kurth.xen

On 6/11/2015 4:43 AM, Wei Liu wrote:
> On Wed, Jun 10, 2015 at 07:45:15PM -0600, Linda wrote:
>> Hello all,
>>      I will be writing a xen front and back-end pair for a 9p transport.  I
>> have two areas where I'm still a little more muddled than I'd like to be.
>>      Can anyone please recommend a good article on either grant tables or the
>> handshaking between the front and back-end drivers, or both?
> The handshake protocol needs to be designed by you. Generally speaking
> you need to at least advertise the event channel and grant table
> references. You also need to advertise other information that you
> identify as part of the handshake process.
OK.  That explains half of my muddle.

Here's the other half.  The wiki article on xenbus taks about the 
front-end registering with xenbus, before anything else happens. But in 
blkback, it looks like it too has to do some kind of setup with xenbus, 
too.

Since the backend is in DOM0, and is around longer than the DOMUs, this 
happens first.   It's that interaction that I'd like a little more text 
on.  If it exists.
>
> There is a wiki page on grant table
>
> http://wiki.xenproject.org/wiki/Grant_Table
Thanks.
>
> Wei.
>
>>      I have looked at the code, but could use more verbiage.
>> Thanks.
>>
>> Linda

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: grant tables and driver handshaking
  2015-06-11 12:32       ` Linda
@ 2015-06-11 16:24         ` Wei Liu
  2015-06-11 16:38           ` Ian Campbell
  0 siblings, 1 reply; 19+ messages in thread
From: Wei Liu @ 2015-06-11 16:24 UTC (permalink / raw)
  To: Linda; +Cc: julien.grall, xen-devel, Wei Liu, lars.kurth.xen

On Thu, Jun 11, 2015 at 06:32:08AM -0600, Linda wrote:
> On 6/11/2015 4:43 AM, Wei Liu wrote:
> >On Wed, Jun 10, 2015 at 07:45:15PM -0600, Linda wrote:
> >>Hello all,
> >>     I will be writing a xen front and back-end pair for a 9p transport.  I
> >>have two areas where I'm still a little more muddled than I'd like to be.
> >>     Can anyone please recommend a good article on either grant tables or the
> >>handshaking between the front and back-end drivers, or both?
> >The handshake protocol needs to be designed by you. Generally speaking
> >you need to at least advertise the event channel and grant table
> >references. You also need to advertise other information that you
> >identify as part of the handshake process.
> OK.  That explains half of my muddle.
> 
> Here's the other half.  The wiki article on xenbus taks about the front-end
> registering with xenbus, before anything else happens. But in blkback, it
> looks like it too has to do some kind of setup with xenbus, too.
> 

Not sure if you still have questions in this area or not. If so please
reply and preferable with the specific code snippet you find
confusing.

> Since the backend is in DOM0, and is around longer than the DOMUs, this
> happens first.   It's that interaction that I'd like a little more text on.
> If it exists.

I'm not completely sure what you're referring to. That probably only
exists in code. The interaction between backend and frontend is very
driver specific.

Wei.

> >
> >There is a wiki page on grant table
> >
> >http://wiki.xenproject.org/wiki/Grant_Table
> Thanks.
> >
> >Wei.
> >
> >>     I have looked at the code, but could use more verbiage.
> >>Thanks.
> >>
> >>Linda

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: grant tables and driver handshaking
  2015-06-11 16:24         ` Wei Liu
@ 2015-06-11 16:38           ` Ian Campbell
  2015-06-11 17:11             ` Linda
  0 siblings, 1 reply; 19+ messages in thread
From: Ian Campbell @ 2015-06-11 16:38 UTC (permalink / raw)
  To: Wei Liu; +Cc: julien.grall, xen-devel, lars.kurth.xen, Linda

On Thu, 2015-06-11 at 17:24 +0100, Wei Liu wrote:
> > Since the backend is in DOM0, and is around longer than the DOMUs, this
> > happens first.   It's that interaction that I'd like a little more text on.
> > If it exists.
> 
> I'm not completely sure what you're referring to. That probably only
> exists in code. The interaction between backend and frontend is very
> driver specific.

Most front and backend pairs follow a similar pattern though, and it is
best not to reinvent the wheel completely, even if some of the details
differ.

In general everything is driven from a pair of "state" nodes in
xenstore, one in the frontend dir and one in the backend dir.

These contain the enum xenbus_state from xen/include/public/io/xenbus.h
(as %d formatted integers). In general both front and backend start in
state 1 (XenbusStateInitialising) and each has a watch on the other end.
Things generally start with the backend moving to state 2
(XenbusStateInitWait) and from there they progress n lockstep through
the stages until they both reach state 4 (XenbusStateConnected), then
you are up and running.

On teardown one end goes to 5 (XenbusStateClosing) and the other
follows.

In Linux the place to look is the various "otherend_changed" hooks in
the front and back drivers, usually the backend half is in a xenbus.c
file (e.g. netback and blkback).

blkif.h has a description of the states in that case.
http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,blkif.h.html

I'm not aware of any particular docs on the general case, or at least I
can't find the ones I thought we had.

Ian

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: grant tables and driver handshaking
  2015-06-11 16:38           ` Ian Campbell
@ 2015-06-11 17:11             ` Linda
  0 siblings, 0 replies; 19+ messages in thread
From: Linda @ 2015-06-11 17:11 UTC (permalink / raw)
  To: Ian Campbell, Wei Liu; +Cc: julien.grall, xen-devel, lars.kurth.xen



On 6/11/2015 10:38 AM, Ian Campbell wrote:
> On Thu, 2015-06-11 at 17:24 +0100, Wei Liu wrote:
>>> Since the backend is in DOM0, and is around longer than the DOMUs, this
>>> happens first.   It's that interaction that I'd like a little more text on.
>>> If it exists.
>> I'm not completely sure what you're referring to. That probably only
>> exists in code. The interaction between backend and frontend is very
>> driver specific.
> Most front and backend pairs follow a similar pattern though, and it is
> best not to reinvent the wheel completely, even if some of the details
> differ.
>
> In general everything is driven from a pair of "state" nodes in
> xenstore, one in the frontend dir and one in the backend dir.
>
> These contain the enum xenbus_state from xen/include/public/io/xenbus.h
> (as %d formatted integers). In general both front and backend start in
> state 1 (XenbusStateInitialising) and each has a watch on the other end.
> Things generally start with the backend moving to state 2
> (XenbusStateInitWait) and from there they progress n lockstep through
> the stages until they both reach state 4 (XenbusStateConnected), then
> you are up and running.
>
> On teardown one end goes to 5 (XenbusStateClosing) and the other
> follows.
Thanks, Ian.  This helped a lot.

And thanks for the links, below.

Linda
> In Linux the place to look is the various "otherend_changed" hooks in
> the front and back drivers, usually the backend half is in a xenbus.c
> file (e.g. netback and blkback).
>
> blkif.h has a description of the states in that case.
> http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,blkif.h.html
>
> I'm not aware of any particular docs on the general case, or at least I
> can't find the ones I thought we had.

>
> Ian
>
>

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2015-06-11 17:11 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-15 17:02 [PATCH v7] libxl: provide libxl_bitmap_{or,and} Linda Jacobson
2015-04-16 14:34 ` Ian Campbell
2015-04-16 14:40   ` Linda
2015-04-16 14:45     ` Wei Liu
2015-04-16 16:49       ` Linda
2015-04-22 14:21         ` Ian Campbell
2015-06-03 15:24 ` clarification of xen Wiki article Linda
2015-06-04  9:58   ` Ian Campbell
2015-06-04 10:35     ` Wei Liu
2015-06-04 11:31       ` Wei Liu
2015-06-04 11:35         ` Ian Campbell
2015-06-04 11:46           ` Wei Liu
2015-06-04 11:15     ` Linda
2015-06-11  1:45   ` grant tables and driver handshaking Linda
2015-06-11 10:43     ` Wei Liu
2015-06-11 12:32       ` Linda
2015-06-11 16:24         ` Wei Liu
2015-06-11 16:38           ` Ian Campbell
2015-06-11 17:11             ` Linda

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.