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

Unfortunately parsing diffs from git format-patch from phabricator side seems to be broken. It only shows the first (and the most trivial) commit. I'm using basic git diff here.

Fix diff with arc cli

Fix style(9)

Unfortunately parsing diffs from git format-patch from phabricator side seems to be broken. It only shows the first (and the most trivial) commit. I'm using basic git diff here.

I'm abandoning this revision for the following reasons:

In fact, the macros added as part of implementing eMMC support already
were based on v5.1 of the eMMC specification. However, some have been
shortened on purpose in order to make it easier for keeping resulting
code within 80 columns.
Apparently, Linux chose to do the same and as you say, still as of today
uses e. g. EXT_CSD_CARD_TYPE and EXT_CSD_PART_CONFIG. Thus,
it seems backwards to change such macros to something Linux doesn't
use either.
Moreover, with 49 chars EXT_CSD_NUMBER_OF_FW_SECTORS_CORRECTLY_PROGRAMMED
is ridiculously long and Linux apparently doesn't have a macro for that
register at all.
Thus, overall, I'd prefer to stick to the convention of shortening macro
names where it makes sense (also for additional ones being added), and to
just add alias macros to linuxkpi when needed.
Generally, your patch also mixes the addition of new macros for mostly
SPI mode with changing existing ones, which should be separate changes,
if at all.

stick with mmc for now

fix missing stuff

As this moves MMC 3.31 to eMMC 5.1, we need to discuss backward-compatibility issue.

Partial build fix

This change could be controversial: both keeping old name and strictly following the spec's name makes sense. Even Linux doesn't strictly follow spec's field name such as PARTITION (PART) and DEVICE ('CARD`), so handling these cases in linuxkpi header is inevitable either way. I want to hear others' opinion on this.

Align comment