RFC: qe lib code location?
afleming at freescale.com
Tue Oct 17 04:46:33 EST 2006
On Oct 3, 2006, at 12:30, Dan Malek wrote:
> 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.
My feeling here is that, all things being equal, drivers/ is better.
My reasoning is that, should Freescale decide to release a non-
powerpc chip with a QUICC Engine, having the code in drivers/ makes
this easier. It would also allow for some screwier implementations
(put an 8360 on a PCI card, and just use the QE directly from the
host processor). Of course, all of this is pure speculation, so if
there's a good reason *not* to put it in drivers/, we should probably
just maintain the status quo.
>> 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.
> -- Dan
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
More information about the Linuxppc-dev