[00:08] hy everybody ! [00:09] im' intrested in implementing a file-system changes notification tool [00:12] i am wondering if is possible to get journaling event from my module [00:13] are there particular kernel structures involved with the journaling system ? [00:17] luca_: fs/jfs/ might give some useful info [00:21] thank you BenC [00:31] are there anything under /proc or /sys that will let me know if some change in the filesystem occurs? [00:32] No [00:32] sorry I got lost in fs/jfs [00:32] If you're purely interested at the filesystem level, inotify will give you notifications [00:33] But I suspect it won't work too well if you try to look at the whole filesystem [00:37] that would be pretty crazy [00:38] and god help you if that notification framework ended up causing writes to the filesystem [00:40] If you're interested in things at the block level rather than the filesystem level, check block/blk-core.c and search for block_dump. fs-writeback.c has similar code that gives notifications if a page is dirtied. [00:40] Is it possible (kernel or user space) to read directly that table the journaling fill with envents occurred to file? [00:41] read it , and understand what happened? [00:42] Well, sure [00:42] But ext3 only journals metadata by defau;t [00:42] File data changes won't go anywhere near the journal [00:44] mmm. right [00:46] do you know more or less how does this happens: [00:47] i open a directory with a gui as nautilus [00:47] i create a file from a shell into that directory [00:48] and magically nautilus know that a file was created [00:48] and show the file icon almost immedately [00:48] It uses inotify [00:54] thanks mjg59 === asac_ is now known as asac === CjNr13 is now known as CjNr14 [13:09] does someone know if there is a way to export a memory area from the host to the guest (Video RAM/ROM for exemple) ? [13:09] Do I need to write a driver like the pci frontend/backend one? [13:10] sorry, wrong chan lol [14:21] Ng: talk to me. any e1000 joy? [14:27] rtg__: not as yet, I don't see silbs around atm, but I'll keep my eye open. [14:27] Ng: k [14:28] I might even keep both eyes open ;) [14:51] hehe [20:52] oh depressing. Recompiling the 2.6.25 kernel is taking 2 hrs 20 mins on my PS3 (weeps). [20:53] and that's with ccache [20:56] * munckfish eyes G5s on Ebay, wonders what wife would think ... [22:23] https://bugs.launchpad.net/ubuntu/+bug/235889 [22:23] somebody can take a look ? :) [22:26] dupondje: Leann asked you to do a bisection test [22:26] if you do that test, you'll be able to find the exact changeset that fixes the problem, so that they can think about backporting it to hardy [22:26] I must say I don't really understand it howto :x [22:26] google git-bisect [22:27] I must compile kernel 100000 times then until I get the right patch ? ... [22:27] well [22:27] BISECTION TEST [22:27] more like binary search [22:27] bisection lets you find the fix in ~7 builds [22:27] so something like log base 2 of the number of commits [22:28] er, wait... i think i pulled that number 7 out of my arse .... [22:28] anyway, bisection helps to find the fix in the least # of builds possible [22:28] any id what part of kernel I should look @ for a possible patch ? [22:29] thats what bisect helps with [22:29] you'll find the changeset that introduced the bug with bisect, and that'll narrow the places down considerably [22:30] im goin home .. .tty all later [22:31] dupondje: i agree, i wish building the ubuntu kernel was simpler [22:31] well pwnguin, It crashes with ubuntu kernels ... but not with the latest kernel.org kernel ... [22:31] dunno about the older kernel.org versions [22:32] so maby its just a bug introduced into the ubuntu patches [22:32] here's an idea [22:33] oh, it still doesnt build [22:33] indeed :) [22:33] ogasawara also had that id ;) [22:33] if ubuntu's kernel built, there shuold be a fairly small diff [22:36] and my damn slow CPU :'( [22:37] AMD Athlon64 3800+ :( [22:37] plenty fast [22:38] not fast enough imo :D [22:45] <|dupondje|> mmm :x === |dupondje| is now known as dupondje [23:11] rtg__: BTW, I have a working hppa kernel patch for you for inclusion in -20- after 8.04.1 is out the door. [23:18] rtg__: chinstrap:~adconrad/hppa.diff [23:19] rtg__: Obviously, the change to 2-binary-arch.mk is for our own personal use, but the config changes work smashingly, and that's the precise source we're using in the DC right now.