On Wed, Jun 24, 2015 at 2:31 AM, QIAO YANG <yangqiao0...@me.com> wrote: > > 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. > 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
