Date: Sun, 21 Nov 1999 00:03:04 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Julian Elischer <julian@whistle.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <38377D08.6A9AD714@vigrid.com> References: <Pine.BSF.4.10.9911202024070.6767-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > THe return value system for MT syscalls is by necessity differnt from non > MT ones, and we need to continue to support old binaries. The return value isn't any different because it really doesn't return to the same context, but to the UTS in a different context :-) When the blocking system call is finally resumed, it returns in the same manner as it does in the non-MT case. > therefore by deduction, either a new syscall gate, or each syscall needs > to be somehow aware as to how it was called. teh new call gate is the > simplest way, and even allows intermixing of the new and old calls. > > New calls must be able to return and say > "hey it's not me returnuing, but actually a new KSE, " > > (just one example of how they must be different) > If it tuns out we think of somw really sneaky wayt of doing it so that > they are compatible with old code, > then we can always remove it, but I think I'd rather be absolutly certain > that code calling a new version syscall knows what to do with the return > values I return, and using a new syscall gate gives me that. I thought we could just put async notification hooks in sleep/wakeup, mi_switch, etc. I guess you could call this sneaky, but how else are you going to do it without changing most of the kernel source? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38377D08.6A9AD714>