David, I don't understand Linus hates Streams... this is one of the most important improvement of SRV4.
Jean-Philippe LONGERAY R&D Director - Service NODE NetCentrex [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> + 33 4 72 53 61 33 or + 33 4 72 53 61 30 Mobile: + 33 6 76 48 34 95 Fax : + 33 4 72 56 61 34 http://www.netcentrex.net -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Grothe Sent: mardi 23 septembre 2003 17:43 To: Jean Philippe Longeray; [EMAIL PROTECTED] Subject: RE: [Linux-streams] LSL Linus actively hates STREAMS and will not even give you a reply to emails on this subject. You are welcome to try, but don't expect success or even acknowledgement. And, BTW, I do not want LiS to be incorporated into the kernel. LfS would be fine, but not LiS. -- Dave At 10:25 AM 9/23/2003 Tuesday, Jean Philippe Longeray wrote: >May I suggest Linus Torvalds to integrate a native streams solution in next >release of Kernel? > >It takes so lot of time to integrate an validate a single solution based on >LiS... I'm not sure to be ready and have enough time to validate a new one. > >Jean-Philippe LONGERAY >R&D Director - Service NODE > >NetCentrex > >[EMAIL PROTECTED] ><mailto:[EMAIL PROTECTED]> >+ 33 4 72 53 61 33 or + 33 4 72 53 61 30 >Mobile: + 33 6 76 48 34 95 >Fax : + 33 4 72 56 61 34 >http://www.netcentrex.net > > > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Behalf Of David Grothe >Sent: mardi 23 septembre 2003 17:05 >To: [EMAIL PROTECTED] >Cc: Matthew Gierlach; [EMAIL PROTECTED] >Subject: Re: [Linux-streams] LSL > > >Brian: > >Not bad for 6 weeks of work. Is this the future feature list or the >working and tested feature list? > >I would be interested in getting feedback from present LiS users as to >whether they intend to use LfS instead of LiS. It would help me get a feel >for who is primarily depending on me for support and who is depending on >Brian. > >-- Dave > >At 05:19 PM 9/22/2003 Monday, Brian F. G. Bidulock wrote: > >Dave, > > > >I have started a Linux Fast-STREAMS (LfS) development. I decided not to >start > >with LiS at all. I have written an SVR4.2 STREAMS for Linux from scratch. >As > >such, it has been placed under Linus-GPL (GPL with Linus Torvalds usage >note > >at the top, but we can also offer commercial license to the code to those >for > >which Linus-GPL is not sufficient.) I have added an LiS 2.16 binary > >compatibility module. > > > >I have almost completed a release package and am looking for beta testers. >I > >expect to release a GPL beta package this week. If you have an interest in > >testing the release, please send mail to me directly at >[EMAIL PROTECTED] > >I will fire up a mailing list on the www.openss7.org site to handle any >issues > >that develop, will release the code after beta testing on the downloads >page > >there. > > > >LfS has all the features of LiS, plus a few more as follows: > > > >o Software pipes using the Linux pipe(2) can be replaced with STREAMS > > pipes. > > > >o Filesystem based fifos using mkfifo(8) can be replaced with STREAMS > > fifos. > > > >o Complete /proc filesystem support for both the specfs filesystem as > > well as sysctls and display of SVR4.2 style debugging information, > > usage and statistics. > > > >o A Named stream device that uses the node name in the filesystem rather > > than a major device number, permitting dynamic allocation of device > > numbers. > > > >o extern inline definitions in header files of short streams utility > > functions. These will be inlined if compiler optimization is turned > > on. > > > >o high-performance memory caches for all STREAMS datastructures. > > > >o full SMP support with loose locking. > > > >o integration with Linux SoftIRQ between NET TX and NET RX for optimal > > performance with Linux native networking, isrs, bottom halves and >timers. > > > >o per-CPU binding of kernel threads and same CPU service procedure > > scheduling. > > > >o addition of getpmsg and putpmsg system calls to Linux under all > > supported architectures including 32-bit to 64-bit glue code. > > > >o more complete SVR4.2 DDI/DKI support. > > > >o roughed in support for Solaris-style barriers and q-functions (such > > as qtimeout and qbufcall). > > > >o implementation of qwait and qwait_sig plus a more SMP friendly qprocsoff > > and qprocson mechanism. > > > >o A more Solaris-like registration mechanism (LiS compatible interface > > provided). > > > >o contained to 26 .c files in a single directory including all supporting > > modules and drivers. > > > >o 16,000 lines of code compared to LiS's whopping 90,000 lines of code. > > > >o 45k executive binary footprint compares to LiS's whopping 220k. > > > >o LiS binary compatibility module exporting all LiS 2.16 functions for > > compatibility with existing LiS binaries. > > > >o (just about) complete documentation. > > > >o socket system call support for TLI devices permitting libc2 sockets > > interface to be used for TLI streams. > > > >o reimplementation of the XNET (XTI) library, timod and tirdwr. > > > >o sockmod implementation and libsocket compatibility library. > > > >o reimplementation of streams-based pipes and fifos. > > > >o reimplementation of the sad driver. > > > >o the strinet driver for accessing Linux sockets as TPI streams. > > > >o patched into Linux 2.4.18 thru 2.4.22 kernel with kernel configuration > > menus. > > > >o Lindented. Suitable for kernel submission. > > > >o a bunch that I have forgotten already. > > > >--brian > > > >On Mon, 11 Aug 2003, Dave Grothe wrote: > > > > > At 02:34 AM 8/8/2003 Friday, Brian F. G. Bidulock wrote: > > > >Dave, > > > > > > > >It might be time to start that Linux STREAMS Lite (LSL) branch that >does > > > >not include overheads for ports (that do not openly exist) nor include > > > >performance reductions without purpose... > > > > > > > >Anyone interested? > > > > > > I think this is an excellent idea. > > > > > > There is clearly a difference of opinion here on design objectives, so >it > > > makes sense to me for those of you who are interested in making > > performance > > > the overriding consideration to mount such a project. > > > > > > I don't think that I will have anything useful to contribute to such a > > > project since I have a high degree of confidence in your abilities to > > > achieve these goals. However, when you set up the mailing list for LSL > > > please add me to it. I would like to monitor the discussions. > > > > > > As there have been some requests coming from the Carrier Grade Linux > > > project that we place LiS on Source Forge for more "traditional" open > > > source maintenance, I would suggest that the LSL project could be hosted > > > there and kill two birds with one stone. > > > > > > It pretty much goes without saying, but I will say it anyway just to >make > > > sure, that the original copyright holders of LiS retain their rights in > > LiS > > > code utilized in the LSL project. LSL must continue to be LGPL since >that > > > is the wishes of the original copyright holders of LiS. > > > > > > You can start with the latest version of LiS, if you like. > > > > > > Keep me posted. > > > > > > -- Dave > > > > > > > > > _______________________________________________ > > > Linux-streams mailing list > > > [EMAIL PROTECTED] > > > http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams > > > >-- > >Brian F. G. Bidulock � The reasonable man adapts himself to the � > >[EMAIL PROTECTED] � world; the unreasonable one persists in � > >http://www.openss7.org/ � trying to adapt the world to himself. � > > � Therefore all progress depends on the � > > � unreasonable man. -- George Bernard Shaw � > > > >_______________________________________________ > >Linux-streams mailing list > >[EMAIL PROTECTED] > >http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams > > >_______________________________________________ >Linux-streams mailing list >[EMAIL PROTECTED] >http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams > > >_______________________________________________ >Linux-streams mailing list >[EMAIL PROTECTED] >http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams _______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams _______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
