All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, Richard Henderson <rth@redhat.com>
Subject: Re: unregistered changes to the user<->kernel API
Date: Thu, 14 Jun 2001 13:52:44 -0400	[thread overview]
Message-ID: <3B28F9EC.D08D3D52@mandrakesoft.com> (raw)
In-Reply-To: <20010614191219.A30567@athlon.random> <3B28F376.1F528D5A@mandrakesoft.com> <20010614194419.A715@athlon.random>

Andrea Arcangeli wrote:
> 
> On Thu, Jun 14, 2001 at 01:25:10PM -0400, Jeff Garzik wrote:
> > They don't hurt but it's also a bad precedent - you don't want to add a
> > ton of CONFIG_xxx to the Linus tree for stuff outside the Linus tree.
> > disagree with this patch.
> 
> If tux will ever be merged into mainline eventually I don't think
> there's a value in defer such bit. Of course if tux will never get
> merged then I totally agree with you.

You're missing the point -- it's a bad precedent.

How many kernel forks and patches exist out there on the net?

Many of these patches will get merged eventually.  But it is a bad idea
to include bits of such into the Linus tree, when they are not used in
the Linus tree.

-Exceptions- to this policy should be carefully considered...  reserving
syscall and sysctl numbers certainly makes sense.  Bloating kernel_stat
with tons of unused numbers, some specific to web servers AFAICS, does
not make sense.

Tangent:  Why is this webserver-specific crap in kernel_stat anyway?  It
looks like there should be a separate per-cpu structure for webserver
statistics.

> +       unsigned int parse_static_incomplete;
> +       unsigned int parse_static_redirect;
> +       unsigned int parse_static_cachemiss;
> +       unsigned int parse_static_nooutput;
> +       unsigned int parse_static_normal;
> +       unsigned int parse_dynamic_incomplete;
> +       unsigned int parse_dynamic_redirect;
> +       unsigned int parse_dynamic_cachemiss;
> +       unsigned int parse_dynamic_nooutput;
> +       unsigned int parse_dynamic_normal;
> +       unsigned int complete_parsing;
> +
> +       unsigned int nr_keepalive_reqs;
> +       unsigned int nr_nonkeepalive_reqs;
> +#define KEEPALIVE_HIST_SIZE 100
> +       unsigned int keepalive_hist[KEEPALIVE_HIST_SIZE];

Even when merging Tux, I would hope Linus would not apply this
particular change.

	Jeff


-- 
Jeff Garzik      | Andre the Giant has a posse.
Building 1024    |
MandrakeSoft     |

  reply	other threads:[~2001-06-14 17:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-14 17:12 unregistered changes to the user<->kernel API Andrea Arcangeli
2001-06-14 17:16 ` Andrea Arcangeli
2001-06-14 17:21   ` Andrea Arcangeli
2001-06-14 17:32     ` Richard Henderson
2001-06-14 17:47       ` Andrea Arcangeli
2001-06-14 18:16         ` Andrea Arcangeli
2001-06-14 18:17         ` Richard Henderson
2001-06-14 18:10       ` Alexander Viro
2001-06-14 17:25 ` Jeff Garzik
2001-06-14 17:44   ` Andrea Arcangeli
2001-06-14 17:52     ` Jeff Garzik [this message]
2001-06-14 18:03       ` Andrea Arcangeli
2001-06-14 18:11         ` Alan Cox
2001-06-14 18:27           ` Andrea Arcangeli
2001-06-14 21:43           ` Albert D. Cahalan

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=3B28F9EC.D08D3D52@mandrakesoft.com \
    --to=jgarzik@mandrakesoft.com \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rth@redhat.com \
    --cc=torvalds@transmeta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.