From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Message-Id: <200111090515.fA95F3g167348@saturn.cs.uml.edu>
Subject: Re: PROPOSAL: /proc standards (was dot-proc interface [was: /proc
To: linux-kernel@alex.org.uk
Date: Fri, 9 Nov 2001 00:15:03 -0500 (EST)
Cc: acahalan@cs.uml.edu (Albert D. Cahalan),
        viro@math.psu.edu (Alexander Viro), jfbeam@bluetopia.net (Ricky Beam),
        roy@karlsbakk.net (Roy Sigurd Karlsbakk),
        linux-kernel@vger.kernel.org (Linux Kernel Mail List)
In-Reply-To: <964381385.1005245622@[195.224.237.69]> from "Alex Bligh - linux-kernel" at Nov 08, 2001 06:53:43 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

Alex Bligh - linux writes:
> [Albert Cahalan]

>> Design the kernel to make doing this difficult.
>> Define some offsets as follows:
>> 
>> # define FOO_PID 0
>> # define FOO_PPID 1
>> 
>> Now, how is anyone going to create "an extra inserted DWORD"
>> between those? They'd need to renumber FOO_PPID and any other
>> values that come after it.
>
> For instance, take the /proc/mounts type example, where
> each row is a sequence of binary values. Someone decides
> to add another column, which assuming it is a DWORD^W__u64,
> does exactly this, inserts a DWORD^W__u64 between the
> end of one record and the start of the next as far a
> poorly written parser is concerned.

That would be a botched design to begin with.

Each row becomes a separate binary file. They are distinct
records anyway. Splitting by column would be a poor choice.

> The brokenness is not due to the distinction between ASCII
> and binary. The brokenness is due the ill-defined nature
> of the format, and poor change control.

ASCII encourages ill-defined formats and poor change control.
People make assumptions about what is valid.
-
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/