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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux