Hardware dependencies in Kconfig

Hardware dependencies in Kconfig

[Jean Delvare]

Hi all,

Configuring kernels from scratch has become an incredibly long and
tedious task. The reason is that the number of drivers and options has
exploded in the past few years. Which in itself is great - Linux is
successful, yeah! - but the side effects must be dealt with.
6000-line .config files are no fun.

Earlier today, I found that NET_CADENCE is set in my x86-64 kernel
configuration. The two ethernet drivers below this menu are for ARM
machines. I really shouldn't be asked about that on x86-64. I just sent
a patch addressing this specific issue, which follows about 50 similar
patches from me for similar issues in various subsystems. But I can't
do all of that by myself, this is too much work quantitatively, and I
am not always the best person to find out the proper hardware
dependencies that should be added.

I would like to call for proper hardware dependencies to become a
general trend: every new hardware-specific driver which is added to the
kernel should depend on ($hardware || COMPILE_TEST), so as to make it
clear right away, which type of hardware is expected to need the driver
in question.

$hardware can be the top-level architecture (e.g. ARM), but can also go
down to sub-architecture/platform (e.g. ARCH_AT91 or PLATFORM_AT32AP) or
even machine (e.g. PICOXCELL_PC3X3). The list can always be extended
later if needed. Ideally we should restrict as much as possible as long
as the result is easy to maintain, not too complex, and not likely to
break in a near future.

Thanks to COMPILE_TEST, we don't lose the build test coverage, and it
also makes it possible for anyone to still build the driver if the
dependency is too strict (as a temporary workaround until it gets fixed
upstream, that is.)

Does anyone object to this?

Ideally existing drivers would get the same treatment, and I encourage
subsystem maintainers or architecture maintainers to check which of
"their" drivers would benefit from that. But I understand this will take
some time, and this is certainly harder for existing drivers as a risk
of regression exists if we set too strict dependencies.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: Hardware dependencies in Kconfig

[Josh Boyer]

On Mon, Apr 14, 2014 at 8:53 AM, Jean Delvare <jdelvare@suse.de> wrote:
> Hi all,
>
> Configuring kernels from scratch has become an incredibly long and
> tedious task. The reason is that the number of drivers and options has
> exploded in the past few years. Which in itself is great - Linux is
> successful, yeah! - but the side effects must be dealt with.
> 6000-line .config files are no fun.
>
> Earlier today, I found that NET_CADENCE is set in my x86-64 kernel
> configuration. The two ethernet drivers below this menu are for ARM
> machines. I really shouldn't be asked about that on x86-64. I just sent
> a patch addressing this specific issue, which follows about 50 similar
> patches from me for similar issues in various subsystems. But I can't
> do all of that by myself, this is too much work quantitatively, and I
> am not always the best person to find out the proper hardware
> dependencies that should be added.

I have much the same problem when I'm doing the config changes for
Fedora kernel rebases.  I've gotten to the point where I can somewhat
guess based on the driver name which arch it's for (lately the
majority are for ARM), but that isn't really a great way to handle
things.  Only being asked about options for the arch being configured
is much better than playing guessing games.

> I would like to call for proper hardware dependencies to become a
> general trend: every new hardware-specific driver which is added to the
> kernel should depend on ($hardware || COMPILE_TEST), so as to make it
> clear right away, which type of hardware is expected to need the driver
> in question.
>
> $hardware can be the top-level architecture (e.g. ARM), but can also go
> down to sub-architecture/platform (e.g. ARCH_AT91 or PLATFORM_AT32AP) or
> even machine (e.g. PICOXCELL_PC3X3). The list can always be extended
> later if needed. Ideally we should restrict as much as possible as long
> as the result is easy to maintain, not too complex, and not likely to
> break in a near future.
>
> Thanks to COMPILE_TEST, we don't lose the build test coverage, and it
> also makes it possible for anyone to still build the driver if the
> dependency is too strict (as a temporary workaround until it gets fixed
> upstream, that is.)
>
> Does anyone object to this?

I think this is a great idea.  Thanks for bringing up the suggestion.

josh

Re: Hardware dependencies in Kconfig

[Greg KH]

On Mon, Apr 14, 2014 at 02:53:59PM +0200, Jean Delvare wrote:
> Hi all,
> 
> Configuring kernels from scratch has become an incredibly long and
> tedious task. The reason is that the number of drivers and options has
> exploded in the past few years. Which in itself is great - Linux is
> successful, yeah! - but the side effects must be dealt with.
> 6000-line .config files are no fun.
> 
> Earlier today, I found that NET_CADENCE is set in my x86-64 kernel
> configuration. The two ethernet drivers below this menu are for ARM
> machines. I really shouldn't be asked about that on x86-64. I just sent
> a patch addressing this specific issue, which follows about 50 similar
> patches from me for similar issues in various subsystems. But I can't
> do all of that by myself, this is too much work quantitatively, and I
> am not always the best person to find out the proper hardware
> dependencies that should be added.

Ideally, the arch doesn't matter at all for a driver, only the
infrastructure the driver depends on does.  So perhaps the
"infrastructure" dependancy should be added for the drivers that you
feel are only present on ARM platforms?  Are these all platform devices?

> I would like to call for proper hardware dependencies to become a
> general trend: every new hardware-specific driver which is added to the
> kernel should depend on ($hardware || COMPILE_TEST), so as to make it
> clear right away, which type of hardware is expected to need the driver
> in question.

Adding more COMPILE_TEST dependancies for platform drivers would be
wonderful to have, and make your life a little bit easier.  Other than
that, a simple 'm' selection for a distro config should be fine :)

thanks,

greg k-h

Re: Hardware dependencies in Kconfig

[Josh Boyer]

On Mon, Apr 14, 2014 at 3:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Apr 14, 2014 at 02:53:59PM +0200, Jean Delvare wrote:
>> Hi all,
>>
>> Configuring kernels from scratch has become an incredibly long and
>> tedious task. The reason is that the number of drivers and options has
>> exploded in the past few years. Which in itself is great - Linux is
>> successful, yeah! - but the side effects must be dealt with.
>> 6000-line .config files are no fun.
>>
>> Earlier today, I found that NET_CADENCE is set in my x86-64 kernel
>> configuration. The two ethernet drivers below this menu are for ARM
>> machines. I really shouldn't be asked about that on x86-64. I just sent
>> a patch addressing this specific issue, which follows about 50 similar
>> patches from me for similar issues in various subsystems. But I can't
>> do all of that by myself, this is too much work quantitatively, and I
>> am not always the best person to find out the proper hardware
>> dependencies that should be added.
>
> Ideally, the arch doesn't matter at all for a driver, only the
> infrastructure the driver depends on does.  So perhaps the
> "infrastructure" dependancy should be added for the drivers that you
> feel are only present on ARM platforms?  Are these all platform devices?

