Linda Walsh wrote:
> Hmmm....this would be a radical step -- something for a .odd kernel, but
> maybe the 32-bit arch's should also return 64 bits (ia - edx,eax)? I don't
> see 64 bit PC's as being commonplace in the near future and I'm sure we'll still
> want linux to run on a 32-bit machine for sometime to come. But it seems "logical"
> that we might want to start moving some values to 64 bit even on the 32-bit
> archs -- specifically enabling system calls to return 64 bits. This would
> keep the code more maintainable -- no system call special kludges like
> "default handlers" for lseek -- and no worries about overflowing long running
> counters.
>
> Is this feasible on the i386 base? Desirable? Undesirable?
--- Wait...the above is just bad. But what we could do is have an alternate syscall trap that can return something in DX. That way old code would continue to live with 32 bits the same as it ever was, but newer libraries could call the alternate trap. The alternate trap would use the same call vector table -- it's just that on return, it would also store save the value of EDX into the saved-EDX. The normal call vector still returns 32 bit values and doesn't touch EDX, but if you call via the new trap it will be defined to return 64-bits so callers won't expect it to be unchanged.It would only affect ia32 (or any other 32-bit arch that wanted to implement the functionality). And it would only affect *new* libraries that can and want a 64 bit return value. Am I making sense?
-l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:19 EST