Networking/Becker et al [was Re: pci-skeleton duplex check]

Networking/Becker et al [was Re: pci-skeleton duplex check]

[Larry McVoy]

In the for what it is worth department...  My brain dump on this situation.

I know Dave Miller, Don Becker, and Jeff Garzik personally, we've spent
time face to face.  These are all good guys, very important guys to the
kernel effort.

I've known Don for a long time and we've had a bunch of talks about why
his style and the Linux style doesn't mesh well.  Here's my view, which
may or may not be shared.

Don is a careful, thoughtful guy.  He is quite conservative when it comes
to programming.  His style most closely matches the Sun kernel style of
development; it does not match the Linux style at all.  The Linux style
is a lot more free wheeling, stuff changes a lot and the kernel team
depends heavily on the fact that it is has this vast army of free testers.
Without that army, I shudder to think what things would be like, I do not
think the current development style would work anywhere near as well.

But it does work, and it violates a lot of engineering disciplines that
old farts, like me and Don, respect.  I've learned to live with it, even
respect the fact that the Linux team does so well.  Don is having a much
tougher time.  He really wants the Linux team to work more like he works
and the Linux team doesn't want to do that at all, they point at their
success and believe that their development style is part of that success.

It is worth putting on the record that Don has done a lot for the Linux
effort, a huge amount, in fact.  Without Don, Linux would be dramatically
less far along than it is.  I've been here since before it had networking
and it really took off when Don started writing drivers.

It's also pointing out that I think he's right about the networking
regressions, suspend/resume on laptops used to work and now the network
is almost always hosed after I do that.

I doubt that either side is likely to change their view.  But, the real
point is how to we get Don's brain engaged on the kernel networking
drivers?  A few thoughts:

    a) Don is going to have to accept that the Linux kernel approach is
       the way it is.  Sitting on the sidelines and whining is not going
       to change how the kernel is developed.  Either get with the 
       program or not, but don't sit there and complain but refuse
       to work the way the rest of the people work.

    b) The kernel folks need to listen to Don more.  Draw him into the
       conversations about interface changes, try and extract the 
       knowledge he has, it's worth it.  Not doing so just means you
       are wasting time.

    c) Don needs to kill those mailing lists he maintains or merge them
       with the appropriate kernel lists.  That is a big part of the
       problem, the interesting stuff seems to be happening over in 
       Don's part of the world and the mainstream kernel team isn't
       aware of it.

    d) Beer.  More beer.  Much more beer and some face time.  If there
       is a tech conference coming up, I think we should get Don to 
       come and give him the first lifetime achievement award for
       Linux kernel development.  Then shove him and the other network
       hackers into a room with a keg and not let them out until they
       are smiling.  BitMover will kick in some money towards this if
       needed.

--lm

On Fri, Dec 13, 2002 at 11:56:17AM -0500, Donald Becker wrote:
> On 13 Dec 2002, David S. Miller wrote:
> > On Thu, 2002-12-12 at 17:18, Donald Becker wrote:
> > > Or perhaps recognizing that when someone that has been a significant,
> > > continuous contributer since the early days of Linux
> > 
> > Until you learn to play nice with people and mesh within the
> > fabric of Linux development, I adamently do not classify you
> > as you appear to self-classify yourself.  You don't contribute,
> > you sit in your sandbox and then point fingers at the people who
> > do know how to work with other human beings and say "see how much
> > that stuff sucks?  well my stuff works, nyah!"
> ..
> > If Linux itself is worse off and went backwards in time for a while...
> 
> The development criteria used to be technically based, and that is still
> the public statement.  Now, as your statement makes clear, working code
> is an irrelevant criteria.
> 
> You comments immediately moved the subject from the technical merit and
> correctness of the code to an ad hominem attack.  The facts, and the
> code, clearly show the long term interaction and contribution.  In most
> cases the code and interfaces we are talking about were written and
> defined by me throughout the past decade.
> 
> 
> 
> -- 
> Donald Becker				becker@scyld.com
> Scyld Computing Corporation		http://www.scyld.com
> 410 Severn Ave. Suite 210		Scyld Beowulf cluster system
> Annapolis MD 21403			410-990-9993
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Networking/Becker et al [was Re: pci-skeleton duplex check]

[Jeff Garzik]

