RFC: qe lib code location?

RFC: qe lib code location?

[Kumar Gala]

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)

Yes, one can argue the cpm code should live in drivers/cpm by this  
logic, but lets considered them grandfathered for now.

- kumar

Re: RFC: qe lib code location?

[Dan Malek]

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

Re: RFC: qe lib code location?

[Andy Fleming]

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.
>
> Thanks.
>
> 	-- Dan
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: RFC: qe lib code location?

[Dan Malek]

On Oct 16, 2006, at 2:46 PM, Andy Fleming wrote:

> My reasoning is that, should Freescale decide to release a non-
> powerpc chip with a QUICC Engine,

Pigs will fly someday, too, but I'm not making plans for that :-)
If you are going to speculate, history shows there will more
likely be yet another version of some communication engine
before there will be a something other than a Power core
with one.

> ....  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.

I thought I provided some reasoning, but I suspect
speculation will prevail.........

Thanks.


	-- Dan

Re: RFC: qe lib code location?

[Vitaly Bordug]

[-- Attachment #1: Type: text/plain, Size: 660 bytes --]

On Tue, 3 Oct 2006 11:34:11 -0500
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)
> 
> Yes, one can argue the cpm code should live in drivers/cpm by this  
> logic, but lets considered them grandfathered for now.
> 

My vote to  let it be as it is now. The lib should be generic enough and for now there are way few QE-enabled designs to declare it generic even inside ppc. Once it virtually become such a thing - nothing will prevent us to move it to the proper  location IMHO.

Thanks,

-Vitaly

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]