Re: [RPI BSP] zero length array in kernel and refactor of video char output
On Wed, Jun 24, 2015 at 2:31 AM, QIAO YANG wrote: > > On Jun 23, 2015, at 07:15 AM, Gedare Bloom wrote: > > On Tue, Jun 23, 2015 at 7:43 AM, QIAO YANG 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
[RPI BSP] zero length array in kernel and refactor of video char output
On Jun 23, 2015, at 07:15 AM, Gedare Bloom wrote: On Tue, Jun 23, 2015 at 7:43 AM, QIAO YANG 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
Re: [RPI BSP] zero length array in kernel and refactor of video char output
On Tue, Jun 23, 2015 at 7:43 AM, QIAO YANG 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. > > 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
[RPI BSP] zero length array in kernel and refactor of video char output
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? 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 Thanks in advance.___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
