[oe] Cleaning up the "linux" directory

[Ulf Samuelsson]

Marcin Juszkiewicz skrev:
> Dnia sobota, 22 sierpnia 2009 o 11:38:41 Ulf Samuelsson napisał(a):
>> As everyone knows, the kernel directory is a mess:
>> I have been thinking about what to do about this,
>> and with the ability to include files in subdirectories,
>> I think I have found a nice solution.
> 
> I had a look at this and for me it adds lot of things to care when kernel 
> needs to be updated/changed.
> 
> With current linux_X.Y.Z(.A).bb recipes it is easy to add new device - just 
> one file needs to be edited and thats all. If new patch has to be added then 
> still one file to edit. New board to be added - same amount of work. If 
> patches common for few targets needs to be added then you can create new 
> variable for them:
> 

The SRC_URI_appends should only contain automatically
generated things and there is warning against editing inserted.

When you say you only  have to edit one file to add a patch,
I think that is wrong. You have to enter the directory
and place the patch there.
It is defintely faster to select all the patches, and
run the script than to edit the toplevel file.

You also do not have to know the variable names.

If you want to add a board, you create the directory,
and possibly add a defconfig.
Rerun the script and again no editing of any files.

If you want to create a new CPU family, you probably are going
to create a file in conf/machine, and  you have to add the cpu  family
directory.
Easiest way to do this, is to copy another directory
and clean out the files.
Then you fill them with new board patches and defconfigs.

Personally, I see very little reasons for doing any editing
but if you want to do something for the at91, it is basically
the linux-2.6.3/at91/at91.inc that will the single file to edit.

It is different, but I think you should give it a try.



> AT91_PATCHES = "\
>         file://linux-2.6.30/at91/2.6.30.2/patch-sets/linux-2.6.30.2-at91-001-
> andrew-victor.patch;patch=1 \
>         file://linux-2.6.30/at91/2.6.30.2/patch-sets/linux-2.6.30.2-at91-002-
> experimental.patch;patch=1 \
>         file://linux-2.6.30/at91/2.6.30.2/patch-sets/linux-2.6.30.2-at91-003-
> ac97-0001-sam9g45-r1.patch;patch=1 \
>         file://linux-2.6.30/at91/2.6.30.2/patch-sets/linux-2.6.30.2-at91-003-
> ac97-0002-ac97-sam9rlek-r1.patch;patch=1 \
>         file://linux-2.6.30/at91/2.6.30.2/patch-sets/linux-2.6.30.2-at91-004-
> NAND-001-configurable-partition-size.patch;patch=1 \
>         file://linux-2.6.30/at91/2.6.30.2/patch-sets/linux-2.6.30.2-at91-005-
> touchscreen-001-sam9g45ek.patch;patch=1 \
>         file://linux-2.6.30/at91/2.6.30.2/patch-sets/linux-2.6.30.2-at91-006-
> EHCI-001.sam9g45ek.patch;patch=1 \
>         file://linux-2.6.30/at91/2.6.30.2/patch-sets/linux-2.6.30.2-at91-007-
> CLK-001-debug-clocks.patch;patch=1 \
>         "
> 
> And use it in SRC_URI for all boards. If patches do not touch files used by 
> other devices then adding them directly to default SRC_URI should also be 
> possible (thats how at91 patch was added in linux_2.6.30.bb recipe).
> 
> With your solution I have to check about 10 files in many directories or 
> regenerate all of them by some script (what about caring of manual changes in 
> those files?).


Running the scripts manually will be bad, you need to run them
from gnome (as of today).
What would be good to have is a bitbake command.

append	linux-${KERNEL_MAJOR}/${CPU_FAMILY}/${KERNEL_VERSION}/patch-sets/*
which would add all the *.patch files in the selected directories
in order.

Then there would be no need to run a script and no files to edit.
If you add a patch to the right directory,
then it will be added to the build.


> Maybe Buildroot uses such way (I do not know because last time I used it 
> before OE) but for me as long time OE developer it just adds lot of possible 
> errors to do.

No, this is brand new and it also >reduces< the number of errors.
Spelling errors in file names in particular.
I believe the whole systen will have less errors,
and the top level can be cleaned out.

The only real error is if you forget to run the script,
but once you are in the patch directory, it takes less than
5 seconds to select the patches, and run the script.
Much faster and less error prone than editing.


> Regards, 


-- 
Best Regards
Ulf Samuelsson