Messages in this thread | | | Subject | Re: [PATCH 00/44 take 2] [UBI] Unsorted Block Images | From | Artem Bityutskiy <> | Date | Mon, 19 Feb 2007 19:07:46 +0200 |
| |
On Mon, 2007-02-19 at 09:33 -0500, Theodore Tso wrote: > It made it much, much, MUCH harder to review. Especially given that > the documentation was separated from the implementation. As I looked > at the implementation, there was no way to look and what it was > supposed to do without flipping back to a previous e-mail message and > losing my place.
I will send Build stuff as the last patch next time, thanks, point taken.
I just used different concept: one looks at declaration and the overall picture becomes clear because _there is_ documentation. One does not look at the implementation to grasp picture on surface.
But your point is fair. I assume _programmers_ look in .c first. Users may always generate a pdf. I will do what you advise.
May be a good compromise would be to have just brief comments at headers, and full specification at .c. I will think about this, thanks.
> > This reflects the way of my thinking. I see UBI as a set of units with > > defined interfaces. So I even physically split the interface description > > into files. I still think it is easier to grasp the architecture this > > way. > > Speaking as someone who was coming into it cold, it actually made it > far more difficult. Your units were too small, so that meant the > number of interfaces that were created as a result were huge! (Around > 20 _sets_ of interfaces, all of which had to be comprehended for what > should have been a relatively simple set of functionality!)
Why not? Some stuff may probably be merged. _Specific_ advices are welcome.
> And when you create that many interfaces, it adds inertia to changing > the interfaces later on, because it's sometimes not clear how many > users of the interface there really are. My general rule of thumb is > that if an interface only has one user, then it may be a good idea to > combine it with the user of that interface, and then make the > functions involved be a static, so that it becomes clear the only user > of that functoin is within that one file. You can take this too far, > and to extremes it doesn't work all that well, but the UBI layer has > gone waaaaaay off the deep end in terms of functional decomposition.
Well... I do not want any flame on this topic. It is about taste, trade-offs, compromises. It is difficult to provide _objective_ and killing arguments here. But I will think on this, point taken, thanks.
-- Best regards, Artem Bityutskiy (Битюцкий Артём)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |