Not to put too fine a point on it, but, I don't see how this can
possibly justify preventing me from committing my critical_*() stuff.
You've just stated publically that your preemption stuff is unusable
as it currently stands. Why am I supposed to wait an arbitrary period
of time for you to fix, test, and commit it?
I would REALLY like to commit my critical_*() stuff, and for the record
this will also include the stage-2 stuff described in the original commit
comments that will be made a few days after the current commit.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:>
:> Preemptive kernels don't even make it out of single user mode for SMP machines,
:> ok? We aren't talking minor breakage here, we are talking _extreme_ breakage.
:> If people want to play with it, preempt.patch on freefall is updated via a cron
:> job every half hour or so. Unfortunately, however, it's in a limbo atm due to
:> KSE and needing to sort out how the priorities are going to work. It will
:> really be better to let KSE settle into the scheduler first adn then add
:> preemption to the scheduler itself afterwards.
:>
:> The reason I'm not pushing preemption into the tree fully (I've already
:> committed half of the original patch) is that there is other work (proc locking
:> for example) that gets us more bang for the buck.
:>
:> --
:>
:> John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
:> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
:>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
