[PATCH rtems 01/18] Broke low-level parts of mv643xx_eth driver into separate files

[Chris Johns]

On 30/3/21 6:03 pm, Till Straumann wrote:
> Hi Chris.
> 
> On 3/30/21 4:16 AM, Chris Johns wrote:
>> Hi,
>>
>> Thanks for bring this to our attention.
>>
>> I have pinged Till via github about the patches.
>>
>> There is no point adding these to master because the legacy stack has moved so
>> appling the to the legacy stack repo is fine.

Agreed. The legacy stack has or is being moved out and the drivers can live
there for as long as someone wants that code and keeps it working.

I just need to review them a little more before merging onto the 5 branch. I
think having the legacy drivers on the 5 branch is a good thing. It will help
the migration process for those on 5 and the legacy stack move to libbsd.

> I'm not sure if I understand you correcly but I want to point out that
> the mv643xx_eth driver consists of two layers.

Thanks. I am farmilar with the libbsd code.

>  a) a low-level, BSD-agnostic part (mv643xx_eth.c) which should IMO always
>     be part of the BSP. We used this e.g., at SLAC to do real-time low-level,
>     bare-bones (w/o TCP/IP) ethernet.
>  b) A BSDnet glue driver (building on top of a). The glue driver is different
>     for legacy networking (mv643xx_eth_bsdnet.c, part of BSP)
>  c) nexus BSDnet driver for rtems-libbsp (builds on top of mv643xx_eth low-level
>      driver).

So the libbsd parts expect the BSP to have the driver?

There are other PowerPC related efforts underway for the beatnik e1000 and the
mvme2307 (mvme2700). It would be good to get them all to live to together.

> The b) piece may become obsolete when the legacy stack is abandoned but
> --again-- IMHO, the low-level driver should remain.

The libbsd drivers all reside in libbsd. The number of drivers not provided by
libbsd is small.

> Cheers

Great to have you back and providing patches. Thank you.

Chris