[feat] Add basic support for iOS 6.1

[tslmy]

Tested working on an iPod touch (4th gen) running iOS 6.1.6:

process information	IO information

How to build

Prerequisites:

• macOS with Homebrew. Tested on macOS 15.7.2 (24G325).
• Xcode 4.6.3 DMG mounted at /Volumes/Xcode.
• automake (brew install automake)
• ncurses (brew install ncurses)

Prepare the SDK

htop needs the IOKit framework for probing battery, disk I/O, and GPU statuses. The vanilla iPhoneOS6.1 SDK does not provide headers for IOKit, so we'll have to stitch together a Frankenstein-style SDK for getting around it.

Assuming you are at a directory outside of htop codebase:

set -gx FOO "/Volumes/Xcode/Xcode.app/Contents/Developer/Platforms"
cp -r $FOO/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk .
cp -r $FOO/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/System/Library/Frameworks/IOKit.framework/Versions/A/Headers iPhoneOS6.1.sdk/System/Library/Frameworks/IOKit.framework/
cp $FOO/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/IOKit.framework/Versions/A/Headers/storage/IOBlockStorageDriver.h iPhoneOS6.1.sdk/System/Library/Frameworks/IOKit.framework/Headers/storage/

Don't unmount the Xcode DMG just yet; we still need the simulator's SDK (for libproc.h).

Build

Assuming you are now in the htop directory, here's the full commands needed to build:

set -gx IOS6_SDK_PATH "/path/to/the/frankenstein/sdk/above/iPhoneOS6.1.sdk"

./autogen.sh
./configure \
  --host=armv7-apple-darwin \
  --disable-unicode \
  --disable-sensors \
  --disable-hwloc \
  CFLAGS="-arch armv7 \
        -miphoneos-version-min=6.1 \
        -isysroot $IOS6_SDK_PATH \
        -I/Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/include \
        -I/opt/homebrew/opt/ncurses/include"
make

[Explorer09]

While this thing might work, the fact that it's generated suggests we cannot merge it as is. Because there's no human review, and there is a copyright concern (the AI might have copied code from someone else that is unlicensed).

Putting the general issue of AI-generated code aside, i see there's a massive style violation. We're not defining or using a macro token like TARGET_OS_IPHONE. Besides, the missing libraries and headers in iPhone should be addressed with configure script macros. So a AC_CHECK_HEADERS(libproc.h) call and a substitute header ProvideLibproc.h might be a good way to start.

[tslmy]

Thank you @BenBE and @Explorer09 for the very detailed reviews! Let me address them and get back to you. Putting this to draft mode while I'm at it.

Is there unit tests that I can run?

[BenBE]

Please note the instruction regarding rebasing/amending your commits for PRs in the style guide.

[tslmy]

Still grinding on it! 💪

I think I’m getting somewhere pointing the compiler to a libproc from another SDK. If that works, we don’t need a code change, and it will just be a matter of documenting what build parameters to use.

Thank you for the continuous discussion today!

[Explorer09]

The entire PR has become too messy for me to review further. There are still coding style violations here and there. But it seems like there are some compatibility fixes that can be cherry-picked early (such as the check of struct vm_statistics64.compressor_page_count).

[BenBE]

Dear @Explorer09,

Please keep discussion in here civilized.

If you don't like AI-generated code: Fine.

If someone has no experience with a certain tool: Help them to get to know that tool or point them to resources that provide an introduction or explain necessary concepts.

If code doesn't follow the coding style: Explain the issue and provide possible alternatives.

BUT: This is no place for attacks or personal vendettas against any particular technology, just because someone chooses to use them.

This is voluntary work. Nobody forces you to respond to each and every issue/PR.

[tslmy]

I'm sorry you feel this way @Explorer09 . Please take a break and you're welcome back when you feel better.

To both of you @Explorer09 and @BenBE :

Thanks for the reviews again. Let me put this PR to draft mode again while I'm at it. (I might need to pick this up only at a next weekend, though.)

In general, I'm a bit confused about the "code style" that you all have been referring to. I thought those changes are applied automatically, yet I don't see a pre-commit hook or a CI job kicking in.

I've been treating the code style doc as "hey don't be surprised if we modify your code this way eventually / don't be offended when a script keeps formatting your code this way", but judging from your comments this isn't the case.

Are those code style rules to be followed manually?

[Explorer09]

@tslmy

In general, I'm a bit confused about the "code style" that you all have been referring to. I thought those changes are applied automatically, yet I don't see a pre-commit hook or a CI job kicking in.

I've been treating the code style doc as "hey don't be surprised if we modify your code this way eventually / don't be offended when a script keeps formatting your code this way", but judging from your comments this isn't the case.

Are those code style rules to be followed manually?

Some code style cannot be automated prior to commit, and our attitude to pull requests is that: it is the OP's responsibility to code in our style when proposing code changes. If someone cannot bother to adapt to our code style, then it's better to maintain htop in their fork and not propose upstream.

Significant disruption to code style and/or paradigms can complicate other developers when reviewing your code. And note that I only review htop PRs on the voluntary basis - and it would be unpleasant for me if someone seems to be deliberately wasting my time.

[tslmy]

@Explorer09 :

