[meta-rockchip,v2,1/2] make rockchip kernel tweaks easier to use

If the machines defined in this layer are used, they will want to pull
in the kmeta data that is also provided in this layer when configuring
the Linux kernel. This all works automatically if linux-yocto or
linux-yocto-dev are used. But it causes build failures if a kernel
recipe is used or defined that is not one of these two.

Putting this layer-specific metadata into an *.inc file (then
referencing it in the kernel bbappends provided in this layer) makes
that metadata available to any other kernel recipe through the "require"
or "include" mechanism. Any other kernel recipe that is created can pull
in this metadata using either of these lines in the kernel recipe:

	require recipes-kernel/linux/linux-rockchip.inc
	include recipes-kernel/linux/linux-rockchip.inc

This layer can not guess or assume what other kernel recipes might be
used with its machine definitions, and providing random, potentially
dangling, bbappends is not a solution either. Therefore splitting this
layer's information into an *.inc file makes it available to recipes
outside this layer.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
changes from v1:
- updated the commit message after discussions with Quentin
- hopefully this version provides a clearer explanation and reasoning
  for the change
---
 recipes-kernel/linux/linux-rockchip.inc       | 35 ++++++++++++++++++
 .../realtek-r8169.cfg                         |  0
 .../rockchip/remove-non-rockchip-arch-arm.cfg |  0
 .../rockchip/remove-non-rockchip-arch-arm.scc |  0
 .../remove-non-rockchip-arch-arm64.cfg        |  0
 .../remove-non-rockchip-arch-arm64.scc        |  0
 recipes-kernel/linux/linux-yocto_%.bbappend   | 36 +------------------
 7 files changed, 36 insertions(+), 35 deletions(-)
 create mode 100644 recipes-kernel/linux/linux-rockchip.inc
 rename recipes-kernel/linux/{linux-yocto => linux-rockchip}/realtek-r8169.cfg (100%)
 rename recipes-kernel/linux/{linux-yocto => linux-rockchip}/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm.cfg (100%)
 rename recipes-kernel/linux/{linux-yocto => linux-rockchip}/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm.scc (100%)
 rename recipes-kernel/linux/{linux-yocto => linux-rockchip}/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm64.cfg (100%)
 rename recipes-kernel/linux/{linux-yocto => linux-rockchip}/rockchip-kmeta/bsp/rockchip/remove-non-rockchip-arch-arm64.scc (100%)

Hi Trevor,

On 12/8/25 8:35 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> If the machines defined in this layer are used, they will want to pull
> in the kmeta data that is also provided in this layer when configuring
> the Linux kernel. This all works automatically if linux-yocto or
> linux-yocto-dev are used. But it causes build failures if a kernel
> recipe is used or defined that is not one of these two.
> 

The issue is that we have machine configuration files settting the 
KERNEL_FEATURES variable in a conf file instead of having it in the 
kernel recipe.

kernel-yocto.bbclass is the one reading the variable and expecting to 
find an associated file defining what to do based on that variable.

So, by setting KERNEL_FEATURES in the machine conf file but only adding 
the necessary files to linux-yocto and linux-yocto-dev, any other recipe 
which inherits kernel-yocto.bbclass will fail to find the file 
associated with KERNEL_FEATURES (as the former is missing, currently 
only added in local bbappens and the latter is set from a conf file so 
always set essentially).

> Putting this layer-specific metadata into an *.inc file (then
> referencing it in the kernel bbappends provided in this layer) makes
> that metadata available to any other kernel recipe through the "require"
> or "include" mechanism. Any other kernel recipe that is created can pull
> in this metadata using either of these lines in the kernel recipe:
> 
> 	require recipes-kernel/linux/linux-rockchip.inc
> 	include recipes-kernel/linux/linux-rockchip.inc
> 

That's an okay work-around but why not move KERNEL_FEATURES into the 
recipe/bbappend so we don't break by default recipes which inherits 
kernel-yocto? You can still have this into a .inc file so it's easier to 
include for other kernel-yocto-inheriting recipes.

