|
From: Paul M. <pa...@sa...> - 2005-06-22 12:40:15
|
Julian Seward writes: > Hi. Lots of ppc32 stuff got folded into the 3 line today. > My apologies for how long it all took. Thanks for providing > 2.4.0-ppc as a base, and for your patience. I'm sure a ppc build > right now won't do anything much, but all the infrastructure is > in place and I hope it will be up to flying speed pretty shortly. That's great! > - in m_main.c, there's a bunch of stuff for finding (the?) vdso > address and various address-space-mashing stuff as a result. > Is this needed? Neither the x86-linux nor amd64-linux code > has anything similar, and it seems to work fine on all tested > x86-linux and amd64-linux distros. Nothing like that should be needed on ppc32. We don't have a VDSO, and when we get one, it will almost certainly end up being mapped by default at the 1MB point. > - I see that you also extract both the cache_line_size and the > hardware_capabilities from the aux vector passed to V, and > pass those onwards to the client. > > * cache_line_size is needed for implementing dcbz I see. > Is there a reliable way to get that same info without > asking the kernel? eg, on x86/amd64 one can do "cpuid" > in userspace and get all that stuff. Does ppc have something > similar? Not really. On many ppc32 machines there is a copy of the Open Firmware device tree in /proc/device-tree and it would be possible to go looking in there. Not all machines have OF though. There is a processor version register (PVR) which has a unique code for each processor implementation. Reading it is privileged, but Linux catches the exception and emulates the instruction for userspace. I don't recommend we do that, though, because it means we need a table of PVR values, which will get out of date (i.e. when you move to a new CPU you expect to need a new kernel but generally not new versions of userland things). The cache line size is also needed for implementing icbi, which ends up invalidating cached block translations. > * hardware_capabilities. Hmm. What's that used for? Is there > any significance to the fact that neither the x86 nor amd64 > code read that auxv entry? That's mainly used to tell whether we have altivec or not. I assume x86 and amd64 use cpuid to tell whether they have mmx/sse/sse2 etc. The easiest and best way on ppc32 to know the cache line size and whether we have altivec is to look in the aux vector. The code to handle them wouldn't even need to be #ifdef ppc32; on x86 we just wouldn't see those entries (well, we might see the AT_HWCAP, but that wouldn't hurt). Paul. |