[RPI BSP] zero length array in kernel and refactor of video char output
Gedare Bloom
gedare at gwu.edu
Wed Jun 24 14:10:29 UTC 2015
On Wed, Jun 24, 2015 at 2:31 AM, QIAO YANG <yangqiao0505 at me.com> wrote:
>
> 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.
>
Yeah I saw this #2 just yesterday too. Good job.
> 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.
>
Makes sense.
> 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.
>
I made a few comments but I think the idea is good for moving forward.
Gedare
More information about the devel
mailing list