<div dir="ltr">I'm sorry, just forget to attach the patch.<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 15, 2013 at 10:13 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Post patch at your convenience. We should include a test case that<br>
uses the workspace. It will also need to do "CONFIGURE_EXTRA_MEMORY"<br>
or something to declare how much of workspace it uses.<br></blockquote><div>Sorry, Gedare, I try to search the "CONFIGURE_EXTRA_MEMORY", but find no details.<br></div><div>I was thinking can we do workspace_allocate() in rtems for user defined data structure? Or we have to configure rtems structure as unlimited, like regions, semaphores, and then workspace becomes available for user defined data structure and we can use workspace_allocate() to allocate user defined data.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5"><br>
On Sun, Jul 14, 2013 at 9:55 PM, Ashi <<a href="mailto:ashi08104@gmail.com">ashi08104@gmail.com</a>> wrote:<br>
> Hi, all, I've updated this patch:<br>
> - rename freelist to freechain<br>
> - remove free_count<br>
> - replace freelist_bump() with an user defined extension handle<br>
> - add 2 test cases:<br>
> - spfreechain01: basic freechain operation test<br>
> - spfreechain02: test whether freechain works correctly when calls user<br>
> defined extension handle, and the handle uses malloc for memory allocation.<br>
><br>
> And I don't whether we need test case for user defined extension handle<br>
> which uses workspace for memory allocation.<br>
><br>
> Thanks,<br>
> Zhongwei<br>
><br>
><br>
> On Fri, Jul 12, 2013 at 6:57 PM, Ashi <<a href="mailto:ashi08104@gmail.com">ashi08104@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>><br>
>> On Thu, Jul 11, 2013 at 9:18 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>>><br>
>>> I don't think we need SAPI. We could consider adding a "classic"<br>
>>> manager interface. Meanwhile, you can write the testsuite with<br>
>>> "#define __RTEMS_VIOLATE_KERNEL_VISIBILITY__" and access the supercore<br>
>>> freelist interface directly...<br>
>><br>
>> OK, I'll use direct way for now.<br>
>>><br>
>>><br>
>>> On Thu, Jul 11, 2013 at 12:25 AM, Ashi <<a href="mailto:ashi08104@gmail.com">ashi08104@gmail.com</a>> wrote:<br>
>>> ><br>
>>> > And I'm adding the test case, and find we haven't the SAPI for freelist<br>
>>> > yet.<br>
>>> > I must add it before adding test case, right? By the way, is the SAPI<br>
>>> > same<br>
>>> > as the user-level API layer as Gedare mentioned before? I haven't<br>
>>> > realized<br>
>>> > it before.<br>
>>> ><br>
>>> ><br>
>>> > On Wed, Jul 10, 2013 at 8:31 PM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>>> >><br>
>>> >> You would call extend instead of calling bump, or as part of bumping.<br>
>>> ><br>
>>> > Thanks, I see.<br>
>>> >><br>
>>> >><br>
>>> >> On Wed, Jul 10, 2013 at 2:30 AM, Ashi <<a href="mailto:ashi08104@gmail.com">ashi08104@gmail.com</a>> wrote:<br>
>>> >> > Thanks for all good explanation.<br>
>>> >> ><br>
>>> >> ><br>
>>> >> > On Tue, Jul 9, 2013 at 11:24 PM, Sebastian Huber<br>
>>> >> > <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>>> >> >><br>
>>> >> >> On 07/09/2013 05:29 AM, Ashi wrote:<br>
>>> >> >>><br>
>>> >> >>> Hi, Sebastian, thanks for your review!<br>
>>> >> >>><br>
>>> >> >>> 在 2013-7-7 下午9:49，"Sebastian Huber"<br>
>>> >> >>> <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a><br>
>>> >> >>> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>>>写道：<br>
>>> >> >>><br>
>>> >> >>> ><br>
>>> >> >>> > Hello Ashi,<br>
>>> >> >>> ><br>
>>> >> >>> ><br>
>>> >> >>> > On 06/07/13 09:17, Ashi wrote:<br>
>>> >> >>> >><br>
>>> >> >>> >> Hi all,<br>
>>> >> >>> >><br>
>>> >> >>> >> this patch adds a data structure called freelist to score,<br>
>>> >> >>> there<br>
>>> >> >>> are<br>
>>> >> >>> no<br>
>>> >> >>> >> test cases yet and should be added later.<br>
>>> >> >>> ><br>
>>> >> >>> ><br>
>>> >> >>> > I would appreciate to have the test for this new stuff included<br>
>>> >> >>> in<br>
>>> >> >>> the<br>
>>> >> >>> patch.<br>
>>> >> >>><br>
>>> >> >>><br>
>>> >> >>> sure, I will update the patch with test cases.<br>
>>> >> >>> ><br>
>>> >> >>> ><br>
>>> >> >>> >><br>
>>> >> >>> >> Freelist is a structure, which contains a chain of nodes. It<br>
>>> >> >>> supports<br>
>>> >> >>> 2<br>
>>> >> >>> >> operation:<br>
>>> >> >>> >> - get node from freelist<br>
>>> >> >>> >> - put node to freelist.<br>
>>> >> >>> >> And when there is no enough node in freelist, it will<br>
>>> >> >>> automatically<br>
>>> >> >>> >> increase itself's size by allocate more nodes from heap or<br>
>>> >> >>> workspace(which<br>
>>> >> >>> >> is specified by user).<br>
>>> >> >>> ><br>
>>> >> >>> ><br>
>>> >> >>> > What can I do if I like to get the nodes from a magic space?<br>
>>> >> >>><br>
>>> >> >>><br>
>>> >> >>> sorry for the unclear, you can get nodes from freelist by 'get'<br>
>>> >> >>> operation. And<br>
>>> >> >>> if you mean get nodes from heap or workspace, it's done by<br>
>>> >> >>> _Freelist_Get_node(), which calls _Freelist_Bump() when there is<br>
>>> >> >>> no<br>
>>> >> >>> free<br>
>>> >> >>> node left.<br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> Yes, the problem is that you limit your Freelist to the heap and<br>
>>> >> >> workspace. If you use a handler function (or virtual method if you<br>
>>> >> >> like)<br>
>>> >> >> then you can avoid this limitation.<br>
>>> >> >><br>
>>> >> >> [...]<br>
>>> >> >><br>
>>> >> >>> >> +/**<br>
>>> >> >>> >> + * @typedef freelist_callout<br>
>>> >> >>> >> + */<br>
>>> >> >>> >> +typedef void (*freelist_callout)(<br>
>>> >> >>> >> + Freelist_Control *fc,<br>
>>> >> >>> >> + void *nodes<br>
>>> >> >>> >> +);<br>
>>> >> >>> >> +<br>
>>> >> >>> >> +/**<br>
>>> >> >>> >> + * @typedef Freelist_Control_struct<br>
>>> >> >>> >> + *<br>
>>> >> >>> >> + * This is used to manage each element.<br>
>>> >> >>> >> + */<br>
>>> >> >>> >> +struct Freelist_Control_struct {<br>
>>> >> >>> >> + Chain_Control Freelist;<br>
>>> >> >>> >> + size_t free_count;<br>
>>> >> >>> ><br>
>>> >> >>> ><br>
>>> >> >>> > Why do we need the free_count?<br>
>>> >> >>><br>
>>> >> >>> free_count is used to keep track how many nodes there is in<br>
>>> >> >>> freelist.<br>
>>> >> >>> And<br>
>>> >> >>> if<br>
>>> >> >>> free_count is 0 when you try to get node from freelist by call<br>
>>> >> >>> _Freelist_Get_node(), _Freelist_Get_node() will call<br>
>>> >> >>> _Freelist_Bump()<br>
>>> >> >>> to<br>
>>> >> >>> allocate more node from heap or workspace.<br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> The list knows if it is empty. There is not need to store this<br>
>>> >> >> information in two ways.<br>
>>> >> >><br>
>>> >> >><br>
>>> >> >>> ><br>
>>> >> >>> >> + size_t bump_count;<br>
>>> >> >>> >> + size_t node_size;<br>
>>> >> >>> ><br>
>>> >> >>> ><br>
>>> >> >>> >> + freelist_callout callout;<br>
>>> >> >>> >> + bool use_workspace;<br>
>>> >> >>> >> +};<br>
>>> >> >>> ><br>
>>> >> >>> ><br>
>>> >> >>> > I would replace this with an extend handler.<br>
>>> >> >>> ><br>
>>> >> >>> > /**<br>
>>> >> >>> > * @brief Extends the freelist.<br>
>>> >> >>> > *<br>
>>> >> >>> > * @param[in] freelist The freelist control.<br>
>>> >> >>> > *<br>
>>> >> >>> > * @return The count of new nodes.<br>
>>> >> >>> > */<br>
>>> >> >>> > typedef size_t ( *Freelist_Extend )( Freelist_Control *freelist<br>
>>> >> >>> );<br>
>>> >> >>> ><br>
>>> >> >>> > This is much more flexible since you only specify the interface<br>
>>> >> >>> and<br>
>>> >> >>> don't<br>
>>> >> >>> limit this to heap/workspace.<br>
>>> >> >>> ><br>
>>> >> >>> > You can provide a _Freelist_Extend_with_nothing() which simply<br>
>>> >> >>> returns<br>
>>> >> >>> 0.<br>
>>> >> >>><br>
>>> >> >>> Yeah, this Freelist_Extend is very flexible, but I feel the<br>
>>> >> >>> Freelist_Extend is<br>
>>> >> >>> a little complex. As it shows in _Freelist_Bump(), if users<br>
>>> >> >>> provides<br>
>>> >> >>> their own<br>
>>> >> >>> extension function, they have to append there new nodes to<br>
>>> >> >>> freelist's<br>
>>> >> >>> internal<br>
>>> >> >>> chain and call their callout function on new nodes. And since<br>
>>> >> >>> _Freelist_Initialize() also would call Freelist_Extend(), if we<br>
>>> >> >>> provided<br>
>>> >> >>> _Freelist_Extend_with_nothing(), the initialization may fail.<br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> Since the Freelist_Extend gets the Freelist as a first argument it<br>
>>> >> >> can<br>
>>> >> >> set<br>
>>> >> >> the extend handler to _Freelist_Extend_with_nothing() after the<br>
>>> >> >> first<br>
>>> >> >> invocation.<br>
>>> >> >><br>
>>> >> >> Example:<br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> /**<br>
>>> >> >> * @brief Extends the freelist.<br>
>>> >> >> *<br>
>>> >> >> * @param[in] freelist The freelist control.<br>
>>> >> >> */<br>
>>> >> >> typedef void ( *Freelist_Extend )( Freelist_Control *freelist );<br>
>>> >> >><br>
>>> >> >> typedef struct {<br>
>>> >> >> Objects_Control obj;<br>
>>> >> >> int x;<br>
>>> >> >> } my_obj;<br>
>>> >> >><br>
>>> >> >> void my_extend( Freelist_Control *freelist )<br>
>>> >> >> {<br>
>>> >> >> size_t bump_count = freelist->bump_count;<br>
>>> >> >> size_t size = bump_count * sizeof(my_obj);<br>
>>> >> >> my_obj *objs = malloc(size);<br>
>>> >> >><br>
>>> >> >> _Freelist_Set_extend_handler( freelist,<br>
>>> >> >> _Freelist_Extend_with_nothing<br>
>>> >> >> );<br>
>>> >> >> _Chain_Initialize(<br>
>>> >> >> _Freelist_Get_list( freelist ),<br>
>>> >> >> objs,<br>
>>> >> >> bump_count,<br>
>>> >> >> size<br>
>>> >> >> );<br>
>>> >> >><br>
>>> >> >> }<br>
>>> >> ><br>
>>> >> > I'm a little confused by my_extend() function, is it only called<br>
>>> >> > after<br>
>>> >> > calling _Freelist_Initialize() by user?<br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> [...]<br>
>>> >> >><br>
>>> >> >> --<br>
>>> >> >> Sebastian Huber, embedded brains GmbH<br>
>>> >> >><br>
>>> >> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
>>> >> >> Phone : +49 89 189 47 41-16<br>
>>> >> >> Fax : +49 89 189 47 41-09<br>
>>> >> >> E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a><br>
>>> >> >> PGP : Public key available on request.<br>
>>> >> >><br>
>>> >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des<br>
>>> >> >> EHUG.<br>
>>> >> ><br>
>>> >> ><br>
>>> >> > Cheers,<br>
>>> >> > Zhongwei<br>
>>> >> ><br>
>>> ><br>
>>> ><br>
>><br>
>><br>
><br>
</div></div></blockquote></div>Thanks,<br>Zhongwei<br></div></div>