- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 19 2023
Jun 17 2023
MFC after: 1 week
Jun 16 2023
Looks good. Did you remember the appropriate entries in sys/conf/files and sys/modules/usb/xxx ?
Jun 12 2023
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 ...
Jun 9 2023
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?
Can you show me excatly where this function is needed?
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.
Jun 7 2023
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).
Jun 5 2023
Jun 4 2023
Jun 1 2023
There should be a newline before devm_ioremap( . Else looks good.
Why not just call del_timer_sync() instead of copying the code?
In D40120#918932, @bz wrote:Hans, any suggestions on how to proceed?
May 30 2023
Change looks good, and the questions raised have been answered.
May 27 2023
May 23 2023
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 😉
May 22 2023
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.
May 21 2023
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?
In D39916#914843, @arichardson wrote:Sure, I'd be more than happy to test and review patches :)
May 20 2023
In D39916#914571, @arichardson wrote:In D39916#914569, @hselasky wrote:Sorting 1125 sysinit items 117378 instructions with qsort() 5509157 instructions with bubbleAnd 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...
May 19 2023
Sorting 1125 sysinit items 117378 instructions with qsort() 5509157 instructions with bubble
May 18 2023
@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
May 17 2023
Please don't implement integers like floating point!
May 13 2023
May 11 2023
Adding Drew, due to changing set affinity for IRQ vectors. Any comments?
Can you rebase this patch?
May 10 2023
@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.
sys/amd64/compile/GENERIC/machine/param.h:#define INKERNEL(va) (((va) >= DMAP_MIN_ADDRESS && (va) < DMAP_MAX_ADDRESS) \ sys/amd64/compile/GENERIC/machine/vmparam.h:#define DMAP_MAX_ADDRESS KV4ADDR(DMPML4I + NDMPML4E, 0, 0, 0) sys/amd64/compile/GENERIC/assym.inc:#define DMAP_MAX_ADDRESS 0xfffffc0000000000 sys/amd64/include/param.h:#define INKERNEL(va) (((va) >= DMAP_MIN_ADDRESS && (va) < DMAP_MAX_ADDRESS) \ sys/amd64/include/vmparam.h:#define DMAP_MAX_ADDRESS KV4ADDR(DMPML4I + NDMPML4E, 0, 0, 0) sys/arm64/include/vmparam.h:#define DMAP_MAX_ADDRESS (0xffffff0000000000UL) sys/arm64/include/vmparam.h:#define DMAP_MAX_PHYSADDR (dmap_phys_max) sys/cddl/contrib/opensolaris/uts/common/sys/idmap.h:#define IDMAP_MAX_DOOR_RPC (256 * 1024) sys/contrib/openzfs/include/os/freebsd/spl/sys/idmap.h:#define IDMAP_MAX_DOOR_RPC (256 * 1024) sys/dev/hid/hidmap.h:#define HIDMAP_MAX_MAPS 4 sys/powerpc/include/vmparam.h:#define DMAP_MAX_ADDRESS 0xc007ffffffffffffUL sys/powerpc/include/vmparam.h:#define DMAP_MAX_ADDRESS 0xbfffffffUL sys/riscv/include/vmparam.h:#define DMAP_MAX_ADDRESS (0xfffffff000000000UL) sys/riscv/include/vmparam.h:#define DMAP_MAX_PHYSADDR (dmap_phys_max)
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: