yes but thete are subcommits that you could go ahead with...
the td_ucred stuff could have been checked in directly into -current.


On Thu, 28 Feb 2002, John Baldwin wrote:

> 
> On 26-Feb-02 Julian Elischer wrote:
> > 
> > 
> > On Tue, 26 Feb 2002, John Baldwin wrote:
> >> 
> >> 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.
> >> 
> > 
> > You know john, I wish you would commit more often and let it break things
> > occasionally.
> > It's REALLY HARD for anyone else to comment and help if you keep doing on
> > P4 which is NOT the  project Souce control system.
> > Even with cvsup assistanace, it's just no-where near as convenient as
> > having it checked in. And after you HAVE checked it in, others can help
> > find and fix problems.. as it is you are "on your own".
> > (This is the reason I will shortly check in the KSE diffs on a branch)
> 
> *sigh*
> 
> 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

Reply via email to