From: Dan Malek <dan@embeddededge.com>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
Kim Phillips <Kim.Phillips@freescale.com>,
Li Yang <leoli@freescale.com>
Subject: Re: RFC: qe lib code location?
Date: Tue, 3 Oct 2006 13:30:20 -0400 [thread overview]
Message-ID: <713AF674-0689-4F20-9896-70696969ED24@embeddededge.com> (raw)
In-Reply-To: <724D42AC-3DBA-4B32-8E4A-914441251470@kernel.crashing.org>
On Oct 3, 2006, at 12:34 PM, Kumar Gala wrote:
> I was wondering what peoples thought were on having the qe lib code
> live in drivers/qe instead of sysdev/qe_lib (with the exception of
> the interrupt controller code)
My personal reason for choosing one place or the other
is based upon usefulness to architectures other than PowerPC,
or general kernel APIs that may change. If something is
useful to architectures other than PowerPC, clearly it
should go there. If the software has dependencies on
general kernel APIs (networking is a good example), I like
to put is there in hopes that someone changing the APIs
will at least make an attempt to keep this code up to
date as well.
I think it neither of these apply (and I don't think the VM
interfaces are a good argument because they generally
affect the architecture ports anyway), then I think it
should stay in a more architecture specific place.
> Yes, one can argue the cpm code should live in drivers/cpm by this
> logic, but lets considered them grandfathered for now.
I would say that based on my opinion above the cpm
stuff should stay in sysdev, too. These are not only
powerpc specific, but even Freescale embedded powerpc
specific. I don't think that code belongs in drivers.
Thanks.
-- Dan
next prev parent reply other threads:[~2006-10-03 17:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-03 16:34 RFC: qe lib code location? Kumar Gala
2006-10-03 17:30 ` Dan Malek [this message]
2006-10-16 18:46 ` Andy Fleming
2006-10-16 19:21 ` Dan Malek
2006-10-03 18:30 ` Vitaly Bordug
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=713AF674-0689-4F20-9896-70696969ED24@embeddededge.com \
--to=dan@embeddededge.com \
--cc=Kim.Phillips@freescale.com \
--cc=galak@kernel.crashing.org \
--cc=leoli@freescale.com \
--cc=linuxppc-dev@ozlabs.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