Tag files and a decent editor are all one needs for full code navigation. The kernel makefile already has a tags target to make the tags file. Smaller files make for better logical isolation of functions, limiting visibilty/scope, and faster compilation of a file (but maybe at the expense of link time). That sort of isolation of functionality into smaller files also makes the code more digestable for someone new looking at it, IMO. Large files are good for a pile of stuff no one ever needs to look at again: well tested code that has an expected low rate of change in the future. Regards, Andy Jarod Wilson <jarod@xxxxxxxxxx> wrote: >On Wed, Sep 08, 2010 at 10:42:10AM -0300, Mauro Carvalho Chehab wrote: >> Em 07-09-2010 18:51, David Härdeman escreveu: >> > This patch merges the files which makes up ir-core and renames the >> > resulting module to rc-core. IMHO this makes it much easier to hack >> > on the core module since all code is in one file. >> > >> > This also allows some simplification of ir-core-priv.h as fewer internal >> > functions need to be exposed. >> >> I'm not sure about this patch. Big files tend to be harder to maintain, >> as it takes more time to find the right functions inside it. Also, IMO, >> it makes sense to keep the raw-event code on a separate file. > >There's definitely a balance to be struck between file size and file >count. Having all the relevant code in one file definitely has its >advantage in that its easier to jump around from function to function and >trace code paths taken, but I can see the argument for isolating the raw >event handling code a bit too, especially if its going to be further >expanded, which I believe is likely the case. So I guess I'm on the >fence here. :) > >> Anyway, if we apply this patch right now, it will cause merge conflicts with >> the input tree, due to the get/setkeycodebig patches, and with some other >> patches that are pending merge/review. The better is to apply such patch >> just after the release of 2.6.37-rc1, after having all those conflicts >> solved. > >The imon patch that moves mouse/panel/knob input to its own input device >should be possible to take in advance of everything else, more or less, >though I need to finish actually testing it out (and should probably make >some further imon fixes for issues listed in a kernel.org bugzilla, the >number of which escapes me at the moment). > >-- >Jarod Wilson >jarod@xxxxxxxxxx > >-- >To unsubscribe from this list: send the line "unsubscribe linux-media" in >the body of a message to majordomo@xxxxxxxxxxxxxxx >More majordomo info at http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n�����{��g����^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
