From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 74905828 for ; Wed, 26 Jun 2019 01:33:37 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id DF9029BDB8; Wed, 26 Jun 2019 11:33:35 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 088CD9BD79; Wed, 26 Jun 2019 11:33:05 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="SaKNDwUx"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 1F81A9BD79; Wed, 26 Jun 2019 11:33:03 +1000 (AEST) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) by minnie.tuhs.org (Postfix) with ESMTPS id 200969BD16 for ; Wed, 26 Jun 2019 11:33:00 +1000 (AEST) Received: by mail-io1-f54.google.com with SMTP id j6so1419596ioa.5 for ; Tue, 25 Jun 2019 18:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=910UVEKd7GCe3PUmxgaU9AxqiG832Es0BUgph3uWe/c=; b=SaKNDwUxqC4xBgFDsrwqWuaNWHUUt+5Xo7pXQ2j1JUKSlUvZ7HUUqshqYcaIWF4yYM STd5DEkWY0J1RsQ/X7E+D+3HGDWr8e9uFDF/LVFGQQHMsY5zHDB0eCgqnh1Jr88tKyg9 +2nNKFCZPNBqrxfYOE1qNyiCmOE+cQ5qiiek9pwVe36T7VNs0tleguHKlTeT2ECc0tBV lTVJnVAvYeYgqrvvPB9WoSaiaaizmmJbntEVZR7tfdNnnFdejTu5Ka6Ac0XVqQc9cLrp 2af6SZ9uVBgpNnrb4NPEoRDRwm5MttXbon0M8PQhVQeFG7RfgNKIBRPluun3xpgm0bMb odqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=910UVEKd7GCe3PUmxgaU9AxqiG832Es0BUgph3uWe/c=; b=ODiQdtuZawUQpD0Ll/kXH9R9MgOEjA/ItyRqohhkTcLG5ziobJWZkkrhKEUKDxx5yj zNHcexiLAwHIp+4mjKYytoXEOnddY5uknDePLSY8+TR3KeDs4Bl3cFO5K7PQfcEE0MUB rpyhHHTuEhhGX11+g6xytFTgQzdFtPv093XgY1zyz7GVgYqg4V2aDJUMTw4OpMmRBXR6 y4KCe8unsEmtUyPztoso2xB2ovHbwbzU4vzy5wUgTAYZPbkq1BRFIpEbxfoUYMmUiiGK +Z4RX75kTr5ElZbRcDR1t1TJzTEBm7SZ2pzHxtk62z5gYcasF77BXUKjn23UGwzuLPLe ycdw== X-Gm-Message-State: APjAAAVWga2eE+O1yIZmZv36Kw/0H7ofqGpRWGl3fi8FQWvGLhxIejxs 21xIJZrldHWPzb6+j00coSzQ/Sk66c0Ob3VDzJ5Lxg== X-Google-Smtp-Source: APXvYqyo5GqxB+f6IWl80LTpM7ZUUHtPwu5/2KAzhSmZLZe9LgX/aijoX/AZlBSIE84sk4RbB0c5w4PBbhx+6lCfpU8= X-Received: by 2002:a5e:c30f:: with SMTP id a15mr1941457iok.246.1561512779461; Tue, 25 Jun 2019 18:32:59 -0700 (PDT) MIME-Version: 1.0 References: <1561491205.19116.for-standards-violators@oclsc.org> <20190626004603.GG925@mcvoy.com> In-Reply-To: From: Noel Hunt Date: Wed, 26 Jun 2019 11:32:34 +1000 Message-ID: To: George Michaelson Content-Type: multipart/alternative; boundary="000000000000883833058c300695" Subject: Re: [TUHS] 4.1c bsd ptrace man entry ("ptrace is unique and arcane") X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000883833058c300695 Content-Type: text/plain; charset="UTF-8" I thought there was a filesystem in Ninth Edition called '/tbl' wherein various system related items could be read. I have never seen it in operation but I'm sure I saw it in the kernel code; it seemed to fulfill all the functions of the non-process related information that Linux dumps into /proc. Am I perhaps mistaken about this? On Wed, Jun 26, 2019 at 11:13 AM George Michaelson wrote: > The lack of consistency in what you can READ in /proc makes it hard to > believe its useful in the "wide" -but I am sure specific things get > benefit from it, as an abstraction which makes code simple because > "its a file" > > if you're WRITING into things in /proc, I think you own the pain be it > an ioctl() or anything else. > > I see occasional shell scripts about turning on and off meta-state for > SCSI or SAS as "cat 0 > > /dev/somedir/some-model-of-abstraction/some-disk" and while I applaud, > I also wince. So easy to go wrong.. > > As a long-term user and non-developer, I'm sort of half a believer, > half not. Maybe if it had emerged before the great Schism(s) it would > be more normal? sane? understandable? > > -G > > On Wed, Jun 26, 2019 at 11:04 AM ron minnich wrote: > > > > On Tue, Jun 25, 2019 at 5:46 PM Larry McVoy wrote: > > > > > > I'm curious what Rob and others think of the Linux /proc. It's string > > > based and it seems like it is more like /whatever_you_might_want. > > > > it's very handy but quite difficult to work with programatically. The > > output is convenient for humans to parse, not very nice for programs > > to parse. > > > > /proc on linux has no real standard way of outputting things. You get > > tables, tuples, and lists and some stuff I can't classify > > (/proc/execdomains, /proc/devices); and, in some cases, some files > > give you more than one type of thing. Units are not clear for many > > tables. > > > > /proc on linux has far more than just process information, including > > stuff that has nothing to do with processes (51 things on my current > > linux, e.g. /proc/mounts). > > > > Things are in many cases not self-describing, though lots of /proc > > have this issue. > > > > I do recall (possibly wrongly) at some point in the 2000s there was an > > effort to stop putting stuff in /proc, but rather in /sys, but that > > seems to have not worked out. /proc is just too convenient a place, > > and by convention, lots of stuff lands there. > > > > While I was at LANL we did experiment with having /proc come out as > > s-expressions, which were nicely self describing, composable, easily > > parsed and operated on, and almost universally disliked b/c humans > > don't read s-expressions that easily. So that ended. > > > > We've been reimplementing Unix commands in Go for about 8 years now > > and dealing with all the variance in /proc on linux was a headache. > > You pretty much need a different function for every file in /proc. > > > > And all that said, it's handy, so hard to complain about too much. > --000000000000883833058c300695 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I thought there was a filesystem in Ninth Edition called
=
'= ;/tbl' wherein various system related items could be read.
I have neve= r seen it in operation but I'm sure I saw it
in the kernel code; it se= emed to fulfill all the functions
of the non-process related information= that Linux dumps
into /proc.

