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