tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: mutexes, locks and so on...

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_vector_enter (parts are still needed)
mutex_vector_exit (parts are still needed)

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 Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email:             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Home | Main Index | Thread Index | Old Index