Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!umd5!roissy.umd.edu!mark From: mark@roissy.umd.edu (Mark Sienkiewicz) Newsgroups: comp.os.386bsd.questions Subject: Re: 386BSD Posix Compliance Message-ID: <18738@umd5.umd.edu> Date: 1 Mar 93 22:55:24 GMT References: <1me016$4j8@agate.berkeley.edu> <C2z38u.3BA@panix.com> <1993Feb25.080612.16553@gmd.de> Sender: news@umd5.umd.edu Organization: University of Maryland Lines: 61 >The second aspect is the kernel domain. A typical user does not normally write >kernel code; Is this a valid assumption for 386bsd? >Bill's mentioned "novel research" focuses on changes in the kernel interfaces, >for instance device drivers, memory management, file systems, networking. This >might be an extreme change for kernel hackers, and 386bsd surely becomes incompatible >to e.g. NET/2 on the *source level*; but this *is* acceptable (noone complains >that device drivers must be rewritten from SysV to BSD, but apparently >they must remain exactly the same for all BSD's since 0.0BSD to 99.99BSD; >this is not progress. BTW: the interfaces have evolved in BSD!). If a kernel >programmer does not accept this, he/she is not worth doing any work here. They >ought to know what they are doing. The issue is more complex than this. There are two different scenarios: 1- Somebody interested in doing major OS hacking. This person will want to hack around with user/system interfaces, internal algorithms, internal interfaces, etc. You need to do this for basic research. It also rapidly makes your system look utterly unlike anybody elses. 2- Somebody who is interested in OS hacking, but cannot afford to devote their life to it. This person wants to hack on kernel code, maybe write a few device drivers, maybe learn how to write kernel code for BSD-based Unixes. For this, you need a stable system. Let me give you an example: I don't have time to be on the cutting edge of OS research. I do like to do a bit of kernel hacking. 386bsd is ideal for this because it comes with source code. My current project is loadable device drivers. Discussion on the net seems to indicate that the code I've written is not useful in the next version (0.02?), because the device driver interface has been/will be changed. >Even if I >and thousand other people suddenly decide to remove 'ls' and call a replacement 'dir', >you are not forced to do the same (see /usr/src/bin/ls/ls.c). No, but it _does_ mean that nobody else will be working on fixes to ls. It also means that _I_ can't make any useful contributions to the effort, because I don't have the new 'dir' program. This analogy is weak, because 'dir' and 'ls' can co-exist on the same machine, where 2 different kernels cannot. (Anybody for VM/386?) >This "threatening incompatibility" in the future of 386bsd, seen in the light, is >no reason for general panic. It is no reason for general panic, but as I see it, the _only_ reasonable course is to split into two groups: - old style BSD for the 386 (call it PCBSD for now) - 386bsd, new and improved I have to be in the former group, otherwise, how can I write any kernel code for 386bsd? Mark S.