On Jun 23, 2015, at 07:15 AM, Gedare Bloom <ged...@rtems.org> wrote:
On Tue, Jun 23, 2015 at 7:43 AM, QIAO YANG <yangqiao0...@me.com> wrote:
Hi,
As suggested by gedare, I think using zero length array to represent the
mailbox buffer and tag data is a good way, much readable, clearer to
abstract the structure of mailbox buffer, tag.
I've done an attemp, here is the scratch:
https://github.com/yangqiao/rtems/commit/3ed7e9bde493bdc8e644fcefa285d99255201ada
The construction of a buffer is then decomposed by the following procedure:
1. Calculate the total length of buffer
2. Allocate and inite the buffer
3. Pack the request data into buffer
4. send the buffer by mailbox, then read the responce
5. Unpack the responce data into variables
I've tested it in userspace it works well but in kernel space I cannot
allocate the memory by malloc. Is there any alternative way to let us use
zero length array in the kernel driver?
It depends. BSP code can use malloc, but care should be taken about
where you use it. An alternative would be to use a free list.
I've retried to allocate zero-length-array statically and I've found some
problems:
1. As described in GCC manual, the size of struct that contains an zero length
array at the end, is determined by the size of the initializer's given array.
But what I've found is that the the initializer don't initialize the zero
length array. it has to be set afterward. I doubt that the problem comes from
the cross compiler. Even if I don't give initializer for the array, I can get
access to the elements. It's dangerous and it doesn't work as described in
manual.
2. I'm afraid that a struct A that contains a zero length array of struct B,
where struct B has a zero-length array, is not acceptable. As the second struct
B2 doesn't know the length of B1, so the position of B2 would be shifted and
override part of the structure B1.
So I propose to:
1. Don't queue the tags, we handle them one by one. one buffer , one tag.
2. Use the zero length array to define the structure of tag.
3. single function for each tag operation.
4. lock to ensure that only one function is in process to avoid mailbox
conflict.
https://github.com/yangqiao/rtems/commit/971d3ccdab04171494a3b73684f4f6f243e230b9
I've only implement the function to get display size here. If it's ok I'll add
some others.
Secondly, since part of functions in outch is considered sharable between
bsps. If my implementation is acceptable, I'll push the refactor code for
review. Here is my implementation
https://github.com/yangqiao/rtems/commit/858a9b091025acc4bfe912f41d70c9a73b99d773
You still need to attribute the original source of that file.
Thanks in advance.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
