*BSD News Article 12466


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