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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAOesGMhBaj14++kJ9tVko68MjC7D+JZrBRgoxa4zmZ9z186MQw@mail.gmail.com>
Date:	Thu, 3 Oct 2013 10:54:07 -0700
From:	Olof Johansson <olof@...om.net>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Kumar Gala <galak@...eaurora.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>, Feng Kan <fkan@....com>
Subject: Re: Use of drivers/platform and matching include?

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.

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.

> 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.

I think many of us are hesitant to introduce something that runs the
risk of becoming a dumping ground for all these "I don't know where to
put them, so here you go" drivers, since we've spent so much time
cleaning them all up and de-forking per-vendor implementations of
similar things.

Still, there's little point in trying to artificially remove drivers
that are 100% vendor unique from a vendor-specific location just for
the sake of it. And we do have a single merge path today through
arm-soc to catch a lot of these things as they get introduced --
almost more so than if everyone adds their own driver/ directory and
declare themselves maintainer of that subtree.

Kumar, it would be useful to get a bit of an inventory of what you
know you need a home for. I know the APM guys have a queue manager
(arm64-only) that handles things such as resource allocation for
ethernet, etc, that they need a home for. It's not a pure library
though, since there's also error interrupts, etc, to deal with.

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