I think there's a theoretical vs. practical argument there.  USB, PCI,
etc drivers are mostly architecture agnostic.  However, the overlap of
drivers in the GPIO, I2C, watchdog, etc subsystems between
architectures is fairly small.  It requires the same (or at least very
similar) IP blocks to be used in different chips.  This _does_ happen,
and when it does it's also possible to have the driver "just work"
without updates.  It's also happens that the driver needs changes to
work on that arch.

So not specifying an arch dependency for those drivers in theory is
fine.  On the other side, asking questions about drivers that
literally have no practical use except on one arch is annoying and
leads to bloat.  Having that arch dep, and adding a new arch dep when
the HW is used one a new arch, adds a bit of development overhead
while helping with the issues Jean and I see.

>> I would like to call for proper hardware dependencies to become a
>> general trend: every new hardware-specific driver which is added to the
>> kernel should depend on ($hardware || COMPILE_TEST), so as to make it
>> clear right away, which type of hardware is expected to need the driver
>> in question.
>
> Adding more COMPILE_TEST dependancies for platform drivers would be
> wonderful to have, and make your life a little bit easier.  Other than
> that, a simple 'm' selection for a distro config should be fine :)

Ugh.  I hate the "distros should just say =m" for everything approach.
 Yeah, sometimes it's warranted but without on-going vetting of
configs you wind up building stuff that doesn't have any practical
chance of being on various platforms.

It also means distro kernel maintainers that want to avoid that spend
a lot of time looking at Kconfig files to figure out what drivers make
sense where.  That in turn leads to builds failing when we turn
something on that isn't in any of the defconfigs built in linux-next
on a particular arch.  That tends to lead to, at best, patch creation,
and more usually build break reports that are dealt with in a wide
variety of ways.  Creating patches for build breaks is great for stats
and stuff, but it would probably be nice not have to deal with that
hassle if it has no practical benefit.

Maybe I'm overly grumpy.  Still, it's frustrating to see Kconfig
entries that clearly say "blahblah found on foo ARM chip" in the help
with no "depends on ARM" (not meaning to pick on ARM).  I would like
to think there is some balance that could be found here.

josh

Re: Hardware dependencies in Kconfig

[Greg KH]

On Mon, Apr 14, 2014 at 03:59:11PM -0400, Josh Boyer wrote:
> 
> Maybe I'm overly grumpy.  Still, it's frustrating to see Kconfig
> entries that clearly say "blahblah found on foo ARM chip" in the help
> with no "depends on ARM" (not meaning to pick on ARM).  I would like
> to think there is some balance that could be found here.

Yes, that would make me grumpy, perhaps a few developers could be
auditing the new Kconfig items of every kernel around -rc3 timeframe to
ensure that they don't do stuff like this...

thanks,

greg k-h

Re: Hardware dependencies in Kconfig

[Jean Delvare]

Hi Greg,

On Mon, 14 Apr 2014 21:53:34 -0700, Greg KH wrote:
> On Mon, Apr 14, 2014 at 03:59:11PM -0400, Josh Boyer wrote:
> > 
> > Maybe I'm overly grumpy.  Still, it's frustrating to see Kconfig
> > entries that clearly say "blahblah found on foo ARM chip" in the help
> > with no "depends on ARM" (not meaning to pick on ARM).  I would like
> > to think there is some balance that could be found here.
> 
> Yes, that would make me grumpy, perhaps a few developers could be
> auditing the new Kconfig items of every kernel around -rc3 timeframe to
> ensure that they don't do stuff like this...

It's the reviewer's job to refuse new drivers with bad Kconfig
descriptions in the first place. This must happen as early as possible
in the chain. By -rc3 it's way too late, all kernel developers and
distributions have already moved to the new kernel so they have already
answered the n/m/y question for all new entries.

-- 
Jean Delvare
SUSE L3 Support

Re: Hardware dependencies in Kconfig

[Jean Delvare]

Hi Greg,

On Mon, 14 Apr 2014 12:11:43 -0700, Greg KH wrote:
> On Mon, Apr 14, 2014 at 02:53:59PM +0200, Jean Delvare wrote:
> > Configuring kernels from scratch has become an incredibly long and
> > tedious task. The reason is that the number of drivers and options has
> > exploded in the past few years. Which in itself is great - Linux is
> > successful, yeah! - but the side effects must be dealt with.
> > 6000-line .config files are no fun.
> > 
> > Earlier today, I found that NET_CADENCE is set in my x86-64 kernel
> > configuration. The two ethernet drivers below this menu are for ARM
> > machines. I really shouldn't be asked about that on x86-64. I just sent
> > a patch addressing this specific issue, which follows about 50 similar
> > patches from me for similar issues in various subsystems. But I can't
> > do all of that by myself, this is too much work quantitatively, and I
> > am not always the best person to find out the proper hardware
> > dependencies that should be added.
> 
> Ideally, the arch doesn't matter at all for a driver, only the
> infrastructure the driver depends on does.  So perhaps the
> "infrastructure" dependancy should be added for the drivers that you
> feel are only present on ARM platforms?

The infrastructure dependencies are already present and correct as far
as I can tell. In this specific case, NET_CADENCE depends on HAS_IOMEM
and the two actual drivers depend on HAS_DMA. I suppose this is
sufficient, otherwise there would have been build failures reported by
now.

>  Are these all platform devices?

In the case above, yes. But I don't quite see how that makes a
difference. x86 has platform drivers too, they are the essence of the
mfd framework. Almost every architecture can have platform drivers,
just like almost every platform can have PCI devices. I have been
adding dependencies on X86_32 for PCI drivers recently, for example.

I'm very fine with USB drivers being architecture-agnostic. They really
are. But in practice a lot of PCI and platform drivers are only useful
of one architecture, of a few ones at best.

Now I can understand that maybe you would prefer that we separate actual
dependencies from usefulness into separate "name spaces". For example
each driver could have a "target" statement where you say which
architectures are expected to need that driver. Then we could have an
option "hide all drivers which aren't for me". In fact I was about to
propose that in my initial post, but on second thought I had the
feeling that this was mostly duplicating what COMPILE_TEST already
achieves but under a different name. We'd need a compelling reason to
make things more complex, and I don't see such a reason at the moment
(I'm opened to discussion though.)

> > I would like to call for proper hardware dependencies to become a
> > general trend: every new hardware-specific driver which is added to the
> > kernel should depend on ($hardware || COMPILE_TEST), so as to make it
> > clear right away, which type of hardware is expected to need the driver
> > in question.
> 
> Adding more COMPILE_TEST dependancies for platform drivers would be
> wonderful to have, and make your life a little bit easier.  Other than
> that, a simple 'm' selection for a distro config should be fine :)

Huh, please, no. "Just say m if you don't know" was fine in the late
90s, when Linux was mostly x86. You could afford including 3% of
useless drivers, and people working on other architectures said "no" by
default and only included the few drivers they needed.

But today things have changed. We have a lot of very active, mature
architectures, with a bunch of existing drivers and a batch of new
drivers coming with every new kernel version. Saying "m" to everything
increases build times beyond reason. You also hit build failures you
shouldn't have to care about, depmod takes forever, updates are slow as
hell. This is the problem I am trying to solve.

openSUSE 13.1 for x86_64 comes with 2629 (modular) device drivers. In
comparison, openSUSE 11.4 came with 2301 device drivers. So we added at
least 328 new drivers in 2.5 years. How many of these are actually
useful on x86_64? My estimate is less than half. Most likely less than
one third. Quite possibly less than one quarter. We did not see that
many totally new devices in the (PC) x86 world lately, really.

In just two months, only looking at the drivers which happened to cross
my road for one reason or another, I already found about 50 drivers
which were included in openSUSE x86_64 and are are totally useless
there. There is probably 10 times that amount still waiting to be found
and disabled.

And it's not going to get any better over time. As others have already
mentioned, most new drivers these days are NOT for x86, they are for
ARM, AVR32 and other fancy embedded architectures.

"Just say m to everything" is just so wrong today that at SUSE we are
very close to switching our policy to "just say no to everything and
wait for people to complain about missing drivers." This may not sound
too appealing but this is the only way to keep the kernel package at a
reasonable size (and build time), as long as upstream doesn't help us
make smarter decisions. Useless modules aren't free, they aren't even
cheap.

Ideally I would like to be able to run "make oldconfig" on a new kernel
version and only be asked about things I should really care about. And
I'm sure every distro kernel package maintainer and most kernel
developers and advanced users feel the same.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: Hardware dependencies in Kconfig

[Greg KH]

On Mon, Apr 14, 2014 at 11:12:54PM +0200, Jean Delvare wrote:
> Hi Greg,
> 
> On Mon, 14 Apr 2014 12:11:43 -0700, Greg KH wrote:
> > On Mon, Apr 14, 2014 at 02:53:59PM +0200, Jean Delvare wrote:
> > > Configuring kernels from scratch has become an incredibly long and
> > > tedious task. The reason is that the number of drivers and options has
> > > exploded in the past few years. Which in itself is great - Linux is
> > > successful, yeah! - but the side effects must be dealt with.
> > > 6000-line .config files are no fun.
> > > 
> > > Earlier today, I found that NET_CADENCE is set in my x86-64 kernel
> > > configuration. The two ethernet drivers below this menu are for ARM
> > > machines. I really shouldn't be asked about that on x86-64. I just sent
> > > a patch addressing this specific issue, which follows about 50 similar
> > > patches from me for similar issues in various subsystems. But I can't
> > > do all of that by myself, this is too much work quantitatively, and I
> > > am not always the best person to find out the proper hardware
> > > dependencies that should be added.
> > 
> > Ideally, the arch doesn't matter at all for a driver, only the
> > infrastructure the driver depends on does.  So perhaps the
> > "infrastructure" dependancy should be added for the drivers that you
> > feel are only present on ARM platforms?
> 
> The infrastructure dependencies are already present and correct as far
> as I can tell. In this specific case, NET_CADENCE depends on HAS_IOMEM
> and the two actual drivers depend on HAS_DMA. I suppose this is
> sufficient, otherwise there would have been build failures reported by
> now.

That's good to hear.

> >  Are these all platform devices?
> 
> In the case above, yes. But I don't quite see how that makes a
> difference. x86 has platform drivers too, they are the essence of the
> mfd framework. Almost every architecture can have platform drivers,
> just like almost every platform can have PCI devices. I have been
> adding dependencies on X86_32 for PCI drivers recently, for example.
> 
> I'm very fine with USB drivers being architecture-agnostic. They really
> are. But in practice a lot of PCI and platform drivers are only useful
> of one architecture, of a few ones at best.

Why would PCI devices only be useful on one architecture?  PCI works on
almost all arches that Linux supports, if it's a PCI card, it could be
on any of those processors.  If it's a mini-pci, the chances are less,
but still quite possible.

> > > I would like to call for proper hardware dependencies to become a
> > > general trend: every new hardware-specific driver which is added to the
> > > kernel should depend on ($hardware || COMPILE_TEST), so as to make it
> > > clear right away, which type of hardware is expected to need the driver
> > > in question.
> > 
> > Adding more COMPILE_TEST dependancies for platform drivers would be
> > wonderful to have, and make your life a little bit easier.  Other than
> > that, a simple 'm' selection for a distro config should be fine :)
> 
> Huh, please, no. "Just say m if you don't know" was fine in the late
> 90s, when Linux was mostly x86. You could afford including 3% of
> useless drivers, and people working on other architectures said "no" by
> default and only included the few drivers they needed.
> 
> But today things have changed. We have a lot of very active, mature
> architectures, with a bunch of existing drivers and a batch of new
> drivers coming with every new kernel version. Saying "m" to everything
> increases build times beyond reason. You also hit build failures you
> shouldn't have to care about, depmod takes forever, updates are slow as
> hell. This is the problem I am trying to solve.

What is the build time difference you are seeing?  I do 'allmodconfig'
builds all the time, with over 3000 modules.  The build works just fine
on "modern" hardware.  Cutting out 100 modules might speed it up a bit,
but really, is that a big deal overall?

> openSUSE 13.1 for x86_64 comes with 2629 (modular) device drivers. In
> comparison, openSUSE 11.4 came with 2301 device drivers. So we added at
> least 328 new drivers in 2.5 years. How many of these are actually
> useful on x86_64? My estimate is less than half.

