From: SUGIOKA T. <su...@it...> - 2003-05-09 01:22:03
|
At 10:34 03/05/08 -0500, Paul Mundt <le...@li...> wrote: >On Thu, May 08, 2003 at 06:39:57PM +0900, SUGIOKA Toshinobu wrote: >> Currently, after scripts/treelink.sh has done, we see many unnecessary >files in >> arch/sh/kernel and include/asm-sh. >> >The only reason some of these files are not needed are because they're >left over garbage in mainline, once this stuff is synced back up, >we can remove a lot of files from the drop-in tree. > >The purpose of the drop-in tree in the first place was to only include >relevant files that needed local modification in order to be of use. If >most of this stuff _already_ sits in mainline, then there's no need to >track those files in the drop-in tree anymore. If someone needs to patch >something on the other hand, then those files can be moved backed in, >patched, and so forth. > >Especially since the drop-in tree already requires that it is applied >against a stock kernel version, we don't lose out on anything here. > >> This is because treelink.sh can not remove any files in stock kernel. >> >Again, most of these useless files will be removed from mainline, so >there's nothing to worry about here. Well, I know what drop-in tree is. And I think it's something inconvenient on some situation. (1) There seems no simple way to see which files should be removed from the stock kernel, so it's a bit hard to create complete patch against stock kernel from drop-in tree. (2) We can not automatically detect if these incorrect files are included in some source file by mistake, because compiler may not complain. (3) Some one who want to analyze the kernel source of sh-port might be confused by these useless files. (4) Once kernel maintainer synchronized stock kernel to our CVS tree, should we remove almost all files from CVS tree ?, and soon in the next kernel version, should some files be restored and modified ? Do you really want to do this ? I don't want to accept these inconveniences. We could maintain whole arch/sh and include/asm-sh with a few transfer size penalty. It should be much better IMHO. ---- SUGIOKA Toshinobu |