From owner-freebsd-java Wed Jul 10 21:46:13 2002 Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE9F937B400 for ; Wed, 10 Jul 2002 21:46:09 -0700 (PDT) Received: from gnuppy.monkey.org (wsip68-15-8-100.sd.sd.cox.net [68.15.8.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3864D43E31 for ; Wed, 10 Jul 2002 21:46:09 -0700 (PDT) (envelope-from billh@gnuppy.monkey.org) Received: from billh by gnuppy.monkey.org with local (Exim 3.35 #1 (Debian)) id 17SVqA-00019C-00; Wed, 10 Jul 2002 21:46:06 -0700 Date: Wed, 10 Jul 2002 21:46:06 -0700 To: Nate Williams Cc: freebsd-java@FreeBSD.ORG, Bill Huey Subject: Re: 1.3.1 patchset 7 not quite ready Message-ID: <20020711044606.GA4375@gnuppy.monkey.org> References: <20020710234814.GE2394@gnuppy.monkey.org> <15660.64672.311655.234760@emerger.yogotech.com> <20020711035137.GA4210@gnuppy.monkey.org> <15661.575.854309.132871@emerger.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15661.575.854309.132871@emerger.yogotech.com> User-Agent: Mutt/1.4i From: Bill Huey Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Jul 10, 2002 at 09:57:51PM -0600, Nate Williams wrote: > Signals 'mostly work' in -current, regardless of what they do in > HotSpot. You may end up chasing your tail trying to fix Java bugs that > are in fact kernel bugs. I'm competent enought to know the differences between those bugs. I've been in libc_r land long enough to figure out what should be working verses what's broken. > Ok, you can run whatever you like, but don't expect anyone to be able to > help you. (The latter was sarcasm, since at the moment you're the only > one doing any HotSpot development.) I'm not. :) > By jumping to -current, you severely limit both the developers *AND* > testers for the code, so you'll continue to be the one-man show. > > If that's what you want, then you'll get your wish. If, however you Well, I'd like to think of it as destiny, maybe punishment and not a wish as you say. ;) > want others to jump in and help you (as well as use the fruits of your > labors), then we need to keep -stable a supported platform, even if it's > non-optimal. Nate !! take a pill dude !! I know what I'm doing. The answer to all of this is backporting libc_r to -stable. > Define progress? Getting stuff working under -stable is progress, and > ripping the code out is certainly not progress. Progress is what I deem to be important at this time. By moving to -current I got around a problem with userspace signals automatically that was previously effecting the port. That's a good thing, otherwise I'd still be screwing with stuff that is already fixed in -current. Next on the list is red/yellow zoning if I choose to do that. My intentions here are to move into straight kernel programming after this project, but I definitely intend to get this project working pretty well before I focus on other things. I'm not exactly abandoning it as you might think or what was implied in previous emailings, so the concerns aren't completely fatalistic. What you've said is valid except that the solution is a backport of libc_r. > Fair enough. Does Dan know exactly what parts of libc_r need to be > merged back in? Can you help him out there, so that the changes are > made back to -stable, so that other developers (and users) can get a > chance at HotSpot? That would be a temporary setback for you as far as > bit-twiddling and such, but it would bring the project and other > developers much further ahead. Dan shouldn't be doing that stuff either, he's got other crazy stuff to worry about. I was hoping that somebody else in this project would take that task on. [setbacks] Well, not really. It's *so* pre-alpha at this time that nobody but the most adventurous can help anyways. Even then you pretty much have to be pthreads expert (+ OOP language runtimes) to fix any of the serious problems. The HotSpot sources are completely mind boggling BTW. For those folks that are willing/capable to work on this, porting libc_r and/or running -current isn't going to be a serious problem or blockage for them, however that does cut out the general bug hunting community. That's a legitmate consideration later on in the project, but not now. Give me a couple of weeks to mesh out a couple of things. I know folks are eager to get at it under -stable, but the key component here is getting libc_r backported. I'm not sure what else here to say. bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message