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
