Return to BSD News archive
Xref: sserve comp.os.386bsd.announce:8 comp.os.386bsd.development:133
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!agate!usenet
From: nate@fubar.cs.montana.edu (Nate Williams)
Newsgroups: comp.os.386bsd.announce,comp.os.386bsd.development
Subject: Some Sample Projects for 386BSD
Followup-To: comp.os.386bsd.development
Date: 9 Mar 1993 18:13:25 -0800
Organization: University of California, Berkeley
Lines: 177
Sender: cgd@agate.berkeley.edu
Approved: 386bsd-announce-request@agate.berkeley.edu
Message-ID: <9303090526.AA07265@fubar.cs.montana.edu>
Reply-To: nate@cs.montana.edu
NNTP-Posting-Host: agate.berkeley.edu
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
To: 386bsd-announce@agate.berkeley.edu
Status: RO
Howdy all.
This is an *unofficial* request for warm bodies.
I spent some time talking with Bill a couple weekends ago, and since I'm
no longer in the patchkit co-ordination business, I thought it would be
nice to know some short-term projects that I could do when I get some
free time. (Short term means I can spend some time here and there,
which hopefully wouldn't require constant watching, unlike patchkit
stuff)
Bill gave me a list of projects that he would like to see done, so
I thought I would share some of them with you.
1) Posix Wardens - Basically, we need some people who are familiar
with POSIX to track the kernel and user interfaces in 386BSD.
A committee of these people would get together (mailing list)
and discuss where 386BSD fall short of POSIX, or places where
it could be improved. This group would inform Bill and the 386BSD
community when a program our kernel interface does not conform with
Posix standards. From what I could glean from Bill, this would be
great jobs for people who is good at reading technical information,
and like to influence the future of 386BSD. This committee would
have fulls rights to tell anyone (within reason) to change a program
or interface if it doesn't conform to POSIX specifications. This
committe would have the last word when it comes to anything changing
or staying the same in 386BSD.
2) Clean up of existing device driver's, and add missing functionality.
For example, the current floppy disk driver does not support
formatting, 720K disks, handle multiple disks at the same time, and
many other features. (This is being worked on, but I'm using the FD
driver as an example). Many of the current driver's in 386BSD
*work*, but could stand to have some additional functionality. For
example, there is work underway to add the Berkeley Packet Filter
code to the ethernet driver's, there are multiple versions of the lpt
driver's floating around, etc.... If you feel that you have some
knowlege in a certain area, go ahead and hack up the current driver
to improve it in ways that you feel are necessary/good. After you've
done that, email it to the patchkit co-ordinator for inclusion in
the next patchkit.
3) Unified releases. At one time, Julian and a bunch of other's on ref
were planning on making a new and improved release, which contained
the patchkit and updated bootables. Due to lack of time, this was
never finished (though a lot of good things came out of it). However,
if someone else would like to pick up the ball (or multiple groups),
it's possible that a better way of releasing could be created, and
new users would be able to install 386BSD easier.
4) Replacements for ref. Since Julian is going back home :-(, ref
will be going away. I realize that not many of you have 486-50's with
a Gig of disk, but some people may be able to get permission from their
companies/schools/whatever to set up a small machine that people could
get access to do limited development work. In this way, the machine
could be used for a small portion of what ref was used for. Also,
this helps spread the network traffic and machine load around a little.
5) Update and clean up man pages. Currently, most of the commands have
man pages, but there are a few commands that don't. Also, some of
the man pages need to be updated and cleaned up, since they are
somewhat old and may require a complete re-write. This is meant as
no offense to the original man page writers, but things have changed
and some of the man pages no longer reflect 386BSD. Also, Bill
mentioned that he would like to see all of the man pages converted
BACK INTO the old man macros. He mentioned that there are scripts
out there now that do most of the dirty work, but a person would need
to verify each man page after it was done, since the scripts aren't
perfect.
6) Missing Library routines.
a) Internationalization routines - Much has been discussed
in the newsgroup about this.
b) Precision Math Libraries
c) Missing Compatability Libraries
d) Fixing current 'buggy' ones.
[ Note: Bill doesn't want any kind of copyrighted/lefted libraries
in the Base Distribution. That way, a person doesn't un-knowingly
have any sort of responsibility to distribute something extra if
they only distributed the base distribution. However, if someone
where to make a completely seperate library that is re-distributable
that people could grab as a seperate add-on to the base distribution,
that would not be a problem. If you don't understand what I'm saying
here, email me. I think I understand why, though I don't think I'm
expression myself very well. ]
7) Performance/benchmarking software for determining system performance
before/after enhancements are made. For example, exec. is very slow
in 0.1 due to some quick coding that didn't pay attention to speed,
rather just functionality at first. It would be nice to do a
clean up of the code and with this performace software, be able to
compare the kernel with and with out the enhancement. Also, certain
hardware configurations by vendors are 5-15% faster than other vendor's
hardware with the same configuration. This kind of information would
be nice to have.
8) Projects that *YOU* think are important. For example there is a group
in Japan that is profiling the VM code, and finding the bottlenecks
and slow parts in it. After doing this, it will be easier to find
out where to spend most of the time in cleaning up things. Another
group in Germany is creating an internationalized precision math
library. These kind of projects are great, and though they might not
get the same amount of attention as patchkits or SCSI drivers, are
just as important.
9) SNMP monitoring. (Simple Network Monitoring Protocol). It would
be nice to be able to monitor the status of the kernel and such
from a remote site, and SNMP is one tool that would allow such a thing
to happen. What would be required would be the addition of kernel
hooks to read the information, and the addition of user level software
that could query the machine on the network to get this information.
10) Line Printer sub-system. This project does not involve replacing
lpr, lpd, and friends, but adding new filters for popular printers,
such as certain laser printers, certain kinds of dot matrix
printers, and such. However, if someone get's real ambitious, they
could re-invent the wheel (assuming it's POSIX compliant) and make a
completely new way of doing things. However, the main thrust was
to fill out what is already there.
a) Someone works on the LPT driver itself and make sure that it
works with a reasonable sampling of printers in doing flow
control, condition detection (out-of-paper, etc) and
performance.
b) One or more people look at "applications side" of printing.
This can be anything from ensuring that the line printer daemon
(and administration) works properly, to dealing with ghostscript
configuration so that people can do things like print postscript
on their PCL printers. It would be really nice if someone could
look at what's required to make FAXing work transparently as
well, since many of the issues behind printing to a printer or
submitting a FAX to a FAXmodem are the same.
11) Clean up the C libraries to remove the name-space pollution that
POSIX requires. Bill has done most of the work for 0.2, but if
you really feel like that is something you'd like to do, give
a jingle and I'm sure something could be worked out. This person
would work with the POSIX committee in order to maintain
consistancy with POSIX.
12) Anything else you think you can do. 386BSD is a group project,
and even if you see someone doing something now, and you think
it can be done better, contact that person and maybe you can
get together and make it better for everyone.
I'm sure there are LOTS more things that can be done, but I for one
was suprised with some of the things Bill would like to see done, so
I thought I would pass this information on to the group.
Also, he wanted me to stress that he would 'like' (not require) people
to send in some sort of test program that triggers bugs when they report
them. This way, it is easy to show that the bug has been fixed after
applying the patch. Also, when 386BSD22.8 is released (;-), you
can go back to the old tests you have to verify that the bug is STILL
fixed. (Don't you hate it when you thought you fixed a bug, and later
on you find out that somehow that fix got lost, and you forgot what
you did to fix it. Boy, *I* sure do)
Anyway, those are some things Bill thought were worth mentioning to
me.
If you are interested in any/all of these projects, send me or Jordan
(or both) some email, and maybe we can help get some of this organised
and get 0.1.X to be a really slick system. (It's pretty slick now, but
it would be nice if everything compiled, it installed nicely, etc..)
Some of these projects have been started, but warm bodies are never a
bad thing, and other projects could use some leadership and time.
Your friendly neighberhood 386BSD dude,
Nate