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
