Hi Eric, Thanks for your reply. See below:
On 4/20/07, Eric Saxe <[EMAIL PROTECTED]> wrote:
> Q2: I am very confused about the naming and meaning of all these names: > sun4u, sun4v, starcat, safari, serengeti, sarek, .... I suppose it has > some logical structure and meaning, can anyone clarify? Well, sun4u and sun4v refer to system architectures. starcat and serengeti are the code names of two platforms in the sun4u architecture. We usually don't know when the platform code is being developed what the platform marketing name (uname -i) will wind up being...but the platform code name does tend to stick around. If it makes you feel any better, it confuses us (well, at least me) too...since i'll forget (or not know) what the code name really is for a given system i'm using (which is needed for assembling the right stuff for a test kernel ala Install(1)).
What exactly makes part of a "platform" ? Is it the whole configuration of motherboard, which processor, how much memory, which devices ... In the pc-market, there are numerous companies, each of which has numerous possible configurations. Is it for example equivalent to what Acer calls "Aspire 5670", "Aspire 5023", etc?
What are the > actual processor names? UltraSPARC * are the processor names, and they have code names just like the platforms. Jaguar, Panther, Niagara, etc... > Does the DR capability depend on the > processor, or the system architecture? (I thought this only depends on > the processor). Probably both I would guess. There's definitely a lot of support needed by the architecture to be able to power on, initialize, and bring online a processor while the rest of the system has already booted. > > Q3: In order to implement the processor shutdown from the scheduler, > is it correct that I should use these cpu_offline and cpu_poweroff > functions? Or should I find a DR implementation (which would be a sort > of wrapper, right?) and use that one instead? > This is also complicated by the fact that we might use a (simulated) > architecture that in real-life doesn't support DR. I guess it depends on what you want to do. If all you want to do is change the state of the CPU, then you could probably get away with using most of the routines in cpu.c with minimal code required in the architecture callbacks. If want to be able to actually delete/add processors to the system ala DR, then you'll need to implement more. Perhaps the fact that this is simulated is somewhat of a simplifying factor (less to do). :)
If with "delete/add processors" you mean physically taking the CPU package out of the computer, then no, this is not what we need. Obviously because it is a simulation, but also because we are targeting chip multiprocessors, which only have one package. If you mean something else, could you clarify?
> Q4: also in common/os/cpu.c, there are these kstats entries which seem > to record, among others, the idle time of processors. Can I read these > values from the kernel, or are they only for export to userspace? You can read them. There is a CPU_STATS() macro.
Thanks, Thomas -Eric
_______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
