[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finish
From: |
Svante Signell |
Subject: |
Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished |
Date: |
Fri, 15 Feb 2013 00:18:16 +0100 |
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)
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, (continued)
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Richard Braun, 2013/02/13
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Svante Signell, 2013/02/13
- Re: [PATCH, HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Ivan Shmakov, 2013/02/13
- Re: [PATCH, HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Svante Signell, 2013/02/13
- Re: [PATCH, HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Samuel Thibault, 2013/02/13
- Re: [PATCH, HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Samuel Thibault, 2013/02/13
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Samuel Thibault, 2013/02/14
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Samuel Thibault, 2013/02/14
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished,
Svante Signell <=
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Samuel Thibault, 2013/02/14
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Svante Signell, 2013/02/14
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Samuel Thibault, 2013/02/14
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Samuel Thibault, 2013/02/14
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Svante Signell, 2013/02/15
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Svante Signell, 2013/02/15
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Samuel Thibault, 2013/02/15
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Svante Signell, 2013/02/15
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Samuel Thibault, 2013/02/15
- Re: [PATCH,HURD][RFC] hurdselect: Step7x, almost complete rewrite finished, Svante Signell, 2013/02/18