Ben Dooks to Linus Torvalds email about Arm vs Linux:

> - x86 has its drivers elsewhere, and they are _discoverable_ and not 
>   hardcoded to some platform. They have often also been useful (to say 
>   the least) to other architecture platforms. That's not always truefor
>   all of them (we do have drivers/platform/x86, but at least that's 
>   maintained separately and is nowhere near the mess that is ARM)

There are some common drivers for ARM specific hardware under
arch/arm/common but there’s not a lot of that. I have been trying to
ensure that new support re-uses common driver code. I was one of
the people who worked with Piere to break the SDHCI reliance on PCI
so that it could be re-used on platform device based systems such as
the new Samsung SoC. I have also been trying to ensure that new
support is carefully considered.

Unfortunately we often run into the following problems between ARM vs Linux;

– The “Our hacked driver has been customer-tested and patched so often
that it must be the one that gets submitted” argument… trying to get
them to realised that firstly, it isn’t of the necessary quality or
has been already done elsewhere is very difficult.

– Often the hardware teams don’t tell you where the blocks that have
been included come from some common source. This makes the task of
identifying a common driver difficult (they just make their own
driver from the ‘documentation’ that the hardware guys hack).

I’ve been subject to this on at-least one occasion and currently
considering renaming the s3c-hsotg driver to dw-hsotg (it turns
out to be a block that was bought in from Synopsys’ DesignWare)

– There is also a problem that as soon as the hardware that has even
a small divergence from the common case that they need a special
driver for it (against, see the SDHCI case where there’s a couple
of extra configuration register to control clocks, etc.)

When Harald Welte and I looked into some of these development
practices we started to try and educate the developers about this. As
an example we looked the clock structure we used to modle the clock
trees in the SoCs, and found that in certain of their branches there
where 4 copies of the same code, each with its own subtle bugs…

I have been trying very hard to make sure that these things are kept
under control, but unfortunately it can be a hard task and until it
hits these big companies in the pocket it very difficult to get them
to actually pay for this.

As for the churn under arch/arm, then there are a few reasons for this
and the size of the code involved.

– Firstly the implemetations of the ARM architecture can vary wildly
depending on the implementor (and there can be several different
implementing teams within one company). There is very little direct
recommendation or specification from ARM on how the system around
the core is layed out.

This means that there are a variety of different interupt controlers
involved, and even when a standard one is used (ARM VIC) then the
interrupt routing and base addresses of the control registers change
between SoCs.

There is also a huge variety of memory layouts, the base of SDRAM
and peripheral layout can change between individual SoCs, let alone
families of them.

– Secondly there has been an rush to get as many header files in
defining as many registers as possible for all the hardware, even
if it turns out later to be a common block or not used.

I have been trying to remove as many #defines in headers where the
result is only used once in the code to try and help the spiraling
size of the project.

– Thirdly the core of these devices is also widly different, there is
often far more complexity in how the SoC’s bus and clock layouts are
put together.

It is not like PCI where each device has a xMHZ clock and integrated
PLL if needed. There are complex heirarchies of PLLs and clocks,
which then need to be exported to the drivers to use, and often the
clock gating is also integrated into the centralised clock control
units instead of in the device.

Also, since there is often very little support for any dynamic bus
discovery, a lot of the device information is dependant on knowing
which SoC you are running on (unlike PCI where there’s a specific
configuration header).

Note, there are moves to try and get device trees supported on ARM
to try and solve the previous paragraph, but we have an awfully big
history to sort out, and it only really pushes that part of the
problem out of the kernel onto the device manfactueres (who can
barely get a bootloader to pass in a couple of registers).

So apart from that, another source for the churn is that when we
do identify common parts, thigns need to get move and older systems
updated to use them. These devices seem to evolve at such a rate it
is difficult to predict what we’ll see 6 months down the line.

