John, Gee, just a kernel compiled with a different version of the gcc compiler than driver modules causes a binary incompatibility. Also, distros always hack their kernels. I don't know of one that uses a stock kernel (maybe Debian?). LiS drivers need to be compiled for each kernel binary supported.
I don't see where SuSE has introduced anything much different here. I have added a check to the autoconf of the openss7 autoconf releases that will automagically compile LiS (and strxnet) -mregparm=3 if CONFIG_REGPARM is defined in <linux/config.h>. Any exported symbols will also have 'regparm_' prefixed to avoid loading a non-production LiS module against a production kernel built LiS. It will be available in LiS-2.16.18-18.tar.gz and strxnet-0.9.2-3.tar.gz soon availble from http://www.openss7.org/download.html Subscribers to the OpenSS7 Project already have access in the LiSnew repository on the LiS-2-16-18-autoconf branch and the strxnet repository. Sorry, it doesn't build a yast or deb package yet, but shortly after I get SuSE and Debian loaded here it will. If you want to look at how to build separate kernel modules that also support this feature, look at the strxnet package, which configures and compiles separate from LiS. If there are any other SuSE idiosynchrasies that I can add to the autoconf for LiS, let me know and I will add them. --brian On Tue, 08 Jun 2004, John A. Boyd Jr. wrote: > I just sent you a private note about the wrapper idea. > > As for Suse, I agree with you. I don't see how such a major > distro could make such a change. I especially agree that it's > gratuitous. > > But you know the saying, "when life gives you a lemon, make > lemonade." There could be a cottage industry providing > common-sense kernels and compiled kernel modules for RedHat > and Suse distributions. We've had that discussion before, > but not in the context of a business opportunity. If anyone > want to fund me, I'd take it on myself. > > -John > > Dave Grothe wrote: > > First of all such a wrapper would not make LiS any slower than it would > > be if the kernel routines were called with stack arguments. The > > wrappers exist now, there is just no argument passing convention issue. > > > > Second, I am seeking someone having a bright idea that can save us from > > maintaining separate builds for our half-million lines of driver code. > > I am sure that no one out there in LiS land is saying, "Oh, goody. A > > chance to port my driver code to another 'platform'." > > > > Somebody should put up a big meter on the wall that calculates how many > > hours and dollars we all are about to spend on this gratuitous change > > made by SuSE. > > > > -- Dave > > > > At 11:49 AM 6/8/2004, John A. Boyd Jr. wrote: > > > >> I'm not sure my message was clear. It would defeat the purpose of > >> the option, which trades off performance for flexibility (register > >> passing is fast but inflexibile; stack passing is slower but very > >> flexible), to use wrappers, which don't gain the performance > >> advantage, but in fact lose some. Not much gain in performance, > >> in my view, for a big loss in flexibility, and a considerable > >> increase in LiS complexity. > >> > >> I don't like the option; don't get me wrong about that. I would > >> like to say to people who want to wander into such waters, "you > >> have the source code, all things are possible for you." > >> > >> The last thing I want to do, though, is further convolute LiS > >> code in a way that makes it slower, to accomodate an option > >> intended to make things faster. > >> > >> This can be a compile option, and people can recompile LiS. It > >> doesn't have to be any more complicated than that. But good > >> luck trying to have one compilation serve both calling conventions. > >> I've done GCC ports; you'll be facing the equivalent of one if > >> you take on that challenge. If you think my open-related changes > >> are big... > >> > >> If a big distro like Suse makes CONFIG_REGPARM the default, then > >> just make it clear how to compile for Suse specifically. With the > >> configuration I have in the works, it's just a different kernel > >> option; you could ship both alternatives if you wanted to, as long > >> as kernel version distinguishes them (which might be the biggest > >> problem). There are simpler alternatives, despite your facing > >> recompiling half a million lines. > >> > >> -John > >> > >> Dave Grothe wrote: > >> > >>> At 11:01 AM 6/8/2004, John A. Boyd Jr. wrote: > >>> > >>>>> The most desirable outcome would be for LiS to provide wrapper > >>>>> functions for the kernel routines, as it now does via osif, lismem, > >>>>> lislocks and lispci, and make these wrapper functions callable with > >>>>> stack parameters as in the past, but with the calls to the kernel > >>>>> functions able to use register passing. > >>>> > >>>> > >>>> That would defeat the purpose, in my view. > >>> > >>> > >>> The reason for seeking such a solution is that those of us with a > >>> half million lines of driver code do not look forward to supporting > >>> "another platform" consisting solely of some kernel hacker's choice > >>> of build options. Such "platforms" could proliferate. > >>> In my mind this chaos is the major downside to using Linux in the > >>> first place. > >>> Shall we port LiS to BSD and just get off this roller coaster? Those > >>> guys at least try to hold their driver/kernel interface relatively > >>> constant. > >>> -- Dave > >> > >> > >> _______________________________________________ > >> 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 -- 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
