todd@ivucsb.UUCP (Todd Day) (03/17/89)
While bopping thru the kernel (Ver3.50), I found the following:
# grep sock /etc/lddrv/unix.sym
sock_write = 0x1d6f4;
sock_read = 0x1d6f8;
sock_ioctl = 0x1d6fc;
sock_close = 0x1d700;
sock_sema = 0x1d704;
I looked thru the dot.h files and found this:
# grep sock /usr/include/* /usr/include/sys/*
sys/errno.h:/* Errors from 4.2 BSD picked up to support sockets */
sys/errno.h:#define ENOTSOCK 229 /* Socket operation on non-socket */
sys/errno.h:#define EPROTOTYPE 232 /* Protocol wrong type for socket */
sys/errno.h:#define EOPNOTSUPP 235 /* Operation not supported on socket */
sys/errno.h:#define ESHUTDOWN 248 /* Can't send after socket shutdown */
sys/space.h:(*sock_write)() = nodev;
sys/space.h:(*sock_read)() = nodev;
sys/space.h:(*sock_ioctl)() = nodev;
sys/space.h:(*sock_close)() = nodev;
sys/space.h:(*sock_sema)() = nullsys;
Further examination of the sys/space.h file reveals:
* The following definitions support the functions called
* from the system calls for networking, and network
* semaphores.
*/
extern int nodev(), nullsys();
(*sock_write)() = nodev;
(*sock_read)() = nodev;
(*sock_ioctl)() = nodev;
(*sock_close)() = nodev;
(*sock_sema)() = nullsys;
short softnetint = 0;
short netbusy = 0;
/*
* The following network constants can be set from tunevars
*/
int net_mbsize = 64*1024; /* amount of space to reserve for mbufs */
int net_tcpdebug = 0; /* Number of tcp trace buffers */
int vt_defcnt = 0; /* Number of configured pseudo-terminals */
^^^^^^^^^^^^^^^^
I have these, now.
Got a driver from
some ftp site.
This looks to me like some beginning efforts to emmulate Berkeley sockets.
Has anyone looked into this? Is it possible for some loadable device driver
to be written to emulate sockets?
--
-Todd Day-
Internet: todd%ivucsb.UUCP@anise.acc.com
UUCP: {pyramid, ucbvax}!ucsbcsl!nessus!ivucsb!todd
Other: todd@ivucsb.UUCP may not work yet.john@polyof.UUCP ( John Buck ) (03/19/89)
In article <612@ivucsb.UUCP>, todd@ivucsb.UUCP (Todd Day) writes: > While bopping thru the kernel (Ver3.50), I found the following: > # grep sock /etc/lddrv/unix.sym > ... lots of SOCKET type references deleted... If you get the UNIX PC WIN TCP package, you will get a BSD 4,2 compatible library with it, including full sockets. Beware, though, they don't work exactly correct (IE the implementation is flawed; select doesnt work right, for one thing). The hooks you see in your kernel are for the WIN / TCP driver that comes with the WIN software. If you want it, talk to you AT&T rep. john@polyof.poly.edu john@Polygraf.bitnet trixie!polyof!john
jbm@uncle.UUCP (John B. Milton) (03/20/89)
In article <612@ivucsb.UUCP> todd@ivucsb.UUCP (Todd Day) writes: [ found a lot of socket references ] ... >int net_tcpdebug = 0; /* Number of tcp trace buffers */ >int vt_defcnt = 0; /* Number of configured pseudo-terminals */ > ^^^^^^^^^^^^^^^^ > I have these, now. > Got a driver from > some ftp site. Not the same thing as the pty driver. This is for a network terminal interface called "vt. >This looks to me like some beginning efforts to emmulate Berkeley sockets. > >Has anyone looked into this? Is it possible for some loadable device driver >to be written to emulate sockets? Yes, there is. It is the Wollongong (sp?) software for the Ethernet board you can get for this machine. What you have found are the parts that had to be compiled into the kernel to provide the hooks Wollongong needed. Now, of course, those hooks could be used by anyone else... John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:764-2933; AMPR: 44.70.0.52; Don't FLAME, inform!
ecf_hap@jhunix.HCF.JHU.EDU (Andrew Poling) (03/22/89)
In article <454@polyof.UUCP> john@polyof.UUCP ( John Buck ) writes: >If you get the UNIX PC WIN TCP package, you will get a BSD 4,2 >compatible library with it, including full sockets. Beware, though, >they don't work exactly correct (IE the implementation is flawed; >select doesnt work right, for one thing). You mean it's not supposed to panic the system? :-) Actually, let me temper that remark with specifics. I have run into problems with select(3W) on numerous occasions. If you have too many long selects(3W) active at once, it will overflow your timeout table ==> PANIC. My solution (based on intuition more than fact) has been to limit my selects(3w) to one second. This does hurt my performance, since it makes my machine impatient, but it allows me to run such goodies as BIND, Sendmail5.58, and other resolver-based routines that I have found SysV ports of here and there. On the positive side, 4.2 BSD socket code usually runs out of the box as soon as you fix all of the other SysV/BSD (ahem) problems. As a side point - I noted in a bug report release for the 3.* code for our 3b4000 warns of possile panics in (as I read it) much the same way. I guess Wollongong only ports this stuff once, then re-uses the same buggy code. :-( Disclaimer: These are my own opinions - don't blame my employer - they don't even know that I think. :-) Andy andy@gollum.hcf.jhu.edu ecf_hap@jhunix.UUCP ecf_hap@jhuvms.BITNET
michael@stb.UUCP (Michael) (03/23/89)
As for a socket device driver, I'm currently writting a stream socket emulation library--but it needs to be in a known process context (hence a library, not a device). How do file descriptors work inside the kernel, andways? Michael p.s. Don't ask for the code right now. Is there a word for "pre-alpha" software? : --- : Michael Gersten uunet.uu.net!stb!michael : michael@stb.uu.net <mx mailers> crash!gryphon!denwa!stb!michael : "Robitussin" for computers? This has gone too far. Where's "Penicillian"? : (rob. is Coff-medicine to let COFF people run bsd-dependent GNU stuff).
alex@umbc3.UMBC.EDU (Alex S. Crain) (03/26/89)
In article <10667@stb.UUCP> michael@stb.UUCP (Michael) writes: >As for a socket device driver, I'm currently writting a stream socket >emulation library--but it needs to be in a known process context >(hence a library, not a device). I was going to avoid saying anything, but more then that I want to avoid duplication of effort, so here I am. For the last 6 weeks, I've been busy porting the BSD4.3 layered socket code to the unix pc. Berkeley released the code awhile back, so it's all free, and theres alot of it. So far, I've got about 3000 lines of code that is nearly complete for socket() bind () listen () accept () connect () within the AF_UNIX domain. socketpair () and pipe () have been working for over a week without problems, and I expect the other 5 to be debugged real soon (figure 30 working hours from now, I had a setback). Note the absence of select(). Also missing is out-of-band data and an interface to fcntl(), although the hooks are there. What does this mean? It means that in June I expect to release code to completely support AF_UNIX sockets, including select(), SOCK_STREAM, SOCK_DGRAM, out-of-band, and all the options that make sence. I am also preserving the layered interface, so that I can add AF_INET sockets via a SLIP connection, and possibly AF_AT (appletalk). The code is huge, and is taking along time, but is moving along on schedule, but it's still vaporware. I'm only making this announcement to avoid duplication of effort, and I'll inform the net with a call for beta sites when its complete and reasonably sound. > How do file descriptors work inside >the kernel, andways? I suggest a book called _The Design of the Unix Operating System_ by Maurice Bach as a guide to the internals of unix (mostly system 5). Also look for _UNIX PC Version 3.0 Device Driver Development Guide_, a free 40 page document from AT&T that comes with a kernal debugger on disk. I have no idea who to talk to at AT&T, I started (a long time ago) with AT&T information (1-800-???-????) and asked about unix-pc's and drivers until I found someone who would send me something. > Michael >p.s. Don't ask for the code right now. Is there a word for "pre-alpha" software? The word is Vaporware. Don't give up on your code, it likely that a non-kernal socket library will come in real handy for people with smaller machines (who don't need an extra 75K of kernal size). And, of course, I could always get hit by a bus. -- :alex Alex Crain Systems Programmer alex@umbc3.umbc.edu Univ Md Baltimore County nerwin!alex@umbc3.umbc.edu (NEW DOMAIN)
vern@zebra.UUCP (Vernon C. Hoxie) (03/27/89)
In article <1834@umbc3.UMBC.EDU>, alex@umbc3.UMBC.EDU (Alex S. Crain) writes: > In article <10667@stb.UUCP> michael@stb.UUCP (Michael) writes: > >As for a socket device driver, I'm currently writting a stream socket > >emulation library--but it needs to be in a known process context > >(hence a library, not a device). deletion..vch > For the last 6 weeks, I've been busy porting the BSD4.3 layered > socket code to the unix pc. Berkeley released the code awhile back, so it's > all free, and theres alot of it. So far, I've got about 3000 lines of code > that is nearly complete for What are some references (besides the short intro in Bach) on how to use these devices and what manuals pages are available? deletion..vch > I suggest a book called _The Design of the Unix Operating System_ by > Maurice Bach as a guide to the internals of unix (mostly system 5). Also > look for _UNIX PC Version 3.0 Device Driver Development Guide_, a free 40 > page document from AT&T that comes with a kernal debugger on disk. I have > no idea who to talk to at AT&T, I started (a long time ago) with AT&T > information (1-800-???-????) and asked about unix-pc's and drivers until I > found someone who would send me something. I have Bach from Prentice-Hall and I got the Device Driver Guide from AT&T by writing to the address in the _UNIX-PC Interface Specification_ book which came with the Development Set (pg 2-52). AT&T Information Systems Product Manager - UNIX-PC Enhancements Attn: Device Driver Information (Rm 6A45) 1776 On the Green Morristown, NJ 07960 However, I didn't get the kernal debugger disk. Anybody with a suggestion how to get a copy of that? We're looking forward to hear more from Michael and Alex. Thank you guys! BTW Is the Prentice-Hall book on UNIX Device Drivers worth while? -- Vernon C. Hoxie {ncar,nbires,boulder,isis}!scicom!zebra!vern 3975 W. 29th Ave. voice: 303-477-1780 Denver, Colo., 80212 uucp: 303-455-2670