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
