--aT9PWwzfKXlsBJM1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 20, 2007 at 05:07:54PM -0800, Bucky Katz wrote:
> Bill Studenmund <wrstuden@netbsd.org> writes:
>=20
> > Actually, it's not a social problem. Maintaining two totally divergent=
=20
> > code bases is a technical problem.
>=20
> It would be. That's not what we are asking for here.  We're asking for
> a kernel compile time define that turns on a feature if requested and
> we'll maintain that feature once you've restored it.
>=20
> This is no different than N other kernel compile time features that
> every OS that's had more than one release finds itself dealing with.
>=20
> > It's one thing for there to ba an SA option that can be enabled in a
> > UP kernel. It's another for there to be two different scheduler
> > infrastructuers and two different interrupt infrastructures. The
> > latter is not maintainable.
>=20
> I disagree. See above.

If the SA code were adapted to cope with the new scheduler and locking,=20
you'd be right. Then I think there'd be little objection to having it=20
around. I actually discussed this very issue with Jason at lunch.

Unfortunatly the SA code doesn't cope with the new scheduler and locking.
The problem is that no one, you or within the NetBSD project, seems
interested in doing this. I think most of the NetBSD developers are most
interested in things that work on MP systems, so stuck-in-the-past SA
won't be interesting. You've indicated that you aren't interested in
making this change.

Thus to make the SA code work, we have to revert other changes in the=20
kernel. As time goes by, the amount of things that need reverting will=20
grow, and so the "DO_SA_UP" option will grow to encompass more and more of=
=20
the kernel.

Interrupt handling is going to change as part of fine-graining the kernel.=
=20
How interrupts actually run will involve the scheduler and locking=20
primitives. Thus, if SA is not updated to work with the new scheduler,=20
soon most drivers will need some sort of "cope with old-style interrrupts"=
=20
code.

That's why I said it was more than just an option.

> > Bucky, what do you want?
>=20
> Which part of what I've asked for isn't clear?

That was a rhetorical question.

> I want y'all to communicate with your users before you dump
> functionality.
>=20
> I want an evbarm port maintainer who actually maintains the port.
>=20
> I want m:n threads back in the uniprocessor case, something I was
> working with people to make happen before Jason showed up out of
> nowhere with his fiats.
>=20
> I want to contribute a bunch of stuff back to NetBSD, but y'all are
> making me want that less all the time.
>=20
> I want the NetBSD developers to do this as an act of good faith, so I
> can use that act in arguments about why we should have just used Linux
> in the first place.
>=20
> I want half a dozen other changes I've communicated to core and have
> been told are reasonable.

The important point is that "being rude" is not in the list.

You're being told that how you are approaching things is not going to help=
=20
you get what you want.

> > You claim you want things to work. However you are being routinely
> > abrasive and rude. This behavior pattern is not encouraging others
> > to actually help you. You have been told this. This is a volunteer
> > project, and as such it matters how you ask for things.
>=20
> Oh dear, let's make the failure of the NetBSD developers to work with
> its user community all about me showing some frustration after months
> of trying to be polite.

Please note. I'm not disparaging the fact that you got upset. I'm trying=20
to point out that remining rude and abrasive is actively discouraging=20
folks in the NetBSD project from helping you. Your continuing behavior,=20
both the immediate present and the future, is the issue.

Put another way, two wrongs do not make a right.

The pain you felt at the threading change gives you a fair amount of
"cred" with the project. Irritating the developer community decreases said
"cred." I recommend spending it well. You've already gotten ARM fixed
(Matt Thomas's shark, running current, has finished rebuilding itself).

> Yes, indeed, it _does_ matter how you ask.  I tried polite. Got zero
> back for six months.  Now I'm trying direct.  If that doesn't work
> then I'll reduce my team's committment to NetBSD.

I'm sorry. You are not being direct. You are being rude and abrasive.=20
Direct is different.

> > So why, if you really want things to work, are you continuing to
> > behave in a manner that you have been told will not encourage others
> > to make SA or M:N work?
>=20
> Well, given that people have fairly abrasively told me that they're
> not going to make SA or M:N work, even when I did ask politely, at the
> start of this exchange, I'm not seeing where I'm losing anything at
> this point.
>=20
> > While Jason is not core, he started the newlock branch way back
> > when. He also knows a fair amount about how the scheduler works and
> > how this part of the kernel works. His input, that a revived SA
> > would need to be adapted to cope with a changed scheduler, is the
> > exact kind of input core would need to answer your request.
>=20
> Then, perhaps, he should have offered advice to core, rather than flat
> fiats to the users.

Jason has given no fiats that I have seen. The statement that the
scheudler and locking have changed is either true or not true. I
understand it to be true. The statement that we aren't ripping 1:1 out
strikes me as a realistic assesment of the project, where it is, and what
it needs to do to go forward.

I am most frustrated by all of this as many of the things you ask for and
claim to want are reasonable and things I desire. However how you are
participating in the discussion is washing all of that out.

Take care,

Bill

--aT9PWwzfKXlsBJM1
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFF2633Wz+3JHUci9cRAmM4AKCVaveY6YT9rrNzjo3r+WnOpCsUHACggYwA
irD5nnQemkuPlZLOCZ9shko=
=w2GR
-----END PGP SIGNATURE-----

--aT9PWwzfKXlsBJM1--