From: Jeff Garzik <jgarzik@pobox.com>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
francis.wiran@hp.com, Greg KH <greg@kroah.com>
Subject: Re: [PATCH] cpqarray update
Date: Wed, 28 Jan 2004 18:39:49 -0500 [thread overview]
Message-ID: <40184845.3030008@pobox.com> (raw)
In-Reply-To: <15D09760-51A9-11D8-AF96-000A95A0560C@us.ibm.com>
Hollis Blanchard wrote:
> I'm defining a new bus and had copied pci_module_init() to
> vio_module_init(). Here's what Greg KH had to say about that:
>
>> Eeek! I want to fix that code in pci_module_init() so it doesn't do
>> this at all. Please don't copy that horrible function. Just register
>> the driver with a call to vio_register_driver() and drop the whole
>> vio_module_init() completly. I'll be doing that for pci soon, and
>> there's no reason you want to duplicate this broken logic (you always
>> want your module probe to succeed, for lots of reasons...)
Actually I disagree with GregKH on this.
The register/unregister functions need to be returning error codes,
_not_ the count of interfaces registered. It is trivial to count the
registered interfaces in the driver itself, but IMO far more important
to propagate fatal errors back to the original caller.
This is what pci_module_init() does... returns an error if an error
occurred, zero if not. Further, use of pci_module_init() makes drivers
future-proof for a time when the API can better return fatal errors that
occur during the registration process.
As it stands now, pci_register_driver() -can- call functions which can
fail internally (see what driver_register calls...), unrelated to the
driver, and the driver will never ever know this.
That is an ugly flaw in most current foo_register_driver() APIs. Errors
are silently lost :(
Jeff
next prev parent reply other threads:[~2004-01-28 23:40 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200401262002.i0QK2iAH031857@hera.kernel.org>
2004-01-26 20:15 ` [PATCH] cpqarray update Jeff Garzik
2004-01-28 15:46 ` Hollis Blanchard
2004-01-28 17:40 ` Greg KH
2004-01-28 23:39 ` Jeff Garzik [this message]
2004-01-28 23:44 ` Jeff Garzik
2004-01-28 23:51 ` Greg KH
2004-01-26 22:32 Wiran, Francis
2004-01-27 1:51 ` Jeff Garzik
-- strict thread matches above, loose matches on Subject: below --
2004-01-27 4:48 Wiran, Francis
2004-01-27 4:50 Wiran, Francis
2004-01-28 22:53 Wiran, Francis
2004-01-28 23:10 Wiran, Francis
2004-01-28 23:28 ` Greg KH
2004-01-29 16:39 Wiran, Francis
2004-01-29 16:56 ` Jeff Garzik
2004-01-29 19:20 Wiran, Francis
2004-01-29 20:14 ` Jeff Garzik
2004-01-30 16:22 Wiran, Francis
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=40184845.3030008@pobox.com \
--to=jgarzik@pobox.com \
--cc=francis.wiran@hp.com \
--cc=greg@kroah.com \
--cc=hollisb@us.ibm.com \
--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