And really, that's only 130 new modules a year or so, with all of the
new hardware coming out, is that really a lot?

Yes, it's a pain for distros, and yes, it would be nice if people wrote
better Kconfig help text.  Pushing back on that is the key here.  If you
see new drivers show up that you don't know where they work on, ask the
developers and make up patches.

> Most likely less than one third. Quite possibly less than one quarter.
> We did not see that many totally new devices in the (PC) x86 world
> lately, really.

There are a lot of new devices out there, and we are dragging in tons of
previously out-of-tree drivers in.  Look at the huge explosion of the
IIO drivers that we now have, supporting hundreds of new types of
sensors.  We have new bus types, coming from the work done by CERN and
other research groups.  We have wacky co-processor boards, and odd huge
iron controller boards.  All of these work on x86 platforms.

Yes lots of drivers are moving out of the arm SOC area into the
"generic" part of the kernel, and that's a good thing.  Lots of those IP
blocks are now showing up on x86 platforms as well, as that processor
goes after the previously-arm-only markets (we have examples of that in
the USB gadget area of the kernel).

> In just two months, only looking at the drivers which happened to cross
> my road for one reason or another, I already found about 50 drivers
> which were included in openSUSE x86_64 and are are totally useless
> there. There is probably 10 times that amount still waiting to be found
> and disabled.

Great, but were all of these new in the past year?  :)

> And it's not going to get any better over time. As others have already
> mentioned, most new drivers these days are NOT for x86, they are for
> ARM, AVR32 and other fancy embedded architectures.
> 
> "Just say m to everything" is just so wrong today that at SUSE we are
> very close to switching our policy to "just say no to everything and
> wait for people to complain about missing drivers." This may not sound
> too appealing but this is the only way to keep the kernel package at a
> reasonable size (and build time), as long as upstream doesn't help us
> make smarter decisions. Useless modules aren't free, they aren't even
> cheap.

I'd argue that your build systems need to get faster, the laptop I'm
typing this on can do a full modconfig build, with over 3000 modules, in
around 20 minutes.  My build server in the cloud can do that in less
than 5 minutes, and that's not a very fast machine these days.

> Ideally I would like to be able to run "make oldconfig" on a new kernel
> version and only be asked about things I should really care about. And
> I'm sure every distro kernel package maintainer and most kernel
> developers and advanced users feel the same.

I agree, but partitioning all new drivers off to a single arch might be
hard to do.  It's not a simple problem, I'd suggest getting a faster
build box to start with :)

thanks,

greg k-h

Re: Hardware dependencies in Kconfig

[Michal Marek]

On 2014-04-15 06:52, Greg KH wrote:
> On Mon, Apr 14, 2014 at 11:12:54PM +0200, Jean Delvare wrote:
>> I'm very fine with USB drivers being architecture-agnostic. They really
>> are. But in practice a lot of PCI and platform drivers are only useful
>> of one architecture, of a few ones at best.
> 
> Why would PCI devices only be useful on one architecture?  PCI works on
> almost all arches that Linux supports, if it's a PCI card, it could be
> on any of those processors.  If it's a mini-pci, the chances are less,
> but still quite possible.

"PCI device" does not necessarily imply any of the PCI/PCIe form
factors. Looking at my desktop machine, neither the integrated graphics
core nor the Intel Management Engine thing are cards that I could plug
into an ARM router with a PCI slot. So the i915 and mei drivers are
properly annotated with 'depends on X86' and one is not bothered with
the prompts when building a kernel for an ARM router.


> Yes, it's a pain for distros, and yes, it would be nice if people wrote
> better Kconfig help text.  Pushing back on that is the key here.  If you
> see new drivers show up that you don't know where they work on, ask the
> developers and make up patches.

Better help texts would be nice, but what would really help is some
machine-readable annotation. 'depends on <arch/mach> || COMPILE_TEST' is
already available, so why not use it.

Michal

Re: Hardware dependencies in Kconfig

[Jean Delvare]

Hi Greg,

On Mon, 14 Apr 2014 21:52:14 -0700, Greg KH wrote:
> On Mon, Apr 14, 2014 at 11:12:54PM +0200, Jean Delvare wrote:
> > In the case above, yes. But I don't quite see how that makes a
> > difference. x86 has platform drivers too, they are the essence of the
> > mfd framework. Almost every architecture can have platform drivers,
> > just like almost every platform can have PCI devices. I have been
> > adding dependencies on X86_32 for PCI drivers recently, for example.
> > 
> > I'm very fine with USB drivers being architecture-agnostic. They really
> > are. But in practice a lot of PCI and platform drivers are only useful
> > of one architecture, of a few ones at best.
> 
> Why would PCI devices only be useful on one architecture?  PCI works on
> almost all arches that Linux supports, if it's a PCI card, it could be
> on any of those processors.  If it's a mini-pci, the chances are less,
> but still quite possible.

"If it's a PCI card" is the key conditional here. Most PCI "devices"
out there do not come in the form of PCI cards. They are embedded into
processors, south bridges, north bridges etc. They are, in essence,
"platform devices", which in turn makes their drivers "platform
drivers", even though they get registered within the kernel using
pci_register_driver().

For all these drivers, depending on a specific architecture or platform
makes sense.

> > (...)
> > Huh, please, no. "Just say m if you don't know" was fine in the late
> > 90s, when Linux was mostly x86. You could afford including 3% of
> > useless drivers, and people working on other architectures said "no" by
> > default and only included the few drivers they needed.
> > 
> > But today things have changed. We have a lot of very active, mature
> > architectures, with a bunch of existing drivers and a batch of new
> > drivers coming with every new kernel version. Saying "m" to everything
> > increases build times beyond reason. You also hit build failures you
> > shouldn't have to care about, depmod takes forever, updates are slow as
> > hell. This is the problem I am trying to solve.
> 
> What is the build time difference you are seeing?

I'm not seeing a build time "difference" at this point, as we don't know
yet exactly which drivers can be omitted. That's the problem which
started this discussion ;-)

What I do see is build times which look excessive. Or, at the very
least, have room for improvement.

> I do 'allmodconfig'
> builds all the time, with over 3000 modules.  The build works just fine
> on "modern" hardware.