The next problem is that if we don’t get some support in each merge
window, then the size of the task for the next one keeps growing and
growing. It is already a problem just for the Samsung range of SoCs
where we only really have core functionality for most of the SoCs;
There are still drivers needed for some of the Security, Multimedia
and connectivity subsystems to be sorted out.

I have been trying my best to keep control of these issues, but it is
very difficult and it isn’t my daytime job 🙁

Kaynak: http://lwn.net/Articles/392160/

Everything related between Daniel Walker, Linus Torvalds, Russell King, Ryan Mallon about arm vs. linux:

The kernel tree for the ARM architecture is large and fairly complicated. Because of the large number of ARM system-on-chip (SoC) variants, as well as different versions of the ARM CPU itself, there is something of a combinatorial explosion occurring in the architecture tree. That, in turn, led to something of an explosion from Linus Torvalds as he is getting tired of “pointless churn” in the tree.

A request from Daniel Walker for some updates to arch/arm/mach-msm was the proximate cause of Torvalds’s unhappiness, but it goes deeper than that. He responded to Walker’s request, by pointing out a problem he sees with ARM:

	arch/arm/configs/
	arch/arm/mach-xyz
	arch/arm/plat-blah

He goes on to note that the majority of the diffs are “mind-deadening” because they aren’t sensibly readable by humans. He further analyzes the problem by comparing the sizes of the x86 and ARM trees, with the latter being some 800K lines of “code”—roughly three times the size of x86. Of that, 200K lines are default config (i.e. defconfig) files for 170+ different SoCs. To Torvalds, those files are “pure garbage”.

In fact, he is “actually considering just getting rid of all the ‘defconfig’ files entirely”. Each of those files represents the configuration choices someone made when building a kernel for a specific ARM SoC, but keeping them around is just a waste, he said:

Another problem that Torvalds identified is the proliferation of platform-specific drivers, which could very likely be combined into shared drivers in the drivers/ tree or coalesced in other ways. Basically, “we need somebody who cares, and doesn’t just mindlessly aggregate all the crud”. Ben Dooks agreed that there is a problem, but that “many of the big company players have yet to really see the necessity” of combining drivers. He also noted that at least some of the defconfig files were being used in automated build testing, but did agree that

Ben Dooks to Linus Torvalds email about arm vs. linux:

> - x86 has its drivers elsewhere, and they are _discoverable_ and not 
>   hardcoded to some platform. They have often also been useful (to say 
>   the least) to other architecture platforms. That's not always truefor
>   all of them (we do have drivers/platform/x86, but at least that's 
>   maintained separately and is nowhere near the mess that is ARM)

There are some common drivers for ARM specific hardware under
arch/arm/common but there’s not a lot of that. I have been trying to
ensure that new support re-uses common driver code. I was one of
the people who worked with Piere to break the SDHCI reliance on PCI
so that it could be re-used on platform device based systems such as
the new Samsung SoC. I have also been trying to ensure that new
support is carefully considered.

Unfortunately we often run into the following problems;

– The “Our hacked driver has been customer-tested and patched so often
that it must be the one that gets submitted” argument… trying to get
them to realised that firstly, it isn’t of the necessary quality or
has been already done elsewhere is very difficult.

– Often the hardware teams don’t tell you where the blocks that have
been included come from some common source. This makes the task of
identifying a common driver difficult (they just make their own
driver from the ‘documentation’ that the hardware guys hack).

I’ve been subject to this on at-least one occasion and currently
considering renaming the s3c-hsotg driver to dw-hsotg (it turns
out to be a block that was bought in from Synopsys’ DesignWare)

– There is also a problem that as soon as the hardware that has even
a small divergence from the common case that they need a special
driver for it (against, see the SDHCI case where there’s a couple
of extra configuration register to control clocks, etc.)

When Harald Welte and I looked into some of these development
practices we started to try and educate the developers about this. As
an example we looked the clock structure we used to modle the clock
trees in the SoCs, and found that in certain of their branches there
where 4 copies of the same code, each with its own subtle bugs…