Am I perhaps mistaken about this?

On Wed, Jun 26, 2019 at 11:13 AM George Michaelson <ggm@algebras.org> wrote:
The lack of consistency in what you= can READ in /proc makes it hard to
believe its useful in the "wide" -but I am sure specific things g= et
benefit from it, as an abstraction which makes code simple because
"its a file"

if you're WRITING into things in /proc, I think you own the pain be it<= br> an ioctl() or anything else.

I see occasional shell scripts about turning on and off meta-state for
SCSI or SAS as "cat 0 >
/dev/somedir/some-model-of-abstraction/some-disk" and while I applaud,=
I also wince. So easy to go wrong..

As a long-term user and non-developer, I'm sort of half a believer,
half not. Maybe if it had emerged before the great Schism(s) it would
be more normal? sane? understandable?

-G

On Wed, Jun 26, 2019 at 11:04 AM ron minnich <rminnich@gmail.com> wrote:
>
> On Tue, Jun 25, 2019 at 5:46 PM Larry McVoy <lm@mcvoy.com> wrote:
> >
> > I'm curious what Rob and others think of the Linux /proc.=C2= =A0 It's string
> > based and it seems like it is more like /whatever_you_might_want.=
>
> it's very handy but quite difficult to work with programatically. = The
> output is convenient for humans to parse, not very nice for programs > to parse.
>
> /proc on linux has no real standard way of outputting things. You get<= br> > tables, tuples, and lists and some stuff I can't classify
> (/proc/execdomains, /proc/devices); and, in some cases, some files
> give you more than one type of thing. Units are not clear for many
> tables.
>
> /proc on linux has far more than just process information, including > stuff that has nothing to do with processes (51 things on my current > linux, e.g. /proc/mounts).
>
> Things are in many cases not self-describing, though lots of /proc
> have this issue.
>
> I do recall (possibly wrongly) at some point in the 2000s there was an=
> effort to stop putting stuff in /proc, but rather in /sys, but that > seems to have not worked out. /proc is just too convenient a place, > and by convention, lots of stuff lands there.
>
> While I was at LANL we did experiment with having /proc come out as > s-expressions, which were nicely self describing, composable, easily > parsed and operated on, and almost universally disliked b/c humans
> don't read s-expressions that easily. So that ended.
>
> We've been reimplementing Unix commands in Go for about 8 years no= w
> and dealing with all the variance in /proc on linux was a headache. > You pretty much need a different function for every file in /proc.
>
> And all that said, it's handy, so hard to complain about too much.=
--000000000000883833058c300695--