From comp.os.386bsd.announce Wed Mar 10 08:44:22 1993 Path: hcshh!Germany.EU.net!ira.uka.de!gmd.de!newsserver.jvnc.net!howland.reston.ans.net!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 Message-ID: <9303090526.AA07265@fubar.cs.montana.edu> Date: 10 Mar 93 02:13:25 GMT Sender: cgd@agate.berkeley.edu Reply-To: nate@cs.montana.edu Followup-To: comp.os.386bsd.development Organization: University of California, Berkeley Lines: 177 Approved: 386bsd-announce-request@agate.berkeley.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