Well, when you build an "allmodconfig" kernel, you get what you asked
for, and that's fine. That's not what distro kernel people do. Also,
distro kernels are many. We have 34 kernel flavors for openSUSE 13.1
for example. And every commit potentially triggers a rebuild of the
whole set, to catch regressions as fast as possible. So every module we
build for no good reason, gets built a hundred times each day.

> Cutting out 100 modules might speed it up a bit,
> but really, is that a big deal overall?

I don't think we're talking about only 100 modules there, more like
1000. Not that I wouldn't want to clean things up even if that was only
100 useless modules, but please don't minimize the importance of the
problem. The exact number is very difficult to evaluate, as evaluating
it would basically require almost the same effort as actually fixing
all the driver dependencies.

Also, again, it's not only a matter of build time. I can only quote
myself: "You also hit build failures you shouldn't have to care about,
depmod takes forever, updates are slow as hell." No matter how powerful
your build farm is, these additional problems still exist.

So please don't lose the focus. The question I raised is "how to help
people generate sane kernel configuration files", not "how to help
people build their kernel faster". The improved build time is only a
(very) nice side effect.

> > openSUSE 13.1 for x86_64 comes with 2629 (modular) device drivers. In
> > comparison, openSUSE 11.4 came with 2301 device drivers. So we added at
> > least 328 new drivers in 2.5 years. How many of these are actually
> > useful on x86_64? My estimate is less than half.
> 
> And really, that's only 130 new modules a year or so, with all of the
> new hardware coming out, is that really a lot?

The absolute number doesn't mean much. The important point is how many
of these we actually need. Most new PC devices are handled by adding
their IDs to existing drivers. Sometimes with a lot of code additions
(think new Radeon graphics cards for example) but in most cases it
doesn't take a new driver. The new drivers, these days, are for
embedded devices.

> Yes, it's a pain for distros, and yes, it would be nice if people wrote
> better Kconfig help text.  Pushing back on that is the key here.  If you
> see new drivers show up that you don't know where they work on, ask the
> developers and make up patches.

That would be a very good start, yes. I get very grumpy when a new
Kconfig option is added and the Kconfig help text doesn't give me a
clue if I should enable it or not. As a kernel maintainer, I do push
back when I have to. But as a developer / distro kernel maintainer, I
am mostly the victim of other kernel maintainers not pushing back.

But even if we got perfect Kconfig help texts, updating a distribution
to the next kernel version would still be much easier if we only had to
answer the 10 questions which really matter to us, rather than 50
questions, 40 of which end up being "no" because they don't even make
sense for us. These "no" take time. Hence my request that developers
and maintainers add hardware dependencies whenever that makes sense.

> > Most likely less than one third. Quite possibly less than one quarter.
> > We did not see that many totally new devices in the (PC) x86 world
> > lately, really.
> 
> There are a lot of new devices out there, and we are dragging in tons of
> previously out-of-tree drivers in.  Look at the huge explosion of the
> IIO drivers that we now have, supporting hundreds of new types of
> sensors.  

IIO is the typical example of drivers which can currently be built
everywhere while only useful on embedded architectures. Thanks for
proving my point ;-) That was an easy one though, in openSUSE we ended
up disabling CONFIG_IIO altogether in all non-arm configs. What's a lot
more difficult to deal with are subsystems where each driver
individually may or may not be useful for a specific architecture /
platform. For example network device drivers, GPIO drivers, I2C bus
drivers, hwmon drivers, MFD... Everything where the functionality
itself is generic but the implementations aren't.

> We have new bus types, coming from the work done by CERN and
> other research groups.  We have wacky co-processor boards, and odd huge
> iron controller boards.  All of these work on x86 platforms.

They work there, yes. Are they useful there? Maybe. Are they used on
"traditional x86" (aka PC / server)? I very much doubt it.

Not all of this can necessarily be expressed with dependencies on
Kconfig symbols which exist today. It may make sense to introduce new
symbols to define per-usage subsets of a given architecture (e.g.
X86_PC or X86_EMBEDDED), or even perpendicular target selection ("What
device type is this kernel for? CONFIG_CELLPHONE / CONFIG_TABLET ...),
to make configuration easier. But I believe that just starting with
what is already available should already help a lot.

> Yes lots of drivers are moving out of the arm SOC area into the
> "generic" part of the kernel, and that's a good thing.  Lots of those IP
> blocks are now showing up on x86 platforms as well, as that processor
> goes after the previously-arm-only markets (we have examples of that in
> the USB gadget area of the kernel).

I'm perfectly happy with "depends on (X86 || ARM || COMPILE_TEST)" if
that corresponds to reality. That will make PPC people happy at
least :-) I didn't claim that adding that type of dependencies will
magically achieve the perfect kernel config for my specific case, I'm
just saying that such dependencies would help (me and others) a lot.

> > In just two months, only looking at the drivers which happened to cross
> > my road for one reason or another, I already found about 50 drivers
> > which were included in openSUSE x86_64 and are are totally useless
> > there. There is probably 10 times that amount still waiting to be found
> > and disabled.
> 
> Great, but were all of these new in the past year?  :)

No, I believe most of the ones I found and fixed were older. But I
don't quite see how it matters. The problem isn't new. Simply I think
it's easier to get the dependencies right on new drivers than on
existing drivers, which is why I propose that we start there. Just like
we require than new drivers pass checkpatch.pl, while old drivers don't
get deleted is they do not. But I certainly don't want to discourage
people from adding dependencies on existing drives, in fact I would
encourage them to do that.

> > And it's not going to get any better over time. As others have already
> > mentioned, most new drivers these days are NOT for x86, they are for
> > ARM, AVR32 and other fancy embedded architectures.
> > 
> > "Just say m to everything" is just so wrong today that at SUSE we are
> > very close to switching our policy to "just say no to everything and
> > wait for people to complain about missing drivers." This may not sound
> > too appealing but this is the only way to keep the kernel package at a
> > reasonable size (and build time), as long as upstream doesn't help us
> > make smarter decisions. Useless modules aren't free, they aren't even
> > cheap.
> 
> I'd argue that your build systems need to get faster, the laptop I'm
> typing this on can do a full modconfig build, with over 3000 modules, in
> around 20 minutes.  My build server in the cloud can do that in less
> than 5 minutes, and that's not a very fast machine these days.

Electricity isn't free, hardware isn't free, rack slot count is finite
and server room space is limited over here.