Larry McVoy wrote:
> Don is a careful, thoughtful guy.  He is quite conservative when it comes
> to programming.  His style most closely matches the Sun kernel style of
> development; it does not match the Linux style at all.  The Linux style
> is a lot more free wheeling, stuff changes a lot and the kernel team
> depends heavily on the fact that it is has this vast army of free testers.
> Without that army, I shudder to think what things would be like, I do not
> think the current development style would work anywhere near as well.
> 
> But it does work, and it violates a lot of engineering disciplines that
> old farts, like me and Don, respect.  I've learned to live with it, even
> respect the fact that the Linux team does so well.  Don is having a much
> tougher time.  He really wants the Linux team to work more like he works
> and the Linux team doesn't want to do that at all, they point at their
> success and believe that their development style is part of that success.

This meshes with what I've observed, too...

I'm not sure which is the bigger issue, Don's devel style versus Linux 
devel style, or use of kernel APIs, but both I think cut to the core of 
the differences in this situation.


> It is worth putting on the record that Don has done a lot for the Linux
> effort, a huge amount, in fact.  Without Don, Linux would be dramatically
> less far along than it is.  I've been here since before it had networking
> and it really took off when Don started writing drivers.

I give him a lot of credit too, though it's often in the way of trying 
to apply lessons learned from him to current net drivers and such.


> It's also pointing out that I think he's right about the networking
> regressions, suspend/resume on laptops used to work and now the network
> is almost always hosed after I do that.

suspend/resume in Linux has always been a hack, and will continue to be 
until the 2.5.x sysfs/device model is fully fleshed out.  Specifically 
for 2.4.x, let me know if your net driver doesn't suspend/resume 
correctly.  The cases I've tested work fine.  Make sure your distro is 
properly calling the /sbin/hotplug agent when suspend/resume occurs though.


> I doubt that either side is likely to change their view.  But, the real
> point is how to we get Don's brain engaged on the kernel networking
> drivers?  A few thoughts:
> 
>     a) Don is going to have to accept that the Linux kernel approach is
>        the way it is.  Sitting on the sidelines and whining is not going
>        to change how the kernel is developed.  Either get with the 
>        program or not, but don't sit there and complain but refuse
>        to work the way the rest of the people work.

indeed... central problem


>     b) The kernel folks need to listen to Don more.  Draw him into the
>        conversations about interface changes, try and extract the 
>        knowledge he has, it's worth it.  Not doing so just means you
>        are wasting time.

I try to do this, and I can point to many specific instances in the past 
when he's been very helpful.

I would love to get Don more involved in interface discussions though... 
typically where he pops up [where I see him] is more in the area of 
hardware experience and knowledge than interface discussions.



>     c) Don needs to kill those mailing lists he maintains or merge them
>        with the appropriate kernel lists.  That is a big part of the
>        problem, the interesting stuff seems to be happening over in 
>        Don's part of the world and the mainstream kernel team isn't
>        aware of it.

This is really a matter of getting his driver changes into the kernel, 
too...  Some mailing list users [not me] would probably complain about 
seeing support traffic for drivers that are not in the kernel.


>     d) Beer.  More beer.  Much more beer and some face time.  If there
>        is a tech conference coming up, I think we should get Don to 
>        come and give him the first lifetime achievement award for
>        Linux kernel development.  Then shove him and the other network
>        hackers into a room with a keg and not let them out until they
>        are smiling.  BitMover will kick in some money towards this if
>        needed.

mmmmmmm, beer :)

Re: Networking/Becker et al [was Re: pci-skeleton duplex check]

[Henning P. Schmiedehausen]

Larry McVoy <lm@bitmover.com> writes:

[... many true words ...]

a)
[...]
b)
[...]
c)
[...]
d)
[...]
e) put an alan-cox-like entity between him and the linux kernel developers
   which translates. Worked terrific for Andre Hedrick. :-)

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Networking/Becker et al [was Re: pci-skeleton duplex check]

[Rik van Riel]

On Sat, 14 Dec 2002, Henning P. Schmiedehausen wrote:
> Larry McVoy <lm@bitmover.com> writes:
>
> [... many true words ...]

> e) put an alan-cox-like entity between him and the linux kernel developers
>    which translates. Worked terrific for Andre Hedrick. :-)

I think we should volunteer Jeff Garzik ;)

Rik
-- 
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"october@surriel.com">october@surriel.com</a>

Re: Networking/Becker et al [was Re: pci-skeleton duplex check]

[Robert Love]

On Sat, 2002-12-14 at 08:28, Henning P. Schmiedehausen wrote:

> e) put an alan-cox-like entity between him and the linux kernel developers
>    which translates. Worked terrific for Andre Hedrick. :-)

Isn't that what Jeff is?

No one seems to have a problem working with him.  Jeff is the
maintainer.  An "Alan Cox" buffer works great when the maintainer is
loony but Jeff is the maintainer and not a wacko.  He can work with
Donald just fine if Donald plays the game.

(And I shall add I hope he does, because Donald is a gifted hacker)

	Robert Love

Re: Networking/Becker et al [was Re: pci-skeleton duplex check]

[Henning P. Schmiedehausen]

Robert Love <rml@tech9.net> writes:

>On Sat, 2002-12-14 at 08:28, Henning P. Schmiedehausen wrote:

>> e) put an alan-cox-like entity between him and the linux kernel developers
>>    which translates. Worked terrific for Andre Hedrick. :-)

>Isn't that what Jeff is?

Yes. And he does a great job. But the second he started to put
something in that he maintains in his subsystem, another obnoxious
developer with too much spare time popped up and started whining about
"don't put this crap in, Marcello". Of course, without offering any
alternative.


	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Networking/Becker et al [was Re: pci-skeleton duplex check]

[Adrian Bunk]

On Sun, Dec 15, 2002 at 09:54:05AM +0000, Henning P. Schmiedehausen wrote:
> Robert Love <rml@tech9.net> writes:
> 
> >On Sat, 2002-12-14 at 08:28, Henning P. Schmiedehausen wrote:
> 
> >> e) put an alan-cox-like entity between him and the linux kernel developers
> >>    which translates. Worked terrific for Andre Hedrick. :-)
> 
> >Isn't that what Jeff is?
> 
> Yes. And he does a great job. But the second he started to put
> something in that he maintains in his subsystem, another obnoxious
> developer with too much spare time popped up and started whining about
> "don't put this crap in, Marcello". Of course, without offering any
> alternative.

I remember the mail you were referring to but I don't have any knowledge 
regarding whether this specific patch is good or bad.

It's often better to reject bad code and to have nothing in the kernel 
instead of having bad code in the kernel. There are several examples 
where bad code entered into the kernel and it would have been better if 
it was rejected.

You might discuss whether the code in question is "crap" or good code 
but please discuss it on a technical level without personal offences.

> 	Regards
> 		Henning

cu
Adrian

-- 

Deutsches Grundgesetz, Artikel 1, Absatz 1, Satz 1:

  Die Wuerde des Menschen ist unantastbar.

Re: Networking/Becker et al [was Re: pci-skeleton duplex check]

[Henning P. Schmiedehausen]

Adrian Bunk <bunk@fs.tum.de> writes:

>> Yes. And he does a great job. But the second he started to put
>> something in that he maintains in his subsystem, another obnoxious
>> developer with too much spare time popped up and started whining about
>> "don't put this crap in, Marcello". Of course, without offering any
>> alternative.

>I remember the mail you were referring to but I don't have any knowledge 
>regarding whether this specific patch is good or bad.

>It's often better to reject bad code and to have nothing in the kernel 
>instead of having bad code in the kernel. There are several examples 
>where bad code entered into the kernel and it would have been better if 
>it was rejected.

>You might discuss whether the code in question is "crap" or good code 
>but please discuss it on a technical level without personal offences.

Hi,

the problem is, that Donald diverted in his drivers from the "official
stance" by introducing a pci-layer which he uses in all his
drivers. To him, at that time, it was technically superior to the
(then existing) PCI code and after he created this layer, he no longer
cared about the ongoing Linux PCI development because he wanted to
keep his drivers stable and laid the emphasis not on "keeping up with
every PCI change in a minor kernel revision" but to keep his drivers
stable.

You can't simply take Donalds' drivers and drop them into the
kernel. You need at least the pci-scan.c file and even then you might
either not get it to work or have to make code changes. BTDTGTT.

But you do have to start somewhere. If Jeff drops the drivers into the
source in a way that they compile and work even if they don't adhere
to every linux kernel programming standard (which seem to be chiseled
in jelly anway...)  and after that start converting with Donalds' help
to the actual PCI core code, that's IMHO the right way to go.

But if one gets shot down for even trying to start this, you might
(after a while) drive developers away from the kernel source (just as
it did happen with Donald).

I considered the ChangeSet which included pci-scan.c as a start and a
peace offer to Donald. Too bad, that not all core developers seem to
be as understanding and ready to make an admission as Jeff.

 	Regards
 		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20