Re: LiS and Linux 2.6 (SuSE 9.1 and SuSE 9.2)
"Brian F. G. Bidulock" <[email protected]> Mon, 11 Apr 2005 18:01:28 -0600
| Newsgroups | gmane.linux.kernel.streams |
|---|---|
| Organization | http://www.openss7.org/ |
| Message-ID | <[email protected]> |
Dan, On Mon, 11 Apr 2005, dan_gora wrote: > > --- "Brian F. G. Bidulock" <[email protected]> wrote: > > > dan_gora, > > Please, just "Dan"... My name is Dan Gora. You might consider changing this: From: dan_gora <[email protected]> to this: From: "Dan Gora" <[email protected]> ;) > > > I don't know what a SuSE EL 9 is, but I have 2.18.1 loading and > > running on: > > Sorry I got confused, it's not EL9 it's ES 9, SuSE Enterprise Server > 9. I guess they got jealous of Red Hat's naming conventions. It > unfortunately has yet a different kernel version from 9.1 or 9.2, > although it's not all that different. The changes that we did for > SuSE 9.1 and 9.2 worked with no changes on ES9 too, so I'm sure that > you'll have similar results. Well, if its expensive and there are no clones, someone else will have to test on it or donate a copy. Are there any clones for this like there are for RH EL3 and 4? > > http://www.novell.com/products/linuxenterpriseserver/ > > > This was fixed on openss7 LiS-2.16.18 releases a long time ago. > > On parisc, one cannot execute a system call from within the > > kernel. I rip the sys_ symbols on the kernel side of the call > > gate and call them directly. > > > > There are probably more things required for full 64-bit safety, > > however, I do not have any 64-bit test platforms. Anybody > > willing to donate some? > > There was some problem with calling them directly on 64 bit > platforms. There is certainly no problem with calling a function. > I think that they are not all exported anymore in the SuSE versions. I rip the symbol address from the system map. The system map effectively exports everything. > I can't recall exactly what the problem was off hand, but calling > them directly wasn't going to work. I'll try and get back to you > about this. Please do. > > I'm not willing to donate test platforms, but we are willing to test > the release on ours... That would be good, but I can only build and sign RPMs and DEBs on architectures to which I have physical access. > > > I haven't released it publicly yet, more so because it is not > > fully ready, not because we want anyone to purchase it. I have > > some debugging and testing to do on the various architectures > > and distributions before relasing it is ready for prime-time. I > > is still my intention to replace LiS with it. > > Is it still your intention to make it full GPL or are you going to > use a similar LGPL that LiS uses? The only component released under LGPL is the libxnet library. This is also true of the LiS 2.18.1 release, which will be released under GPL. > > > Linux Fast-STREAMS compiles and loads on all the above > > architectures and distributions as well. I have split off a > > strxns package (ldl, ip_strms stuff, DLPI, NPI headers and > > docs), strxnet package (timod, tirdwr, libxnet, TPI, XTI headers > > and docs), strinet package (inet driver), strsctp package > > (STREAMS sctp driver). The purpose of spitting these packages > > our of LiS was so that they would build and load against both > > LiS and Linux Fast-STREAMS from the same codebase. > > > > In wrapping LiS 2.18.1 under autoconf I was very disappointed to > > observe SMP races by simple inspection. (If you want a quick > > example look at how lis_freezestr and lis_unfreezestr examine > > flags outside of locks and then take locks and change flags > > depending on the unlocked check.) > > Did you fix all of the ones that you found or are there still some > hanging out? I didn't fix any of the ones I found. The code is a rats nest and is full of bugs. The fixes I applied to 2.16.18 have been applied to 2.18.1, but I don't intend to go looking for bugs to fix. (I was trying to document the functions when I found the ones I mentioned.) If you (or someone else) have some fixes I will patch them in. But my time is better spent on the production grade Linux Fast-STREAMS, instead of fixing all the bugs in LiS. Take a look at the alpha when its released and you'll see what I mean. > > > I will apply patches and fixes to 2.18.1 and maintain the code, > > however, all my further development effort will be on Linux > > Fast-STREAMS instead of LiS. If you work with the 2.18.1 > > release, you should move quite easily to the Linux Fast-STREAMS > > release that has lis_ compatibility functions and is largely > > source compatible with LiS. > > We'll look into that but without being able to see it, it's pretty > hard to make any plans to migrate to it. The licensing will also be > a big issue because we sell comercial non-GPL products and have no > intention on making our code GPL. I can release the alpha that I'm working with now for perusal, but don't expect it to do much right now without crashing your kernel. It will be GPL, however, as with all software released by the OpenSS7 Project, commercial licensing will be available through OpenSS7 Corporation. This is a free beer vs. freedom of speech situation. > > > > thanks for the new release, looking forward to see it. > > > > Your welcome. I hope it can be a stable branch along which > > patches can be made as required. > > sounds good. I'll make sure that we get our changes for the 64 bit > stuff integrated once you release it, then I'll send em back. > > How are you planning on releasing this? On openSS7.org? I'd still > like at some point to open a sourceforge project for this but time > has been lacking lately. I will put the release up on openss7.org with the other LiS releases, for now. Once Linux Fast-STREAMS is production grade, I will discontinue LiS releases. But until then I will maintain LiS 'cause it doesn't look like there is anyone else willling to do so. --brian > > thanks- > dan > _______________________________________________ > 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 ¦