I don't quite see why we should invest in new hardware to shorten the
build times, if the same can be achieved with our current hardware
simply with better configuration files. Plus there is no reason to
choose between the two. We can have new hardware _and_ better configs
and improve the build times further :-) So your proposal is off-topic
to some degree.

And really, I don't see why I should have to wait for 10 minutes for my
build to complete if half of that is spent building drivers that will
never be used. The fact that 10 minutes is "reasonable" is irrelevant.

Of course, if the Linux Foundation, or you personally, are willing to
buy me a brand new workstation with more CPU power than I currently
have, I'll gladly accept. You can also donate your powerful laptop to
the OBS project, they'll be happy to add it to their build farm ;-)

> > Ideally I would like to be able to run "make oldconfig" on a new kernel
> > version and only be asked about things I should really care about. And
> > I'm sure every distro kernel package maintainer and most kernel
> > developers and advanced users feel the same.
> 
> I agree, but partitioning all new drivers off to a single arch might be
> hard to do.  It's not a simple problem, I'd suggest getting a faster
> build box to start with :)

I know it's not simple, but we could start with the low-hanging fruits,
which I believe are many. What I'm really asking for is not "all new
drivers partitioned to a single arch", but "new drivers partitioned to
whatever arch or platform dependencies make sense where applicable." I
don't think this is unreasonable.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: Hardware dependencies in Kconfig

[Randy Dunlap]

On 04/15/2014 03:54 AM, Jean Delvare wrote:
> Hi Greg,
> 
> On Mon, 14 Apr 2014 21:52:14 -0700, Greg KH wrote:
>> On Mon, Apr 14, 2014 at 11:12:54PM +0200, Jean Delvare wrote:
> 
>> I do 'allmodconfig'
>> builds all the time, with over 3000 modules.  The build works just fine
>> on "modern" hardware.
> 
>> I'd argue that your build systems need to get faster, the laptop I'm
>> typing this on can do a full modconfig build, with over 3000 modules, in
>> around 20 minutes.  My build server in the cloud can do that in less
>> than 5 minutes, and that's not a very fast machine these days.
> 
> Electricity isn't free, hardware isn't free, rack slot count is finite
> and server room space is limited over here.
> 
> I don't quite see why we should invest in new hardware to shorten the
> build times, if the same can be achieved with our current hardware
> simply with better configuration files. Plus there is no reason to
> choose between the two. We can have new hardware _and_ better configs
> and improve the build times further :-) So your proposal is off-topic
> to some degree.
> 
> And really, I don't see why I should have to wait for 10 minutes for my
> build to complete if half of that is spent building drivers that will
> never be used. The fact that 10 minutes is "reasonable" is irrelevant.
> 
> Of course, if the Linux Foundation, or you personally, are willing to
> buy me a brand new workstation with more CPU power than I currently
> have, I'll gladly accept. You can also donate your powerful laptop to
> the OBS project, they'll be happy to add it to their build farm ;-)

hey, over here also...
I'd like a new fast laptop that does decent allmodconfig build times.  :)
[e.g., a core i7 cpu and ssd and lots of RAM]

-- 
~Randy

Re: Hardware dependencies in Kconfig

[Josh Boyer]

On Tue, Apr 15, 2014 at 12:52 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Apr 14, 2014 at 11:12:54PM +0200, Jean Delvare wrote:
>> And it's not going to get any better over time. As others have already
>> mentioned, most new drivers these days are NOT for x86, they are for
>> ARM, AVR32 and other fancy embedded architectures.
>>
>> "Just say m to everything" is just so wrong today that at SUSE we are
>> very close to switching our policy to "just say no to everything and
>> wait for people to complain about missing drivers." This may not sound
>> too appealing but this is the only way to keep the kernel package at a
>> reasonable size (and build time), as long as upstream doesn't help us
>> make smarter decisions. Useless modules aren't free, they aren't even
>> cheap.

FWIW, we did that policy changed in Fedora a while ago.  Not
wholesale, but if it looks niche, it's disabled by default and enabled
only on request.

> I'd argue that your build systems need to get faster, the laptop I'm
> typing this on can do a full modconfig build, with over 3000 modules, in
> around 20 minutes.  My build server in the cloud can do that in less
> than 5 minutes, and that's not a very fast machine these days.

Is that literally 'make modconfig && make bzImage && make modules' in
those setups?  I'm curious if the distros have some options enabled
that significantly impact build time.  Perhaps CONFIG_DEBUG_INFO or
something else like that.  Could you send me whatever config results
from what you're building in 5min?

It takes my desktop machine about 30-45min to build an x86_64 kernel
RPM with the current configs.  Now granted, that's a bit more than
just building a kernel in a local git tree, but it's nowhere near
5min.  Our official build servers show similar timings for x86_64.

For ARM kernels, it takes about 3.5-4 hours.  That's due to policy
decisions on now allowing cross-builds in the distro (sigh), so all of
the kernels are built on native ARM machines.

>> Ideally I would like to be able to run "make oldconfig" on a new kernel
>> version and only be asked about things I should really care about. And
>> I'm sure every distro kernel package maintainer and most kernel
>> developers and advanced users feel the same.
>
> I agree, but partitioning all new drivers off to a single arch might be
> hard to do.  It's not a simple problem, I'd suggest getting a faster
> build box to start with :)

In some cases, that literally isn't possible.  As far as I'm aware,
Fedora is using the fastest available ARM server boxes from Calxeda.
In the future, AArch64 machines will help but that doesn't solve the
problem of bloat anyway.

josh

Re: Hardware dependencies in Kconfig

[Greg KH]

On Tue, Apr 15, 2014 at 07:50:05AM -0400, Josh Boyer wrote:
> On Tue, Apr 15, 2014 at 12:52 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Mon, Apr 14, 2014 at 11:12:54PM +0200, Jean Delvare wrote:
> >> And it's not going to get any better over time. As others have already
> >> mentioned, most new drivers these days are NOT for x86, they are for
> >> ARM, AVR32 and other fancy embedded architectures.
> >>
> >> "Just say m to everything" is just so wrong today that at SUSE we are
> >> very close to switching our policy to "just say no to everything and
> >> wait for people to complain about missing drivers." This may not sound
> >> too appealing but this is the only way to keep the kernel package at a
> >> reasonable size (and build time), as long as upstream doesn't help us
> >> make smarter decisions. Useless modules aren't free, they aren't even
> >> cheap.
> 
> FWIW, we did that policy changed in Fedora a while ago.  Not
> wholesale, but if it looks niche, it's disabled by default and enabled
> only on request.
> 
> > I'd argue that your build systems need to get faster, the laptop I'm
> > typing this on can do a full modconfig build, with over 3000 modules, in
> > around 20 minutes.  My build server in the cloud can do that in less
> > than 5 minutes, and that's not a very fast machine these days.
> 
> Is that literally 'make modconfig && make bzImage && make modules' in
> those setups?

