From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 19:16:32 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 19:16:21 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:38539 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Thu, 3 Jan 2002 19:16:12 -0500 Date: Thu, 3 Jan 2002 19:02:19 -0500 From: "Eric S. Raymond" To: Joerg Schilling Cc: anderson@metrolink.com, hch@caldera.de, lsb-discuss@lists.linuxbase.org, lsb-spec@lists.linuxbase.org, linux-kernel@vger.kernel.org Subject: Re: LSB1.1: /proc/cpuinfo Message-ID: <20020103190219.B27938@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Joerg Schilling , anderson@metrolink.com, hch@caldera.de, lsb-discuss@lists.linuxbase.org, lsb-spec@lists.linuxbase.org, linux-kernel@vger.kernel.org In-Reply-To: <200201032355.g03Ntx911860@burner.fokus.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201032355.g03Ntx911860@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Fri, Jan 04, 2002 at 12:55:59AM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Joerg Schilling : > The way /proc works has been introduced by Plan 9 in the first half > of the 80s. What Linux added as an abuse of the /proc filesytem in > principle is a Plan 9 idea too. It makes sense to have something > similar, but please please _not_ inside the /proc tree. > > Sun is planning to have /sys with similar backgound in a future > version of Solaris so it wouls make sense to talk to the Solaris > kernel kackers to have a common way to go for the new /sys tree. Well, hell. If the "/proc is a blight on the face of the planet" ranting that I've been hearing is just about the *name* /proc, then let's separate the name issue from the content issue. The kind of non-per-process information that is now in /proc needs to still be there for many purposes; autoconfiguration is the one that is bugging me right now, but cluster management is just as important. If moving /proc/cpuinfo to /sys/cpuinfo means people will stop trying to make the cpuinfo information go away, then By all means let's move it. I want /sys/dmi, too. I'm willing to write up a proposal for /sys that would migrate the `unclean' /proc stuff over to ./sys, and I'm willing to write the kernel patches to implement the renaming. I'm motivated to attack this right now because it touches the work I'm doing on kernel autoconfiguration. (Copied to the linux-kernel mailing list because of a parallel argument happening there...) -- Eric S. Raymond The common argument that crime is caused by poverty is a kind of slander on the poor. -- H. L. Mencken From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 19:32:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 19:32:01 -0500 Received: from relay1.pair.com ([209.68.1.20]:34322 "HELO relay.pair.com") by vger.kernel.org with SMTP id ; Thu, 3 Jan 2002 19:31:57 -0500 X-pair-Authenticated: 24.126.75.67 Message-ID: <3C34F8C6.6B5C4C67@kegel.com> Date: Thu, 03 Jan 2002 16:35:18 -0800 From: Dan Kegel X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Joerg Schilling CC: anderson@metrolink.com, hch@caldera.de, lsb-discuss@lists.linuxbase.org, lsb-spec@lists.linuxbase.org, Rusty Russell , "linux-kernel@vger.kernel.org" Subject: Re: LSB1.1: /proc/cpuinfo In-Reply-To: <200201032355.g03Ntx911860@burner.fokus.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Joerg Schilling wrote: > ... > The way /proc works has been introduced by Plan 9 in the first half of the 80s. > What Linux added as an abuse of the /proc filesytem in principle is a Plan 9 > idea too. It makes sense to have something similar, but please please _not_ > inside the /proc tree. > > Sun is planning to have /sys with similar backgound in a future version of > Solaris so it wouls make sense to talk to the Solaris kernel kackers to have a > common way to go for the new /sys tree. FWIW, Rusty Russell is working on a replacement for /proc/sys in Linux; see http://lwn.net/2002/0103/a/proc.php3 I wonder if he's talked to the Solaris people about their /sys plans. > If you like to look for other ideas on how to retrieve the needed information > it makes sense to look at Solaris too. The reason is that Solaris uses "prtconf" > which is close to the device tree from the IEEE standard Boot loader. > > prtconf -p is giving exactly the IEEE device tree > > prtconf -p -v gives more verbose information. > > If you don't use -p you will see the kernel view of the device tree. > > On MacOS X which also uses the IEEE Boot architecture the same beast > will be shown via a 'ioreg -l' That's interesting stuff, thanks. - Dan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 19:57:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 19:57:03 -0500 Received: from leibniz.math.psu.edu ([146.186.130.2]:34018 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Thu, 3 Jan 2002 19:56:53 -0500 Date: Thu, 3 Jan 2002 19:56:51 -0500 (EST) From: Alexander Viro To: "Eric S. Raymond" cc: Joerg Schilling , anderson@metrolink.com, hch@caldera.de, lsb-discuss@lists.linuxbase.org, lsb-spec@lists.linuxbase.org, linux-kernel@vger.kernel.org Subject: Re: LSB1.1: /proc/cpuinfo In-Reply-To: <20020103190219.B27938@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 Jan 2002, Eric S. Raymond wrote: > Well, hell. If the "/proc is a blight on the face of the planet" ranting that > I've been hearing is just about the *name* /proc, then let's separate the > name issue from the content issue. It's more than just a name. a) granularity. Current "all or nothing" policy in procfs has a lot of obvious problems. b) tree layout policy (lack thereof, to be precise). c) horribly bad layout of many, many files. Any file exported by kernel should be treated as user-visible API. As it is, common mentality is "it's a common dump; anything goes here". Inconsistent across architectures for no good reason, inconsistent across kernel versions, just plain stupid, choke-full of buffer overruns... Fixing these problems will _hurt_. Badly. We have to do it, but it won't be fast and it certainly won't happen overnight. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 20:06:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 20:06:44 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:52619 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Thu, 3 Jan 2002 20:06:30 -0500 Date: Thu, 3 Jan 2002 19:52:07 -0500 From: "Eric S. Raymond" To: Alexander Viro Cc: Joerg Schilling , anderson@metrolink.com, hch@caldera.de, lsb-discuss@lists.linuxbase.org, lsb-spec@lists.linuxbase.org, linux-kernel@vger.kernel.org Subject: Re: LSB1.1: /proc/cpuinfo Message-ID: <20020103195207.A31252@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alexander Viro , Joerg Schilling , anderson@metrolink.com, hch@caldera.de, lsb-discuss@lists.linuxbase.org, lsb-spec@lists.linuxbase.org, linux-kernel@vger.kernel.org In-Reply-To: <20020103190219.B27938@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from viro@math.psu.edu on Thu, Jan 03, 2002 at 07:56:51PM -0500 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alexander Viro : > It's more than just a name. > a) granularity. Current "all or nothing" policy in procfs has > a lot of obvious problems. > b) tree layout policy (lack thereof, to be precise). > c) horribly bad layout of many, many files. Any file exported by > kernel should be treated as user-visible API. As it is, common mentality > is "it's a common dump; anything goes here". Inconsistent across > architectures for no good reason, inconsistent across kernel versions, > just plain stupid, choke-full of buffer overruns... > > Fixing these problems will _hurt_. Badly. We have to do it, but it > won't be fast and it certainly won't happen overnight. I'm willing to work on this. Is there anywhere I can go to read up on current proposals before I start coding? -- Eric S. Raymond When all government ...in little as in great things... shall be drawn to Washington as the center of all power; it will render powerless the checks provided of one government on another, and will become as venal and oppressive as the government from which we separated." -- Thomas Jefferson, 1821 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 3 Jan 2002 21:01:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 3 Jan 2002 21:01:38 -0500 Received: from svr3.applink.net ([206.50.88.3]:5129 "EHLO svr3.applink.net") by vger.kernel.org with ESMTP id ; Thu, 3 Jan 2002 21:01:32 -0500 Message-Id: <200201040200.g0420PSr029316@svr3.applink.net> Content-Type: text/plain; charset=US-ASCII From: Timothy Covell Reply-To: timothy.covell@ashavan.org To: Alexander Viro , "Eric S. Raymond" Subject: Re: LSB1.1: /proc/cpuinfo Date: Thu, 3 Jan 2002 19:56:46 -0600 X-Mailer: KMail [version 1.3.2] Cc: Joerg Schilling , anderson@metrolink.com, hch@caldera.de, lsb-discuss@lists.linuxbase.org, lsb-spec@lists.linuxbase.org, linux-kernel@vger.kernel.org In-Reply-To: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 03 January 2002 18:56, Alexander Viro wrote: > On Thu, 3 Jan 2002, Eric S. Raymond wrote: > > Well, hell. If the "/proc is a blight on the face of the planet" ranting > > that I've been hearing is just about the *name* /proc, then let's > > separate the name issue from the content issue. > > It's more than just a name. > a) granularity. Current "all or nothing" policy in procfs has > a lot of obvious problems. > b) tree layout policy (lack thereof, to be precise). > c) horribly bad layout of many, many files. Any file exported by > kernel should be treated as user-visible API. As it is, common mentality > is "it's a common dump; anything goes here". Inconsistent across > architectures for no good reason, inconsistent across kernel versions, > just plain stupid, choke-full of buffer overruns... > > Fixing these problems will _hurt_. Badly. We have to do it, but it > won't be fast and it certainly won't happen overnight. Talking from the SysAdmin point of view, procfs is one of the truly cool things which separates Linux from the others. I'd rather tune /proc/sys stuff than use sysctl or Solaris' funky /etc/system and ndd crap. It's the next best thing to "point and click" without going over to the dark side. Sure /system is a better name (extra typing becaue we can't have /sys/sys can we??). And while you all are at it, why not take a look at some of the naming conventions that BeOS makes too. I'm _not_ being sarcastic. Example1: Excellent devfs layout. Example 2: BeOS root directory is a ramfs off of which the other drives/filesystems are mounted. (I haven't thought this one out too much but I could image that it would make some things easier.) Example 3: Kernel Modules are in the directory: /boot/beos/system/add-ons/kernel Perhaps we could have directories something like: /boot/kernel /boot/grub /boot/lilo /dev using devfs ! /etc /home /system/config/sys /net /system/modules/kernelversion/ (modules in devfs similar tree) /system/info (for cpuinfo, ioports, meminfo, filesystems, etc.) /sbin (or even in /system/bin ???) /tmp /usr /var Example 3: BeOS moves /usr/local stuff to more of a per user configuration where each user has a $HOME/config directory. Of course, we would put things like .Xdefaults, kde, gnome, etc. directories here which vary according to user while still keeping /usr/local for all users. My ~/config contains things like "find ~/config -type d | hand edit some" config/add-ons/media/decoders config/add-ons/media/encoders config/add-ons/media/extractors config/add-ons/media/writers config/add-ons/net_server config/be/Applications config/be/Demos config/be/Preferences config/bin config/boot (Things my personal boot/login preferences) config/doc config/doc/postgresql config/doc/postgresql/html config/documentation config/etc config/fonts config/include config/include/openssl config/include/postgresql config/include/postgresql/lib config/include/postgresql/libpq config/lib config/lib/perl5 config/lib/perl5/5.00503 config/lib/perl5/site_perl config/lib/perl5/site_perl/5.005/BePC-beos config/man config/man/man1 config/servers config/settings config/settings/beos_mime config/settings/beos_mime/application config/settings/beos_mime/audio config/settings/beos_mime/image config/settings/beos_mime/message config/settings/beos_mime/text config/settings/beos_mime/video config/share config/share/postgresql config/ssl config/ssl/certs config/ssl/lib config/ssl/man config/ssl/man/man1 Of course, on heavily user subscribed systems, some sort of NT like COW technique might be nesc. if too many file duplications occur in the ~/config directories. Having a good /usr/local would prevent much of this growth, at least in theory. As would strict quotas. :-) Just some thoughts. -- timothy.covell@ashavan.org. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 03:18:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 03:18:17 -0500 Received: from codepoet.org ([166.70.14.212]:33551 "EHLO winder.codepoet.org") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 03:18:01 -0500 Date: Fri, 4 Jan 2002 01:18:02 -0700 From: Erik Andersen To: "Eric S. Raymond" Cc: linux-kernel Subject: Re: LSB1.1: /proc/cpuinfo Message-ID: <20020104081802.GC5587@codepoet.org> Reply-To: andersen@codepoet.org Mail-Followup-To: Erik Andersen , "Eric S. Raymond" , linux-kernel In-Reply-To: <20020103190219.B27938@thyrsus.com> <20020103195207.A31252@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020103195207.A31252@thyrsus.com> User-Agent: Mutt/1.3.24i X-Operating-System: Linux 2.4.16-rmk1, Rebel-NetWinder(Intel StrongARM 110 rev 3), 185.95 BogoMips X-No-Junk-Mail: I do not want to get *any* junk mail. Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu Jan 03, 2002 at 07:52:07PM -0500, Eric S. Raymond wrote: > Alexander Viro : > > It's more than just a name. > > a) granularity. Current "all or nothing" policy in procfs has > > a lot of obvious problems. > > b) tree layout policy (lack thereof, to be precise). > > c) horribly bad layout of many, many files. Any file exported by > > kernel should be treated as user-visible API. As it is, common mentality > > is "it's a common dump; anything goes here". Inconsistent across > > architectures for no good reason, inconsistent across kernel versions, > > just plain stupid, choke-full of buffer overruns... > > > > Fixing these problems will _hurt_. Badly. We have to do it, but it > > won't be fast and it certainly won't happen overnight. > > I'm willing to work on this. Is there anywhere I can go to read up on > current proposals before I start coding? I once wrote up /dev/ps and /dev/mounts drivers to eliminate proc for embedded systems (pointer available if you care). It was not warmly received, but I did form some opinions in the process. The main things to think about are 1) machine readability Generally speaking the kernel gods have decided that ASCII is good, binary structures and such are bad (think endiannes, nfs exports, and similar oddness). 2) typing Right now, if some /proc file prints a number, user space has to go digging about in the kernel sources to find what type that thing is -- int, uint, long, long long, etc. Cant tell without digging in the source. And what if someone then changes the type next week -- userspace then overflows. 3) field length When coping a string from /proc (say /proc/mounts), userspace has to go digging in the kernel source to find the field length. So if I copy things into a static buffer, I may be fine. Till someone changes the kernel to print out a bit more stuff. Then I've either got a buffer overflow (if I can't code) or a truncated string. Either way, its a problem. So what is needed is a kernelfs virtual filesystem that provides kernel info to user space. It needs a format that provides information as an organized directory hierarchy, which each directory and filename identifying the nature of the provided information. Files should provide information in ASCII with one value per file (to avoid all the tedious parsing), but also provides along with that bit of information type and or/length information. In some cases I guess we may also need more complex classes on information. (lists of key-value stuff for example). -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 07:33:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 07:33:04 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:50831 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 07:32:56 -0500 Date: Fri, 4 Jan 2002 07:19:40 -0500 From: "Eric S. Raymond" To: Erik Andersen , linux-kernel Subject: Re: LSB1.1: /proc/cpuinfo Message-ID: <20020104071940.A10172@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Erik Andersen , linux-kernel In-Reply-To: <20020103190219.B27938@thyrsus.com> <20020103195207.A31252@thyrsus.com> <20020104081802.GC5587@codepoet.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020104081802.GC5587@codepoet.org>; from andersen@codepoet.org on Fri, Jan 04, 2002 at 01:18:02AM -0700 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Erik Andersen : > I once wrote up /dev/ps and /dev/mounts drivers to eliminate proc > for embedded systems (pointer available if you care). It was not > warmly received, but I did form some opinions in the process. Sure, I'd like to see this work. > The main things to think about are > 1) machine readability > Generally speaking the kernel gods have decided that > ASCII is good, binary structures and such are bad (think > endiannes, nfs exports, and similar oddness). I agree with this decision. Binary structures would be false economy, trading away readability and flexibility for a marginal speed gain. > 2) typing > Right now, if some /proc file prints a number, user space > has to go digging about in the kernel sources to find > what type that thing is -- int, uint, long, long long, etc. > Cant tell without digging in the source. And what if > someone then changes the type next week -- userspace > then overflows. I'm not very worried about this. On modern machines int == long and the only case that's a potential headache is long long. If longer than int-size data is labeled, we'll be OK. > 3) field length > When coping a string from /proc (say /proc/mounts), > userspace has to go digging in the kernel source to > find the field length. So if I copy things into a > static buffer, I may be fine. I think the right answer to this is usually "don't use a language that has static buffers". :-) > So what is needed is a kernelfs virtual filesystem that provides > kernel info to user space. I don't care what it's called. I've seen `sys', 'system', and 'archfs' thrown around. > It needs a format that provides information as an organized > directory hierarchy, which each directory and filename > identifying the nature of the provided information. Files should > provide information in ASCII with one value per file (to avoid > all the tedious parsing), but also provides along with that bit > of information type and or/length information. > > In some cases I guess we may also need more complex classes on > information. (lists of key-value stuff for example). One value per *file*? That seems excessively fine-grained. Sometimes you want multiple values per file because the information is a functional unit for reporting to humans. -- Eric S. Raymond Americans have the will to resist because you have weapons. If you don't have a gun, freedom of speech has no power. -- Yoshimi Ishikawa, Japanese author, in the LA Times 15 Oct 1992 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 08:11:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 08:11:30 -0500 Received: from ns.suse.de ([213.95.15.193]:12293 "HELO Cantor.suse.de") by vger.kernel.org with SMTP id convert rfc822-to-8bit; Fri, 4 Jan 2002 08:11:18 -0500 To: "Eric S. Raymond" Cc: Erik Andersen , linux-kernel Subject: Re: LSB1.1: /proc/cpuinfo In-Reply-To: <20020103190219.B27938@thyrsus.com> <20020103195207.A31252@thyrsus.com> <20020104081802.GC5587@codepoet.org> <20020104071940.A10172@thyrsus.com> X-Yow: Am I elected yet? From: Andreas Schwab Date: Fri, 04 Jan 2002 14:11:16 +0100 In-Reply-To: <20020104071940.A10172@thyrsus.com> ("Eric S. Raymond"'s message of "Fri, 4 Jan 2002 07:19:40 -0500") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1.30 (ia64-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Eric S. Raymond" writes: |> I'm not very worried about this. On modern machines int == long You mean alpha, ia64, ppc64, s390x, x68-64 are not modern machines? Andreas. -- Andreas Schwab "And now for something Andreas.Schwab@suse.de completely different." SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 08:17:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 08:17:32 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:2448 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 08:17:21 -0500 Date: Fri, 4 Jan 2002 08:03:58 -0500 From: "Eric S. Raymond" To: Andreas Schwab Cc: Erik Andersen , linux-kernel Subject: Re: LSB1.1: /proc/cpuinfo Message-ID: <20020104080358.A11215@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Andreas Schwab , Erik Andersen , linux-kernel In-Reply-To: <20020103190219.B27938@thyrsus.com> <20020103195207.A31252@thyrsus.com> <20020104081802.GC5587@codepoet.org> <20020104071940.A10172@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from schwab@suse.de on Fri, Jan 04, 2002 at 02:11:16PM +0100 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Andreas Schwab : > |> I'm not very worried about this. On modern machines int == long > > You mean alpha, ia64, ppc64, s390x, x68-64 are not modern machines? Well, S390 certainly isn't! :-) If the PPC etc. have 32-bit ints then I stand corrected, but I thought the compiler ports on those machines used the native register size same as everybody else. -- Eric S. Raymond All forms of government are pernicious, including good government. -- Edward Abbey From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 08:25:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 08:25:21 -0500 Received: from ns.suse.de ([213.95.15.193]:16646 "HELO Cantor.suse.de") by vger.kernel.org with SMTP id convert rfc822-to-8bit; Fri, 4 Jan 2002 08:25:14 -0500 To: "Eric S. Raymond" Cc: Erik Andersen , linux-kernel Subject: Re: LSB1.1: /proc/cpuinfo In-Reply-To: <20020103190219.B27938@thyrsus.com> <20020103195207.A31252@thyrsus.com> <20020104081802.GC5587@codepoet.org> <20020104071940.A10172@thyrsus.com> <20020104080358.A11215@thyrsus.com> X-Yow: I'm also pre-POURED pre-MEDITATED and pre-RAPHAELITE!! From: Andreas Schwab Date: Fri, 04 Jan 2002 14:25:13 +0100 In-Reply-To: <20020104080358.A11215@thyrsus.com> ("Eric S. Raymond"'s message of "Fri, 4 Jan 2002 08:03:58 -0500") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1.30 (ia64-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Eric S. Raymond" writes: |> Andreas Schwab : |> > |> I'm not very worried about this. On modern machines int == long |> > |> > You mean alpha, ia64, ppc64, s390x, x68-64 are not modern machines? |> |> Well, S390 certainly isn't! :-) s390x is the new 64 bit architecture. |> If the PPC etc. have 32-bit ints then I stand corrected, but I thought the |> compiler ports on those machines used the native register size same as |> everybody else. On all those architectures the ABI used on Linux has int == 32 bits and long == 64 bits. LP64 is more usefull in most cases than ILP64. Andreas. -- Andreas Schwab "And now for something Andreas.Schwab@suse.de completely different." SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 08:27:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 08:27:21 -0500 Received: from ns.suse.de ([213.95.15.193]:24582 "HELO Cantor.suse.de") by vger.kernel.org with SMTP id ; Fri, 4 Jan 2002 08:27:07 -0500 Mail-Copies-To: never To: "Eric S. Raymond" Cc: Andreas Schwab , Erik Andersen , linux-kernel Subject: Re: LSB1.1: /proc/cpuinfo In-Reply-To: <20020103190219.B27938@thyrsus.com> <20020103195207.A31252@thyrsus.com> <20020104081802.GC5587@codepoet.org> <20020104071940.A10172@thyrsus.com> <20020104080358.A11215@thyrsus.com> From: Andreas Jaeger Date: Fri, 04 Jan 2002 14:27:01 +0100 In-Reply-To: <20020104080358.A11215@thyrsus.com> ("Eric S. Raymond"'s message of "Fri, 4 Jan 2002 08:03:58 -0500") Message-ID: User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Eric S. Raymond" writes: > Andreas Schwab : >> |> I'm not very worried about this. On modern machines int == long >> >> You mean alpha, ia64, ppc64, s390x, x68-64 are not modern machines? > > Well, S390 certainly isn't! :-) s390x - the zSeries - is newer ;-) > If the PPC etc. have 32-bit ints then I stand corrected, but I thought the > compiler ports on those machines used the native register size same as > everybody else. All the ports Andreas mentioned use 32-bit int and 64-bit longs. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 08:36:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 08:36:21 -0500 Received: from ns.caldera.de ([212.34.180.1]:55173 "EHLO ns.caldera.de") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 08:36:14 -0500 Date: Fri, 4 Jan 2002 14:36:04 +0100 Message-Id: <200201041336.g04Da4l15036@ns.caldera.de> From: Christoph Hellwig To: esr@thyrsus.com ("Eric S. Raymond") Cc: Erik Andersen , linux-kernel , Andreas Schwab Subject: Re: LSB1.1: /proc/cpuinfo X-Newsgroups: caldera.lists.linux.kernel In-Reply-To: <20020104080358.A11215@thyrsus.com> User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.13 (i686)) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In article <20020104080358.A11215@thyrsus.com> you wrote: > If the PPC etc. have 32-bit ints then I stand corrected, but I thought the > compiler ports on those machines used the native register size same as > everybody else. ANY Linux for to a 64bit machines use the LP64 programming model which means that long != int. Christoph -- Of course it doesn't work. We've performed a software upgrade. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 10:35:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 10:35:37 -0500 Received: from Expansa.sns.it ([192.167.206.189]:52754 "EHLO Expansa.sns.it") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 10:35:28 -0500 Date: Fri, 4 Jan 2002 16:34:53 +0100 (CET) From: Luigi Genoni To: "Eric S. Raymond" cc: Andreas Schwab , Erik Andersen , linux-kernel Subject: Re: LSB1.1: /proc/cpuinfo In-Reply-To: <20020104080358.A11215@thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 4 Jan 2002, Eric S. Raymond wrote: > Andreas Schwab : > > |> I'm not very worried about this. On modern machines int == long > > > > You mean alpha, ia64, ppc64, s390x, x68-64 are not modern machines? > > Well, S390 certainly isn't! :-) > > If the PPC etc. have 32-bit ints then I stand corrected, but I thought the > compiler ports on those machines used the native register size same as > everybody else. No, and the last troubles I had with reiserFS on sparc64 were exaclty because of this. in 2.4.17 s_properties is declared as unsigned int, while it should be an unsigned long. On x86 that is not aproblem at all, on all 64 bits CPUs reiserFS is unusable if you do not make a little patch. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 10:46:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 10:46:27 -0500 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:34064 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 10:46:11 -0500 Message-ID: <3C35CE40.836D3552@mandrakesoft.com> Date: Fri, 04 Jan 2002 10:46:08 -0500 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17-pre8 i686) X-Accept-Language: en MIME-Version: 1.0 To: esr@thyrsus.com CC: Erik Andersen , linux-kernel Subject: Re: LSB1.1: /proc/cpuinfo In-Reply-To: <20020103190219.B27938@thyrsus.com> <20020103195207.A31252@thyrsus.com> <20020104081802.GC5587@codepoet.org> <20020104071940.A10172@thyrsus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Eric S. Raymond" wrote: > I'm not very worried about this. On modern machines int == long I have been attempting to hammer this incorrect assumption out of people's brains for years, and have submitted many patches to Linus [1] over time, removing such crud from the kernel. Such an assumption is blatantly non-portable, rendering your code fragile. Jeff, longtime alpha owner [1] and other userland maintainers -- Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and one tongue. MandrakeSoft | - nomeansno From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 11:52:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 11:51:54 -0500 Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:33299 "EHLO the-village.bc.nu") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 11:51:46 -0500 Subject: Re: LSB1.1: /proc/cpuinfo To: esr@thyrsus.com Date: Fri, 4 Jan 2002 17:02:34 +0000 (GMT) Cc: schwab@suse.de (Andreas Schwab), andersen@codepoet.org (Erik Andersen), linux-kernel@vger.kernel.org (linux-kernel) In-Reply-To: <20020104080358.A11215@thyrsus.com> from "Eric S. Raymond" at Jan 04, 2002 08:03:58 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > If the PPC etc. have 32-bit ints then I stand corrected, but I thought the > compiler ports on those machines used the native register size same as > everybody else. Nobody I am aware of uses 64bit int default types on a 64bit platform. Its a waste of memory, bus bandwidth and instruction bandwidth. In almost all cases a 32bit int is quite adequate and since size_t can be 64bit when int is 32bit life works out nicely. Alan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 13:45:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 13:45:09 -0500 Received: from dsl254-112-233.nyc1.dsl.speakeasy.net ([216.254.112.233]:10129 "EHLO snark.thyrsus.com") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 13:45:00 -0500 Date: Fri, 4 Jan 2002 13:30:55 -0500 From: "Eric S. Raymond" To: Alan Cox Cc: Andreas Schwab , Erik Andersen , linux-kernel Subject: Re: LSB1.1: /proc/cpuinfo Message-ID: <20020104133055.C15889@thyrsus.com> Reply-To: esr@thyrsus.com Mail-Followup-To: "Eric S. Raymond" , Alan Cox , Andreas Schwab , Erik Andersen , linux-kernel In-Reply-To: <20020104080358.A11215@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Jan 04, 2002 at 05:02:34PM +0000 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Alan Cox : > Nobody I am aware of uses 64bit int default types on a 64bit platform. Its > a waste of memory, bus bandwidth and instruction bandwidth. In almost > all cases a 32bit int is quite adequate and since size_t can be 64bit when > int is 32bit life works out nicely. Thanks for the education. -- Eric S. Raymond A wise and frugal government, which shall restrain men from injuring one another, which shall leave them otherwise free to regulate their own pursuits of industry and improvement, and shall not take from the mouth of labor the bread it has earned. This is the sum of good government, and all that is necessary to close the circle of our felicities. -- Thomas Jefferson, in his 1801 inaugural address From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 14:35:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 14:35:14 -0500 Received: from codepoet.org ([166.70.14.212]:43784 "EHLO winder.codepoet.org") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 14:35:07 -0500 Date: Fri, 4 Jan 2002 12:35:06 -0700 From: Erik Andersen To: "Eric S. Raymond" , linux-kernel Subject: Re: LSB1.1: /proc/cpuinfo Message-ID: <20020104193506.GA15540@codepoet.org> Reply-To: andersen@codepoet.org Mail-Followup-To: Erik Andersen , "Eric S. Raymond" , linux-kernel In-Reply-To: <20020103190219.B27938@thyrsus.com> <20020103195207.A31252@thyrsus.com> <20020104081802.GC5587@codepoet.org> <20020104071940.A10172@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020104071940.A10172@thyrsus.com> User-Agent: Mutt/1.3.24i X-Operating-System: Linux 2.4.16-rmk1, Rebel-NetWinder(Intel StrongARM 110 rev 3), 185.95 BogoMips X-No-Junk-Mail: I do not want to get *any* junk mail. Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri Jan 04, 2002 at 07:19:40AM -0500, Eric S. Raymond wrote: > Erik Andersen : > > I once wrote up /dev/ps and /dev/mounts drivers to eliminate proc > > for embedded systems (pointer available if you care). It was not > > warmly received, but I did form some opinions in the process. > > Sure, I'd like to see this work. http://busybox.net/cgi-bin/cvsweb/busybox/examples/kernel-patches/ -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 16:45:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 16:45:02 -0500 Received: from twilight.cs.hut.fi ([130.233.40.5]:23904 "EHLO twilight.cs.hut.fi") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 16:44:48 -0500 Date: Fri, 4 Jan 2002 23:44:38 +0200 From: Ville Herva To: Alan Cox Cc: esr@thyrsus.com, linux-kernel Subject: Re: LSB1.1: /proc/cpuinfo Message-ID: <20020104234438.G1331@niksula.cs.hut.fi> In-Reply-To: <20020104080358.A11215@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from alan@lxorguk.ukuu.org.uk on Fri, Jan 04, 2002 at 05:02:34PM +0000 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 04, 2002 at 05:02:34PM +0000, you [Alan Cox] claimed: > > If the PPC etc. have 32-bit ints then I stand corrected, but I thought the > > compiler ports on those machines used the native register size same as > > everybody else. > > Nobody I am aware of uses 64bit int default types on a 64bit platform. Its > a waste of memory, bus bandwidth and instruction bandwidth. In almost > all cases a 32bit int is quite adequate and since size_t can be 64bit when > int is 32bit life works out nicely. I *think* long is 32 bit on Windows XP 64bit, though. I imagine they went with this hack to ensure backward compability or something. Can't tell for sure since the IA64 box lying around hasn't got a bootable Windows on it yet, just linux :). http://msdn.microsoft.com/library/en-us/win64/64bitwin_4d0z.asp?frame=true -- v -- v@iki.fi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 17:20:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 17:20:05 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:59397 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 17:19:49 -0500 To: linux-kernel@vger.kernel.org From: "H. Peter Anvin" Subject: Re: LSB1.1: /proc/cpuinfo Date: 4 Jan 2002 14:19:29 -0800 Organization: Transmeta Corporation, Santa Clara CA Message-ID: In-Reply-To: <20020104080358.A11215@thyrsus.com> <20020104234438.G1331@niksula.cs.hut.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Disclaimer: Not speaking for Transmeta in any way, shape, or form. Copyright: Copyright 2002 H. Peter Anvin - All Rights Reserved Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Followup to: <20020104234438.G1331@niksula.cs.hut.fi> By author: Ville Herva In newsgroup: linux.dev.kernel > > > > Nobody I am aware of uses 64bit int default types on a 64bit platform. Its > > a waste of memory, bus bandwidth and instruction bandwidth. In almost > > all cases a 32bit int is quite adequate and since size_t can be 64bit when > > int is 32bit life works out nicely. > > I *think* long is 32 bit on Windows XP 64bit, though. I imagine they went > with this hack to ensure backward compability or something. Can't tell for > sure since the IA64 box lying around hasn't got a bootable Windows on it > yet, just linux :). > > http://msdn.microsoft.com/library/en-us/win64/64bitwin_4d0z.asp?frame=true > Yes, 'doze uses int == long == 32 bits, long long == void * == 64 bits. This is because the 'doze API has a bunch of really bogus assumptions hard-coded in it, back from the days when "portable" in the M$ world meant "don't use int; use `short' for 16 bits and `long' for 32 bits." -hpa -- at work, in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 6 Jan 2002 22:08:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 6 Jan 2002 22:07:51 -0500 Received: from sydney1.au.ibm.com ([202.135.142.193]:23826 "EHLO haven.ozlabs.ibm.com") by vger.kernel.org with ESMTP id ; Sun, 6 Jan 2002 22:07:47 -0500 Date: Mon, 7 Jan 2002 12:05:45 +1100 From: Rusty Russell To: Alexander Viro Cc: esr@thyrsus.com, schilling@fokus.gmd.de, anderson@metrolink.com, hch@caldera.de, lsb-discuss@lists.linuxbase.org, lsb-spec@lists.linuxbase.org, linux-kernel@vger.kernel.org Subject: Re: LSB1.1: /proc/cpuinfo Message-Id: <20020107120545.57570c8a.rusty@rustcorp.com.au> In-Reply-To: In-Reply-To: <20020103190219.B27938@thyrsus.com> X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.10; powerpc-debian-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 3 Jan 2002 19:56:51 -0500 (EST) Alexander Viro wrote: > It's more than just a name. > a) granularity. Current "all or nothing" policy in procfs has > a lot of obvious problems. > b) tree layout policy (lack thereof, to be precise). > c) horribly bad layout of many, many files. Any file exported by As usual, Al has hit the highpoints (five lines vs. >> 1000 msgs of proc flamewars over time). At risk of boring regular readers, I shall expand: There is /proc, and /proc/sys. /proc is a pain to use in the kernel (seq_* made this better recently, but far from perfect), but is flexible. /proc/sys (aka sysctl) is easier to use, but a PITA for dynamic entries. The "manual formatting" nature of /proc entries has lead to (c) mentioned by Al. This can be alleviated by making the simplest method of exporting data the correct one (ie. more like /proc/sys). The tree layout issues are more complicated. In particular, the following namespaces should be equivalent: Boot command line: 3c509.debug=1 Module parameter: insmod 3c509 debug=1 proc entry: echo 1 > .../3c509/debug Finally, I consider the granularity issue a red-herring: if it's in the kernel, it should be in a logical location. Now, I have a sample patch for a simple "/proc/sys" replacement which follows the "one value per file" (similar to the current proc/sys) and "dynamic is easy" principle (required for widespread use). I also have module loader rewrite and boot param unification patches. http://www.kernel.org/pub/linux/kernel/people/rusty Important to realize that we will be stuck with the current interfaces for another stable kernel version (backwards compatibility is a WIP). Once Linus accepts general patches again I shall start pushing things to him. Hope that helps, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell.