From 12c341b917921eb631026ec44a284c4d884e5de6 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 6 Mar 2013 21:52:20 +0100 Subject: IRC. --- hurd/translator/ext2fs.mdwn | 38 +++++++++++++- hurd/translator/pfinet/ipv6.mdwn | 68 +++++++++++++++++++++++++- hurd/translator/procfs/jkoenig/discussion.mdwn | 23 +++++++++ 3 files changed, 126 insertions(+), 3 deletions(-) (limited to 'hurd/translator') diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index 13a1d9ec..65361ff4 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 Free Software +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -89,6 +89,42 @@ small backend stores, like floppy devices. which can be quite probable +#### [[libpager]] API change + +##### IRC, freenode, #hurd, 2013-03-04 + + youpi: i don't remember exactly your answer when i asked about + considering the ext2 large store patch for merging + there's just an API change that it introduces + but otherwise I'd say we should just do it + ok + I've just checked the API change again + it's simply adding a notify_on_evict parameter + and a pager_notify_evict callback + yes + I'd say we mostly need to polish this + ah, there is the same parameter on diskfs_start_disk_pager + + +#### `EXT2FS_DEBUG` + +##### IRC, freenode, #hurd, 2013-03-04 + + youpi: do we want EXT2FS_DEBUG defined upstream ? + I don't really have an opinion on this + stuffing it in the large store patch is not good of course + I wonder whether we want it by default. + it is currently defined by the patch + (in the debian package i mean) + I've just seen that yes + i won't include it upstream, and if we decide to keep this + behaviour, we can add a patch just for that + or a define + err + a configure option + ok + + ## Sync Interval [[!tag open_issue_hurd]] diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn index edd31017..03a5670a 100644 --- a/hurd/translator/pfinet/ipv6.mdwn +++ b/hurd/translator/pfinet/ipv6.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2012 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2012, 2013 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -94,3 +94,67 @@ Amongst other things, support for [[IOCTL]]s is missing. There is one already: http://www.gnu.org/software/hurd/community/gsoc/project_ideas/tcp_ip_stack.html personally, i'd advocate resuing code from netbsd + + +### IRC, freenode, #hurd, 2013-02-23 + + we're beginning to seriously lack ipv6 though + what is the actual problem? + (again) + lack? + we do have ipv6 working + i couldn't have it work with public addresses + uh? + I believe it worked for me + yes i told you a few months back + braunr reported recently that v6 did not work as expected? + I don't remember about that (and my inbox neither) + it was only on irc + routing would be nice to have too + the stack can do it but we lack the interface + anyway, there would be benefits on working on it, but what we have + now is fine and again, there are priorities + braunr: it seems ndp doesn't work indeed, I wonder why, it was + working for me + that's what i found too + there have been other additions to the ipv6 spec over time, i + don't know what else we might be lacking + ndp is elder + yes ndp isn't lacking + and pfinet *does* actually do ndp :) + that's a different issue + my debugging session ended in the routing code + and i didn't investigate further + braunr: it seems the BPF filter on /dev/eth0 doesn't include IPv6 + frames + that'd explain that it worked before but not any more + oh + good + i'd love to assign global addresses to our VMs :) + ok, it goes through, there is just a remaining multicast join issue + yep, ethernet_set_multi is empty :) + ok, enabling ALLMULTI was enough to fix it + you can ping6 2001:910:1059:2:5054:00ff:fe12:3456 :) + + +## IRC, freenode, #hurd, 2013-01-13 + + gnu_srs, gnu_srs1: fyi, I'm having a look at cherry-picking the + v6only option from linux + + +### IRC, freenode, #hurd, 2013-02-23 + + youpi: From when is the Linux + 524354b4d086a4f013343d727eaccb7b4c39eb25 commit (IPV6_V6ONLY)? + which repo? + I don't have such commit here + + http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=2b2d7fdc42475019e5ce3eabc9c9673e3c13d89f + From which release, 2.4.x, 2.6.x? + it's very old + 2002 + it's not in the current linux git tree, but in the "history" tree + I don't remember its url + git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git + might be even older diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index e71ea02b..4cd4e5ca 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -337,3 +337,26 @@ filing these: https://enc.com.au/2012/09/careful-with-pids/' ? nope + + +# CPU Usage + +## IRC, freenode, #hurd, 2013-01-30 + + Hi, htop seems to report CPU usage correct, but not top, is that + a known issue? + does your /proc have the -c flag? + /hurd/procfs -c + I don't remember which way it works, but iirc depending on whether + -c is there or not, it will work or not + problem being that nothing says linux' clock is 100Hz, but a lot of + programs assume it + seems like htop gets it right though + possibly just by luc + k + + +### IRC, freenode, #hurd, 2013-01-31 + + both htop and top seem to have problems report the cpu time + so i expect the problem to be in procfs -- cgit v1.2.3