I have been trying very hard to make sure that these things are kept
under control, but unfortunately it can be a hard task and until it
hits these big companies in the pocket it very difficult to get them
to actually pay for this.

As for the churn under arch/arm, then there are a few reasons for this
and the size of the code involved.

– Firstly the implemetations of the ARM architecture can vary wildly
depending on the implementor (and there can be several different
implementing teams within one company). There is very little direct
recommendation or specification from ARM on how the system around
the core is layed out.

This means that there are a variety of different interupt controlers
involved, and even when a standard one is used (ARM VIC) then the
interrupt routing and base addresses of the control registers change
between SoCs.

There is also a huge variety of memory layouts, the base of SDRAM
and peripheral layout can change between individual SoCs, let alone
families of them.

– Secondly there has been an rush to get as many header files in
defining as many registers as possible for all the hardware, even
if it turns out later to be a common block or not used.

I have been trying to remove as many #defines in headers where the
result is only used once in the code to try and help the spiraling
size of the project.

– Thirdly the core of these devices is also widly different, there is
often far more complexity in how the SoC’s bus and clock layouts are
put together.

It is not like PCI where each device has a xMHZ clock and integrated
PLL if needed. There are complex heirarchies of PLLs and clocks,
which then need to be exported to the drivers to use, and often the
clock gating is also integrated into the centralised clock control
units instead of in the device.

Also, since there is often very little support for any dynamic bus
discovery, a lot of the device information is dependant on knowing
which SoC you are running on (unlike PCI where there’s a specific
configuration header).

Note, there are moves to try and get device trees supported on ARM
to try and solve the previous paragraph, but we have an awfully big
history to sort out, and it only really pushes that part of the
problem out of the kernel onto the device manfactueres (who can
barely get a bootloader to pass in a couple of registers).

So apart from that, another source for the churn is that when we
do identify common parts, thigns need to get move and older systems
updated to use them. These devices seem to evolve at such a rate it
is difficult to predict what we’ll see 6 months down the line.

The next problem is that if we don’t get some support in each merge
window, then the size of the task for the next one keeps growing and
growing. It is already a problem just for the Samsung range of SoCs
where we only really have core functionality for most of the SoCs;
There are still drivers needed for some of the Security, Multimedia
and connectivity subsystems to be sorted out.

I have been trying my best to keep control of these issues, but it is
very difficult and it isn’t my daytime job 🙁

Kaynak: http://lwn.net/Articles/392160/

Everything related between Daniel Walker, Linus Torvalds, Russell King, Ryan Mallon about arm vs. linux:

The kernel tree for the ARM architecture is large and fairly complicated. Because of the large number of ARM system-on-chip (SoC) variants, as well as different versions of the ARM CPU itself, there is something of a combinatorial explosion occurring in the architecture tree. That, in turn, led to something of an explosion from Linus Torvalds as he is getting tired of “pointless churn” in the tree.

A request from Daniel Walker for some updates to arch/arm/mach-msm was the proximate cause of Torvalds’s unhappiness, but it goes deeper than that. He responded to Walker’s request, by pointing out a problem he sees with ARM:

	arch/arm/configs/
	arch/arm/mach-xyz
	arch/arm/plat-blah

He goes on to note that the majority of the diffs are “mind-deadening” because they aren’t sensibly readable by humans. He further analyzes the problem by comparing the sizes of the x86 and ARM trees, with the latter being some 800K lines of “code”—roughly three times the size of x86. Of that, 200K lines are default config (i.e. defconfig) files for 170+ different SoCs. To Torvalds, those files are “pure garbage”.

In fact, he is “actually considering just getting rid of all the ‘defconfig’ files entirely”. Each of those files represents the configuration choices someone made when building a kernel for a specific ARM SoC, but keeping them around is just a waste, he said:

