Re: ARM promising platform, needs to learn from PC.

[Luke Kenneth Casson Leighton]

in http://thread.gmane.org/gmane.linux.kernel/1114495/focus=112007,
with subject "[GIT PULL] omap changes for v2.6.39 merge window" in
which the topic discussed has nothing to do with the subject (so glad
to see i'm not the only one who does that...), Thomas Gleixner said:

> I'm sure that device tree is part of the solution, but that only helps
> if we find a way to prevent duplicate drivers in the first place.

well if you apply the proposed "selfish patches are automatically
rejected in favour of collaboration patches" rule, there won't *be*
any duplicate drivers, only shared (i.e. collaborative) ones.

problem's solved, yes?

in the case of peripheral "cores" (e.g. a USB-3 Hardware Macro Block
which multiple SoC vendors license from e.g. Synopsys and lay down as
part of the CPU) i bet you that enough "Hell On Earth" for SoC vendors
whose kernel patches get rejected (because they're classified as
"selfish") would ultimately result in the actual designers of those
"cores" (e.g. Synopsys) writing the actual linux driver code
themselves.

under such circumstances, if the actual designer of the Hardware Macro
Block actually wrote the bloody linux driver, it would a) fit the
"collaborative patches rule", b) save the SoC vendors a job
reimplementing driver code c) stop the SoC vendors from submitting
duplicate drivers.

it might happen.  pigs might fly, but it might happen.

l.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/