From: "Adam J. Richter" <adam@yggdrasil.com>
To: davem@redhat.com
Cc: greg@kroah.com, linux-kernel@vger.kernel.org, mochel@osdl.org
Subject: Re: Patch: linux-2.5.45/drivers/base/bus.c - new field to consolidate memory allocation in many drivers
Date: Sun, 3 Nov 2002 23:50:15 -0800 [thread overview]
Message-ID: <200211040750.XAA01372@baldur.yggdrasil.com> (raw)
Dave Miller writes:
>I don't know how much I like the DMA memory being allocated
>transparently based upon some structure initialization values.
>
>I'd rather the DMA alloc/free be explicit in the drivers.
I think I roughly understand your attitude. Certainly I am of
wary adding more abstraction. Programmers tend to get lost in it. In
spite of the best intentions, code is often made less readable and
maintainable, bugs less apparent.
However, at some point, abstraction can be worth it. The
resulting code actually shirnking, accelerating, being clearer,
when the abstraction results in the removal of bugs, are all
metrics that I would look at.
Lifting most of the memory allocation and DMA mapping out of
the drivers will remove thousands of lines from Linux drivers in
aggregate and remove hundreds of potentially buggy error branches. It
will be a little easier see the hardware from reading the driver.
In comparison, the CPU costs are small and may be negative if
some of that consolidation allows for additional optimizations.
I'd be interested in knowing how you quantify this trade-off
and what you think might persuade you to support or at least be
neutral toward this type of facility (results of converting drivers,
examples of buggy error branches?). Please keep in mind that not all
drivers necessarily need to use these facilities.
>Otherwise, the ->ops->alloc_consistent et al. abstraction
>looks ok.
Thanks.
Adam J. Richter __ ______________ 575 Oroville Road
adam@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
next reply other threads:[~2002-11-04 7:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-04 7:50 Adam J. Richter [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-11-03 22:40 Adam J. Richter
2002-11-04 6:49 ` David S. Miller
2002-11-02 23:55 Adam J. Richter
2002-11-02 19:29 Adam J. Richter
2002-11-02 20:42 ` Greg KH
2002-11-03 7:45 ` Adam J. Richter
2002-11-03 12:33 ` Alan Cox
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=200211040750.XAA01372@baldur.yggdrasil.com \
--to=adam@yggdrasil.com \
--cc=davem@redhat.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.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
all inboxes | Powered by JetHome®