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

[Bill McGonigle]

On 10/08/2009 07:10 PM, Ben Scott wrote:

>   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.

The thing you're studiously ignoring is that I never did and never would
advocate such a solution. :)

>   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.

I have to admit, I don't know how much sysfs semantics have changed
since it was introduced.  I should definitely try some of my software on
older distros to see what happens.

>   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.

sysfs is supposed to be that bridge to userland, though, so you don't
need to keep querying kernel data structures, which are bound to break.
 There are things in sysfs that aren't exposed in FOTS software, so at
that point you're left either writing a c-stub for your text processing
language (and maintaining that), or using sysfs.  From what I've seen
the C API changes more quickly and is generally harder to make bug-free.
 Breakage in both cases is certainly inevitable at some point.

>   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.

The feature here is that when a kernel change is made, the sysfs
exposure is changed at the same time by the kernel developer; there
would be lag to getting the userland app updated for the new kernel
datastructures.  If you're on a long-term support distro with somebody
else doing that work, not so much of an issue.

-Bill

-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.603.448.4440
Email, IM, VOIP: bill at bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle