public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Henning P. Schmiedehausen" <hps@intermeta.de>
To: linux-kernel@vger.kernel.org
Subject: Re: Networking/Becker et al [was Re: pci-skeleton duplex check]
Date: Sun, 15 Dec 2002 13:06:41 +0000 (UTC)	[thread overview]
Message-ID: <athup1$pen$1@forge.intermeta.de> (raw)
In-Reply-To: 20021215123159.GJ27658@fs.tum.de

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   

      reply	other threads:[~2002-12-15 12:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-13 17:22 Networking/Becker et al [was Re: pci-skeleton duplex check] Larry McVoy
2002-12-13 21:19 ` Jeff Garzik
2002-12-14 13:28 ` Henning P. Schmiedehausen
2002-12-14 15:21   ` Rik van Riel
2002-12-14 20:47   ` Robert Love
2002-12-15  9:54     ` Henning P. Schmiedehausen
2002-12-15 12:32       ` Adrian Bunk
2002-12-15 13:06         ` Henning P. Schmiedehausen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='athup1$pen$1@forge.intermeta.de' \
    --to=hps@intermeta.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox