linux-kernel - Re: Use of drivers/platform and matching include?

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20131004111820.GD25137@arm.com>
Date:	Fri, 4 Oct 2013 12:18:21 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Olof Johansson <olof@...om.net>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	Feng Kan <fkan@....com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Kumar Gala <galak@...eaurora.org>
Subject: Re: Use of drivers/platform and matching include?

On Thu, Oct 03, 2013 at 06:54:07PM +0100, Olof Johansson wrote:
> On Thu, Oct 3, 2013 at 10:09 AM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote:
> >> I don't have a good answer though. If it wasn't for the arm64 fork,
> >> locating these under arch/arm somewhere would really be the reasonable
> >> answer, like we used to do on powerpc. :(
> >
> > Sounds like yet-another-good reason why there shouldn't be an arm64
> > "fork" at all :(
> 
> Doing a fork gives a chance at a clean slate refresh of platform
> support, which is in itself quite useful. But indeed it causes some
> things to be more complicated.

Also note that arm64 work started (internally) before the arm-soc was
formed and it was nearing upstreaming at a time when the arm-soc was
still undergoing heavy clean-up.

Of course, there is always a balance between advantages and
disadvantages but the main benefits are a clean implementation of
AArch64 architecture support (without legacy baggage) and forcing SoC
people to clean up the code for AArch64 (e.g. default single Image,
decoupling booting protocols from SoC initialisation, firmware interface
standardisation, resisting the urge to add SoC code under arch/arm64/).

> It's a common complaint that "everybody who ever forked for 64-bit
> have later merged", and that's true, but that doesn't mean there's no
> value in forking (and perhaps later merging), instead of adding on top
> to start with.

Exactly. Later merging is possible, but such process, to produce
clean/maintainable/shareable code, needs additional clean-up in the
32-bit ARM architecture code (at least breaking recent ARMv7 support
from legacy architectures). Otherwise we end up with either a less than
clean arm64 re-port on top of arm or just completely separate files
artificially forced under the same arch directory.

Where code sharing makes sense (e.g. ARM KVM and Xen), the arm64
Makefiles already reference arch/arm/. It's not ideal but it's a
trade-off for the time being.

> > The arm community created this mess, you all can fix it up, it's not too
> > late.
> 
> It wouldn't be a huge deal to add something like arch/arm/syslib and
> give some of the system library-type code a home there -- stuff like
> resource allocation libraries, etc. I don't think we want to collect
> all the back-end drivers in there though, just libraries.

On the SoC part, we need to analyse what exactly needs sharing, whether
it's a library used by multiple drivers (and arguably the library could
also go under drivers/) or whether it's some SoC initialisation that
could be better done before Linux is started.

-- 
Catalin
--
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/