Re: linux-omap-psp-2.6.32 breaks iscsi-target

[Graeme Gregory <dp@xora.org.uk>]

 On 31/08/10 10:17, Frans Meulenbroeks wrote:
> 2010/8/31 Koen Kooi <k.kooi@student.utwente.nl>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 30-08-10 19:47, Frans Meulenbroeks wrote:
>>> The current beagleboard angstrom and minimal distro's (and maybe
>>> others) use the linux-omap-psp_2.6.32.bb recipe to build the kernel.
>>>
>>> This one says:
>>> # This is the v2.6.32_OMAPPSP_03.00.01.06 branch
>>> SRCREV = "a6bad4464f985fdd3bed72e1b82dcbfc004d7869"
>>>
>>> # The main PR is now using MACHINE_KERNEL_PR, for omap3 see
>>> conf/machine/include/omap3.inc
>>> MACHINE_KERNEL_PR_append = "+gitr${SRCREV}"
>>>
>>> SRC_URI = "git://arago-project.org/git/people/sriram/ti-psp-omap.git;protocol=git;branch=master
>>> \
>>>
>>> Building it creates:
>>> linux-omap-psp-2.6.32-r88+gitra6bad4464f985fdd3bed72e1b82dcbfc004d7869
>>>
>>> However this is not a sound 2.6.32 tree. It contains this patch
>>> http://arago-project.org/git/people/?p=sriram/ti-psp-omap.git;a=commit;h=c720c7e8383aff1cb219bddf474ed89d850336e3
>>> which was not in the mainstream kernel in 2.6.32
>> What a surprise, a vendor kernel has patches that aren't in mainline linux.
> Well the surprise is not that a vendor kernel has patches that are not
> mainlined. Actually I expect vendor specific patches in such a kernel.
> The surprise is that this kernel advertises itself as 2.6.32, yet has
> 2.6.33 patches integrated that are non-vendor related at all.
>
> And surprise or no surprise, what happened is that I encountered a
> problem in a recipe I maintain in conjunction with a platform that
> used to support this.
> (actually both the iscsi-target package and the tgt package appear on
> the angstrom feed for armv7a)
>
> I've analysed the problem, figured that there is no good way to
> resolve this in the package and that the root cause is a kernel that
> advertises itself as 2.6.32 but is not compliant with it.
> Therefore I report the problem. I actually offered to work on a patch.
>
> However, instead of appreciating the fact that someone reports an
> incompatibility so that it is known, some people seem to prefer to
> shoot the messenger. :-(
> Great piece of teamwork!
>
>>> (compare
>>> http://arago-project.org/git/people/?p=sriram/ti-psp-omap.git;a=blob;f=include/net/inet_sock.h;hb=c720c7e8383aff1cb219bddf474ed89d850336e3
>>> with
>>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=blob;f=include/net/inet_sock.h;h=47004f35cc7eaf6f2b3cac2779ea7b7ccd5d9c1f;hb=HEAD
>>> ).
>>>
>>> The patch mentioned above was integrated in a 2.6.33 rc version.
>>>
>>> iscsi-utils uses the inet_sock struct, and contains code to access the
>>> daddr field of this struct. For versions <= .32 daddr is used. for
>>> higher versions inet_daddr is used.
>>> However the omap-psp kernel from arago does contain this patch  but
>>> reports as a .32 kernel causing a compiler errir when compiling
>>> iscsi_target (as the name the recipe expects is not there).
>>>
>>> Not sure how to fix it. Changing the test in iscsi-target is not an
>>> option as then it does not work for official .32 kernels.
>>> Probably the best way to fix this is to use the above patch to revert
>>> the change.
>>>
>>> anyone a better solution?
>> I can tell you right now that patching the psp kernel will not be
>> accepted, so patching the iscsi recipe is the way to go.
> iscsi-target cannot fix this in a reasonable way. If I saw a decent
> fix (which does not break things for other .32 kernels), I would have
> done it.
> A patch for the psp kernel would be very simple. We're only talking
> about a patch (which could be in oe, not in arago) to give the struct
> fields the name that they should have according to 2.6.32).
> Functionally this is a zero-impact patch.
>
> Then again, the flexibility, open-minded-ness and customer
> friendliness of some of our developers is already known to me, so I
> kind-a expected this reaction (which is also why I posted this before
> spending time to develop a patch).
>
> Anyway, I already lost interest in resolving this. I can make it work
> locally for me, no problem with that, and I'll add DP of -1 for
> beagleboard to the iscsi-target recipe with an explanatory note.
>
There is no such thing as a stable kernel anymore, all 2.6.XX releases
are classed as unstable, it is upto vendors to stabalise and select API/ABI.

Graeme