MFC after: 1 week

Looks good. Did you remember the appropriate entries in sys/conf/files and sys/modules/usb/xxx ?

I see now how Linux defines this macro / function. Sorry, my bad. I was just looking at the change itself, and wondering what happens to negative time differences ...

Maybe add:
MPASS(ceil >= floor);

Looks good!

In D40120#921419, @bz wrote:

In D40120#918998, @hselasky wrote:

In D40120#918932, @bz wrote:

Hans, any suggestions on how to proceed?

@bz

Can you show me excatly where this function is needed?

https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git/tree/drivers/net/wireless/intel/iwlwifi/mvm/ptp.c#n74

In case this is going to be too complicated I'll add a "skeleton" in given we are unlikely going to use this much -- if at all -- anywhere.

Are there any updates here?

@arichardson : Use SORT_BY_INIT_PRIORITY()

Change %03X to %07X to print subsystem values, now that I reverted the renumbering of the subsystem and order values.

In D40463#921144, @hselasky wrote:

In D40463#921097, @jrtc27 wrote:

Oh also linker_file_lookup_set with a section name like that won't work on anything other than amd64, since link_elf relies on the start/stop symbols, not the section name.

Please tell me if I'm mistaken, but isn't that all controlled by the ldscripts we have?

I'm just about to test D40467 on aarch64. It seems to do the trick, at least as seen by objdump.

Fix a bug in sysinit_insert_sorted().

Fix wording. SYSUNINITs are only called on module unload.

@emaste : You added something similar a while back for amd64. Adding you for review.

In D40463#921097, @jrtc27 wrote:

Oh also linker_file_lookup_set with a section name like that won't work on anything other than amd64, since link_elf relies on the start/stop symbols, not the section name.

Change from .ctors to .init_array and .dtors to .fini_array . This is what the default FreeBSD kernel toolchain currently outputs. Also noted by @jrtc27 .

Finally, I'm highly unconvinced that it makes sense to dynamically register each sysinit individually.

In D40463#921068, @jrtc27 wrote:

MFC after: 1 week

There is no way this can be MFC'ed, it is a big pile of KBI break.

What do you think about this change?

Keep "struct __hack" to force semicolon after SYSINIT() and SYSUNINIT().

This revision is abandoned in favor of D40463 .

FYI: Here is my second take on the issue D40463 . Please have a look if you are interested.

Removed some VNET related changes (not related to this change).

There should be a newline before devm_ioremap( . Else looks good.

Why not just call del_timer_sync() instead of copying the code?

Tab after #define .

In D40120#918932, @bz wrote:

Hans, any suggestions on how to proceed?

Change looks good, and the questions raised have been answered.

CFLAGS is also a keyword. Which directory to look at first. Local or parent.

In D40192#915712, @kib wrote:

In D40192#915111, @hselasky wrote:

In D40192#915080, @kib wrote:

Perhaps you could add vdso_offset.h as a file to files.amd64, and there specify a dependency on .o together with empty build rule.

That's possible, but you still need the dependency keyword for the C-files in question. Either you depend on the "elf-vdso.so.o" or you depend on "vdso_offset.h". I don't know which is better.

Yes, vdso_offset.h would depend on the vdso. My point is that .c sources depend on vdso_offset.h, which would be a more correct dep edge, than vdso->.c (if possible to express).

The patch as is should work fine.

Though it is obviously a little confusing why we have both beforedepend and beforebuild dependencies.
You *could* put offset.inc and assym.inc into a list (naming the list is the hard bit 😉

I will check this a bit more before pushing and see if more developers have anything to say.

In D40192#915080, @kib wrote:

Does config(8) allow to specify that a build step produces more than one file? This is the problem causing the use of elf-vdso.so.o as a build indicator.

In D40193#915024, @imp wrote:

I'll have to study this in detail... it's a bigger change than I thought it would be...

In D40192#915023, @imp wrote:

It would be better if we depended on the header files directly... but if these really are files otherwise not mentioned in the build system and are purely a side effect of the o creation then this is goid.

@imp : Get me right: Maybe I need to += them to a new variable?

Looks good!

In D39916#914843, @arichardson wrote:

Sure, I'd be more than happy to test and review patches :)

In D39916#914571, @arichardson wrote:

In D39916#914569, @hselasky wrote:

Sorting 1125 sysinit items
117378 instructions with qsort()
5509157 instructions with bubble

And if the list is already sorted and you use insertion sort there instead of bubble sort, what is the time then? Can you get that into the list too?

I guess it will be something like 500x instead of your 50x.

--HPS

Yes that would obviously be faster but I don't have time to work on that. If you are planning to work on this and it's going to be ready for review in the near future I'd be happy to drop this patch.

However, using a pre-existing sorting function to obtain a noticeable speedup seems like a valid approach to me. Just because it could be done in a more optimal way at some hypothetical point in the future shouldn't mean we can't make incremental improvements on the way to an ideal solution. Otherwise things would never improve...

@bz : Another thing coming to mind, is to apply the greatest common divisor between x,y,z. This computation is pretty cheap. When you have exact fractions, it doesn't look so good seeing rounding errors.

In D40120#913732, @bz wrote:

In D40120#913699, @hselasky wrote:

Please don't implement integers like floating point!

I think you need to do something exactly like below. I just quickly sketched this up. Can you verify it?

No

Please don't implement integers like floating point!

Adding Drew, due to changing set affinity for IRQ vectors. Any comments?

Can you rebase this patch?

@markj: How did you come to that conclusion? On amd64 DMAP_MAX_ADDRESS is KV4ADDR(DMPML4I + NDMPML4E, 0, 0, 0) = 0xfffff80000000000 + NDMPML4E*0x8000000000. On arm64 it is 0xffffff0000000000UL.

Could you figure out if VM_MAX_KERNEL_ADDRESS is inclusive or exclusive.

I can test this today, and report back. I think your change is OK. There may be different ways to enumerate interrupts, and passing a pointer may make more sense, for example software interrupts not connected to any specific hardware - right?

Two comments:

Ping.