Matti Aarnio wrote:
> > Ahh...um... it is lseek that returns an actual 'offset' value, llseek only
> > returns 0 or error code. So...then I ask what would the implications (in a future
> > development release) of changing lseek to return 64 bits on intel.
>
> Use lseek64() and be happy.
> On intel linux it is implemented at glibc by means of llseek(),
> but that is then a side issue.
--- Is there some good reason why the interface shouldn't be cleaned up on Intel? Seems like it would be much more maintainable, less ugly -- rather than have various user-land kludges that take advantage of extra kernel calls. Wouldn't it be more straightforward to have lseek return a 64 bit value on ia32 (et al. 32 bit platforms) as it does on the 'big machines'? Seems like it could result in simpler glib code as well...I mean -- it's not that big of an issue to me, but the change is trivial the kernel side. Then we can list the alternate 64 bit kludges as 'deprecated' and some day not worry about them at all...(?) It just seem like a cleaner implementation for the future... I just figured if there's a 64-bit ia32 kernel call interface, why not use it?
-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 30 2000 - 21:00:08 EST