:> rather then make it more complex. You have your fingers in just about
:> every single goddamn file in the system and you and others have cried
:> wolf one too many times. I am through with playing that game.
:>
:> The commit goes in. I am open to any suggestions you have for stage-2,
:> which will be a furtherance of the cleanup, but I absolutely refuse to
:> allow you to prevent me from contributing to the SMP work in -current
:> for a forth time because it doesn't exactly match your dream or
:> N-month-old stale patches you might have sitting around in P4.
:
:My suggestion will be to back it out. I would rather not have to make said
:suggestion. Can you please try to fit this into the existing framework rather
:than ripping it all up? We need to finalize and test the design before we
:hardcode too many assumptions about the implementation into the interface. You
:have pointed out some issues with the current interface which are valid and I
:would like to address those, however, there are still changes to the MI
:implementation that need to go in once it doesn't crash right and left. If you
:wish I could commit the code and make current a living hell for everyone, but
:my ethics don't permit me to test code that I know is broken.
:
:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
You still don't get it, John. What you've done with critical_enter()
and critical_exit() is not design a bunch of routines to an API. What
you've done is write a bunch of routines and made the API conform to
them. You have also put your fingers into so many pies that I haven't
been able to do one things with SMP without tripping over something you've
got in your tree that you haven't committed. Hell, I don't think you
even understand what my patch does! I think you and a few others have
gotten the rumor mill running in overdrive on IRC and can't see the hand
in front of your faces because of it.
I think you need to take a step back and consider focusing on one
subsystem at a time rather then trying to control the whole project
all by yourself.
The commit will be going in in a few minutes. If you have work related
to the critical_*() code, such as the preemption work, I see no problem
getting it in. All you have to do is discuss it on the lists. In fact,
judging by what you posted on IRC I would have to say that my framework
is going to work a whole lot better in regards to dealing with preemption
then the hacks you've thrown together!
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
