Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 7 Nov 2001 17:25:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 7 Nov 2001 17:25:07 -0500 Received: from stingr.net ([212.193.33.37]:6405 "EHLO stingr.net") by vger.kernel.org with ESMTP id ; Wed, 7 Nov 2001 17:24:54 -0500 Date: Thu, 8 Nov 2001 01:24:52 +0300 From: Paul P Komkoff Jr To: Linux Kernel Mail List Subject: Re: PROPOSAL: /proc standards (was dot-proc interface [was: /proc Message-ID: <20011108012452.A14971@stingr.net> Mail-Followup-To: Linux Kernel Mail List In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Agent Orange X-Mailer: mIRC32 v5.91 K.Mardam-Bey X-RealName: Stingray Greatest Jr Organization: Stingray Software Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Replying to Ricky Beam: > And those who *will* complain that binary structures are hard to work with, > (you're idiots too :-)) a struct is far easier to deal with than text > processing, esp. for anyone who knows what they are doing. Yes, changes Just read the whole thread, and got my head explode. Let me reply to random picked msg. First, to these who know about kernel-user interaction in, for example, windows. Win32 API has functions, which fill structs, defined in SDK headers. Linux kernel is much more light-w ... or maybe for any other reason it does not have that functions. pity. they can achieve performance you need. and no need for parsing, yeah. (we also do have X, which implementation is much more slow than winNT gui). but. How much time you will parse a single integer ? Without any text around needs to be thrown away, optionally with 0x and considered it __int64 ? This is much better than current /proc, yeah ? Anyway, Linus will keep proc ASCII, and we don't have another Linus. So proposed standard for /proc - is a good idea. Let's get rid of progressbars, percent-o-meters with pseudographics. Maybe we should switch from single file, for ex, cpuinfo, to dir with many INDIVIDUAL files containing single number or feature-set in it. Splitting away parts that need to be formatted in-kernel and then parsed in-user maybe a good decision 'coz ... maybe they are rarely used ? Another point. Including formatting code in EVERY kernel part that resides in /proc maybe (as for me) a bad idea - so one can do simple interface, formatting functions, and switch modules to use them Another point is writable /proc files - but no one in this thread said something clever about it and ... maybe discuss it later ? - -- Paul P 'Stingray' Komkoff 'Greatest' Jr // (icq)23200764 // (irc)Spacebar PPKJ1-RIPE // (smtp)i@stingr.net // (http)stingr.net // (pgp)0xA4B4ECA4 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAjvptKwACgkQyMW8naS07KSA2QCgm0z0ICxmJxqjImrPMk7Denzx CjIAnRCQ6WYMXa0lOMFFyYoHJpZ0jRuy =8+oN -----END PGP SIGNATURE----- - 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/