[RPI BSP] zero length array in kernel and refactor of video char output

QIAO YANG yangqiao0505 at me.com
Wed Jun 24 06:31:35 UTC 2015


On Jun 23, 2015, at 07:15 AM, Gedare Bloom <gedare at rtems.org> wrote:

On Tue, Jun 23, 2015 at 7:43 AM, QIAO YANG <yangqiao0505 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150624/4e72295e/attachment.html>


More information about the devel mailing list