Re: compat-drivers wishlist

[Johannes Berg <johannes@sipsolutions.net>]

On Thu, 2013-03-28 at 15:15 -0700, Luis R. Rodriguez wrote:

> > 1) Ability to copy only some drivers.

> Seems reasonable. Maybe admin-update can read your own .config

This is a tricky proposition, see below & my other mail on Kconfig
thoughts.

> GNU patch could use some love. 

I'd hate to have to rely on a modified version of that :-)

FWIW, I think there's a python library to apply (unified) patches, if we
want to get fancy.

> See commit 4a1a94f93 on compat-drivers.

Ah, what's that for? Refreshing patches? I've never seen dependencies in
the compat patches so mostly I refresh manually, but yeah, the refresh
part is something I'd have to think about. Though, to be honest, when
you can just blow away your output directory and try again I'm not too
worried about this. Trying to apply the patches could just leave it in
the state you're in, and then you modify them until it works?

> Maybe we need a context patch parser that given a .config will only
> apply patches for the desired files. For this to work we'd need a
> mapping of CONFIG_FOO symbols to respective driver path files regexps.

Even assuming we do have such a mapping, I think it's the wrong approach
and causes a chicken-and-egg problem.

As I wrote in my other mail, you don't have a .config file before you
know the target kernel. This is because, for example, there's no way to
know if PCI is enabled in the target kernel, and thus sometimes you get
PCI drivers and sometimes not. Also I think maintenance and driver split
is not usually per Kconfig symbol but per directory. There are many more
Kconfig symbols, after all.

Also above you said you could do the source copying (or pruning) based
on the .config file. This has the exact same issue, I'd rather have the
copying or pruning be based on directories.

Basically I'm saying the .config file only exists on the target build
system, while the selective copying/pruning needs to be done on the
tarball creation system.

> > 4) Kconfig.

> I think its possible to remove not desired source code based on
> reading .config.

See above.

Oh, another issue I haven't addressed is default configurations, but I
think that's easy to do by providing something like the kernel's
defconfig.

johannes