You definitely don't want '-w' by default as it is quite dangerous, but it can be useful on a live system to be able to modify variables in the kernel, and it does mean passing O_RDWR to kvm_open().

fix man page

In D54895#1255113, @minsoochoo0122_proton.me wrote:

Okay, I'll backport to our tree after Dimitry finishes his llvm import. But since it's unclear how upstream would respond as well as the progress on importing llvm 21, I think it would be better to review this now and bring -w change later.

In D54895#1255107, @emaste wrote:

I can implement this but we missed 22.1.x branching. I'll implement this in future when we MFV llvm 23.

We can also implement it in the copy in our tree and replace it with what ends up upstream. Most important is just to have agreement with upstream on the command-line interface so that we don't introduce a breaking change later on.

I can implement this but we missed 22.1.x branching. I'll implement this in future when we MFV llvm 23.

In D54895#1254999, @emaste wrote:

We open it in read-only mode by default so it's a bit safer, just to avoid possibly corrupting the running system.

I don't think lldb has a way that we could do something like this on the command line, but it ought to. It would be nice to support something like ssh's -o (although -o specifically is already taken) so that we could e.g. -o kernel-rw=yes or -o aslr=no.

We open it in read-only mode by default so it's a bit safer, just to avoid possibly corrupting the running system.

In D54895#1254974, @emaste wrote:

-w opens /dev/mem RW; without -w attempts to write will fail.

-w opens /dev/mem RW; without -w attempts to write will fail.

There is also reference HFI source code from Intel available at https://github.com/intel/intel_hfi

In D44457#1251574, @koinec_yahoo.co.jp wrote:

Thank you for your suggestion.
I understood that the driver name "coredirector" is vague.

How about "intelhfi" (Intel Hardware feedback interface)?

I understand that the "IntelThread Director" is the Intel's product name, and the Intel Software Developer Manual describes the following two functions:

• Hardware Feedback Interface (HFI): A function that communicates the performance and power saving scores of each CPU core to the OS.
• Thread Director (TD): A function that notifies the OS of the attributes of the instructions of the process currently running on the CPU core, such as normal instructions, SIMD(vector) instructions, etc.

The patch I'm proposing supports the "Hardware Feedback Interface". It would be nice to be able to support both in the future, but first I would like to support the HFI so that the scheduler can take into account the performance of the P-core, E-core, and LP-E-core. I'm also aware that AMD is implementing a similar function using a different mechanism in the Zen5/Zen5c, so I would like to be able to swap out both drivers to match the CPU. Therefore, how about combining "intel" and "HFI" to make it "intelhfi"?

I have re-created the build and test environment locally, and would like to correct the driver name to the one decided upon in this discussion.

@brooks That's a fair point. I added queue.3 with minimum intro and restored some man pages that can have queue.3 rather than listing all four.

I like the idea of the split, but I'm not convinced queue.3 should go away entirely. If nothing else this commit fails to remove all references to queue(3) in the tree and I suspect it's in some people's finger memory. I'd suggest transforming queue.3 into an intro-like manpage with a brief comparison of each of the relevant list/queue types.

man page update, added foreach, etc...

Thank you for your suggestion.
I understood that the driver name "coredirector" is vague.

In D54753#1251494, @markj wrote:

In D54753#1251493, @minsoochoo0122_proton.me wrote:

In D54753#1251492, @markj wrote:

In D54753#1251486, @minsoochoo0122_proton.me wrote:

This is really just an argument for moving away from C entirely. And I'd quite like that personally, but it's easier said than done.

My original implementation of minmax caching on wavl (using prev and next) always failed CI build on github,

I would strongly encourage you to work towards having a build-compile-test loop that does not rely on github or any third-party CI. You will be much more productive if you don't have to wait for CI to run in order to discover compile errors. It should take maybe 5 seconds to check whether your latest edits build.

In D54753#1251493, @minsoochoo0122_proton.me wrote:

In D54753#1251492, @markj wrote:

In D54753#1251486, @minsoochoo0122_proton.me wrote:

This is really just an argument for moving away from C entirely. And I'd quite like that personally, but it's easier said than done.

My original implementation of minmax caching on wavl (using prev and next) always failed CI build on github,

In D54753#1251492, @markj wrote:

In D54753#1251486, @minsoochoo0122_proton.me wrote:

In D54753#1251467, @markj wrote:

To be honest, I'm not thrilled to have a whole new set of functions for doing something already covered by queue.h and used extensively throughout the tree. These functions don't provide any type checking or debug assertions/poisoning like the queue.h macros do. These functions might be easier to use for someone not used to queue.h, but there are tons of examples of queue.h macro usage in the tree to draw from.

Type checking is done here and there is no need for (void *) casting. containerof() will return the structure that contains the node and other data. For assertion, we can let users to declare their own assert functions and call it in the headers, but I forgot to implement it here.

No, I mean that when when I define a list or queue head with LIST_HEAD, etc., I also declare the type of the item within that list. Attempting to insert an item of a different type results in a compile error rather than runtime memory corruption. This checking is useful, and is the entire reason for using macros in the first place. containerof doesn't provide any checking.

In D54753#1251486, @minsoochoo0122_proton.me wrote:

In D54753#1251467, @markj wrote:

To be honest, I'm not thrilled to have a whole new set of functions for doing something already covered by queue.h and used extensively throughout the tree. These functions don't provide any type checking or debug assertions/poisoning like the queue.h macros do. These functions might be easier to use for someone not used to queue.h, but there are tons of examples of queue.h macro usage in the tree to draw from.

Type checking is done here and there is no need for (void *) casting. containerof() will return the structure that contains the node and other data. For assertion, we can let users to declare their own assert functions and call it in the headers, but I forgot to implement it here.

In D54753#1251467, @markj wrote:

To be honest, I'm not thrilled to have a whole new set of functions for doing something already covered by queue.h and used extensively throughout the tree. These functions don't provide any type checking or debug assertions/poisoning like the queue.h macros do. These functions might be easier to use for someone not used to queue.h, but there are tons of examples of queue.h macro usage in the tree to draw from.

asserts I wrote were... nonsense. We should let users declare their own asserts instead.

@imp separated commits. I'll keep the 3-clause license and ask the foundation on Monday.

To be honest, I'm not thrilled to have a whole new set of functions for doing something already covered by queue.h and used extensively throughout the tree. These functions don't provide any type checking or debug assertions/poisoning like the queue.h macros do. These functions might be easier to use for someone not used to queue.h, but there are tons of examples of queue.h macro usage in the tree to draw from.

generally I like the concept. If this isn't just text motion, though, I'd split it into (1) move things to new man page with as few other changes as is needed to make them work and (2) improvements, etc as a second commit.

fix commit message

Update man page makefile

Fix headers

Fix style(9)

license format

use spdx identifier (keep original BSD 3-clause license)

@ziaee I splitted queue.3 into four man pages, so each of them should have length of 50% of the original NAME section (1/4 * 2 for function-based API).

split man pages

Split commits into individual files