What are you using this for? I think it's ahoodchange, but I'm curios.

I htink that we need a PORTREVISION=1 addded to the Makefile.
I can help push this once it's ready.

Perfect. This is just what I had in mind.

Comma separated is preferred. Spaces happen to work.

This matches what I think one can do with mkimg

This looks good to me. It also shows a bit of a disconnect on how we've put the 'ranges' in different ways. A limit of 256 is likely better than 100 or 500, but honestly all are fine.

In D54810#1253014, @bz wrote:

In D54810#1252993, @emaste wrote:

Why do we use linuxkpi prefix sometimes and lkpi others?

But looks fine

Historically this was mixed. We are trying to use linuxkpi_ for official public LinuxKPi functions now and lkpi_ for internal. Historically there's also linux_ which we shoudl leave to the Linuxolator. Doing the full sweep one day will be tough but at least trying to keep it consistent for new stuff.

Should we add a README somewhere in sys/compat/linuxkpi/ and start writing these things down?

This looks good to my eye, but best get Kirk to confirm as well.

I like Kyle's idea better than mine...

I like the idea behind this, just have one question...

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.

I'm torn on this...
I'd rather have a regexp -> modules to load table that we cruise through so we can also do zfs
But at the same time, I don't want errors for people that have zfs or the p9fs modules in the kernel (I thought my playing with this required an additional module).
So this fills a need, but it's the end of the road for things like this...

@kib something like https://reviews.freebsd.org/D54751 maybe?

Yea. inline often isn't needed these days...

Tweaks from john: sizing variables and noting we can only do up to 2^16-1
queues, not the full 2^16. That's sane for the far forseeable future.

In D54714#1250118, @jhb wrote:

(I would probably put the uint16_t before the two existing bool fields, so that the fields are somewhat sorted by size, but that doesn't really matter)

Note: we could compress retries to 16 bits and have this be 16 bits too since the number of queues is limited to 64k if this busts the cache-line sizes of this struct.

This is a nice cleanup and eliminates a void * -> void ** type smearing we had with ElfAddr and should be a nop if I read right.

I'm agnostic on the NDEBUG issue, though have 'never disable assert' leanings. But just leanings, since performance is also important and I don't know the lay of the land here to have an informed opinion.

This works for me too. Feel free to revert the thing I committed.
I gotta work on tagging people better on github reviews

You could combine the two lines too by

OFFSET=$((0X$(hd...) ))

In D52780#1248183, @benoit_neviani.fr wrote:

First of all many many thanks for this ! Perhaps not the right place for this question but how this would work during upgrade, have you tested that ? would the data being copied on all ESPs ? I have to comment the /dev/gpt/efiboot0 line on fstab, without that when the first drive fails I am dropped to single mode , so I am wondering if commenting is the right thing to do (as this would not being mounted would it be impacted by potential upgrades). Many thanks for the clarification

LSI hasn't owned or marked this for a decade.