diff options
Diffstat (limited to 'hurd')
40 files changed, 4037 insertions, 146 deletions
diff --git a/hurd/authentication.mdwn b/hurd/authentication.mdwn index 2d6084bf..09dfb821 100644 --- a/hurd/authentication.mdwn +++ b/hurd/authentication.mdwn @@ -1,18 +1,22 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2013 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this 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]]."]]"""]] -UIDs on the Hurd are separate from processes. A process has +UIDs on the Hurd are separate from [[glibc/process]]es. A process has [[capabilities|capability]] designating so-called UID vectors that are implemented by an [[translator/auth]] server. This makes them easily [[virtualizable|virtualization]]. +The standard POSIX interfaces to a [[glibc/process]]' UID management are +implemented in [[glibc]]. + When a process wishes to gain access to a resource provided by a third party (e.g., a file system) and that party wishes to authenticate the client so as to implement some identity-based access control ([[IBAC]]) policy, @@ -25,3 +29,237 @@ naming a newly authenticated session with the server and the server is delivered the client's designated UID vector. For more details, see section 2.3 of the [[critique]]. + + +# Open Issues + +[[!tag open_issue_hurd]] + + +## IRC, freenode, #hurd, 2013-09-26 + + <braunr> teythoon: hum, i just saw something disturbing + <braunr> teythoon: to isolate the leak, i created my own proc directory + <braunr> and the mtab translators it spawns seem to be owned by root oO + <teythoon> braunr: but how is that possible? are you sure? have you checked + with 'ids'? + <braunr> no i'm not sure + <braunr> also, ext2fs seems to ignore --writable when started as a passive + translator + <braunr> < teythoon> braunr: but how is that possible? + <braunr> messup with passive translators i guess + <braunr> teythoon: actually, it looks like it has effective/available id + <braunr> it has no* + <braunr> this feature doesn't map well in unix + <teythoon> braunr: ah yes, htop doesn't handle this well and shows root + indeed, our ps shows - as username + <braunr> yes + + +## IRC, freenode, #hurd, 2013-09-28 + + <braunr> mhmm + <braunr> this process has no uid + <braunr> isn't it a security issue that processes can remove their identity + ? + <braunr> i really don't like that we allow processes to loose their + identity ... + <teythoon> braunr: y not? I think that's a killer feature + <teythoon> one that is notoriously absent in unices + <braunr> not exactly + <braunr> gaining rights to switch your identity is ok + <braunr> since you have proven that you are allowed to do it + <braunr> now, if you can remove your identity, you can create "ghost" + processes + <braunr> processes that can spend their day causing denial of services + without the possibility for the administrator to know who is responsible + <braunr> the unix "way" of dealing with DoS is to warn and ban users after + they violated the rules + <braunr> we need to have at least that possibility + <youpi> perhaps we need to add an "initial" uid + <teythoon> otoh the unix way of dropping privileges is hardly being able to + do so at all ;) + <braunr> teythoon: ? + <braunr> on unix, you need privileges to drop your identity :) + <braunr> i understand it involves security risks, but that's understandable + <braunr> the thing is, we actually don't care about dropping privileges + <braunr> we care about gaining them + <teythoon> you cannot drop your identity, you can just use another one + <braunr> exactly + <braunr> that's what i want + <braunr> and the way the hurd does it is superior + <braunr> let's keep that + <braunr> processes that should run with least privileges can simply have + their own user/group as it's done on unix + <teythoon> then how do you obtain such a uid/gid? + <braunr> teythoon: you gain the right, use it to prove who you can be, and + ask an identity switch + <braunr> identities would then be managed at server side (in proc for + example) + <teythoon> I know how it's done on the Hurd, but who creates them for you? + <braunr> the password server + <braunr> well no + <braunr> the password server gives you the right you need to prove who you + can be + <braunr> then i'd assume you'd ask the proc server for the switch + <teythoon> but who creates the uid for you in the first place, who sets up + a passwd entry + <braunr> the administrator ? + <braunr> what bothers me is that it goes directly against the main goal of + the hurd + <teythoon> indeed + <braunr> but i think it's a better compromise of freedom/order + <teythoon> I always thought that the ability to drop the unix-like + credentials is really nice + + +### IRC, freenode, #hurd, 2013-09-29 + + <antrik> braunr: dropping privileges doesn't unregister a process from the + proc server... so it shouldn't be too hard to find out who is + responsible. however, there are more effective ways to create ghost + processes -- a special executable skipping the ordinary bootstrap won't + be registered with proc at all... + <antrik> however, that would be a non-issue if we had proper resource + accounting + <teythoon> antrik: I do not believe that this is correct. every mach task + will eventually be picked up by the proc server + <teythoon> eventually being next time someone fork(2)s or so + <teythoon> but if noone uses proc_child to claim the new process ones + child, it will not be presented by the proc server as unix process (aiui) + <antrik> teythoon: not sure what you mean by "pick up" + <antrik> of course proc will see the process when listing all tasks on the + system; but it will have no additional knowlegde about it + <antrik> (which is the whole purpose of proc) + + +### IRC, freenode, #hurd, 2013-09-30 + + <braunr> antrik: proc should be redesigned to fix these issues + <braunr> in particular, the way that proc lists mach tasks to show them to + the rest of the system is something i find deeply disturbing + <braunr> hurd processes should be forced to go through proc + <antrik> braunr: well, if we are talking about fundamentally fixing things, + I believe the central proc server is not a good idea in the first place + :-) + <antrik> I believe hierarchical management of resource management and + information flow -- cf. nghurd and genode -- is a much better approach + <braunr> antrik: i agree with hierarchical management of resources, but i + don't see why this prevents a central proc server + <braunr> i.e. one proc server per hurd instance + + +### IRC, freenode, #hurd, 2013-10-06 + + <antrik> braunr: hierarchical management of resources doesn't prevent a + central proc server of course; but a central proc server would fit really + ill with hierarchical management of permissions... + + +### IRC, freenode, #hurd, 2013-10-07 + + <braunr> antrik: does proc manage permissions ? + <antrik> braunr: well, it manages some permissions... like who is allowed + to send signals + <antrik> hm... or perhaps proc is not involved in signal delivery itself? + don't remember. but at any rate, proc decides whether it hands out + privileged task ports + <braunr> antrik: yes, it decides whether or not a client is allowed to + obtain the message port of another task + <braunr> antrik: but i don't see why this is a problem + <braunr> what we have now is one proc server per hurd instance + <braunr> how is that not both central (inside the hurd instance) and + hierarchical with regard to resource management ? + <antrik> braunr: we are probably talking past each other + <antrik> all I'm saying is that in an ideal world, there should not be a + central server deciding who is allowed to see and/or control other + processes + <braunr> antrik: how should it be structured then ? + <braunr> i mean, how would you see it ? + <antrik> child processes should be fully controlled by their parent -- + including outside communication + <antrik> (like in genode AIUI) + <braunr> isn't that conflicting with the unix design ? + <kilobug> antrik: maybe I'm saying silly stuff since I don't have all the + background, but seems problematic to me with SUID/SGID programs + <kilobug> antrik: in which a child can be more privilegied than the parent + <braunr> kilobug: that's part of my question too + <kilobug> and it's even "worse" with Hurd's addauth in which any process + can be given additional rights in runtime, but not its parent + <antrik> braunr: one of the conclusions from ngHurd was that suid as such + is problematic. it makes more sense to have privileged services actually + run by the privileged user, and only requested by the unprivileged one + using RPC + <antrik> admittedly, I'm not sure how this interacts with UNIX + compatibility ;-) + <antrik> kilobug: in the genode approach, the parent would control that as + well + <braunr> in unix, the idea of parent processes doesn't imply much + <braunr> parents merely exist to reap resources from their children + <braunr> and as templates when forking + <antrik> yeah, but that's one of the major shortcomings of UNIX in my + book... + <braunr> sure + <braunr> i'm just thinking out loud + <braunr> if we want to maintain posix compatibility, it seems reasonable to + keep it that way + <braunr> despite the shortcomings + <braunr> does that imply a centralized proc server anyway ? + <antrik> I suspect we could similate suid in the hierarchical design, only + that the resources would be accounted to the user under whose ID the + process runs, rather than to the one who invoked it + <braunr> i also have a hard time seeing what the completely hierarchical + model brings compared to what the hurd does (isolating system instances) + <antrik> and I don't think we need a central proc server. it could probably + be done similar to the VFS: each process implements the interfaces, + passing on to the children as appropriate + <antrik> braunr: it's much easier to isolate parts of the system for + security and/or customisation + <antrik> that's actually one of the things discussed in the "critique" + IIRC... + <braunr> i'm not sure + <braunr> anyway, processes implementing the interface looks bad to me + <braunr> that's already a problem with the current hurd + <braunr> using normal client processes as servers means we rely on them to + behave nicely + <antrik> you have a point there: while untrusted filesystems can be ignored + easily, ignoring untrusted proc providers would be problematic... + <antrik> (I don't think it's strictly necessary to know about other user's + processes; but we could hardly keep a UNIX feel without it...) + <antrik> other users' + <braunr> i feel the hierarchical model may imply some unnecessary burden + <braunr> capabilities along with resource containers look much more + flexible + <braunr> and not less secure + <braunr> children would share the same container as their parent by + default, unless they obtain the right to use another or create their own + <antrik> braunr: decoupling control from resource ownership is *always* + problematic. that's pretty much the major takeaway from ngHurd + discussions (and the major reason why Coyotos was abandoned as a base for + ngHurd) + <antrik> if a process runs on your resources, you should have full control + over it. anything else faciliates DRM & Co. + <braunr> antrik: i see + <braunr> nonetheless, i don't see the point of that restriction, since the + simplest way to avoid drms in the first place is not using them + <braunr> and that restriction makes posix compatibility hard to provide + <antrik> I'm not sure it's really all that hard... + <antrik> IIRC genode is aiming at POSIX compatibility + <antrik> I'm not sure it's any harder than with the current Hurd + architecture + <braunr> i didn't see anything like that + <braunr> they provide posix compatibility by running legacy systems on top + of it + <braunr> well, namely linux + <antrik> hm... they have some UNIX compatibility at least... perhaps not + aiming at full POSIX. don't remember the details + <antrik> Linux on genode? that's news to me... I know they do run genode on + Linux + <braunr> anyway, i'll probably stick with the close unix approach for x15 + <braunr> http://genode.org/documentation/general-overview/ + <braunr> In an preliminary study, a user-level version of the Linux kernel + (L4Linux) was successfully ported to the Genode OS Framework running on a + L4 kernel. This study suggests that Genode combined with an appropriate + kernel or hypervisor is suited as a virtual-machine hosting platform. + <antrik> hm... that's boring though ;-) + <braunr> isn't it :) diff --git a/hurd/console.mdwn b/hurd/console.mdwn index 55581870..c9f47afe 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 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 @@ -37,8 +37,8 @@ where the numbered nodes represent virtual consoles and their contents are all alike. As the following graph shows, the console, input and display nodes are the -interfaces used by the terminal server, input driver and display drivers -respectively. +interfaces used by the [[terminal server|translator/term]], input driver and +display drivers respectively. +------------------+ +-----------------+ | Input driver | | Terminal Server | @@ -67,7 +67,8 @@ respectively. +----------------+ +-----------------+ The input driver takes scancodes from the in-kernel kbd queue, translates them -into characters and writes them to the input node. Then the terminal server +into characters and writes them to the input node. Then the [[terminal +server|translator/term]] reads the console node taking the characters out of the console server. Each of theese actions is actually an RPC handled by the translator on @@ -110,7 +111,8 @@ Additional information about the console can be found in the [Hurd Console Tutor **_The new Hurd console features:_** -**A console server**, which provides a number of virtual consoles to term servers, with a full set of terminal capabilities. +**A console server**, which provides a number of virtual consoles to [[term +servers|translator/term]], with a full set of terminal capabilities. The console server supports any encoding supported by iconv, but uses Unicode internally. The default encoding is ISO8859-1, another useful variant is UTF-8. @@ -214,7 +216,7 @@ Available mouse protocols are: ### <a name="Setting_up_encoding"> Setting up encoding </a> -The virtual consoles you are now running on are providing an ISO8859-1 environment (also known as latin1), which is good enough for the USA and some countries in Europe. If you require a different encoding for your locale (like, let's say, ISO8859-2), you can specify this as an argument to the console server. I am sorry to say that fsysopts doesn't do the trick yet, so you have to set the option with `settrans -fg`, which will _terminate all your login sessions and restart the console server_. +The virtual consoles you are now running on are providing an ISO8859-1 environment (also known as latin1), which is good enough for the USA and some countries in Europe. If you require a different encoding for your locale (like, let's say, ISO8859-2), you can specify this as an argument to the console server. I am sorry to say that [[hurd/fsysopts]] doesn't do the trick yet, so you have to set the option with `settrans -fg`, which will _terminate all your login sessions and restart the console server_. To do this, _first_ exit the client. It will get disconnected anyway (and doesn't attempt to reconnnect yet in such a case). Then do a @@ -307,7 +309,13 @@ If you use mutt, install `mutt-utf8` package. For lynx, edit `/etc/lynx.cfg`, ma If you use other applications, try to search with google for "application-name utf8" or "application-name unicode". Often you find what you need. The issues are the same for the GNU/Hurd and GNU/Linux systems, so most of the information can be shared, except how to setup the system console to support Unicode, of course. -The `console-server` watches for new hurdio terms (devices translated with `/hurd/term`) and adds them to `/dev/vcs` automatically. What this means is, if you create a new tty with `MAKEDEV`, and then attach something to it, it will now appear in `/dev/vcs`. When a term is disconnected from, it disappears from `/dev/vcs`. `/libexec/getty` is what is usually attached to a term. You can see this automatic adding and removing of terms from the `console-server` by typing the following: +The `console-server` watches for new [[hurdio terms (devices translated with +`/hurd/term`)|translator/term]] and adds them to `/dev/vcs` automatically. +What this means is, if you create a new tty with `MAKEDEV`, and then attach +something to it, it will now appear in `/dev/vcs`. When a term is disconnected +from, it disappears from `/dev/vcs`. `/libexec/getty` is what is usually +attached to a term. You can see this automatic adding and removing of terms +from the `console-server` by typing the following: # cd /dev # ls vcs/ @@ -444,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 0022ec23..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 @@ -48,3 +49,183 @@ License|/fdl]]."]]"""]] <pinotree> http://xkbcommon.org/ ¡û sounds interesting for our console translator + + +# IRC, freenode, #hurd, 2013-10-01 + +[[!tag open_issue_hurd]] + + <pinotree> teythoon_: df: `/dev/cons': Operation not supported + <pinotree> missing/stub implementation in the console translator? + + +## IRC, freenode, #hurd, 2013-10-02 + + <teythoon_> pinotree: yes, df does file_statfs which fails + + +# IRC, freenode, #hurd, 2013-10-22 + + <C-Keen> hello hurders! I happened to watch samuel's gnu hackers talk and + wanted to start to use the hurd more regularily. However I noticed that + when I use the preinstalled image, there seems to be some issue with the + console driver + <C-Keen> when I start emacs the mode line is drawn 3 times above the bottom + of the screen + <C-Keen> is this know or did I miss a step in setting it up? Or should I + use the debian installer and start from scratch again? + <youpi> C-Keen: it's probably unknown, and not an issue on your side. Did + you try to upgrade to the latest packages? + <C-Keen> youpi: doing that now + <C-Keen> my base image is debian-hurd-20130504.img + <youpi> still an issue with the latest packages indeed + <youpi> it seems emacs and the hurd console don't agree on the number of + lines... + <youpi> C-Keen: you can set TERM=vt100 to work around the issue + <C-Keen> ah alright. + <youpi> or TERM=linux + <C-Keen> youpi: can you start the emacs in X? I get an empty window here + <youpi> I never tried + <youpi> I never use emacs :) + <C-Keen> I see ;) + <youpi> it seems there's a bug in cud1 indeed + <C-Keen> what's cud1? + <youpi> see man 5 terminfo + <braunr> yes it's a terminfo problem + <braunr> the hurd console isn't well defined there + <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/fsysopts.mdwn b/hurd/fsysopts.mdwn new file mode 100644 index 00000000..debe2ebc --- /dev/null +++ b/hurd/fsysopts.mdwn @@ -0,0 +1,33 @@ +[[!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 +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]]."]]"""]] + +Get or set command line options for a running [[translator]]. + +See [[documentation/translators#manage]]. + + +# Open Issues + +[[!tag open_issue_hurd]] Not all translators support fsysopts: + + * [[console]] + * [[translator/pflocal]] + * [[virtualization/remap_root_translator]] + * [...] + + +## IRC, freenode, #hurd, 2013-05-23 + + <braunr> work around this by using showtrans + <braunr> fsysopts asks the server itself how it's running, usually giving + its command name and options + <braunr> showtrans asks the parent how it starts a passive translator + attached to the node + <gnu_srs> Yes showtrans works :), thanks. diff --git a/hurd/interface/fsys/02.mdwn b/hurd/interface/fsys/02.mdwn index 63b84c48..e5223e38 100644 --- a/hurd/interface/fsys/02.mdwn +++ b/hurd/interface/fsys/02.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 1992, 1993, 1994, 1995, 1996, 1997, 2002, 2009 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 1992, 1993, 1994, 1995, 1996, 1997, 2002, 2009, +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 @@ -29,5 +29,5 @@ Return a file to the root of the filesystem. `flags` are as for [[`dir_lookup`|dir_lookup]] (but `O_CREAT` and `O_EXCL` are not meaningful). `do_retry`, `retry_name`, and `result` are as for [[`dir_lookup`|dir_lookup]]. The port should be authenticated with `gen_uids` and `gen_gids` (except, of -course, for `FS_RETRY_REAUTH` and `FS_RETRY_MAGICAL). `dotdot_node` is an +course, for `FS_RETRY_REAUTH` and `FS_RETRY_MAGICAL`). `dotdot_node` is an unauthenticated port for the directory in which this root is located. diff --git a/hurd/libfuse.mdwn b/hurd/libfuse.mdwn index 78e96022..28125dd9 100644 --- a/hurd/libfuse.mdwn +++ b/hurd/libfuse.mdwn @@ -49,6 +49,25 @@ etc. <braunr> and they could almost readily use our libfuse version +## IRC, freenode, #hurd, 2013-10-01 + + <pinotree> our libfuse implementation is still basic atm (there's a wiki + page about it) + <alsuren> okay... talk to me about FUSE + <pinotree> even with the improvements i have in my public branch, it still + cannot do real-world fs'es + <alsuren> okay, so you're the person to ask about FUSE + <alsuren> it strikes me that HURD not having FUSE support is a bit of an + architectural oversight + <pinotree> i'm not sure what's your point about fuse, since what fuse on + linux (and not only) does is done *natively* by the hurd + <alsuren> exactly + <pinotree> all of the hurd filesystems (which are just a type of servers) + run in userspace already + <alsuren> so FUSE should Just Work + <pinotree> well no + + # Source [[source_repositories/incubator]], libfuse/master. 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 e029744d..c4c864f7 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 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 @@ -83,6 +83,24 @@ because else *-gnu* would catch i386-pc-linux-gnu for instance... Note: some of such statements are not from the source package itself, but from aclocal.m4 which is actually from libtool. In such case, the package simply needs to be re-libtoolize-d. + +## Preprocessor Define + +### IRC, freenode, #hurd, 2013-10-23 + + <C-Keen> Is there a preprocessor define gcc sets for hurd which I can check + in my code? + <braunr> __GNU__ + <braunr> glibc sets it if i'm right + <C-Keen> I also see that __MACH__ gets set + <azeem> that's also set on Mac OS X + <C-Keen> right, which uncovered a bug in the code + <braunr> the microkernel doesn't always implies what operating system runs + on top of it + <C-Keen> braunr: but __GNU__ is the correct define for hurd specific code? + <braunr> yes + + ## <a name="Undefined_bits_confname_h_tt_mac"> Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) </a> If macro `XXX` is undefined, but macro `_SC_XXX` or `_PC_XXX` is defined in `bits/confname.h`, you probably need to use `sysconf`, `pathconf` or `fpathconf` to obtain it dynamicaly. @@ -362,6 +380,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/chroot.mdwn b/hurd/running/chroot.mdwn index ea08ec48..38bab04e 100644 --- a/hurd/running/chroot.mdwn +++ b/hurd/running/chroot.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this diff --git a/hurd/running/debian.mdwn b/hurd/running/debian.mdwn index 39c7d1a6..c52fbf75 100644 --- a/hurd/running/debian.mdwn +++ b/hurd/running/debian.mdwn @@ -22,3 +22,76 @@ *Debian GNU/Hurd*, [[MichaelBanck]], LinuxTag 2004 Karlsruhe - [[Status]] - [Archive Qualification](http://wiki.debian.org/ArchiveQualification/hurd-i386) + + +# `/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/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn index a906afef..95c23920 100644 --- a/hurd/running/debian/qemu_image.mdwn +++ b/hurd/running/debian/qemu_image.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012, 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 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/running/virtualbox.mdwn b/hurd/running/virtualbox.mdwn index 822f771d..23a0b156 100644 --- a/hurd/running/virtualbox.mdwn +++ b/hurd/running/virtualbox.mdwn @@ -40,7 +40,44 @@ To convert the image you need the VirtualBox package properly installed with a V If [[QEMU with KVM|qemu]] is not available, VirtualBox reportedly has better performance. -IRC, freenode, #hurd, 2011-10-31: + +# Open Issues + +## IRC, freenode, #hurd, 2011-10-31 <youpi> I don't know what virtualbox does with hardware emulation, but gnumach is awfully slow to probe things there + + +## IRC, freenode, #hurd, 2013-09-28 + + <snadge> the problem is if i giveit more than 1855 it says truncating to + that + <snadge> so i give it that.. then it has kmem alloc error + <snadge> 1536mb same.. 1024 isok + <braunr> hum + <braunr> that's weird + <braunr> virtual box ? + <snadge> yeah + <snadge> i wonder what cpu features i should enable/disable + <snadge> pae ? + <braunr> make sure vbox doesn't count on the so called memory balloon + <braunr> pae isn't used except on xen + <braunr> disable apic + <braunr> enable host io cache in disk controllers + <youpi> do we have these written on the wiki? + <braunr> no because i didn't run into these problems + <braunr> but since i know the system well enough to avoid them in the first + place .. + <braunr> we need real users to report them + <braunr> i'm not sure we have anything about vbox in the wiki actually + <youpi> ./hurd/running/virtualbox.mdwn + <youpi> we seem to have a page at least + <snadge> it seems to be okay with 1024MiB + <braunr> still weird + <braunr> looks more random than buggy with more memory + <braunr> do you have the exact error message you got during your previous + attempts ? + <snadge> no.. i should have taken a screenshot.. its easy enough to + reproduce though + <snadge> i'll wait until after its installed diff --git a/hurd/settrans/discussion.mdwn b/hurd/settrans/discussion.mdwn index 74f1c8f5..aff7562a 100644 --- a/hurd/settrans/discussion.mdwn +++ b/hurd/settrans/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 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 @@ -10,6 +11,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation open_issue_hurd]] +[[!toc]] + # IRC, freenode, #hurd, 2011-06-01 @@ -37,3 +40,29 @@ License|/fdl]]."]]"""]] <antrik> braunr: well, the fact that a translator is unset by setting it to nothing is unclear in general, not only for passive translator. I agree that pointing this out should make things much more clear in general... + + +<a name="chroot"> +# `--chroot` +</a> + +## IRC, freenode, #hurd, 2013-08-29 + + <teythoon> btw, I somehow feel settrans is being abused for chroot and + friends, there is no translator setting involved + <youpi> chroot, the command? or the settrans option? + <youpi> I don't understand what you are pointing at + <teythoon> the settrans option being used by fakeroot, remap and (most + likely) our chroot + <youpi> our chroot is just a file_reparent call + <youpi> fakeroot and remap do start a translator + +[[virtualization/remap_root_translator]], [[virtualization/fakeroot]]. + + <teythoon> yes, but it is not being bound to a node, which is (how I + understand it) what settrans does + <teythoon> the point being that if settrans is being invoked with --chroot, + it does something completely different (see the big if (chroot) {...} + blocks) + <teythoon> to a point that it might be better of in a separate command + <youpi> Mmm, indeed, a lot of the options don't make sense for chroot diff --git a/hurd/status.mdwn b/hurd/status.mdwn index cca8fc15..6aa319d1 100644 --- a/hurd/status.mdwn +++ b/hurd/status.mdwn @@ -38,15 +38,10 @@ Although the [[POSIX interface|faq/posix_compatibility]] is provided, some additional interfaces like POSIX shared memory or semaphores are still under development. -All this applies to the current development version, and not to the -last release (0.2). We encourage everybody who is interested to try +We encourage everybody who is interested to try out the current development version, and send feedback to the Hurd developers. -The Hurd team doesn't create Hurd-only releases, but instead relies on -the distributions done by folks from *Debian*, *Arch* (since 2010), and *Nix* -(since 2012). - [[!img hurd-iceweasel-screenshot-2012-03-21.png size=300x alt="Iceweasel running on GNU/Hurd" title="Iceweasel running on GNU/Hurd" @@ -63,17 +58,6 @@ GNU/Hurd 2013|news/2013-05-debian_gnu_hurd_2013]]. [[hurd/running/Nix]] provides QEMU images. -That said, the last official release of the Hurd -without the Debian parts was 0.2 done in 1997 ([[history]]). - -New official releases will be done, as soon as -the Hurd is sufficently stable and feature -complete. If an official release of the Hurd were made -now, people would try the Hurd and be disappointed. People -already expect delays; to disappoint them in this way as -well would be unfortunate. Moreover, it would lessen the -possibility that they would want to try the Hurd again in the future. - ## Usability Reports diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index 0c7677a9..e50ea0d5 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2013 Free Software +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -192,6 +192,9 @@ characteristic thread counts. ports from the mother hurd to the subhurd <teythoon> so that we could pass in a port to the eth-multiplexer <teythoon> or use like /hurd/remap as the root translator for the subhurd + +[[open_issues/virtualization/remap_root_translator]]. + <braunr> eth-multiplexer was created exactly for that iirc, <braunr> so it's probably already done somewhere diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn index fac93625..892387ef 100644 --- a/hurd/subhurd/discussion.mdwn +++ b/hurd/subhurd/discussion.mdwn @@ -180,3 +180,37 @@ License|/fdl]]."]]"""]] <braunr> safer <braunr> perhaps more powerful too, but that entirely depends on the features you want inside + + +# IRC, freenode, #hurd, 2013-10-04 + + <braunr> hm, looks like we broke subhurds again + <braunr> freezes after starting exec + <teythoon> o_O + <braunr> looks like some translator refuses to start + <braunr> teythoon: we need better error reporting first :) + +[[open_issues/subhurd_error_messages]]. + + <braunr> and better visibility in general + <braunr> teythoon: it may be that the subhurd i'm using is a bit od + <braunr> old + <braunr> one weird thing about subhurds is that they actually use the + ext2fs and linker from the host + <braunr> so it's better if the subhurd and the host uses the same bootstrap + protocol :) + <teythoon> braunr: isn't boot --boot-root=DIR there to specify which root + translator and linker to use? + <braunr> teythoon: yes but you don't want your root file system mounted + from the host when starting your subhurd + <teythoon> you can mount it r/o just fine, no? + <braunr> ideally, we'd have a userspace version of grub reading the files + from the disk, as it's done when booting + <braunr> hm + <braunr> right + + +## IRC, freenode, #hurd, 2013-10-07 + + <teythoon> braunr: btw, did you straighten out your subhurd issue? + <braunr> teythoon: no i haven't diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index 52cd09f7..32562a8b 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -106,6 +106,7 @@ The [[concept|concepts]] of translators creates its own problems, too: * [[symlink]] * [[firmlink]] * [[fifo]] +* [[term]] * ... diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn index 7fd4832c..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 @@ -8,7 +9,8 @@ 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]]."]]"""]] -The *auth server* (or, *authentification server*). +The *auth server* (or, *authentification server*) is a key component managing +[[authentication]] in a Hurd system. It is stated by `/hurd/init`. @@ -18,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 e038ba84..70a6efee 100644 --- a/hurd/translator/discussion.mdwn +++ b/hurd/translator/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011 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,7 +11,10 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation open_issue_hurd]] -IRC, freenode, #hurd, 2011-08-25: +[[!toc]] + + +# IRC, freenode, #hurd, 2011-08-25 < frhodes> how can I replace an existing running server with a new one without rebooting? @@ -23,3 +27,184 @@ IRC, freenode, #hurd, 2011-08-25: nature < antrik> in some cases, you might even be able simply to remove the old translator... but obviously only for non-critical stuff :-) + + +# IRC, freenode, #hurd, 2013-10-21 + + <braunr> mhmm, there is a problem with thread destruction + +[[open_issues/libpthread/t/fix_have_kernel_resources]]. + + <braunr> actually, translator self destruction + <braunr> if a request arrives after the last thread servicing a port set + returns from mach_msg because of a timeout, but before the translator is + detached from its parent, the client will get an error + <braunr> it should very rarely happen, but if it does, we could face the + same kind of issues we have when a server crashes + <braunr> e.g. sshd looping over select() returning EBADF, consuming all cpu + <braunr> not sure we want to introduce such new issues + + <braunr> i don't think i'll be able to make translators disappear reliably + .. + <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/examples.mdwn b/hurd/translator/examples.mdwn index 4947808e..69f15c02 100644 --- a/hurd/translator/examples.mdwn +++ b/hurd/translator/examples.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -92,4 +92,4 @@ To join "foo/" "bar/" and "baz/" in the directory "quux/", just do: $ settrans -capfg quux/ /hurd/unionfs foo/ bar/ baz/ If you want to join even quux/ contents in the union itself, add `-u` as a translator argument. -You can add filesystems at run-time with the `fsysopts` command. +You can add filesystems at run-time with the [[fsysopts]] command. diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index e2f6b044..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 @@ -163,6 +163,11 @@ small backend stores, like floppy devices. <youpi> ok +#### IRC, freenode, #hurd, 2013-10-08 + + <braunr> ogi: your ext2fs patches were finally merged upstream :) + + ## Sync Interval [[!tag open_issue_hurd]] @@ -209,37 +214,332 @@ That would be a nice improvement, but only after writeback throttling is impleme <teythoon> tschwinge: well, thanks anyway ;) -## Increased Memory Consumption - -### IRC, freenode, #hurd, 2013-09-18 - - <braunr> ext2fs is using a ginormous amount of memory on darnassus since i - last updated the hurd package :/ - <braunr> i wonder if my ext2fs large store patches rework have introduced a - regression - <braunr> the order of magnitude here is around 1.5G virtual space :/ - <braunr> it used to take up to 3 times less before that - <braunr> looks like my patches didn't make it into the latest hurd package - <braunr> teythoon: looks like there definitely is a new leak in ext2fs - <teythoon> :/ - <braunr> memory only - <braunr> the number of ports looks stable relative to file system usage - <teythoon> braunr: I tested my patches on my development machine, it's up - for 14 days (yay libvirt :) and never encountered problems like this - <braunr> i've been building glibc to reach that state - <teythoon> hm, that's a heavy load indeed - <teythoon> could be the file name tracking stuff, I tried to make sure that - everything is freed, but I might have missed something - <braunr> teythoon: simply running htop run shows a slight, regular increase - in physical memory usage in ext2fs - <pinotree> old procfs stikes again? :) - <teythoon> braunr: I see that as well... curious... - <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried - to make sure that everything is freed, but I might have missed something - <braunr> how knows, maybe completely unrelated - <teythoon> the tracking patch isn't that big, I've gone over it twice today - and it still seems reasonable to me +## 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 diff --git a/hurd/translator/fifo.mdwn b/hurd/translator/fifo.mdwn index 857922fc..4132e94a 100644 --- a/hurd/translator/fifo.mdwn +++ b/hurd/translator/fifo.mdwn @@ -46,3 +46,9 @@ The *fifo* translator implements named pipes (FIFOs). <pochu> gg0: got an example? <gg0> http://bugs.debian.org/629184 <gg0> i didn't close it myself + + +## IRC, OFTC, #debian-hurd, 2013-10-04 + + <braunr> there is new-fifo, which you can try + <braunr> i guess none of us know what it was really meant for diff --git a/hurd/translator/magic.mdwn b/hurd/translator/magic.mdwn index 84bacdfb..2b0d1bf7 100644 --- a/hurd/translator/magic.mdwn +++ b/hurd/translator/magic.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2010 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 2010, 2013 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -9,7 +9,13 @@ 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]]."]]"""]] -The magic translator provides `/dev/fd`. +The `magic` translator returns magic retry results, which are then resolved by +[[glibc]]'s *name lookup* routines. + +[[!toc]] + + +# `/dev/fd`. $ showtrans /dev/fd /hurd/magic --directory fd @@ -20,3 +26,253 @@ individually like this: $ ls -l /dev/fd/0 crw--w---- 1 bing tty 0, 0 Nov 19 18:00 /dev/fd/0 + + +# `/dev/tty` + + $ showtrans /dev/tty + /hurd/magic tty + + +## Open Issues + +### IRC, OFTC, #debian-hurd, 2013-06-18 + + <XTaran> http://www.zsh.org/mla/workers/2013/msg00547.html + + +#### IRC, OFTC, #debian-hurd, 2013-06-19 + + <XTaran> youpi: http://www.zsh.org/mla/workers/2013/msg00548.html -- Is + that realistic? If yes, can someone of you test it? I though would expect + that if /dev/tty exists everywhere, it's a chardev everywhere, too. + <youpi> that's not impossible indeed + <youpi> I've noted it on my TODO list + + +#### IRC, OFTC, #debian-hurd, 2013-06-20 + + <pinotree> youpi: wrt the /dev/tty existance, + https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=hurd-i386&ver=46-2&stamp=1371553966 + <pinotree> For the build logs, demonstrate that /dev/null and /dev/tty + exist: + <pinotree> ls: cannot access /dev/tty: No such device or address + <youpi> uh?! + <youpi> ah, ENODEV + <youpi> so that's what we was thinking, no tty -> no /dev/tty + + +#### IRC, OFTC, #debian-hurd, 2013-09-20 + + <XTaran> Hi. zsh still FTBFS on Hurd due to some test failure: + https://buildd.debian.org/status/package.php?p=zsh -- IIRC I checked last + time on some porterbox and couldn't reproduce the failure there. Any + insight if /dev/tty is not accessible on the buildds inside the chroot? + Or is it no character device there? I checked on strauss and there it is + a character device. + <XTaran> My only other option to debug this (didn't think of that yesterday + before the upload unfortunately) would be to override dh_auto_test with + "ls -l /dev/tty; dh_auto_test". Do you think that would be helpful? + <pinotree> i see /dev/tty on exodar, in the root system and in the chroot + <XTaran> pinotree: And it is a character device? + <XTaran> ... in both cases? + <pinotree> crw--w---- 1 pino tty 0, 0 Sep 20 10:20 /dev/tty + <pinotree> yes + <XTaran> pinotree: Hrm. + <pinotree> (/dev in the chroot is a firmlink to the system /dev, iirc) + <XTaran> pinotree: What is a firmlink? :) + <XTaran> pinotree: /dev/tty belongs to your user in the example above. + <pinotree> something between a (sym)link and an union mount + <XTaran> pinotree: Is it possible that /dev/tty is not visible if the + buildd runs without a connected terminal? + <pinotree> that i'm not sure + <XTaran> I see. + <pinotree> wouldn't it be possible to skip only that check, instead of the + whole test suite? + <pinotree> maybe something like + <pinotree> tty=$(find /dev/ -name 'tty*' -type c -print) + <pinotree> if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c $zerolength ]] + / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty ]] (no tty + found)' / [[ ! -c $zerolength ]] / fi + <pinotree> (never used zsh, so please excuse me if i wrote something silly + above) + <XTaran> re + <XTaran> pinotree: Yeah, sure. That would be one way to get the thing + building again, if that's really the cause. + <pinotree> i guess it would find any of the available tty* devices + <pinotree> it does that for block devices, why not with tty devices, after + all? :) + <XTaran> pinotree: I just wonder if the failing test is because the test + doesn't work properly on that architecture or because it indicates that + there is a bug in zsh which only is present on hurd. + <pinotree> wouldn't the change proposed above help in determining it? + <XTaran> If I'm sure that it's a broken test, I'll try to disable that + one. If not I'd report (more details) to upstream. :) + <XTaran> pinotree: Oh, indeed. + <pinotree> if you get no warning, then a tty device was found with find + (using its -type c option), so the failing condition would be a zsh (or + maybe something in the stack below) bug + <pinotree> with the warning, somehow there were no tty devices available, + hence nothing to test -c with + <XTaran> So basically doing a check with dash to see if we should run the + zsh test. + <pinotree> dash? + <XTaran> Well, whatever /bin/sh points to. :) + <pinotree> ah, do you mean because of $(find ...)? + <XTaran> Ah, right, -type c is from find not /bin/sh + <XTaran> pinotree: That's my try: + http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=ba5c7320d4876deb14dba60584fcdf5d5774e13b + <pinotree> o_O + <pinotree> isn't that a bit... overcomplicated? + <XTaran> pinotree: Yeah, it's a little bit more complicated as the tests + itself are not pure shell code but some format on their own. + <pinotree> why not the "thing" i wrote earlier? + <XTaran> pinotree: Actually it is what I understand you wanted to do, just + with more debug output. Or I dunderstood + <XTaran> pinotree: Actually it is what I understand you wanted to do, just + with more debug output. Or I understood your thing wrongly. + <pinotree> <pinotree> tty=$(find /dev/ -name 'tty*' -type c -print) + <pinotree> <pinotree> if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c + $zerolength ]] / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty + ]] (no tty found)' / [[ ! -c $zerolength ]] / fi + <XTaran> pinotree: Yeah, I know. + <pinotree> that is, putting these lines instead of the current two + tty=/dev/tty + following + <pinotree> imho that should be fit for upstream + <XTaran> pinotree: You mean inside C02cond.ztst? + <pinotree> yep + <XTaran> pinotree: No, IMHO that's a bad idea. + <pinotree> why? + <XTaran> pinotree: That file is to test the freshly compiled zsh. I can't + rely on their code if I'm testing it. + <pinotree> uh? + <pinotree> the test above for -b is basically doing the same + <XTaran> pinotree: Indeed. Hrm. + <pinotree> that's where i did c&p most of it :) + <XTaran> So upstream relies on -n in the testsuite before it has tested it? + Ugly. + <pinotree> if upstream does it, why cannot i too? :D + <XTaran> pinotree: You've got a point there. + <XTaran> Ok, rethinking. :) + <pinotree> otoh you could just move the testcase for -n up to that file, so + after that you know it works already + <XTaran> pinotree: Well, if so, upstream should do that, not me. :) + <pinotree> you could suggest them to, given the -n usage in the -b testcase + <XTaran> pinotree: Looks alphabetically sorted, so I guess that's at least + not accidentially. + <XTaran> pinotree: Ok, you've convinced me. :) + <pinotree> :D + <XTaran> Especially because this is upstream-suitable once it proved to fix + the Hurd FTBFS. :) + <XTaran> pinotree: The previous upstream code (laast change 2001) instead + of the hardcoded /dev/tty was btw "char=(/dev/tty*([1]))", so I suspect + that the find may work on Cygwin, too. + <XTaran> s/aa/a/ + <pinotree> ah, so that's that comment about globbing on cygwin was + referring to + <XTaran> Yep + <pinotree> cool, so incidentally i've solved also that small issue :9 + <pinotree> :) + <XTaran> pinotree: I hope so. :) + <XTaran> Then again, I hope, external commands like find are fine for + upstream. + <pinotree> then they should rework the already existing testcases ;) + <XTaran> pinotree: Ah, I fall again for the same assumptions. :) + <XTaran> Seems as I would really build test suites with a different + approach. :) + <pinotree> nothing bad in that, i'd say + <XTaran> I'd try to make the tests as far as possible independent from + other tools or features to be sure to test only the stuff I want to test. + <XTaran> Warning: Not testing [[ -c tty ]] (no tty found) + <XTaran> Interesting. I didn't expect that outside a chroot. :) + <pinotree> where's that? + <XTaran> pinotree: A plain "debuild on my Sid VM. + <pinotree> ah + <XTaran> Linux, amd64 + <XTaran> (and Debian of course ;-) + <XTaran> pinotree: Ah, my fault, I kept upstreams char= but didn't change + it in your code. :) + <pinotree> hehe + <XTaran> pinotree: Will be included in the next zsh upload. But I don't + want to upload a new package before the current one moved to testing (or + got an RC bug report to fix :-) + <pinotree> oh sure, that's fine + <XTaran> pinotree: + http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=22bc9278997a8172766538a2ec6613524df03742 + <XTaran> (I've reverted my previous commit) + <pinotree> \o/ + + +#### IRC, OFTC, #debian-hurd, 2013-09-30 + + <XTaran> Anyone knows why the building of zsh on ironforge restarted? It + was at something like "building 4h20m" when I looked last and it now is + at "building 1h17m" but there's no old or last log, so it does still look + like the first build. + <pinotree> most probably got stuck + <XTaran> Oh, ok. + <XTaran> pinotree: So there are cases where the log is not kept? + <pinotree> looks so + <youpi> when the machine crashes, yes :) + <XTaran> youpi: Ooops. Was that me? + <youpi> no, I just rebooted the box + <youpi> I didn't easily find which process to kill + <XTaran> Ok. Then I'll check back tomorrow morning if pinotree's fix for + zsh's test suite on hurd worked. :) + <youpi> it seems to be hung on + /build/buildd-zsh_5.0.2-5-hurd-i386-vO9pnz/zsh-5.0.2/obj/Test/../Src/zsh + <youpi> ../Src/zsh ../../Test/ztst.zsh ../../Test/Y02compmatch.ztst + <XTaran> :( + <XTaran> At least pinotree's patch worked as it then likely passed + C02cond.ztst. :) + <XTaran> youpi: For how long? There are multiple tests which take at least + 3 seconds per subtest. + <youpi> one hour already + <XTaran> Ok. + <XTaran> That's far too long + + +#### IRC, OFTC, #debian-hurd, 2013-10-01 + + <XTaran> pinotree: I've just checked + https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=hurd-i386&ver=5.0.2-5&stamp=1380608100 + manually: Your fix unfortunately seemed not to help, but another test + failed, too, and that one came later and was hence suspected as primary + failing issue. + <XTaran> pinotree: But "+ find: `/dev/tty': No such device or address" + gives some hint. I just have no idea, why find issues that message. + * XTaran really wonders how that message can be caused. + <XTaran> So find sees /dev/tty, but gets an error if it tries to access + (maybe only stat) it while not being connected to a terminal. + <XTaran> Bingo: This reproduces the issue (note the missing -t option to + ssh): ssh exodar.debian.net "find /dev/ -nowarn -maxdepth 1 -name 'tty*' + -type c -ls" + <XTaran> Even clearer: $ ssh exodar.debian.net "ls -l /dev/" | grep 'tty$' + <XTaran> ls: cannot access /dev/tty: No such device or address + <XTaran> ?????????? ? ? ? ? ? tty + <XTaran> I'd say this is a bug somewhere deep down, either in libc or the + kernel. + <pinotree> or in the console translator + <XTaran> pinotree: Never heard of that so far. :) + <XTaran> pinotree: Someone from zsh upstream suggests to use /dev/null or + /dev/zero instead of /dev/tty* -- will try that for the next upload. + <pinotree> ah right, /dev/null should be standard POSIX + <XTaran> I hope so. :) + <pinotree> http://pubs.opengroup.org/onlinepubs/9699919799/ check in POSIX + <pinotree> in any case, sorry for the troubles it is giving you... + <XTaran> pinotree: I'm more concerned about the hanging second test. I + think I can get that test working with using /dev/null. + <XTaran> Now that I've understood why the original test is failing. + <XTaran> pinotree: Shall I write a bug report for that issue? If so, + against which package? + <pinotree> XTaran: not sure it is worth at this stage, having a clearer + situation on what happens could be useful + <pinotree> it is something that can happen sporadically, though + <XTaran> pinotree: Well, it seems a definitely unwanted inconsistency + between what the directory listing shows and which (pseudo) files are + accessible. Independently of where the bug resides, this needs to be + fixed IMHO. + <pinotree> sure, nobody denies that + <XTaran> pinotree: I'd call it easily reproducible. :) + <pinotree> not really + <XTaran> ... once you know where to look for. diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index 0734e1e6..89593436 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]] @@ -1864,21 +1870,9 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <teythoon> and I saw that this also aplies to remap.sh <teythoon> *while <youpi> yep, they're basically the same - <teythoon> btw, I somehow feel settrans is being abused for chroot and - friends, there is no translator setting involved - <youpi> chroot, the command? or the settrans option? - <youpi> I don't understand what you are pointing at - <teythoon> the settrans option being used by fakeroot, remap and (most - likely) our chroot - <youpi> our chroot is just a file_reparent call - <youpi> fakeroot and remap do start a translator - <teythoon> yes, but it is not being bound to a node, which is (how I - understand it) what settrans does - <teythoon> the point being that if settrans is being invoked with --chroot, - it does something completely different (see the big if (chroot) {...} - blocks) - <teythoon> to a point that it might be better of in a separate command - <youpi> Mmm, indeed, a lot of the options don't make sense for chroot + +[[open_issues/virtualization/remap_root_translator]], +[[open_issues/virtualization/fakeroot]]. ## IRC, freenode, #hurd, 2013-09-06 @@ -1973,6 +1967,9 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <teythoon> right, so now at last I got the whole question :) <braunr> :) <teythoon> ugh, I just found the FS_RETRY_MAGICAL handler in the libc :-/ + +[[interface/dir_lookup]]. + <braunr> ? <braunr> why "ugh" ? <teythoon> well, I'm inclined to think this is the bad kind of magic ;) @@ -2103,7 +2100,173 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <youpi> anyway, got to run -## IRC, freenode, #hurd, 2013-09-20 +## Memory Leak + +Fixed in 2013-09-28 Hurd commit a81c0c28ea606b0d0a2ad5eeb74071c746b7cdeb +(libdiskfs), and 2013-10-04 Hurd commit +98b6f846b628e858acbae9258bac78cf54126d27 (libnetfs). + +### IRC, freenode, #hurd, 2013-09-18 + + <braunr> ext2fs is using a ginormous amount of memory on darnassus since i + last updated the hurd package :/ + <braunr> i wonder if my ext2fs large store patches rework have introduced a + regression + <braunr> the order of magnitude here is around 1.5G virtual space :/ + <braunr> it used to take up to 3 times less before that + <braunr> looks like my patches didn't make it into the latest hurd package + <braunr> teythoon: looks like there definitely is a new leak in ext2fs + <teythoon> :/ + <braunr> memory only + <braunr> the number of ports looks stable relative to file system usage + <teythoon> braunr: I tested my patches on my development machine, it's up + for 14 days (yay libvirt :) and never encountered problems like this + <braunr> i've been building glibc to reach that state + <teythoon> hm, that's a heavy load indeed + <teythoon> could be the file name tracking stuff, I tried to make sure that + everything is freed, but I might have missed something + <braunr> teythoon: simply running htop run shows a slight, regular increase + in physical memory usage in ext2fs + <pinotree> old procfs stikes again? :) + <teythoon> braunr: I see that as well... curious... + <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried + to make sure that everything is freed, but I might have missed something + <braunr> how knows, maybe completely unrelated + <teythoon> the tracking patch isn't that big, I've gone over it twice today + and it still seems reasonable to me + <braunr> hm + + +### IRC, freenode, #hurd, 2013-09-25 + + <braunr> seems like a small leak per file access + <braunr> but htop makes it obvious because it makes lots of them + <braunr> shouldn't be too hard to find + <braunr> since it might also come from the large store patch, i'll take a + look at it + + +### IRC, freenode, #hurd, 2013-09-27 + + <braunr> teythoon: found the leak :) + <braunr> although its origin is weird + <teythoon> braunr: where is it? + <braunr> i'm still building packages to make sure that's it + <braunr> see + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/blob/HEAD:/libdiskfs/dir-lookup.c + <braunr> which you changed in + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/commit/06d49cdadd9e96361f3fe49b9c940b88bb869284 + <braunr> line 306 is "return error" instead of "goto out" + <braunr> has been so since 1994 + <braunr> what is unclear is why this code path is now run + <braunr> patch is here: + http://darnassus.sceen.net/~rbraun/0001-Fix-memory-leak-in-libdiskfs.patch + <teythoon> I see, weird indeed + <braunr> teythoon: the system also feels slower somehow + <braunr> such errors might have introduced unexpected retries + <teythoon> i think it's possible to write a coccinelle patch to find such + errors + + +### IRC, freenode, #hurd, 2013-09-28 + + <youpi> braunr: bah, I havent noticed the leak on my box, even after + building eglibc & hurd several times + <braunr> that's weird + <braunr> are you sure it's up to date ? + <braunr> also, is procfs correctly attached to /proc ? + <braunr> that's what seems to trigger it + <youpi> yes, 20130924-2, with procfs on /proc + + <teythoon> braunr: that turned out to be the leak indeed? and somehow my + changes triggered it? did you discover why? + <braunr> teythoon: yes, yes, no + <braunr> but youpi didn't see the leak on his system + <teythoon> ^^ cool that you found it + <teythoon> I did + <braunr> oh yes you mean you saw the leak + <teythoon> yes + + +### IRC, freenode, #hurd, 2013-10-01 + + <braunr> the fix i did in libdiskfs might have fixed other issues + <braunr> apparently, it's the code path taken when error isn't ENOENT, + including no error (translator started) + <pinotree> the memory leak fix, you mean? + <braunr> yes + <braunr> it might haved fixed reference counting too + <braunr> although i'm not sure if we actually ever run into that issue in + the past + <braunr> the weird thing is, that path is taken when starting a passive + translator + <braunr> (i think) + <braunr> (it might be any kind of translator, and just doing nothing if + alcready active) + <braunr> already* + <braunr> anyway, the fact that the leak was so visible means this code was + run very often + <braunr> which doesn't make sense + <braunr> hm ok, it seems that code was run every time actually + <braunr> but the leak became visible when it concerned memory + <pinotree> which side-effects did the old code produce? + <braunr> teythoon added a dynamically allocated path that wasn't freed + <braunr> reference leaks + <braunr> which might explain the assertion on reference we sometimes see + with ext2fs + <braunr> when a counter overflows and becomes 0 + +[[open_issues/ext2fs_libports_reference_counting_assertion]]? + + <pinotree> hmm + <braunr> which is why i'm mentioning it + <braunr> :) + <braunr> i'll try to reproduce the assertion + <braunr> pinotree: actually, after a more in-depth look, reference counting + looks valid before the fix too + <pinotree> ok, thanks for checking + <braunr> pinotree: the assertion affects the root translator, and is + triggered by a test that stresses memory + <pinotree> memory as in ram, or as in disk storage? + <braunr> malloc + <pinotree> ok + <braunr> i suspect the code doesn't handle memory failure well + + +### IRC, freenode, #hurd, 2013-10-02 + + <teythoon_> braunr: btw, did you fix the leak? + <braunr> yes + <braunr> + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/commit/a81c0c28ea606b0d0a2ad5eeb74071c746b7cdeb + <braunr> 1h after tagging 0.5 ( + <braunr> :( + <teythoon> ah yes, I've seen that commit + <teythoon> I just wanted to know whether this settled the issue + <braunr> it does :) + <teythoon> good + <braunr> i still can't figure out why youpi didn't had it + <braunr> the code path is run when no error (actually error != ENOENT) + <braunr> which explains why the leak was so visible + <teythoon> so my patch exposed this b/c of the allocation I added, makes + sense + <teythoon> it's funny actually, b/c this wasn't an issue for me as well, I + had my development vm running on that patches for two weeks + + +### IRC, freenode, #hurd, 2013-10-02 + + <braunr> libnetfs suffers from the same leak as libdiskfs when looking up a + translator + <braunr> i'll fix it too + + +## Multiple mtab Translators Spawned + +Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a? + + +### IRC, freenode, #hurd, 2013-09-20 <braunr> teythoon: how come i see three mtab translators running ? <braunr> 6 now oO @@ -2113,10 +2276,773 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <braunr> teythoon: more bug fixing for you :) -## IRC, freenode, #hurd, 2013-09-23 +### IRC, freenode, #hurd, 2013-09-23 <teythoon> so it might be a problem with either libnetfs (which afaics has never supported passive translator records before) or procfs, but tbh I haven't investigated this yet [[open_issues/libnetfs_passive_translators]]. + + +### [[!debbug 724868]] + + +### IRC, freenode, #hurd, 2013-10-03 + + <braunr> i can't manage to find out where the hurd stores information about + active translators ... + <braunr> there is this transbox per node + <braunr> but where are nodes stored ? + <braunr> what if they are are dropped ? + <pinotree> braunr: iirc, see libfshelp + <braunr> well i have + <braunr> i still can't find it + <braunr> i fear that it works for ext2fs because that particular translator + implements a cache of open nodes + <braunr> whereas things like procfs drop and recreate nodes per open + <braunr> which would be the root cause for the multiple mtab bug + <pinotree> doesn't tmpfs support translators? + <braunr> good idea + <braunr> although it's still a libdiskfs based one + <braunr> no problem for tmpfs, so it would be a netfs/procfs issue + <braunr> better than what i feared :) + <braunr> now, how is libdiskfs able to find active translators .. + <braunr> ah, there is a name cache in libdiskfs .. + <braunr> nope, looks fine + + +### IRC, freenode, #hurd, 2013-10-04 + + <braunr> nodes with a translator seem to keep a reference in libdiskfs and + not in libnetfs + <braunr> mhmmpf + <braunr> oh great .. + <braunr> each libdiskfs that "works" seems to implement its own + diskfs_cached_lookup function + <braunr> so both ext2fs and tmpfs actually maintain a list of nodes, + keeping a reference on those with a translator + <braunr> while procfs simply doesn't + <braunr> teythoon: ^ + <braunr> *sigh* + <teythoon> braunr: ok, thanks, I'll look into that + <braunr> i'm not sure how to fix it + <braunr> we can either fix node destruction to cleanly shut down + translators + <braunr> but this would mean starting mtab on each access + <braunr> or we could implement a custom cache in procfs + <braunr> or perhaps a very custom change in the lookup callback for mounts + <braunr> i'll try the latter + <teythoon> err, shouldn't we try to fix this in lib*fs? + <braunr> unless you really want to work on it + <braunr> i dont' know + <teythoon> ah, so the node is destroyed but the translator is kept running? + that's what you mean by the above? + <teythoon> and ext2fs makes an effort of killing it in its node cleanup + code? + <braunr> yes + <braunr> grmbl, i'm lagging a lot + <braunr> i'm not sure + <braunr> ext2fs maintains it + <braunr> with ext2fs, translators can only be explicitely removed + <braunr> i mean, ext2fs keeps all node descriptors alive once accessed + <braunr> while procfs doesn't + <braunr> teythoon: ok, looks like i have a working patch that merely caches + the node for mounts + + <braunr> i installed my fixed procfs on darnassus, only one mtab :) + <teythoon> nice :) + + <braunr> i have a fix for the multiple mtab issue, will send a patch + tonight + + +## `/home` Missing + +### IRC, freenode, #hurd, 2013-10-04 + + <braunr> now, why is there no /home in df output ? + <teythoon> not sure + <teythoon> note how /dev/tty* end up in /proc/mounts, those are passive + translators too, no? + <braunr> yes + <braunr> but that's a good thing i guess + <braunr> or was mounts intended for file systems only ? + <braunr> well, in the unix traditional meaning + <teythoon> I think its nice too, yes + <teythoon> but why are they fine and your /home is not... + <braunr> that's weirder + <braunr> also, mounts actually doesn't show passive translators + <braunr> teythoon: does your code perform any kind of comparison ? + <braunr> i see /servers/socket/26 but not /servers/socket/2 + <braunr> s/comparison/filter/g + <teythoon> hmm + <teythoon> well, yes, try /hurd/mtab --insecure / + <teythoon> (I cannot connect to darnassus from here...) + <braunr> ok but that looks unrelated + <braunr> both /servers/socket/26 and /servers/socket/2 refer to the same + translator + <braunr> i was wondering if mtab was filtering similar entries based on + that + <teythoon> no + <braunr> that's weird too then, isn't it ? + <teythoon> yes ;) + <braunr> ok + <teythoon> btw, how is that done with the same traanslator being bound to + two nodes? settrans cannot do that, can it? + <braunr> no it can't + <braunr> the translator does it when started + <teythoon> ah + <braunr> (which means there is a race if both are started simulatneously, + although it's very rare and not hard to solve) + <teythoon> a weird beaving translator then :) + + <braunr> teythoon: if ext2fs is set active, mtab output reports it + + <braunr> teythoon: looks like this bug is what allows mtab not to deadlock + <braunr> teythoon: when i attach it as an active translator, cat freezes + + <braunr> teythoon: if (control && control->pi.port_right == fsys) + <braunr> that's the filtering i was previously talking about + + <braunr> oh please don't name global variables "path" ... + + +### IRC, freenode, #hurd, 2013-10-06 + + <antrik> teythoon: pty-s also bind to two nodes, not only pfinet + + +### IRC, freenode, #hurd, 2013-10-07 + + <braunr> teythoon: please tell us when you're available, we need to work + out the last mtab issues + <teythoon> braunr: I'm available now :) + <teythoon> I'm sorry, I've been very busy the last two weeks, but I've + plenty of time now + <braunr> great :) + <braunr> did you see youpi's mail ? + <braunr> i have the exact same question + <teythoon> I did + <braunr> it seems your code registers active translators + <braunr> but parent translators don't seem to register them when they're + created from passive translators + <braunr> or am i mistaken ? + <teythoon> I'll need a moment to get my hurd machine and myself up to + speed... + <teythoon> braunr: I concur with youpi, hooking into fshelp_fetch_root + should do just fine + <teythoon> I'll just try that + <braunr> ok + <braunr> how do you deal with mtab reporting itself ? + <teythoon> o_O does it do that? + <braunr> no, but it should + <braunr> when i set it as an active translator, i get a deadlock + <braunr> hm + <braunr> teythoon: before you change libfshelp, i'd like you to try + something else + <braunr> use more appropriate names for global variables in mtab.c + <braunr> in particular, the variable path clashes with local names + <teythoon> noted + <braunr> teythoon: as a side note (i'm not asking to rewrite anything) + <braunr> i strongly recommend a very explicit object oriented style of + coding + <braunr> (or data-oriented as it's sometimes called) + <braunr> use prefixes for all your interfaces so they can be made public if + needed (which acts as a namespace and avoids lots of collisions + naturally) + <braunr> use "constructors" and "destructors" (functions that both allocate + and initialize) + <braunr> this helps avoiding leaks a lot too + <teythoon> hm, I thought I did that, could you be more specific? + <braunr> ok didn't see the comment + <braunr> /* XXX split up */ error_t mtab_populate (... + <braunr> :) + <braunr> as a better example, see your code in libfshelp/translator-list.c + <braunr> struct translator should have been treated as an object + <braunr> this would probably have completely avoided any leaks in the first + place + <teythoon> braunr: right, I deviated from that style there + <braunr> teythoon: these are minor details, don't mind them too much, i + just find it helps me a lot + <teythoon> braunr: sure, I appreciate the feedback :) + + +### IRC, freenode, #hurd, 2013-10-08 + + <teythoon> braunr: I'm on to the passive translator not getting registered + issue + <teythoon> however, removing them from the list if the active translator is + killed does not work as expected... I still need to fiddle with the + notifications to get this right + <braunr> ok + + +### IRC, freenode, #hurd, 2013-10-16 + + <teythoon> braunr: btw, I fixed the 'passive translator not showing up in + proc/mounts'-issue + <teythoon> but 4 ports do leak each time a translator is killed and + reinstalled + <teythoon> this happens with passive ones as well as active ones + <braunr> teythoon: is that issue tied to your changed ? + <braunr> changes* + <teythoon> I'm not sure tbh, testing that is on my list of things to do + <braunr> ok + <braunr> first thing to know i guess + <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 + +[[open_issues/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 + + <braunr> teythoon: isn't there a leak in translator_ihash_cleanup ? + <teythoon> braunr: looks like, yes + <teythoon> braunr: I probably forgot to add the free (element->name) when I + added the name field + <braunr> teythoon: ok + <braunr> teythoon: i let you fix that :p + <teythoon> braunr: sure ;) diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn index 77162d8a..31432788 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 @@ -53,6 +53,82 @@ implementation. <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]] @@ -66,6 +142,10 @@ implementation. <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 @@ -86,3 +166,93 @@ implementation. 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..13b5e01b 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,42 @@ 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 + + +## [[hurd/fsysopts]] + +Doesn't support [[hurd/fsysopts]]. diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn index d5e0960c..924abc99 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 @@ -63,6 +64,11 @@ It is stated by `/hurd/init`. something special +## IRC, freenode, #hurd, 2013-09-25 + + <braunr> so nice to finally see proc in top :) + + # Process Discovery ## IRC, freenode, #hurd, 2013-08-26 @@ -73,3 +79,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 fc071337..628cb396 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 @@ -125,7 +125,9 @@ License|/fdl]]."]]"""]] <braunr> but when they do, they do +<a name="self"> # `/proc/self` +</a> ## IRC, freenode, #hurd, around 2010-09 @@ -151,6 +153,8 @@ License|/fdl]]."]]"""]] <antrik> in either case, it can't hurt to bring this up again :-) [[mtab/discussion]], *IRC, freenode, #hurd, 2013-09-07*. +Look at `[glibc]/hurd/lookup-retry.c` for how [[`FS_RETRY_MAGICAL` +lookups|interface/dir_lookup]] work. # root group @@ -348,6 +352,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 @@ -436,6 +469,89 @@ Also used in `[GCC]/intl/relocatable.c`:`find_shared_library_fullname` for `#ifdef __linux__`. +### IRC, freenode, #hurd, 2013-10-03 + + <camm`> what's the equivalent of cat /proc/self/maps on hurd? + <braunr> camm`: for now, /proc/self doesn't work as expected + <camm`> thanks, I just want to get a list of maps and protection status for + a running process -- how? + <braunr> vminfo + <camm`> thanks so much! I'm trying to debug an unexec failure on hurd when + a linker script is present. All works with the default script, but when + the text address is changed, unexec fails, running into a page with no + access in the middle of the executable: 0xc4b000[0x1000] (prot=0, + max_prot=RWX, offs=0xb55000) + <camm`> I get a segfault when trying to read from this page. + <braunr> unexec ? + <camm`> emacs/gcl/maxima/acl2/hol88/axiom use unexec to dump a running + image into a saved executable elf file. + <braunr> what is unexec ? + <braunr> ok looks like a dirty tool + <braunr> camm`: what is segfaulting, unexec or the resulting executable ? + <camm`> unexec opens the file from which the running program was originally + executed, finds its section start addresses, then writes a new file + replacing any data in the old file with possibly modified versions in + running memory. The reverse of 'exec'. + <camm`> the read from running memory delimited by the addresses in the + executable file is hitting a page which has been protected with *no* + access, and is segfaulting. Somehow, when the binary file is loaded, + hurd turning off all rights to this page. + <camm`> let me check the stack location ... + <camm`> ok I think I've got it -- hurd moves the sbrk(0) address away from + the end of .data (as reported by readelf) if the addresses are low, + presumably to avoid running into the stack. + <camm`> starting sbrk(0)!=.data+data_size on hurd + <braunr> i'm not sure there is anything like the heap on the hurd + <braunr> sbrk is probably implemented on top of mmap + <braunr> camm`: hm no, i'm wrong, glibc implements brk and sbrk mostly as + expected, but remapping the area isn't atomic + <braunr> "Now reallocate it with no access allowed" + <braunr> then, there is a call to vm_protect + <braunr> and no error checking + <braunr> ... + <camm`> ok, that's fine, but need to know -- in general there is no + relationship between the address returned by sbrk(0) and the .data + addresses reported by readelf on the file, (hurd only) yes? + <braunr> i don't know about that + <braunr> there should be .. + <camm`> Specific example: readelf -a -> [24] .data PROGBITS + 000f5580 0c4580 000328 00 WA 0 0 32 + <camm`> + <camm`> sbrk(0)->(void *) 0x8021000 + <braunr> camm`: is that on an executable or a shared object ? + <camm`> executable + <braunr> 000f5580 looks very low + <camm`> This is using a linker script. The default setup works just fine. + <camm`> I think it (might) make sense for hurd to silently do this give the + placement of the C stack, but the assumptions behind my algorithm need + changing (perhaps). + <camm`> (I probe in configure the allowable range of __executable_start, + and then choose a value to either ensure a large free signed range around + NULL, or a low data start to maximize heap) + <camm`> braunr: are there any guarantees of sbrk(0)==.data+size without a + linker script? + <braunr> camm`: i'm not sure at all + <braunr> sbrk isn't even posix + <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 @@ -471,3 +587,56 @@ Needed by glibc's `pldd` tool (commit <braunr> both htop and top seem to have problems report the cpu time <braunr> so i expect the problem to be in procfs + + +# IRC, freenode, #hurd, 2013-10-03 + + <braunr> teythoon: any reason the static variable translator_exists isn't + protected by a lock in procfs/rootdir.c ? + + +## IRC, freenode, #hurd, 2013-10-04 + + <braunr> teythoon: can you tell me why translator_exists isn't protected + from shared access in rootdir_mounts_exists ? + <teythoon> braunr: hm, dunno tbh, I probably thought the race was harmless + enough + <braunr> it probably is + <braunr> settrans -Rg doesn't work on procfs :( + + +# Kernel PID + +## IRC, freenode, #hurd, 2013-09-25 + + <braunr> hm cute, htop layout has become buggy, top just won't start + <teythoon> braunr: make sure your procfs knows the correct kernel pid + <teythoon> # showtrans /proc + <teythoon> /hurd/procfs -c -k 3 + <teythoon> we could have handled this nicer if procfs were integrated + upstream + <teythoon> we should probably just update the default + <braunr> teythoon: mhm + <braunr> $ fsysopts /proc + <braunr> /hurd/procfs --stat-mode=444 --fake-self=1 + <braunr> $ showtrans /proc + <braunr> /hurd/procfs -c + <pinotree> -c == --stat-mode=444 --fake-self=1 + <braunr> better indeed + <braunr> teythoon: thanks + + +## IRC, freenode, #hurd, 2013-10-04 + + <braunr> youpi: i fixed procfs on ironforge and exodar to be started as + procfs -c -k 3 + <braunr> without -k 3, many things as simple as top and uptime won't work + + +## IRC, freenode, #hurd, 2013-10-24 + + <gg0> braunr: i'm using your repo and i can't see cpu percentage in htop + anymore, all zeroes, confirmed? + <braunr> gg0: no + <braunr> gg0: you probably need to reset procfs + <braunr> gg0: settrans /proc /hurd/procfs -c -k 3 diff --git a/hurd/translator/short-circuiting.mdwn b/hurd/translator/short-circuiting.mdwn index 6f608fb2..438e8d80 100644 --- a/hurd/translator/short-circuiting.mdwn +++ b/hurd/translator/short-circuiting.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2012, 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 @@ -42,7 +43,8 @@ as translators at all. Translator short-circuiting is when a file system server implements the functionality of a passive translator itself, instead of actually starting it. For instance, all the [[`symlink`|symlink]] translator does is return -a `FS_RETRY_*` reply to the caller. So instead of starting it, the file +a [[`FS_RETRY_*`|interface/dir_lookup]] reply to the caller. +So instead of starting it, the file system server can simply continue the file name look-up internally by appending the target of the symbolic link to the path being looked-up. diff --git a/hurd/translator/term.mdwn b/hurd/translator/term.mdwn new file mode 100644 index 00000000..834ef9bd --- /dev/null +++ b/hurd/translator/term.mdwn @@ -0,0 +1,220 @@ +[[!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 +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]]."]]"""]] + +The *term* translator implements POSIX termios discipline. + + +# Open Issues + +## [[open_issues/Term_Blocking]] + +## Leaks/Not Re-used/Not Terminating + +[[!tag open_issue_hurd]] + + +### IRC, freenode, #hurd, 2013-10-14 + + <braunr> good news + <braunr> the terminal leak is related to privilege separation + +[[tschwinge]] confirming (using `ssh -t [machine] tty`) that with privilege +separation enabled there is this problem, and once disabled it goes away. + + <atheia> I love how, as an unknowing by-stander, that is somehow good news + :-) + <braunr> :) + <braunr> it's a good news because 1/ we have more knowledge about the issue + <braunr> and 2/ it may not even be a hurd bug + <braunr> but rather an openssh-on-hurd bug + <braunr> this explains why i didn't see the issue on anything else + (mach/hurd consoles, x terminals) + <braunr> and this will also indirectly solve the screen lockup issue + <teythoon> braunr: good catch :) + <braunr> s/a good news/good news/ + <atheia> ah, yes, both definitely good news. Congrats on the progress. + <braunr> i remember we used to disable privilege separation in the past + <braunr> i'll have to dig what made us use it + +[[news/2010-09]]. + + <braunr> interesting, screen seems to be affected nonetheless + <braunr> so it's something common to both screen and ssh privsep + <braunr> apparently, what sshd+privse and screen have in common is a fifo + <braunr> so it's probably a tricky hurd bug actually + + +### IRC, freenode, #hurd, 2013-10-16 + + <braunr> pflocal is leaking ports .. + <braunr> this might be what blocks terminals + * pinotree gives braunr a stick of glue + <braunr> thanks + + <braunr> pflocal leaks struct sock .. + <braunr> grmbl + + <braunr> hm nice, pflocal leaks each time a socket is bound and/or accepted + on + <braunr> looks like a simple ref mess + <pinotree> braunr: really? + <braunr> yes + <pinotree> a leak in pflocal feels strange, never noticed it taking lots of + memory (and it's used a lot) + <braunr> it's a port leak + <braunr> well + <braunr> no it's both a memory and port leak + <braunr> not sure which one is the root cause yet + <braunr> i guess server sockets aren't automatically unbound + <braunr> if you want to see the leak, just disable priv separation in ssh + (to avoid the terminal leak ....) and write a shell loop to start ssh + your_server echo hello + <braunr> google shows mails about the leak in the past + <braunr> i also hope it fixes the terminal leak, although i'm really not + sure :( + + +### IRC, freenode, #hurd, 2013-10-17 + + <braunr> hm nice, apparently, there is no pflocal leak + <braunr> but a libdiskfs one ! + <braunr> since ext2fs enables the ifsock shortcut + <braunr> seems like it leaks a reference on sock node deletion + <teythoon> braunr: have you looked at libdiskfs/dead-name.c? + <teythoon> braunr: I think I'm hunting a very similar problem + <braunr> i'm doing it now + <teythoon> I had the problem of dead name notifications not being delivered + <braunr> wow + <teythoon> b/c I held no reference to the ports_info thing, so the dead + name handler in libports could no longer find the pi struct, so the + notification was silently dropped + <braunr> i see + <braunr> but it looks like dropping a node makes sure the associated + sockaddr has been deleted if any + <teythoon> are you sure the node is dropped in the first place? + <braunr> no + <braunr> well + <braunr> i see something happenning at the pflocal side when removing the + node + <braunr> but there is still a send right lingering somewhere + <braunr> (see why we need a global lsof :p) + <teythoon> indeed + <braunr> i'll try portinfo with that option we talked about + <teythoon> yes + <braunr> 121 => 1682: send (refs: 1) + <braunr> yep, ext2fs still has it + <teythoon> (I wonder how portinfo does that...) + <braunr> i guess it imports rights from the target task + <braunr> and see if it gets the same name as a local right + <teythoon> makes sense + <braunr> easy to check + <teythoon> well, no, it cannot do that for receive rights + <braunr> it creates an empty task just for that purpose + <braunr> and uses mach_port_extract_right + <teythoon> but it works as you described, yes + <braunr> so yes it does work for receive rights too + <teythoon> yes + <teythoon> cool :) + <braunr> so it assumes identical port names are part of the ipc interface + <braunr> something neal said we shouldn't rely on + <braunr> iirc + <teythoon> yes, I remember something like that too + <braunr> here is the strange thing + <braunr> node->sockaddr is deallocated on a dead name notification + <braunr> drop_node checks that sockaddr is null + <braunr> so how can the dead name notification occur before the node is + dropped ? + <braunr> so maybe the node is still around indeed + <braunr> apparently, libdiskfs considers the address holds a reference on + the node + <braunr> on the other hand, the server socket won't get released unless the + address gets a no-sender notification ... + <braunr> this should probably be turned into a weak reference + <braunr> teythoon: indeed, the node is leaked + + <braunr> pflocal crashes when removing correctly deallocating addresses and + removing server sockets :/ + + <braunr> ok, pflocal bug fixed + <braunr> still have to fix the libdiskfs leak + <braunr> and libdiskfs leak fixed too + <braunr> :) + <braunr> i'll build hurd packages with my changes to make sure i don't + break something before comitting + <braunr> and see if this fixes the term issue + + <braunr> looks like my patches work just fine :) + <braunr> it doesn't solve the term issue though + + <braunr> so, according to portinfo, pflocal has send rights to terminals oO + + <braunr> mhhhmmmmmm + <braunr> openssh seems to pass terminal file descriptors through unix + sockets when using privilege separation + <pinotree> braunr: i a write(sock, &pid, sizeof int) (or the like)? + <pinotree> *ie + <braunr> not pid, file descriptors + <braunr> SCM_RIGHTS + <pinotree> ah ok + <braunr> the socket send/recv interface does support passing mach ports + <braunr> and the leaked ports do turn into dead names when i kill terminals + <pinotree> yes, we support with a patch pochu did few years ago + <braunr> so it seems the leak is related to libpipe this time + <braunr> ok got it :) + <braunr> pflocal used copy_send instead of move_send + <braunr> \o/ + <braunr> that bug was such a pain + * braunr happy + <teythoon> :) + <pinotree> speaking of it, in pflocal' S_socket_recv is it correct the + "out_flags = 0;"? + <braunr> nice catch + <braunr> although i wonder why flags are returned + <braunr> it may have been set to null to tell us that we don't want to + return flags + <braunr> pfinet seems to use it + <pinotree> but you change a local variable anyway + <braunr> yes it's not useful + <braunr> hmm + <braunr> out_flags is what gets in struct msghdr -> msg_flags + <braunr> so i guess it makes sense to fix it to *out_flags = 0, just to be + safe + <braunr> pinotree: do you want me to push it tonight along with the others + ? + <pinotree> yes please + <braunr> ok + <pinotree> thanks! + <braunr> pflocal seems to not leak any memory or ports at all + <braunr> great :> + + <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]] + + +### IRC, freenode, #hurd, 2013-10-14 + + <braunr> i fixed term so that screen can shutdown properly + <braunr> read() wouldn't return EIO after terminal hangup + + +### IRC, freenode, #hurd, 2013-10-17 + + <braunr> and the missing EOI prevented screen from correctly shutting down + windows diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn index 20aba837..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]] @@ -430,3 +432,72 @@ License|/fdl]]."]]"""]] <youpi> ok <youpi> but that indeed means writeback of ext2fs works, which is a good sign :) + + +# IRC, freenode, #hurd, 2013-10-04 + + <teythoon> btw, I noticed that fifos do not work on tmpfs + <braunr> teythoon: tmpfs seems limited, yes + <teythoon> that's annoying b/c /run is a tmpfs on Debian and sysvinit + creates a crontrol fifo there + <teythoon> I wonder why I didn't notice that before + <braunr> also, fifos, like symlinks, can be shortcircuited in libdiskfs + <braunr> i wonder if that has anything to do with the problem at hand + +[[mtab/discussion]], *Multiple mtab Translators Spawned*. + + <teythoon> b/c this breaks reboot & friends + <teythoon> I do too + <teythoon> b/c I cannot find any shortcut related code in tmpfs + <braunr> well, it's optional normally + <braunr> so that's ok + <braunr> but has it really been tested when the option wasn't there ? :) + <teythoon> yes, but the tmpfs requests this by setting diskfs_shortcut_fifo + = 1; + <pinotree> hm i remember tmpfs was said to be working with + sockets/fifos/etc, back then when it was fixed + <braunr> teythoon: oh + + +## IRC, freenode, #hurd, 2013-10-11 + + <teythoon> this will have to wait for the next hurd pkg unfortunately, b/c + I broke tmpfs by accident :-/ + <pinotree> how so? + <teythoon> the dropping of privileges broke passive translators and mkfifo + <braunr> there actually is a reason why those are run as root or with the + 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 diff --git a/hurd/translator/unionfs.mdwn b/hurd/translator/unionfs.mdwn index 2fcd1fad..06524f3e 100644 --- a/hurd/translator/unionfs.mdwn +++ b/hurd/translator/unionfs.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 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 @@ -116,7 +116,7 @@ one will see the information about the `<translator>`, not the `unionfs` translator. Although this might seem the only natural way to do union mounts, one must keep in mind that such transparency deprives one of the possibility to modify the unioned virtual -filesystem exported by `unionfs` at run-time (via `fsysopts`). +filesystem exported by `unionfs` at run-time (via [[fsysopts]]). One can create a nontransparent union mount with the following command: @@ -127,7 +127,7 @@ When running $ fsysopts <node> one will see the information about the `unionfs` translator. Although -this way allows modifying the contents of the unioned filesystem +this way allows [[modifying|fsysopts]] the contents of the unioned filesystem exported by `unionfs` at runtime, the access to `<translator>` is blocked. diff --git a/hurd/translator/wishlist.mdwn b/hurd/translator/wishlist.mdwn index 5b473a2d..4d074df0 100644 --- a/hurd/translator/wishlist.mdwn +++ b/hurd/translator/wishlist.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 @@ -307,10 +307,3 @@ Firmlink to a file according to a filename matching pattern. When a file goes aw ## alphabetfs Organize a large group of files by their first letter. Present one subdirectory for each letter in the alphabet. - -## fsysoptsctl - -Send an fsysopts command to a set of translators. When you have a directory full of translators and you want to send each of them the same runtime option, this translator can do it for you. - - $ settrans -ac all /hurd/fsysoptsctl '/tmp/mystuff/*' - $ fsysopts all --update |