diff options
Diffstat (limited to 'hurd')
| -rw-r--r-- | hurd/console.mdwn | 13 | ||||
| -rw-r--r-- | hurd/console/discussion.mdwn | 136 | ||||
| -rw-r--r-- | hurd/critique.mdwn | 33 | ||||
| -rw-r--r-- | hurd/debugging.mdwn | 189 | ||||
| -rw-r--r-- | hurd/debugging/rpctrace.mdwn | 124 | ||||
| -rw-r--r-- | hurd/libihash.mdwn | 54 | ||||
| -rw-r--r-- | hurd/libports.mdwn | 67 | ||||
| -rw-r--r-- | hurd/libstore.mdwn | 13 | ||||
| -rw-r--r-- | hurd/porting/guidelines.mdwn | 66 | ||||
| -rw-r--r-- | hurd/running/debian.mdwn | 84 | ||||
| -rw-r--r-- | hurd/running/debian/dhcp.mdwn | 77 | ||||
| -rw-r--r-- | hurd/running/qemu.mdwn | 19 | ||||
| -rw-r--r-- | hurd/translator/auth.mdwn | 228 | ||||
| -rw-r--r-- | hurd/translator/discussion.mdwn | 165 | ||||
| -rw-r--r-- | hurd/translator/ext2fs.mdwn | 332 | ||||
| -rw-r--r-- | hurd/translator/mtab/discussion.mdwn | 552 | ||||
| -rw-r--r-- | hurd/translator/pfinet/implementation.mdwn | 180 | ||||
| -rw-r--r-- | hurd/translator/pflocal.mdwn | 36 | ||||
| -rw-r--r-- | hurd/translator/proc.mdwn | 68 | ||||
| -rw-r--r-- | hurd/translator/procfs/jkoenig/discussion.mdwn | 50 | ||||
| -rw-r--r-- | hurd/translator/term.mdwn | 8 | ||||
| -rw-r--r-- | hurd/translator/tmpfs/discussion.mdwn | 36 |
22 files changed, 2487 insertions, 43 deletions
diff --git a/hurd/console.mdwn b/hurd/console.mdwn index 10c74bf9..411058c8 100644 --- a/hurd/console.mdwn +++ b/hurd/console.mdwn @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2011, -2012, 2013 Free Software Foundation, Inc."]] +2012, 2013, 2014 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 @@ -452,6 +452,17 @@ Added examples that use repeaters needed by X. <Tekk_> started typing something different +## IRC, freenode #hurd, 2013-11-28 + + <Gerhard> I see a mouse cursor, but I'm not able to copy and paste. gpm is + not in the repository, right? + <youpi> copy/paste is not actually implemented yet + <youpi> so you can move the mouse, but clicks don't do anything :o) + <teythoon> ^^ + <Gerhard> ok, thx for the feedback. + <teythoon> i always wondered if it was just me >,< + + # Graphics/Higher Resolution ## IRC, freenode #hurd, 2012-04-24 diff --git a/hurd/console/discussion.mdwn b/hurd/console/discussion.mdwn index 73d605ed..48e2009e 100644 --- a/hurd/console/discussion.mdwn +++ b/hurd/console/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013, 2014 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 @@ -95,3 +96,136 @@ License|/fdl]]."]]"""]] <youpi> braunr: actually it seems like a bug in emacs <youpi> cud may or may not scroll the screen, depending on the implementation + + +# IRC, freenode, #hurd, 2013-12-28 + + <braunr> ahem, looks like the last xkb-data package dropped + /usr/share/X11/xkb/compat/default :/ + <ivanshmakov> braunr: Looks more like an upstream issue; check, e. g., + http://cgit.freedesktop.org/xkeyboard-config/commit/?id=882f5470713d. + <ivanshmakov> braunr: Slightly more surprising is that xkb-data 2.8 was + packaged for Debian last Sunday. While the upstream has released 2.10.1 + back in October, as per + http://www.x.org/releases/individual/data/xkeyboard-config/. + <gg0> ivanshmakov: + http://packages.qa.debian.org/x/xkeyboard-config/news/20131222T160519Z.html + <ivanshmakov> gg0: ACK, thanks. (No idea how did I read 2.10.1 as 2.8, as I + was looking on essentially the same information.) + + +## IRC, freenode, #hurd, 2013-12-30 + + <ZenWalker> on debian/hurd, with startx, show the error "cannot open + keyboard (no such file or directory)" + <braunr> ZenWalker: what version of xkb-data do you have ? + <ZenWalker> braunr: 2.10.1-1 + <braunr> ZenWalker: there is a bug in that package + <braunr> you can confirm it by spotting an error during system startup that + mentions a missing "compat/default" file + <braunr> this prevents the hurd console from starting + <braunr> and without the hurd console, xorg can't find the input device + <braunr> hopefully it will be fixed soon + <ZenWalker> braunr: yes, "couldn't open include file "compat/default"" + <ZenWalker> thanks + + +## IRC, freenode, #hurd, 2013-12-31 + + <braunr> youpi1: fyi, xkb-data doesn't provide compat/default, which + prevents the hurd console from starting + + <ZenWalker> braunr: X works with xkb-data 2.5.1-3 :) + + <braunr> maybe xkb-data isn't the problem + <braunr> maybe we need to fix the hurd-console + <braunr> youpi: we should probably fix the hurd with regard to xkb-data + before releasing the next packages + <braunr> it's very unlikely that xkb-data will be fixed + <braunr> they say compat/default is unused since march 2012 + + +## IRC, freenode, #hurd, 2014-01-01 + + <DusXMT> Is anyone else having problems with the console? + <gg0> downgrade xkb-data to + http://snapshot.debian.org/package/xkeyboard-config/2.5.1-3/#xkb-data_2.5.1-3 + <DusXMT> ty + + +## IRC, freenode, #hurd, 2014-01-04 + + <mihi> does anybody know if the fact that aptitude looks shitty on the hurd + console is a bug in the console implementation or some broken + term{cap,info} config? + <youpi> ncurses is pending a terminfo fix, possibly related + <youpi> you can try to recompile your hurd terminfo entry, adding xenl to + it, and see whether it fixes it + <mihi> hmm, just did an aptitude upgrade, and now after a restart the Hurd + console does not even start any more (did not mess with my terminfo yet) + <mihi> Couldn't open include file "compat/default" + <youpi> yes, xkb-data broke, downgrade it + <mihi> youpi, to which version? + <youpi> well, the previous one :) + <mihi> (or can aptitude or another tool show me what version I had + previously?) + <youpi> you can simply take the but-last on snapshot.debian.org + <mihi> youpi, thanks, that helped. And adding xenl to hurd.ti and + recompiling helped, too :) + + +## IRC, freenode, #hurd, 2014-01-13 + + <gnu_srs> Couldn't open include file "compat/default" from the console + <teythoon> that has been reported on the ml and as debian bug + <teythoon> a workaround is both in the upcoming hurd package as well as in + the ones i provide in hurd-ci + <gnu_srs> Any workaround for the hang in the console for now? + <teythoon> there is no hang + <teythoon> there is simply no getty + <gnu_srs> how come? + + <gnu_srs> and the xkb-data problems I thought was causing problems with the + hurd console to start, not the mach console. + <teythoon> gnu_srs: exactly, the missing xkb data prevents your + hurd-console from running + + +# IRC, freenode, #hurd, 2014-02-05 + + <bu^> btw, does the console handle other keymaps than the qwerty US one ? + Samuel thibault talked about this during his fosdem conference + <braunr> it does + <braunr> check /etc/default/hurd-console + <bu^> how ? I mean which lib does it use, because I face a similar issue + with my programms and would like a "smart" way to handle this (meaning + not reimplement something doing it worse) + <bu^> thx + <braunr> bu^: xkb + <bu^> I'm not clear with xkb and how much it is related to xorg, I would + like to be xorg independant, but the hurd console also should be and it + seems to work + <youpi> bu^: xkb is just a library + <youpi> xorg uses it + <youpi> but other applications can use it + <youpi> it just happens to be maintained by x.org people + <bu^> oh ok, nice, I'll look at it + <bu^> we are talking about this one ? + http://www.x.org/releases/current/doc/libX11/XKB/xkblib.html + <youpi> yes + <bu^> btw the way special caracters like é or à breaks the backspace + (erase) key as it will not count properly the number of caracters on the + line + <bu^> and I end up with remaining caracters I can't erase + <bu^> I also started to look for this one but didn't find a proper way to + use it as a library http://www.kbd-project.org + <youpi> bu^: probably a bogus locale + <youpi> that just works for me + + +# IRC, freenode, #hurd, 2014-02-25 + +[[!tag open_issue_hurd]] + + <gg0> to reproduce "task f5ca6e40 deallocating an invalid port 1711, most + probably a bug." just restart hurd-console diff --git a/hurd/critique.mdwn b/hurd/critique.mdwn index c432cc17..69400c5c 100644 --- a/hurd/critique.mdwn +++ b/hurd/critique.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2014 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="A Critique of the GNU Hurd Multi-server Operating System"]] @@ -18,3 +19,29 @@ is sometimes referred to as *the critique*. The paper provides a technical overview of the Hurd's architecture and critiques some of the decisions made. + + +# IRC, freenode, #hurd, 2014-02-06 + + <bwright> Just read a paper on hurd. + <bwright> Some interesting dot-dot and chroot issues were raised. + <bwright> But this was written my guess is in about 2007. + + +## IRC, freenode, #hurd, 2014-02-08 + + <antrik> bwright: both the dot-dot and chroot issues are fairly easy to + solve... of course they do indicate some more fundamental things to keep + in mind though. in fact, a few years ago we came up with a concept for + making filesystem permission handling more robust... but nobody ever got + to implementing it :-( + <antrik> bwright: this paper, I guess you are referring to the "critique"? + it was in fact written by the Hurd/L4 initiators. the observations made + in this paper are right, but IMHO they got carried away on the + conclusions -- most of the issues can be solved within the existing + framework, if you think about the actual problems seriously + <azeem> so they didn't think about it seriously? + <antrik> azeem: not in the right mindset I'd say :-) + <antrik> macrus actually said himself a while later that he probably + could/should have implemented some of the ideas within the existing + Hurd... diff --git a/hurd/debugging.mdwn b/hurd/debugging.mdwn index ae9b7bef..e0da8e76 100644 --- a/hurd/debugging.mdwn +++ b/hurd/debugging.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2013, 2014 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 @@ -53,3 +53,188 @@ License|/fdl]]."]]"""]] <braunr> a temporary receive right to get replies from servers <hacklu> so we can reuse the name which are freed before <braunr> of course + + +## IRC, freenode, #hurd, 2013-11-08 + + <teythoon> braunr: btw, portinfo --search turned out quite nice for + detecting port leaks + <braunr> teythoon: something you added i guess ? + <teythoon> braunr: just yesterday + <teythoon> braunr: portinfo.c is full of useful ideas + <teythoon> braunr: for example, with a little help of the target server + (introspection protocol for libports) we could reliably detect leaks of + ports managed with libports + <braunr> yes introspection is probably required + + +## IRC, freenode, #hurd, 2013-11-20 + + <braunr> looking forward to using portinfo --search btw :) + <teythoon> yeah, that turned out to be quite helpful + <teythoon> that reminds me of the libports introspection idea :) + <braunr> introspection ? + <braunr> i mean + <braunr> that much, or a simple name for each port ? + <teythoon> I thought about returning more information, like the port class + <braunr> class ? + <braunr> i don't think you should + <braunr> iirc, classes are deemed not very useful for hurdng + <braunr> they were supposed to be removed, leaving only buckets + <teythoon> hurdng ... ? + <braunr> which seems more appropriate + <braunr> oh :) + <teythoon> well, no need for an introspectino interface then + <braunr> http://www.gnu.org/software/hurd/hurd/ng.html + <braunr> introspection is a bit too much + <teythoon> just look at the ports in the only port set then + <braunr> but something that would be reusable in lsof + <braunr> or /proc/*/maps + <braunr> would be very nice + <teythoon> if you could just be a little more specific then I might just go + and implement it ;) + <antrik> braunr: I don't think bucket information would be useful to the + outside world; classes OTOH might + <teythoon> worked fine with the mtab translator, let's do that again ;) + <braunr> antrik: buckets aren't, clearly + <braunr> antrik: more than classes, object types + <braunr> teythoon: well cat /proc/self/maps on linux + <antrik> ain't that the same? ;-) + <braunr> i don't know + <braunr> and i'm not sure it's that easy to make classes/types something + global + <braunr> so simply returning a path, or even more generally a description + string (sometimes a path) + <braunr> should be fine + <braunr> teythoon: just consider ports are frontends to objects + <teythoon> yes + <braunr> what i'd like is something like object.toString() :p + <teythoon> right + <braunr> something that would help us gather information about objects + accessible from user applications + <braunr> what is known as open files on unix :) + <teythoon> so 1) get a list of ports managed by libports, and 2) map those + ports to strings describing the object ? + <braunr> the list isn't strictly necessary + <braunr> just associate a string description to ports + <braunr> portinfo and such already create port lists + <teythoon> and fail if the port wasn't vaild? + <teythoon> rihgt + <braunr> well + <braunr> if the port isn't valid, you can't succeed anyway + <braunr> but + <braunr> what is more likely is the port not supporting the operation + <teythoon> yes + <braunr> in which case assume the empty string + <braunr> it may not be that straightforward + <braunr> imagine reply ports in select() for example + <teythoon> so where would I put such an rpc ? + <braunr> i'm not sure + <braunr> for a time, i considered making it a kernel call + <braunr> it could be implemented in the signal thread too + <teythoon> uh, oh, that's glibc land, right... ? + <braunr> in addition to "what are you waiting on", we could have "what's + the name for that port" + <braunr> yes + <braunr> :) + <braunr> well not name + <braunr> port names refer to integers + <braunr> port desc + <teythoon> yes + <braunr> i'm not sure how it should be done + <braunr> ideally, user applications should never have any reply ports + <braunr> and we could implement it all in libports + <braunr> select (and maybe others) make it hard + <teythoon> how so ? + <braunr> such calls don't expect any kind of request + <braunr> other than what's intended + <braunr> if select gets something else than a select reply, it returns with + an error + <teythoon> so ? + <braunr> changing that to deal with unexpected requests makes the select + implementation even harder than it is + <braunr> hum so, you don't want something like a mail server to fail + because you used lsof right ? + <teythoon> why would it get unexpected requests ? + <teythoon> no + <braunr> a new rpc like "give me your description" would be unexpected for + select + <braunr> servers properly demuxing messages would already reply they don't + implement the interface + <braunr> select would return an error to its caller + <braunr> that's very different + <teythoon> ah, well, ok, but if we put it in the signal thread, then lsof + would talk to that port + <braunr> yes + <teythoon> you mentioned that as a reason not to put it in libports ? + <braunr> yes + <braunr> normal applications don't use libports + <braunr> but they do have receive rights + <teythoon> I see, yes + + +## IRC, freenode, #hurd, 2013-11-29 + + <braunr> is the format of portinfo --search ORIG_PID => ... FOUND_PID => + ... ? + <teythoon> i think so, not sure atm + <braunr> 4 -> 5: 1 => 1: send (refs: 65534) + <braunr> :/ + <braunr> hm i don't see such a right in pid 1 + <teythoon> no, frompid -> topid: port name in frompid => corresponding name + in topid + <braunr> oh ok + + +# IRC, freenode, #hurd, 2013-11-08 + +[[!tag open_issue_gdb]] + + <braunr> what i'd like personally would be gdb to be able to track threads + across address spaces, when it has the right to do so + <crocket> braunr, can gdb debug across threads? + <braunr> no + <braunr> the same is it can't follow system calls + <braunr> it can follow RPCs + <crocket> Then, I guess you have to debug multiple applications at once. + <braunr> can't* + <braunr> well + <braunr> the goal would be that + <braunr> right now, we debug them one at a time + <braunr> following our leads across applications + <braunr> it's a bit more tricky but not that hard + <teythoon> braunr: that would be nice indeed + <braunr> we're talking about cross-address-space debugging + <braunr> which is needed only when objects are shared between multiple + applications + <crocket> gdb can't do it + <braunr> but it can't do it on a monolithic system either + <braunr> people debug the kernel separately + <braunr> we debug our servers separately + <braunr> it's almost the same + <braunr> we don't debug all our servers, only those relevant in the code + path + <braunr> that's only a few + <teythoon> no it's worse for the monolithic kernel + <crocket> braunr, "Additionally, just tracking down a FS/write issue means + examining the user space process, the block device service, VFS service, + file system service and (possibly) the PCI service. If you get a blank on + that, its time to look at the IPC service. This is often easier in a + monolithic kernel." + <braunr> teythoon: depends + <braunr> crocket: agreed + <braunr> but again, such bugs are huge + <braunr> rare + <braunr> the only real class of cross-address-space bugs are leaks + <braunr> and leaks are easy to solve in practice + + +# [[open_issues/Translate_FD_or_Port_to_File_Name]] + + +# IRC, freenode, #hurd, 2014-01-30 + + <pere> btw, is there some alternative to strace? wanted to figure out why + lightdm didn't find dbus. + <pochu> there's rpctrace but that's a bit different + <youpi> there's also sotruss from recent glibc diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index d62a4387..dbd4b30b 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013 Free -Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 +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 @@ -225,6 +225,126 @@ See `rpctrace --help` about how to use it. <braunr> select is partially hand written <braunr> but it's a special case so that's ok +* IRC, freenode, #hurd, 2013-12-11 + + <gnu_srs> teythoon: Congrats regarding rpctrace, is it now fully + functional? + <teythoon> should be + <teythoon> well, you should be able to use it on any application that uses + select + <teythoon> other than that, it's as functional as it ever was + <teythoon> i was annoyed that i couldn't rpctrace ping, and the fix was + much easier than expected + <gnu_srs> and fork is no problem anymore? + <teythoon> was it ever ? + <braunr> yes, fork and some issues + <teythoon> rpctrace should pick up any forked processes + <teythoon> oh ? + <braunr> thanks for rpctrace too + <braunr> it was indeed on the todo list for a long time + <braunr> ah fork with regard to rpctrace + <braunr> no i don't think so + <braunr> but + <braunr> rpctrace can't be a perfect proxy + <braunr> because some calls just go directly through the kernel + <teythoon> really ? + <teythoon> we could install custom functions for any such call + <braunr> system calls + <braunr> yes + <teythoon> so why couldn't it be perfect ? + <braunr> i don't see how custom functions would do the trick + <braunr> i mean + <braunr> it would help, but not guarantee applications have to use these + functions + <braunr> the real solution would be something like strace + <teythoon> huh ? + <teythoon> why wouldn't there be any guarantee like that ? + <braunr> rpctrace catches messages, not system calls + <braunr> you don't see calls to mach_reply_port() obviously + <braunr> you just hope that such reply ports are sent through messages + rpctrace will see + <teythoon> + http://www.gnu.org/software/hurd/gnumach-doc/Syscall-Emulation.html + <teythoon> sure one does + <braunr> ah that + <braunr> we don't want that :p + <teythoon> why not ? + <braunr> it's a hack + <braunr> and checking for those impacts performances a bit + <braunr> it would be better to change the system calls into RPCs + <teythoon> so ? it would only affect tasks running in rpctrace, and the + documentation does not call that interface a hack ;) + <braunr> oh i agree + <braunr> i was saying we don't want them the same way we don't want async + ipc + <teythoon> yeah sure, i agree + <braunr> but since that's how mach works, why not + <braunr> although iirc, checking for emulated syscalls is done by the + syscall entry code + <teythoon> so ? + <braunr> so it has an impact on every system call + <teythoon> we could make that a compile time option and use it in rpctrace + only when available + <teythoon> so anyone who needs good traces, could run that kind of kernel + <braunr> no need + <teythoon> for what ? + <braunr> mach and the hurd are already too slow for this to be noticeable + <braunr> let's just live with it and use syscall emulation + <teythoon> why do you say that, i mean, do you have numbers ? + <braunr> from what i see, it's a bunch of less than 5 instructions + <teythoon> ok + <braunr> i'm just being picky + <braunr> i really don't like the idea of emulated system calls + <braunr> RPCs are much cleaner + <braunr> and frankly, the system calls that i'd like to see in rpctrace are + those like mach_thread_self() + <braunr> to spot reference leaks + <braunr> not too annoying actually + +* IRC, freenode, #hurd, 2013-12-13 + + <teythoon> hm + <teythoon> i briefly looked into the haskell test suite failure youpi wrote + about + <teythoon> i looked at one of the haskell-http-conduit failures + <teythoon> i think it starts a dummy web server and does one request to + itself + <teythoon> the binary is using select, so i used the fixed rpctrace to + obtain a trace + <teythoon> it looks strange ... + <teythoon> the http request is answered before the request is sent + + <gnu_srs> teythoon: Nice to see that you added escape of non-printable + characters in rpctrace:-D + <teythoon> yeah, makes rpctrace less trippy though ;) + +* IRC, OFTC, #debian-hurd, 2014-02-20 + + * pere really misses strace. + <pere> rpctrace is not even close. + <teythoon> pere: why do you say that ? + <teythoon> pere: it is not that we couldn't write strace for mach, it + would just be very boring + <pere> teythoon: because strace tell me what a program does in details, + without too much irrelevant information, while rpctrace is just so + verbose that it is hard to see the relevant parts. + <youpi> well, they are mostly equivalent + <youpi> strace ls / gives me 200 lines, while rpctrace ls / gives me + 300 lines + <youpi> there are spurious lines like term_getctty, but otherwise it's + mostly the same level of details + <youpi> (also, mach_port_deallocate get in the way) + <pere> strace also have the great advantage for C programmers that the + output look like the equivalent C calls. + <youpi> well, twice as many lines is not so much more verbose :) + <youpi> but yes, having internal RPC names doesn't help + <youpi> another way would be to use sotruss + <pere> sotruss just gave me 'killed' + <youpi> yes, it probably needs fixing, nobody worked on it AFAIK + <youpi> that's why I said "would", not "is" :) + <pere> in the mean time, I'll just keep dreaming of something with + output like strace. :) + # See Also diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn index be20fa58..57588d55 100644 --- a/hurd/libihash.mdwn +++ b/hurd/libihash.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009, 2010, 2011, 2012, 2013 Free Software +[[!meta copyright="Copyright © 2009, 2010, 2011, 2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -22,23 +22,44 @@ License|/fdl]]."]]"""]] # Open Issues - * [[viengoos libhurd-ihash|microkernel/viengoos/projects/new_hash_function]] +## Collisions - IRC, freenode, #hurd, 2008/2009 +Viengoos: [[microkernel/viengoos/projects/new_hash_function]]. - <neal> so, we need a new ihash implementation - <neal> marcusb: When 80% full, the collision rate is very high. - <neal> marcusb: I tested using 512mb / 4096 entries - <neal> marcusb: Changing the load factor to 30% resulted in my program - running more than an order of magnitude faster. - <marcusb> yeah, it shouldn't get so full - <marcusb> don't we do an exponential back-off in the array size? - <marcusb> of course it's clear we can do much better - <marcusb> the ihash algo is very simple - <marcusb> I'm not even sure it makes much sense to have a generic - library - * [[community/gsoc/project_ideas/object_lookups]] +### IRC, freenode, #hurd, 2008/2009 + + <neal> so, we need a new ihash implementation + <neal> marcusb: When 80% full, the collision rate is very high. + <neal> marcusb: I tested using 512mb / 4096 entries + <neal> marcusb: Changing the load factor to 30% resulted in my program + running more than an order of magnitude faster. + <marcusb> yeah, it shouldn't get so full + <marcusb> don't we do an exponential back-off in the array size? + <marcusb> of course it's clear we can do much better + <marcusb> the ihash algo is very simple + <marcusb> I'm not even sure it makes much sense to have a generic + library + + +## Reader-Writer Locks + +### IRC, freenode, #hurd, 2013-12-09 + + <teythoon> btw, why don't we use rwlocks for serializing access to our + hash tables ? + <braunr> teythoon: we definitely could + <teythoon> ok + <braunr> teythoon: we definitely could use rcu *whistles* + <teythoon> should we ? + <braunr> i don't know + <teythoon> yeah, ofc + <braunr> rwlocks have some overhead compared to mutexes + <braunr> and our mutexes are already quite expensive + <braunr> our condition variables are also not optimized + + +# [[community/gsoc/project_ideas/Object_Lookups]] # Alternatives? @@ -64,3 +85,6 @@ License|/fdl]]."]]"""]] * <http://www.azillionmonkeys.com/qed/hash.html> * CCAN's htable, idtree + + * Not actually use a hashing data structure; see [[libports]], *Open Issues*, + *IRC, freenode, #hurd, 2013-11-14*. diff --git a/hurd/libports.mdwn b/hurd/libports.mdwn index 6f2cd46d..b0a0f6d5 100644 --- a/hurd/libports.mdwn +++ b/hurd/libports.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 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 @@ -35,3 +36,67 @@ when they are not used. ([[!taglink open_issue_hurd]]: there used to be bugs in this area, [[!message-id "87hev152we.fsf@becket.becket.net"]], but it may be fixed as of [[!message-id "20111030210045.GA4983@myhost"]], [[!GNU_Savannah_Git_hurd_hurd 9b5429e834cde56f73b8ff605e36afc7d9bb6e1b]].) + + +# Open Issues + +## Several on the [[/Open_Issues]] page + +## IRC, freenode, #hurd, 2013-11-14 + + <teythoon> # portinfo $(pgrep mach-defpager) | tail -n 1 + <teythoon> 16819001: receive + <teythoon> is that normal ? + <braunr> it can be, yes + <braunr> port names can be renamed + <braunr> there are a few occurrences in the code + <braunr> see + http://www.gnu.org/software/hurd/gnumach-doc/Port-Names.html#Port-Names + <teythoon> I know + <braunr> mach-defpager/default_pager.c: kr = mach_port_rename( + default_pager_self, + <teythoon> heh, it is a pointer + <teythoon> I thought that'd make stuff inefficient in gnumach? + <braunr> it does + <braunr> such rights are moved from a regular fast-access table to a splay + tree + <braunr> but when i looked into it, there were never more than a few dozen + rights in these trees + <braunr> (which is why i didn't merge my radix tree in gnumach) + <teythoon> I've been contemplating to replace the libihash usage in + libports with a simple array + <braunr> consider a radix tree too then :) + <teythoon> well, I did + <braunr> ok + <teythoon> but I'm not convinced that it would do better than a simple + array (or the current ihash implementation) + <braunr> really ? + <teythoon> what do you hope to gain? + <braunr> i'm practically certain it would do better than the current ihash + code + <braunr> uh, speed + <braunr> the problem with an array or a hash table is resizing + <braunr> a well tuned radix tree (say 64 ot 512 items per node) can reduce + to a simple array for the common case + <teythoon> right + <teythoon> but consider the use case + <braunr> and scale very well for massive users such as file systems which + can reach several hundred thousand rights + <teythoon> hm + <braunr> an array could be very efficient as well + <braunr> i'm just concerned about resizing + <teythoon> but this is a problem with the current implementation as well + <braunr> sure + <braunr> we're not considering keeping it anyway + <braunr> this discussion is about array vs radix tree + <braunr> the radix tree also has the advantage to efficiently deal with + sparsely populated port name spaces + <braunr> to some degree + <braunr> which is probably what you're currently concerned with about this + weird port name in defpager :) + <teythoon> http://paste.debian.net/65780/ + <teythoon> yes, but mach-defpager does not use libports + <braunr> ok + +See also discussion on [[microkernel/mach/deficiencies]], *X15*, *IRC, +freenode, #hurd, 2013-11-14*. diff --git a/hurd/libstore.mdwn b/hurd/libstore.mdwn index b2e7f7a9..45fc0860 100644 --- a/hurd/libstore.mdwn +++ b/hurd/libstore.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2013, 2014 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 @@ -65,3 +65,12 @@ feeds=no]] course, any results he got from his work really should be integrated more properly into the existing body of documents. <tschwinge> As with so many other documents/discussions/etc. ;-| + + +## IRC, freenode, #hurd, 2013-11-12 + +[[!tag open_issue_hurd]] + + <phcoder> Is it possible to specify hurd root by sth else than device name? + E.g. fs UUID? + <teythoon> phcoder: I do not believe so diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index a9acd9f9..6afa46fc 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010, 2011, -2012, 2013 Free Software Foundation, Inc."]] +2012, 2013, 2014 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 @@ -376,6 +376,70 @@ With Python, you can use the [`errno` module](http://docs.python.org/library/err Configure script often hardcode the library that contains dlopen & such (`-ldl`), and only for Linux. Simply add the other GNU OS cases: replace `linux*` with `linux*|gnu*|k*bsd*-gnu*` +## `struct sockaddr`, `sa_len/sa_family` + +### IRC, freenode, #hurd, 2014-02-18 + + <braunr> if there is someone here that can help, i've traced the https + issue in iceweasel down to nspr + <braunr> the problem being that the hurd uses the old 4.4bsd sockaddr + structure that includes sa_len before sa_family, and nspr directly maps + that into its own structure, assuming the internal layout is the same + <braunr> i need to change a configure script so that a macro is defined for + the hurd + <braunr> let's see if that works + <braunr> better :) + <braunr> there, ssl now works + <braunr> \o/ + <braunr> it's still the experimental one + <braunr> and there are other minor issues + <braunr> (like no logo on the about panel :p) + <cluck> that's a feature^TM + <braunr> maybe it's not a mistake + <braunr> i haven't seen that version on linux to actually compare + *** rbraun_hurd (c3445c23@gateway/web/freenode/ip.195.68.92.35) has joined + channel #hurd + <rbraun_hurd> webchat from freenode :) + <teythoon> :D + <rbraun_hurd> there is also this weird :"Failed to truncate cookie file: + Invalid argument Failed to write cookie file: Unknown error (os/kern) + 303" error + <rbraun_hurd> but i guess it's simply a matter of supporting an option in + glibc/hurd somewhere + <braunr> 18:06 CTCP VERSION reply from rbraun_hurd: qwebirc v0.91, + copyright (C) 2008-2011 Chris Porter and the qwebirc project -- + Mozilla/5.0 (X11; GNU i686-AT386; rv:27.0) Gecko/20100101 Firefox/27.0 + Iceweasel/27.0 + <braunr> hm, i didn't version the iceweasel packages :/ + <braunr> i'll rebuild them properly and put them on my repository + <braunr> oh, the freenode webchat actually runs in gnash oO + + +### IRC, freenode, #hurd, 2014-02-19 + + <braunr> http://darnassus.sceen.net/~rbraun/nspr4_hurd.patch + <braunr> in short: nsprt has its own struct sockaddr, which it assumes to + have the same layout as the native one + <youpi> doesn't kfreebsd also have sockaddr_len ? + <braunr> and of course, that's not the case on the hurd, because we use an + old 4.4bsd header that defines sa_len before sa_family, making all sorts + of tests fail in nspr + <braunr> hm + <braunr> i don't know + <braunr> we could discuss that with them + <braunr> but i doubt they don't use iceweasel :) + <youpi> it really seems kfreebsd has sa_len etc. + <youpi> kfreebsd really has sa_len + <youpi> so put it in the new case too :) + <braunr> i'll ask them first + <braunr> something in nspr might already take care of the bsd case + elsewhere + <braunr> nspr knows more about bsd systems than it knows about the hurd :) + <braunr> but with all these fixed, i could run iceweasel for a whole day at + work, multiple tabs, gnash running (things like youtube and freenode web + chat client among other things) + + ## <a name="linux_headers"> Missing `linux/types.h`, `asm/types.h`, `linux/limits.h`, `asm/byteorder.h`, `sys/endian.h`, `asm/ioctl.h`, `asm/ioctls.h`, `linux/soundcard.h` </a> These are often used (from lame rgrep results) instead of their standard equivalents: `sys/types.h` (or `stdint.h` for fixed-size types), `limits.h`, `endian.h`, `sys/ioctl.h`, `sys/soundcard.h` diff --git a/hurd/running/debian.mdwn b/hurd/running/debian.mdwn index 39c7d1a6..ac40ce79 100644 --- a/hurd/running/debian.mdwn +++ b/hurd/running/debian.mdwn @@ -22,3 +22,87 @@ *Debian GNU/Hurd*, [[MichaelBanck]], LinuxTag 2004 Karlsruhe - [[Status]] - [Archive Qualification](http://wiki.debian.org/ArchiveQualification/hurd-i386) + + +# IRC, freenode, #hurd, 2014-01-18 + + <anatoly> From http://darnassus.sceen.net/~hurd-web/hurd/running/debian/ + "Just in case you were wondering: the root password is root.". I think + it's not correct because it allows me to login witout password in hurd + console + <anatoly> Tried it in latest qemu image (from 2013 05 04) + <braunr> anatoly: you probably can change it yourself since it's a wiki + <anatoly> braunr: ok + + +# `/etc/mtab` -> `/proc/mounts` + +## IRC, freenode, #hurd, 2014-02-12 + + <braunr> hm, there is something weird + <braunr> after successfully installing (with the new installer cd), and + rebooting, system init fails because fsck can't be run on /home (a + separate partition) + <braunr> it can't fsck because at that point, /home is already mounted, and + indeed the translator is running + <braunr> teythoon: any idea what might cause that ? + <teythoon> me ? + <teythoon> no + <braunr> ok + <braunr> ah no, actually /home isn't mounted oO + <braunr> but fsck still refuses to check it, stating that reason + <braunr> hm, /etc/mtab isn't a link to /proc/mounts here, might explain + + +## IRC, freenode, #hurd, 2014-02-12 + + <braunr> yes, better with a proper symlink :) + <teythoon> good + <youpi> Mmm, what is supposed to create that symlink? + <teythoon> one debian init script did that at one time + <teythoon> i believe they dropped that + <youpi> err, but something must be creating it for newer systems + <teythoon> good point + <braunr> well, except for these small details, everything went pretty + smooth + <braunr> both on ide and ahci + <youpi> it seems /etc/mtab gets created at boot + <youpi> (on Linux I mean) + <teythoon> youpi: i cannot find the init script, but i'm sure that it was + there + <youpi> I can't find it either on the installed system... + <azeem> maybe pere or rleigh in #debian-hurd can help + + +## IRC, freenode, #hurd, 2014-02-13 + + <braunr> 6<--60(pid1698)->dir_lookup ("var/run/mtab" 4194305 0) = 0 3 + "/run/mtab" (null) + <braunr> looks like /etc/mtab isn't actually used anymore + <teythoon> it never was on hurd + <tomodach1> braunr: well it is generated i believe from mounted filesystems + <tomodach1> if its still around there is a reason for it, like posix + compatiblity perhaps? + <braunr> well the problem is that, as mentioned in pere's thread on + bug-hurd, some tools now expect /var/run/mtab instead of /etc/mtab + <braunr> and since nothing currently creates this file, these tools, such + as df, are lost + <braunr> they can't find the info they're looking for + + +## IRC, freenode, #hurd, 2014-02-17 + + <braunr> i still don't have mtab at the proper location on darnassus + <pere> is there something missing with sysvinit on hurd? + <braunr> is that normal ? + <pere> yes. I recommended fixing it in the hurd package. (BTS #737759) + <braunr> yes i saw but was there any action taken ? + <pere> did not check + <teythoon> i thought youpi mentioned that it is fixed in the libc and we + just need to rebuild coreutils or something + <pere> yes + <braunr> oh ok + <braunr> but doesn't that mean it will use /etc/mtab ? + <pere> if I was a hurd porter, I would fix it in hurd while waiting for a + fix in coreutils, just to save people for wondering about the breakage, + but I am not the most patient of developers. :) diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn index 849ff382..8846769a 100644 --- a/hurd/running/debian/dhcp.mdwn +++ b/hurd/running/debian/dhcp.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -124,3 +124,78 @@ scripts, but has its own `/libexec/rc` script -- which integrates scripts from in /dev/eth0) <teythoon> I tried to rebuild the package served on debian-ports, but that failed + + IRC, freenode, #hurd, 2014-01-03: + + <congzhang> dhcp 4.3 alpha released + <congzhang> and PATH_MAX issue was fixed + + IRC, freenode, #hurd, 2014-01-21: + + <gnu_srs> teythoon: what about this? *** stack smashing detected ***: + dhclient terminated + <teythoon> gnu_srs: well, dhclient dies + <teythoon> i've seen this, it comes and goes + <teythoon> not sure what happens, but i tend to blame it on our + custom-built dhcp package + <teythoon> from debian-ports, and it's outdated + <teythoon> it's most likely not your fault + <gnu_srs> i thought there was a new upstream by now + <teythoon> and the network configuration can be done with passive + translators as it was always done + <teythoon> there was ? + <gnu_srs> there is one recently released, haven't checked yet + <gnu_srs> in experimental: 4.3.0a1-2, does still not build out of the + box + <teythoon> there was, but it does not seem to build on the hurd + <teythoon> + https://buildd.debian.org/status/logs.php?pkg=isc-dhcp&arch=hurd-i386 + <teythoon> the most recent version is from debian-ports + + + IRC, freenode, #hurd, 2014-01-24: + + <braunr> stack smashing detected ***: dhclient terminated + <braunr> how nice + <tschwinge> braunr: dhclient: + http://news.gmane.org/find-root.php?message_id=%3C874ngfvwn4.fsf%40kepler.schwinge.homeip.net%3E + <tschwinge> braunr: And I thought, teythoon had found this to be a + buffer overflow; something like char dev[10], and for us the path to + the dev (/dev/eth0) was longer (but I may be misremebering). + <braunr> tschwinge: sounds reasonable + <tschwinge> braunr: By the way: I'm seeing this segfault all the time + during boot, but when I again run it manually (root login), it works + fine. + <braunr> tschwinge: you mean the dhclient one µ? + <tschwinge> Yes. + <braunr> mhm + <teythoon> braunr, tschwinge: i never found the cause of the dhclient + issue + <teythoon> i blame the (outdated) build on debian-ports + + + IRC, freenode, #hurd, 2014-01-30: + + <youpi> err, still nobody found the dhclient bug? + <gnu_srs> youpi: You found the dh-client bug, right? + <youpi> gnu_srs: yes, the dhclient bug was in libc, as tschwinge + guessed + <youpi> I'll probably upload a fixed glibc on debian-ports + + <gnu_srs> youpi: dhclient starts OK with libc 2.17-98~0 + + <youpi> btw, the experimental version of isc-dhcp has a newer + occurrence of PATH_MAX + <gnu_srs> :-( + <youpi> (aside from not including the needed debian files for + hurd-i386) + + * IPv6 + + IRC, freenode, #hurd, 2014-02-23: + + <gg0> seems dhclient can't also set ipv6 translator + <gg0> cheated by setting it manually, i had probably screwed it up + somehow + <gg0> exim was complaining 2014-02-23 22:26:41 IPv6 socket creation + failed: Address family not supported by protocol diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index a0b9e6da..df65eb7b 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, -2013 Free Software Foundation, Inc."]] +2013, 2014 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 @@ -275,6 +275,23 @@ but note that `ping` doesn't work with QEMU's user-networking stack. If you want to connect from the host system to the Hurd system running in QEMU, you can use port forwarding in QEMU or to setup something more advanced, like bridged networking. + +### IRC, freenode, #hurd, 2014-02-12 + + <braunr> youpi: also, the problems i had with regard to accessing the + debian repository were caused by a qemu bug where, in nat mode, qemu is + unable to handle dns requests if the host dns servers are ipv6 ones + <youpi> yes, we've noticed that with a student of mine + <youpi> you may be interested by a patch we submitted to qemu-devel, that + adds ipv6 support to -net user :) + <braunr> :) + <braunr> for now i directly change resolv.conf + <youpi> braunr: the issue is that you have only ipv6 nameservers, right? + <braunr> yes + <youpi> there's not much better to do than that + <youpi> (patching resolv.conf inside the guest, or apply the ipv6 patch) + + ## Port Forwarding in QEMU (In the following we assume we use kvm!) diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn index 10cfb3aa..68bbce44 100644 --- a/hurd/translator/auth.mdwn +++ b/hurd/translator/auth.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2013, 2014 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 @@ -19,3 +20,228 @@ It is stated by `/hurd/init`. [[*The_Authentication_Server*|documentation/auth]], the transcript of a talk about the details of the authentication mechanisms in the Hurd by Wolfgang Jährling. + + +## IRC, freenode, #hurd, 2013-10-31 + +[[!tag open_issue_documentation]] + + <braunr> is there an in-depth documentation somewhere about the auth server + that explains why there are "reauthenticate" operations everywhere ? + <braunr> nice, hammar's thesis does it :) + +[[hurd/documentation]], *Generalizing mobility for the Hurd*, Carl Fredrik +Hammar. + + +## IRC, freenode, #hurd, 2013-11-01 + + <gnu_srs> neal: Thanks, I'm trying to to call auth_server_authenticate + from a libc function, but that fails. That function returns MIG_NO_REPLY. + <gnu_srs> auth_user_authenticate works OK, but I need the IDs from the + auth_server_authenticate. What to do, implement a new RPC, + <gnu_srs> modify auth_user_authenticate (probably not) ? + <gnu_srs> or modify auth_server_authenticate (probably not) + <youpi> gnu_srs: show the source code you have written. MIG_NO_REPLY is not + expected, unless you called server_authenticate on the wrong port + <gnu_srs> S_auth_server_authenticate does not have any other exits than + MIG_NO_REPLY (and errors) + <gnu_srs> auth/auth.c + <youpi> yes, but it does do auth_server_authenticate_reply, which is what + matters + <youpi> i.e. what provides the answer + <youpi> (and the uids etc.) + <gnu_srs> I don't seem to be able to call that function directly from libc? + <youpi> eh? You're not supposed to call auth_server_authenticate_reply + yourself, it's auth which is supposed to + <youpi> precisely to provide the reply to the auth_server_authenticate RPC + <youpi> again, please show your source code + <youpi> there must be some mistake + <gnu_srs> Please show me how to call auth_server_authenticate and that + function returning 0 + <youpi> there are plenty of examples in the hurd source code + <youpi> e.g. ext2fs + <youpi> or libdiskfs, I can't remember where it is exactly inside ext2fs + <gnu_srs> I've tried all, on avail:( + <gnu_srs> no* + <youpi> € git grep auth_server_auth + <youpi> libiohelp/iouser-reauth.c: err = auth_server_authenticate + (authserver, + <youpi> was it so hard? + <gnu_srs> I did, and tried every combination, nothing works! + <youpi> something has to work, otherwise we'd have no uid authentication + against ext2fs + <youpi> so there must be a combination you missed + <youpi> did you understand how the authentication protocol works, for a + start? + <youpi> otherwise, random code will most probably never work, for sure :) + <gnu_srs> called from libc? + <gnu_srs> a libc function? + <youpi> being from a libc function or from an io_reauthenticate callback + does not really matter + <gnu_srs> well, random or not, please show me then + <youpi> it's already there in ext2fs + <youpi> again, if you don't understand *that* code, no need to try to write + other code, take time to understand what exactly happens in the ext2fs + case + <gnu_srs> ok, can you tell me how a function only returning MIG_NO_REPLY + can return 0 when called? + <gnu_srs> by a server or client + <youpi> maybe one thing you are missing: in the ext2fs case, we have the + sender use io_reauthenticate to provide the receiver (ext2fs) with the + reference port, in the sendmsg/recvmsg, it'll be the message which will + hold the ref port + <youpi> but otherwise it's all the same + <youpi> gnu_srs: as I said, by being called on the proper port, + <youpi> i.e. the auth port, with the ref port provided by the sender + <youpi> but again, without seeing your code, I can't divine what mistake + you may have done + <youpi> all I can do is that your code is supposed to really look very much + like the ext2fs case + <gnu_srs> there is a difference between io_reauthenticarte and + proc_reauthenticate, a subsequent call to auth_user_authenticate returns + 0 in the second case. + <youpi> i.e. _hurd_setauth in hurd/setauth.c and iohelp_reauth in + libiohelp/iouser-reauth.c + <youpi> why are you talking about io_reauthenticate an proc_reauthenticate? + <youpi> again, without seeing your source code, I can't understand what you + are talking about + <gnu_srs> first: (17:06:23) srs: ok, can you tell me how a function only + returning MIG_NO_REPLY can return 0 when called? + <youpi> and I can't afford the time to divine + <youpi> yes, that's iohelp_reauth in libiohelp/iouser-reauth.c + <youpi> for an example that works + <youpi> by using the proper ports + <youpi> if you don't get a reply, it's most probably simply because the + reply goes to the wrong port + <gnu_srs> again, where/how is the return value communicated by + auth_server_authenticate to the client/caller? + <youpi> again, it's the auth/auth.c code + <youpi> which calls auth_server_authenticate_reply + <gnu_srs> but that function ends with return MIG_NO_REPLY? + <youpi> yes, because auth_server_authenticate_reply() already did provide + the reply + <youpi> so the RPC function does not return a reply + <youpi> since it already explicitly sent one + <youpi> through auth_server_authenticate_reply + <gnu_srs> and exits earlier? + <youpi> it doesn't exit earlier + <youpi> it first calls auth_serveru_authenticate_reply + <youpi> and then returns with MIG_NO_REPLY + <gnu_srs> how the fck should i know that? + <youpi> by reading MIG documentation? + <youpi> I believe that _request/_reply mechanism is documented there + <gnu_srs> MIG magic again:( It strikes back, whatever you do to avoid it + <youpi> at least I don't think I have divined how it was working, so I must + have read that in some documentation + <youpi> it's not magic + <youpi> you just have to read the doc to understand how it works + <gnu_srs> I've not found any good doc on MIG yet. + <youpi> depends what you call "good" + <youpi> MIG is a complex thing, so documentation is complex, yes + <youpi> that can't really be avoided + <gnu_srs> mig.pdf + <gnu_srs> again: how can a function returning MIG_NO_REPLY return 0 when + called (as current implementations show)? + <youpi> again, by using the proper ports + <youpi> if not using the proper ports, the reply goes to another port + <youpi> and thus no reply + <youpi> and again, without showing the source code, we can't divine how you + didn't use the proper ports + <gnu_srs> so you mean a reply to a port is the same as the error code + returned? + <youpi> not always exactly, but basically yes + <youpi> gnu_srs: *again* , *really*, showing us what you've come up with + would very *most* probably allow us to help you + <youpi> otherwise it's just guess work and misunderstandings + <gnu_srs> FYI: there is no libc function calling auth_server_authenticate + directly + <youpi> sure + <youpi> that doesn't mean it can't + <gnu_srs> and here is one code example, not even trying to send+receive, it + is only in recvmsg.c: http://paste.debian.net/63374/ + <youpi> why is that code doing both auht_user_auth and auth_server_auth ? + <youpi> it's the sender side which is supposed to call auth_user_auth + <youpi> and why are you calling proc_reauthenticate, that has nothing to do + with the matter at stake + <gnu_srs> sorry, you can remove that part, same result + <youpi> ok but auth_user_authenticate should really go to the sender side + <youpi> s/should/must + <youpi> it is supposed to hang until auth_server_authenticate gets called + by the receiver + <youpi> so putting both on the receiver can not work + <youpi> at best auth_user_authenticate would hang, waiting for the + auth_server_authenticate which is called just after that... + <youpi> don't try random code, that can't work + <youpi> follow what I said + <youpi> in my mail + <gnu_srs> I did issue auth_user_authenticate on the send side, and + auth_server_authenticate on the receive side. + <gnu_srs> that was the path I followed, then when nothing worked,. I tried + the receive side only. + <youpi> that's why I said don't try random code + <youpi> it can't work with receive side only + <youpi> really, go as I said + <youpi> send / receive + <youpi> there must be something you made wrong + <gnu_srs> in the beginning it was not random code;) + <youpi> but it's not a reason for stabbing in the dark with random code, + that just can't work + <youpi> then stay with the code at the beginning + <youpi> and don't start writing random code + <youpi> that approach can *not* work + <gnu_srs> still when issuing __proc_reauthenticate followed by + auth_user_authenticate on the send side the port delivered is 0, + i.e. unusable + <youpi> why calling proc_reauthenticate?? + <youpi> it has nothing to do with the auth_*_authenticate protocol + <youpi> really + <youpi> what made you believe it was part of it? + <gnu_srs> dunno, if you say so;) + <youpi> it's not even mentioned in the documentation I referred to in my + mail + <youpi> again, make sure you actually *understand* the auth_*_authenticate + protocol + <gnu_srs> I found it in the already implemented code. + <gnu_srs> and process.defs + <youpi> for the proc_authenticate protocol, sure + <youpi> but that has nothing to do with the auth_*_authenticate protocol + <gnu_srs> well, the hurd documentation does not cover the proc case only + the io case, unfortunately:( Marcus, please write more documentation:-D + <youpi> it's just the same + <youpi> exactly the same + <youpi> ok, now I understand what happend: you followed some code which was + doing the auth protocol with the proc translator, not with the ext2fs + translator + <youpi> and you had *not* understood what proc_reauthenticate was doing + there + <youpi> you should have followed some code which was doing the auth + protocol with the ext2fs translator, i.e. through io_reauthenticate, of + course + <youpi> if you read random code, there's no way you can understand it of + coruse + <youpi> again, read hurd/setauth.c + <youpi> it does the reauthentication with ext2fs, through io_reauth to give + the ref prot + <youpi> s/prot/port + <youpi> io_reauth has to be replace with a port send over the socket of + course + <youpi> if that's obvious, don't write code, and ask yourself whether you + have really understood the auth protocol at all + <youpi> s/that's obvious/that's not obvious/ + <youpi> understand means being able to match the source code of setauth.c + with the explanation from marcus + <gnu_srs> I'm learning all the time, in a few years I will be able to + contribute seriously;-) but the MIG stuff, I dunno:( + <youpi> well, the problem is that it takes us a hell lot of time to explain + you things + <youpi> just because you don't seem to manage to learn without going + randomly + <gnu_srs> just reading source code is a random process, unfortunately. + <youpi> ?! + <youpi> sure not + <youpi> if you do it randomly, then it's not wonder you're getting random + <youpi> don't read it randomly + <youpi> follow paths + <youpi> I've never read code randomly, it's a loss of time and a way to + just mix everything together without understanding anything diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn index 95f5ab0c..70a6efee 100644 --- a/hurd/translator/discussion.mdwn +++ b/hurd/translator/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2013, 2014 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 @@ -10,6 +11,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation open_issue_hurd]] +[[!toc]] + # IRC, freenode, #hurd, 2011-08-25 @@ -45,3 +48,163 @@ License|/fdl]]."]]"""]] .. <braunr> but at least, thread consumption will correctly decrease with inactivity + + +# IRC, freenode, #hurd, 2014-01-30 + + <sjbalaji> can any one exmplain me hello translator ? I am new to hurd + <teythoon> sjbalaji: sure, what do you want to know ? + <teythoon> how to use it ? + <sjbalaji> No I mean what is the main reason of that translator. I am + familiar with Linux. + <gnu_srs> sjbalaji: start with: + https://www.gnu.org/software/hurd/hurd/documentation/translator_primer.html + <sjbalaji> I ran that example but I am still clueless about the actual + reason behind the translators and this simple hello world translator + example. + <teythoon> sjbalaji: the Hurd is a multiserver os, almost all functionality + lives in userspace servers called 'translators' + <teythoon> sjbalaji: the Hurd uses the file system as namespace to lookup + these servers + <teythoon> e.g. /servers/socket/1 is /hurd/pflocal and handles pipes and + unix socket communication + <sjbalaji> I can see from the example that a hello file is associated with + a /hurd/hello translator + <teythoon> yes + <teythoon> think of translators like FUSE-based filesystems, only more + general + <teythoon> b/c translators are not restricted to provide filesystem-like + services + <sjbalaji> So this example hello translator just adds hello world in the + associated file, am I correct ? + <teythoon> it's not adding stuff to a file + <teythoon> say you did settrans -ac /tmp/hi /hurd/hello, if you do cat + /tmp/hi, cat does some rpc calls to the started /hurd/hello program that + returns 'hello world' as the file contents + <teythoon> in a sense /hurd/hello is a 'filesystem' that provides a single + file + <sjbalaji> So is it like hello is the mount moint for that hello server ? + <teythoon> sjbalaji: yes, kind of that, but in a more general sense + <sjbalaji> teythoon: How can I see the different servers that are running + in the system ? I tried top in the terminal but it returned cannot find + /proc/version + <teythoon> sjbalaji: so it seems your procfs is not running, try as root: + settrans /proc /hurd/procfs -c + <sjbalaji> teythoon: But how does one differentiate between a server and a + normal process ? + <teythoon> one does not + <teythoon> for a rule of thumb: anything from /hurd is a translator + <teythoon> you can view a nodes passive translator record using showtrans, + e.g. showtrans /dev/hd0 + <sjbalaji> Is there something like a man page for translators ? Like how to + work with them or to figure out what services are offered by them ? + <teythoon> well, there is --help + <teythoon> also, go to /dev and /servers and look around using showtrans or + fsysopts + <sjbalaji> teythoon: What is the difference between a nodes active and + passive translator ? + <teythoon> a passive translator record is stored in the file system for the + node + <teythoon> if the node is accessed, and no translator is currently running, + it is started on demand + <teythoon> we call a running translator an active one + <sjbalaji> So the hello translator in the example is a passive one ? + <teythoon> if you used settrans foo /hurd/hello, a node foo is created with + an passive translator record + <teythoon> if you used settrans -a foo /hurd/hello, the translator is + started immediately + <sjbalaji> teythoon: What do you mean by a passive translator record ? + <teythoon> sjbalaji: it's an argv-vector encoded in the filesystem + (currently, only ext2 supports this) + <teythoon> in ext2, it is stored in a block and a os-specific field in the + inode points to that block + <sjbalaji> teythoon: I can't understand the logic behind that :( + <teythoon> this way, the servers are started on demand + <sjbalaji> But once they are invoked they are always online after that. + <teythoon> yes + <sjbalaji> I thought that the server goes down once its used + <gnu_srs> teythoon: shouldn't the passive ones time out if unused? + <teythoon> yes, that's how it was intented to be, but that has been + patched-out in debian/hurd + <gnu_srs> reason? + <teythoon> i don't know the details, but there is a race condition + +(`libports_stability.patch`.) + + +# IRC, freenode, #hurd, 2014-01-31 + + <sjbalaji> How can I see the complete control flow when I run the hello + translator example ? + + +# IRC, freenode, #archhurd, 2014-02-05 + + <CalimeroTeknik> plus I discussed quickly that idea with Richard Stallman + and he told me translators had a conception flaw that would forbid such a + system to be usable + + +## IRC, freenode, #archhurd, 2014-02-06 + + <antrik_> CalimeroTeknik: the "conceptal problem" rms told you about was + probably the simple issue that translators are always followed, even if + they are run by another user + <antrik> CalimeroTeknik: the conceptal problem is only in that the original + designers believed that would be safe, which it isn't. changing that + default policy (to be more like FUSE) wouldn't do much harm to the Hurd's + features, and it should be easy to do + <antrik> it's just nobody bothered so far, because it's not a big deal for + typical use cases + <antrik> rms isn't really in touch with Hurd development. he was made to + believe it was a fundamental issue by a former Hurd developer who got + carried away; and he didn't know enough to realise that it's really not a + big deal at all + + +# Candidates for Google Summer of Code [[community/gsoc/Project_Ideas]] + +## Extend `ls` et al. for Translators + +### IRC, freenode, #hurd, 2014-02-08 + + <youpi> heh + <youpi> I was wondering what that incoming/ directory was in my home + <youpi> ls gave me hundreds of packages + <youpi> then I remembered I had /hurd/httpfs http://incoming.debian.org/ on + it :) + <cluck> if only there were an easy and automated way to make ls and file + managers (like dired!) aware of links, mounts and translators :) + <youpi> cluck: what do you mean by "awaree"? + <cluck> someting like: lrwxrwxrwx 1 foo foo 31 Aug 21 18:01 + my_translator-23.0 -> ../some/fakefs /some_parameters* + <cluck> (yes, i realize it goes against some security practices but maybe + there could be a distinction like with soft/hard links that made it + opaque for some use cases) + + +## Passive Translators + +### IRC, freenode, #hurd, 2014-02-12 + + <braunr> well don't expect rsync to save passive translator records .. + <braunr> i recommend you save either the entire disk image or the partition + <gg0> should i expect it from tar/cp ? + <braunr> no + <braunr> i'm not even sure dumpe2fs does it + <braunr> the only reliable way is to save the block device + <azeem> might be a worthwhile GSOC + <azeem> "implement Hurd specific features in GNU utilities" + <azeem> there were some patches floating around for some things in the past + IIRC + <antrik> azeem: the plan for supporting Hurd features in FS utilities was + exposing them as xattrs, like Roland's Linux patch did... cascardos once + did some work on this, but don't remember how far he got + +[[community/gsoc/project_ideas/xattr]]. + + <antrik> you are right though that it would make for a good GSoC project... + <antrik> of course, *some* utilities would still benefit from explicit Hurd + support -- most notably ls + <azeem> IIRC there were also ls patches at one point + <antrik> can't recall that... but maybe it was befor my time ;-) diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index cfd09502..ba849cca 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013, 2014 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 @@ -214,6 +214,334 @@ That would be a nice improvement, but only after writeback throttling is impleme <teythoon> tschwinge: well, thanks anyway ;) +## IRC, freenode, #hurd, 2014-02-11 + + <gg0> task with pid 5 deallocating an invalid port 4622, most probably a + bug. + <gg0> ext2fs + <teythoon> yes, i've seen this + <teythoon> e.g. when a passive translator starts + <teythoon> i guess it is in libfshelp/translator-list.c + + +## Inode Sizes, Fragment and Block Sizes + +### IRC, freenode, #hurd, 2014-02-12 + + <gg0> this might be interesting and could make people not to fsck hurd + filesystem on linux: + <gg0> start ext2fs: ext2fs: device:hd0s1 + <braunr> ? + <gg0> : panic: get_hypermetadata: inode size 256 isn't supported + <gg0> (wait, also a bad typist) + <braunr> well, if the file system was created from the hurd, or with -o + hurd, as it ought to be, you wouldn't have this problem + <gg0> oh, good to know, especially before restoring :p + <braunr> i suspect your mkfs command to have created an ext4 fs + <gg0> nope mkfs.ext2 + <braunr> hm ok, so it seems to create 256 size inodes by default there + <gg0> i guess -o hurd would set some os-specific properties + <braunr> it merely enforces a few restrictions + <gg0> some predefined defaults + <braunr> fragments and blocks are 4k + <braunr> and apparently inodes are 128 bytes + <gg0> because it can't support bigger values? is it worth working on remove + such restrictions? + <braunr> probably not so far + <braunr> certainly not the fragment/block size restriction + <braunr> it matches the page size + <braunr> larger inode sizes could be supported if they're dependencies for + other worthwhile features such as those someone would add in an ext4 + translator + + +## Linux' `CONFIG_EXT4_USE_FOR_EXT23` + +### IRC, freenode, #hurd, 2014-02-12 + + <gg0> why the hell i have thousands of Inode 839, i_blocks is 248, should + be 256. Fix<y>? yes + <gg0> in all cases i_blocks should be +8 + <gg0> and /dev/sda1: (There are 245635 inodes containing multiply-claimed + blocks.) + <gnu_srs1> 10:50:08< gg0> start ext2fs: Hurd server bootstrap: + ext2fs[device:hd0s1] exec + <gnu_srs1> That's exactly where my image boot hangs! + <gg0> start ext2fs: Hurd server bootstrap: ext2fs[gunzip:device:rd0] exec + <AliciaC> gnu_srs1: you might want to check that linux isn't using the ext4 + module to handle ext2 and ext3 filesystems + <AliciaC> gnu_srs1: as I understand it the idea is that the ext4 module + treats them as ext2/ext3 filesystems, just avoiding code duplication from + having three separate modules for related filesystems, so it shouldn't + change it from ext2 at all, but it does do something strange with it + <AliciaC> but I'm not sure if that's the case or if it's converting it to + ext4. last I heard Hurd doesn't support anything beyond ext2 + <gnu_srs1> AliciaC: I did use ext2 when mounting from Linux: mount -t ext2 + /dev/loop0 /mnt + <gnu_srs1> and when not mounted: e2fsck /dev/loop0 + <AliciaC> gnu_srs1: I'd check the kernel config to be sure, + CONFIG_EXT4_USE_FOR_EXT23 must be disabled + <braunr> you can use the ext4 driver for ext2 + <braunr> that's not a problem here + <braunr> the problem happens long before, when the file system gets + corrupted + <braunr> you must understand why + <AliciaC> I have done some testing on this, mounting a Hurd ext2 filesystem + with the ext4 module broke it for me, an easily repeated issue + <AliciaC> mounting Debian's ext2 image and unmounting it with ext4 broke + it, resulting precisely in the kind of hang ups mentioned by gnu_srs1 and + gg0 + <braunr> interesting + <AliciaC> that's with a clean image with nothing corrupting it before hand, + tested to be working as well + <braunr> ok so the ext4 driver must ignore hurd specific stuff + <braunr> that's strange because i recall using it to perform small repairs + on darnassus and never had any issue + <braunr> even on the root file syste + <braunr> but my repairs were very quick and targetted + <AliciaC> different linux versions maybe + <AliciaC> when I was testing it I didn't even need to do anything in the + filesystem to trigger the issue, just mount and unmount + <gnu_srs1> I repaired filesystems before like this, has something happened + with later versions of Linux? + <gnu_srs1> One of my boxes is ext3 (probably worked before) another ext4 + (the one breaking things, but worked before) + <gnu_srs1> ext3 and ext4 box: CONFIG_EXT4_USE_FOR_EXT23=y same kernel + 3.12-1.amd64 + <gnu_srs1> what about mounting with bs=4096 (used by hurd) + <braunr> -t ext2 should work fine + <braunr> just don't use the ext4 driver if in doubt + <gg0> no difference between specifying -t or not, in both cases EXT4-fs + (sda1): mounting ext2 file system using the ext4 subsystem + <braunr> hmm + <braunr> you're screwed then ; + <braunr> ;p + <braunr> or maybe -t ext3 .. :) + <braunr> although i suspect ext4 would be used then too + <gg0> linux-image-3.2.0-4-amd64: + /lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko + <gg0> wheezy still has it. then something between 3.2.0 and 3.13(?) removed + it + <braunr> check the config file + <gg0> i mean ext2 module + <braunr> check if the config file enables it + <gnu_srs1> It's not: # CONFIG_EXT2_FS is not set + <gg0> 14:42 < gg0> wheezy still has it. then something between 3.2.0 and + 3.13(?) removed it + <braunr> how about retrying what you did without ever mounting from linux ? + <braunr> gg0: it wasn't clear enough that you meant removed from + configuration + <braunr> (for example, it could have been blacklisted) + <gg0> or present not as a module + <braunr> maybe yes, although it's unusual to see generic kernels embedding + file systems these days + <AliciaC> the CONFIG_EXT4_USE_FOR_EXT23 option isn't available if either + ext2 or ext3 are enabled though, even just as loadable modules + <gnu_srs1> The ext2 and ext3 modules were there in 3.10-3, not in 3.12-1 + <gnu_srs1> (14:48:59) <srs>: It's not: # CONFIG_EXT2_FS is not set -- + 3.12-1 + <gg0> https://bugs.debian.org/731072 + * gg0 rsync'ing back to new fs with 3.10 kernel + <gnu_srs1> seems like this bug was archived without being closed?? + <gg0> someone should produce a testcase and file another one btw + <gnu_srs1> but that bug was for files systems up to 4MB, not 4GB? + <gg0> i pasted it just because submitter talks about config option in + question and when was enabled + <gg0> don't we want to thank AliciaC who pointed it out and who could + precisely file a bug? :) + <gg0> filed http://bugs.debian.org/738758 + <braunr> gg0: thanks + <braunr> AliciaC: and thanks too + + +### IRC, freenode, #hurd, 2014-02-13 + + <gnu_srs> gg0: Did you create and test with an ext2 Linux image too on + 3.10/3.12? + <gnu_srs> here is a diff: http://paste.debian.net/81837/ + <gnu_srs> visible differences: Filesystem features:filetype (linux only) + and Free inodes:1268(hurd) / 1269(linux) + <AliciaC> between one created with -o Hurd and one created with -o Linux + (or no -o)? + <gnu_srs> AliciaC: -o Hurd and -b 4096 (no -o) + <AliciaC> I wonder if that would show any interesting difference between an + untouched -o Hurd ext2 image and a copy of it that has been mounted with + the ext4 module + <gnu_srs> AliciaC: here: http://paste.debian.net/81857/ + <gnu_srs> there is a difference of one in the number of free inodes! + <gnu_srs> cf the number of free inodes for linux + <AliciaC> gnu_srs: thanks :) though I don't know what to make of that, I + guess just adding an inode shouldn't break anything + <AliciaC> wait, no, removing an inode? + <AliciaC> bleh, too tired, read it wrong + <gnu_srs> this line should read:(11:37:48) srs: visible differences: + Filesystem features:filetype (linux only) and Free inodes:1268(linux) / + 1269(hurd) + <gnu_srs> There are differences in ext2.h and ext4.h in the Linux source + code wrt hurd1, hurd2 structs. + <gnu_srs> one change might be interesting: http://paste.debian.net/81864/ + <braunr> gnu_srs: probably not + <gnu_srs> If not, where to look? + <braunr> well, the first thing would be to create a (small) ext2 file + system, usable on the hurd, with a few files and directories + <braunr> save it + <braunr> mount it with the ext4 driver + <braunr> and make a binary comparison + <braunr> you could use a modified ext2fs translator to tell you exactly + what's wrong when loading the file system + <braunr> and then look at the corresponding code in the ext4 driver + <gnu_srs1> braunr: here is a binary diff of the unmounted and mounted e2fs + files: http://paste.debian.net/81896/ + <braunr> gnu_srs1: i'm not going to analyze it + <braunr> you are + <braunr> :p + <gnu_srs1> many of them can be removed: e.g. /mnt and bug000 + <braunr> ? + <gnu_srs1> many diff entries* + <braunr> but why ? + <braunr> you shouldn't have changed the content at all + <gnu_srs1> If I don't add a file, the fs is not corrupted + <gnu_srs1> this is with two vers small files created as in gg0s bug report + <gnu_srs1> very* + <braunr> ok + <braunr> i guess checking the source code first and the binary diffs next + is easier + <gnu_srs1> OK, I have to find out how the ext2fs files are organized. + <gnu_srs1> I.e. reading mke2fs source code + <braunr> no + <braunr> read the ext4 driver + <braunr> how a directory entry is created + <braunr> how a directory is saved back on the block device + <braunr> how any potential conversion could be triggered + <gnu_srs1> k, will do + <braunr> read about the ext2fs format if doing that first doesn't help + <braunr> learning a file system is complicated and long + <gnu_srs1> What is the inode size for Hurd/Linux? + <braunr> probably 128 + <gnu_srs1> same for both? + <braunr> what is "Hurd/Linux" ? + <gnu_srs1> on Hurd / on Linux + <braunr> 128 on hurd, variable on linux + <braunr> 128-512 i'd say + <gnu_srs1> ext2 on linux + <gnu_srs1> found it from dumpe2fs: 128 for both + <braunr> no, it can vary on linux + <braunr> although once a file system is built, the inode size cannot be + changed + <gnu_srs1> k, the file created with mke2fs has 128 + + +## `ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion 'block' failed.` + +### IRC, freenode, #hurd, 2014-02-19 + + <pere> "ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion + 'block' failed." in the console. + +[[user/Maksym_Planeta]] also has hit that one. + + <braunr> wow oO + <braunr> using debian hurd right ? + <pere> power cycling. + <pere> yes. + <braunr> with hurd 1:0.5.git20140203-1 and glibc 2.17-98~1 ? + <pere> braunr: not sure how to check. + <braunr> pere: dpkg -l | grep .. i suppose + <pere> gah, autofsck do not work.. :( + <braunr> it does :( + <braunr> unstable is easy to mess it seems + <pere> had to run fsck -y / manually... + <braunr> i suspect you were using a corrupted file system at mount time + <braunr> ah that + <braunr> yes it is sometimes needed + <braunr> but ext2 is reliable enough that only temporary files get their + way into lost+found + <braunr> temporary/recently created + <braunr> the crash you had, on the other hand, looks more serious + <braunr> it seems like you mounted a corrupted file system + <pere> could be. + <pere> hurd v1:0.5.git20140203-1 and libc0.3 v2.17-98~1, it seem. + <braunr> good + <braunr> you shouldn't have such problems then, i suspect a mess up on your + part + <braunr> but you're not the only one to have had weird file systems + problems lately + <pere> hah. I blame the hurd. :P + <braunr> heh :) + <pere> gah, another crash. :( + <braunr> Oo + <braunr> same assertion ? + <pere> same place, or almost the same place. + <pere> yes. + <braunr> hm + <pere> same crash. :( + <braunr> what kind of machine do you run the hurd on ? + <pere> kvm + <braunr> how much memory ? + <pere> 1G + <braunr> did you see if the system was swapping ? + <pere> no idea. + <braunr> i suggest always running top/htop on the hurd ;p + <braunr> and monitor memory usage closely + <gg0> unless pere lately mounted/fsck'ed fs in question with a recent linux + kernel, there should not be particular problems + <braunr> it definitely doesn't look like it was mounted by an ext4 driver, + no + <braunr> which means it's something else entirely and this is scary + <pere> I didn't. I fetched the prebuild image, upgraded it, switched it to + sysvinit and started working. + <braunr> sorry i can't be of more help about that + <braunr> ext2fs has been quite solid on my machines for a long time :( + <braunr> there are known assertions that trigger under some special + pressure, but that's not what you're having here + <braunr> pere: anything particular in fstab ? + <pere> nope, have not touched /etc/fstab. + <braunr> hm stupid question + <braunr> are you sure it's not full ? + <pere> nothing look full to me. + <pere> neither the disk nor the host file system. + + +### IRC, freenode, #hurd, 2014-02-20 + + <pere> braunr: do you remember my ext2fs crash from yesterday? I could + avoid it by interrupting the triggering build and running sync once in a + while. and it show up again if I do not sync in between. :) + <braunr> ? + <braunr> are you sure you're not swapping ? + <pere> I have no idea. still. :) + <braunr> again, i recommend you run top/htop and monitor that + <braunr> pere: is your patch needed to trigger the assertion ? + +[[open_issues/ti-rpc_then_nfs]]. + + <pere> braunr: well, without it, the package do not build, so yeah. :) + <braunr> ok + <pere> tested again, and is not swapping. 850MB free memory. + <braunr> ok + <braunr> so this might be a real file system bug + <braunr> let me see + <braunr> pere: libtirpc built fine here .. + <braunr> pere: do you have a separate /home partition ? + <braunr> or any separate file system for builds + <pere> braunr: nope, everything on / + <braunr> pere: i wouldn't recommend that + <braunr> there very probably are bugs in the file system code and using + separate partitions is a way to alleviate them + + +## `ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: Assertion `!diskfs_readonly' failed.` + +### IRC, freenode, #hurd, 2014-02-22 + + <gg0> login: init: notifying pfinet of shutdown...init: notifying tmpfs + none of shutdown...init: notifying tmpfs none of shutdown...init: + notifyi. + <gg0> ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: + Assertion `!diskfs_readonly' failed. + <gg0> In tight loop: hit ctl-alt-del to reboot + + # Documentation * <http://e2fsprogs.sourceforge.net/ext2.html> diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index 973fb938..ef5e8cbd 100644 --- a/hurd/translator/mtab/discussion.mdwn +++ b/hurd/translator/mtab/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2008, 2009, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -18,7 +18,7 @@ mounted file systems. This also means that commands like `df` can only work on explicitly specified mountpoints, instead of displaying the usual listing. One possible solution to this would be for the translator startup mechanism to -update the `mtab` on any `mount`/`unmount`, like in traditional systems. +update the `mtab` on any `mount`/`umount`, like in traditional systems. However, there are some problems with this approach. Most notably: what to do with passive translators, i.e., translators that are not presently running, but set up to be started automatically whenever the node is accessed? Probably @@ -1110,6 +1110,12 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. e.g. http://darnassus.sceen.net/gitweb/?p=teythoon/hurd.git;a=shortlog;h=refs/heads/feature-mtab-translator-v3-wip +### IRC, freenode, #hurd, 2013-11-20 + + <braunr> teythoon: ah thanks for making mtab multithreaded :) + <braunr> i forgot about that + + ## [[open_issues/libnetfs_passive_translators]] @@ -2587,6 +2593,548 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <teythoon> yes +### IRC, freenode, #hurd, 2013-11-06 + + <braunr> by the way, did you fix mtab for passive translators ? + <braunr> or make any progress ? + <teythoon> I just cleaned up the patch series + <braunr> ah good + <teythoon> I'm still trying to decide whether I leak any ports + + +### IRC, freenode, #hurd, 2013-11-15 + + <teythoon> btw, I haven't forgotten about the passive translator not + showing up in /proc/mounts + <teythoon> I have a patch series, the first patch seems fine, but if I + build hurd packages with the other two (those that actually hook into + dir-lookup), strange things happen + <teythoon> on the first boot, everything is fine, passive translators + showing up in /proc/mounts, nice + <teythoon> but when I reboot, the system kind-of comes back, but something + is very wrong with many (passive?) translators + <teythoon> the system never recovers, I have no idea whats going on there + <braunr> ok + <braunr> push that work in a branch somewhere for review please + <teythoon> right, thanks + <teythoon> braunr: + http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators + + +### IRC, freenode, #hurd, 2014-01-04 + + <youpi> teythoon: did you eventually get any idea about why /proc/mounts is + missing mounts? + <youpi> e.g. I have /boot as a separate partition, it doesn't show up + + +### IRC, freenode, #hurd, 2014-01-05 + + <teythoon> youpi: yes, passive translators are not currently handled + <teythoon> youpi: i have patches for that, but they produce weird results, + braunr promised to take a look + <braunr> teythoon: hum + <teythoon> ^^ + <braunr> i thought they were pending review + <braunr> ! + <braunr> where are they again ? + <teythoon> + http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators + <braunr> ok + <teythoon> they are reasonably straight-forward + <teythoon> but cause this funny issue, after the first reboot with the + patched hurd everything is fine + <teythoon> after the second reboot, everything is weird and broken badly + <braunr> right + <braunr> interesting :) + + +### IRC, freenode, #hurd, 2014-01-06 + + <braunr> teythoon: is it normal that, if ext2fs is started as an active + translator for /home, and then for another directory inside my home, mtab + only reports / and /home and not this third file system ? + <braunr> (with the hurd master version) + <braunr> (the translator for /home is run by root, but the one inside my + home is started with my uid) + <braunr> (and every component on the path is readable/crossable) + + +### IRC, freenode, #hurd, 2014-01-07 + + <teythoon_> braunr: well yes, the mtab tool/translator does not follow + translators bound to nodes not owned by root + <teythoon> braunr: try /hurd/mtab --insecure /home + <braunr> ok + <braunr> good thinking + + <teythoon> braunr: did you encounter any problems after the second reboot ? + <braunr> i'm not yet there + <braunr> work still making me busy + <braunr> and i'm trying to isolate the problem first + <braunr> that is, restrict tests to a single leaf translator + <teythoon> you reproduced the weirdness ? + <braunr> teythoon: attempting + <braunr> teythoon: first i'm trying to check a few things + <braunr> teythoon: i'm running my leaf translator as root now + <braunr> active + <braunr> and i still don't see it :/ + <braunr> one of the components in the path is not own by root + <braunr> is that a problem ? + <teythoon> no, but maybe the mtab translator should check for that... + <braunr> does it check for the node ownership or the process rights ? + <braunr> credentials, rather + <teythoon> node ownership + <braunr> ah, ok + <braunr> ok i see it now + <braunr> oh, also, it looks like settrans -g on an active translator + doesn't work, i get ebusy all the time :/ + <teythoon> oh ? + <teythoon> that could explain the fs corruption i saw + <teythoon> did i break that ? + <braunr> i don't know + <braunr> maybe + <braunr> i think it was possible in the past + + <braunr> teythoon: when isolated, your code works fine + <braunr> i'll try applying it globally + <braunr> btw, how did you do that ? + <braunr> through debian packages ? + <teythoon> i'm trying to get to the point, but i'm still not there + <teythoon> with our uber-buildbot setup i picture myself pushing to a git + repo, wait a little and get the packages from my deb repo... + <teythoon> for now, i have my hurdtest tool that i used during gsoc + <teythoon> with that i can just drop files into a directory and have that + overlayed ontop of my test image + <braunr> hum + <braunr> so you replaced the lib*fs libraries directly ? + <braunr> and the static rootfs ? + <teythoon> yes + * teythoon checks + <teythoon> hm, maybe i just missed a file, not sure anymore + + <braunr> teythoon: with the new libraries, df -h doesn't see passive + translators :/ + <teythoon> braunr: see /proc/mounts please + <braunr> same + <teythoon> or /hurd/mtab / + <teythoon> weird + <braunr> no :/ + <teythoon> b/c when i developed it, i used a test suite to check that every + combination of tmpfs/ext2fs active/passive and every way to get rid of + any translator produced the desired results + <teythoon> i'll look into this + <braunr> teythoon: when i remove the active translator i set on /home, i + get + <braunr> /dev/hd0s1 8.1G 2.0G 5.8G 26% /home + <braunr> hd0s1 being used for / :/ + <braunr> this does need reviewing + <teythoon> this is how i expect the system to react currently + <braunr> oh + <teythoon> w/o these patches + <braunr> hm ok + <braunr> well + <braunr> i'm currently using them + <teythoon> including the root fs ? + <braunr> yes + <teythoon> hmpf + <braunr> i have to mention that i merged master into it + <teythoon> i did the same + <teythoon> currently compiling... + <braunr> i only changed libdiskfs, libnetfs and libfshelp + <braunr> is there something else that should be changed ? + <braunr> (i.e. because of inlining ?) + <braunr> i guess i should rebuild a hurd package just to be sure + <kilobug> braunr: isn't the translator for / statically linked ? if so it + needs to be rebuilt (sorry if I'm saying silly things by popping out of + nowhere) + <braunr> yes i took care of that + + <braunr> teythoon: i've built a hurd package with the three patches and i + don't see passive translators at all + <teythoon> :/ + <braunr> well + <braunr> actually i see a lot of the + <braunr> them + <braunr> just not /home + + <teythoon> braunr: please see + /home/teythoon/build/hurd-upstream/test.{bash,log} + <teythoon> the latter is a log i just created on darnassus + <teythoon> it shows no failures + <teythoon> do you have another translator that is started from a passive + translator record ? + <teythoon> besides /home, if so, does that show up ? + <braunr> well, as i just said, i can actually see many of them + <teythoon> weird + <braunr> http://darnassus.sceen.net/~rbraun/mounts + <braunr> hm + <braunr> let's try without --sync= + <braunr> ah, now i can see it + <teythoon> can you give me the command line you used before + <teythoon> for the /home translator + <braunr> /hurd/ext2fs --sync=30 /dev/hd0s6 + <braunr> but hm + <braunr> i can only see /home when the passive translator is started + <braunr> is that intentional ? + <teythoon> yes + <braunr> ok + <teythoon> and it doesn't work with --sync=30 o_O + <braunr> so, actually, mtab doesn't report passive translators + <teythoon> no + <braunr> it reports active ones only, whether they're started manually or + from passive translators + <teythoon> yes + <braunr> ok + <braunr> that's good enough + <braunr> reporting passive translators wouldprobably require a complete + scan + <teythoon> yes, that was deemed not feasible + <braunr> right + <braunr> i can't reproduce any weirdness + <teythoon> good + <braunr> it seems to just work well + <braunr> except this option parsing problem + <teythoon> thanks for looking into this + <teythoon> yeah + <braunr> sur + <braunr> e + <braunr> thanks for reminding me :) + <teythoon> the actual fix is implementing fsys_get_source + <braunr> i forgot that "pending review" was my review here he + <teythoon> which should actually be file_get_source + + <braunr> teythoon: why does mtab report errors for /proc/swaps and + /xconsole ? + <teythoon> not sure + + <teythoon> btw, i build hurd packages with my patches and it reliably + wreaks havoc on my test vms ... + <braunr> now that's really weird + <braunr> are you certain everything has been cleaned since your manual + replacement of the libraries ? + <teythoon> yes, i use mainly throwaway-vms for such experiments + <braunr> ok + <teythoon> did you include the debian patches ? + <braunr> yes + <teythoon> so did i + <braunr> i based my work on my own packages + <braunr> with thread destruction + <braunr> i'll redo it from the sid ones + <braunr> but before, i guess i should share mine with you + <braunr> so you can test them in your vms + <braunr> we may simply have different configurations + <teythoon> yes + <braunr> something we might have missed just like the --sync parameter + + +### IRC, freenode, #hurd, 2014-01-08 + + <braunr> teythoon: hello + <braunr> see http://darnassus.sceen.net/~rbraun/teythoon/ for the custom + hurd packages + <braunr> they need thread destruction so get the latest gnumach package + from unstable, and the libc packages from my repository first + + +### IRC, freenode, #hurd, 2014-01-09 + + <teythoon> braunr: your packages indeed seem to work + <teythoon> and with mine i encounter a different problem, the proc server + crashes *very* early + <teythoon> this is w/o a rebuilt libc + <teythoon> different as in not the weird one i remember having back when i + wrote those patches + <braunr> hum + <braunr> you're using all my glibc/hurd packages right ? + <teythoon> your packages work fine + <braunr> i wonder if your bug is caused by + 2c9422595f41635e2f4f7ef1afb7eece9001feae + <teythoon> mine don't + <braunr> (or rather, not having it) + <braunr> look at the patches i've added + <braunr> it's included, and i remember i really needed it + <braunr> althouhg it was just about a leak + <braunr> hm + <braunr> i don't know :/ + <braunr> but i strongly suspect your patches are ok + <braunr> and something else is wrong + <teythoon> why would my packages miss that patch ? + <braunr> hum + <braunr> are you testing with your packages built from upstream sources ? + <teythoon> always + <braunr> upstream hurd against debian glibc ? + <teythoon> yes + <braunr> check the patches again + <teythoon> what patches ? + <braunr> the debian ones that you don't include + <braunr> another thing you can do is + <teythoon> err + <braunr> get the latest debian hurd package + <braunr> add your patch only + <braunr> rebuild + <teythoon> i use hurd upstream + all the debian stuff + <braunr> that's weird + <braunr> but hurd upstream has received quite a lot of patches + <braunr> please try from debian hurd + your patch only + + <teythoon> braunr: i'm afraid it might be your patch 3a3fcc81 that breaks + proc + +[[libpthread_set_stack_size]]. + + <braunr> teythoon: but anyway, it does look like your patches are actually + fine + <teythoon> yes + <braunr> i'll install my packages on darnassus and test a bit more + <teythoon> there is an issue however + <braunr> ah + <teythoon> grep sd2s1 /proc/mounts + <teythoon> /dev/sd2s1 /dev/sd2s1 /hurd/storeio writable 0 0 + <teythoon> that makes fsck think that /dev/sd2s1 is mounted + <braunr> hmpf + <teythoon> which makes debians fsck magic (when using sysvinit) drop to a + root shell at boot time + <braunr> why does it report a mount point ? + <braunr> or even a device + <braunr> why not none /dev/sd2s1 ? + <teythoon> b/c of the heuristic it uses + <teythoon> and i know, you told me it's a bad idea + <braunr> i did ? + <teythoon> probably + <braunr> hm + <braunr> we said so many things i don't remember + <braunr> but that doesn't look too hard to fix + <teythoon> well, i'll just have to make translators provide meaningful + get_source responses + <teythoon> and get rid of the heuristic + <braunr> ok + <teythoon> so if you use passive translators for the mounts, and not + /etc/fstab, you should be fine + <teythoon> my "traditional" hurd systems are + <braunr> teythoon: i'll wait a bit before deplying it on darnassus then + + +### IRC, freenode, #hurd, 2014-01-13 + + <braunr> teythoon: does your latest patch series take care of --sync ? + <teythoon> yeah, i finally got why the hurd would react strangely after an + reboot, it was umount --all removing vital passive translator records + <teythoon> i never had any issues with --sync + <braunr> ah, umount -a + <braunr> hm + <braunr> do you recall i did :) ? + <teythoon> umount -a was only run with the sysvinit scripts, that's why you + didn't see that issue, only me + <teythoon> yes, i do + <braunr> yes, i see + <teythoon> however, i'm also using --sync 30 on my fs + <braunr> ok so you couldn't reproduce that particular issue + <braunr> hum + <braunr> try --sync=30 + <teythoon> showtrans /media/scratch + <teythoon> /hurd/ext2fs --sync=30 /dev/sd1s1 + <teythoon> works fine + <braunr> now that's weird :) + <teythoon> then again, previously there was another bug + <braunr> but then the patches i've tested are not the complete series you + sent + <teythoon> in the dir lookup function, if a passive translator is started + <teythoon> say, if i first access /proc/foo, /proc/foo would be recorded, + not /proc + <teythoon> i fixed that yesterday + <braunr> ok + <teythoon> maybe it was b/c of that + <braunr> but hm + <braunr> why would /proc be recorded ? + <teythoon> now ? + <braunr> i mean, /proc should be recorded at /, and /foo at /proc + <braunr> right ? + <teythoon> yes + <braunr> and that wasn't the case ? + <teythoon> but what happened was that proc/foo was recorded as a child + translator for / + <braunr> ohh + <teythoon> yes + <braunr> i see + <braunr> well, i'm not sure it's that bug, since the translator involved + was on /home + <teythoon> same problem + <teythoon> it's unlikely that the translator was started b/c of a /home + lookup + <teythoon> much more likely that the first lookup is /home/someone + <braunr> yes + <braunr> but mtab correctly reported /home without --sync, and not when the + option was present + <braunr> and that part doesn't quite make sense to me + <teythoon> how did you trigger the startup + <teythoon> ? + <braunr> ssh i believe + <teythoon> hm + <teythoon> anyways, i could not reproduce this issue + <braunr> do you have packages somewhere i can test ? + <teythoon> yes + <braunr> oh and btw + <teythoon> http://darnassus.sceen.net/~teythoon/hurd-ci/ + <braunr> something you could do to deal with umount -a + <braunr> but i guess that's what you did already + <braunr> is to only shut the active translator down + <teythoon> + http://git.sceen.net/hurd/hurd.git/commitdiff/0033d20449b3bb558f2ea470983018db39b572aa + <teythoon> yeah, i thought about that + <teythoon> but i believe that is not the right hting to do + <braunr> yes i know but i'm not sure that's the right approach + <braunr> hm :) + <teythoon> b/c if on linux you do umount /foo && ls /foo, foo will be empty + <braunr> yours is probably more posix-friendly + <teythoon> if the passive translator lookup is left, /foo will be restarted + <braunr> ok + <teythoon> s/lookup/record/ + <braunr> that's one reason i'm not very fond of passive translators tbh + <teythoon> yep + <braunr> i'd reserve them as a user-oriented hurd-specific feature + <braunr> anything that must behave as mount/umount expects has to be active + anyway + <braunr> ok let's give a quick shot at your packages :) + + <braunr> teythoon: works fine :) + <braunr> mtab still reports console entries though + <braunr> is tha texpected ? + <teythoon> braunr: kind of + <teythoon> braunr: /bin/console is a netfs-based translator, probably for + multiplexing, dunno exactly + <braunr> i see + + +### IRC, freenode, #hurd, 2014-01-14 + + <youpi> teythoon: passive translators do work fine in mtab now, thanks :) + <braunr> indeed :) + + +### IRC, freenode, #hurd, 2014-02-11 + + <antrik> another topic: what's the rationale again behind umount removing + passive translators?... + <teythoon> antrik: umount is for compatibility with unixoid systems + <teythoon> consider umount /foo; ls /foo + <teythoon> if umount would leave the passive translator record on /foo, + /foo would be started again + <antrik> but mount never creates passive translators, right? + <antrik> so why would umount remove them? they are none of its business... + <teythoon> sure, you can see it this way + <teythoon> still, i like the way it is now, hence i implemented it this way + ;) + <youpi> teythoon: but then umount -a unmounts all passive translators + <youpi> include ~joe/http:/ + <youpi> s/include/including/ + <youpi> I tend to agree with antrik + <teythoon> i won't oppose a change of course + <teythoon> and yes, we have seen problems b/c of that. otoh those can be + fixed (and they are, i just sent a patch fixing that) + <youpi> teythoon: well, it's not only about http:, joe user may want to + mount its own iso image, or whatever + <teythoon> thats true + <teythoon> no + <teythoon> it's not + <teythoon> /proc/mounts does not contain translators bound to nodes that do + not belong to root + <teythoon> but sure, we can change umount + <braunr> i agree + <braunr> active translators can be viewed as unix mounts + <braunr> passive translators are an entirely hurdish feature + <braunr> but then, servers such as pflocal and pfinet shouldn't probably + not be passive translators + <antrik> braunr: shouldn't not? what are you trying to say? :-) + <braunr> woops + <braunr> i'm not trying to make this unconfusingly clearer + <braunr> :p + <braunr> pflocal and pfinet should probably be active translators + <antrik> why? + <braunr> hum wait + <braunr> i had a reason weeks ago + <braunr> but now it looks the opposite is better actually :p + <braunr> so that they don't appear in mounts + <braunr> but aiui, there is another property that is tested to make + translators appear in mounts + <antrik> hm... I know this question has been discussed when first talking + about an mtab translator years ago... but don't remember whether there + was any conclusion + <antrik> I think one of the ideas was that translators would opt in for + being considered as mounts... + <braunr> it makes sense to only have file systems in mounts anyway + <antrik> instead of going by the translator type, another option might be + ignoring anything that is backed by a passive translator?... + <antrik> or have a startup option (perhaps with some "smart" defaults) to + request a translator to manifest as a mount or not + <antrik> so many ideas... ;-) + + +## coreutils' `df` + +### IRC, freenode, #hurd, 2014-01-24 + + <braunr> gnu_srs: "df: Warning: cannot read table of mounted file systems: + No such file or directory" + <braunr> you should be able to fix that easily + + +### IRC, OFTC, #debian-hurd, 2014-02-03 + + <pere> /run/mtab also seem to be missing. df do not work. + <teythoon> that's a libc bug + + +### IRC, OFTC, #debian-hurd, 2014-02-05 + + <gg0> i had to ln -s /proc/mounts /var/run/mtab to make df work, what's the + proper fix? + <gg0> (here sysvinit+openrc) + <youpi> gg0: the proper fix for df is to fix the coreutils build + + <pere> I checked the mtab problem, and /etc/hurd/runsystem.gnu via + /etc/hurd/rc fixes the symlink, while runsystem.sysv do not. I suspect + /etc/init.d/checkroot.sh should fix the symlink too. + <youpi> well, atm df looks at /var/run/mtab instead of /etc/mtab only + because it hasn't been rebuilt against a recent glibc, that's all + <youpi> but we can brownpaperbag fix it, yes + <pere> right. so perhaps that is the bug to fix? + <youpi> yes, it is + <youpi> it depends on coreutils actually building + <teythoon> youpi: i thought the proper way to fix the /var/run/mtab issue + is to patch the libc ? + <youpi> it is + <teythoon> the libc defines some macro, on linux it expands to /etc/mtab, + on hurd to /var/run/mtab + <youpi> but you need to rebuild coreutils to get a fixed df + <teythoon> ok, right + <pere> should it be /var/run/mtab or /etc/mtab on hurd? the former seem + more correct, but /run/mtab give more sense given that it should be + available also before /var/ is mounted. + <youpi> to be honest, I don't really care + <youpi> and I thus tend to agree on sticking with what linux does + <youpi> to avoid issues + <youpi> as in: keep debian working mostly the same on all kernels, to avoid + issue + <youpi> s + <pere> well, linux really should move that file away from /etc/ too. :) + <youpi> pere: ok, but let's move at the same time + <youpi> rather than hitting bugs ourselves + <pere> perhaps df should use /proc/mount instead, and get rid of the + problem completely... + <youpi> that can be a way, too + + <pere> I believe <URL: http://bugs.debian.org/737759 > is a good fix for + the mtab problem. + + <rleigh> WRT /etc/mtab the main reason for keeping it is solely for + compatibility; there's no reason not to use /proc/mounts directly (or + /run/mtab if we want a kernel-agnostic location). Whether it's worth + doing something like that is debatable. + <rleigh> The main issue with doing stuff like this nowadays is that you get + shouted at by all the systemd people for making changes... + + ## Memory Leak in `translator_ihash_cleanup` ### IRC, freenode, #hurd, 2013-10-04 diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn index 3e66c870..7b2f07aa 100644 --- a/hurd/translator/pfinet/implementation.mdwn +++ b/hurd/translator/pfinet/implementation.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2000, 2008, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2000, 2008, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -166,6 +166,14 @@ In context of the item on [[/contributing]]. <braunr> rekado: development pace on the hurd has always been slow, no need to apologize + +### IRC, freenode, #hurd, 2014-02-12 + + <braunr> youpi: btw, the patch you finally decided to write yourself making + pfinet continue on driver failure is as expected quite handy :) + <youpi> :) + + ## MAC Addresses [[!tag open_issue_hurd]] @@ -192,6 +200,82 @@ In context of the item on [[/contributing]]. <youpi> it's not plugged inside pfinet anyway +## IRC, freenode, #hurd, 2014-01-15 + + <braunr> 2014-01-14 23:06:38 IPv4 socket creation failed: Computer bought + the farm + <braunr> :O + <youpi> hum :) + <youpi> perhaps related with your change for "lo" performance? + <braunr> unlikely + <youpi> I don't see what would have changed in pfinet otherwise + <braunr> mig generated code if i'm right + <braunr> lib*fs + <braunr> libfshelp + <braunr> looks plenty enough + <braunr> teythoon's output has been quite high, it's not so suprising to + spot such integration issues + + +### IRC, freenode, #hurd, 2014-01-16 + + <braunr> teythoon: so, did you see we have bugs on the latest hurd packages + :) + <braunr> for some reason, exim4 starts nicely on darnassus, but not on + another test vm + <braunr> and there is a "deallocate invalid name" error at boot time + <braunr> it's also present with your packages + <teythoon> yes + + <braunr> not being able to start exim4 and other servers on some machines, + apparently randomly, is a bit frightening to me + <braunr> as the message says, "most probably a bug" + <teythoon> yes + <braunr> so we have to get rid of it as soon as possible so we can get to + the more interesting stuff + <teythoon> but there is no way to attribute this message to a process + <braunr> well, for those at boot time, there is + <teythoon> ? + <braunr> if i disable exim, i don't get it :p + <teythoon> oh ? + <braunr> but again, it doesn't occur on all machines + <braunr> and that part is the one i don't like at all + <teythoon> still, is it in exim, pfinet, pflocal, ... ? + <teythoon> no way to answer that + <braunr> ah right sorry + <braunr> it's probably pfinet, since exim says computer bought the farm on + a socket + <braunr> pflocal had its same pid + <teythoon> ok + <braunr> and after an upgrade, i don't reproduce that + <braunr> good, in a way + <braunr> there still is the one, after auth + <teythoon> yes + <teythoon> i'm seeing that too + <braunr> (as in "exec init proc auth" + <braunr> shouldn't be too hard to fix + <braunr> i'll settle on this one after i'm done with libps + <gnu_srs> (15:21:34) braunr: it's probably pfinet, since exim says computer + bought the farm on a socket: + <gnu_srs> remember my having problems with removing a socket file, maybe + related, probably not pfinet then? + <braunr> gnu_srs: unlikely + <braunr> that pfinet bug may have been completely transient + <braunr> fixed by upgrading packages + <gnu_srs> braunr: k! + + <braunr> and exim4 keeps crashing on my hurd instance at home + <braunr> (pfinet actually) + <braunr> uh, ok, a stupid typo .. + <braunr> teythoon: --natmask in the /servers/socket/2 node, but correct + options in the 26 one .... :) + + +### IRC, freenode, #hurd, 2014-01-17 + + <teythoon> braunr: *phew* + + # Reimplementation, [[!GNU_Savannah_task 5469]] ## [[community/gsoc/project_ideas/tcp_ip_stack]] @@ -205,6 +289,10 @@ In context of the item on [[/contributing]]. <braunr> hm, why not <braunr> i would still prefer using code from netbsd <braunr> especially now with the rump kernel project making it even easier + +[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel +and Rump Kernels*. + <youpi> well, whatever is easy to maintain up to date actually <braunr> netbsd's focus on general portability normally makes it easy to maintain @@ -225,3 +313,93 @@ In context of the item on [[/contributing]]. Cloudius OSv apparently have isolated/re-used a BSD networking stack, <http://www.osv.io/>, <https://github.com/cloudius-systems/osv>. + + +## IRC, freenode, #hurd, 2014-02-06 + + <akshay1994> Hello Everyone! Just set up my Hurd system. I need some help + now, in selecting a project on which i can work, and delving further into + this. + <braunr> akshay1994: what are you interested in ? + <akshay1994> I was going through the project ideas. Found TCP/IP Stack, and + CD Audio grabbing interesting. + <braunr> cd audio grabbing ? + <braunr> hm why not + <braunr> akshay1994: you have to understand that, when it come to drivers, + we prefer reusing existing implementations in contained servers than + rewriting ourselves + <braunr> the networking stack project would be very interesting, yes + <akshay1994> Yes. I was indeed reading about the network stack. + <akshay1994> So we need an easily modularise-able userspace stack, which we + can run as a server for now. + <akshay1994> And split into different protocol layers later. + <braunr> hum no + <braunr> we probably want to stick to the model we're currently using with + pfinet + <braunr> for network drivers, yes + <braunr> i strongly suspect we want the whole IPv4/IPv6 networking stack in + a single server + <braunr> and writing glue code so that it works on the hurd + <braunr> then, you may want to add hooks for firewall/qos/etc... + <braunr> (although i think qos should be embedded to) + <braunr> sjbalaji: i also suggest reusing the netbsd networking stack, + since netbsd is well known for its clean portable code, and it has a + rather large user base (compared to us or other less known projects) and + is well maintained + <braunr> the rump project might make porting even easier + +[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel +and Rump Kernels*. + + <akshay1994> okay! I was reading the project idea, where they mention that + a true hurdish stack will use a set of translator processes , each + implementing a different protocol layer + <braunr> a true hurdish stack would + <braunr> i strongly doubt we'll ever have the man power to write one + <braunr> i don't really see the point either to be honest :/ + <akshay1994> haha! + <braunr> but others have better vision than me for these things so i don't + know + <akshay1994> So, what are the problems we are facing with the current + pfinet implementation? + <braunr> it's old + <braunr> meaning it doesn't implement some features that may be important, + and has a few bugs due to lack of maintenance + <braunr> maintenance here being updating the code base with a newer + version, and we don't particularly want to continue grabbing code from + linux 2.2 :) + <akshay1994> I see. I was just skimming through google, about userspace + network stacks, but I think I might need to first understand how the + current one works and interacts with the system, before proceeding + further! + <braunr> yes + <braunr> the very idea of a userspace stack itself has little implications + <braunr> it basically means it doesn't run in system mode, and instead of + directly calling functions, it uses RPCs to communicate with other parts + of the system + + <akshay1994> braunr: I looked at the netBSD net-stack, and also how hurd + (and mach) work. I'm starting with the hacking guide. Seems a little + difficult :p + <akshay1994> But i feel, I'll get over it. Any tips? + <braunr> akshay1994: it's not straightforward + <akshay1994> I know. Browsing through pfinet gave me an idea, how complex a + thing I'm trying to deal with in first try :p + + +### IRC, freenode, #hurd, 2014-02-09 + + <antrik> braunr: the point of a hurdisch network stack is the same as a + hurdish block layer, and in fact anything hurdish: you can do things like + tunelling in a natural manner, rather than needing special loopback code + and complex control interfaces + <braunr> antrik: i don't see how something like the current pfinet would + prevent that + + +# IRC, freenode, #hurd, 2013-10-31 + + <braunr> looks like there is a deadlock in pfinet + <braunr> maybe triggered or caused by my thread destruction patch + +[[open_issues/libpthread/t/fix_have_kernel_resources]]. diff --git a/hurd/translator/pflocal.mdwn b/hurd/translator/pflocal.mdwn index fdcc39f1..6cb01e18 100644 --- a/hurd/translator/pflocal.mdwn +++ b/hurd/translator/pflocal.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2000, 2008, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2000, 2008, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -33,3 +33,37 @@ implementation). (maybe not so interesting case). <pinotree> pflocal does not support it <gnu_srs> Is that of interest at all? + + +## IRC, freenode, #hurd, 2014-01-14 + + <braunr> sudo -s eats 100 cpu :/ + <braunr> possibly because of pflocal + <braunr> only change on pflocal (notwithstanding the libraries) is + "pflocal: improve the demuxer functions" + <braunr> teythoon: why did you change the order of the function calls in + sock_demuxer ? + <youpi> for efficiency iirc + <braunr> yes, looks reasonable + + +### IRC, freenode, #hurd, 2014-01-16 + + <braunr> i suspect the "improve the demuxer functions" changes may have + hard-to-understand side effects + <teythoon> yes, mostly being faster + <braunr> ah, the latest sudo has been fixed + <braunr> haha :) + <teythoon> ^^ + <braunr> that one is easy to understand :) + <braunr> sudo was looping around calls to pflocal + <braunr> and exim crashed because of pfinet + <braunr> and those servers were only affected by these changes, other than + the library ones which don't seem to apply at all + <braunr> but with sudo being fixed, i'm not sure it's relevant any more + <teythoon> i'd say being faster could easily cause hard-to-understand side + effects + <braunr> ah, yes + <braunr> being faster isn't the side effect itself ;p + <braunr> nice, sudo was bugged on linux too, its behaviour matched its hurd + version perfectly diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn index 75bfb8fd..39840e99 100644 --- a/hurd/translator/proc.mdwn +++ b/hurd/translator/proc.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013, 2014 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 @@ -102,3 +103,68 @@ It is stated by `/hurd/init`. < braunr> teythoon: i agree with you on proc process-to-task mapping < braunr> that's something i intend to completely rework on propel < braunr> in a way similar to how pid namespaces work on linux + + +# PID "Races" + +## IRC, freenode, #hurd, 2014-01-26 + + <quotemstr> Does Hurd have anything that generally solves PID races? + <youpi> what kind of race are you thinking about? + <youpi> I'm not sure, but I guess keeping a reference to a task port will + prevent the proc server from recycling the corresponding pid + <quotemstr> Yep. + <quotemstr> How does the Hurd avoid the obvious denial-of-service attack + that results? + <youpi> well quotas would probably be enough + <youpi> that's not a new issue :) + <quotemstr> Fair enough. + <quotemstr> Returning to the POSIX-y world after a few year stint over in + NT-land, it's infuriating that it's still not possible to write a + reliable killall(1) under Linux or the BSDs. + <quotemstr> I'm glad Hurd solves the problem. :-) + <braunr> but it doesn't + <braunr> how can you write a reliable killall ? + <youpi> so keeping a reference to the task port is not enough? + <braunr> i'm not sure + <braunr> first i'd like quotemstr to clearly define the reliability problem + of killall + <quotemstr> braunr: The possibility that a PID might be used between the + time you decide to kill it and the time you actually kill it. + <braunr> well, it would have to wrap around for that + <quotemstr> braunr: So? It's possible. + <braunr> i guess that's what you refer to + <braunr> ok + <braunr> well yes, it's possible to easily create a routine that atomically + increases the number of references on a task/process when looking it up + <braunr> preventing its removal from the list of processes reported by the + proc server + <quotemstr> Like OpenProcess? :-) Would this reference count be + automatically decremented if the task owning the reference is killed? + <braunr> it would clearly not be a "posixy killall" then, but i suppose we + don't care about that at all + <braunr> no + <quotemstr> Oh. + <braunr> destroying an object doesn't remove its references + <quotemstr> So it's possible to leak the reference and prevent reuse of + that PID forever. + <braunr> hardly + <braunr> for that, killall would have to run a long time + <quotemstr> braunr: No, I'm talking about our hypothetical killall itself + being killed after taking out a reference on another process, but before + releasing it + <braunr> but a malicious killall could + <braunr> when a task is destroyed, its capability space is destroyed too + <braunr> removing all the references it previously had + <quotemstr> Ah, I see. + <braunr> the leaks we have occur in servers + <braunr> which sometimes act as clients to other servers + <braunr> and run forever + + +# Crashes due to rpctrace + +## IRC, freenode, #hurd, 2014-02-18 + + <braunr> something is wrong in the proc server + <braunr> rpctrace is often causing it to crash .. diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 018db7b2..8ac48a59 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012, 2013, 2014 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 @@ -348,6 +348,35 @@ Disadvantage is that every program using this needs to be patched. This is used in `[LLVM]/lib/Support/Unix/Path.inc`. +### IRC, OFTC, #debian-hurd, 2013-11-10 + + <mjt> Hello. Does hurd have /proc/self/exe equivalent, to "re-exec myself" + ? + <youpi> no, only argv[0] + <mjt> busybox uses /proc/self/exe by default to re-exec itself when running + one of its applets, or failing that, tries to find it in $PATH. I guess + it doesn't work on hurd... :) + <mjt> and argv0 is unreliable + <youpi> some discussion on the hurd wiki talks about using Dl_info DLInfo + <youpi> which contains DLInfo.dli_fname + <youpi> err, I mean, callling dladdr(&main, &DLInfo); + <youpi> this is kernel-agnostic, provided one uses glibc + <mjt> um. -ldl. nice for static linking + <mjt> gcc t.c -ldl -static + <mjt> ./a.out + <mjt> fname=AVA� �j + <mjt> bah :) + <mjt> (it just prints dli_fname) + <teythoon> :/ + <youpi> ah, yes, that won't work with static linking + <teythoon> fixing /proc/self is on my todo list, it shouldn't be too hard + <youpi> since in that case it's the exec server which sets the process up, + not dl.so + <teythoon> but we do not have the exe link either + <mjt> (the above test run was on linux not on hurd, fwiw_ + <mjt> ) + + # `/proc/[PID]/fd/` ## IRC, freenode, #hurd, 2012-04-24 @@ -502,6 +531,23 @@ Also used in `[GCC]/intl/relocatable.c`:`find_shared_library_fullname` for <camm`> thanks +## IRC, freenode, #hurd, 2014-02-22 + + <ignaker> i'm trying to implement proc/maps + <ignaker> actually I can't well evaluate complexity of tasks. However, I + appreciate your comments + <braunr> the complexity can be roughly estimated from the number of + components involved + <braunr> proc/maps involves procfs, ports, virtual memory, and file systems + <braunr> the naive implementation would merely be associating names to + memory objects, and why not, but a more complete one would go ask file + system servers about them + <braunr> perhaps more + <braunr> although personally i'd go for the naive one because less + dependencies usually means better reliability + <braunr> something similar to task_set_name could do the job + + # `/proc/[PID]/mem` Needed by glibc's `pldd` tool (commit diff --git a/hurd/translator/term.mdwn b/hurd/translator/term.mdwn index 667677a7..5ae52abe 100644 --- a/hurd/translator/term.mdwn +++ b/hurd/translator/term.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2013, 2014 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 @@ -190,6 +190,12 @@ The *term* translator implements POSIX termios discipline. <braunr> there, patches pushed :) +### IRC, freenode, #hurd, 2014-02-07 + + <braunr> btw, as a note, there really are leaks in terminals + <braunr> i managed to get a term server eat up to 300M of memory yesterday + + ## `screen` Logout Hang [[!tag open_issue_hurd]] diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn index 8c332d84..72400121 100644 --- a/hurd/translator/tmpfs/discussion.mdwn +++ b/hurd/translator/tmpfs/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -19,6 +19,8 @@ License|/fdl]]."]]"""]] * [[!GNU_Savannah_bug 26751]] +[[!toc]] + # [[Maksym_Planeta]] @@ -467,3 +469,35 @@ License|/fdl]]."]]"""]] privilege of their owner <braunr> privileges should be decoupled from identity <teythoon> yes + + +## IRC, freenode, #hurd, 2013-11-08 + + <teythoon> braunr: I'm investigating this port leak of mine + <teythoon> well, I thought I introduced one + <teythoon> but I'm not too sure anymore + <teythoon> the setting is this + <teythoon> i start an active tmpfs translator, bind it to foo + <teythoon> then, i create foo/bar with a passive translator entry + <teythoon> i access foo/bar, the passive translator is started + <teythoon> my test suite now covers several methods of making that + translator go away + <teythoon> killing it with 15 or 9 is fine, i.e. does not make the first + tmpfs leak ports + <teythoon> however, doing settrans -g foo/bar does for some reason + <teythoon> i think my code is fine, i spent considerable time on tracking + down this problem, always thinking that i must have introduced it + <teythoon> but another thing just cought my eye, the first tmpfs translator + says this when i do settrans -g foo/bar: + <teythoon> tmpfs/tmpfs: pthread_create: Resource temporarily unavailable + <teythoon> could it be that a no-sender notification is ignored b/c the + handler thread failed to start ? + <braunr> teythoon: i saw this pthread error too + + +# IRC, freenode, #hurd, 2014-02-09 + + <gg0> remounting tmpfs doesn't work if in use + http://paste.debian.net/plain/80937/ + <gg0> you will also get a pthread_create: Resource temporarily unavailable + <youpi> iirc the pthread_create warning happens for any kind of translator |