summaryrefslogtreecommitdiff
path: root/hurd/translator
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2012-07-11 22:39:59 +0200
committerThomas Schwinge <tschwinge@gnu.org>2012-07-11 22:39:59 +0200
commit8cee055ec4fac00e59f19620ab06e2b30dccee3c (patch)
tree6cd7ca1b8ce7eba1820fdbd31ee5755ed33dabe2 /hurd/translator
parentb75e038615d51cb62c200e336e59202519db8cae (diff)
IRC.
Diffstat (limited to 'hurd/translator')
-rw-r--r--hurd/translator/ext2fs.mdwn44
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn53
2 files changed, 95 insertions, 2 deletions
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
+
+ <braunr> 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)
+ <youpi> braunr: the api part could be merged perhaps
+ <youpi> it's very small apparently
+ <antrik> 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...
+ <youpi> antrik: it's clearly not finished
+ <youpi> there are XXXs here and there
+ <braunr> it's called an RC1 and RC2 is mentioned in the release notes
+ <antrik> youpi: well, that doesn't stop most other projects from commiting
+ stuff... including most emphatically the original Hurd code :-)
+ <youpi> what do you refer to my "that" ? :)
+ <braunr> "XXX"
+ <youpi> right
+ <youpi> at the time it made sense to delay applying
+ <youpi> but I guess by nowadays standard we should just as well commit it
+ <youpi> it works enough for Debian, already
+ <youpi> there is just one bug I nkow about
+ <youpi> the apt database file keeps haveing the wrong size, fixed by e2fsck
+ <pinotree> youpi: remember that patch should be fixed in the offset
+ declaration in diskfs.h
+ <youpi> I don't remember about that
+ <youpi> did we fix it in the debian package?
+ <pinotree> nope
+ <youpi> you had issues when fixing it, didn't you?
+ <youpi> (I don't remember where I can find the details about this)
+ <pinotree> 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
+ <pinotree> i don't exclude i could have done something stupid on my side
+ though
+ <youpi> or there could just be actual issues, uncovered here
+ <youpi> which can be quite probable
+
+
# Documentation
* <http://e2fsprogs.sourceforge.net/ext2.html>
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
<antrik> 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
+
+ <pinotree> bdefreese: the two elfutils tests fail because there are no
+ /proc/$pid/maps files
+ <pinotree> that code is quite relying on linux features, like locating the
+ linux kernel executables and their modules, etc
+ <pinotree> (see eg libdwfl/linux-kernel-modules.c)
+ <pinotree> refactor elfutils to have the linux parts executed only on linux
+ :D
+ <bdefreese> Oh yeah, the maintainer already seems really thrilled about
+ Hurd.. Did you see
+ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041 ?
+ <pinotree> kurt is generally helpful with us (= hurd)
+ <pinotree> 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
+
+ <pinotree> jkoenig: procfs question: in process.c, process_lookup_pid, why
+ is the entries[2].hook line repeated twice?
+ <jkoenig> pinotree, let me check
+ <jkoenig> pinotree, it's probably just a mistake, there's no way the second
+ one has any effect
+ <pinotree> jkoenig: i see, it looked like you c&p'd that code accidentally
+ <jkoenig> pinotree, it's probably what happened, yes.
+
+
+# IRC, freenode, #hurd, 2012-06-30
+
+ <pinotree> btw, what do you think about making jkoening's procfs master the
+ real master?
+ <youpi> probably a good idea
+ <youpi> it does work quite well, except a few pidof hangs
+ <pinotree> surely better than the old one :)
+ <youpi> 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