Chris's Wiki :: blog/programming/RelativeEncapsulation Commentshttps://utcc.utoronto.ca/~cks/space/blog/programming/RelativeEncapsulation?atomcommentsDWiki2009-05-30T17:33:59ZRecent comments in Chris's Wiki :: blog/programming/RelativeEncapsulation.By Chris Siebenmann on /blog/programming/RelativeEncapsulationtag:CSpace:blog/programming/RelativeEncapsulation:28eb693fe05d2e5ae107563c6d4a1c08c3942a1dChris Siebenmann<div class="wikitext"><p>Given an existing non-C language environment and a just-introduced
C library call, the former often cannot use the latter without you
doing considerable work (often work that steps outside the language,
sometimes very far outside the language). In some cases it may even
be impossible to do this, because the information you need to call
the C library function is not exposed.</p>
<p>(Consider a new C function involving stdio in an environment where
the language does not expose the <code>FILE *</code>'s it uses inside its own
standard IO package. Not exposing them is even good programming
practice.)</p>
<p>That the API to access information from a language is to 'open' 'files'
does not mean that the language has to implement this API by making
OS calls to open and read real files (and thus has to run on an OS where
those files are available). We are conditioned to think of APIs as
function calls and file access as file access, but this is not
a state of affairs that is mandated by the universe.</p>
<p>I believe that Plan 9 demonstrates the power of using real files as a
large part of your API, which is why I would like to see more of it.
As for ioctls et al, they have serious problems that the Linux kernel
people routinely discuss. In fact I believe that these days the Linux
kernel people have basically stopped accepting new ioctls and ioctl
based APIs, and now tell people to provide sysfs based interfaces.</p>
</div>2009-05-30T17:33:59ZFrom 82.181.217.186 on /blog/programming/RelativeEncapsulationtag:CSpace:blog/programming/RelativeEncapsulation:6ed15bdc31a2fac14a6aee5bdea9b5d1cccab817From 82.181.217.186<div class="wikitext"><p>Few things.</p>
<p>The /proc-interface is a so-called Linux'ism and should therefore be left as such (if we ignore Plan9 as a research operating system). It is a start of an end for an interpreted language when its standard libraries tie themselves to such interfaces. Wasn't the <em>raison d'etre</em> of interpreted languages the exact opposite?</p>
<p>Perhaps I look things from a too different perspective, but I don't quite understand your comment about APIs and libraries. How again do you retrieve kernel data from userspace without using a system call (a "library")? How can you not call C functions when practically all interpreters are written in C? If this is impossible, shouldn't this be understood as a limitation of interpreted languages in the context of system programming instead of understanding the system as a limiting factor? Why interpreted languages should be used as system programming languages when they were <em>not</em> designed to be ones?</p>
<p>I have always had a big distaste of the /proc-interface and the usage of it in the Linux kernel. It has become a free dumpyard to which every imaginable interface and driver is free to export whatever is deemed as necessary. This critique is hardly unique among Linux kernel developers.</p>
<p>My critique had nothing to do with "reading and writing files". We have always had several ways to achieve this from the perspective of a kernel.</p>
<p>The irony is obviously visible in your comment about "reading and writing" kernel data from userspace. The /proc-interface has started to replace the older and much better structured sysctl-inteface (at least as a usage scenario where people change the kernel dynamically by "echoing" to some knob). Somehow also, for an example, good-old characteristic devices and ioctls are just not as "cool" as the /proc-interface, even though these would be much better suited for "language-independent" implementations.</p>
<p>Two cents and few more.</p>
</div>2009-05-30T09:17:43ZBy Chris Siebenmann on /blog/programming/RelativeEncapsulationtag:CSpace:blog/programming/RelativeEncapsulation:6036354bdf15ca946ae65a2f6e567820cc86221fChris Siebenmann<div class="wikitext"><p>I disagree. I strongly believe that as many APIs as possible should be
exposed in language-independent ways, and on Unix-like systems today
that means that a /proc-like interface is the right way. Everyone can
read and write files; not everyone can call specific language libraries.</p>
<p>(And with some work, reading and writing files can be a perfectly good
and portable API too. It is just fashionable these days to cast APIs as
library function calls, partly because we have better tools for writing
APIs that way.)</p>
</div>2009-05-30T06:24:28ZFrom 82.181.217.186 on /blog/programming/RelativeEncapsulationtag:CSpace:blog/programming/RelativeEncapsulation:bd53c88db3921816995ce0f5f483b56e0396ca66From 82.181.217.186<div class="wikitext"><p>That is the great benefit of C: it actually offers portability instead of the pseudo-portability of many interpreted languages often advertised as portable. (Yes, I am thinking of Java here.)</p>
<p>For the same reason I recommend that everyone should stay away from the /proc-interface. It is a ugly hack even in the Linux world.</p>
<p>Finally, it is a sad state of affairs that a portable program has started to refer to a program that runs both on Ubuntu and on Fedora (imagine that!). For us old-timers a portable program has to run both on Linux and on AIX as well as on x86 and on SPARC. Increasingly we are a minority and I believe this has started to show also in the quality of code (or the lack thereof).</p>
</div>2009-05-29T14:59:16Z