blob: 32cfd8ae04973523b3b900e9eaef2409c3cc68e2 [file] [log] [blame]
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<link rel=stylesheet type="text/css" href="style.css" title="style">
The linux-api mailing list
<form method="get" action="">
<table border=0 cellpadding=0 cellspacing=0 width="100%">
<td align="left">
<font size="-1">
Linux <em>man-pages</em>: &nbsp;
<a href="./index.html">home</a> |
<a href="./contributing.html">contributing</a> |
<a href="./reporting_bugs.html">bugs</a> |
<a href="./patches.html">patches</a> |
<a href="./download.html">download</a>
&nbsp; || &nbsp;
<a href="">git</a> |
<a href="">online pages</a></font>
<td align="right">
<input type="text" name="q" size=10 maxlength=255 value="">
<input type="hidden" name="sitesearch" value="">
<input type="submit" name="sa" value="Search online pages">
<h1>The linux-api mailing list</h1>
Following a session
(<a href="">Who own's the interface</a>)
led by Michael Kerrisk at the 2008 Linux Plumbers Conference,
the <em>linux-api</em> mailing list
(<span class="email"></span>)
was created as a forum to discuss
changes that affect the Linux programming interface</a>
(API or ABI).
Among other things, a primary goal of the list is to help
answer the question: <em>How do we even know when an interface has been
added or changed?</em>
Many people have an interest in the answer to that question,
maintainers of C libraries,
the <em>man-pages</em> project,
testing projects such as
<a href="">LTP</a>
<a href="">trinity</a>,
maintainers of tracing tools such as
<a href="">strace(1)</a>,
the <a href="">Linux Standard Base (LSB)</a>,
(possibly) other groups, such as the maintainers for the
<a href="">LinuxChanges</a>
page at,
and, of course, user-space programmers.
The difficulty of answering that question is a contributing factor
to many problems in the Linux API&mdash;for example,
insufficient design review before release
(with the consequence that mistakes in API designs
are recognized too late),
insufficient prerelease testing,
poor or late documentation,
and delays before kernel APIs are made
available via C libraries.
The kernel source file
<span class="pathname">Documentation/SubmitChecklist</span>
notes that all Linux kernel
<strong>patches that change userspace interfaces should be CCed to</strong>.
You would help many people by heeding that advice,
and in return your kernel patches might even see a bit more view
and get better documentation, faster.
Message for easy pasting into mail threads ;-):
[CC +=]
Since this is a kernel-user-space API change,
could you please CC linux-api@ (and also for any
future iterations of this patch series). The kernel source
file Documentation/SubmitChecklist notes that all Linux kernel patches
that change userspace interfaces should be CCed to, so that the various
parties who are interested in API changes are informed. For further information, see
<h2>Subscription and archive</h2>
To subscribe to the list, send a message containing the
following <em>body</em> to
<span class="email"></span>:
<pre> subscribe linux-api </pre>
Searchable archives of this list can be found on
<a href="">lore</a>.
<a href="">MARC</a>.
<!-- SITETRACKING.linux_man-pages -->
<!-- Start of StatCounter Code -->
<script type="text/javascript">
var sc_project=5618989;
var sc_invisible=1;
var sc_partition=60;
var sc_click_stat=1;
var sc_security="4f8507d7";
<script type="text/javascript"
class="statcounter"><a title="customisable counter"
target="_blank"><img class="statcounter"
src="" alt="customisable
counter" ></a></div></noscript>
<!-- End of StatCounter Code -->