![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to README CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [MW Coherent from dump] / coherent / b / STREAMS / conf_79|
Return to README CVS log | Up to [MW Coherent from dump] / coherent / b / STREAMS / conf_79 |
1.1 root 1: This directory and its children contain a mostly-working STREAMS system for
2: Coherent. The "mostly-working" is due to the fact that as yet polling of
3: STREAMS files is not yet supported (although it shortly will be), but more
4: importantly the lack of even rudimentary layering in the Coherent filesystem
5: code prevents full STREAMS functionality from being available (and hurts
6: performance to boot).
7:
8: Features implemented but not yet glued into the existing Coherent framework
9: include...
10: poll (), I_SETSIG, M_SIGNAL, hardware interrupts in drivers
11:
12: Features implemented but not available through Coherent (and therefore not
13: tested at all) include...
14: clone devices, getmsg ()/putmsg (), I_SENDFD/I_RECVFD,
15: scatter/gather read ()/write ()
16:
17: As yet unimplemented features...
18: autopush via SAD(7), strlog (7), and fairly much any major
19: driver.
20:
21: At this point, enough is going that if these sources merge well with the
22: current (pre-)release kernel held by Hal, then enough is going to give
23: substantial new functionality to users. In particular, a STREAMS driver
24: could be hacked up to support a large subset of BSD sockets (with the
25: emphasis on "hacked", since STREAMS protocols are *protocols* and must
26: under normal circumstances be given all the design attention of an ABI).
27:
28: Many of the sources (especially the headers and makefiles) from around
29: r73 have been touched, although mostly the changes appear to be in different
30: areas than those revised recently by Hal. Whoever gets the nasty job of
31: merging these things in should probably take a full 'diff' and look
32: closely to ensure that the changes make sense.
33:
34: -------------------------------------------------------------------------
35: /ker/conf
36: - Confguration program, 'mkdev', plus sources and kernel
37: configuration descriptions in mdevice(4), sdevice(4),
38: mtune(4) and stune(4) format. 'mkdev' reads the above
39: files plus a makefile template in "template.mak", and
40: writes a makefile which will build a single ".o" file
41: with the given configuration.
42: /ker/conf/streams
43: - The streams system, packaged up into a small, reasonably
44: self-contained unit. The makefile builds the STREAMS code
45: into a 'Driver.o' file that can be manipulated by the
46: configuration system (and a Stubs.o file supplies basic
47: definitions for all the Coherent hooks into STREAMS).
48: /ker/conf/loop
49: - The loop-around driver example from the SVR4 MP STREAMS
50: Programmer's Guide, with many corrections. Get a copy of
51: the Guide from your nearest bookstore for more information.
52: /ker/conf/dump
53: - The dump module example from the SVR4 MP STREAMS Programmer's
54: Guide, lightly edited. When pushed onto a stream, displays
55: information about STREAMS messages flowing past.
56: /ker/conf/echo
57: - Simple echo driver that reflects data written to it back to
58: the stream head. A simple test program in this directory
59: will open "/dev/echo", push the dump mode, write a string
60: and read it back again as an exercise (the test program is
61: called 'strtest', and assumes you have made a /dev node
62: for the echo device which is configured at major number 33
63: in this distribution).
64:
65: -------------------------------------------------------------------------------
66:
67: The /ker/conf/<prefix>/ subdirectories each have a makefile to build the
68: Driver.o and whatever other files are needed. This step must be performed
69: manually at the moment. Once you have built the driver objects, in theory
70: just typing 'bld' in /ker/i386 should build a STREAMS-capable kernel. About
71: 70K of code and about 32K (by default) of data will be lost to the STREAMS
72: system when compiled with 'cc' and with the default level of debugging.
73: Compiling with 'gcc' and/or turning off ASSERT () statements (which is not
74: recommended at this point) should reduce the code size considerably.
75:
76: This system is at a *very* early stage of testing... perhaps only 30% of the
77: code paths in the system have been touched at all, so many bugs remain. Try
78: writing some simple STREAMS drivers and see how it works, and let me know if
79: you have any problems!
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.