diff options
Diffstat (limited to 'hurd')
| -rw-r--r-- | hurd/debugging/rpctrace.mdwn | 80 | ||||
| -rw-r--r-- | hurd/translator/ext2fs.mdwn | 44 | ||||
| -rw-r--r-- | hurd/translator/procfs/jkoenig/discussion.mdwn | 53 |
3 files changed, 174 insertions, 3 deletions
diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index fd24f081..df6290f7 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011 Free Software +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -89,6 +89,84 @@ See `rpctrace --help` about how to use it. <pinotree> braunr: the output of rpctrace --help should tell the default dir for msgids +* IRC, freenode, #hurd, 2012-06-30 + + <mcsim> hello. Has anyone faced with problem when translator works + fine, but when it is started via rpctrace it hangs? Probably you know + what can cause this? + <antrik> mcsim: rpctrace itself is quite buggy + <antrik> zhengda once did a number of improvements, but they never went + upstream... + <youpi> well, he never explained how his fixes worked :) + <youpi> GNU/Hurd is no different from other projects in that regard: if + you don't explain how your patches work, there's low chance that they + are applied + <youpi> unless the maintainer has time to dive himself, which we don't + <pinotree> "it compiles, ship it!" + <braunr> pinotree: i guess the hurd is different in that particular + regard :p + <youpi> not different from linux + <braunr> eh, they include staging drivers now :) + <youpi> we have a sort-of staging tree as well, with netdde + <youpi> we don't really care about stability there + <antrik> youpi: actually, I think by now (and not to a small part + because of this episode) that we are too strict about patch + submission + <youpi> well, review really is needed, otherwise source gets into a bad + shape + <antrik> while zhengda's variant might not have been ideal (nobody of + us understands the workings of rpctrace enough to tell), I have + little doubt that it would be an improvement... + <youpi> it happened quite a few times that a fix revealed to be + actually bogus + <youpi> in that particular case, I agree + <youpi> the problem is that usually what happens is that questions are + asked + <youpi> and the answers never happen + <youpi> and thus the patch gets lost + <antrik> after all, when he when he submitted that patch, he had a much + better understanding of rpctrace than any of us... + <youpi> sure + <antrik> Linus is actually quite pragmatic about that. from what I've + seen, if he can be convinced that something is *probably* an + improvement over the previous status, he will usually merge it, even + if he has some qualms + <youpi> when there is a maintainer, he usually requires his approval, + doesn't he? + <antrik> in particular, for code that is new or has been in a very bad + shape before, standards shouldn't be as high as for changes to known + good code. and quite frankly, large parts of the Hurd code base + aren't all that good to begin with... + <youpi> sure + <antrik> well, sure. in this case, we should have just appointed + zhengda to be the rpctrace maintainer :-) + <antrik> BTW, as his version is quite fundamentally different, perhaps + instead of merging the very large patch, perhaps we should just ship + both versions, and perhaps drop the old one at some point if the new + one turns out to work well... + <antrik> (and perhaps I overused the word perhaps in that sentence + perhaps ;-) ) + <youpi> about that particular patch, you had needed raised a few bits + <youpi> and there was no answers + <youpi> the patch is still in my mbox, far away + <youpi> so it was *not* technically lost + <youpi> it's just that as usual we lack manpower + <antrik> yeah, I know. but many of the things I raised were mostly + formalisms, which might be helpful for maintaining high-quality code, + but probably were just a waste of time and effort in this case... I'm + not surprised that zhengda lost motivation to pursue this further :-( + <braunr> it would help a lot to get the ton of patches in the debian + packages upstream :) + <youpi> braunr: there aren't many, and usually for a good reason + <youpi> some of them are in debian for testing, and can probably be + commited at some point + <pinotree> youpi: we could mark (with dep3 headers) the ones which are + meant to be debian-specific + <youpi> sure + <antrik> well, there are also a few patches that are not exactly + Debian-specific, but not ready for upstream either... + <youpi> antrik: yes + # See Also 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 |