- User Since
- Aug 2 2014, 12:45 PM (175 w, 4 d)
Mon, Dec 11
Sat, Dec 9
Sat, Dec 2
Fri, Dec 1
Thu, Nov 30
Tue, Nov 28
Mon, Nov 27
Sat, Nov 25
Thanks. Not sure why I went with the additional variable, tbh. Also, there are a few other calls to kdb_enter(), so I think adding a separate kdb_enter_silent() is nicer, especially regarding that it's a pretty small function and doesn't really need a wrapper.
Use kdb_reenter_silent() instead of an additional variable.
Thu, Nov 23
Wed, Nov 22
Oh wow. It's hard to believe I managed to overlook _that_. Approved :-)
Sun, Nov 19
No idea if it works. Few months ago I've tried to build the kernel with kgmon support, and it didn't build. Either way, the correct way to phasing it out is to declare it obsoleted in the man page, and I think that's something that can be done without checking if it actually works.
Sat, Nov 18
I've tested it on i386, and yes, 32k is not enough there as well.
Fri, Nov 17
Tue, Nov 14
Nov 8 2017
Nov 7 2017
Nov 4 2017
Why this way, instead of adding handling all that inside disk(9) instead? That would "just work" for all the periph drivers, without changing them.
Nov 3 2017
Nov 2 2017
Oct 30 2017
No idea if it eats the same amount on 32 bit archs. Why is this important? Even if we wasted this 128kB of virtual address space, it doesn't hurt in any way, right?
It is still being allocated dynamically, it's just the current preallocation size is not enough even for true(1). See the munmap/mmap pair below:
I've got mixed feelings. On one hand it's nice to get rid of those sigprocmasks, and the patch itself looks fine. On the other hand, this adds the fetch to syscallenter(2), which is already quite bloated...
Oct 29 2017
Oct 26 2017
There is nothing there that seems related to libc (setsigmask(2)), why?
Oct 24 2017
Rebase after commiting the style fixes.
Oct 23 2017
I only see one libc.so.7 - from /lib. There's an attempt to load it from /usr/local/lib, but that fails with ENOENT.
I've just did a totally unscientific benchmark (for n in jot 10`; do /usr/bin/time sh -c 'for f in jot 10000; do /usr/bin/true; done'; done 2>&1`), curated the results with sed 's/,/./g', and... huh.
The allocated memory probably indeed seems to be allocated with mmap(2), but that's done anyway, ie we're not adding another mmap call to the binary startup. The read(2) might indeed be a bit faster due to not messing with memory mappings, but as you say, I don't expect this to be measurable. The additional copy won't hurt either - we're touching all that data just afterwards.
One fewer syscall during binary startup. Besides, reading in a small text file using mmap seems just weird; we use the usual read(2) for ld-elf.so.hints.