NBBY

[Michael Bloom]

In article <2800 at nuchat.UUCP> orion at nuchat.UUCP (Roland Dunkerley) writes:
 > Can anyone tell me what the symbol NBBY (#defined in sys/param.h under
 > 4.3 BSD, I think) represents?

This stands for number of bits per byte, usually 8.

 > Another problem I've come across: How does one go about changing
 > the value of nsysent and adding entries to sysent (ie: adding sys
 > calls) on a binary-only site?  Has anyone had any success in doing
 > this?  (on our system these are compiled into
 > /etc/atconf/moduled/kernel/os.o)

On an s5r3 system, you should be able to find the definition of sysent
in systm.h.  In att distributions, there are many unused entries. The
fact that you have them compiled into os.o rather than sysent.o does
not look encouraging, however.

 > I'm working on porting the BSD ipc facilities to System V Rel 3.0 /
 > 80386.

You may well find this impossible to do properly without source. For example
the unix domain requires the use of namei(), whose calling interface differs
from BSD.  You'll probably have to scratch the unix domain.

Also many innocuous differences (some of which are described below)
will get in your way as well.

Your kernel probably has a function called pfind whose purpose is
totally different from the pfind used by the BSD code. 

The BSD code expects copyin and copyout to return errno's to pass back
to the user, which the ATT routines do not return.

The ioctl interface is also different.  BSD ioctl does copyin's to the
kernel stack in the highest level ioctl routines, passing a pointer to
the kernel resident data to the lower level ioctl routines, while the
ATT ioctl passes a pointer to user level data to the lowest level routines.

There are one or two places in the network code (select comes to mind)
where untimeout gets called.  This is easy under BSD, since the call
takes the same (routine,arg) pair passed to timeout.  On sys5,
however, timeout returns a unique integer id which you later pass to
untimeout instead of a (routine,arg) pair.  You'll need some place to
safely stash this id till you're ready to use it.

Select poses some other problems as well.  To be able to use it for
anything other than sockets, you'll need to modify driver code.
You'll have to be able to add proc pointers and flag bits to driver
data structures. If you have streams drivers, you could effectively
merge select and poll by defining SSEL as SPOLL and selwait as
pollwait.  This would require adding a stream_select() routine and
making a minor change to the poll() code to deal with a formerly
"cannot happen" condition that will occur when selwakeup is called
following a select collision. Unfortunately, impossible without
source.

You also need to provide various pieces of BSD functionality that are
needed by user applications (sigsetmask, restartable syscalls,
setpgrp(x,y), TIOCSPGRP, etc) without breaking SVID conformance (i.e.
existing ATT programs should still work without change).

It took me about eight weekends to do what you're proposing, but I
never would have tried doing it without source. (Sorry, I can't give
out my port, since it involves changes to ATT code).