public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <peterw@aurema.com>
To: Tim Bird <tim.bird@am.sony.com>
Cc: "Randy.Dunlap" <rddunlap@osdl.org>,
	Richard.Curnow@superh.com, ak@muc.de,
	Arjan van de Ven <arjanv@redhat.com>,
	aeb@cwi.nl, Jamie Lokier <jamie@shareable.org>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>,
	Albert Cahalan <albert@users.sourceforge.net>
Subject: Re: finding out the value of HZ from userspace
Date: Sat, 03 Apr 2004 08:05:00 +1000	[thread overview]
Message-ID: <406DE38C.8010502@aurema.com> (raw)
In-Reply-To: <406DB0B0.8060003@am.sony.com>

Tim Bird wrote:
> Peter Williams wrote:
> 
>>> It's not possible to change USER_HZ.  There are too many programs with
>>> the number hard-coded into the binary.
>>
>>
>> This is an argument that the tail should be allowed to wag the dog and 
>> is not really valid :-)
> 
> 
> It is an interesting, but untenable, position that the applications
> are the tail and the OS is the dog.  The OS exists to serve the 
> applications.
> The applications, are, after all what a user actually DOES with their 
> computer.

I guess wagging was a bad analogy.  I was thinking in terms of the 
kernel being the main entity and the programs being peripheral in the 
sense that the kernel can exist without the programs but the programs 
can't exist without the kernel.

> 
> It is possible that the current applications which use hardcoded USER_HZ 
> are
> not important enough, or are easy enough to fix, that the cost in 
> incompatibility
> is offset by the benefit of providing different behaviour for future 
> applications.

Yes, this is the real point is that the facilities provided by the 
kernel shouldn't be tailored/compromised to cope with the problems of a 
couple of buggy programs especially when fixing the programs would be 
trivial.  I don't think the importance of the program is an issue as I 
doubt that there is any program that is so important that its 
requirements dictate kernel design.

> 
> But breaking them for no good reason, and particularly while there is a
> migration path possible over time which does not break compatibility, 
> seems like
> a bad idea.

Far more important things than these programs have been "broken" by 
changes in the kernel (I know, I've had to cope with them getting 2.6.X 
kernels to work with Red Hat 9) but no one complains or suggests that 
the kernel should revert to its original behaviour.  Change is part of 
progress and has to be coped with not resisted for no good reason.

Peter
-- 
Dr Peter Williams, Chief Scientist                peterw@aurema.com
Aurema Pty Limited                                Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia  Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com


  reply	other threads:[~2004-04-02 22:08 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-16 16:14 finding out the value of HZ from userspace Albert Cahalan
2004-03-16 17:22 ` Richard Curnow
2004-03-20  9:56 ` Arjan van de Ven
2004-03-20 14:54   ` Albert Cahalan
2004-03-20 23:58     ` Peter Williams
2004-03-31 21:40       ` Randy.Dunlap
2004-03-31 23:46         ` Albert Cahalan
2004-04-01 15:54           ` Jamie Lokier
2004-04-01 16:01             ` Arjan van de Ven
2004-04-01 16:30               ` Jamie Lokier
2004-04-01 16:50                 ` Richard B. Johnson
2004-04-01 17:01                   ` Jamie Lokier
2004-04-01 21:27                   ` Michael Buesch
2004-04-02  0:16                   ` Peter Williams
2004-04-02  0:07                 ` Peter Williams
2004-04-02  0:39                   ` Jamie Lokier
2004-04-02  1:44                     ` Peter Williams
2004-04-02 18:28                       ` Tim Bird
2004-04-02 22:05                         ` Peter Williams [this message]
2004-04-01 16:12             ` Albert Cahalan
     [not found] <1zkOe-Uc-17@gated-at.bofh.it>
     [not found] ` <1zl7M-1eJ-43@gated-at.bofh.it>
     [not found]   ` <1zn9p-3mW-5@gated-at.bofh.it>
     [not found]     ` <1znj5-3wM-15@gated-at.bofh.it>
     [not found]       ` <1AaWr-655-7@gated-at.bofh.it>
2004-03-16  2:27         ` Andi Kleen
2004-03-16  5:53           ` Peter Williams
2004-03-16  6:16             ` Andi Kleen
2004-03-16 23:15               ` Peter Williams
2004-03-16 23:56                 ` Andi Kleen
2004-03-17  0:15                   ` Peter Williams
2004-03-16  9:16             ` Bernd Petrovitsch
2004-03-16 23:45               ` Peter Williams
     [not found] <michf@post.tau.ac.il>
2004-03-11 14:17 ` Micha Feigin
2004-03-13 17:24   ` Arjan van de Ven
2004-03-13 19:34     ` John Reiser
2004-03-13 19:38       ` Arjan van de Ven
2004-03-13 22:14         ` Micha Feigin
2004-03-13 22:32           ` Arjan van de Ven
2004-03-14  1:05             ` Micha Feigin
2004-03-14  1:49               ` Andrew Morton
2004-03-14 14:37                 ` Micha Feigin
2004-03-16  0:28         ` Peter Williams
2004-03-16  6:33           ` Arjan van de Ven
2004-03-16 23:38             ` Peter Williams
2004-03-20 10:22               ` Arjan van de Ven
2004-03-20 11:28                 ` Stefan Smietanowski
2004-03-20 11:41                   ` Arjan van de Ven
2004-03-20 23:58                     ` Peter Williams
2004-03-21  1:09                       ` Tim Schmielau
2004-03-21  1:30                         ` Peter Williams
2004-03-21  8:00                   ` Kai Henningsen
2004-03-21 10:32                     ` Stefan Smietanowski
2004-03-22 22:34                   ` Micha Feigin
2004-03-22 23:04                     ` Peter Williams
2004-03-25 17:40                       ` Jamie Lokier
2004-03-25 23:22                         ` Peter Williams
2004-03-27 13:31                           ` Jamie Lokier
2004-03-27 23:52                             ` Peter Williams
2004-03-28 12:16                               ` Jamie Lokier
2004-03-27 21:11                       ` Micha Feigin
2004-03-20 23:26                 ` Peter Williams
2004-03-13 21:19     ` tabris
2004-03-13 22:10     ` Micha Feigin
2004-03-13 22:41       ` Arjan van de Ven
2004-03-14  1:07         ` Micha Feigin
2004-03-14 18:26         ` John Reiser
2004-03-14  2:45   ` Horst von Brand
2004-03-14 14:39     ` Micha Feigin
2004-03-15  8:17     ` Jamie Lokier
2004-03-16 18:16       ` Mark Gross
2004-03-15 10:13     ` Richard Curnow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=406DE38C.8010502@aurema.com \
    --to=peterw@aurema.com \
    --cc=Richard.Curnow@superh.com \
    --cc=aeb@cwi.nl \
    --cc=ak@muc.de \
    --cc=albert@users.sourceforge.net \
    --cc=arjanv@redhat.com \
    --cc=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rddunlap@osdl.org \
    --cc=tim.bird@am.sony.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox