Date: Fri, 01 Mar 2002 08:24:02 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: John Baldwin <jhb@FreeBSD.org>, Bruce Evans <bde@zeta.org.au>, Alfred Perlstein <alfred@FreeBSD.org>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, FreeBSD current users <current@FreeBSD.org>, Julian Elischer <julian@elischer.org> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <3C7FAB22.A908E3D9@mindspring.com> References: <XFMail.020228203314.jhb@FreeBSD.org> <200203010309.g2139DI40526@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > My patches have been tested, they work, and they ARE going to > be committed as soon as I am able to do so. "Tut, tut, looks like rain!" -- Winnie the Pooh; A. A. Milne If you guys spent as much energy documenting your designs as you do bitching at each other, everyone would now have a clear idea of which side they should be on, or if there were even sides to begin with -- since the worst thing John has said about the patches is that they'd be a premature optimization that he expects to be needed later, but inappropriate now. > There are already hacks in the trampoline/fork_exit > and ast code that seriously pollutes the MD/MI boundry, all of which > you've flicked off your shoulder and explained away as being allowed > by your API, and Peter added a third hack with his pmap commit (which > got backed-out when he backed out the commit). Peter's pmap code was good work, but he ran head on into an undocumented processor bug that FreeBSD had escaped earlier by serendipity. Remember the whole AMD/Intel/AGP discussion? > You have > so many balls in the air constructed in a fine mesh that you can't seem > to accept a single change to your perfectly meshing subsystems, half > of which are going stale in P4. This is greatly restricting your > ability to consider deviation. Whether deviation is called for or not is still an open question, to my mind. However, you have a point about the uncommitted work. On the other hand, it was you who have been arguing so strenously that the size of the patches that need to go in in one go make them "too dangerous". And John has a point about the uncommitted work, in that the SMP system doesn't make it to single user mode with the preemption patches. I think the right thing to do is to commit the cred changes, and stabilize them, if there's even a problem, as you expect from your comments about "dangerous". I think the right thing to do on the cred front, *after* that, is to commit the patches -- John, if it won't boot to SMP afterward, you will have the eyes of everyone who uses SMP -current to help you discover why, and to correct the problems, which will happen *much faster* with a large number of eyes on it. > I will repeat, if you want to discuss specific technical issues related > to these commits after I put them in, I am all ears. I will repeat, I > see nothing in this code that prevents you from accomplishing anything > that you've brought up to date (which so far as just been the non-working > preemption code you have sitting in P4). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C7FAB22.A908E3D9>