Sure, I'll comply my PR to the code style. It is going to take me some time, but that's standard work anywhere. No problem with that.

I don't believe anyone is interested in deliberately spending their time on wasting your time. Has that happened to you? Do you want to talk about it?

[BenBE]

In general, I'm a bit confused about the "code style" that you all have been referring to. I thought those changes are applied automatically, yet I don't see a pre-commit hook or a CI job kicking in.

I've been treating the code style doc as "hey don't be surprised if we modify your code this way eventually / don't be offended when a script keeps formatting your code this way", but judging from your comments this isn't the case.

Are those code style rules to be followed manually?

The code style is not done automatically, as the code base has several aspects that would break any automatic formatting in a way, which causes unnecessary noise. One example is indentation of case labels inside switch statements, where you have several sections of the code that indent them, with other parts not indenting them. So the general consensus on the code style document is "write your code in such a way that someone looking at the changes would not notice them being made". That's also why the code style gives some specific hints on certain aspects (these are the ones that are fixed throughout), but is more open on other aspects. There is some rough command mentioned in the style guide that does the formatting approximately, but still you'd need to select only the parts that concern your patch.

Same goes for the header includes: As you noticed, there are some situations where the usual alphabetic order just wouldn't work. Thus automatic enforcement just wouldn't work. And minor deviations are acceptable if they are missed or justified. When writing a PR the style guide actually encourages you to fix minor style issues you notice along the way, like the missing NULL check or even the header ordering issue that was present even before your PR. The only thing the style guide asks in this case is to have these changes in separate commits. More on that in a moment.

As code style also includes other aspects like how you perform certain operations. For example with the libproc situation you have multiple ways to go, like distributing several #ifdefs all over the code for each site where you need access to that library, or you could do a central approach like has been done with e.g. ProvideCurses.h that streamlines the various ways that ncurses wants to be babysitted and just makes things "work"™. This latter part is where AI tools love to stray off-road any time you're not watching carefully, which is part of why they cause some friction on things like with the build system. (Well, autotools is horrible to work with, even if you know what you are doing, but getting reasonable results from AI tools there is like fighting two up-hill battles at once – one against autotools and one against the AI tool).

And no: There is no commit hook magically fixing things. Writing well structured code is the responsibility of the developer – even if they decide to support their work with tools like code formatters (like astyle) or AI agents.

The style guide is as the word implies a guide and it's intentionally written with a lot of room for things that are acceptable.

Okay, not for the commits: The usual PR development easily spirals into dozens of commits with advancing things one step and rewinding others several times in a row. This makes the (version control) history terrible to read if left untreated. That's why the style guide asks you to group your commits not by when you changed things, but by the aspects that you changed in order to arrive at your goal. So any PR that's like more than 3 to 5 commits usually needs a VERY good explanation why it splits things into so many steps. The largest PR I can remember was one where I cleaned up a cross-platform feature to align on all platforms. And that one had only about 30 commits, when intermediate versions of that same PR peaked at over 90 commits. And these 30 commits were not the usual "trial-and-error" "back-and-forth" you have while developing, but the exact steps you needed to go to arrive at the new structure by transforming things from its starting point over to the desired code structure. And that's what is meant by the "rebase early, rebase often" in the style guide: Don't document your journey through the maze, but the best path to reach its goal.

[tslmy]

@BenBE that totally makes sense to me. Thanks for the very detailed explanation of the rationales. (What you wrote should really be stored in doc/!)

Let me undo my commits, regroup them, and then force-push a cleaner "history".

---

Spoiler alert -- With a Frankenstein-style SDK I pieced together from iOS and macOS SDKs, I was able to make the IOKit work:

I'll revert some of the changes in this PR soon and provide instructions on how to compose this SDK instead.

[Explorer09]

And no: There is no commit hook magically fixing things. Writing well structured code is the responsibility of the developer – even if they decide to support their work with tools like code formatters (like astyle) or AI agents.

While automated code style fixing tools can correct the line breaking, indents and token spacing, there are many things that would be off the scope of said tools: Variable or function naming, choice on whether to define a constant as a macro or enum, the overall code structure in a header or source file, etc.

Therefore, don't expect there would be a tool, AI powered or not, that magically fixes everything.

[tslmy]

Hi all,

What a journey!

This Frankenstein-style SDK worked better than I expected (🤦 ). It inspired me to use iPhone Simulator's SDK files for this libproc support, so I don't even need XNU now. This PR has now boiled down to just 4 small patches, which I've re-organized as atomic commits.

I guess this "simulator SDK will help a lot" is common knowledge to the jailbreak community 🤷 . But when it comes to learning something, later is better than never! :D

I appreciate you all guiding me through this weekend hobbyist project of mine, as I'm quite amateur when it comes to htop codebase itself, open-source C programs in general, and iOS/Mach/XNU development. 🫡

[tslmy]

Turns out the deprecated name (*master*) is now caught as an error when building for modern macOS.

I've force-pushed again to make use of

#if __IPHONE_OS_VERSION_MIN_REQUIRED <= __IPHONE_6_1

as a stricter way to apply the patches. When building for iOS, this macro is needed anyway.

I can put this in configure, but another part of me doesn't want to expose this macro to all other platforms.