I see no way to split the core part in smaller parts. It does not make sense
to merge only half of this for example.
The rest of the patch is a huge amount of makefile.in files, and some other
The patch as such could be splitted in several different ways, but again
it would not make sense to merge that gradually over time.
> Don't confuse the build system with the configuration system.
> Whilst they are somewhat intertwined, they are not dependant on each other.
I do not mix up the purpose of the two systems, but suggesting the
drivers.conf concept makes both systems rely on information in the same file.
Therefore I suggested a two step approach:
1) Let kbuild understand and accept the drivers.conf concept gradually
2) Let the configuration system accept the Drivers.conf concept gradually
With gradually I expect it to be on a directory basis.
> > IMHO it would also be plain stupid to put a lot of effort in
> > supporting the old makefile syntax, when the files are already converted.
> That effort has already been done. kbuild2.5 can live alongside the
> existing build system.
What exists now is two parrallel systems. This has the negative effect that
it fails to show how much old cruft can be removed from the kernel upon
acceptance of kbuild-2.5. As it is now kbuild-2.5 either modify some
existing files or add some new files.
It would be nice to see how much could be cleaned up from the kernel
upon acceptance of kbuild-2.5.
The makefiles that can be removed alone counts ~2700 lines.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/