935 reputation
1921
bio website
location
age
visits member for 3 years, 1 month
seen yesterday

Feb
13
awarded  Civic Duty
Feb
10
comment Repeating a text-output terminal command, in a scrollable ncurses-like interface?
PSS: Multitail linked from one of the pages on this answer also looks neat, but it needs to be built from source (for me, libncursesw5-dev was also needed); but unfortunately it can scroll "only the last 100 lines", and refresh of the command kills the scroll window (as of v6.0).
Feb
10
comment Repeating a text-output terminal command, in a scrollable ncurses-like interface?
PS: pwatch seems to be able to do what I wanted; except it needs handlers for proper termination of ncurses; it also (currently) terminates prematurely if one goes above a certain line in the ps axf output (though scrolling works). But otherwise, that was what I was looking for. Cheers!
Feb
10
comment Repeating a text-output terminal command, in a scrollable ncurses-like interface?
Many thanks for that answer @slm - it explains well that what is a "state of the art" for this problem (which I wasn't aware of) - so I accepted it for now. I got both atop and htop - and it seems, none of them report kthreadd and its "dependencies"; and that is a part of what I need this for (and which is why I wanted a "generic" application which gives one a curses scrolling window). Thanks again - cheers!
Feb
10
accepted Repeating a text-output terminal command, in a scrollable ncurses-like interface?
Feb
9
comment Repeating a text-output terminal command, in a scrollable ncurses-like interface?
Thanks, @MarkPlotnick and @Marki - unfortunately, there seems to be no scrolling behavior with watch, although, at least it keeps the start of output on top of terminal...
Feb
9
asked Repeating a text-output terminal command, in a scrollable ncurses-like interface?
Jan
30
comment Linux Kernel logical address space organisation
Thanks for the example! Just my note on the Linux part - I just tried this example as where.c, on Ubuntu 11.04 using gcc where.c -o where; reports "main at 0x80483c4". Tried readelf -S where, and it reports, say "[13] .text PROGBITS 08048310 ... " which looks about right? Although I also get "ac at 0xbfb035a0" and "local at 0xbfb0358c", and that address range (0xbf...) seems not to reported by readelf -S.
Jan
29
answered Filesystem content inspection GUI (like gconf-/dconf-editor)?
Jan
29
asked Filesystem content inspection GUI (like gconf-/dconf-editor)?
Jan
25
awarded  Nice Question
Jan
22
comment Resolving executable user stack trace addresses in ftrace
Thanks for the edits, @slm - I definitely do not have -dbg packages loaded; which is why I find this strange - if they were the problem, then I shouldn't get any resolved traces from Xorg or other processes? And this trace only gives an offset into an executable file, so the debug info (as in, a link to source code file and line number) isn't even needed... Yet, I get stacktraces resolved everywhere, except my program; and the program isn't even linked to anything other than (implicitly) libc?
Jan
22
comment Resolving executable user stack trace addresses in ftrace
Many thanks for the answer, @slm - could this also refer to the libc library? As I don't see what other library would the program above refer to... Cheers!
Jan
22
asked Resolving executable user stack trace addresses in ftrace
Jan
22
awarded  Popular Question
Jan
22
comment Observing a hard-disk write in kernel space (with drivers/modules)
A small note: some of the explanation in this answer (e.g. dirty pages flushing) is observable, if in the sudo bash... script in the OP: ftrace memory is increased (echo 8192 > $KDBGPATH/buffer_size_kb); and sync ; is added after the ./wtest ; call. Then I can see flush-8, kworker (under kthreadd in ps axf), and sync itself, as processes in ftrace calling functions like e.g. ata_bmdma_setup() (which is part of libata, which ata_piix builds on), or get_nr_dirty_inodes().
Jan
22
revised Observing a hard-disk write in kernel space (with drivers/modules)
fixed typo "ati_piix" to "ata_piix"
Jan
22
comment Observing a hard-disk write in kernel space (with drivers/modules)
Many thanks for that, @FaheemMitha - while I've heard of (and used) the config file before, for some reason I've completely forgotten about it in this example; nicely spotted! :) On my system, grep ATA_PIIX /boot/config-2.6.38-16-generic says CONFIG_ATA_PIIX=y, which should probably mean on this kernel, ata_piix is build "in-kernel", and not as a module. Cheers!
Jan
22
comment Observing a hard-disk write in kernel space (with drivers/modules)
Many thanks for the comment, @FaheemMitha - I also had similar doubts, but I wasn't really sure how to cut up the questions - and wasn't aware until now I can use chat for it (and I wasn't keen on using meta for asking about that kind of advice); will definitely give chat a try next time. Thankfully, this time it worked out with a very acceptable answer ... Cheers!
Jan
22
comment Observing a hard-disk write in kernel space (with drivers/modules)
Hi @derobert - many, many thanks for your answer; it contains the exact kind of information I was missing! I originally started with looking for a simple illustration of user vs. kernel space, but I realized soon a hard-disk write isn't exactly something I understand fully, and isn't that trivial - thanks for confirming it is actually a book-length effort! Cheers!