On Thu, 2013-02-14 at 23:49 +0100, Samuel Thibault wrote: > Svante Signell, le Wed 13 Feb 2013 07:24:46 +0100, a écrit : > > Problem is that he did not give any hints on _how_ to make the > > rewrite. If introducing the SELECT_ERROR had been discussed (or > > allowed to introduce) my solution would have been different too. > > As I mentioned yesterday, I couldn't have thought about it before seeing > your change. That's one of the places where "release often, release > early" applies. > > > > If it's easier for > > > us, it's also faster, and we can more effectively concentrate on > > > thinking about the big picture and the details. The second is to reduce > > > the likeliness of regressions. Please keep that in mind. > > > > Yes, the risk of regressions increase proportionally to the number of > > changes. But sometimes, introducing fixes for every corner case in an > > old design can create other bugs and/or side effects. > > Yes, but revamping everything is a much more risky approach, especially > when dealing with the most complex Unix call, select/poll, and without > so much C programming experience.
Well, I might say I have some C programming experience (and a number of other languages too, starting with basic and algol) but kernel programming is new, admitted. > > It's all a matter of hierarchical versus flat design methodology. > > The current code already has some hierarchy: some common select/poll > code, then a divergence, then common code, then divergence again, and > return. I find this easier to understand than moving code into a > function whose behavior has to be defined properly. Ok, I wanted it to be written differently, from my perspective, but I've only written application code before (and a lot of it). So for me embedding details in a function is preferred, to keep the level of details down (you don't see the woods because of all the trees) > Svante Signell, le Wed 13 Feb 2013 06:51:29 +0100, a écrit : > > On Wed, 2013-02-13 at 01:53 +0100, Samuel Thibault wrote: > > > Samuel Thibault, le Wed 13 Feb 2013 01:42:53 +0100, a écrit : > > > > I have rewritten your changes as seen below, > > - the rewritten code is faster than the old one. In the old code no > > delay is needed for the POLL case but is for the rewritten code. i.e. > > it's faster. (irrespective of moving timeouts to the server side or not) > > I don't understand what you mean. What delay are you talking about? > The only delay in by branch is the delay requested by the user. Well, with my code I need a timeout of 1ms for poll, with the old code I don't. > > But nobody dares (or is allowed to) to make major changes > > nowadays. Incremental development is not always the best way to make > > progress. > > Not always, yes. But with select/poll(), I can tell you it is: it's way > to easy to break it. Yes, I've seen that with different versions of my patched hurdselect.c... in the past. > > - regarding programming style: Let's assume you develop a microprocessor > > containing several millions of gates. Which solution is most easily > > developed, maintained, reviewed and bug fixed: A flat netlist design or > > a hierarchical design? Just ask the chip developers, like Intel and AMD. > > That's why keeping code factorized is important. This argument I cannot buy: Please explain factorized code. Hierarchical versus flat (yes this applies to SW too). And as a final note: My latest version of hurdselect.c works, irrespective of what gets implemented for Hurd ;.) (no big deal really, as long as functionality is according to POSIX)