Yes, I use ktest with the allmodconfig option.

> I'm curious if the distros have some options enabled
> that significantly impact build time.  Perhaps CONFIG_DEBUG_INFO or
> something else like that.  Could you send me whatever config results
> from what you're building in 5min?

You can use ktest with the BUILD_TYPE set to allmodconfig and it will
reproduce the same options.

> It takes my desktop machine about 30-45min to build an x86_64 kernel
> RPM with the current configs.  Now granted, that's a bit more than
> just building a kernel in a local git tree, but it's nowhere near
> 5min.  Our official build servers show similar timings for x86_64.
> 
> For ARM kernels, it takes about 3.5-4 hours.  That's due to policy
> decisions on now allowing cross-builds in the distro (sigh), so all of
> the kernels are built on native ARM machines.

That's really crazy to do that, there is this wonderful tool called
qemu... :)

good luck,

greg k-h

Re: Hardware dependencies in Kconfig

[Josh Boyer]

On Tue, Apr 15, 2014 at 11:24 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, Apr 15, 2014 at 07:50:05AM -0400, Josh Boyer wrote:
>> On Tue, Apr 15, 2014 at 12:52 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>> > On Mon, Apr 14, 2014 at 11:12:54PM +0200, Jean Delvare wrote:
>> >> And it's not going to get any better over time. As others have already
>> >> mentioned, most new drivers these days are NOT for x86, they are for
>> >> ARM, AVR32 and other fancy embedded architectures.
>> >>
>> >> "Just say m to everything" is just so wrong today that at SUSE we are
>> >> very close to switching our policy to "just say no to everything and
>> >> wait for people to complain about missing drivers." This may not sound
>> >> too appealing but this is the only way to keep the kernel package at a
>> >> reasonable size (and build time), as long as upstream doesn't help us
>> >> make smarter decisions. Useless modules aren't free, they aren't even
>> >> cheap.
>>
>> FWIW, we did that policy changed in Fedora a while ago.  Not
>> wholesale, but if it looks niche, it's disabled by default and enabled
>> only on request.
>>
>> > I'd argue that your build systems need to get faster, the laptop I'm
>> > typing this on can do a full modconfig build, with over 3000 modules, in
>> > around 20 minutes.  My build server in the cloud can do that in less
>> > than 5 minutes, and that's not a very fast machine these days.
>>
>> Is that literally 'make modconfig && make bzImage && make modules' in
>> those setups?
>
> Yes, I use ktest with the allmodconfig option.
>
>> I'm curious if the distros have some options enabled
>> that significantly impact build time.  Perhaps CONFIG_DEBUG_INFO or
>> something else like that.  Could you send me whatever config results
>> from what you're building in 5min?
>
> You can use ktest with the BUILD_TYPE set to allmodconfig and it will
> reproduce the same options.

OK, I'll look at what it produces.  Thanks.

I still agree with Jean that this isn't a solution to the actual problem though.

>> It takes my desktop machine about 30-45min to build an x86_64 kernel
>> RPM with the current configs.  Now granted, that's a bit more than
>> just building a kernel in a local git tree, but it's nowhere near
>> 5min.  Our official build servers show similar timings for x86_64.
>>
>> For ARM kernels, it takes about 3.5-4 hours.  That's due to policy
>> decisions on now allowing cross-builds in the distro (sigh), so all of
>> the kernels are built on native ARM machines.
>
> That's really crazy to do that, there is this wonderful tool called
> qemu... :)

Yes, well... I don't get to set the policy.  This particular brand of
crazy does have some benefits, but I'm not sure they outweigh the
negatives.

josh

Re: Hardware dependencies in Kconfig

[Jean Delvare]

On Mon, 14 Apr 2014 21:52:14 -0700, Greg KH wrote:
> I'd argue that your build systems need to get faster, the laptop I'm
> typing this on can do a full modconfig build, with over 3000 modules, in
> around 20 minutes.  My build server in the cloud can do that in less
> than 5 minutes, and that's not a very fast machine these days.

For the record, and again underlining that this isn't the problem I was
discussing originally: an allmodconfig build on my workstation takes a
over 38 minutes. This is a Xeon 5520 CPU (4 cores + HT) and I'm
building on an SSD. The machine is otherwise idle. While this isn't
exactly brand new hardware, it is still reasonably powerful, and 38
minutes is time, especially when you're waiting for the build to
complete before you can resume working on something.

-- 
Jean Delvare
SUSE L3 Support

Re: Hardware dependencies in Kconfig

[Pavel Machek]

Hi!

> > > > Configuring kernels from scratch has become an incredibly long and
> > > > tedious task. The reason is that the number of drivers and options has
> > > > exploded in the past few years. Which in itself is great - Linux is
> > > > successful, yeah! - but the side effects must be dealt with.
> > > > 6000-line .config files are no fun.
> > > > 
> > > > Earlier today, I found that NET_CADENCE is set in my x86-64 kernel
> > > > configuration. The two ethernet drivers below this menu are for ARM
> > > > machines. I really shouldn't be asked about that on x86-64. I just sent
> > > > a patch addressing this specific issue, which follows about 50 similar
> > > > patches from me for similar issues in various subsystems. But I can't
> > > > do all of that by myself, this is too much work quantitatively, and I
> > > > am not always the best person to find out the proper hardware
> > > > dependencies that should be added.
> > > 
> > > Ideally, the arch doesn't matter at all for a driver, only the
> > > infrastructure the driver depends on does.  So perhaps the
> > > "infrastructure" dependancy should be added for the drivers that you
> > > feel are only present on ARM platforms?
> > 
> > The infrastructure dependencies are already present and correct as far
> > as I can tell. In this specific case, NET_CADENCE depends on HAS_IOMEM
> > and the two actual drivers depend on HAS_DMA. I suppose this is
> > sufficient, otherwise there would have been build failures reported by
> > now.
> 
> That's good to hear.
> 
> > >  Are these all platform devices?
> > 
> > In the case above, yes. But I don't quite see how that makes a
> > difference. x86 has platform drivers too, they are the essence of the
> > mfd framework. Almost every architecture can have platform drivers,
> > just like almost every platform can have PCI devices. I have been
> > adding dependencies on X86_32 for PCI drivers recently, for example.
> > 
> > I'm very fine with USB drivers being architecture-agnostic. They really
> > are. But in practice a lot of PCI and platform drivers are only useful
> > of one architecture, of a few ones at best.
> 
> Why would PCI devices only be useful on one architecture?  PCI works on
> almost all arches that Linux supports, if it's a PCI card, it could be
> on any of those processors.  If it's a mini-pci, the chances are less,
> but still quite possible.

