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
