Add some suggested skills to the projects I suggested to Murray

This commit is contained in:
Warner Losh 2008-03-18 07:21:30 +00:00
parent 29a9462781
commit e57c632b48
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/www/; revision=31683

View file

@ -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.50 2008/03/18 04:24:39 murray Exp $
$FreeBSD: www/en/projects/ideas/ideas.xml,v 1.51 2008/03/18 04:49:44 murray Exp $
</cvs:keyword>
</cvs:keywords>
@ -27,14 +27,27 @@ Ideas//EN"
<desc><p><strong>Technical Contact</strong>: <a
href="mailto:imp@FreeBSD.org">Warner Losh</a></p>
<p>This project would take Sam Leffler's scripts, picobsd,
and/or tinybsd and create a reproducible build of FreeBSD for
a tiny footprint. 16MB is a good side to target, although 8MB
would be better. Most Linux distributions boot using uboot or
redboot. In this environment, the kernel is loaded,
decompressed and away you go. There's also a step for
compressed ram disks. This is basically openwrt for embedding
FreeBSD.</p>
<p>In the Linux world, there are a number of packages available
which will grab a bunch of software, including Linux, the tool
chains, packages, etc and create a firmware image for popular
devices. Since FreeBSD is an integrated system, many of these
elements are present in the base system or the ports tree.</p>
<p>There have been attempts at this problem over the years:
nanobsd, picobsd, and tinybsd are in the tree, Sam Leffler has
his own custom scripts, etc. This project would pick an
approach and use the existing scripts to make it simple to
create images that could be loaded into the firmware of these
devices. Many of the newer devices have 8MB or 16MB flash
parts, so that would be a good size to target for the kernel
and ram disk image. A good way to think of this project is
openwrt for FreeBSD images.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong C and scripting language programming skills.</li>
<li>No fear of the FreeBSD build process.</li>
<li>Good knowledge of how FreeBSD is put together.</li>
<li>Knowledge of the ports system.</li>
</ul>
</desc>
</idea>
@ -43,6 +56,11 @@ Ideas//EN"
<desc><p><strong>Technical Contact</strong>: <a
href="mailto:imp@FreeBSD.org">Warner Losh</a></p>
<p>Add support for nand flash support.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good C programming skills</li>
<li>Ability to understand FreeBSD subsystems like geom, device, etc.</li>
</ul>
</desc>
</idea>
@ -54,6 +72,11 @@ Ideas//EN"
activate children. They are far too hard to create. We need to
abstract out the basics for these buses and provide a way to allow
these buses to be a subclass of this new base class.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good C programming skills</li>
<li>Good knowledge of the NewBus configuration system in FreeBSD</li>
</ul>
</desc>
</idea>
@ -68,6 +91,10 @@ these buses to be a subclass of this new base class.</p>
have a mechanism that code on these machines can use to load
one of several sets of hints, which can then be used to
populate the bus.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good C programming skills</li>
</ul>
</desc>
</idea>
@ -80,6 +107,11 @@ these buses to be a subclass of this new base class.</p>
needs to be. A lot of benefit could be had by creating tables
for memory ranges, etc, and having more generic initialization
code. Much of this can also be Machine Independent (MI).</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good C programming skills</li>
<li>Good refactoring skills</li>
</ul>
</desc>
</idea>
@ -93,6 +125,11 @@ these buses to be a subclass of this new base class.</p>
etc that have chips that are supported by FreeBSD, or nearly
supported by FreeBSD. Pick one and bring FreeBSD up on it.
Integrate it into the tree.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good C programming skills</li>
<li>Good kernel debugging skills</li>
</ul>
</desc>
</idea>
@ -107,7 +144,12 @@ these buses to be a subclass of this new base class.</p>
There's also inconsistent dependency tracking. We should fix
this. Bikeshed included, along with three colors of
paint.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Good C programming skills</li>
<li>Good kernel debugging skills</li>
<li>Ability to withstand Bikesheds</li>
</ul>
</desc>
</idea>