Another problem that Torvalds identified is the proliferation of platform-specific drivers, which could very likely be combined into shared drivers in the drivers/ tree or coalesced in other ways. Basically, “we need somebody who cares, and doesn’t just mindlessly aggregate all the crud”. Ben Dooks agreed that there is a problem, but that “many of the big company players have yet to really see the necessity” of combining drivers. He also noted that at least some of the defconfig files were being used in automated build testing, but did agree that there are older defconfigs that should be culled.

Dooks also had a longer description of the problems that ARM maintainers have in trying to support so many different SoCs, while also trying to reduce the size and complexity of the sub-architecture trees. Essentially, the maintainers are swamped and “until it hits these big companies in the pocket it [is] very difficult to get them to actually pay” for cleaning up the ARM tree and keeping it clean in the future.

Because Torvalds said that he was planning to remove the ARM (and other) defconfig files, ARM maintainer Russell King posted a warning to the linux-arm-kernel mailing list:

That set off a separate discussion on that mailing list—King’s and others’ attempts to mobilde-64-bit-deneyimiredirect it back to linux-kernel notwithstanding—about ways to reduce the amount of mostly redundant information carried around in the defconfig files. Ryan Mallon is in favor of proactively eliminating some defconfigs, while others discussed various ways to only keep the deltas between the config files for various SoCs.

Based on Torvalds’s comments on linux-kernel, some kind of delta scheme is unlikely to fly. His main complaint is that the defconfig files are neither readable nor writable by humans, as they are generated by various tools. He made some specific suggestions of alternatives that would still allow the generation of those config files, using Kconfig files that are usable by humans.

Reducing the number of defconfigs, as Mallon suggested, may be helpful, but King at least is convinced that it doesn’t go far enough. Hebelieves that Torvalds has already made up his mind to remove the defconfigs in the next merge window and that the ARM community better be ready with something else:

The discussion ranged from possible solutions to the immediate defconfig problem to the larger issue of reducing the duplication throughout the ARM trees. There is an effort underway to produce a single kernel that would support multiple ARM platforms for Ubuntu 10.10, which will likely help consolidate various sub-architectures. Given that Canonical is working closely with the newly formed Linaro organization—founded to simplify ARM Linux—there is reason to believe that things will get better.

Meanwhile, though, back on linux-kernel, Torvalds started a new thread to flesh out his ideas for a hierarchical collection of Kconfig files that would essentially take the place of the defconfigs. After some back and forth, Torvalds gave an example of exactly what he is suggesting:

	config MYCONFIG
		bool
		default y
		select USB

	source arch/x86/Kconfig

	KBUILD_KCONFIG=Mykconfig make allnoconfig

He goes on to describe a theoretical Kconfig.omap3_evm file that sets the specific requirements for that platform and then includesKconfig.omap3. That file sets up whatever is required for the OMAP3 platform and includes Kconfig.arm. That would allow developers or tools like kautobuild to generate the necessary config files without having to carry them around in the kernel tree. Those Kconfig files would also be much more readable and any diffs would be understandable, which is important to Torvalds.

That solves a significant subset of the problem, but there is still a fly in the ointment: dependencies. In Torvalds’s example, CONFIG_USB requiresCONFIG_USB_SUPPORT, so that would need to be added to Mykconfig. Not accounting for dependencies will get you a kernel that doesn’t build or, worse yet, won’t run correctly. There are a number of possible solutions to the dependency problem, though, ranging from Catalin Marinas’spatch to track unmet dependencies of options used in select statements to Vegard Nossum’s summer of code project to add a satisfiability solver into the configuration editors (menuconfig, etc.).

It certainly seems likely that defconfig files will be removed from the kernel tree in the 2.6.36 merge window. Whether there is another solution—based on Torvalds’s ideas or something else—to replace them is really up to the architecture teams as Torvalds is perfectly happy to move on without them. ARM, PowerPC, MIPS, and others all have lots of defconfig files, but unless he changes his mind, they won’t in a few short months. They can keep maintaining those files in a separate repository somewhere, or find an acceptable method to generate them. While it may be painful in the short term, it will reduce the size of the kernel tree and make Torvalds’s job easier, both of which are worth striving for.

Source: http://lwn.net/Articles/391372/

there are older defconfigs that should be culled.

Dooks also had a longer description of the problems that ARM maintainers have in trying to support so many different SoCs, while also trying to reduce the size and complexity of the sub-architecture trees. Essentially, the maintainers are swamped and “until it hits these big companies in the pocket it [is] very difficult to get them to actually pay” for cleaning up the ARM tree and keeping it clean in the future.

Because Torvalds said that he was planning to remove the ARM (and other) defconfig files, ARM maintainer Russell King posted a warning to the linux-arm-kernel mailing list:

That set off a separate discussion on that mailing list—King’s and others’ attempts to mobilde-64-bit-deneyimiredirect it back to linux-kernel notwithstanding—about ways to reduce the amount of mostly redundant information carried around in the defconfig files. Ryan Mallon is in favor of proactively eliminating some defconfigs, while others discussed various ways to only keep the deltas between the config files for various SoCs.

Based on Torvalds’s comments on linux-kernel, some kind of delta scheme is unlikely to fly. His main complaint is that the defconfig files are neither readable nor writable by humans, as they are generated by various tools. He made some specific suggestions of alternatives that would still allow the generation of those config files, using Kconfig files that are usable by humans.

Reducing the number of defconfigs, as Mallon suggested, may be helpful, but King at least is convinced that it doesn’t go far enough. Hebelieves that Torvalds has already made up his mind to remove the defconfigs in the next merge window and that the ARM community better be ready with something else:

The discussion ranged from possible solutions to the immediate defconfig problem to the larger issue of reducing the duplication throughout the ARM trees. There is an effort underway to produce a single kernel that would support multiple ARM platforms for Ubuntu 10.10, which will likely help consolidate various sub-architectures. Given that Canonical is working closely with the newly formed Linaro organization—founded to simplify ARM Linux—there is reason to believe that things will get better.

Meanwhile, though, back on linux-kernel, Torvalds started a new thread to flesh out his ideas for a hierarchical collection of Kconfig files that would essentially take the place of the defconfigs. After some back and forth, Torvalds gave an example of exactly what he is suggesting:

	config MYCONFIG
		bool
		default y
		select USB

	source arch/x86/Kconfig

	KBUILD_KCONFIG=Mykconfig make allnoconfig

He goes on to describe a theoretical Kconfig.omap3_evm file that sets the specific requirements for that platform and then includesKconfig.omap3. That file sets up whatever is required for the OMAP3 platform and includes Kconfig.arm. That would allow developers or tools like kautobuild to generate the necessary config files without having to carry them around in the kernel tree. Those Kconfig files would also be much more readable and any diffs would be understandable, which is important to Torvalds.

That solves a significant subset of the problem, but there is still a fly in the ointment: dependencies. In Torvalds’s example, CONFIG_USB requiresCONFIG_USB_SUPPORT, so that would need to be added to Mykconfig. Not accounting for dependencies will get you a kernel that doesn’t build or, worse yet, won’t run correctly. There are a number of possible solutions to the dependency problem, though, ranging from Catalin Marinas’spatch to track unmet dependencies of options used in select statements to Vegard Nossum’s summer of code project to add a satisfiability solver into the configuration editors (menuconfig, etc.).

It certainly seems likely that defconfig files will be removed from the kernel tree in the 2.6.36 merge window. Whether there is another solution—based on Torvalds’s ideas or something else—to replace them is really up to the architecture teams as Torvalds is perfectly happy to move on without them. ARM, PowerPC, MIPS, and others all have lots of defconfig files, but unless he changes his mind, they won’t in a few short months. They can keep maintaining those files in a separate repository somewhere, or find an acceptable method to generate them. While it may be painful in the short term, it will reduce the size of the kernel tree and make Torvalds’s job easier, both of which are worth striving for.

Source: http://lwn.net/Articles/391372/