Software interface design strategies (was: ... mount count ...)

[Ben Scott]

On Thu, Oct 8, 2009 at 6:08 PM, Bill McGonigle <bill at bfccomputing.com> wrote:
>  Mount Count:          36
> but if that becomes:
>  mount count:          36
> ... it's potentially fragile.
>> You just think the C struct way works better
> oh, yeah?

  The thing you're studiously ignoring is that when C structures don't
match, you end up reading or writing memory that isn't what you think.
 If you're lucky, that leads to an immediate core dump.  If you're not
so lucky, you corrupt stack or heap, and everything blows up later on
when you're not even thinking about that API call anymore.

  I fail to see how that's an improvement over not finding expected
text output, and detecting that immediately.  :)

> I'd venture that paths in a /proc or /sys filesystem are less likely to
> be tweaked for appearance than command output.

  I've certainly seen /proc change over the years, breaking all sorts of things.

>>   And it's not like /proc or /sys *aren't* giving you text output.  :)
>
> right, but the value is the least likely thing to break.

  Ibid.

  Your whole assumption seems to be that things are less likely to
change if they're enshrined in the kernel, and that's simply not true.
 :)

  The kernel and dump2fs are both C programs.  Both are FOSS.  Both
can be changed just by editing a text file and recompiling.  And both
are maintained by engineers.  "I know engineers.  They *love* to
change things."  ;-)

  Even more than those general tendencies, Linus has promised *not* to
keep the kernel API consistent over time.  His position is that the
stable API should be implemented in userland.

>>> > I'd have guessed this would be exposed in sysfs ...
>>   Just as bad as sticking it in /proc.  Just a different name.  :)
> sysfs has a semantic separation from procfs ...

  I know that.  :)  The point was, there's no need to put this code in
the kernel.

> It's the 'everything is a file' philosophy.

  And files are just bags of bytes.  Preferably holding text.  You
build the system by passing the bags between programs.

  My contention is: Whether you get the bag from a userland program or
a kernel subroutine via sysfs, you're still getting a bag of bytes
from a read() call.  Since there's no need to have this in the kernel,
it's better off in userland.

  I'll quote Doug McIlroy[1].  You've heard of him, right?  ;-)  He wrote:

"This is the Unix philosophy: Write programs that do one thing and do
it well. Write programs to work together. Write programs to handle
text streams, because that is a universal interface." [2]

"Expect the output of every program to become the input to another, as
yet unknown, program." [3]

[1] Via ESR: <http://catb.org/~esr/writings/taoup/html/ch01s06.html>
[2] Originally in /A Quarter-Century of Unix/, 1994, according to ESR.
[3] Originally in /The Bell System Technical Journal/, 1978, according to ESR.

-- Ben