BNR2SS vs xxxBSD...
Robert Withrow
kernel, rather than the 3 to 5 there are now, witness the following statement
in the recent announcement of BSDSS8:
``The CMU Mach group will be able to devote very limited effort to this project.
System support is complicated by the existence of several different kernels
derived from BNR2. Thus it is not clear which we should be trying to maintain
compatibilty with.''
It should be clear to everyone that this sort of thing hurts us all. Especially
when it appears to me (from the outside) that the only real reason for the
proliferation of competing kernels is the personality conflicts between the
various developers. I say this because I have yet to see a *technical* conflict
between the various systems that could not be resolved if there were a *true*
spirit of cooperation amoung the developers.
And so I say again, ``Kernel developers, please pull on the same end of the
rope''. Re-unify into *one* BSD derived kernel for 386 architectures.
--
Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: wi...@rwwa.COM
R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA
Holger Veit
I strongly second this. The situation is unsatisfying for every participant:
the core developers, the application developers and the users (who are most
irritated what to choose). There have been omissions in the past, in that
there was no system of communication and regular update of 386bsd. This way
NetBSD was a consequence, and the idea itself was not bad. The
problem arises that NetBSD now has become an own group with different goals
than 386bsd. The difficulty is that the goal is not just fixing known bugs
with corrections from the known pool of corrections, but more and more
moving into different design directions (for what reasons, ever; I have my
own opinions here). A sign here, for instance, is the number of problems
with porting my codrv driver that have been introduced with the move from
386bsd-0.1 to NetBSD-0.8 to NetBSD-0.8a (I have never had this amount of
new problems with the OS besides my own faults before, and I seriously consider
dropping any support for NetBSD, as long as there are no pointers to
a clear direction).
I know that there will be considerable changes with 386bsd-0.2,
and I accept that there are things to do, but what the hell is the
reason of changing several interfaces from version to version?
The interpretation of "removing several of Bill's hacks" (as mentioned in
the recently published list of changes in NetBSD) is a relative thing; it
appears that there is a "back to the roots" stream working on NetBSD to return
to the "NET/2" which is "the BSD" (and the starting point for 4.4BSD) and
everything people contribute, who do not belong to this scene, should be removed.
Of course this introduces the old bugs that are still in Net/2 back into
the current release, where they have been fixed before (or you might also
call it "hacked away"), but at least it is "different".
The same confrontation Bill wanted to avoid with having newsgroups like
'comp.*OS.386bsd*....' with the emphasis on OS and 386bsd. So what is then
NetBSD? Something like comp.unix.386bsd or comp.unix.net2 or comp.unix.4.4bsd.for.386,
and should we then have 'YANGH(tm)' (yet another news group hierarchy)?
I fear the schisma has been there since the earliest days of 386bsd; but
the intensity has now increased (and this is the dark side of NetBSD
and certainly not for the benefit of the usership).
Holger
--
Dr. Holger Veit | INTERNET: Holge...@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Three lines Signature space
| |/ Schloss Birlinghoven | available for rent. Nearly
DW-5205 St. Augustin, Germany | unused, good conditions
Chris G. Demetriou
.It should be clear to everyone that this sort of thing hurts us all. Especially
.when it appears to me (from the outside) that the only real reason for the
.proliferation of competing kernels is the personality conflicts between the
.various developers. I say this because I have yet to see a *technical* conflict
.between the various systems that could not be resolved if there were a *true*
.spirit of cooperation amoung the developers.
here're a few somewhat-technical conflicts:
(1) we doing NetBSD believe in both regularly releaseing
things, and making them available to the public
(2) we would rather have a stable functional system
than develop new features and change system
structure.
those are very much "technical" points, because they relate
to the overall design of the system, and (while not as
technical, much more important) how it gets to its users.
Bill and Lynne Jolitz cannot *possibly* claim those
two goals as their own, and until they can, then then...
.And so I say again, ``Kernel developers, please pull on the same end of the
.rope''. Re-unify into *one* BSD derived kernel for 386 architectures.
*THIS* will not become a reality, unless everybody jumps
ship to NetBSD.
chris
--
Chris G. Demetriou c...@cs.berkeley.edu
"386bsd as depth first search: whenever you go to fix something you
find that 3 more things are actually broken." -- Adam Glass
Sean Eric Fagan
>.And so I say again, ``Kernel developers, please pull on the same end of the
>.rope''. Re-unify into *one* BSD derived kernel for 386 architectures.
>*THIS* will not become a reality, unless everybody jumps
>ship to NetBSD.
Not quite. Everybody could jump ship to netbsd, or 386bsd 0.1, or 386bsd 0.2,
or whatever.
But one of the goals for "NetBSD" is that it be ported to non-386 platforms.
Given some things Chris has said, in public and private, I am led to believe
that is happening; also, by tracking 4.4 as much as possible, NetBSD may be
in a better position to take advantage of various other ports that exist,
if are not quite yet available. For 386bsd 0.2, everything would have to
start from scratch.
Oh, and yeah: there *is* no way there will be one BSD-derived kernel
for 386 architectures. Unless everyone goes to BSDi, or BSDi dies (which
would be a very bad thing).
Chris G. Demetriou
.The
.problem arises that NetBSD now has become an own group with different goals
.than 386bsd.
from NetBSD's inception it has had different goals than 386bsd.
Nothing new.
.The difficulty is that the goal is not just fixing known bugs
.with corrections from the known pool of corrections, but more and more
.moving into different design directions (for what reasons, ever; I have my
.own opinions here).
yes; NetBSD is meant to be a stable base for research.
therefore you'll have bug fixes, but you'll have major changes too.
this is nothing new: it was announced in public before, and told
again to anyone who would ask.
you, sir, never asked, and obviously never read the note about it
which was posted in the newsgroup.
.A sign here, for instance, is the number of problems
.with porting my codrv driver that have been introduced with the move from
.386bsd-0.1 to NetBSD-0.8 to NetBSD-0.8a (I have never had this amount of
.new problems with the OS besides my own faults before, and I seriously consider
.dropping any support for NetBSD, as long as there are no pointers to
.a clear direction).
umm, i dunno how many problems you had, but if you had more than
two in any case, you did something very wrong. unless i'm mistaken,
the changes from 386bsd that we've made are:
(1) make tty structures dynamically allocated, to save
many K each in BSS (not hard to get around, and
not done in all cases).
(2) improve the kernel select intererface, and make it
*EASIER* to use, and hell, even give prototypes
for the new interface, so people wan't get confused.
even forgetting these two (minor) changes, if you'd had problems,
you should have mailed "netbs...@sun-lamp.cs.berkeley.edu".
that's what were there for, and we certainly don't read minds...
(and, if you'll notice, for a *long* time now, i've been encouraging
people to send mail rather than post, because the time spent
reading and responding to news could be better used, and also
the person who best knows the answer to your question may not
read news!)
also, if you're looking for pointers to a new direction,
you should *ASK* what we're doing, and what our future plans
are... "hac...@sun-lamp.cs.berkeley.edu" is for discussions
of that nature, and *ANYONE* who wants to be on it (and asks)
can be placed there.
but if you're not even interested enough in the future direction
of NetBSD to ask what it is, or how to find out more about it,
then *we* can't be held responsible for you not knowing.
.I know that there will be considerable changes with 386bsd-0.2,
.and I accept that there are things to do, but what the hell is the
.reason of changing several interfaces from version to version?
i enumerated above the reasons for those changes;
the latter was to make things more consistent and less confusing,
the former was so that we could actually boot a kernel with
16 ptys, they SCSI system, and DDB!
.The interpretation of "removing several of Bill's hacks" (as mentioned in
.the recently published list of changes in NetBSD) is a relative thing; it
.appears that there is a "back to the roots" stream working on NetBSD to return
.to the "NET/2" which is "the BSD" (and the starting point for 4.4BSD) and
.everything people contribute, who do not belong to this scene, should be removed.
once again, you might actually *ask* before you start trying to speak
for our intentions...
umm, Holger, you want to see some of "Bill's hacks"?
take a look at 386bsd. read exec. read vfs bio. read ufs_disksubr,
and note the "struct dos partition *" which gets handed to
a generic disk management routing.
you tell me that that is not bad code, and you do it with a straight
face, and either you've spent too much time working on PC's,
or you deserve a beer for not busting a gut holding in the laughter.
.Of course this introduces the old bugs that are still in Net/2 back into
.the current release, where they have been fixed before (or you might also
.call it "hacked away"), but at least it is "different".
yes, in general, if you don't understand the motivations or
actions of a group, it *IS* best to comment on their work
in a derogatory manner! Holger, you've learned WELL!
we have no intentions of going "back" to Net/2.
Net/2 is a snapshot, at best, of then-current work at CSRG.
it's reasonably broken in a lot of ways, and we'd be the
first to tell you that.
however, for all its brokenness, they did understand some
very important concepts (e.g. keep architectire-dependent code
in the architecture-dependent parts of the kernel source)
pretty well.
.The same confrontation Bill wanted to avoid with having newsgroups like
.'comp.*OS.386bsd*....' with the emphasis on OS and 386bsd. So what is then
.NetBSD? Something like comp.unix.386bsd or comp.unix.net2 or comp.unix.4.4bsd.for.386,
.and should we then have 'YANGH(tm)' (yet another news group hierarchy)?
i see no confrontation, other than the one which perhaps you'd
like to create.
honestly, it perhaps *should* have another newsgroup hierarchy, but
the advantages and disadvantages of that are many...
i this the biggest is that:
there wouldn't be enough volume to warrant it
(it's dubious as to whether the *386bsd groups
have enough volume to warrant them, but figured
that from the beginning, and it didn't bother me...)
.I fear the schisma has been there since the earliest days of 386bsd; but
.the intensity has now increased (and this is the dark side of NetBSD
.and certainly not for the benefit of the usership).
The schism had been there since the earliest days of 386bsd?
i was *there* in the earliest public days of 386bsd, and i didn't see
any schism.
what caused a schism was Bill and Lynne (but more the latter) acting
like 3-year-olds on the Net, and them going off to change everything
in the kernel without releasing a stable system first.
i don't think that you can argue that *either* one of those are
"good" things.
since they've shown little desire to change especially the latter,
we've not even looked back.
as for the dark side of NetBSD, well, i've met a few of the NetBSD
gang, and neither looked much to me like Darth Vader or
the Emperor... i imagine one of them could be "working" for us... 8-)
chris
shaking his head, and wondering how people come up with
some of the ideas which they have.
Jaye Mathisen
>
>various developers. I say this because I have yet to see a *technical* conflict
>
This will never happen as long as you have people like Mr. Bill who believe
that the work they're doing is so earth shatteringly important to warrant
locking it away never to see the light of day in the quest for "when
we release it, it shall be perfect", which will never happen. Hell,
witness 0.2.takes.forever.
I suspect that this is one of the reasons NetBSD spun off and Chris and co.
are doing their own thing.
If I were starting over now, I would recommend that people just work with
NetBSD, except that their source release mechanism/upgrade mechanism needs
some serious work, which nobody probably has time or desire to do because
it's tedious. The NetBSD philosophy seems to be "get it out there and
let 'em beat on it".
The Jolitz philosophy is "It's mine, mine, all mine, and when I dub it
good enough, then you may partake of the fountain of BSD, and be forever
saved".
It's a sad state of affairs, but one that given all the various egos
involved will probably never be rectified.
I share your concerns, and Nate and I have talked about this a lot up
here, and I think that we're agreed that it's a bad thing, but not a lot
individuals can do.
The interim group is doing some good stuff, perhaps 0.1.5 may be a nice
compromise, I don't know.
--
Jaye Mathisen, COE Systems Manager (406) 994-4780
410 Roberts Hall,Dept. of Computer Science
Montana State University,Bozeman MT 59717 os...@cs.montana.edu
Nate Williams
>
>.A sign here, for instance, is the number of problems
>.with porting my codrv driver that have been introduced with the move from
>.386bsd-0.1 to NetBSD-0.8 to NetBSD-0.8a (I have never had this amount of
>.new problems with the OS besides my own faults before, and I seriously consider
>.dropping any support for NetBSD, as long as there are no pointers to
>.a clear direction).
>
>umm, i dunno how many problems you had, but if you had more than
>two in any case, you did something very wrong. unless i'm mistaken,
>the changes from 386bsd that we've made are:
> (1) make tty structures dynamically allocated, to save
> many K each in BSS (not hard to get around, and
> not done in all cases).
> (2) improve the kernel select intererface, and make it
> *EASIER* to use, and hell, even give prototypes
> for the new interface, so people wan't get confused.
And Theo's (well done) change of the ring buffers from char's to rbchars
(signed to unsigned).
Nate
--
os...@terra.oscs.montana.edu | Still trying to find a good reason for
na...@cs.montana.edu | these 'computer' things. Personally,
work #: (406) 994-4836 | I don't think they'll catch on -
home #: (406) 586-0579 | Don Hammerstrom
David C. Niemi
round. Me and my big mouth.
At least both camps know how to spell "kernel". Over in the Microsoft advocacy
group lots of people use "kernal" to describe the Windows NoT macrokernal. Maybe
because Bill Gates spells it that way.
---
David C. Niemi: David...@oasis.gtegsc.com
My opinions are those of my fuzz-brained, cat-sniffing Norwegian Elkhound.
Nate Williams
>In article <CGD.93Ju...@eden.cs.berkeley.edu> c...@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes:
>>.And so I say again, ``Kernel developers, please pull on the same end of the
>>.rope''. Re-unify into *one* BSD derived kernel for 386 architectures.
>>*THIS* will not become a reality, unless everybody jumps
>>ship to NetBSD.
>
>Not quite. Everybody could jump ship to netbsd, or 386bsd 0.1, or 386bsd 0.2,
>or whatever.
>
>But one of the goals for "NetBSD" is that it be ported to non-386 platforms.
In defense of Bill, from conversations I've had with him he is planning
on (in the process of ??) porting to other architectures.
>Given some things Chris has said, in public and private, I am led to believe
>that is happening; also, by tracking 4.4 as much as possible, NetBSD may be
>in a better position to take advantage of various other ports that exist,
>if are not quite yet available. For 386bsd 0.2, everything would have to
>start from scratch.
But, as Chris has done, and admitted, some of the changes in the current
NetBSD source tree have not been done in 4.4.
As with any software project, everyone thinks that by changing this or
that, things will be better. So, NetBSD, though it has a much stronger
4.4 basis than the others, will still be different from 4.4.
And, will Chris's select changes be put into 4.4? I doubt it (but then again,
who am I to say what does/doesn't go into 4.4).
So, in the end, we will still end up with 3/4/5 or 6 competing kernels.
The sad thing is that there have already been enough kernel changes
in NetBSD to make all of the binaries created under it useless in
386BSD. (New a.out format).
Sigh..
Sean Eric Fagan
>The sad thing is that there have already been enough kernel changes
>in NetBSD to make all of the binaries created under it useless in
>386BSD. (New a.out format).
Yeah, yeah, yeah. The new a.out format is "QMAGIC"; it unmaps the first
page of memory, so that dereferencing NULL causes the appropriate core-dump.
I initiially did the work so that I could run BSDi's /bin/sh, and verify
whether or not some bugs in 386bsd's sh were present there, as well (they
were, for the curious).
So, here are some diffs; they're from my current kernel, and they allow
NetBSD (and BSD/386) binaries to run, if not perfectly (the passwd database
seems to be differnet in NetBSD [they have the new db code, that should
be it, I think], BSD/386 has some ioctl's not supported in *bsd, etc.;
but, for the most part, programs should work, at least someone).
These are *NOT* complete diffs! Other stuff that needs to be done, that
both the NetBSD folks and BSDi have done, include changing <a.out.h>,
making the file(1) database recognize the new magic number, having the
linker able to output the new format, and, of course, making gdb understand
the new file format. (By updating <a.out.h>, and rebuilding the entire
system, things like size(1) et al should pick up everything. I think.
I haven't done it here [yet?], so I'm not sure.) One can always look at
the NetBSD code to see what they did; they will, I'm sure, be more than
happy for people to use their code!
Thanks to Nate for making the changes; thanks to mycroft of the NetBSD
folks for doing the various and sundry work that I don't want to do
(making all of the supporting changes, of course); and thanks to cgd
for convincing me that doing the bloody thing in the first place would
be a good idea :). (Deity, I feel like I've just won an oscar :).)
*** kern_execve.c Mon Jun 7 13:41:44 1993
--- /tmp/kern_exec Wed Jun 9 14:40:02 1993
***************
*** 91,96 ****
--- 91,100 ----
extern int dostacklimits;
#define copyinoutstr copyinstr
+ #ifndef QMAGIC
+ # define QMAGIC 0314
+ #endif
+
/*
* execve() system call.
*/
***************
*** 187,193 ****
/* ... that we recognize? */
rv = ENOEXEC;
! if (exdata.ex_hdr.a_magic != ZMAGIC) {
char *cp, *sp;
if (exdata.ex_shell[0] != '#' ||
--- 191,198 ----
/* ... that we recognize? */
rv = ENOEXEC;
! if (exdata.ex_hdr.a_magic != ZMAGIC &&
! exdata.ex_hdr.a_magic != QMAGIC) {
char *cp, *sp;
if (exdata.ex_shell[0] != '#' ||
***************
*** 227,239 ****
/* sanity check "ain't not such thing as a sanity clause" -groucho */
rv = ENOMEM;
! if (/*exdata.ex_hdr.a_text == 0 || */ exdata.ex_hdr.a_text > MAXTSIZ ||
! exdata.ex_hdr.a_text % NBPG || exdata.ex_hdr.a_text > attr.va_size)
goto exec_fail;
! if (exdata.ex_hdr.a_data == 0 || exdata.ex_hdr.a_data > DFLDSIZ
! || exdata.ex_hdr.a_data > attr.va_size
! || exdata.ex_hdr.a_data + exdata.ex_hdr.a_text > attr.va_size)
goto exec_fail;
if (exdata.ex_hdr.a_bss > MAXDSIZ)
--- 232,246 ----
/* sanity check "ain't not such thing as a sanity clause" -groucho */
rv = ENOMEM;
! if (exdata.ex_hdr.a_text > MAXTSIZ ||
! exdata.ex_hdr.a_text % NBPG ||
! exdata.ex_hdr.a_text > attr.va_size)
goto exec_fail;
! if (exdata.ex_hdr.a_data == 0 ||
! exdata.ex_hdr.a_data > DFLDSIZ ||
! exdata.ex_hdr.a_data > attr.va_size ||
! exdata.ex_hdr.a_data + exdata.ex_hdr.a_text > attr.va_size)
goto exec_fail;
if (exdata.ex_hdr.a_bss > MAXDSIZ)
***************
*** 392,413 ****
/* blow away all address space, except the stack */
rv = vm_deallocate(&vs->vm_map, 0, USRSTACK - 2*MAXSSIZ);
! if (rv)
goto exec_abort;
!
/* destroy "old" stack */
if ((unsigned)newframe < USRSTACK - MAXSSIZ) {
rv = vm_deallocate(&vs->vm_map, USRSTACK - MAXSSIZ, MAXSSIZ);
! if (rv)
goto exec_abort;
} else {
rv = vm_deallocate(&vs->vm_map, USRSTACK - 2*MAXSSIZ, MAXSSIZ);
! if (rv)
goto exec_abort;
}
/* build a new address space */
! addr = 0;
/* screwball mode -- special case of 413 to save space for floppy */
if (exdata.ex_hdr.a_text == 0) {
--- 399,422 ----
/* blow away all address space, except the stack */
rv = vm_deallocate(&vs->vm_map, 0, USRSTACK - 2*MAXSSIZ);
! if (rv) {
goto exec_abort;
! }
/* destroy "old" stack */
if ((unsigned)newframe < USRSTACK - MAXSSIZ) {
rv = vm_deallocate(&vs->vm_map, USRSTACK - MAXSSIZ, MAXSSIZ);
! if (rv) {
goto exec_abort;
+ }
} else {
rv = vm_deallocate(&vs->vm_map, USRSTACK - 2*MAXSSIZ, MAXSSIZ);
! if (rv) {
goto exec_abort;
+ }
}
/* build a new address space */
! addr = (exdata.ex_hdr.a_magic == QMAGIC ? NBPG : 0);
/* screwball mode -- special case of 413 to save space for floppy */
if (exdata.ex_hdr.a_text == 0) {
***************
*** 415,421 ****
exdata.ex_hdr.a_data += exdata.ex_hdr.a_text;
} else {
tsize = roundup(exdata.ex_hdr.a_text, NBPG);
! foff = NBPG;
}
/* treat text and data in terms of integral page size */
--- 424,430 ----
exdata.ex_hdr.a_data += exdata.ex_hdr.a_text;
} else {
tsize = roundup(exdata.ex_hdr.a_text, NBPG);
! foff = (exdata.ex_hdr.a_magic == ZMAGIC ? NBPG : 0);
}
/* treat text and data in terms of integral page size */
***************
*** 426,448 ****
/* map text & data in file, as being "paged in" on demand */
rv = vm_mmap(&vs->vm_map, &addr, tsize+dsize, VM_PROT_ALL,
MAP_FILE|MAP_COPY|MAP_FIXED, (caddr_t)ndp->ni_vp, foff);
! if (rv)
goto exec_abort;
!
/* mark pages r/w data, r/o text */
if (tsize) {
! addr = 0;
rv = vm_protect(&vs->vm_map, addr, tsize, FALSE,
VM_PROT_READ|VM_PROT_EXECUTE);
! if (rv)
goto exec_abort;
}
/* create anonymous memory region for bss */
! addr = dsize + tsize;
rv = vm_allocate(&vs->vm_map, &addr, bsize, FALSE);
! if (rv)
goto exec_abort;
/*
* Step 5. Prepare process for execution.
--- 435,460 ----
/* map text & data in file, as being "paged in" on demand */
rv = vm_mmap(&vs->vm_map, &addr, tsize+dsize, VM_PROT_ALL,
MAP_FILE|MAP_COPY|MAP_FIXED, (caddr_t)ndp->ni_vp, foff);
! if (rv) {
goto exec_abort;
! }
/* mark pages r/w data, r/o text */
if (tsize) {
! addr = (exdata.ex_hdr.a_magic == QMAGIC ? NBPG : 0);
rv = vm_protect(&vs->vm_map, addr, tsize, FALSE,
VM_PROT_READ|VM_PROT_EXECUTE);
! if (rv) {
goto exec_abort;
+ }
}
/* create anonymous memory region for bss */
! addr = dsize + tsize + (exdata.ex_hdr.a_magic == QMAGIC ? NBPG : 0);
!
rv = vm_allocate(&vs->vm_map, &addr, bsize, FALSE);
! if (rv) {
goto exec_abort;
+ }
/*
* Step 5. Prepare process for execution.
***************
*** 451,458 ****
/* touchup process information -- vm system is unfinished! */
vs->vm_tsize = tsize/NBPG; /* text size (pages) XXX */
vs->vm_dsize = (dsize+bsize)/NBPG; /* data size (pages) XXX */
! vs->vm_taddr = 0; /* user virtual address of text XXX */
! vs->vm_daddr = (caddr_t)tsize; /* user virtual address of data XXX */
vs->vm_maxsaddr = newframe; /* user VA at max stack growth XXX */
vs->vm_ssize = ((unsigned)vs->vm_maxsaddr + MAXSSIZ
- (unsigned)argbuf)/ NBPG + 1; /* stack size (pages) */
--- 463,473 ----
/* touchup process information -- vm system is unfinished! */
vs->vm_tsize = tsize/NBPG; /* text size (pages) XXX */
vs->vm_dsize = (dsize+bsize)/NBPG; /* data size (pages) XXX */
! /* user virtual address of text XXX */
! vs->vm_taddr = (exdata.ex_hdr.a_magic == QMAGIC ? NBPG : 0);
! /* user virtual address of data XXX */
! vs->vm_daddr = (caddr_t)tsize +
! (exdata.ex_hdr.a_magic == QMAGIC ? NBPG : 0);
vs->vm_maxsaddr = newframe; /* user VA at max stack growth XXX */
vs->vm_ssize = ((unsigned)vs->vm_maxsaddr + MAXSSIZ
- (unsigned)argbuf)/ NBPG + 1; /* stack size (pages) */
Garrett Wollman
>As another example of why I claim there should be *just one* BSD Net2 derived
>kernel
I doubt this will ever happen. Throughout the history of BSD
development (and, indeed, UNIX development in general), large groups
interested in working on improving the system have degenerated into
cliques. This is not necessarily bad (at least from the point of view
of someone who has their own theory of OS design). There are a few
warning signs:
1) One or two people appear as ``spokespeople'' for a group.
2) People who don't belong to mailing-list X are considered
unimportant and not worth paying attention to.
3) Developers make ad-hominem attacks against people who
have different goals than they do.
[this is not a complete list]
As Sergeant Gilks (in ``Dirk Gently's Holisitic Detective Agency'')
puts it, the trouble with smart people is that they assume nobody else
is smart either.
And so 386BSD, like many of its predecessors, has degenerated into
four mutually-incompatible groups:
- Chris Demetriou and followers
- Bill and Lynne
- The patchkit people
- J. Random User
I do not see any chance of any of these groups agreeing on much of
anything for very long. Over a period of time, these groups will all
end up introducing gratuitous incompatibilities with each other (and I
am not innocent in this regard, and anyone looking at my source tree
can tell you!). Everyone should remember, however, that we are only
human; none of us are omniscient, and every one of us has a different
goal in working on these operating systems.
I will be direct in stating some of my goals:
- Get a grade for this project that I've been working on for a year
and a half now.
- Implement IP multicast routing properly. (almost done)
- Make code and header files conform to my standards. (almost done)
- Advance the cause of Free Software without evangelizing.
[My standards for header files are as follows: 1) All header files
must be idempotent. 2) No header file should depend on the previous
inclusion of another, with the exception of systm.h. 3) ALL repeat
ALL functions and function pointers MUST be prototyped. My standard
for code is simpler: all code should compile with no warnings under
`gcc -O -Wall', or be commented with a reason why the warning is not a
problem. Fixing this is a lot harder than fixing the header files.]
As a result of this and other hacking that I've done, my
system---originally 386BSD plus a selection of patchkit 0.1
patches---has already diverged so far from anybody else's base that I
can no longer take the time required to manually merge in
modifications made by any other group, including the patchkit.
(However, I am willing to share my working source tree with anyone
else who's interested; send mail to wol...@tsornin.emba.uvm.edu for
information.)
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wol...@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman | It is a bond more powerful than absence. We like people
UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant
A Wizard of Earth C
>Robert Withrow writes:
>|> As another example of why I claim there should be *just one* BSD Net2
>|> derived kernel, rather than the 3 to 5 there are now, witness the
>|> following statement in the recent announcement of BSDSS8:
[ ... "we find it hard to pick one of NetBSD or the 0.1 + patchkit" ...]
>|> It should be clear to everyone that this sort of thing hurts us all.
>|> Especially when it appears to me (from the outside) that the only real
>|> reason for the proliferation of competing kernels is the personality
>|> conflicts between the various developers. I say this because I have
>|> yet to see a *technical* conflict between the various systems that
>|> could not be resolved if there were a *true* spirit of cooperation
>|> amoung the developers.
[ ... "Work together" ... (this will be key later) ... ]
>I strongly second this. The situation is unsatisfying for every participant:
>the core developers, the application developers and the users (who are most
>irritated what to choose). There have been omissions in the past, in that
>there was no system of communication and regular update of 386bsd. This way
>NetBSD was a consequence, and the idea itself was not bad. The
>problem arises that NetBSD now has become an own group with different goals
>than 386bsd. The difficulty is that the goal is not just fixing known bugs
>with corrections from the known pool of corrections, but more and more
>moving into different design directions (for what reasons, ever; I have my
>own opinions here). A sign here, for instance, is the number of problems
>with porting my codrv driver that have been introduced with the move from
>386bsd-0.1 to NetBSD-0.8 to NetBSD-0.8a (I have never had this amount of
>new problems with the OS besides my own faults before, and I seriously
>consider dropping any support for NetBSD, as long as there are no pointers
>to a clear direction).
>I know that there will be considerable changes with 386bsd-0.2,
>and I accept that there are things to do, but what the hell is the
>reason of changing several interfaces from version to version?
[ ... ]
>I fear the schisma has been there since the earliest days of 386bsd; but
>the intensity has now increased (and this is the dark side of NetBSD
>and certainly not for the benefit of the usership).
This article should probably be titled "Why I wrote the patchkit, am using
NetBSD 0.8 instead of something else on my personal machine, and have
joined with most of the other patchkit people in working on the 0.1.5
interim release". Instead, I have left the subject line alone to allow
people with a bias for threaded news readers to know what the heck I'm
talking about.
About a year and a half ago, I got a copy of 386BSD 0.0; it was a "neat
idea", but it was far from useful either as an application platform or
as a research environment, unless one wanted to engage in rather esoteric
internals twiddling (something I have been known to do on occasion, but
which I don't view as my primary goal in life).
Shortly after this, I got a copy of 386BSD 0.1; this was, finally, a usable
platform for research, if not applications. After hacking the machdep.c to
handle memory identification without thinking it had more than a terrabyte
of memory if it hit something it didn't expect, I finished installing. To
help others with the same problems (and other problems which could be fixed
either without patches or with simple patches), I wrote the first unofficial
FAQ.
I began to get to work on my primary area of interest at that time (virtual
file systems) but soon discovered a number of bugs ...patches were readily
available, but all of them conflicted! You couln't install one patch and
another patch at the same time without an error! So a little over a year
ago, I wrote the first patchkit.
After the advent of the first patchkit, 386BSD became a much more usable
system (in my opinion). It was possible to install on the majority of
hardware, and, with a few minor glitches, it ran.
The patchkit was updated several times, by several different people; it's
a large enough job that, unpaid, it's nearly not worth it. Rod is either
very dedicated or he's insane (the jury is still out 8-).
The 0.1.5 interim group was formed, and I signed on after Bill blessed it
and gave assurances that there would be an upgrade path that wouldn't
require a full reinstall; 0.1.5 was formed because of the time difference
between 0.1 and 0.2 being so large compared to the time between 0.0 and
0.1. 386BSD was not losing "market share", but it was losing the interest
of people who had contributed in the past and were impatient to see 0.2;
the 386BSD community could not afford to lose these people.
I made plans to purchase a (yetch!) Intel based power machine as a platform
for the 0.1.5 work I planned to do, and as a personal machine to do my own
programming on. After 2 weeks of fighting timing problems, the 386BSD
install program, a power supply, and a DOS partition on a translated drive
(Adaptec lies in it's marketing literature and on it support line; there
is *no way* to turn off translation. When called on this, their support
person was overtly insulting to me. Needless to say, even though they
have blindingly fast hardware, they will not get any more of my money.
The recent 1542C fiasco has only served to reaffirm this decision), I was
about to kill my DOS partition entirely and install the whole drive as
386BSD. Then NetBSD was released.
NetBSD not only dealt with the translation problem, but also had two real
fixes that my new hardware needed that were not in the patchkit and were
not available elsewhere (at the time; they have since put their source
tree up nightly -- I have yet to take advantage of this). After beating
NetBSD over the head with a baseball bat, I was able to install it where
the 386BSD+patchkit installation had failed.
The reason I am running NetBSD? It would install without an additional
2 weeks of work on my part (the work had already been put in by the NetBSD
team) and I didn't have to go through the magic incantations I would have
suffered with 386BSD+patchkit to get 64M of swap (this is a big box). I
could be running 386BSD+patchkit now, but I would have lost out on a month's
use of my machine to do it.
I don't know what I'm going to do in the future; it's likely that, without
a method (like the patchkit) for doing an incremental update to more recent
sources, I will end up going back to 386BSD+patchkit. Not because NetBSD
is inferior, but because they haven't provided an update mechanism to
replace the one the got rid of when they didn't maintain the patchkit
that applied the patches included with their distribution -- there is no
baseline and no way to get back to one, currently. Their goal of having
an end-user system is laudable, but I can't buy into it if I have to
totally reinstall to get from the current to the next version. It's
important to me to do research, and this means incremental updates to
prevent interruptions in the flow of research. I think this will be a
problem for them as well, in the future, since an update to an end-user
system will be difficult to accept if it requires a reinstall. I am
going to *require* Bruce Evans code in the near future (July 1) for a
streams environment I have been working on for 386BSD. If I have to
go to 386BSD+patchkit to get it, I will.
I will probably not update to 0.2 when it comes out. Sure, I'll load it
on a spare machine, but the interface completely changes. For instance,
there are no longer cdevsw[]/bdevsw[] tables; there are many changes
that I don't know the details of (no one but Bill does), and so I can't
code to what it will be... I can only code to what is or what I have
specification for.
Robert has pointed out the problem, but Holger has hit the nail on the
head: "...there are no pointers to a clear direction...". I have taken
this quote out of the context of NetBSD. It's true for all of the 0.1
386BSD-based developement efforts: NetBSD, the patchkit, the interim
group (almost the same as the patchkit), and even 0.2. And now there
is yet another "splinter": MACH; unless they pick one and stick with
it, they are just another group doing their own thing. This is four
that I count; Robert was close in his estimate.
I am nearly constantly frustrated in the inability to tie everything
together; the NetBSD tried to do this, perhaps with the idea that the
patchkit would move over to NetBSD and there wouldn't be the schizm.
Instead, the patchkit has remained "mainstream" and NetBSD has not
supported itself within its framework (a perhaps impossible goal, given
that the patchkit was never intended to do some of the things it now
does). I can understand their points; I have heard Bill described as
"the code hotel" (code checks in, but it doesn't check out); it's very
hard to contribute to something when you don't get the advantage of
other people's contributions in return except in final release. Think
of it is desiring "most favored nation" trade status.
At present, I don't believe that there's anything that can be done as
far as apparent direction of the groups is concerned; I think they are
closer in ideal than they are given credit for, and I believe that a
lot more behind the scenes cooperation is going on (at least between
the patchkit/interim and NetBSD groups) than is commonly believed.
I know that I and various other members of the different factions talk
to Bill on a semi-regular basis, so we aren't that far out of sync.
Public appearance/perception is unlikely to change for a long time, if
ever.
Now that I've offended everyone, I'm going to crawl back into my hole
and code.
Terry Lambert
te...@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Mark Sienkiewicz
count the ">" symbols. :)
In article <1993Jun9.1...@gmd.de> ve...@mururoa.gmd.de (Holger Veit) writes:
>In article <1993Jun9.1...@rwwa.COM>, wi...@rwwa.COM (Robert Withrow) writes:
>|> It should be clear to everyone that this sort of thing hurts us all. Especially
>|> when it appears to me (from the outside) that the only real reason for the
>|> proliferation of competing kernels is the personality conflicts between the
>|> various developers. I say this because I have yet to see a *technical* conflict
>|> between the various systems that could not be resolved if there were a *true*
>|> spirit of cooperation amoung the developers.
...
>I strongly second this. The situation is unsatisfying for every participant:
>the core developers, the application developers and the users (who are most
>irritated what to choose). There have been omissions in the past, in that
>there was no system of communication and regular update of 386bsd. This way
>NetBSD was a consequence, and the idea itself was not bad. The
>problem arises that NetBSD now has become an own group with different goals
>than 386bsd. The difficulty is that the goal is not just fixing known bugs
>with corrections from the known pool of corrections, but more and more
>moving into different design directions (for what reasons, ever; I have my
>own opinions here).
hmmm... what could "*true* spirit of cooperation" mean? Everybody would like
for _everybody_else_ to cooperate by not having their own opinions. In the
real world, this rarely happens.
Are you suggesting that only people named "Jolitz" have a right to have
their own goals and their own "design directions"? Or are you suggesting
that the Jolitz's should stop pursuing their own interests and throw their
efforts into Netbsd?
If the 386bsd 0.2 group and the Netbsd group are going to work together
to make _ONE_ BSD system for 386, 486, HP300, and CT Miniframe computers, one
of them is going to have to give up their own goals.
So which one has the less worthy goals, and who should abandon their own
desires in favor of yours?
Mark S.
Charles Hannum
In article <C8DGs...@kithrup.com> s...@kithrup.com (Sean Eric Fagan)
writes:
>
> In article <1993Jun9.1...@coe.montana.edu> na...@cs.montana.edu
> (Nate Williams) writes:
>
>> The sad thing is that there have already been enough kernel changes
>> in NetBSD to make all of the binaries created under it useless in
>> 386BSD. (New a.out format).
This is a pretty small change in the kernel. It has the nice benefits
of making most executables 4K smaller, making *NULL core dump (which
led me to fix a bunch of bugs from Net/2), and allows us to run BSDI
executables.
> (By updating <a.out.h>, and rebuilding the entire system, things
> like size(1) et al should pick up everything.
This isn't really true, unfortunately. In particular, `strip' was
braindead. (The BSDI version also has an interesting and amusing bug
in it--but it's not fatal.)
--
\ / Charles Hannum, myc...@ai.mit.edu
/\ \ PGP public key available on request. MIME, AMS, NextMail accepted.
Scheme White heterosexual atheist male (WHAM) pride!
Bakul Shah
>And so I say again, ``Kernel developers, please pull on the same end of the
>rope''. Re-unify into *one* BSD derived kernel for 386 architectures.
This is not likely to happen. There are already quite a few
versions and they are not just because of different personalities
but because of different goals. Any attempt to unify them will
simply create yet another version. Also, none of these versions
are significantly better than others.
A more realistic goal might be to agree on a binary interface
for the common functions, and there is a very high degree of
commonality at this point, so that the same binary can be made to
run on multiple machines. There needs to be a similar standard
definition for the kernel<->driver interface, for shared
libraries, for loadable drivers etc.
I am not holding my breath for even this but one way to start
might be to poll people on which features they like most in
various flavors of Unix, drivers, etc. and vote for *existing
interfaces* based on that. With enough peer pressure we just
might convince implementers to follow these interfaces. [Unlike
the commercial arena we don't have to choose a solution that puts
everyone at an equal _disadvantage_]
It seems to me that the *users* of BSDI, 386BSD, NetBSD, Linux
will benefit most from this sort of evolution. They can still
use their favorite set of tools and on whatever system they want
(following whichever of copyleft, copyright or copycenter
policies they want :-) Agreeing on interfaces also allows
implementors considerable freedom.
Bakul Shah <b...@BitBlocks.com>
Chuck Bacon
Some hobbiests over their dont no there ass from a whole in the ground.
--
Chuck Bacon - cr...@helix.nih.gov ( alas, not my 3b1 )-:
ABHOR SECRECY - DEFEND PRIVACY
Peter da Silva
> And so 386BSD, like many of its predecessors, has degenerated into
> four mutually-incompatible groups:
> - Chris Demetriou and followers
> - The patchkit people
The core people in these two groups appear to be the same people. So are some
of the people on the periphery (I send patches in to both, for example).
> - J. Random User
Most of the NetBSD and Patchkit supporters *are* J. Random User.
> - Bill and Lynne
Bill and Lynne were vital to starting this off, but they now seem to have
marginalized themselves by not interacting with anyone other than to make
reassuring noises and gripe about bugs in the patchkit. There are probably
major bugs in the patchkit, but without some feedback there's really no way
to tell what they are, or how to fix them. I appreciate that what the
Jolitzes are doing is tremendously complex and difficult, but if they want
to take political control of this thing again they need to take some time
out to release code on an ongoing basis, because that's what it takes to
keep people actively interested.
Me, I'll continue to be a NetBSD supporter, but if the next release of the
patchkit has solid multiport serial card support I'll stick with it until
a decent update mechanism for NetBSD emerges.
--
Peter da Silva. <pe...@sugar.neosoft.com>.
`-_-' Har du kramat din varg idag?
'U`
"Det er min ledsager, det er ikke drikkepenge."
Nate Williams
>Throughout the history of BSD
>development (and, indeed, UNIX development in general), large groups
>interested in working on improving the system have degenerated into
>cliques. This is not necessarily bad (at least from the point of view
>of someone who has their own theory of OS design). There are a few
>warning signs:
>
>1) One or two people appear as ``spokespeople'' for a group.
>2) People who don't belong to mailing-list X are considered
> unimportant and not worth paying attention to.
>3) Developers make ad-hominem attacks against people who
> have different goals than they do.
>[this is not a complete list]
>
Hmm, so if I hear you correctly we should.
1) Let everyone post a message if they belong to said group, and that
way everyone in the world can see what each and every member of the
group agrees with, even if it's the same thing worded differently.
2) Put everyone that every posted anything to a newsgroup, or who might
have interest on a mailing list.
3) Not point out what people believe to be errors, and blindly accept
everything anyone does as being perfect.
>As Sergeant Gilks (in ``Dirk Gently's Holisitic Detective Agency'')
>puts it, the trouble with smart people is that they assume nobody else
>is smart either.
Agreed, and that's the point for #3. Most people involved think they have
a clue, and hope that their solution is the best one.
>And so 386BSD, like many of its predecessors, has degenerated into
>four mutually-incompatible groups:
>
>- Chris Demetriou and followers
>- The patchkit people
>- J. Random User
As has been pointed out before, all of the above are working together and
sharing information BOTH WAYS. I talked with Chris yesterday, and I told
him a bunch of code I'm going to *steal* from NetBSD, and he told me that
he was waiting for us to finish up some code that he is going to *steal*
from us. The information goes both ways, and neither group is upset about
it.
>- Bill and Lynne
Unfortunately, up to this point, this has been a black hole, where J. Random
User doesn't see what is being done or what has been done except for big
bursts here and there. This is very unfortunate, since it would be nice to
1) Know any bugs that existed in code that has been donated, so that they
can be fixed by the person that understands the code the best, the author
2) Make suggestions and improvements on code that others have donated
3) Make suggestions on design decisions that one person may have
experience in.
etc..
But this is Bill's choice, and we have to live with it.
I guess folks should realize that I don't believe anyone (??) has the
intention of alienating or hoarding code. If you want to get involved,
send some email to the interested parties, and see what happens. If you
don't agree, then go and do your own thing. But, the advantage of
groups is that it allows you to bounce your ideas of other qualified
people, and it brings you together for a common purpose so that the goal
can be met more timely and efficiently.
I'll get off my soapbox now.
Chris G. Demetriou
just say thatt i thank DEC for their vt220 keyboard layout. NOT! 8-)
In article <C8DLB...@BitBlocks.com> b...@BitBlocks.com (Bakul Shah) writes:
.A more realistic goal might be to agree on a binary interface
.for the common functions, and there is a very high degree of
.commonality at this point, so that the same binary can be made to
.run on multiple machines. There needs to be a similar standard
.definition for the kernel<->driver interface, for shared
.libraries, for loadable drivers etc.
first i must ask "what is a common function"?
i actually think that this is realistic, and i've gone out of my
way thus far and plan to continue to do so in the future, to
insure that 386bsd and or "Interim group" binaries will run on
NetBSD. (note that in the future this might not be the
default method of operation; you might need to compile a kerne
with a "COMPAT" flag...)
in the future, this will be more difficult, but i am still
committed to it, only serious architectural change by
one of the other groups will change my mind... whether or
not the *other groups* support NetBSD's e.g. magic numbers
is not my decision... (one of the thing's that's going on
right now is that we're in the process of making the
a_magic and a_mid fields of the a.out header byte-order
independent, so that one can easily tell the diff between
various architectures' binaries...)
as for binary interfaces for things like shlibs, loadable
kernel modules, etc, it's not quite that simple.
first of all, i think shared libraries should be possible,
but that fact that Bill has decided to adopt a shared libararies
package which i refuse to adopt could make that more difficult.
as for loadable kernel modules, i've looked at Terry's
implementation, it's currently in our (NetBSD's) tree, and i'm
using it to develop a file system. all in all, it's a *SLICK*
package!
however, there are other concerns:
between different versions, kernel interfaces *must*
change, to allow for the evolution of the system.
for example, in our current sources, the NetBSD gang
has made tty structures dynamically allocated, fixed a problem
with the ring buffer code, where it was using chars instead
of a wider data type (and you need to use the latter to keep the
flags associated w/the characters), and also we've imporoved
the kernel select interface once again.
none of these are major changes, and all are arguably sound
architectural changes. and all of them will make
dropping in a binary absolutely impossible. (assuming you
want the system to live for a while... 8-) actually, all
of *those* also introduce source code incompatibilities,
in the first case an extra pointer, in the second char vs. rbchar,
in the third using functions rather than doing everything by hand...)
(btw :i say arguably sound because i know quite well that i'm not the
final arbiter of taste and architecture... that's why, in NetBSD,
a *group* of developers exists, so we can look at changes the
others are making, see what they're up to, and question if the
changes are appropriate. it's not design by committee, it's
sort-of design-review by your peers...)
just random ramblings...
chris
A Wizard of Earth C
>must be idempotent. 2) No header file should depend on the previous
>inclusion of another, with the exception of systm.h. 3) ALL repeat
>ALL functions and function pointers MUST be prototyped. My standard
>for code is simpler: all code should compile with no warnings under
>`gcc -O -Wall', or be commented with a reason why the warning is not a
>problem. Fixing this is a lot harder than fixing the header files.]
I'm curious (and I suppose other people are, or I would be emailing about
this instead of asking publically): Under item 3, how do you resolve programs
which *must* include stdio.h *and* systm.h (which has the kernel printf
prototype in it)?
Basically, I can think of three cases where this would be necessary, one
that should impact you (kernel modules -- by the way did you get my recent
code release on this? -- specifically, the module loaders, and more
specifically, because of defined module classes int the header file that
defines the module type. At the very least, the module stat program, which
must printf in user space the module type as defined in the header).
>As a result of this and other hacking that I've done, my
>system---originally 386BSD plus a selection of patchkit 0.1
>patches---has already diverged so far from anybody else's base that I
>can no longer take the time required to manually merge in
>modifications made by any other group, including the patchkit.
I tend to put myself in the same boat.
>(However, I am willing to share my working source tree with anyone
>else who's interested; send mail to wol...@tsornin.emba.uvm.edu for
>information.)
Ah yes! Yet another version! Maybe I should release my tree as well... 8-).
Kelly Murray
back, and it seems things have become even less clear since then.
I realize I probably don't hold much credibility with you folks, but let me give
some parting comments before I stop reading 386BSD news groups.
I /really wanted/ to use BSD for my new project, as it seems the maturity level
over here is so much higher than Linux, and there is no GPL nonsense to deal with.
I have yet to see a clear explanation of what the goals and directions are
of the BSD camps.
Creating a platform for OS research seems to be primary,
and not to create a free Unix system for people to use and play with,
which is the primary goal behind Linux. I thought that NetBSD was oriented
towards this, but I'm not sure anymore.
In any case, I've decided to do my project under Linux primarily because so many
people use it, which means the impact of the software I create will be greater.
The idea behind the project is to build an Object Oriented Operating System,
with Lisp (CLOS really) being the underlying data and programming model.
I see it as the next step after NextStep. Yes, it's too ambitious, but I plan to start
small with the user-interface and work my way down to paging hardware, eventually
it won't be Unix at all (if you want to get involved, I'm looking for help).
I would like to see BSD become as popular as Linux, but that will only happen
if this is actually a primary goal for the software. I would strongly suggest
that such a software system be called "BSDFree."
Perhaps I could participate with such a development group,
but for now it will be Linux.
-Kelly Murray
Garrett Wollman
>I'm curious (and I suppose other people are, or I would be emailing about
>this instead of asking publically): Under item 3, how do you resolve programs
>which *must* include stdio.h *and* systm.h (which has the kernel printf
>prototype in it)?
By moving the definition of `struct sysent' into another file, if that
ever arises. That's the only thing in systm.h that any user program
has any business touching....
>Basically, I can think of three cases where this would be necessary, one
>that should impact you (kernel modules -- by the way did you get my recent
>code release on this? -- specifically, the module loaders, and more
>specifically, because of defined module classes int the header file that
>defines the module type. At the very least, the module stat program, which
>must printf in user space the module type as defined in the header).
I'm having trouble parsing this. If a program is running in user
mode, it doesn't have any need for five gazillion prototypes for
kernel functions. If it's running in kernel mode, it doesn't have
access to stdio. I guess I /could/ wrap all of systm.h with #ifdef
KERNEL, but it seems singularly pointless since I defined systm.h as
being a header that kernel sources /and only kernel sources/ have any
business using.
>Ah yes! Yet another version! Maybe I should release my tree as well... 8-).
Sure, go right ahead! (But obviously you might need to check with
your legal eagles first...)
A Wizard of Earth C
>In article <1993Jun11.0...@fcom.cc.utah.edu> te...@cs.weber.edu (A Wizard of Earth C) writes:
>>I'm curious (and I suppose other people are, or I would be emailing about
>>this instead of asking publically): Under item 3, how do you resolve programs
>>which *must* include stdio.h *and* systm.h (which has the kernel printf
>>prototype in it)?
>
>By moving the definition of `struct sysent' into another file, if that
>ever arises. That's the only thing in systm.h that any user program
>has any business touching....
>
>>Basically, I can think of three cases where this would be necessary, one
>>that should impact you (kernel modules -- by the way did you get my recent
>>code release on this? -- specifically, the module loaders, and more
>>specifically, because of defined module classes int the header file that
>>defines the module type. At the very least, the module stat program, which
>>must printf in user space the module type as defined in the header).
OK, say I have a single header file shared between the kernel and user
portions of a loadable kernel module interface. I have both the per type
module structures, such as:
============================================================================
#ifndef _lkm_h_
#define _lkm_h_
/*
* Supported module types
*/
typedef enum loadmod {
LM_SYSCALL,
LM_VFS,
LM_DEV,
LM_STRMOD,
LM_EXEC,
LM_MISC
} MODTYPE;
#define LKM_VERSION 1 /* version of module loader*/
/****************************************************************************/
/*
* Loadable system call
*/
struct lkm_syscall {
MODTYPE lkm_type;
int lkm_ver;
char *lkm_name;
int lkm_offset; /* save/assign area*/
struct sysent *lkm_sysent;
struct sysent lkm_oldent; /* save area for unload*/
};
============================================================================
And the status function returned information structure:
============================================================================
#define LMSTAT _IOWR( 'K', 11, struct lmc_stat)
[ ... ]
/*
* Get module information for a given id (or name if id == -1).
*/
struct lmc_stat {
int id; /* IN: module ID to unload*/
char name[ MAXLKMNAME]; /* IN/OUT: name of module*/
int offset; /* OUT: target table offset*/
MODTYPE type; /* OUT: type of module*/
char *area; /* OUT: kernel load addr*/
int size; /* OUT: module size (pages)*/
unsigned long private; /* OUT: module private data*/
int ver; /* OUT: lkm compile version*/
};
============================================================================
Both in the same header file. I have the choice of including everything
in the same file (/usr/include/sys/lkm.h), in which case anything that
includes the header must also include the definitions of systent, cdevsw,
bdevsw, vfssw, and any other defined module type specific kernel structure
include files. The actual list looks like:
#define printf I_HATE_ANSI
#include <stdio.h>
#undef printf
#include <stdlib.h>
#include <sys/param.h>
#include <sys/ioctl.h>
#include <sys/systm.h>
#include <sys/conf.h>
#include <sys/mount.h>
#include <sys/exec.h>
#include <sys/lkm.h>
#include <a.out.h>
#include <sys/file.h>
#include <sys/errno.h>
(the "I_HATE_ANSI" gets around the multiple definition of printf. It's a
hack).
OR, I could break it into two files... the problem is that the available
module types will probably vary between two systems (like 386BSD and Linux,
for instance, since it will be a long time before Linux supports loadable
streams modules, but my kernel does now). This means the enumerated types
which may be returned in the stat function will be system dependant (ie: it
should be in a /usr/include/sys file) even if the stat and other I/O call
definitions belong in a /usr/include file (being, supposedly, system
independant). The stat function has to be aware of all possible module
types so that it can report the type to the user as part of the status
information.
The third alternative is to disable the reporting of the module type.
The first alternative is hackable, but is totally inelegant; the prototype
definitions for kernel functions do *not* belong in a mandatory file for
use for any other reason, because they conflict with standard library
prototypes.
The second soloution is untenable; threee files would work, but this is a
rabid pollution of the include file name space used by the compilers and
is only being fored on us because someone decided putting kernel function
prototypes in a mandatory file would be a good idea. Besides name space
pollution (which is reason enough, in my book), it divorces the meaning
from two of the files. You end up having to print them out do understand
the interrelationships.
The third alternative is information hiding for no better reason than a
workaround to a bad prototype location. Better to use the inelegant hack
shown, since hiding easily available and useful information is the epitomy
of bad programming.
The conclusion I was attempting to lead you to was that systm.h was a piss
poor location for prototypes, and that it is bad design for conflicting
prototype to be potentially required by virtue of header file layout.
Another example might be made of any program which requires promiscuous
knowledge of kernel structures in user space. Any number of debugging
tools (like crash or a VFS debugger) or normal system utilities (like
vmstat, ps, w, shmstat, etc., etc.) will also fall into this trap; user
space utilties should not even have these prototypes, even if they *must*
access the data structures, since they do not call the functions.
An #ifdef KERNEL around the prototype portion of systm.h is probably not
sufficient. Consider, if you will, a "bottom end VFS interface" defined
in user space, with a combined pseudo-device/VFS module loaded into the
kernel. A user process is built to use these two interfaces to implement
a user-space hook for VFS developement (ie: I can debug new file systems
with my favorite graphical debugger and much less chance of panic'ing the
system out from under myself). The user space interface must allow
calling of kernel functions as of the process were running in the kernel
at the time. What is needed is a partial prototype definition (if the
prototypes are used at all, since their utility lies in the realm of
people to lazy to run lint) for the block I/O interface and DNLC portions
of the kernel, *without* system call and other prototypes being defined.
This is, obviously, wishful thinking. I can build a user-space VFS
testbed easily, but the kernel is not sufficiently compartmentalized as
it now stands to segregate the prototype definitions by function without
a serious (and probably unacceptable) reorganization of the kernel itself
and all associated header files.
If "eveything *must* be prototyped", then we have more of a job than just
providing the prototypes.
Comments?
Christopher Maeda
>
>In any case, I've decided to do my project under Linux primarily because so many
>people use it, which means the impact of the software I create will be greater.
>The idea behind the project is to build an Object Oriented Operating System,
>with Lisp (CLOS really) being the underlying data and programming model.
>I see it as the next step after NextStep. Yes, it's too ambitious, but I plan to start
>small with the user-interface and work my way down to paging hardware, eventually
>it won't be Unix at all (if you want to get involved, I'm looking for help).
If you are writing code at user level in Common Lisp and CLOS, then it
shouldn't matter what operating system you use. Common Lisp runs on
everything.
If you plan to write an object oriented operating system, you might
want to read "Why Object Oriented Operating Systems Are Boring" in the
proceedings of the 1991 International Workshop on Object Orientation
in Operating Systems (IWOOOS-91) before you start.
--
Chris Maeda, Grad Student and RetroGrouch <cma...@cs.cmu.edu>
"A unix signature isn't a return address, it's the ASCII equivalent of
a black velvet clown painting. It's a rectangle of carets surrounding
a quote from a literary giant of weeniedom like Heinlein or Dr. Who."
Garrett Wollman
/in/ systm.h /except/ for the declaration of struct sysent and a whole
mess of prototypes. All the other ``interesting'' structures (bdevsw,
cdevsw, ttysw, netif, etc.) are already elsewhere.
Your situation where one source module contains both kernel and user
bits is a bit difficult. (And printf() isn't the only function
contained in systm.h, either.) Ok, here's what I've done:
- struct sysent is no longer in systm.h.
- Include <sys/sysent.h> to get access to struct sysent from either user
or kernel code. (If you are in the kernel, it also declares sysent[]
and nsysent for you.)
- Both kernel source files (yes, all two of them!) have been modified
appropriately. The only files involved are makesyscalls.sh (which
creates init_sysent.c) and i386/i386/trap.c.
Here is my current value of systm.h. (Had I to do it over again, I
would have done this all in kernel.h.)
------------------------------------
/*-
* Copyright (c) 1982, 1988, 1991 The Regents of the University of California.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors.
* 4. Neither the name of the University nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* @(#)systm.h 7.17 (Berkeley) 5/25/91
*
* PATCHES MAGIC LEVEL PATCH THAT GOT US HERE
* -------------------- ----- ----------------------
* CURRENT PATCH LEVEL: 1 00061
* -------------------- ----- ----------------------
*
* 11 Dec 92 Williams Jolitz Fixed panic:remrq and tty handling
*/
#ifndef __h_systm
#define __h_systm
#include "param.h"
#include "types.h"
/* The above two are required for this file. The following are headers
which are needed by almost every file:
*/
#include "proc.h"
#include "user.h"
#include "malloc.h"
/* Declare some stuff */
struct proc; struct vnode;
extern const char *panicstr; /* panic message */
extern char version[]; /* system version */
extern char copyright[]; /* system copyright */
extern int nblkdev; /* number of entries in bdevsw */
extern int nchrdev; /* number of entries in cdevsw */
extern int nswdev; /* number of swap devices */
extern int nswap; /* size of swap space */
extern int selwait; /* select timeout address */
extern u_char curpri; /* priority of current process */
extern int maxmem; /* max memory per process */
extern int physmem; /* physical memory */
extern dev_t dumpdev; /* dump device */
extern long dumplo; /* offset into dumpdev */
extern dev_t rootdev; /* root device */
extern struct vnode *rootvp; /* vnode equivalent to above */
extern dev_t swapdev; /* swapping device */
extern struct vnode *swapdev_vp;/* vnode equivalent to above */
extern int boothowto; /* reboot flags, from console subsystem */
#ifdef KADB
extern char *bootesym; /* end of symbol info from boot */
#endif
/* insque and remque */
#ifdef __GNUC__
static inline void
insque(a, b)
void *a;
void *b;
{
register struct prochd *element = a, *head = b;
element->ph_link = head->ph_link;
head->ph_link = (struct proc *)element;
element->ph_rlink = (struct proc *)head;
((struct prochd *)(element->ph_link))->ph_rlink=(struct proc *)element;
}
static inline void
remque(a)
void *a;
{
register struct prochd *element = a;
((struct prochd *)(element->ph_link))->ph_rlink = element->ph_rlink;
((struct prochd *)(element->ph_rlink))->ph_link = element->ph_link;
element->ph_rlink = (struct proc *)0;
}
#else
extern void insque __P((void *, void *));
extern void remque __P((void *));
#endif /* __GNUC__ */
typedef void (*timeout_t) __P((caddr_t));
/*
* General function declarations.
*/
int nullop(); /* WARNING WILL ROBINSON */
int enodev(); /* All these routines are potentially */
int enoioctl(); /* called with differing arguments. */
int enxio(); /* For this reason, they cannot be */
int eopnotsupp(); /* prototyped without causing conflicts. */
/* select() support functions */
int selscan __P((struct proc *p, fd_set *ibits, fd_set *obits,
int nfd, int *retval));
int seltrue __P((dev_t dev, int which, struct proc *p));
void selwakeup __P((pid_t pid, int coll));
/* SPL Levels */
int splhigh __P((void));
int splclock __P((void));
int splsoftclock __P((void));
int splbio __P((void));
int spltty __P((void));
int splimp __P((void));
int splnet __P((void));
int splnone __P((void));
int spl0 __P((void));
int splx __P((int));
/* Initialize the world */
void startrtclock __P((void));
void consinit __P((void));
void vm_mem_init __P((void));
void kmeminit __P((void));
void cpu_startup __P((void));
void rqinit __P((void));
void vm_init_limits __P((struct proc *));
void vfsinit __P((void));
void mbinit __P((void));
void shminit __P((void));
void ifinit __P((void));
void domaininit __P((void));
void swapinit __P((void));
void enablertclock __P((void));
/* Default network interfaces... */
int slattach __P((void)); /* XXX */
void loattach __P((void));
/* Scheduling */
void roundrobin __P((caddr_t));
void schedcpu __P((caddr_t));
void softclock();
void setsoftclock __P((void));
void setpri __P((struct proc *));
void gatherstats(); /* cannot prototype */
void remrq __P((struct proc *));
void setrq __P((struct proc *));
void swtch __P((void));
void setrun __P((struct proc *));
void vmmeter __P((void));
void updatepri __P((struct proc *));
/* Timeouts and sleeps */
void timeout __P((timeout_t, caddr_t, int));
void untimeout __P((timeout_t, caddr_t));
void wakeup __P((caddr_t));
int tsleep __P((caddr_t, int, const char *, int));
void sleep __P((caddr_t, int));
/* User data reference */
int useracc __P((caddr_t, int, int));
int kernacc __P((caddr_t, int, int));
int copystr __P((void *kfaddr, void *kdaddr, u_int len, u_int *done));
int copyinstr __P((void *udaddr, void *kaddr, u_int len, u_int *done));
int copyoutstr __P((void *kaddr, void *udaddr, u_int len, u_int *done));
int copyin __P((void *udaddr, void *kaddr, u_int len));
int copyout __P((void *kaddr, void *udaddr, u_int len));
int fubyte __P((void *base));
int fuibyte __P((void *base));
int subyte __P((void *base, int byte));
int suibyte __P((void *base, int byte));
int fuword __P((void *base));
int fuiword __P((void *base));
int suword __P((void *base, int word));
int suiword __P((void *base, int word));
/* Miscellaneous */
int fdopen __P((dev_t, int, int));
void logwakeup __P((void));
void addlog __P((const char *, ...));
void log __P((int, const char *, ...));
void printf __P((const char *, ...));
int sprintf __P((char *, const char *, ...));
void uprintf __P((const char *, ...));
void tablefull __P((char *));
/* Extrema */
unsigned int min __P((unsigned int, unsigned int));
unsigned int max __P((unsigned int, unsigned int));
int imin __P((int, int));
int imax __P((int, int));
/* routines which never return */
#ifdef __GNUC__
volatile void sched __P((void));
volatile void exit __P((struct proc *, int));
volatile void cpu_exit __P((struct proc *));
volatile void panic __P((const char *));
volatile void boot __P((int));
#else
void panic __P((const char *));
void sched __P((void));
void exit __P((struct proc *, int));
void cpu_exit __P((struct proc *));
void boot __P((int));
#endif
/* string functions */
int strlen __P((const char *));
int strcmp __P((const char *, const char *));
char *strncpy __P((char *, const char *, int));
char *strcat __P((char *, const char *));
char *strcpy __P((char *, const char *));
void bcopy __P((void *from, void *to, u_int len));
void ovbcopy __P((void *from, void *to, u_int len));
void bzero __P((void *, u_int));
int bcmp __P((void *str1, void *str2, u_int len));
int scanc __P((unsigned size, u_char *cp, u_char *table, int mask));
int skpc __P((int, u_int, u_char *));
int locc __P((int, unsigned, u_char *));
int ffs __P((long));
/* Debugger entry points */
int Debugger __P((void)); /* in DDB only */
int read_symtab_from_file __P((struct proc *,struct vnode *,const char *));
#endif /* __h_systm */
------------------------------------
Theo de Raadt
rope''. Re-unify into *one* BSD derived kernel for 386 architectures.
This is a weak goal.
We need one BSD derived kernel that runs on *all* architectures. This is
the most important goal we have for NetBSD: removal of all the machine
dependent kludges in 386BSD (which were not in NET2, note that.)
tdr.
--
This space not left unintentionally unblank. der...@fsa.ca
Theo de Raadt
> with porting my codrv driver that have been introduced with the move from
> 386bsd-0.1 to NetBSD-0.8 to NetBSD-0.8a (I have never had this amount of
> new problems with the OS besides my own faults before, and I seriously consider
> dropping any support for NetBSD, as long as there are no pointers to
> a clear direction).
Perhaps you have not noticed why the port is so hard. Please tell me which
out of the following things is not a worthwhile and important change.
1. select is now handled inside the kernel in a really nice simple way.
Chris called it "one-stop-shopping"...
2. ^V now works. Come on everyone, type ^V^D<return> at your shell prompt...
3. prototyles for getc() and ungetc() now work, since the kernel functions
are now called rbgetc() and rbungetc().
4. It is now possible to compile a kernel without the console driver in it.
There is no reason that machine independent code in the kernel should have
called entry points in pccons.c (that is what cons.c is for)
The hp300 does *not* have an sgetc() function in it's console device
driver.
5. tty structures are now allocated dynamically. This saves 7K of bss per
pseudo tty or serial console. (Means it's possible to build a full scsi
kernel with 32 pty's and DDB. If anyone says that this is solved by having
the kernel load above 1M, I welcome them sending me code that does this.)
I know that there will be considerable changes with 386bsd-0.2,
and I accept that there are things to do, but what the hell is the
reason of changing several interfaces from version to version?
Many of these changes are being made as they are discovered to be bugs.
Not that I really want to slime him, many of the above listed things
are fixes to Jolitz code. Jolitz will have to make many of the same changes.
(esp. the ^V fix.)
> The interpretation of "removing several of Bill's hacks" (as mentioned in
> the recently published list of changes in NetBSD) is a relative thing; it
> appears that there is a "back to the roots" stream working on NetBSD to return
> to the "NET/2" which is "the BSD" (and the starting point for 4.4BSD) and
> everything people contribute, who do not belong to this scene, should be removed.
Yup. Back to roots, because you know, NET2 was fairly easy to port to other
machines. 386bsd is not. Taken a look at 386bsd ufs/ufs_disksubr.c lately?
What the heck is DOS doing in a machine independent file? Read through our
CHANGES file and see how many of the changes are for machine independence.
I'd not mention 90% of those are because of how Jolitz wrote things, but
that's a fact.
> Of course this introduces the old bugs that are still in Net/2 back into
> the current release, where they have been fixed before (or you might also
> call it "hacked away"), but at least it is "different".
Where do you get this idea? Ok, whatever you say, yes, we just love
putting old bugs back in the code.......
> I fear the schisma has been there since the earliest days of 386bsd; but
> the intensity has now increased (and this is the dark side of NetBSD
> and certainly not for the benefit of the usership).
One of our major goals is to make the code run on machines other than i386.
You would not believe how much Jolitz code has to be rewritten to have this
happen.
Note, if you send in a patch for NetBSD to me, I will install it cleanly
(thinking about machine independence issues and other changes that we're
making) and will tell you how I put it in the sources and why. Our
turnaround for merging patches into the source tree has lately been
around a day.. and you get mail saying *YES, IT IS IN THERE*.
Theo de Raadt
> But one of the goals for "NetBSD" is that it be ported to non-386 platforms.
> Given some things Chris has said, in public and private, I am led to believe
> that is happening;
oh... it's happening.. trust me :-)
> also, by tracking 4.4 as much as possible, NetBSD may be
> in a better position to take advantage of various other ports that exist,
> if are not quite yet available.
Does someone who fiddles with 4.4 want to remind people how many
architectures 4.4 has been ported to?
> For 386bsd 0.2, everything would have to
> start from scratch.
You've got our comments. Bill, want to comment on the truth-value of this
last sentence?
Chris Torek
(Theo de Raadt) writes:
>Does someone who fiddles with 4.4 want to remind people how many
>architectures 4.4 has been ported to?
The 4.4 tree has machine-dependent kernel directories for:
hp300 -- HP 9000/300 series 680x0 workstations
i386 -- need I explicate? :-)
luna68k -- 680x0 workstations from Omron (a Japanese company)
news3400 - Sony NEWS workstations (R3000 based)
pmax -- DEC PMAX workstations (R3000 based)
sparc -- Sun SS1, SS2 series (i.e., only older sparc boxes)
tahoe -- CCI/Harris/ICL/Sperry `tahoe' machines
vax -- where `vmunix' began
Not all of these work; in particular, the vax and tahoe support is
thoroughly out of date, and the 386 support is way behind the NetBSD in
stability, if it works at all. I personally use hp300 and sparc boxes
running 4.4BSD; these seem to be as stable as anything using the Mach
2.5-based VM can be. I know very little about the other three ports.
--
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA Domain: to...@ee.lbl.gov
Terry Kennedy, Operations Mgr.
> Not all of these work; in particular, the vax and tahoe support is
> thoroughly out of date, and the 386 support is way behind the NetBSD in
> stability, if it works at all. I personally use hp300 and sparc boxes
> running 4.4BSD; these seem to be as stable as anything using the Mach
> 2.5-based VM can be. I know very little about the other three ports.
I got my "4.4BSD is complete" letter today, complete with check-boxes
for which binary architecture I'd like. The choices are the hp300, the
DECstation (MIPS) boxes, and Sparcstation I/II.
There was some work done with 4.4/VAX here, but we decided to move to
386's as a more cost-effective solution. Paul Vixie was working on the
VAX VM stuff as well, but I never heard back if he got it working.
Terry Kennedy Operations Manager, Academic Computing
te...@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA
te...@spcvxa.spc.edu +1 201 915 9381
Theo de Raadt
(signed to unsigned).
Uhhm. No. The change is from (char to short). ^V is implimented by
fiddling with the the 8th bit (counting from 0, ie. 0-7) and there is
no 8th bit (0x100) in 8 bit chars. The clists in BSD used shorts as I
understand, but the Jolitz ring buffer code used chars. Functions were
supplied to copy to/from clists to buffers: q_to_b() and b_to_q(). In
386BSD, there were a few device drivers that used bcopy() for this
purpose; these had to be fixed. The new functions I created are called
rbpack() and rbunpack() (I may want to change those names.)