Add two new ideas suitable for SoC projects: update the USB stack, and
in-kernel linux emulation for device drivers. Submitted by: luigi
This commit is contained in:
Murray Stokely
parent
181fe4144e
commit
0f14658f84
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/www/; revision=29764
1 changed files with 109 additions and 33 deletions
|
|
@ -15,7 +15,7 @@ Ideas//EN"
|
|||
<ideas>
|
||||
<cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
|
||||
<cvs:keyword name="freebsd">
|
||||
$FreeBSD: www/en/projects/ideas/ideas.xml,v 1.5 2007/03/10 10:12:44 joel Exp $
|
||||
$FreeBSD: www/en/projects/ideas/ideas.xml,v 1.6 2007/03/11 06:58:12 murray Exp $
|
||||
</cvs:keyword>
|
||||
</cvs:keywords>
|
||||
|
||||
|
|
@ -121,6 +121,38 @@ Ideas//EN"
|
|||
<category>
|
||||
<title>Kernel</title>
|
||||
|
||||
<idea id="setproctitle" class="soc">
|
||||
<title>Avoiding syscall overhead</title>
|
||||
|
||||
<desc>
|
||||
<p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>
|
||||
|
||||
<p>setproctitle() calls are a serious
|
||||
performance bottleneck in a default pgsql configuration (they are
|
||||
called at least once per query, which might be thousands of times per
|
||||
second - I measured a performance impact of about 33% on sysbench).</p>
|
||||
|
||||
<p>One idea for avoiding the syscall (and global sysctl lock) overhead
|
||||
for this kind of thing would be a memory page shared between kernel
|
||||
and userland which libc could read/write to access things like the
|
||||
process title. There are potentially many other data values that
|
||||
could be optimized by a similar method. This is presumably a well
|
||||
established technique in other OSes.</p>
|
||||
|
||||
<p>This project requires mentoring/review/planning with someone with
|
||||
significant VM experience to make sure this approach
|
||||
works properly. Done incorrectly, this could result in fairly
|
||||
massive security holes, performance issues (perhaps not visible in
|
||||
simple benchmarks), etc.</p>
|
||||
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Strong knowledge of C.</li>
|
||||
<li>Understanding of kernel VM.</li>
|
||||
</ul>
|
||||
</desc>
|
||||
</idea>
|
||||
|
||||
<idea id="cpuusage">
|
||||
<title>CPU usage display in top</title>
|
||||
|
||||
|
|
@ -256,6 +288,39 @@ Ideas//EN"
|
|||
</ul>
|
||||
</desc>
|
||||
</idea>
|
||||
<idea id="kernel-linuxemu" class="soc">
|
||||
<title>Extending the in-kernel linux emulation layer</title>
|
||||
|
||||
<desc>
|
||||
<p><strong>Technical contact</strong>: <a href="mailto:luigi@FreeBSD.org">Luigi Rizzo</a></p>
|
||||
|
||||
<p>Recently, a project was started to let linux device drivers
|
||||
compile on FreeBSD through an in-kernel emulation layer, which
|
||||
implements part of the linux kernel API on top of the FreeBSD
|
||||
kernel API. The initial implementation was good enough to
|
||||
support a few USB webcam drivers, and is documented
|
||||
<a
|
||||
href="http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html">here</a>.</p>
|
||||
|
||||
<p>The goal of this project is to extend the emulation layer
|
||||
to cover more of the linux kernel API. Two areas that need
|
||||
further work are the API used by network device drivers (e.g.
|
||||
many USB wired and wireless device drivers), and the API used
|
||||
by memory-mapped devices and drivers (e.g. analog or DVB video
|
||||
acquisition cards, both USB and PCI).</p>
|
||||
|
||||
<p>A Summer of Code applicant would be required to choose a significant set of
|
||||
extensions to the existing work (e.g. one of those indicated
|
||||
above), and select at least two linux device drivers to be
|
||||
ported to FreeBSD using the newly implemented functions.</p>
|
||||
|
||||
<p>Before the start of the project a Summer of Code applicant is expected to
|
||||
have studied the above URL and understood the emulation technique
|
||||
used, and to have/acquire access to at least some of the hardware
|
||||
involved, so that actual functionality tests can be performed
|
||||
in addition to the compile tests.</p>
|
||||
</desc>
|
||||
</idea>
|
||||
|
||||
<idea id="ktrace">
|
||||
<title>Extend ktrace/kdump output</title>
|
||||
|
|
@ -354,6 +419,49 @@ Ideas//EN"
|
|||
</desc>
|
||||
</idea>
|
||||
|
||||
|
||||
<idea id="usb-update" class="soc">
|
||||
<title>Improving the USB stack in FreeBSD</title>
|
||||
|
||||
<desc>
|
||||
<p><strong>Technical contact</strong>: <a href="mailto:luigi@FreeBSD.org">Luigi Rizzo</a></p>
|
||||
|
||||
<p>The USB stack in FreeBSD suffers from a few problems, including
|
||||
lack of functionality (e.g. isochronous support for USB2 devices),
|
||||
lack of documentation (most of the code is undocumented and
|
||||
derives from other BSD implementations), lack of support (there
|
||||
is not, to our knowledge, active development of the stack),
|
||||
and the fact that it is still running under the Giant lock.</p>
|
||||
|
||||
<p>There is an alternate USB stack under development but it also
|
||||
suffers from its own share of problems: while it supports
|
||||
isochronous transfers for USB2 and does not run under Giant, it is
|
||||
also almost completely undocumented, and it exports a different API
|
||||
from the current one, which in turn causes portability problems for
|
||||
device drivers that run on top of USB. Additionally, it is not in
|
||||
widespread use.</p>
|
||||
|
||||
<p>The goal of this project is to improve the FreeBSD stack in one
|
||||
of the following ways:</p>
|
||||
|
||||
<ul>
|
||||
<li>Add documentation and isochronous USB2 transfers to the existing
|
||||
driver. Documentation also includes a detailed description of the
|
||||
locking requirements to ease the move to a different locking
|
||||
architecture;</li>
|
||||
<li>Add documentation and a compatibility layer to the 'new' usb
|
||||
stack, and verify that the basic functionality is preserved for
|
||||
widely used drivers (umass, mouse, keyboard, etc.).
|
||||
This work will likely require some debugging of the new code
|
||||
which we expect to be less tested than the existing one, and so
|
||||
more prone to undetected bugs.</li>
|
||||
</ul>
|
||||
|
||||
<p>The production of suitable documentation in the source is a key
|
||||
requirement of the project.</p>
|
||||
</desc>
|
||||
</idea>
|
||||
|
||||
<idea id="iscsi">
|
||||
<title>iSCSI</title>
|
||||
|
||||
|
|
@ -630,38 +738,6 @@ be used without kernel symbols to analyze the failure mode.</p>
|
|||
<ul>
|
||||
<li>Familiarity with FreeBSD kernel debugging environment.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
</ul>
|
||||
</desc>
|
||||
</idea>
|
||||
|
||||
<idea id="setproctitle" class="soc">
|
||||
<title>Avoiding syscall overhead</title>
|
||||
|
||||
<desc>
|
||||
<p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>
|
||||
|
||||
<p>setproctitle() calls are a serious
|
||||
performance bottleneck in a default pgsql configuration (they are
|
||||
called at least once per query, which might be thousands of times per
|
||||
second - I measured a performance impact of about 33% on sysbench).</p>
|
||||
|
||||
<p>One idea for avoiding the syscall (and global sysctl lock) overhead
|
||||
for this kind of thing would be a memory page shared between kernel
|
||||
and userland which libc could read/write to access things like the
|
||||
process title. There are potentially many other data values that
|
||||
could be optimized by a similar method. This is presumably a well
|
||||
established technique in other OSes.</p>
|
||||
|
||||
<p>This project requires mentoring/review/planning with someone with
|
||||
significant VM experience to make sure this approach
|
||||
works properly. Done incorrectly, this could result in fairly
|
||||
massive security holes, performance issues (perhaps not visible in
|
||||
simple benchmarks), etc.</p>
|
||||
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Strong knowledge of C.</li>
|
||||
<li>Understanding of kernel VM.</li>
|
||||
</ul>
|
||||
</desc>
|
||||
</idea>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue