On 2010-11-12 18:19, Antti Kantee wrote:
On Fri Nov 12 2010 at 16:58:18 +0000, Mindaugas Rasiukevicius wrote:What Johnny apparently suggests is to revisit mutex(9) interface, which is known to work very well, and optimise it for VAX. Well, I hope we do not design MI code to be focused on VAX. If we do, then perhaps I picked the wrong project to join.. :)He is suggesting to revisit the implementation. It doesn't take much thinking to figure out you don't have to use kern_rwlock.c on vax, just provide the interface. It's really really unlikely the *interface* will change, so it's not much code updating to worry about either. (incidentally, rump kernels have take this approach for, what, 3 years now because the kernel implementation of mutex/rwlock uses primitives which are not in line with the goals of rump, namely to virtualize without stacking multiple unnecessary implementations of the same abstraction)
I wish. Doing that for kern_mutex.c (skipping the file, that is), would require me to implement:
mutex_dump mutex_abort mutex_init mutex_destroy mutex_onproc mutex_vector_enter (parts are still needed) mutex_vector_exit (parts are still needed) mutex_wakeup mutex_owned mutex_owner mutex_tryenter mutex_spin_retryAnd for many of them, I suspect I would just want to copy them over. The same is true for rwlock and lock. Having such code duplicated is doomed to be a failure. So no, skipping on files in kern, and having my own implementation for them is not a realistic option.
But if you say that you are doing this for rump, then maybe I am wrong, and that it really is a realistic option. Care to point to where your rump alternative files are, and I can look at that and ponder this for a while?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol