From 8cee055ec4fac00e59f19620ab06e2b30dccee3c Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 11 Jul 2012 22:39:59 +0200 Subject: IRC. --- hurd/translator/ext2fs.mdwn | 44 +++++++++++++++++++++ hurd/translator/procfs/jkoenig/discussion.mdwn | 53 +++++++++++++++++++++++++- 2 files changed, 95 insertions(+), 2 deletions(-) (limited to 'hurd/translator') diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index ad79c7b9..8e15d1c7 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -18,6 +18,8 @@ License|/fdl]]."]]"""]] * [[Page_cache]] + * [[metadata_caching]] + ## Large Stores @@ -43,6 +45,48 @@ Smaller block sizes are commonly automatically selected by `mke2fs` when using small backend stores, like floppy devices. +#### IRC, freenode, #hurd, 2012-06-30 + + at least having the same api in the debian package and the git + source would be great (in reference to the large store patch ofc) + braunr: the api part could be merged perhaps + it's very small apparently + braunr: the large store patch is a sad story. when it was first + submitted, one of the maintainers raised some concerns. the other didn't + share these (don't remember who is who), but the concerned one never + followed up with details. so it has been in limbo ever since. tschwinge + once promised to take it up, but didn't get around to it so far. plus, + the original author himself mentioned once that he didn't consider it + finished... + antrik: it's clearly not finished + there are XXXs here and there + it's called an RC1 and RC2 is mentioned in the release notes + youpi: well, that doesn't stop most other projects from commiting + stuff... including most emphatically the original Hurd code :-) + what do you refer to my "that" ? :) + "XXX" + right + at the time it made sense to delay applying + but I guess by nowadays standard we should just as well commit it + it works enough for Debian, already + there is just one bug I nkow about + the apt database file keeps haveing the wrong size, fixed by e2fsck + youpi: remember that patch should be fixed in the offset + declaration in diskfs.h + I don't remember about that + did we fix it in the debian package? + nope + you had issues when fixing it, didn't you? + (I don't remember where I can find the details about this) + i changed it, recompiled hurd and installed it, started a perl + rebuild and when running one of the two lfs tests it hard locked the vm + after ext2fs was taking 100% cpu for a bit + i don't exclude i could have done something stupid on my side + though + or there could just be actual issues, uncovered here + which can be quite probable + + # Documentation * diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index e7fdf46e..182b438b 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -68,7 +68,7 @@ IRC, #hurd, around October 2010 owner, but always with root group -# `/proc/$pid/stat` being 400 and not 444, and some more +# `/proc/[PID]/stat` being 400 and not 444, and some more IRC, freenode, #hurd, 2011-03-27 @@ -187,7 +187,7 @@ IRC, freenode, #hurd, 2011-07-22 server anyway, I think. -# `/proc/mounts`, `/proc/$pid/mounts` +# `/proc/mounts`, `/proc/[PID]/mounts` IRC, freenode, #hurd, 2011-07-25 @@ -277,3 +277,52 @@ Needed by glibc's `pldd` tool (commit it's very weird for example for fd connected to files that have been unlinked. it looks like a broken symlink, but when dereferencing (e.g. with cp), you get the actual file contents... + + +# `/proc/[PID]/maps` + +## IRC, OFTC, #debian-hurd, 2012-06-20 + + bdefreese: the two elfutils tests fail because there are no + /proc/$pid/maps files + that code is quite relying on linux features, like locating the + linux kernel executables and their modules, etc + (see eg libdwfl/linux-kernel-modules.c) + refactor elfutils to have the linux parts executed only on linux + :D + Oh yeah, the maintainer already seems really thrilled about + Hurd.. Did you see + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041 ? + kurt is generally helpful with us (= hurd) + most probably there he is complaining that we let elfutils build + with nocheck (ie skipping the test suite run) instead of investigate and + report why the test suite failed + + +# IRC, freenode, #hurd, 2011-06-19 + + jkoenig: procfs question: in process.c, process_lookup_pid, why + is the entries[2].hook line repeated twice? + pinotree, let me check + pinotree, it's probably just a mistake, there's no way the second + one has any effect + jkoenig: i see, it looked like you c&p'd that code accidentally + pinotree, it's probably what happened, yes. + + +# IRC, freenode, #hurd, 2012-06-30 + + btw, what do you think about making jkoening's procfs master the + real master? + probably a good idea + it does work quite well, except a few pidof hangs + surely better than the old one :) + yes :) + + +# `/proc/[PID]/cwd` + +## IRC, freenode, #hurd, 2012-06-30 + + * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying + on "internal" (but exported) glibc functions -- cgit v1.2.3