Good day y'all,
Many of you have received a gerrit review request that concerns Gator and a kernel API change that happened between 3.3 and 3.4. If you maintain a build associated to a board, please review.
The problem happens when compiling an android build with a 3.4 kernel. The Gator driver is looking for the 'd_alloc_root' function when compiling 'gator_fs.c', something that is provided by the kernel.
But commit [1] has replaced the function with 'd_make_root' during the 3.4 merge cycle. Zach suggested to point the last SHA of the old API to avoid spinning off yet another branch, something that was implemented as part of [2].
If you are the last one to review and have merge rights, please push the changes.
Best regards, Mathieu.
[1]. 32991ab vfs: d_alloc_root() gone [2]. http://review.android.git.linaro.org/#change,2014
On Mon, May 7, 2012 at 11:40 PM, Mathieu Poirier mathieu.poirier@linaro.org wrote:
Good day y'all,
Many of you have received a gerrit review request that concerns Gator and a kernel API change that happened between 3.3 and 3.4. If you maintain a build associated to a board, please review.
The problem happens when compiling an android build with a 3.4 kernel. The Gator driver is looking for the 'd_alloc_root' function when compiling 'gator_fs.c', something that is provided by the kernel.
But commit [1] has replaced the function with 'd_make_root' during the 3.4 merge cycle. Zach suggested to point the last SHA of the old API to avoid spinning off yet another branch, something that was implemented as part of [2].
If you are the last one to review and have merge rights, please push the changes.
I assume it's the driver/ part of ds5 causing troubles here? Any way to make the source support both kernel ABIs using an #ifdef or something? In this way we could continue tracking the latest and would be able to spin 3.3 and 3.4 based LEBs off the same thing.
On 12-05-07 03:48 PM, Alexander Sack wrote:
On Mon, May 7, 2012 at 11:40 PM, Mathieu Poirier mathieu.poirier@linaro.org wrote:
Good day y'all,
Many of you have received a gerrit review request that concerns Gator and a kernel API change that happened between 3.3 and 3.4. If you maintain a build associated to a board, please review.
The problem happens when compiling an android build with a 3.4 kernel. The Gator driver is looking for the 'd_alloc_root' function when compiling 'gator_fs.c', something that is provided by the kernel.
But commit [1] has replaced the function with 'd_make_root' during the 3.4 merge cycle. Zach suggested to point the last SHA of the old API to avoid spinning off yet another branch, something that was implemented as part of [2].
If you are the last one to review and have merge rights, please push the changes.
I assume it's the driver/ part of ds5 causing troubles here? Any way to make the source support both kernel ABIs using an #ifdef or something? In this way we could continue tracking the latest and would be able to spin 3.3 and 3.4 based LEBs off the same thing.
Correct, it's the driver part of ds5.
Using and #ifdef would mean that all builds would have to declare a new define somewhere, which, in my opinion is not as clean as what Zach and I are proposing.
This approach is easy - as soon as the kernel for a board moves to 3.4 then the branch can be tracked again rather than the SHA.
On Tue, May 8, 2012 at 12:01 AM, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On 12-05-07 03:48 PM, Alexander Sack wrote:
On Mon, May 7, 2012 at 11:40 PM, Mathieu Poirier mathieu.poirier@linaro.org wrote:
Good day y'all,
Many of you have received a gerrit review request that concerns Gator and a kernel API change that happened between 3.3 and 3.4. If you maintain a build associated to a board, please review.
The problem happens when compiling an android build with a 3.4 kernel. The Gator driver is looking for the 'd_alloc_root' function when compiling 'gator_fs.c', something that is provided by the kernel.
But commit [1] has replaced the function with 'd_make_root' during the 3.4 merge cycle. Zach suggested to point the last SHA of the old API to avoid spinning off yet another branch, something that was implemented as part of [2].
If you are the last one to review and have merge rights, please push the changes.
I assume it's the driver/ part of ds5 causing troubles here? Any way to make the source support both kernel ABIs using an #ifdef or something? In this way we could continue tracking the latest and would be able to spin 3.3 and 3.4 based LEBs off the same thing.
Correct, it's the driver part of ds5.
Using and #ifdef would mean that all builds would have to declare a new define somewhere, which, in my opinion is not as clean as what Zach and I are proposing.
I thought the info which kernel ABI one builds against could be taken from the kernel headers used at build time ...
If that's not the case, then it feels that either ds5 really must find a way to just use stable API (if that exists) or move in-kernel...
Hi,
On 7 May 2012 23:40, Mathieu Poirier mathieu.poirier@linaro.org wrote:
Good day y'all,
Many of you have received a gerrit review request that concerns Gator and a kernel API change that happened between 3.3 and 3.4. If you maintain a build associated to a board, please review.
Looks good to me, but I wonder if just fixing the code to handle both cases wouldn't be smarter...
#include <linux/version.h> #if LINUX_VERSION_CODE < KERNEL_VERSION(3,4,0) d_alloc_root #else d_make_root #endif
ttyl bero
On Tue, May 8, 2012 at 12:05 AM, Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org wrote:
Hi,
On 7 May 2012 23:40, Mathieu Poirier mathieu.poirier@linaro.org wrote:
Good day y'all,
Many of you have received a gerrit review request that concerns Gator and a kernel API change that happened between 3.3 and 3.4. If you maintain a build associated to a board, please review.
Looks good to me, but I wonder if just fixing the code to handle both cases wouldn't be smarter...
#include <linux/version.h> #if LINUX_VERSION_CODE < KERNEL_VERSION(3,4,0) d_alloc_root #else d_make_root #endif
+1 ... Jon/Ryan: can we take this and maybe even feed it back to ARM?
On 12-05-07 04:05 PM, Bernhard Rosenkränzer wrote:
Hi,
On 7 May 2012 23:40, Mathieu Poirier mathieu.poirier@linaro.org wrote:
Good day y'all,
Many of you have received a gerrit review request that concerns Gator and a kernel API change that happened between 3.3 and 3.4. If you maintain a build associated to a board, please review.
Looks good to me, but I wonder if just fixing the code to handle both cases wouldn't be smarter...
#include <linux/version.h> #if LINUX_VERSION_CODE < KERNEL_VERSION(3,4,0) d_alloc_root #else d_make_root #endif
ttyl bero
This is a much, much better solution. I will revert the merge and implement your way.
On Mon, 2012-05-07 at 16:30 -0600, Mathieu Poirier wrote:
On 12-05-07 04:05 PM, Bernhard Rosenkränzer wrote:
Hi,
On 7 May 2012 23:40, Mathieu Poirier mathieu.poirier@linaro.org wrote:
Good day y'all,
Many of you have received a gerrit review request that concerns Gator and a kernel API change that happened between 3.3 and 3.4. If you maintain a build associated to a board, please review.
Looks good to me, but I wonder if just fixing the code to handle both cases wouldn't be smarter...
#include <linux/version.h> #if LINUX_VERSION_CODE < KERNEL_VERSION(3,4,0) d_alloc_root #else d_make_root #endif
ttyl bero
This is a much, much better solution. I will revert the merge and implement your way.
Yes, that is the better way, however the API wasn't simply renamed in 3.4, the semantics are different so it needs another change to keep the inode reference count correct in case of error. I have applied a fix in this change... http://git.linaro.org/gitweb?p=arm/ds5/gator.git%3Ba=commit%3Bh=097d741a276a...
I had fixed the 3.4 compilation issue in the Gator topic branch, but forgot that some Android kernels don't yet include this, sorry about that.
Yesterday was a public holiday in the UK which is why I haven't responded sooner.
On 12-05-07 04:05 PM, Bernhard Rosenkränzer wrote:
Hi,
On 7 May 2012 23:40, Mathieu Poirier mathieu.poirier@linaro.org wrote:
Good day y'all,
Many of you have received a gerrit review request that concerns Gator and a kernel API change that happened between 3.3 and 3.4. If you maintain a build associated to a board, please review.
Looks good to me, but I wonder if just fixing the code to handle both cases wouldn't be smarter...
#include <linux/version.h> #if LINUX_VERSION_CODE < KERNEL_VERSION(3,4,0) d_alloc_root #else d_make_root #endif
ttyl bero
Done:http://git.linaro.org/gitweb?p=arm/ds5/gator.git%3Ba=shortlog%3Bh=refs/heads...
linaro-android@lists.linaro.org
-
Alexander Sack -
Bernhard Rosenkränzer -
Jon Medhurst (Tixy) -
Mathieu Poirier