Adrian commit his version in e56f7becc7efe05acbb08162961dca574b152720

In D51399#1308016, @adrian wrote:

yeah, I'm pretty sure the original interface was for hardware stuff, not per-interface stuff. I don't even recall if we had per-VAP ioctls handled by the driver.

I don't mind doing this change; drivers should document what ioctls are per-vap and what are global.

Anyone?

In D57063#1307735, @aokblast wrote:

In D57063#1307650, @bz wrote:

What's the expected bandwidth needed for that with VNC? 30Mbit/s?

Some body mentioned the samething with me privately. The actual speed it needs is 30 * 60fps. I guess you want to tell me that it is impractical. I will switch it to 2k tomorrow instead of 4k. Thanks!

We assume that parent it is not a drmn device. Given I added this, it was for mt76 back then likely, so this was clearly a bug.

What's the expected bandwidth needed for that with VNC? 30Mbit/s?

I did a pouder run on all supported branches for the stack:

I am fine with the logic, if @markj is as well. He understands the comments and the need for the MPASS better than I do.

In D57020#1306569, @adrian wrote:

Want to rebase this to use the net80211_rssi_t once that diff lands?

In D57004#1306496, @kevans wrote:

Mark's suggestion (which I interpreted as https://paste.fbsd.dev/5k6n) seems to work as well; I'm inserting an SDT probe now to confirm my test scenario is actually hitting it right and will stress-test it more.

The problem I have with all of these things is that I don't really know what the failure mode might look like if these attrs aren't adjusted correctly here -- I'm not naive enough to call not-panicking during a lowmem event a solid win since I'm removing the assertion that I hit, but I haven't yet spent enough time understanding where the page(s) are ending up after this (returned to the pool or actually freed) to try and reason about what plausible victims might look like.

In D57004#1306343, @kevans wrote:

#14 0xffffffff852d036f in set_pages_wb (vm_page=<optimized out>, numpages=-2126791527) at /usr/src.kbsd/sys/compat/linuxkpi/common/include/asm/set_memory.h:90

I have a suggestion from markj staged to walk the contiguous pages instead and continue using pmap_page_set_memattr since the m->md.pat_mode assignment is likely critical, and I'll try that tomorrow morning.

Am I correct in what you are describing is that if you had a debug kernel, you would hit the KASSERTs?

Use 0x%04x instead of %#06x to avoid 000000 when 0x0000 would be better as suggested by @jhb.

No necessarily changes but the LinuxKPI dev_is_pci() variant should get more careful checking (especially in drm land; I believe wireless is fine).

I was contemplating the name but I couldn't come up with anything nice that started with pci_ ..

Well this may also result in a lot of unnecessary error logs on systems without IPv6 support (on an interface or at all).

I stopped reading. I do not understand the PROTOCOL file for most of it. If you want an overview of the specification go and read a summary of the specification but that doesn't need to be in our tree.

In D56693#1298919, @aokblast wrote:

In D56693#1298751, @bz wrote:

None of them is hooked up to the build and I have more local changes but yes, go for it. I have vague plans to enable ath10k soon.

Thanks:). I have this because I just buy a QCA9377 and is trying to build the module.

In D56443#1298877, @olce wrote:

In D56443#1298756, @bz wrote:

I would highly advise against this. Don't start splattering lock internals without KPI over the kernel. Seems not a good idea to me.

Sorry if that wasn't clear, but that reaction is completely missing my point, which is that sx(9) locks can readily provide the information of whether there are waiters, and there's no need to graft a machinery just for that purpose on top of it. I stand firm by it.

The snippet was just to illustrate how to implement retrieving the information (hence the e.g.). It goes without saying that sx internals should not be leaked, and that the best place for this code is in fact a sx(9) routine. As I was in a hurry when commenting, I just didn't make it explicit, but I'm pretty sure this point is obvious to everyone here.

The SX_READ_VALUE define should likely be moved to kern_sx.c, its only consumer so far--or at least seen as such.

Even kern_sx.c does not use SX_READ_VALUE() everywhere it should (sc_lock direct accesses), and conversely internals of struct sx, including sc_lock, will stay exposed to the outside to allow for some inline implementations, regardless of whether SX_READ_VALUE() is hidden, and they are currently in use by LinuxKPI and ZFS. So moving SX_READ_VALUE() is not nearly enough.

That said, I agree this kind of leakage is a sorry state of affairs that should be fixed going forward.

If you really want this, add a tiny (inline) wrapper to the sx implementation and then use that as a proper KPI from here in LinuxKPI.

There's not the slightest doubt that leveraging sx(9) information is the best way.

According to style the check is not !! but != 0

Yes. !! is indeed a Linuxism (also used elsewhere).

In D56443#1298661, @olce wrote:

I'd suggest instead to give up on this new implementation as sx locks can directly provide this information, e.g., you can implement rwsem_is_contended() simply as:

static inline int
rwsem_is_contended(struct rw_semaphore *sem)
{
	return (SX_READ_VALUE(&sem->sx) & SX_LOCK_WAITERS);
}

(perhaps adding !! if Linux consumers expect 0 or 1)

None of them is hooked up to the build and I have more local changes but yes, go for it. I have vague plans to enable ath10k soon.

In D56637#1297541, @pouria wrote:

We may want to also update the /etc/rc.d/defaultroute consequently to avoid unnecessary wait time.
But that's another review.

In D56560#1296780, @rmacklem wrote:

In D56560#1296776, @bz wrote:

Sorry but I don't know this code specifically and what these macros are doing or not in the end; unless I am going to read it all to understand I cannot help given there is no high level description of what you are trying to (de-)virtualize here.

I had initially asked if it was possible to run NFS exports from within jails. Rick made that happen in 2003(?). And that's kind-of as much as I know. I believe I had not reviewed any of that code back then; you may want to talk to people who did -- I think @markj , @jamie and @mjg did in the end when it came to jails and mounted and some other bits got refined. But that's just from vague memory.

Well, my vague memory is that you (bz@) requested that the vnet macros
be hidden behind other macros because you thought you might want
to do something different than that happen.
All the macros like KRPC_CURVNET_SET() do is CURVNET_SET(), etc.

Oh, and it happens a few years ago (closer to 2023 than 2003).

If you (bz@) don't want/need the macros, they can go away.

There also was NFSD_VNET_NAME et al intially btw (a quick grep says some still exists from ed03776ca7f43de8275da80cfa89a9ecc4732f82 ).

Sorry but I don't know this code specifically and what these macros are doing or not in the end; unless I am going to read it all to understand I cannot help given there is no high level description of what you are trying to (de-)virtualize here.

You probably want to abandon this review then?