On 10/28/2016 05:43 PM, Andrew Rybchenko wrote: > On 10/28/2016 03:33 PM, Thomas Monjalon wrote: >> 2016-10-28 13:50, Andrew Rybchenko: >>> The only thing which comes to my mind is to split libefx import on >>> subsystem >>> basis (few files per subsystem). It is artificial and added files will >>> be abandoned >>> until the patch which adds them into build. It could be something like: >>> 1. External interfaces definition >>> 2. Internal interfaces definition >>> 3. Registers definition (hardware interface) >>> 4. Management CPU interface definition (it is one file, but still >>> big >>> 650K) >>> 5. Management CPU interface implementation >>> and so on for NIC global controls, interrupts, event queue, transmit, >>> receive, >>> filtering etc. >> Yes it is artificial. >> The most valuable would be a transversal logical split, kind of feature >> per feature, in order to explain how the device works. > > I'm not the main author of the libefx and personally would consider it > very useful. > From the other hand I understand that it is a huge amount of work to > make it. > >> Such commit is also the opportunity to explain acronyms and so on. > > Good. We'll go this way and 'll do my best to make it useful to > understand > overall structure of the code and how the device works.
Now we have a split of the base driver import in big feature steps. The base driver is split into 28 patches. Just only 1 patch exceeds 300K boundary (which add MCDI definitions header). Before submitting 56 patches I'd like to double-check that checkpatch.pl errors (for example, because of assignments in the 'if' condition, parenthesis around return value) is not a show-stopper for base driver import. Andrew.
