Just use the existing USB transfers:
UCHCOM_BULK_WR -> UCHCOM_BULK_DT_WR
UCHCOM_BULK_RD -> UCHCOM_BULK_DT_RD

In D39723#904466, @zlei wrote:

I have to admit that I get bitten by the function name. I almost always treat qsort() as quicksort but it is actually a generic interface for sorting.
So it should be treated / named as sort() .

A second thought about this, I think for STD C or POSIX, use an implementation as standard is not scalable, as there're so many sorting algorithms.

From qsort(3):

The qsort() function is a modified partition-exchange sort, or quicksort.

Regardless of the naming, maybe it is right direction to place emphasis about the standard / posix requirement of qsort(). What do you all think ?

In D39723#904040, @jrtc27 wrote:

No. This is a widely-used ISO C function. If it has poor performance, fix that.

I have a patch to move Giant out of adaptive locking. I wonder if it can help?

Looks good!

Adding a nice SVG picture showing how the algorithm is sorting data. BSORT_TABLE_MAX=2 and n=16 elements to sort.

Thank you for your reviews!

@emaste : "<= 0" is for the future, in case the type changes to be signed.

Add a "case 0:" for the object size.

Maybe add a word about it in UPDATING ?

Doing some test builds, and then I'll push this.

Final version (some minor changes and nits)

• limit on-stack buffer for copying objects to 256 bytes
• add check for zero object size to bsort_s().

The qsort code actually use the object size for advancing for loops, so clearly we should catch this regardless of ISO definitions.

Can I have a quick go on this one?

In D35754#857657, @pauamma_gundo.com wrote:

In D35754#857510, @hselasky wrote:

Regarding:

Functionality: Control-B still seems to have no effect when displaying ttyv0 and vtspeakd was started on ttyv1. With that same vtspeakd VTY, control-B works on ttyv2. Control-B also has no effect when used on ttyv0 and vtspeakd was started on ttyv0.

Can you explain to me step by step how to reproduce. I don't fully get this. Are you using the serial console. I.E. my patches only support characters going to a real VT console, and that VT console must be selected by using typically ALT+F1 ... F2 ... F3 and so on.

No, using the built-in VTY (but booting with EFI and using a USB keyboard, if that makes a difference; that laptop's builtin keyboard is broken and keeps spewing garbage characters, so I disabled it in devices.hint).

Steps to reproduce:
1- Boot and wait for the ttyv0 login prompt.
2- Using alt-F2, switch to ttyv1.
3- Login as root.
4- At the # prompt, enter "clear; vtspeakd".
5- Switch back to ttyv0 using alt-F1.
6- As vtspeakd starts reading each line, press control-B once per line, a second or two in.
7- When vtspeakd is done reading, switch to ttyv2 using alt-F3.
8- Login as root.
9- As vtspeakd starts reading each line, press control-B once per line, a second or two in.
Expected: at steps 6 and 9, reading each line is aborted on successive control-B presses and vtspeakd skips to the next line.
Observed: at step 6, each line is read out in full (incorrect); at step 9, vtspeak aborts and skips to the next line on every control-B press (correct).

I will also update the symbol maps file under the 1.7 section.

I'll make those changes before commit.

Can people have a look here? I'd like to get this into FreeBSD-14.

Looks good!

About the location, maybe linuxkpi/tools would be better? Like tools related to the Linuxkpi. There probably will be more of them as time goes by!

When changing structure layouts you need to bump the FreeBSD version.

Change looks good, but the commit message should be more descriptive:

@kib : I will sync these changes internally ...

Maybe the right approach is moving the needs_epoch check to ipoib_cm_handle_rx_wc() and ipoib_ib_handle_rx_wc().

@zlei : It's ok if this is for mlx5ib currently. You would need to get @np into the loop to test it for chelsio.

The mlx5 core IRQ handler grabs the NET EPOCH for all CQEs, so this should be pretty much fine!

Just write:
Suggested by: hselasky@

@emaste : Patch is now split. It won't apply to 14-current, but should be easier to review.

@emaste: Yes, I can split the diff into two parts like you suggest.