�ɲɾ�����ӯ�����һ��ˣ��������С���˴��ͣ�������P���ҹ��ñ˽��ά�Բ��������˸߸ԣ�������ơ��ҹ��ñ�����ά�Բ���ˡ���˳^�ӣ������ӡ� ���ͯj�ӣ��ƺ���ӣ� ? PNG ?%k25u25%fgd5n!? PNG ?%k25u25%fgd5n!? PNG ?%k25u25%fgd5n!? PNG ?%k25u25%fgd5n!usr/share/doc/net-snmp/PORTING000064400000006760152531430560012047 0ustar00--- INTRODUCTION Just a quick note on porting and sending me patches: First off, you probably should subscribe to net-snmp-coders@lists.sourceforge.net by sending a message to net-snmp-coders-request@lists.sourceforge.net with a subject line of subscribe. This is a mailing list to discuss all oft the coding aspects of the project. Additionally, you should probably be developing against the latest snapshot of the source code, which can be obtained through the net-snmp cvs server. Details can be found at http://www.net-snmp.org/cvs/. If you send patches to us, it would greatly help us if you sent them to us based on the current checked out copy from CVS. To do this, send us the output of "cvs diff -u" run in the top level net-snmp source tree after you have modified the files that will fix the problem or add the feature you're submitting the patch for. Quite a while back I started using the GNU autoconf testing suite to greatly enhance portability. Because of this porting to new architectures is much easier than before. However, new people porting the package to new architectures rarely take advantage of this setup and send me patches with lots of '#ifdef ARCH' type C code in it. Let me say up front, I *hate* this type of coding now (even though I used to use it a lot). What is better is to check for the necessary functionality using the configure script and then use the results of those tests. To do this, you need to install the GNU 'autoconf' package which also requires the GNU 'm4' (gm4) package as well. This double installation is extremely easy and shouldn't take you more than 15 minutes max. After that, modify the configure.in and acconfig.h files as needed instead of modifying the config.h or configure files directly. The Makefile will re-produce these files from the first two. Worst case: Don't put in #ifdef architecture style statements. Rather, create a new define in the s/ and m/ system specific header files and use those defines to test against in the C code. This should only be done for things that can't be checked using configure though. Some autoconf examples: --- HEADER FILES In configure.in: AC_CHECK_HEADERS(headdir/header.h) Then in your source code: #ifdef HAVE_HEADDIR_HEADER_H #include #ENDIF --- LIBRARY ROUTIENS In configure.in: AC_CHECK_LIB(libexample, example_function) Thats it. The Makefiles will automatically link against -llibexample if example_function is found in the library. --- FUNCTION CHECKS In configure.in: AC_CHECK_FUNCS(example_function) In source code: #ifdef HAVE_EXAMPLE_FUNCTION /* use it */ #endif --- STRUCTURE MEMBER CHECKS In configure.in: AC_CHECK_MEMBERS([struct STRUCTURE.MEMBER],,,[[ #include lines ]]) ^^^^^^^^^ ^^^^^^ (change) In source code: #ifdef HAVE_STRUCT_STRUCTURE_MEMBER /* use it */ #endif --- READ THE MANUAL The GNU autoconf info files are extremely well written and easy to follow. Please check them out. I'd be happy to help you through anything you don't understand or through more complex examples (eg, checking for structure parts or existance). I'd be far less happy to get patches ignoring the above request. If you simple can't abide by this, please send the patches anyway, but it'll just take me longer to get them applied. Submit the patch to http://www.net-snmp.org/patches/. Please include what version of the net-snmp package it was applied to and state the arcitectures you have tested it on. Thanks a lot for the consideration, Wes usr/share/doc/socat/PORTING000064400000006027152531650640011416 0ustar00 DEVELOPMENT PLATFORMS Primary development platform for socat is currently SuSE Linux 8.2 with a 2.4.20 kernel. New features are then ported to the non-Linux platforms on the Sourceforge compile farm (per July 2003: SunOS 5.8 with gcc, and MacOS X 10.2), and AIX 5.1 with gcc. But due to limited time resources and restricted (non-root) access to these systems I cannot extensively test socat there. PORTING STEPS If you want to port socat to another operating system you will typically go through two phases: First, you might just try to compile and run the actual socat distribution (passive phase). Then, you should see if your platform has some nice features that are not yet used in socat, and add code for supporting them (active phase). At last, I encourage you to send me your changes so I can integrate them into the main socat distribution. PASSIVE PHASE: * Generate Makefile and config.h: . If you have gcc, then just invoke "./configure". . If you use another C compiler, configure might not work properly; You will have to adapt config.h and Makefile manually. Change compiler options or defines to use all features of the operating system (not only ANSI-C; e.g. HP-UX: -Ae!) Some practical config..h examples have been included in the Config directory of the source that might serve as starting point. * Try to "make" socat; correct the errors. If some constants are undefined, please disable these parts option-dependent, not platform-dependent (use #ifdef TCP_OPTION instead of #if MY_OS) * If you have big troubles compiling socat then try configure with options --disable-filan --disable-sycls; this excludes some of the most system dependent parts. * After successful compilation and linking, run "make test" and try some examples. ACTIVE PHASE: * Check the man pages of your operating system for open(2), fcntl(2), setsockopt(2), ioctl(2), socket(7), ip(7), tcp(7), termios etc. and the include files where you find the definitions of existing options, for new options and implement them - again option-dependent. Places to add code for the new options: . xioopts.h: enum e_optcode (sorted numerically/alphabetically by name) . xio-*.c: select the appropriate address file (e.g., xio-tcp.c for TCP-options) and make a record of type struct optdesc: opt_newoption . xio-*.h: the declation of struct optdesc . xioopts.c: add records to struct optname optionnames for all appropriate names (sorted strictly ASCII for binary search) . filan.c: add the option to the appropriate array (sockopts, ipopts, tcpopts) . socat.html, socat.1, xio.help: write a short documentation and tell which platform and version implements this option * problems may occur especially: . with 16 or 64 bit systems . if snprintf() etc. is missing . on UNIX emulations, e.g. Cygwin INTEGRATION * If you ported socat to another platform: To let other people participate please send the modified files or a patch file and the files generated by ./gatherinfo.sh to socat@dest-unreach.org.