Many machines (arm) have PCI but not PCI slot. It would be good to use that information
to reduce ammount of config questions.

> > Huh, please, no. "Just say m if you don't know" was fine in the late
> > 90s, when Linux was mostly x86. You could afford including 3% of
> > useless drivers, and people working on other architectures said "no" by
> > default and only included the few drivers they needed.
> > 
> > But today things have changed. We have a lot of very active, mature
> > architectures, with a bunch of existing drivers and a batch of new
> > drivers coming with every new kernel version. Saying "m" to everything
> > increases build times beyond reason. You also hit build failures you
> > shouldn't have to care about, depmod takes forever, updates are slow as
> > hell. This is the problem I am trying to solve.
> 
> What is the build time difference you are seeing?  I do 'allmodconfig'
> builds all the time, with over 3000 modules.  The build works just fine
> on "modern" hardware.  Cutting out 100 modules might speed it up a bit,
> but really, is that a big deal overall?

Well, cutting 100 config questions would be worth it.

I am configuring kernels for N900. After kernel learns, it is n900, it would be possible
to ask very little questions: it has no ISA, no PCI and set of devices on i2c / platform
bus is well known and well defined...


> There are a lot of new devices out there, and we are dragging in tons of
> previously out-of-tree drivers in.  Look at the huge explosion of the
> IIO drivers that we now have, supporting hundreds of new types of
> sensors.  We have new bus types, coming from the work done by CERN and
> other research groups.  We have wacky co-processor boards, and odd huge
> iron controller boards.  All of these work on x86 platforms.
> 
> Yes lots of drivers are moving out of the arm SOC area into the
> "generic" part of the kernel, and that's a good thing.  Lots of those IP
> blocks are now showing up on x86 platforms as well, as that processor
> goes after the previously-arm-only markets (we have examples of that in
> the USB gadget area of the kernel).

It would be better to actually update our Kconfig when IP block moves into
new area then giving up and asking our users all the time...

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Generating .config from device tree [was Re: Hardware dependencies in Kconfig]

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

Hi!

> Ideally, the arch doesn't matter at all for a driver, only the
> infrastructure the driver depends on does.  So perhaps the

Actually, it would be nice if user was never asked for combination
that can be compiled, and kernel would support them, but there's no
such hardware.

For example, if I am configuring for Nokia N900, I pretty much know
all the devices -- not even USB host is officially supported, so this
machine is not extensible. Yet I'll have to answer about 1000
questions about config.

And ... we already have very accurate description of what hardware
Nokia N900 has -- in the device tree. Perhaps it would make sense to
generate hardware-dependend parts of config from device tree? [I'll
still need to answer questions like CONFIG_NFS but should
not have to answer CONFIG_DISPLAY_PANEL_SONY_ACX565AKM question.]

Anyway, script is attached, perhaps it is useful to someone. 

[And yes, I believe we should build CONFIG_FOO corresponds to
"ti,omap3-foo" database.]

Run it from linux directory, and modify 

        m.linux_path = "/data/l/linux-n900/"
        m.dtb_path = "arch/arm/boot/dts/omap3-n900.dtb"

to match your configuration.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: dtsconfig.py --]
[-- Type: text/x-python, Size: 2842 bytes --]

#!/usr/bin/python
#
# Scripts for automatic kernel configuration from dts
# 
# Copyright 2014 Pavel Machek <pavel@ucw.cz>
# Distribute under GPLv2+
#

import os
import re

class DtsParser():
    def __init__(m):
        m.linux_path = "/data/l/linux-n900/"
        m.dtb_path = "arch/arm/boot/dts/omap3-n900.dtb"

    def find_files(m, match):
        l = os.popen("find "+m.linux_path+" -name '"+match+"'").readlines()
        return map(lambda s: s.rstrip(), l)
        

    def find_compatible(m):
        dts = os.popen("dtc -I dtb "+m.dtb_path).readlines()
        compatibles = {}
        for line in dts:
            match = re.match(".*compatible = ([^;]*);", line)
            if not match:
                continue
            l = match.group(1)
            for s in l.split('",'):
                s = re.sub('^[" ]*', '', s)
                s = re.sub('"$', '', s)
                compatibles[s] = 1

        m.compatibles = compatibles


    def find_drivers(m):
        drivers = {}
        for fname in m.find_files("*.c"):
            for line in open(fname, "r").readlines():
                for c in m.compatibles:
                    if re.match('.*"'+c+'".*', line):
                        m.compatibles[c] = 2
                        if not fname in drivers:
                            drivers[fname] = []
                        drivers[fname] += [ line ]
        m.drivers = drivers

    def find_configs(m):
        configs = {}
        m.found_drivers = {}
        for fname in m.drivers:
            makefile = fname.rstrip("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.,_")
            makefile += "Makefile"
            basename = re.match("^.*/([a-zA-Z0-9-_,]*).c$", fname)
            if not basename:
                print "Can't find basename for ", fname
                continue
            basename = basename.group(1)
            print basename

            lines = open(makefile, "r").readlines()
            for l in lines:
                l = l.rstrip()
                c = re.match("^obj-\$\(([A-Z0-9_]*)\)[ 	]*\+= "+basename+".o$", l) 
                if c:
                    break
            if not c:
                print "Could not file config option for ", basename, " in ", makefile
                continue
            c = c.group(1)
            print "Have config option ", c
            configs[c] = fname
            m.found_drivers[fname] = c
        m.configs = configs

    def run(m):
        m.find_compatible()
        m.find_drivers()
        m.find_configs()

    def print_configs(m):
        for c in m.configs:
            print c
        for c in m.compatibles:
            if m.compatibles[c] != 2:
                print "Could not find driver for ", c
        
parser = DtsParser()
parser.run()
parser.print_configs()


#print parser.find_files("*.c")