See meta-arm, oe-core with linux-yocto. I don't understand why we have 
KERNEL_FEATURES:append:pn-linux-yocto and 
KERNEL_FEATURES:append:pn-linux-yocto-rt in 
meta/conf/machine/include/qemu.inc though. I'm assuming we can move that 
to linux-yocto and linux-yocto-rt recipes.

Cheers,
Quentin

On Thu 2025-12-11 @ 03:13:50 PM, Quentin Schulz via lists.yoctoproject.org wrote:
> Hi Trevor,
> 
> On 12/8/25 8:35 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> > If the machines defined in this layer are used, they will want to pull
> > in the kmeta data that is also provided in this layer when configuring
> > the Linux kernel. This all works automatically if linux-yocto or
> > linux-yocto-dev are used. But it causes build failures if a kernel
> > recipe is used or defined that is not one of these two.
> > 
> 
> The issue is that we have machine configuration files settting the
> KERNEL_FEATURES variable in a conf file instead of having it in the kernel
> recipe.

As far as I am aware, there is no rule saying that KERNEL_FEATURES can
only appear in kernel recipes; in fact I think that's the wrong way to
think about them. The kernel provides many things, and each of these
things can be configured in the kernel.

For example the kernel provides filesystem types. If you developed
an application that, say, provided a fancy dashboard or status or
configuration or debug interface to a particular filesystem, then
I strongly feel the relevant KERNEL_FEATURES additions should be
contained in the Yocto Project recipe for that application. Perhaps
your application needs the CONFIG_*_FS_DEBUG flag enabled in the kernel
in order to work correctly or fully, in that case the KERNEL_FEATURES
should be specified in the recipe. There's no point having a user
include your app in their image if the kernel doesn't provide the
interface or data it needs to work correctly. I would even go a step
further than that: ideally all Yocto Project recipes would include the
KERNEL_FEATURES on which they depend, regardless of whether or not that
feature is present by default via, say, the in-kernel defconfig. For
example, a user might not be relying on some defconfig (regardless from
where it comes, whether it be in-kernel or from a BSP). In that case,
the recipe should work "out-of-the-box" for a user who is including
it in their image. My guess is that currently throughout oe-core and
meta-oe there are probably some recipes that have an implicit dependency
on some kernel feature being enabled; I think those should be make
explicit via KERNEL_FEATURES.

Another thing a kernel provides is architecture- and SoC-specific
code. In the same way as my user-space application example above,
architecture- and SoC-specific KERNEL_FEATURES should be specified in
machine configurations, not kernel recipes. Somebody building an image
for a Rockchip-based device does not need (for example) Qualcomm support
(and associated Qualcomm-specific drivers and features) in their kernel.
In meta-rockchip, using one of the meta-rockchip-defined MACHINES
disables Qualcomm (and others) support. This saves you in image size,
it saves you in runtime RAM usage, and it shrinks the attack surface
somewhat. You're suggesting meta-rockchip should have bbappends for
various known kernel recipes in order to provide the user with the same
kernel configuration adjustments, but this doesn't help a Rockchip user
if/when they define their own kernel recipe, or use, say, linux-stable
or linux-mainline from some of the kernel-specific Yocto Project layers
that exist. In that case they will get no error or warnings, they just
won't have any Rockchip-specific KERNEL_FEATURES enabled.

In an ideal world kernels would be configured starting with nothing,
from the ground up, by using KERNEL_FEATURES. BSP layers would add
KERNEL_FEATURES based on which SoC/board you are using which would come
into your build depending on which MACHINE you chose, software layers
would add KERNEL_FEATURES based on what software you're including. A
basic set of KERNEL_FEATURES would be available that most people would
want, but it could be overridden or tweaked as the user sees fit for
their purposes.

I feel the correct location for Rockchip-specific KERNEL_FEATURES is in
Rockchip MACHINE definitions, and I discovered they can be cumbersome to
use when they are only available for specific kernel recipes. Moving the
core of these files into an *.inc makes them available for all kernel
recipes.

