[Top] [All Lists]

Re: [PATCH 05/29] MIPS: Add Cavium OCTEON processor support files to arc

To: Christoph Hellwig <>
Subject: Re: [PATCH 05/29] MIPS: Add Cavium OCTEON processor support files to arch/mips/cavium-octeon/executive and asm/octeon.
From: David Daney <>
Date: Fri, 07 Nov 2008 09:14:54 -0800
Cc:, Tomaso Paoletti <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <>
User-agent: Thunderbird (X11/20080723)
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

<Prev in Thread] Current Thread [Next in Thread>