31–38 of 38 posts
It's articles like this that keep me reading HN. Kernel bugs, POSIX thread details, code disassembly, binary patching, and I get to learn about a new signal. What's not to love?
So you can't boot OS X by taking stock Darwin/XNU and recompile? If so that is kind of disappointing. I understand they have private code that they don't want to open up but it would be nice if you could still boot with a self-compiled kernel.
So you can't boot OS X by taking stock Darwin/XNU and recompile? If so that is kind of disappointing. I understand they have private code that they don't want to open up but it would be nice if you could still boot with a self-compiled kernel.
You can. See http://shantonu.blogspot.com/2012/07/building-xnu-for-os-x-1...
I guess Apple doesn't exactly shout from the rooftops how to do this but I see now that this is the top Google hit for "building xnu". So it's not too hidden.
Can someone explain what this patch actually does? I have an old Macbook Air with a malfunctioning sensor that cause the CPU to always run in powersaving mode (capped at 800 mhz), so it's basically unusable under OS X. I have walked around this issue by installing Linux which allows me to tune the CPU governor manually, and it uncaps the artificial limit that the malfunctioning sensor puts. Would this patch allow me…
Earlier quoted context omitted.
Last time I checked on this, there was no safe way (i.e. using only async-signal-safe calls) to list the contents of /dev/fd post-fork. Did I miss something?
It's interesting that starting a new process in a signal handler is something you want to do. (I just searched and yes I understand fork() and exec() are spec'd by POSIX to be safe.) It seems like writing safe signal handlers is hard enough, making them multiprocess seems like a "now you have two problems" kind of thing. I suppose if I am not mistaken you could go the pre-readdir() route and open a directory with ope…
(In both cases, you can't count on currently acquired locks ever being released. In a signal handler, this is because it could be acquired on the current thread, and post-fork, this is because all other threads have been killed from the perspective of the child process. As such, no lock-based code can safely be called.)
Can someone explain what this patch actually does? I have an old Macbook Air with a malfunctioning sensor that cause the CPU to always run in powersaving mode (capped at 800 mhz), so it's basically unusable under OS X. I have walked around this issue by installing Linux which allows me to tune the CPU governor manually, and it uncaps the artificial limit that the malfunctioning sensor puts. Would this patch allow me…
You could try NullCPUPowerManagement.kext. It's used in the OS X x86 community to disable the built in Power management. If you don't mind getting your hands dirty you might be able to get it (or another related kext) to turn off frequency switching. [1] http://www.osx86.net/downloads.php?do=file&id=16
Can someone explain what this patch actually does? I have an old Macbook Air with a malfunctioning sensor that cause the CPU to always run in powersaving mode (capped at 800 mhz), so it's basically unusable under OS X. I have walked around this issue by installing Linux which allows me to tune the CPU governor manually, and it uncaps the artificial limit that the malfunctioning sensor puts. Would this patch allow me…
You could also try this out... https://github.com/hholtmann/smcFanControl/tree/master/smc-c...