lkml.org 
[lkml]   [2006]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: -mm merge plans for 2.6.20

    * Roman Zippel <zippel@linux-m68k.org> 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 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/

    \
     
     \ /
      Last update: 2006-12-06 16:27    [W:2.616 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site