Re: [PATCH 05/29] MIPS: Add Cavium OCTEON processor support files to arch/mips/cavium-octeon/executive and asm/octeon.

[David Daney <ddaney@caviumnetworks.com>]

Christoph Hellwig wrote:
> Still lacks an explanation what the mess in the executive directory
> actually does.

I will try to explain it.

First a little background:  The OCTEON processor has many CPU cores 
(current parts have up to 16, but more are possible).  It also has a 
variety of on-chip hardware blocks for things like network acceleration, 
encryption and RAID.

One typical configuration is to run Linux on several of the CPU cores, 
and other dedicated applications on the other cores.

Resource allocation between the various programs running on the system 
(Linux kernel and other dedicated applications) needs to be coordinated. 
  The code we use to do this we call the 'executive'.  We have gathered 
all of this code together and placed it in the executive directory.

Included in the patch set are the following files:

cvmx-bootmem.c and cvmx-sysinfo.c -- Coordinates memory allocation.  All 
memory used by the Linux kernel is obtained here at boot time.

cvmx-l2c.c -- Coordinates operations on the shared level 2 cache.

octeon-model.c  -- Probes chip capabilities and version.

Of these files, the only one that doesn't interact with other programs 
running on the system is octeon-model.c.

Now if we look at other Linux ports we should consider xen.  You will 
note that it occupies its own directory and coordinates access to shared 
resources.  The analogy is not perfect, but there is some precedent for 
grouping this type of code together in a single place.

> And as mentioned before I don't think any amount of
> explanation would actually be enough for it, so please kill the mess
> and write it as proper kernel code.
> 

We are certainly open to suggestions, but we feel that keeping this 
shared resource management code segregated will result in easier 
maintenance and thus a higher quality kernel in the future.

Any suggestions as to how the code could be made more 'proper' are 
welcome, but telling us to kill the whole lot doesn't help us much 
unless you can suggest something better.

In any event, thanks for taking the time to look at it,
David Daney