* Roman Zippel <[email protected]> wrote:
> > > > If I understand it correctly, Roman wants clockevents to be usable
> > > > for other things aside hrtimer/dyntick, i.e. let other code request
> > > > unused timer event hardware for special purposes. I thought about
> > > > that in the originally but I stayed away from it, as there are no
> > > > users at the moment and I wanted to avoid the usual "who needs that"
> > > > comment.
> > >
> > > Nonsense, [...]
> >
> > why do you call Thomas' observation nonsense?
>
> What's the point of this question? [...]
the point of my question was what it said: to ask you why you called
Thomas' pretty fair observation 'nonsense'.
> [...] Your answer is/was in the "[...]" part.
meaning:
> > > [...] one obvious user would be the scheduler, [...]
but that is not a refutation of what Thomas said, at all. You say that
the scheduler /could/ use such a facility. What Thomas said was that
/there are no current users of such a facility/. It is a really simple
(and unconditionally true) observation from Thomas. Yes, we could change
other kernel code not directly related to high-res timers, but we chose
not to.
[ The word 'nonsense' is in general a negative descriptor and implies
that what Thomas said was 'obviously false' - while in reality what we
have is /at most/ a difference in opinion. I.e. even if our opinion
differs you shouldnt call his opinion "nonsense", unless you are
willing to prove that it's false - which you didnt do so far. I claim
that what Thomas said is /unconditionally true/, and i can prove it:
it is unconditionally true that such a new facility is not needed
by our code, and that no other kernel code is using it at the moment -
because the facility does not exist yet. If you misunderstood what
Thomas said then please point that out, or prove that his claims are
untrue - thanks. ]
> > Fact: there is no current user of such a facility. What we
> > implemented, high-res timers and dynticks does not need such a
> > facility.
>
> Fact: there _are_ users which need a timer facility (e.g. the
> scheduler).
this is something we are not contesting at all: that a new timer
facility /could/ be used by /other/ kernel code, which does /not/ use it
right now.
our point is simple: the code we add does not in itself necessiate the
new facility, hence we didnt add it. We didnt want to impact other
kernel code, just yet. We repeat: we agree (in theory) with such a
facility, but we wanted to do it separately.
> > we wholeheartedly agree that such a facility 'would be nice', and
> > 'could be used by existing kernel code' but we didnt want to chew
> > too much at a time.
>
> Maybe the existing code should have been cleaned up first?
yes, we'll do that, and we have a good track record doing such cleanups.
> Unfortunately the dynticks feature seems to more appealing than clean
> code...
i think this accusation against us is very unfair.
> > > [...] one obvious user would be the scheduler, [...]
> >
> > But cleaning up the scheduler tick was not our purpose with high-res
> > timers nor with dynticks. One of your previous complaints was that the
> > patches are too intrusive to be trusted. Now they are too simple?
>
> Would you please stop these personal attacks?
please point it out which portion of the above two sentences you
consider a personal attack - or if you cannot, please retract your
baseless accusation.
Fact: you did complain in the past about the complexity and/or
intrusiveness of our high-res timers patches - we've been working on
getting high-res timers upstream for more than a year now.
Fact: you did complain about unused facilities in past patches of ours,
and your feedback caused us significant extra work to remove those
facilities, just to reintroduce them later again.
(i can provide URLs and Message-IDs for these facts)
this time around we chose the minimalistic approach, we didnt add
anything that is not immediately needed, and we didnt want to increase
intrusiveness by "cleaning up" other code and changing it over to the
new facilities.
It cannot be had both ways: either we stay simpler and less intrusive,
or we go more generic but more intrusive.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
