arm: Split GENERIC into vendor files
Needs ReviewPublic

Authored by manu on Mon, Dec 25, 9:26 PM.

Details

Reviewers
None
Group Reviewers
ARM
Summary

While this doesn't give us an optimum flexibility this allow a user to build a kernel for a specific SoC family just by commenting one line in the GENERIC kernel.

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 13804
Build 14017: arc lint + arc unit
manu created this revision.Mon, Dec 25, 9:26 PM
imp added a comment.Mon, Dec 25, 11:20 PM

I like this.

Have you consider the testing requirements for making sure that one can write a config file with these w/o them breaking over time?

manu added a comment.Mon, Dec 25, 11:29 PM
In D13624#284876, @imp wrote:

I like this.

Have you consider the testing requirements for making sure that one can write a config file with these w/o them breaking over time?

The only "bad" thing that could happen is that someone add a "device blah" in multiple vendor file and so config will warn.
If every change to the GENERIC file is to add a generic driver and every change to a vendor file is to add a vendor driver everything is fine (tm).
I have other plan for config to allow a much better conf files but for now it's still in my brain.

imp added a comment.Tue, Dec 26, 1:52 AM
In D13624#284888, @manu wrote:
In D13624#284876, @imp wrote:

I like this.

Have you consider the testing requirements for making sure that one can write a config file with these w/o them breaking over time?

The only "bad" thing that could happen is that someone add a "device blah" in multiple vendor file and so config will warn.
If every change to the GENERIC file is to add a generic driver and every change to a vendor file is to add a vendor driver everything is fine (tm).
I have other plan for config to allow a much better conf files but for now it's still in my brain.

So you don't plan to write a script to generate a GENERIC that has all the 'other' std.foo lines commented out for each std.foo type to make sure that compiles?

manu added a comment.Tue, Dec 26, 1:50 PM
In D13624#284912, @imp wrote:
In D13624#284888, @manu wrote:
In D13624#284876, @imp wrote:

I like this.

Have you consider the testing requirements for making sure that one can write a config file with these w/o them breaking over time?

The only "bad" thing that could happen is that someone add a "device blah" in multiple vendor file and so config will warn.
If every change to the GENERIC file is to add a generic driver and every change to a vendor file is to add a vendor driver everything is fine (tm).
I have other plan for config to allow a much better conf files but for now it's still in my brain.

So you don't plan to write a script to generate a GENERIC that has all the 'other' std.foo lines commented out for each std.foo type to make sure that compiles?

What I plan is more or less something like that :

add two new directive for config :

  • deviceneed blah (which include device blah if it's not already present)
  • devicerequire blah (which fail if device blah isn't present already)

And add all devices in std.vendor that the SoC needs.

Move the rest of the require stuff from GENERIC to std.armv7.

This way one can easily create an ALLWINNER kernel config that contain three lines :
IDENT ALLWINNER
include std.armv7
include std.allwinner