> kernel-yocto.bbclass is the one reading the variable and expecting to find
> an associated file defining what to do based on that variable.
> 
> So, by setting KERNEL_FEATURES in the machine conf file but only adding the
> necessary files to linux-yocto and linux-yocto-dev, any other recipe which
> inherits kernel-yocto.bbclass will fail to find the file associated with
> KERNEL_FEATURES (as the former is missing, currently only added in local
> bbappens and the latter is set from a conf file so always set essentially).
> 
> > Putting this layer-specific metadata into an *.inc file (then
> > referencing it in the kernel bbappends provided in this layer) makes
> > that metadata available to any other kernel recipe through the "require"
> > or "include" mechanism. Any other kernel recipe that is created can pull
> > in this metadata using either of these lines in the kernel recipe:
> > 
> > 	require recipes-kernel/linux/linux-rockchip.inc
> > 	include recipes-kernel/linux/linux-rockchip.inc
> > 
> 
> That's an okay work-around but why not move KERNEL_FEATURES into the
> recipe/bbappend so we don't break by default recipes which inherits
> kernel-yocto? You can still have this into a .inc file so it's easier to
> include for other kernel-yocto-inheriting recipes.
> 
> See meta-arm, oe-core with linux-yocto. I don't understand why we have
> KERNEL_FEATURES:append:pn-linux-yocto and
> KERNEL_FEATURES:append:pn-linux-yocto-rt in
> meta/conf/machine/include/qemu.inc though. I'm assuming we can move that to
> linux-yocto and linux-yocto-rt recipes.
> 
> Cheers,
> Quentin
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#2765): https://lists.yoctoproject.org/g/yocto-patches/message/2765
> Mute This Topic: https://lists.yoctoproject.org/mt/116682100/900817
> Group Owner: yocto-patches+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13168745/900817/63955952/xyzzy [twoerner@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 
>

On Thu, Dec 11, 2025 at 3:22 PM Trevor Woerner via
lists.yoctoproject.org <twoerner=gmail.com@lists.yoctoproject.org>
wrote:
>
> On Thu 2025-12-11 @ 03:13:50 PM, Quentin Schulz via lists.yoctoproject.org wrote:
> > Hi Trevor,
> >
> > On 12/8/25 8:35 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> > > If the machines defined in this layer are used, they will want to pull
> > > in the kmeta data that is also provided in this layer when configuring
> > > the Linux kernel. This all works automatically if linux-yocto or
> > > linux-yocto-dev are used. But it causes build failures if a kernel
> > > recipe is used or defined that is not one of these two.
> > >
> >
> > The issue is that we have machine configuration files settting the
> > KERNEL_FEATURES variable in a conf file instead of having it in the kernel
> > recipe.
>
> As far as I am aware, there is no rule saying that KERNEL_FEATURES can
> only appear in kernel recipes; in fact I think that's the wrong way to
> think about them. The kernel provides many things, and each of these
> things can be configured in the kernel.

While there's no rule, it is just a variable and the variables follow the
standard scoping rules of bitbake. It isn't used like a configuration /
global scope variable, so it does get scoped to recipes.

It's the same way that you can't have recipe-a directly manipulating
the variables of recipe-b (or the classes used by those recipes).

You are also binding / coupling the kernel knowledge through different
parts of the system and that can cause issues. You can't have all
sorts of recipes making kernel configuration tweaks, as you will run
into conflicts and recipe-a and recipe-c will inevitably want conflicting
options, or will try and enable things that the hardware doesn't support.

I'm not describing that very well, I can try to explain it a different way
if that doesn't make sense.

What we've done in cases like this in the past, is just like any other
part of the system where you need coordination. Set a machine, distro
or image feature, use that variable to ensure that the kernel recipes
select the right KERNEL_FEATURES (and hence the right kernel
configuration options.

I'm not exactly what the error is that you are seeing and trying to
solve, but I'd suggest looking at meta-virtualization. I've solved
what I think you are encountering and describing, in that meta-virtualization
works with linux-yocto, works with non-linux yocto kernels, works with
specific versions and also maps virtualization packages/features to
specific KERNEL_FEATURES to ensure that any number of kernels
a user might want are configured in a way to support the stacks.

Cheers,

Bruce

>
> For example the kernel provides filesystem types. If you developed
> an application that, say, provided a fancy dashboard or status or
> configuration or debug interface to a particular filesystem, then
> I strongly feel the relevant KERNEL_FEATURES additions should be
> contained in the Yocto Project recipe for that application. Perhaps
> your application needs the CONFIG_*_FS_DEBUG flag enabled in the kernel
> in order to work correctly or fully, in that case the KERNEL_FEATURES
> should be specified in the recipe. There's no point having a user
> include your app in their image if the kernel doesn't provide the
> interface or data it needs to work correctly. I would even go a step
> further than that: ideally all Yocto Project recipes would include the
> KERNEL_FEATURES on which they depend, regardless of whether or not that
> feature is present by default via, say, the in-kernel defconfig. For
> example, a user might not be relying on some defconfig (regardless from
> where it comes, whether it be in-kernel or from a BSP). In that case,
> the recipe should work "out-of-the-box" for a user who is including
> it in their image. My guess is that currently throughout oe-core and
> meta-oe there are probably some recipes that have an implicit dependency
> on some kernel feature being enabled; I think those should be make
> explicit via KERNEL_FEATURES.
>
> Another thing a kernel provides is architecture- and SoC-specific
> code. In the same way as my user-space application example above,
> architecture- and SoC-specific KERNEL_FEATURES should be specified in
> machine configurations, not kernel recipes. Somebody building an image
> for a Rockchip-based device does not need (for example) Qualcomm support
> (and associated Qualcomm-specific drivers and features) in their kernel.
> In meta-rockchip, using one of the meta-rockchip-defined MACHINES
> disables Qualcomm (and others) support. This saves you in image size,
> it saves you in runtime RAM usage, and it shrinks the attack surface
> somewhat. You're suggesting meta-rockchip should have bbappends for
> various known kernel recipes in order to provide the user with the same
> kernel configuration adjustments, but this doesn't help a Rockchip user
> if/when they define their own kernel recipe, or use, say, linux-stable
> or linux-mainline from some of the kernel-specific Yocto Project layers
> that exist. In that case they will get no error or warnings, they just
> won't have any Rockchip-specific KERNEL_FEATURES enabled.
>
> In an ideal world kernels would be configured starting with nothing,
> from the ground up, by using KERNEL_FEATURES. BSP layers would add
> KERNEL_FEATURES based on which SoC/board you are using which would come
> into your build depending on which MACHINE you chose, software layers
> would add KERNEL_FEATURES based on what software you're including. A
> basic set of KERNEL_FEATURES would be available that most people would
> want, but it could be overridden or tweaked as the user sees fit for
> their purposes.
>
> I feel the correct location for Rockchip-specific KERNEL_FEATURES is in
> Rockchip MACHINE definitions, and I discovered they can be cumbersome to
> use when they are only available for specific kernel recipes. Moving the
> core of these files into an *.inc makes them available for all kernel
> recipes.
>
> > kernel-yocto.bbclass is the one reading the variable and expecting to find
> > an associated file defining what to do based on that variable.
> >
> > So, by setting KERNEL_FEATURES in the machine conf file but only adding the
> > necessary files to linux-yocto and linux-yocto-dev, any other recipe which
> > inherits kernel-yocto.bbclass will fail to find the file associated with
> > KERNEL_FEATURES (as the former is missing, currently only added in local
> > bbappens and the latter is set from a conf file so always set essentially).
> >
> > > Putting this layer-specific metadata into an *.inc file (then
> > > referencing it in the kernel bbappends provided in this layer) makes
> > > that metadata available to any other kernel recipe through the "require"
> > > or "include" mechanism. Any other kernel recipe that is created can pull
> > > in this metadata using either of these lines in the kernel recipe:
> > >
> > >     require recipes-kernel/linux/linux-rockchip.inc
> > >     include recipes-kernel/linux/linux-rockchip.inc
> > >
> >
> > That's an okay work-around but why not move KERNEL_FEATURES into the
> > recipe/bbappend so we don't break by default recipes which inherits
> > kernel-yocto? You can still have this into a .inc file so it's easier to
> > include for other kernel-yocto-inheriting recipes.
> >
> > See meta-arm, oe-core with linux-yocto. I don't understand why we have
> > KERNEL_FEATURES:append:pn-linux-yocto and
> > KERNEL_FEATURES:append:pn-linux-yocto-rt in
> > meta/conf/machine/include/qemu.inc though. I'm assuming we can move that to
> > linux-yocto and linux-yocto-rt recipes.
> >
> > Cheers,
> > Quentin
> >
> >
> >
> >
> >
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#2768): https://lists.yoctoproject.org/g/yocto-patches/message/2768
> Mute This Topic: https://lists.yoctoproject.org/mt/116682100/1050810
> Group Owner: yocto-patches+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13171493/1050810/607820704/xyzzy [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

Hi Trevor,

On 12/11/25 9:22 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> On Thu 2025-12-11 @ 03:13:50 PM, Quentin Schulz via lists.yoctoproject.org wrote:
>> Hi Trevor,
>>
>> On 12/8/25 8:35 PM, Trevor Woerner via lists.yoctoproject.org wrote:
>>> If the machines defined in this layer are used, they will want to pull
>>> in the kmeta data that is also provided in this layer when configuring
>>> the Linux kernel. This all works automatically if linux-yocto or
>>> linux-yocto-dev are used. But it causes build failures if a kernel
>>> recipe is used or defined that is not one of these two.
>>>
>>
>> The issue is that we have machine configuration files settting the
>> KERNEL_FEATURES variable in a conf file instead of having it in the kernel
>> recipe.
> 
> As far as I am aware, there is no rule saying that KERNEL_FEATURES can
> only appear in kernel recipes; in fact I think that's the wrong way to
> think about them. The kernel provides many things, and each of these
> things can be configured in the kernel.
> 
> For example the kernel provides filesystem types. If you developed
> an application that, say, provided a fancy dashboard or status or
> configuration or debug interface to a particular filesystem, then
> I strongly feel the relevant KERNEL_FEATURES additions should be
> contained in the Yocto Project recipe for that application. Perhaps
> your application needs the CONFIG_*_FS_DEBUG flag enabled in the kernel
> in order to work correctly or fully, in that case the KERNEL_FEATURES
> should be specified in the recipe. There's no point having a user
> include your app in their image if the kernel doesn't provide the
> interface or data it needs to work correctly. I would even go a step
> further than that: ideally all Yocto Project recipes would include the
> KERNEL_FEATURES on which they depend, regardless of whether or not that
> feature is present by default via, say, the in-kernel defconfig. For
> example, a user might not be relying on some defconfig (regardless from
> where it comes, whether it be in-kernel or from a BSP). In that case,
> the recipe should work "out-of-the-box" for a user who is including
> it in their image. My guess is that currently throughout oe-core and
> meta-oe there are probably some recipes that have an implicit dependency
> on some kernel feature being enabled; I think those should be make
> explicit via KERNEL_FEATURES.
> 

That's simply breaking the variable context. You cannot have your 
application recipe specify KERNEL_FEATURES and have the kernel recipe 
pick it up, that's not how it works unfortunately. Also, good luck 
making sure the application recipe in layer meta-i-am-haxorr isn't 
disabling all kernel security features via KERNEL_FEATURES if that was 
the case. (But then, "user's problem to make sure it doesn't happen" I 
guess).

This kind of need historically has been handled via a combination of 
DISTRO_FEATURES and MACHINE_FEATURES I assume? Maybe we need another 
mechanism for the kernel as well. I for sure would like one for 
specifying to the image (creating the U-Boot extlinux conf file) which 
of the kernel Device Trees my kernel recipe has installed (and which one 
should be the default). This is currently not possible and you need to 
modify the machine conf file when changing the kernel recipe (I have had 
kernel recipes with different names for the "same" device tree and I'll 
soon have overlays replacing full DTB I had made by hand, included 
through the same KERNEL_DEVICETREE mechanism). This is not 
meta-rockchip-specific, just a global issue. I stumbled upon 
meta/classes-recipe/uboot-config.bbclass modifying IMAGE_FSTYPES in the 
anonymous python function, I guess this must work (have worked?)... 
Wondering if that would work for my use-case. Another topic anyway.

> Another thing a kernel provides is architecture- and SoC-specific
> code. In the same way as my user-space application example above,
> architecture- and SoC-specific KERNEL_FEATURES should be specified in
> machine configurations, not kernel recipes. Somebody building an image
> for a Rockchip-based device does not need (for example) Qualcomm support
> (and associated Qualcomm-specific drivers and features) in their kernel.
> In meta-rockchip, using one of the meta-rockchip-defined MACHINES
> disables Qualcomm (and others) support. This saves you in image size,
> it saves you in runtime RAM usage, and it shrinks the attack surface
> somewhat. You're suggesting meta-rockchip should have bbappends for
> various known kernel recipes in order to provide the user with the same
> kernel configuration adjustments, but this doesn't help a Rockchip user
> if/when they define their own kernel recipe, or use, say, linux-stable

Their kernel recipe, their problem. I'm suggesting you to *not care* 
about those recipes you have no idea about, don't try to actively be 
smart about it.

Support what you want to support. Which seems to be linux-yocto, 
possibly linux-yocto-dev for some boards when linux-yocto is "too old" 
and you seem to have had some interest about linux-mainline recently. 
Support those, and people can infer from what you've done what they need 
to do to support their own fork.

Also, how do you plan on handling Kconfig option renames? See 
c20e8c5b1203 ("mfd: rk808: Split into core and i2c") for example.

> or linux-mainline from some of the kernel-specific Yocto Project layers
> that exist. In that case they will get no error or warnings, they just
> won't have any Rockchip-specific KERNEL_FEATURES enabled.
> 

Yes. And you complained that because KERNEL_FEATURES was set in machine 
conf file but there was no bbappend for linux-mainline to add anything 
specific to KERNEL_FEATURES, it would fail building it. This is not 
fixing the issue, it's making it easier to work-around it.

Now, I'm a user of meta-rockchip and I write my own kernel recipe and 
inherit kernel-yocto because I want to. I cannot build my recipe even 
though I did everything right in the recipe, because I'm missing a file 
I never asked to be there in the first place (via KERNEL_FEATURES in the 
machine conf file). Now I have to fix my kernel recipe to ignore this 
KERNEL_FEATURES or override it in my machine configuration file, but 
then I could be building linux-yocto and will report bugs to 
meta-rockchip with a config that doesn't match the one you are expecting.

I haven't checked if the following can happen, but a glance at the code 
seems to indicate yes. Let's say I know EXACTLY what I want and I 
provide a defconfig I built myself for linux-yocto after 
vetting/auditting it. Would I expect meta-rockchip's machine conf file 
to modify my kernel recipe's defconfig to add some config fragment? And 
yet it seems it would.

> In an ideal world kernels would be configured starting with nothing,
> from the ground up, by using KERNEL_FEATURES. BSP layers would add
> KERNEL_FEATURES based on which SoC/board you are using which would come
> into your build depending on which MACHINE you chose, software layers
> would add KERNEL_FEATURES based on what software you're including. A
> basic set of KERNEL_FEATURES would be available that most people would
> want, but it could be overridden or tweaked as the user sees fit for
> their purposes.
> 
> I feel the correct location for Rockchip-specific KERNEL_FEATURES is in
> Rockchip MACHINE definitions, and I discovered they can be cumbersome to

And I disagree.

> use when they are only available for specific kernel recipes. Moving the

So stop making it apply to all kernel recipes in all layers inheriting 
kernel-yocto, by simply moving KERNEL_FEATURES in the appropriate recipe 
(via an .inc file if you want)?

> core of these files into an *.inc makes them available for all kernel
> recipes.
> 

Yes, that's fine. I don't have an issue with the patch per-se, rather 
the reason for the patch to exist in the first place. This is a zero-sum 
patch, feel free to apply it, we can still continue the discussion in 
parallel on whether KERNEL_FEATURES should really be in machine conf 
files (it shouldn't :p).

Cheers,
Quentin