orion@nuchat.UUCP (Roland Dunkerley) (01/08/89)
Can anyone tell me what the symbol NBBY (#defined in sys/param.h under 4.3 BSD, I think) represents, I'm working on porting the BSD ipc facilities to System V Rel 3.0 / 80386. 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) Thanks in advance, Roland Pleasant Dunkerley III KSC *** (orion@nuchat.UUCP) (uunet.UU.NET!nuchat!orion) *** South Coast Computing Services *** We service Publicly Redistributable software - reasonable rates *** Inquire within -- *** (orion@nuchat.UUCP) (uunet.UU.NET!nuchat!orion) *** South Coast Computing Services *** We service Publicly Redistributable software - reasonable rates *** Inquire within
chris@mimsy.UUCP (Chris Torek) (01/09/89)
In article <2800@nuchat.UUCP> orion@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 .... #define NBBY 8 /* number of bits in a byte */ >How does one go about changing the value of nsysent and adding entries >to sysent (ie: adding sys calls) on a binary-only site? 1) obtain source; 2) add entries. 1) may be achieved by `decompiling' objects. 1/2 :-) ---actually, more like :-( -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/09/89)
In article <2800@nuchat.UUCP> orion@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, ... Number of Bits in a BYte (usually 8). >I'm working on porting the BSD ipc facilities to System V Rel 3.0 / 80386. What IPC facilities?? If you mean sockets, emulate them via a user-mode library similar to the TLI interfaces.
mb@ttidca.TTI.COM (Michael Bloom) (01/10/89)
In article <2800@nuchat.UUCP> orion@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).
campbell@redsox.UUCP (Larry Campbell) (01/10/89)
In article <15348@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: }In article <2800@nuchat.UUCP> orion@nuchat.UUCP (Roland Dunkerley) writes: }>How does one go about changing the value of nsysent and adding entries }>to sysent (ie: adding sys calls) on a binary-only site? } }1) obtain source; }2) add entries. } }1) may be achieved by `decompiling' objects. Note that every UNIX license I've seen contains an explicit prohibition against disassembling, reverse compiling, or reverse engineering the objects. Also, the national speed limit is 55 (ok, 65 in some places). [Speed limit flames to rec.autos, please!] -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146
ckl@uwbln.UUCP (Christoph Kuenkel) (01/10/89)
In article <9319@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <2800@nuchat.UUCP> orion@nuchat.UUCP (Roland Dunkerley) writes: > >I'm working on porting the BSD ipc facilities to System V Rel 3.0 / 80386. > > What IPC facilities?? If you mean sockets, emulate them via a user-mode > library similar to the TLI interfaces. Has anybody done an emulation of SysV IPC messages on top of BSD Unix domain sockets and is willing to share the code? christoph -- # include <std/disclaimer.h> Christoph Kuenkel/UniWare GmbH Kantstr. 152, 1000 Berlin 12, West Germany ck@tub.BITNET ckl@uwbln {unido,tmpmbx,tub}!uwbln!ckl