4

I am in my learning the landscape of Linux kernel for ARM-based SoCs development.
This is the very early stage of learning and will surely take a long time as the matters seem to be comprehensive.
The goal is to have sufficient orientation in the eco-system so as soon as concrete issues in own project are to be solved one is able to route the search/investigation in the proper trails.

There is the Linus's tree, vanilla kernel. As for ARM platform there is also the ARM port tee/project/repository. If however to have a look at MAINTAINER file there are several maintainers/sub-systems of, apparently, ARM specific narrow-spectrum topics.
I wonder why all those narrow-spectrum topics do not deliver/contribute to the ARM port (http://www.arm.linux.org.uk/) repository instead of delivering directly to Torvalds tree? There seems to exist also ARM SUB-ARCHITECTURES sub-system. Several those narrow-spectrum sub-systems/maintainers seem to be intended for porting to certain platform, conclusion based on naming the found sub-system/maintainer. Why are these centralized at / contribute to Linus tree directly instead of doing it to ARM SUB-ARCHITECTURES sub-system or as mentioned above?

The organization is somehow mysterious, in-transparent for a newbie.

artless noise
  • 21,212
  • 6
  • 68
  • 105
  • In my subjective impression it lacks on common awareness of existing structure, maybe due to lack of sufficient communication. Or one other option there are concrete reasons why folks prefer to contribute directly to Linus tree. I think the multi-stage structure is good for better flow control. –  Dec 11 '15 at 16:44
  • I believe the specifically vast range of ARM family not necessarily determines how much levels are to used to upstream to Linus tree. Both should qualify quite well to get isolated in some extend. The intermediate stage like ARM port tree had surely advantages. –  Dec 11 '15 at 16:55
  • 1
    @dwelch "Linus's rant" was about a lot of code for different ARM SOC boards. These have been rectified with device tree and other structures. For instance the freescale 'iMx' family use to have 20-50 machine files and lots of code. It is now far less and all the 'iMx' boards/cpus will use a common driver with conditions/function pointers; not multiple files and/or conditional compilation. Typical mainline is a 'CPU demo board' (like RPI, etc) and maybe very popular products (NAS, router, etc). It is correct that no other architecture is as successful at being so diversified. – artless noise Dec 12 '15 at 21:04
  • The problem is I did not find other community/discussion platform suitable for asking the answer as this. LKML is not suitable as in 99% the hard core kernel development is discussed there, and for myself unclear if whole kernel devel. ARM family is covered there. Git understanding is not everything, there is additionally the big question of project collaboration which in case of AMR surely applies too. My very beginning was just to get Git understanding, it was not sufficient enough as local and private repository shows lot of stuff which for some unclear reason is included there... –  Dec 14 '15 at 09:43
  • Say you want to update an existing USB driver for a NEW Broadcom chip that is similar to an old one. You need to edit the *driver/usb*, a *device tree* and some broadcom board/platform callback in *arch/arm*. It means you need to generate a patchset (mail files) and then send them to each of the USB, devicetree and ARM lists. The discussion proceeds with all involved groups (if you are lucky or patient). You take review comments and incorporate them and maybe requested to 'rebase' against a Linux target and repost. Each sub-tree takes your changes and they get pulled as a squash by Linus. – artless noise Dec 14 '15 at 14:38
  • Thanks for your comments. These are interesting but not necessarily the answer to asked question. Rather low-level proceedings instructions. Few days ago I could see which are removed now, don't remember the editor. Those went towards the question answer quite well. –  Dec 14 '15 at 16:01
  • The ARM sub-systems are their own git tree/organization for co-ordinating changes. They will be pulled to the ARM 'for-next' or if they are trusted enough, they go right to the mainline. The ARM tree is about the ARM cpu (MMU/context switch/ARM TRM, ARM64, etc). The other trees are more about SOC issues; a broadcom/freescale, etc chip. They seem to be 'sub-systems', but actually they are different things. A typical code task will involve many of the sub-systems. The USB example will involve 'broad-com', pinctrl, clock, as well as ones I mentioned. – artless noise Dec 14 '15 at 16:10
  • As formulated in initial post I wonder why can't the ARM port tree not be the hub for ARM soc trees rather than latter ones to contribute direct to Linus tree. –  Dec 14 '15 at 16:20
  • Many trees not in the mainline are 'throw away' branches. They rebase changes on the 'mainline'; that is the process. So you can not look at a sub-tree git history and know what went on. They delete or rebase, etc and pulling from sub-system trees doesn't always work as they try to make things match what is in the mainline; Ergo, I don't know where you get your information about 'contribute to Linus tree directly'? It may seem like that when it is not actually true. – artless noise Dec 14 '15 at 16:20
  • The people who maintain the ARM soc tree have different interests/knowledge than the ARM tree. What would putting the changes through the ARM tree improve? Sometimes the ARM tree will pull SOC changes if they depend on each other and they will get merged together. Really it depends on the issue. – artless noise Dec 14 '15 at 16:21
  • Because I see all these as sub-systems and/or maintainers within Linus tree, MAINTAINERS file. From this me concludes they contribute to Linus tree, not to the ARM port. For an outsider, why the ARM port sub-system tree not to be the hub for ARM SoC's trees. –  Dec 14 '15 at 16:24
  • Because git doesn't have to work like that. It can take changes from anywhere. The maintainers do what ever is best to get the job done with minimum effort on their part. If a change is logically discrete to the SOC, then it can go directly to the mainline. The end goal is to get to the mainline; every one will start from that on the next version. If a change has both an SOC and ARM dependency, then it may go the route as you describe. The SOC branch might be 'for-russell' or something like that when it goes the route you describe. – artless noise Dec 14 '15 at 16:27
  • I mean mainly collaborating from sub-trees to mainline tree. Forking/forking-forking from Linus tree less in focus, however also interesting point. It is bad if tools are determining the organization of the work and the processes. It is very good approach to unitize the kernel source and thus the development organization. Yet better multi-level modularization. The lower number of sub-system at particular level the easier to control this level of contribution. –  Dec 14 '15 at 16:39
  • 1
    http://www.elinux.org/images/a/ad/Arm-soc-checklist.pdf –  Jan 07 '16 at 10:43

0 Answers0