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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPweEDwQH-pM120CQhaNy3+aQO8pUiTzFuEaPx5kbJPF6yyDLA@mail.gmail.com>
Date:	Thu, 18 Aug 2011 22:33:10 +0100
From:	Luke Kenneth Casson Leighton <luke.leighton@...il.com>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: ARM promising platform, needs to learn from PC.

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/