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_retry
And 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: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
