Bill Studenmund <wrstuden@netbsd.org> writes:

> On Sun, Feb 18, 2007 at 12:01:53AM -0800, Bucky Katz wrote:
>> Bill Studenmund <wrstuden@netbsd.org> writes:
>> 
>> > On Sat, Feb 17, 2007 at 09:55:12PM -0800, Bucky Katz wrote:
>> >> 

> Well, I guess the question is what is the goal?
>
> Getting 1:1 threading on ARM working should happen once things are 
> compiling. So for 1:1, I think 'compiles' == 'works'.

'compiles' == 'can start debugging'

> Getting m:n threading working will take a lot of work. It will take much 
> more than getting locks to work.

It should take very little work. m:n threading already works, on
up. All it takes is carefully ifdefing and making it a conf feature
that's only available in uP.

>> surgery on subsystems to fix locking.  In fact, the _last_ thing
>> I'd do as part of trying to make my locking more fine grained is to
>> start by doing new locking primitives.
>
> Well, what if you were setting out on file graining, and the only
> lock primitives you had sucked? i.e. you did not feel they were
> sufficient for the transition? That's the position we felt we were
> in, and which is why Jason Thorpe started the newlock branch way
> back when.

Then I'd do an a a/b b transition. I would be _very_ worried that if I
didn't get my locking primitives right the first time I wouldn't get
them right the second either.

I also would solicit as much help as I could get up front. Redoing
locking primitives for a multi-architecture OS and not screwing over
at least one active architecture is difficult.

> I'm sorry, but it takes two to communicate. I agree we, the NetBSD
> developer community, could do more to include others in
> discussions. But I also have to question if you have been
> approaching this in a way that really makes us want to communicate
> with you. Your pain and frustration have been very clear. But I
> haven't seen a lot of, "Let's get this fixed," attitude in the
> messages so far. What would you do, were you in our shoes?

If by "Let's" you meant me volunteering my team as the fixers, no, you
haven't, and you're not going to. I don't currently have the resources
available to fix something I didn't break.

Further, I wish that NetBSD developers clean this up as a
demonstration to my management that some of the things we sold them as
strengths of working with NetBSD that they doubted are in fact true.

If by "Let's", you meant "positive suggestions for how to solve the
problem from Bucky", you have, but either you've disregarded them, or
you disagree with them.  I've also communicated a bunch of suggestions
to core.

I _do_ understand your development process. What I propose is meant to
help you fix it.

It has been suggested to me off line that I'm starting to sound
monotonous, so I am _not_ going to hammer on my points about how you
should treat -current in this email, but I will defend those comments
as attempts to help you clean up your process.

If I were in your shoes?  I would be defensive and reactionary,
because no one likes to have flaws pointed out. I'd fail to understand
all of the suggestions being made to me because I was filtering
through my defensiveness. I'd be stiff necked about backing out the
change, whether it was really the right thing to do or not. I'd make a
lot of promises about doing better in the future while not acting on
them immediately. I'd be strongly tempted to kill the messenger over
the message. I'd probably rush together a fix for ARM not compiling
but be unable to test it and run out of energy before actually getting
m:n back into uniprocessor.

Knowing my failings, I work hard to never be in your shoes.