From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761583AbYBLGYr (ORCPT ); Tue, 12 Feb 2008 01:24:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757896AbYBLGYj (ORCPT ); Tue, 12 Feb 2008 01:24:39 -0500 Received: from wa-out-1112.google.com ([209.85.146.179]:40282 "EHLO wa-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756102AbYBLGYi (ORCPT ); Tue, 12 Feb 2008 01:24:38 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NxT3p23mxC/JeBDB3t6Zo6J90g72+MtJU/4LKFVMoMcrRUKpRJJwFlSUTEriUpXwmwu1wrBbHS5d8nBmmIBrKODNf0t/ikXMxPawzjW2Y2msdkWtGFVR/K6bitvvY3BpyFqvN51mirrrDfsr5+8BfdxfVNIxBF1/ay4Hyr9fEfE= Message-ID: Date: Tue, 12 Feb 2008 01:24:37 -0500 From: "Scott Lovenberg" To: "Peter Teoh" Subject: Re: Documentation about sysfs/procfs entries Cc: LKML , kernelnewbies , "Rik van Riel" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <804dabb00802112123t774623b2n3e1e0a4addde1512@mail.gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Feb 12, 2008 1:17 AM, Scott Lovenberg wrote: > > > > > > > On Feb 12, 2008 12:23 AM, Peter Teoh wrote: > > > > > I was looking for documentation on the kstack_depth_to_print under /proc/sys/kernel, and I found it in Documentation/sysctl.txt (written by Rik). > > > > How about /proc/sys/net? or all other directories under /sys or /proc fs? > > > > Wouldn't it be useful to have a centralized store located in Documentation - properly structured, just a one-liner or two - on the reasons and explanations for each of these /proc or /sys parameters? And something to look for further details? > > > > Something of the following: > > > > |-- netfilter > > | |-- nf_conntrack_buckets:your explanation here > > | |-- nf_conntrack_checksum:your explanation here... > > | |-- nf_conntrack_count > > | |-- nf_conntrack_expect_max > > | |-- nf_conntrack_generic_timeout > > | |-- nf_conntrack_icmp_timeout > > | |-- nf_conntrack_log_invalid > > | |-- nf_conntrack_max > > | |-- nf_conntrack_tcp_be_liberal > > | |-- nf_conntrack_tcp_loose > > | |-- nf_conntrack_tcp_max_retrans > > | |-- nf_conntrack_tcp_timeout_close > > | |-- nf_conntrack_tcp_timeout_close_wait > > | |-- nf_conntrack_tcp_timeout_established > > | |-- nf_conntrack_tcp_timeout_fin_wait > > | |-- nf_conntrack_tcp_timeout_last_ack > > | |-- nf_conntrack_tcp_timeout_max_retrans > > | |-- nf_conntrack_tcp_timeout_syn_recv > > | |-- nf_conntrack_tcp_timeout_syn_sent > > | |-- nf_conntrack_tcp_timeout_time_wait > > | |-- nf_conntrack_udp_timeout > > | `-- nf_conntrack_udp_timeout_stream > > |-- nf_conntrack_max > > |-- token-ring > > | `-- rif_timeout > > `-- unix > > `-- max_dgram_qlen > > > > > > Alternatively, we can write a script to extract out the partial explanations/details from existing source code, based on some coding convention/style structure, and further hand-modification from there. (given the dynamic nature of the kernel code, this may be preferred?) > > > > > I was looking for exactly this about 2 weeks ago; I needed to look up the knobs for net and disk elevators, and had to jump all over the place. I assumed that such a thing should exist, but I didn't find it. I know I would personally benefit from this, and I'm sure many others would, too.