that was gonna' be my next question - is it possible to use 1 cpu in a multi-cpu system.
seeing that it is, probably means that your task is theoretically feaseable.
that also means that running another os on that cpu is theoretically possible too.

this is new to me too so please post all you can minus the proprietary stuff.

maybe you can consider implimenting something like a beuwolf cluster (the 2nd cpu being in a totally different box with its own memory and bus...). then you can do whatever you want with the 2nd cpu/ system so long that it can communicate with/ is triggered by events from the 1st cpu/ system.

You always use one CPU in a multi-cpu system ...

Trite - what about multi-threaded applications ???. And what about keeping every other task *off* that CPU.

As to the OPs conundrum, have a look at the cpusets project. Initially probably designed from the NUMA mindset, but intrinsically not limited to that. This intersects with LSE and CKRM, and linux-vserver, and ...
So it probably ain't going to be widely available for a while .... ;)

Let's just say that what you're looking for is coming in Linux - might just be awhile arriving at your prospective customers doorstep.

http://www.intel.com/technology/computing/vptech/
http://www.amdboard.com/pacifica.html

ps3 to run multiple oses at the same time.

all is just future hardware.

It seems as though the BIOS on most multi-CPU MBs loads a "resource table" into memory, containing information about all CPUs and their Local APICs.

OK, it is gelling in my mind.

1) The BSP CPU boots Linux in non-SMP mode, not invoking any logic concerning multiple CPUs. (kernel vs. kernel-smp)

2) The application on the BSP starts, and using the CPU resource table put in RAM by the BIOS, sends an boot interrupt to the AP CPU, and provides it with an image (OS) for it to boot. This image is my custom application.

3) The AP CPU's application will need to have:
a. A Linux kernel memory manager
b. PCI driver
c. I/O device driver
d. The propritary application

4) The AP CPU will be guaranteed to process I/O device data at that devices speed, and write results to memory in a place mutually agreed-upon by the AP application and the BSP application.

Problem solved, at a high level anyway. Now all I need to do is write a PCI driver, I/O device driver and memory manager and integrate them with the custom application on the AP.

No memory manager needed
 

Instead of porting the Linux memory manager, I will include the important physical addresses into the application image. That will simplify things considerably.

Impressive. You truly are a system programmer. My question is this though, how will you keep your custom OS from interfering with Linux on the BSP cpu? And why don't you trust sched_set_affinity()?

However if it works well and you are able to give us the equivalent of "alt-tab" between operating systems, both running natively, each with there own cpu dedicated to it, seamless device switchover, and you can monitor each OS from within the OS, that would the coolest thing since sliced bread.

Ofcourse someone might argue, its easier to just get another computer, but what do they know?

:)
Good luck with what you do.

a and d are mutually exclusive.
Which will cost you the price of buying a truck load of PCs and the time of all this being obsolete ...

So much negativity... :)

I am not a systems programmer really, mainly I have done protocol stack development. But every problem has a solution, right? I will also have a team to support the effort with some more specific and applicable skills.

No memory manager in the custom app, per my recent posting.

As for multiple PCs... Hmmm... We lose the sharing of memory problem, but still have the need to run without an OS. And this PC would have to manage all its own resources, something the Linux CPU would do in my solution. There are also limitations imposed by the application of the entire system. But I will mull this some more though...

How to keep Linux on the BSP and the custom app on the AP from interfering with each others' memory is TBD. I think it will be easy enough to manage how much of physical memory the Linux CPU uses. I am willing to assume that between the Linux kernel and the BIOS I will have the tools to do that. The trick will be to manage the same behavior in the custom app. All the while, both will need to access data regions.

Ideas? Or at least issues to consider, places to start researching...

So let's see, you plan to solve the memory issue as follows:

1. Boot your Linux O/S
2. Within the Linux OS you hard code a block of memory as used
3. You pass this address block to you app as being the available memory

You'll need to ensure that the Linux O/S will never move this block of memory for what ever reason. So you will need to look at how the Linux O/S manages the memory.

How will your network communication work? Will this be done by the app or will you let the O/S manage it, thus the app will pass the data back and forth through the O/S?

How does you app manage error situations? (write to a log file - disk IO) (write to the screen screen IO) {Both of these can produce conflicts with the O/S that is running} (network alert - not very satisfactory of the error is caused by the network itself)

Okay just a few thoughts and yes I am negative about you approach since - from what you have told us - I don't believe that this is the the safest approach. Sure it may work but I really believe that you are walking into a mine field wearing a magnetic belt. However, it's your call, all the best with it.

graeme.

Excellent point. I am thinking that I will want to divide memory into three main segments: 1( for the BSP, Linux and the main app, 2) for the AP app, and 3) shared memory.

Maybe what I could do for thr AP app is to boot a small assembly program first, which will immediately copy the main application program from the BSP's memory to the AP's memory, and subsequently branch to it. Hence the memory in which the application resides would be local to the AP and not managed by Linux.

I would also have to somehow ensure that shared memory stays contiguous and is not "managed" by Linux.

I am not sure yet how the system will function on the network. These details can be worked out per the requirements as they evolve. The BSP will surely have a NIC over which it converses. The AP may only listen and/or forward traffic over its own NIC.

It probably won't. It will be very simple, likely a state machine. Any interaction it has with the outside world it can have via the interface between the 2 apps in shared memory. The BSP Linux app will be what the outside world interacts with. As for AP status, the Linux app may expect periodic HELLOs from the AP app, and the failure to receive one may precipitate a reboot of the AP, or some similar approach. These are application details. The nasty stuff is managing memory between the 2 processors, and managing the AP's mammary.

I wish it were all my call. I have been given an assignment. The requirement that the special app do its job thousands of times faster than the main app is the thing that necessitates some special approach. Oh yeah - cost. Two systems would cost too much.

But I appreciate your input, especially this last one. You have helped me a lot in focusing on the challenges I face here. I am thinking hard to come up with another approach. The two systems approach is lingering in my mind. Maybe 2 in one chassis, each with 1 CPU, one running Linux, the other uClinux maybe.

copy 1st, then boot
 

No wait - the main app on the BSP copies the AP's app to the AP's physical memory, then boots the AP from it.