summaryrefslogtreecommitdiff
path: root/hurd/translator
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@codesourcery.com>2014-02-26 12:32:06 +0100
committerThomas Schwinge <thomas@codesourcery.com>2014-02-26 12:32:06 +0100
commitc4ad3f73033c7e0511c3e7df961e1232cc503478 (patch)
tree16ddfd3348bfeec014a4d8bb8c1701023c63678f /hurd/translator
parentd9079faac8940c4654912b0e085e1583358631fe (diff)
IRC.
Diffstat (limited to 'hurd/translator')
-rw-r--r--hurd/translator/auth.mdwn228
-rw-r--r--hurd/translator/discussion.mdwn165
-rw-r--r--hurd/translator/ext2fs.mdwn332
-rw-r--r--hurd/translator/mtab/discussion.mdwn552
-rw-r--r--hurd/translator/pfinet/implementation.mdwn180
-rw-r--r--hurd/translator/pflocal.mdwn36
-rw-r--r--hurd/translator/proc.mdwn68
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn50
-rw-r--r--hurd/translator/term.mdwn8
-rw-r--r--hurd/translator/tmpfs/discussion.mdwn36
10 files changed, 1642 insertions, 13 deletions
diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn
index 10cfb3aa..68bbce44 100644
--- a/hurd/translator/auth.mdwn
+++ b/hurd/translator/auth.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2008, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2013, 2014 Free Software Foundation,
+Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -19,3 +20,228 @@ It is stated by `/hurd/init`.
[[*The_Authentication_Server*|documentation/auth]], the transcript of a talk
about the details of the authentication mechanisms in the Hurd by Wolfgang
Jährling.
+
+
+## IRC, freenode, #hurd, 2013-10-31
+
+[[!tag open_issue_documentation]]
+
+ <braunr> is there an in-depth documentation somewhere about the auth server
+ that explains why there are "reauthenticate" operations everywhere ?
+ <braunr> nice, hammar's thesis does it :)
+
+[[hurd/documentation]], *Generalizing mobility for the Hurd*, Carl Fredrik
+Hammar.
+
+
+## IRC, freenode, #hurd, 2013-11-01
+
+ <gnu_srs> neal: Thanks, I'm trying to to call auth_server_authenticate
+ from a libc function, but that fails. That function returns MIG_NO_REPLY.
+ <gnu_srs> auth_user_authenticate works OK, but I need the IDs from the
+ auth_server_authenticate. What to do, implement a new RPC,
+ <gnu_srs> modify auth_user_authenticate (probably not) ?
+ <gnu_srs> or modify auth_server_authenticate (probably not)
+ <youpi> gnu_srs: show the source code you have written. MIG_NO_REPLY is not
+ expected, unless you called server_authenticate on the wrong port
+ <gnu_srs> S_auth_server_authenticate does not have any other exits than
+ MIG_NO_REPLY (and errors)
+ <gnu_srs> auth/auth.c
+ <youpi> yes, but it does do auth_server_authenticate_reply, which is what
+ matters
+ <youpi> i.e. what provides the answer
+ <youpi> (and the uids etc.)
+ <gnu_srs> I don't seem to be able to call that function directly from libc?
+ <youpi> eh? You're not supposed to call auth_server_authenticate_reply
+ yourself, it's auth which is supposed to
+ <youpi> precisely to provide the reply to the auth_server_authenticate RPC
+ <youpi> again, please show your source code
+ <youpi> there must be some mistake
+ <gnu_srs> Please show me how to call auth_server_authenticate and that
+ function returning 0
+ <youpi> there are plenty of examples in the hurd source code
+ <youpi> e.g. ext2fs
+ <youpi> or libdiskfs, I can't remember where it is exactly inside ext2fs
+ <gnu_srs> I've tried all, on avail:(
+ <gnu_srs> no*
+ <youpi> € git grep auth_server_auth
+ <youpi> libiohelp/iouser-reauth.c: err = auth_server_authenticate
+ (authserver,
+ <youpi> was it so hard?
+ <gnu_srs> I did, and tried every combination, nothing works!
+ <youpi> something has to work, otherwise we'd have no uid authentication
+ against ext2fs
+ <youpi> so there must be a combination you missed
+ <youpi> did you understand how the authentication protocol works, for a
+ start?
+ <youpi> otherwise, random code will most probably never work, for sure :)
+ <gnu_srs> called from libc?
+ <gnu_srs> a libc function?
+ <youpi> being from a libc function or from an io_reauthenticate callback
+ does not really matter
+ <gnu_srs> well, random or not, please show me then
+ <youpi> it's already there in ext2fs
+ <youpi> again, if you don't understand *that* code, no need to try to write
+ other code, take time to understand what exactly happens in the ext2fs
+ case
+ <gnu_srs> ok, can you tell me how a function only returning MIG_NO_REPLY
+ can return 0 when called?
+ <gnu_srs> by a server or client
+ <youpi> maybe one thing you are missing: in the ext2fs case, we have the
+ sender use io_reauthenticate to provide the receiver (ext2fs) with the
+ reference port, in the sendmsg/recvmsg, it'll be the message which will
+ hold the ref port
+ <youpi> but otherwise it's all the same
+ <youpi> gnu_srs: as I said, by being called on the proper port,
+ <youpi> i.e. the auth port, with the ref port provided by the sender
+ <youpi> but again, without seeing your code, I can't divine what mistake
+ you may have done
+ <youpi> all I can do is that your code is supposed to really look very much
+ like the ext2fs case
+ <gnu_srs> there is a difference between io_reauthenticarte and
+ proc_reauthenticate, a subsequent call to auth_user_authenticate returns
+ 0 in the second case.
+ <youpi> i.e. _hurd_setauth in hurd/setauth.c and iohelp_reauth in
+ libiohelp/iouser-reauth.c
+ <youpi> why are you talking about io_reauthenticate an proc_reauthenticate?
+ <youpi> again, without seeing your source code, I can't understand what you
+ are talking about
+ <gnu_srs> first: (17:06:23) srs: ok, can you tell me how a function only
+ returning MIG_NO_REPLY can return 0 when called?
+ <youpi> and I can't afford the time to divine
+ <youpi> yes, that's iohelp_reauth in libiohelp/iouser-reauth.c
+ <youpi> for an example that works
+ <youpi> by using the proper ports
+ <youpi> if you don't get a reply, it's most probably simply because the
+ reply goes to the wrong port
+ <gnu_srs> again, where/how is the return value communicated by
+ auth_server_authenticate to the client/caller?
+ <youpi> again, it's the auth/auth.c code
+ <youpi> which calls auth_server_authenticate_reply
+ <gnu_srs> but that function ends with return MIG_NO_REPLY?
+ <youpi> yes, because auth_server_authenticate_reply() already did provide
+ the reply
+ <youpi> so the RPC function does not return a reply
+ <youpi> since it already explicitly sent one
+ <youpi> through auth_server_authenticate_reply
+ <gnu_srs> and exits earlier?
+ <youpi> it doesn't exit earlier
+ <youpi> it first calls auth_serveru_authenticate_reply
+ <youpi> and then returns with MIG_NO_REPLY
+ <gnu_srs> how the fck should i know that?
+ <youpi> by reading MIG documentation?
+ <youpi> I believe that _request/_reply mechanism is documented there
+ <gnu_srs> MIG magic again:( It strikes back, whatever you do to avoid it
+ <youpi> at least I don't think I have divined how it was working, so I must
+ have read that in some documentation
+ <youpi> it's not magic
+ <youpi> you just have to read the doc to understand how it works
+ <gnu_srs> I've not found any good doc on MIG yet.
+ <youpi> depends what you call "good"
+ <youpi> MIG is a complex thing, so documentation is complex, yes
+ <youpi> that can't really be avoided
+ <gnu_srs> mig.pdf
+ <gnu_srs> again: how can a function returning MIG_NO_REPLY return 0 when
+ called (as current implementations show)?
+ <youpi> again, by using the proper ports
+ <youpi> if not using the proper ports, the reply goes to another port
+ <youpi> and thus no reply
+ <youpi> and again, without showing the source code, we can't divine how you
+ didn't use the proper ports
+ <gnu_srs> so you mean a reply to a port is the same as the error code
+ returned?
+ <youpi> not always exactly, but basically yes
+ <youpi> gnu_srs: *again* , *really*, showing us what you've come up with
+ would very *most* probably allow us to help you
+ <youpi> otherwise it's just guess work and misunderstandings
+ <gnu_srs> FYI: there is no libc function calling auth_server_authenticate
+ directly
+ <youpi> sure
+ <youpi> that doesn't mean it can't
+ <gnu_srs> and here is one code example, not even trying to send+receive, it
+ is only in recvmsg.c: http://paste.debian.net/63374/
+ <youpi> why is that code doing both auht_user_auth and auth_server_auth ?
+ <youpi> it's the sender side which is supposed to call auth_user_auth
+ <youpi> and why are you calling proc_reauthenticate, that has nothing to do
+ with the matter at stake
+ <gnu_srs> sorry, you can remove that part, same result
+ <youpi> ok but auth_user_authenticate should really go to the sender side
+ <youpi> s/should/must
+ <youpi> it is supposed to hang until auth_server_authenticate gets called
+ by the receiver
+ <youpi> so putting both on the receiver can not work
+ <youpi> at best auth_user_authenticate would hang, waiting for the
+ auth_server_authenticate which is called just after that...
+ <youpi> don't try random code, that can't work
+ <youpi> follow what I said
+ <youpi> in my mail
+ <gnu_srs> I did issue auth_user_authenticate on the send side, and
+ auth_server_authenticate on the receive side.
+ <gnu_srs> that was the path I followed, then when nothing worked,. I tried
+ the receive side only.
+ <youpi> that's why I said don't try random code
+ <youpi> it can't work with receive side only
+ <youpi> really, go as I said
+ <youpi> send / receive
+ <youpi> there must be something you made wrong
+ <gnu_srs> in the beginning it was not random code;)
+ <youpi> but it's not a reason for stabbing in the dark with random code,
+ that just can't work
+ <youpi> then stay with the code at the beginning
+ <youpi> and don't start writing random code
+ <youpi> that approach can *not* work
+ <gnu_srs> still when issuing __proc_reauthenticate followed by
+ auth_user_authenticate on the send side the port delivered is 0,
+ i.e. unusable
+ <youpi> why calling proc_reauthenticate??
+ <youpi> it has nothing to do with the auth_*_authenticate protocol
+ <youpi> really
+ <youpi> what made you believe it was part of it?
+ <gnu_srs> dunno, if you say so;)
+ <youpi> it's not even mentioned in the documentation I referred to in my
+ mail
+ <youpi> again, make sure you actually *understand* the auth_*_authenticate
+ protocol
+ <gnu_srs> I found it in the already implemented code.
+ <gnu_srs> and process.defs
+ <youpi> for the proc_authenticate protocol, sure
+ <youpi> but that has nothing to do with the auth_*_authenticate protocol
+ <gnu_srs> well, the hurd documentation does not cover the proc case only
+ the io case, unfortunately:( Marcus, please write more documentation:-D
+ <youpi> it's just the same
+ <youpi> exactly the same
+ <youpi> ok, now I understand what happend: you followed some code which was
+ doing the auth protocol with the proc translator, not with the ext2fs
+ translator
+ <youpi> and you had *not* understood what proc_reauthenticate was doing
+ there
+ <youpi> you should have followed some code which was doing the auth
+ protocol with the ext2fs translator, i.e. through io_reauthenticate, of
+ course
+ <youpi> if you read random code, there's no way you can understand it of
+ coruse
+ <youpi> again, read hurd/setauth.c
+ <youpi> it does the reauthentication with ext2fs, through io_reauth to give
+ the ref prot
+ <youpi> s/prot/port
+ <youpi> io_reauth has to be replace with a port send over the socket of
+ course
+ <youpi> if that's obvious, don't write code, and ask yourself whether you
+ have really understood the auth protocol at all
+ <youpi> s/that's obvious/that's not obvious/
+ <youpi> understand means being able to match the source code of setauth.c
+ with the explanation from marcus
+ <gnu_srs> I'm learning all the time, in a few years I will be able to
+ contribute seriously;-) but the MIG stuff, I dunno:(
+ <youpi> well, the problem is that it takes us a hell lot of time to explain
+ you things
+ <youpi> just because you don't seem to manage to learn without going
+ randomly
+ <gnu_srs> just reading source code is a random process, unfortunately.
+ <youpi> ?!
+ <youpi> sure not
+ <youpi> if you do it randomly, then it's not wonder you're getting random
+ <youpi> don't read it randomly
+ <youpi> follow paths
+ <youpi> I've never read code randomly, it's a loss of time and a way to
+ just mix everything together without understanding anything
diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn
index 95f5ab0c..70a6efee 100644
--- a/hurd/translator/discussion.mdwn
+++ b/hurd/translator/discussion.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013, 2014 Free Software Foundation,
+Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -10,6 +11,8 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_documentation open_issue_hurd]]
+[[!toc]]
+
# IRC, freenode, #hurd, 2011-08-25
@@ -45,3 +48,163 @@ License|/fdl]]."]]"""]]
..
<braunr> but at least, thread consumption will correctly decrease with
inactivity
+
+
+# IRC, freenode, #hurd, 2014-01-30
+
+ <sjbalaji> can any one exmplain me hello translator ? I am new to hurd
+ <teythoon> sjbalaji: sure, what do you want to know ?
+ <teythoon> how to use it ?
+ <sjbalaji> No I mean what is the main reason of that translator. I am
+ familiar with Linux.
+ <gnu_srs> sjbalaji: start with:
+ https://www.gnu.org/software/hurd/hurd/documentation/translator_primer.html
+ <sjbalaji> I ran that example but I am still clueless about the actual
+ reason behind the translators and this simple hello world translator
+ example.
+ <teythoon> sjbalaji: the Hurd is a multiserver os, almost all functionality
+ lives in userspace servers called 'translators'
+ <teythoon> sjbalaji: the Hurd uses the file system as namespace to lookup
+ these servers
+ <teythoon> e.g. /servers/socket/1 is /hurd/pflocal and handles pipes and
+ unix socket communication
+ <sjbalaji> I can see from the example that a hello file is associated with
+ a /hurd/hello translator
+ <teythoon> yes
+ <teythoon> think of translators like FUSE-based filesystems, only more
+ general
+ <teythoon> b/c translators are not restricted to provide filesystem-like
+ services
+ <sjbalaji> So this example hello translator just adds hello world in the
+ associated file, am I correct ?
+ <teythoon> it's not adding stuff to a file
+ <teythoon> say you did settrans -ac /tmp/hi /hurd/hello, if you do cat
+ /tmp/hi, cat does some rpc calls to the started /hurd/hello program that
+ returns 'hello world' as the file contents
+ <teythoon> in a sense /hurd/hello is a 'filesystem' that provides a single
+ file
+ <sjbalaji> So is it like hello is the mount moint for that hello server ?
+ <teythoon> sjbalaji: yes, kind of that, but in a more general sense
+ <sjbalaji> teythoon: How can I see the different servers that are running
+ in the system ? I tried top in the terminal but it returned cannot find
+ /proc/version
+ <teythoon> sjbalaji: so it seems your procfs is not running, try as root:
+ settrans /proc /hurd/procfs -c
+ <sjbalaji> teythoon: But how does one differentiate between a server and a
+ normal process ?
+ <teythoon> one does not
+ <teythoon> for a rule of thumb: anything from /hurd is a translator
+ <teythoon> you can view a nodes passive translator record using showtrans,
+ e.g. showtrans /dev/hd0
+ <sjbalaji> Is there something like a man page for translators ? Like how to
+ work with them or to figure out what services are offered by them ?
+ <teythoon> well, there is --help
+ <teythoon> also, go to /dev and /servers and look around using showtrans or
+ fsysopts
+ <sjbalaji> teythoon: What is the difference between a nodes active and
+ passive translator ?
+ <teythoon> a passive translator record is stored in the file system for the
+ node
+ <teythoon> if the node is accessed, and no translator is currently running,
+ it is started on demand
+ <teythoon> we call a running translator an active one
+ <sjbalaji> So the hello translator in the example is a passive one ?
+ <teythoon> if you used settrans foo /hurd/hello, a node foo is created with
+ an passive translator record
+ <teythoon> if you used settrans -a foo /hurd/hello, the translator is
+ started immediately
+ <sjbalaji> teythoon: What do you mean by a passive translator record ?
+ <teythoon> sjbalaji: it's an argv-vector encoded in the filesystem
+ (currently, only ext2 supports this)
+ <teythoon> in ext2, it is stored in a block and a os-specific field in the
+ inode points to that block
+ <sjbalaji> teythoon: I can't understand the logic behind that :(
+ <teythoon> this way, the servers are started on demand
+ <sjbalaji> But once they are invoked they are always online after that.
+ <teythoon> yes
+ <sjbalaji> I thought that the server goes down once its used
+ <gnu_srs> teythoon: shouldn't the passive ones time out if unused?
+ <teythoon> yes, that's how it was intented to be, but that has been
+ patched-out in debian/hurd
+ <gnu_srs> reason?
+ <teythoon> i don't know the details, but there is a race condition
+
+(`libports_stability.patch`.)
+
+
+# IRC, freenode, #hurd, 2014-01-31
+
+ <sjbalaji> How can I see the complete control flow when I run the hello
+ translator example ?
+
+
+# IRC, freenode, #archhurd, 2014-02-05
+
+ <CalimeroTeknik> plus I discussed quickly that idea with Richard Stallman
+ and he told me translators had a conception flaw that would forbid such a
+ system to be usable
+
+
+## IRC, freenode, #archhurd, 2014-02-06
+
+ <antrik_> CalimeroTeknik: the "conceptal problem" rms told you about was
+ probably the simple issue that translators are always followed, even if
+ they are run by another user
+ <antrik> CalimeroTeknik: the conceptal problem is only in that the original
+ designers believed that would be safe, which it isn't. changing that
+ default policy (to be more like FUSE) wouldn't do much harm to the Hurd's
+ features, and it should be easy to do
+ <antrik> it's just nobody bothered so far, because it's not a big deal for
+ typical use cases
+ <antrik> rms isn't really in touch with Hurd development. he was made to
+ believe it was a fundamental issue by a former Hurd developer who got
+ carried away; and he didn't know enough to realise that it's really not a
+ big deal at all
+
+
+# Candidates for Google Summer of Code [[community/gsoc/Project_Ideas]]
+
+## Extend `ls` et al. for Translators
+
+### IRC, freenode, #hurd, 2014-02-08
+
+ <youpi> heh
+ <youpi> I was wondering what that incoming/ directory was in my home
+ <youpi> ls gave me hundreds of packages
+ <youpi> then I remembered I had /hurd/httpfs http://incoming.debian.org/ on
+ it :)
+ <cluck> if only there were an easy and automated way to make ls and file
+ managers (like dired!) aware of links, mounts and translators :)
+ <youpi> cluck: what do you mean by "awaree"?
+ <cluck> someting like: lrwxrwxrwx 1 foo foo 31 Aug 21 18:01
+ my_translator-23.0 -> ../some/fakefs /some_parameters*
+ <cluck> (yes, i realize it goes against some security practices but maybe
+ there could be a distinction like with soft/hard links that made it
+ opaque for some use cases)
+
+
+## Passive Translators
+
+### IRC, freenode, #hurd, 2014-02-12
+
+ <braunr> well don't expect rsync to save passive translator records ..
+ <braunr> i recommend you save either the entire disk image or the partition
+ <gg0> should i expect it from tar/cp ?
+ <braunr> no
+ <braunr> i'm not even sure dumpe2fs does it
+ <braunr> the only reliable way is to save the block device
+ <azeem> might be a worthwhile GSOC
+ <azeem> "implement Hurd specific features in GNU utilities"
+ <azeem> there were some patches floating around for some things in the past
+ IIRC
+ <antrik> azeem: the plan for supporting Hurd features in FS utilities was
+ exposing them as xattrs, like Roland's Linux patch did... cascardos once
+ did some work on this, but don't remember how far he got
+
+[[community/gsoc/project_ideas/xattr]].
+
+ <antrik> you are right though that it would make for a good GSoC project...
+ <antrik> of course, *some* utilities would still benefit from explicit Hurd
+ support -- most notably ls
+ <azeem> IIRC there were also ls patches at one point
+ <antrik> can't recall that... but maybe it was befor my time ;-)
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index cfd09502..ba849cca 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013 Free Software
-Foundation, Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013, 2014 Free
+Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -214,6 +214,334 @@ That would be a nice improvement, but only after writeback throttling is impleme
<teythoon> tschwinge: well, thanks anyway ;)
+## IRC, freenode, #hurd, 2014-02-11
+
+ <gg0> task with pid 5 deallocating an invalid port 4622, most probably a
+ bug.
+ <gg0> ext2fs
+ <teythoon> yes, i've seen this
+ <teythoon> e.g. when a passive translator starts
+ <teythoon> i guess it is in libfshelp/translator-list.c
+
+
+## Inode Sizes, Fragment and Block Sizes
+
+### IRC, freenode, #hurd, 2014-02-12
+
+ <gg0> this might be interesting and could make people not to fsck hurd
+ filesystem on linux:
+ <gg0> start ext2fs: ext2fs: device:hd0s1
+ <braunr> ?
+ <gg0> : panic: get_hypermetadata: inode size 256 isn't supported
+ <gg0> (wait, also a bad typist)
+ <braunr> well, if the file system was created from the hurd, or with -o
+ hurd, as it ought to be, you wouldn't have this problem
+ <gg0> oh, good to know, especially before restoring :p
+ <braunr> i suspect your mkfs command to have created an ext4 fs
+ <gg0> nope mkfs.ext2
+ <braunr> hm ok, so it seems to create 256 size inodes by default there
+ <gg0> i guess -o hurd would set some os-specific properties
+ <braunr> it merely enforces a few restrictions
+ <gg0> some predefined defaults
+ <braunr> fragments and blocks are 4k
+ <braunr> and apparently inodes are 128 bytes
+ <gg0> because it can't support bigger values? is it worth working on remove
+ such restrictions?
+ <braunr> probably not so far
+ <braunr> certainly not the fragment/block size restriction
+ <braunr> it matches the page size
+ <braunr> larger inode sizes could be supported if they're dependencies for
+ other worthwhile features such as those someone would add in an ext4
+ translator
+
+
+## Linux' `CONFIG_EXT4_USE_FOR_EXT23`
+
+### IRC, freenode, #hurd, 2014-02-12
+
+ <gg0> why the hell i have thousands of Inode 839, i_blocks is 248, should
+ be 256. Fix<y>? yes
+ <gg0> in all cases i_blocks should be +8
+ <gg0> and /dev/sda1: (There are 245635 inodes containing multiply-claimed
+ blocks.)
+ <gnu_srs1> 10:50:08< gg0> start ext2fs: Hurd server bootstrap:
+ ext2fs[device:hd0s1] exec
+ <gnu_srs1> That's exactly where my image boot hangs!
+ <gg0> start ext2fs: Hurd server bootstrap: ext2fs[gunzip:device:rd0] exec
+ <AliciaC> gnu_srs1: you might want to check that linux isn't using the ext4
+ module to handle ext2 and ext3 filesystems
+ <AliciaC> gnu_srs1: as I understand it the idea is that the ext4 module
+ treats them as ext2/ext3 filesystems, just avoiding code duplication from
+ having three separate modules for related filesystems, so it shouldn't
+ change it from ext2 at all, but it does do something strange with it
+ <AliciaC> but I'm not sure if that's the case or if it's converting it to
+ ext4. last I heard Hurd doesn't support anything beyond ext2
+ <gnu_srs1> AliciaC: I did use ext2 when mounting from Linux: mount -t ext2
+ /dev/loop0 /mnt
+ <gnu_srs1> and when not mounted: e2fsck /dev/loop0
+ <AliciaC> gnu_srs1: I'd check the kernel config to be sure,
+ CONFIG_EXT4_USE_FOR_EXT23 must be disabled
+ <braunr> you can use the ext4 driver for ext2
+ <braunr> that's not a problem here
+ <braunr> the problem happens long before, when the file system gets
+ corrupted
+ <braunr> you must understand why
+ <AliciaC> I have done some testing on this, mounting a Hurd ext2 filesystem
+ with the ext4 module broke it for me, an easily repeated issue
+ <AliciaC> mounting Debian's ext2 image and unmounting it with ext4 broke
+ it, resulting precisely in the kind of hang ups mentioned by gnu_srs1 and
+ gg0
+ <braunr> interesting
+ <AliciaC> that's with a clean image with nothing corrupting it before hand,
+ tested to be working as well
+ <braunr> ok so the ext4 driver must ignore hurd specific stuff
+ <braunr> that's strange because i recall using it to perform small repairs
+ on darnassus and never had any issue
+ <braunr> even on the root file syste
+ <braunr> but my repairs were very quick and targetted
+ <AliciaC> different linux versions maybe
+ <AliciaC> when I was testing it I didn't even need to do anything in the
+ filesystem to trigger the issue, just mount and unmount
+ <gnu_srs1> I repaired filesystems before like this, has something happened
+ with later versions of Linux?
+ <gnu_srs1> One of my boxes is ext3 (probably worked before) another ext4
+ (the one breaking things, but worked before)
+ <gnu_srs1> ext3 and ext4 box: CONFIG_EXT4_USE_FOR_EXT23=y same kernel
+ 3.12-1.amd64
+ <gnu_srs1> what about mounting with bs=4096 (used by hurd)
+ <braunr> -t ext2 should work fine
+ <braunr> just don't use the ext4 driver if in doubt
+ <gg0> no difference between specifying -t or not, in both cases EXT4-fs
+ (sda1): mounting ext2 file system using the ext4 subsystem
+ <braunr> hmm
+ <braunr> you're screwed then ;
+ <braunr> ;p
+ <braunr> or maybe -t ext3 .. :)
+ <braunr> although i suspect ext4 would be used then too
+ <gg0> linux-image-3.2.0-4-amd64:
+ /lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko
+ <gg0> wheezy still has it. then something between 3.2.0 and 3.13(?) removed
+ it
+ <braunr> check the config file
+ <gg0> i mean ext2 module
+ <braunr> check if the config file enables it
+ <gnu_srs1> It's not: # CONFIG_EXT2_FS is not set
+ <gg0> 14:42 < gg0> wheezy still has it. then something between 3.2.0 and
+ 3.13(?) removed it
+ <braunr> how about retrying what you did without ever mounting from linux ?
+ <braunr> gg0: it wasn't clear enough that you meant removed from
+ configuration
+ <braunr> (for example, it could have been blacklisted)
+ <gg0> or present not as a module
+ <braunr> maybe yes, although it's unusual to see generic kernels embedding
+ file systems these days
+ <AliciaC> the CONFIG_EXT4_USE_FOR_EXT23 option isn't available if either
+ ext2 or ext3 are enabled though, even just as loadable modules
+ <gnu_srs1> The ext2 and ext3 modules were there in 3.10-3, not in 3.12-1
+ <gnu_srs1> (14:48:59) <srs>: It's not: # CONFIG_EXT2_FS is not set --
+ 3.12-1
+ <gg0> https://bugs.debian.org/731072
+ * gg0 rsync'ing back to new fs with 3.10 kernel
+ <gnu_srs1> seems like this bug was archived without being closed??
+ <gg0> someone should produce a testcase and file another one btw
+ <gnu_srs1> but that bug was for files systems up to 4MB, not 4GB?
+ <gg0> i pasted it just because submitter talks about config option in
+ question and when was enabled
+ <gg0> don't we want to thank AliciaC who pointed it out and who could
+ precisely file a bug? :)
+ <gg0> filed http://bugs.debian.org/738758
+ <braunr> gg0: thanks
+ <braunr> AliciaC: and thanks too
+
+
+### IRC, freenode, #hurd, 2014-02-13
+
+ <gnu_srs> gg0: Did you create and test with an ext2 Linux image too on
+ 3.10/3.12?
+ <gnu_srs> here is a diff: http://paste.debian.net/81837/
+ <gnu_srs> visible differences: Filesystem features:filetype (linux only)
+ and Free inodes:1268(hurd) / 1269(linux)
+ <AliciaC> between one created with -o Hurd and one created with -o Linux
+ (or no -o)?
+ <gnu_srs> AliciaC: -o Hurd and -b 4096 (no -o)
+ <AliciaC> I wonder if that would show any interesting difference between an
+ untouched -o Hurd ext2 image and a copy of it that has been mounted with
+ the ext4 module
+ <gnu_srs> AliciaC: here: http://paste.debian.net/81857/
+ <gnu_srs> there is a difference of one in the number of free inodes!
+ <gnu_srs> cf the number of free inodes for linux
+ <AliciaC> gnu_srs: thanks :) though I don't know what to make of that, I
+ guess just adding an inode shouldn't break anything
+ <AliciaC> wait, no, removing an inode?
+ <AliciaC> bleh, too tired, read it wrong
+ <gnu_srs> this line should read:(11:37:48) srs: visible differences:
+ Filesystem features:filetype (linux only) and Free inodes:1268(linux) /
+ 1269(hurd)
+ <gnu_srs> There are differences in ext2.h and ext4.h in the Linux source
+ code wrt hurd1, hurd2 structs.
+ <gnu_srs> one change might be interesting: http://paste.debian.net/81864/
+ <braunr> gnu_srs: probably not
+ <gnu_srs> If not, where to look?
+ <braunr> well, the first thing would be to create a (small) ext2 file
+ system, usable on the hurd, with a few files and directories
+ <braunr> save it
+ <braunr> mount it with the ext4 driver
+ <braunr> and make a binary comparison
+ <braunr> you could use a modified ext2fs translator to tell you exactly
+ what's wrong when loading the file system
+ <braunr> and then look at the corresponding code in the ext4 driver
+ <gnu_srs1> braunr: here is a binary diff of the unmounted and mounted e2fs
+ files: http://paste.debian.net/81896/
+ <braunr> gnu_srs1: i'm not going to analyze it
+ <braunr> you are
+ <braunr> :p
+ <gnu_srs1> many of them can be removed: e.g. /mnt and bug000
+ <braunr> ?
+ <gnu_srs1> many diff entries*
+ <braunr> but why ?
+ <braunr> you shouldn't have changed the content at all
+ <gnu_srs1> If I don't add a file, the fs is not corrupted
+ <gnu_srs1> this is with two vers small files created as in gg0s bug report
+ <gnu_srs1> very*
+ <braunr> ok
+ <braunr> i guess checking the source code first and the binary diffs next
+ is easier
+ <gnu_srs1> OK, I have to find out how the ext2fs files are organized.
+ <gnu_srs1> I.e. reading mke2fs source code
+ <braunr> no
+ <braunr> read the ext4 driver
+ <braunr> how a directory entry is created
+ <braunr> how a directory is saved back on the block device
+ <braunr> how any potential conversion could be triggered
+ <gnu_srs1> k, will do
+ <braunr> read about the ext2fs format if doing that first doesn't help
+ <braunr> learning a file system is complicated and long
+ <gnu_srs1> What is the inode size for Hurd/Linux?
+ <braunr> probably 128
+ <gnu_srs1> same for both?
+ <braunr> what is "Hurd/Linux" ?
+ <gnu_srs1> on Hurd / on Linux
+ <braunr> 128 on hurd, variable on linux
+ <braunr> 128-512 i'd say
+ <gnu_srs1> ext2 on linux
+ <gnu_srs1> found it from dumpe2fs: 128 for both
+ <braunr> no, it can vary on linux
+ <braunr> although once a file system is built, the inode size cannot be
+ changed
+ <gnu_srs1> k, the file created with mke2fs has 128
+
+
+## `ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion 'block' failed.`
+
+### IRC, freenode, #hurd, 2014-02-19
+
+ <pere> "ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion
+ 'block' failed." in the console.
+
+[[user/Maksym_Planeta]] also has hit that one.
+
+ <braunr> wow oO
+ <braunr> using debian hurd right ?
+ <pere> power cycling.
+ <pere> yes.
+ <braunr> with hurd 1:0.5.git20140203-1 and glibc 2.17-98~1 ?
+ <pere> braunr: not sure how to check.
+ <braunr> pere: dpkg -l | grep .. i suppose
+ <pere> gah, autofsck do not work.. :(
+ <braunr> it does :(
+ <braunr> unstable is easy to mess it seems
+ <pere> had to run fsck -y / manually...
+ <braunr> i suspect you were using a corrupted file system at mount time
+ <braunr> ah that
+ <braunr> yes it is sometimes needed
+ <braunr> but ext2 is reliable enough that only temporary files get their
+ way into lost+found
+ <braunr> temporary/recently created
+ <braunr> the crash you had, on the other hand, looks more serious
+ <braunr> it seems like you mounted a corrupted file system
+ <pere> could be.
+ <pere> hurd v1:0.5.git20140203-1 and libc0.3 v2.17-98~1, it seem.
+ <braunr> good
+ <braunr> you shouldn't have such problems then, i suspect a mess up on your
+ part
+ <braunr> but you're not the only one to have had weird file systems
+ problems lately
+ <pere> hah. I blame the hurd. :P
+ <braunr> heh :)
+ <pere> gah, another crash. :(
+ <braunr> Oo
+ <braunr> same assertion ?
+ <pere> same place, or almost the same place.
+ <pere> yes.
+ <braunr> hm
+ <pere> same crash. :(
+ <braunr> what kind of machine do you run the hurd on ?
+ <pere> kvm
+ <braunr> how much memory ?
+ <pere> 1G
+ <braunr> did you see if the system was swapping ?
+ <pere> no idea.
+ <braunr> i suggest always running top/htop on the hurd ;p
+ <braunr> and monitor memory usage closely
+ <gg0> unless pere lately mounted/fsck'ed fs in question with a recent linux
+ kernel, there should not be particular problems
+ <braunr> it definitely doesn't look like it was mounted by an ext4 driver,
+ no
+ <braunr> which means it's something else entirely and this is scary
+ <pere> I didn't. I fetched the prebuild image, upgraded it, switched it to
+ sysvinit and started working.
+ <braunr> sorry i can't be of more help about that
+ <braunr> ext2fs has been quite solid on my machines for a long time :(
+ <braunr> there are known assertions that trigger under some special
+ pressure, but that's not what you're having here
+ <braunr> pere: anything particular in fstab ?
+ <pere> nope, have not touched /etc/fstab.
+ <braunr> hm stupid question
+ <braunr> are you sure it's not full ?
+ <pere> nothing look full to me.
+ <pere> neither the disk nor the host file system.
+
+
+### IRC, freenode, #hurd, 2014-02-20
+
+ <pere> braunr: do you remember my ext2fs crash from yesterday? I could
+ avoid it by interrupting the triggering build and running sync once in a
+ while. and it show up again if I do not sync in between. :)
+ <braunr> ?
+ <braunr> are you sure you're not swapping ?
+ <pere> I have no idea. still. :)
+ <braunr> again, i recommend you run top/htop and monitor that
+ <braunr> pere: is your patch needed to trigger the assertion ?
+
+[[open_issues/ti-rpc_then_nfs]].
+
+ <pere> braunr: well, without it, the package do not build, so yeah. :)
+ <braunr> ok
+ <pere> tested again, and is not swapping. 850MB free memory.
+ <braunr> ok
+ <braunr> so this might be a real file system bug
+ <braunr> let me see
+ <braunr> pere: libtirpc built fine here ..
+ <braunr> pere: do you have a separate /home partition ?
+ <braunr> or any separate file system for builds
+ <pere> braunr: nope, everything on /
+ <braunr> pere: i wouldn't recommend that
+ <braunr> there very probably are bugs in the file system code and using
+ separate partitions is a way to alleviate them
+
+
+## `ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: Assertion `!diskfs_readonly' failed.`
+
+### IRC, freenode, #hurd, 2014-02-22
+
+ <gg0> login: init: notifying pfinet of shutdown...init: notifying tmpfs
+ none of shutdown...init: notifying tmpfs none of shutdown...init:
+ notifyi.
+ <gg0> ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal:
+ Assertion `!diskfs_readonly' failed.
+ <gg0> In tight loop: hit ctl-alt-del to reboot
+
+
# Documentation
* <http://e2fsprogs.sourceforge.net/ext2.html>
diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn
index 973fb938..ef5e8cbd 100644
--- a/hurd/translator/mtab/discussion.mdwn
+++ b/hurd/translator/mtab/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008, 2009, 2013 Free Software Foundation,
+[[!meta copyright="Copyright © 2008, 2009, 2013, 2014 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -18,7 +18,7 @@ mounted file systems. This also means that commands like `df` can only work on
explicitly specified mountpoints, instead of displaying the usual listing.
One possible solution to this would be for the translator startup mechanism to
-update the `mtab` on any `mount`/`unmount`, like in traditional systems.
+update the `mtab` on any `mount`/`umount`, like in traditional systems.
However, there are some problems with this approach. Most notably: what to do
with passive translators, i.e., translators that are not presently running, but
set up to be started automatically whenever the node is accessed? Probably
@@ -1110,6 +1110,12 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
e.g. http://darnassus.sceen.net/gitweb/?p=teythoon/hurd.git;a=shortlog;h=refs/heads/feature-mtab-translator-v3-wip
+### IRC, freenode, #hurd, 2013-11-20
+
+ <braunr> teythoon: ah thanks for making mtab multithreaded :)
+ <braunr> i forgot about that
+
+
## [[open_issues/libnetfs_passive_translators]]
@@ -2587,6 +2593,548 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
<teythoon> yes
+### IRC, freenode, #hurd, 2013-11-06
+
+ <braunr> by the way, did you fix mtab for passive translators ?
+ <braunr> or make any progress ?
+ <teythoon> I just cleaned up the patch series
+ <braunr> ah good
+ <teythoon> I'm still trying to decide whether I leak any ports
+
+
+### IRC, freenode, #hurd, 2013-11-15
+
+ <teythoon> btw, I haven't forgotten about the passive translator not
+ showing up in /proc/mounts
+ <teythoon> I have a patch series, the first patch seems fine, but if I
+ build hurd packages with the other two (those that actually hook into
+ dir-lookup), strange things happen
+ <teythoon> on the first boot, everything is fine, passive translators
+ showing up in /proc/mounts, nice
+ <teythoon> but when I reboot, the system kind-of comes back, but something
+ is very wrong with many (passive?) translators
+ <teythoon> the system never recovers, I have no idea whats going on there
+ <braunr> ok
+ <braunr> push that work in a branch somewhere for review please
+ <teythoon> right, thanks
+ <teythoon> braunr:
+ http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators
+
+
+### IRC, freenode, #hurd, 2014-01-04
+
+ <youpi> teythoon: did you eventually get any idea about why /proc/mounts is
+ missing mounts?
+ <youpi> e.g. I have /boot as a separate partition, it doesn't show up
+
+
+### IRC, freenode, #hurd, 2014-01-05
+
+ <teythoon> youpi: yes, passive translators are not currently handled
+ <teythoon> youpi: i have patches for that, but they produce weird results,
+ braunr promised to take a look
+ <braunr> teythoon: hum
+ <teythoon> ^^
+ <braunr> i thought they were pending review
+ <braunr> !
+ <braunr> where are they again ?
+ <teythoon>
+ http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators
+ <braunr> ok
+ <teythoon> they are reasonably straight-forward
+ <teythoon> but cause this funny issue, after the first reboot with the
+ patched hurd everything is fine
+ <teythoon> after the second reboot, everything is weird and broken badly
+ <braunr> right
+ <braunr> interesting :)
+
+
+### IRC, freenode, #hurd, 2014-01-06
+
+ <braunr> teythoon: is it normal that, if ext2fs is started as an active
+ translator for /home, and then for another directory inside my home, mtab
+ only reports / and /home and not this third file system ?
+ <braunr> (with the hurd master version)
+ <braunr> (the translator for /home is run by root, but the one inside my
+ home is started with my uid)
+ <braunr> (and every component on the path is readable/crossable)
+
+
+### IRC, freenode, #hurd, 2014-01-07
+
+ <teythoon_> braunr: well yes, the mtab tool/translator does not follow
+ translators bound to nodes not owned by root
+ <teythoon> braunr: try /hurd/mtab --insecure /home
+ <braunr> ok
+ <braunr> good thinking
+
+ <teythoon> braunr: did you encounter any problems after the second reboot ?
+ <braunr> i'm not yet there
+ <braunr> work still making me busy
+ <braunr> and i'm trying to isolate the problem first
+ <braunr> that is, restrict tests to a single leaf translator
+ <teythoon> you reproduced the weirdness ?
+ <braunr> teythoon: attempting
+ <braunr> teythoon: first i'm trying to check a few things
+ <braunr> teythoon: i'm running my leaf translator as root now
+ <braunr> active
+ <braunr> and i still don't see it :/
+ <braunr> one of the components in the path is not own by root
+ <braunr> is that a problem ?
+ <teythoon> no, but maybe the mtab translator should check for that...
+ <braunr> does it check for the node ownership or the process rights ?
+ <braunr> credentials, rather
+ <teythoon> node ownership
+ <braunr> ah, ok
+ <braunr> ok i see it now
+ <braunr> oh, also, it looks like settrans -g on an active translator
+ doesn't work, i get ebusy all the time :/
+ <teythoon> oh ?
+ <teythoon> that could explain the fs corruption i saw
+ <teythoon> did i break that ?
+ <braunr> i don't know
+ <braunr> maybe
+ <braunr> i think it was possible in the past
+
+ <braunr> teythoon: when isolated, your code works fine
+ <braunr> i'll try applying it globally
+ <braunr> btw, how did you do that ?
+ <braunr> through debian packages ?
+ <teythoon> i'm trying to get to the point, but i'm still not there
+ <teythoon> with our uber-buildbot setup i picture myself pushing to a git
+ repo, wait a little and get the packages from my deb repo...
+ <teythoon> for now, i have my hurdtest tool that i used during gsoc
+ <teythoon> with that i can just drop files into a directory and have that
+ overlayed ontop of my test image
+ <braunr> hum
+ <braunr> so you replaced the lib*fs libraries directly ?
+ <braunr> and the static rootfs ?
+ <teythoon> yes
+ * teythoon checks
+ <teythoon> hm, maybe i just missed a file, not sure anymore
+
+ <braunr> teythoon: with the new libraries, df -h doesn't see passive
+ translators :/
+ <teythoon> braunr: see /proc/mounts please
+ <braunr> same
+ <teythoon> or /hurd/mtab /
+ <teythoon> weird
+ <braunr> no :/
+ <teythoon> b/c when i developed it, i used a test suite to check that every
+ combination of tmpfs/ext2fs active/passive and every way to get rid of
+ any translator produced the desired results
+ <teythoon> i'll look into this
+ <braunr> teythoon: when i remove the active translator i set on /home, i
+ get
+ <braunr> /dev/hd0s1 8.1G 2.0G 5.8G 26% /home
+ <braunr> hd0s1 being used for / :/
+ <braunr> this does need reviewing
+ <teythoon> this is how i expect the system to react currently
+ <braunr> oh
+ <teythoon> w/o these patches
+ <braunr> hm ok
+ <braunr> well
+ <braunr> i'm currently using them
+ <teythoon> including the root fs ?
+ <braunr> yes
+ <teythoon> hmpf
+ <braunr> i have to mention that i merged master into it
+ <teythoon> i did the same
+ <teythoon> currently compiling...
+ <braunr> i only changed libdiskfs, libnetfs and libfshelp
+ <braunr> is there something else that should be changed ?
+ <braunr> (i.e. because of inlining ?)
+ <braunr> i guess i should rebuild a hurd package just to be sure
+ <kilobug> braunr: isn't the translator for / statically linked ? if so it
+ needs to be rebuilt (sorry if I'm saying silly things by popping out of
+ nowhere)
+ <braunr> yes i took care of that
+
+ <braunr> teythoon: i've built a hurd package with the three patches and i
+ don't see passive translators at all
+ <teythoon> :/
+ <braunr> well
+ <braunr> actually i see a lot of the
+ <braunr> them
+ <braunr> just not /home
+
+ <teythoon> braunr: please see
+ /home/teythoon/build/hurd-upstream/test.{bash,log}
+ <teythoon> the latter is a log i just created on darnassus
+ <teythoon> it shows no failures
+ <teythoon> do you have another translator that is started from a passive
+ translator record ?
+ <teythoon> besides /home, if so, does that show up ?
+ <braunr> well, as i just said, i can actually see many of them
+ <teythoon> weird
+ <braunr> http://darnassus.sceen.net/~rbraun/mounts
+ <braunr> hm
+ <braunr> let's try without --sync=
+ <braunr> ah, now i can see it
+ <teythoon> can you give me the command line you used before
+ <teythoon> for the /home translator
+ <braunr> /hurd/ext2fs --sync=30 /dev/hd0s6
+ <braunr> but hm
+ <braunr> i can only see /home when the passive translator is started
+ <braunr> is that intentional ?
+ <teythoon> yes
+ <braunr> ok
+ <teythoon> and it doesn't work with --sync=30 o_O
+ <braunr> so, actually, mtab doesn't report passive translators
+ <teythoon> no
+ <braunr> it reports active ones only, whether they're started manually or
+ from passive translators
+ <teythoon> yes
+ <braunr> ok
+ <braunr> that's good enough
+ <braunr> reporting passive translators wouldprobably require a complete
+ scan
+ <teythoon> yes, that was deemed not feasible
+ <braunr> right
+ <braunr> i can't reproduce any weirdness
+ <teythoon> good
+ <braunr> it seems to just work well
+ <braunr> except this option parsing problem
+ <teythoon> thanks for looking into this
+ <teythoon> yeah
+ <braunr> sur
+ <braunr> e
+ <braunr> thanks for reminding me :)
+ <teythoon> the actual fix is implementing fsys_get_source
+ <braunr> i forgot that "pending review" was my review here he
+ <teythoon> which should actually be file_get_source
+
+ <braunr> teythoon: why does mtab report errors for /proc/swaps and
+ /xconsole ?
+ <teythoon> not sure
+
+ <teythoon> btw, i build hurd packages with my patches and it reliably
+ wreaks havoc on my test vms ...
+ <braunr> now that's really weird
+ <braunr> are you certain everything has been cleaned since your manual
+ replacement of the libraries ?
+ <teythoon> yes, i use mainly throwaway-vms for such experiments
+ <braunr> ok
+ <teythoon> did you include the debian patches ?
+ <braunr> yes
+ <teythoon> so did i
+ <braunr> i based my work on my own packages
+ <braunr> with thread destruction
+ <braunr> i'll redo it from the sid ones
+ <braunr> but before, i guess i should share mine with you
+ <braunr> so you can test them in your vms
+ <braunr> we may simply have different configurations
+ <teythoon> yes
+ <braunr> something we might have missed just like the --sync parameter
+
+
+### IRC, freenode, #hurd, 2014-01-08
+
+ <braunr> teythoon: hello
+ <braunr> see http://darnassus.sceen.net/~rbraun/teythoon/ for the custom
+ hurd packages
+ <braunr> they need thread destruction so get the latest gnumach package
+ from unstable, and the libc packages from my repository first
+
+
+### IRC, freenode, #hurd, 2014-01-09
+
+ <teythoon> braunr: your packages indeed seem to work
+ <teythoon> and with mine i encounter a different problem, the proc server
+ crashes *very* early
+ <teythoon> this is w/o a rebuilt libc
+ <teythoon> different as in not the weird one i remember having back when i
+ wrote those patches
+ <braunr> hum
+ <braunr> you're using all my glibc/hurd packages right ?
+ <teythoon> your packages work fine
+ <braunr> i wonder if your bug is caused by
+ 2c9422595f41635e2f4f7ef1afb7eece9001feae
+ <teythoon> mine don't
+ <braunr> (or rather, not having it)
+ <braunr> look at the patches i've added
+ <braunr> it's included, and i remember i really needed it
+ <braunr> althouhg it was just about a leak
+ <braunr> hm
+ <braunr> i don't know :/
+ <braunr> but i strongly suspect your patches are ok
+ <braunr> and something else is wrong
+ <teythoon> why would my packages miss that patch ?
+ <braunr> hum
+ <braunr> are you testing with your packages built from upstream sources ?
+ <teythoon> always
+ <braunr> upstream hurd against debian glibc ?
+ <teythoon> yes
+ <braunr> check the patches again
+ <teythoon> what patches ?
+ <braunr> the debian ones that you don't include
+ <braunr> another thing you can do is
+ <teythoon> err
+ <braunr> get the latest debian hurd package
+ <braunr> add your patch only
+ <braunr> rebuild
+ <teythoon> i use hurd upstream + all the debian stuff
+ <braunr> that's weird
+ <braunr> but hurd upstream has received quite a lot of patches
+ <braunr> please try from debian hurd + your patch only
+
+ <teythoon> braunr: i'm afraid it might be your patch 3a3fcc81 that breaks
+ proc
+
+[[libpthread_set_stack_size]].
+
+ <braunr> teythoon: but anyway, it does look like your patches are actually
+ fine
+ <teythoon> yes
+ <braunr> i'll install my packages on darnassus and test a bit more
+ <teythoon> there is an issue however
+ <braunr> ah
+ <teythoon> grep sd2s1 /proc/mounts
+ <teythoon> /dev/sd2s1 /dev/sd2s1 /hurd/storeio writable 0 0
+ <teythoon> that makes fsck think that /dev/sd2s1 is mounted
+ <braunr> hmpf
+ <teythoon> which makes debians fsck magic (when using sysvinit) drop to a
+ root shell at boot time
+ <braunr> why does it report a mount point ?
+ <braunr> or even a device
+ <braunr> why not none /dev/sd2s1 ?
+ <teythoon> b/c of the heuristic it uses
+ <teythoon> and i know, you told me it's a bad idea
+ <braunr> i did ?
+ <teythoon> probably
+ <braunr> hm
+ <braunr> we said so many things i don't remember
+ <braunr> but that doesn't look too hard to fix
+ <teythoon> well, i'll just have to make translators provide meaningful
+ get_source responses
+ <teythoon> and get rid of the heuristic
+ <braunr> ok
+ <teythoon> so if you use passive translators for the mounts, and not
+ /etc/fstab, you should be fine
+ <teythoon> my "traditional" hurd systems are
+ <braunr> teythoon: i'll wait a bit before deplying it on darnassus then
+
+
+### IRC, freenode, #hurd, 2014-01-13
+
+ <braunr> teythoon: does your latest patch series take care of --sync ?
+ <teythoon> yeah, i finally got why the hurd would react strangely after an
+ reboot, it was umount --all removing vital passive translator records
+ <teythoon> i never had any issues with --sync
+ <braunr> ah, umount -a
+ <braunr> hm
+ <braunr> do you recall i did :) ?
+ <teythoon> umount -a was only run with the sysvinit scripts, that's why you
+ didn't see that issue, only me
+ <teythoon> yes, i do
+ <braunr> yes, i see
+ <teythoon> however, i'm also using --sync 30 on my fs
+ <braunr> ok so you couldn't reproduce that particular issue
+ <braunr> hum
+ <braunr> try --sync=30
+ <teythoon> showtrans /media/scratch
+ <teythoon> /hurd/ext2fs --sync=30 /dev/sd1s1
+ <teythoon> works fine
+ <braunr> now that's weird :)
+ <teythoon> then again, previously there was another bug
+ <braunr> but then the patches i've tested are not the complete series you
+ sent
+ <teythoon> in the dir lookup function, if a passive translator is started
+ <teythoon> say, if i first access /proc/foo, /proc/foo would be recorded,
+ not /proc
+ <teythoon> i fixed that yesterday
+ <braunr> ok
+ <teythoon> maybe it was b/c of that
+ <braunr> but hm
+ <braunr> why would /proc be recorded ?
+ <teythoon> now ?
+ <braunr> i mean, /proc should be recorded at /, and /foo at /proc
+ <braunr> right ?
+ <teythoon> yes
+ <braunr> and that wasn't the case ?
+ <teythoon> but what happened was that proc/foo was recorded as a child
+ translator for /
+ <braunr> ohh
+ <teythoon> yes
+ <braunr> i see
+ <braunr> well, i'm not sure it's that bug, since the translator involved
+ was on /home
+ <teythoon> same problem
+ <teythoon> it's unlikely that the translator was started b/c of a /home
+ lookup
+ <teythoon> much more likely that the first lookup is /home/someone
+ <braunr> yes
+ <braunr> but mtab correctly reported /home without --sync, and not when the
+ option was present
+ <braunr> and that part doesn't quite make sense to me
+ <teythoon> how did you trigger the startup
+ <teythoon> ?
+ <braunr> ssh i believe
+ <teythoon> hm
+ <teythoon> anyways, i could not reproduce this issue
+ <braunr> do you have packages somewhere i can test ?
+ <teythoon> yes
+ <braunr> oh and btw
+ <teythoon> http://darnassus.sceen.net/~teythoon/hurd-ci/
+ <braunr> something you could do to deal with umount -a
+ <braunr> but i guess that's what you did already
+ <braunr> is to only shut the active translator down
+ <teythoon>
+ http://git.sceen.net/hurd/hurd.git/commitdiff/0033d20449b3bb558f2ea470983018db39b572aa
+ <teythoon> yeah, i thought about that
+ <teythoon> but i believe that is not the right hting to do
+ <braunr> yes i know but i'm not sure that's the right approach
+ <braunr> hm :)
+ <teythoon> b/c if on linux you do umount /foo && ls /foo, foo will be empty
+ <braunr> yours is probably more posix-friendly
+ <teythoon> if the passive translator lookup is left, /foo will be restarted
+ <braunr> ok
+ <teythoon> s/lookup/record/
+ <braunr> that's one reason i'm not very fond of passive translators tbh
+ <teythoon> yep
+ <braunr> i'd reserve them as a user-oriented hurd-specific feature
+ <braunr> anything that must behave as mount/umount expects has to be active
+ anyway
+ <braunr> ok let's give a quick shot at your packages :)
+
+ <braunr> teythoon: works fine :)
+ <braunr> mtab still reports console entries though
+ <braunr> is tha texpected ?
+ <teythoon> braunr: kind of
+ <teythoon> braunr: /bin/console is a netfs-based translator, probably for
+ multiplexing, dunno exactly
+ <braunr> i see
+
+
+### IRC, freenode, #hurd, 2014-01-14
+
+ <youpi> teythoon: passive translators do work fine in mtab now, thanks :)
+ <braunr> indeed :)
+
+
+### IRC, freenode, #hurd, 2014-02-11
+
+ <antrik> another topic: what's the rationale again behind umount removing
+ passive translators?...
+ <teythoon> antrik: umount is for compatibility with unixoid systems
+ <teythoon> consider umount /foo; ls /foo
+ <teythoon> if umount would leave the passive translator record on /foo,
+ /foo would be started again
+ <antrik> but mount never creates passive translators, right?
+ <antrik> so why would umount remove them? they are none of its business...
+ <teythoon> sure, you can see it this way
+ <teythoon> still, i like the way it is now, hence i implemented it this way
+ ;)
+ <youpi> teythoon: but then umount -a unmounts all passive translators
+ <youpi> include ~joe/http:/
+ <youpi> s/include/including/
+ <youpi> I tend to agree with antrik
+ <teythoon> i won't oppose a change of course
+ <teythoon> and yes, we have seen problems b/c of that. otoh those can be
+ fixed (and they are, i just sent a patch fixing that)
+ <youpi> teythoon: well, it's not only about http:, joe user may want to
+ mount its own iso image, or whatever
+ <teythoon> thats true
+ <teythoon> no
+ <teythoon> it's not
+ <teythoon> /proc/mounts does not contain translators bound to nodes that do
+ not belong to root
+ <teythoon> but sure, we can change umount
+ <braunr> i agree
+ <braunr> active translators can be viewed as unix mounts
+ <braunr> passive translators are an entirely hurdish feature
+ <braunr> but then, servers such as pflocal and pfinet shouldn't probably
+ not be passive translators
+ <antrik> braunr: shouldn't not? what are you trying to say? :-)
+ <braunr> woops
+ <braunr> i'm not trying to make this unconfusingly clearer
+ <braunr> :p
+ <braunr> pflocal and pfinet should probably be active translators
+ <antrik> why?
+ <braunr> hum wait
+ <braunr> i had a reason weeks ago
+ <braunr> but now it looks the opposite is better actually :p
+ <braunr> so that they don't appear in mounts
+ <braunr> but aiui, there is another property that is tested to make
+ translators appear in mounts
+ <antrik> hm... I know this question has been discussed when first talking
+ about an mtab translator years ago... but don't remember whether there
+ was any conclusion
+ <antrik> I think one of the ideas was that translators would opt in for
+ being considered as mounts...
+ <braunr> it makes sense to only have file systems in mounts anyway
+ <antrik> instead of going by the translator type, another option might be
+ ignoring anything that is backed by a passive translator?...
+ <antrik> or have a startup option (perhaps with some "smart" defaults) to
+ request a translator to manifest as a mount or not
+ <antrik> so many ideas... ;-)
+
+
+## coreutils' `df`
+
+### IRC, freenode, #hurd, 2014-01-24
+
+ <braunr> gnu_srs: "df: Warning: cannot read table of mounted file systems:
+ No such file or directory"
+ <braunr> you should be able to fix that easily
+
+
+### IRC, OFTC, #debian-hurd, 2014-02-03
+
+ <pere> /run/mtab also seem to be missing. df do not work.
+ <teythoon> that's a libc bug
+
+
+### IRC, OFTC, #debian-hurd, 2014-02-05
+
+ <gg0> i had to ln -s /proc/mounts /var/run/mtab to make df work, what's the
+ proper fix?
+ <gg0> (here sysvinit+openrc)
+ <youpi> gg0: the proper fix for df is to fix the coreutils build
+
+ <pere> I checked the mtab problem, and /etc/hurd/runsystem.gnu via
+ /etc/hurd/rc fixes the symlink, while runsystem.sysv do not. I suspect
+ /etc/init.d/checkroot.sh should fix the symlink too.
+ <youpi> well, atm df looks at /var/run/mtab instead of /etc/mtab only
+ because it hasn't been rebuilt against a recent glibc, that's all
+ <youpi> but we can brownpaperbag fix it, yes
+ <pere> right. so perhaps that is the bug to fix?
+ <youpi> yes, it is
+ <youpi> it depends on coreutils actually building
+ <teythoon> youpi: i thought the proper way to fix the /var/run/mtab issue
+ is to patch the libc ?
+ <youpi> it is
+ <teythoon> the libc defines some macro, on linux it expands to /etc/mtab,
+ on hurd to /var/run/mtab
+ <youpi> but you need to rebuild coreutils to get a fixed df
+ <teythoon> ok, right
+ <pere> should it be /var/run/mtab or /etc/mtab on hurd? the former seem
+ more correct, but /run/mtab give more sense given that it should be
+ available also before /var/ is mounted.
+ <youpi> to be honest, I don't really care
+ <youpi> and I thus tend to agree on sticking with what linux does
+ <youpi> to avoid issues
+ <youpi> as in: keep debian working mostly the same on all kernels, to avoid
+ issue
+ <youpi> s
+ <pere> well, linux really should move that file away from /etc/ too. :)
+ <youpi> pere: ok, but let's move at the same time
+ <youpi> rather than hitting bugs ourselves
+ <pere> perhaps df should use /proc/mount instead, and get rid of the
+ problem completely...
+ <youpi> that can be a way, too
+
+ <pere> I believe <URL: http://bugs.debian.org/737759 > is a good fix for
+ the mtab problem.
+
+ <rleigh> WRT /etc/mtab the main reason for keeping it is solely for
+ compatibility; there's no reason not to use /proc/mounts directly (or
+ /run/mtab if we want a kernel-agnostic location). Whether it's worth
+ doing something like that is debatable.
+ <rleigh> The main issue with doing stuff like this nowadays is that you get
+ shouted at by all the systemd people for making changes...
+
+
## Memory Leak in `translator_ihash_cleanup`
### IRC, freenode, #hurd, 2013-10-04
diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index 3e66c870..7b2f07aa 100644
--- a/hurd/translator/pfinet/implementation.mdwn
+++ b/hurd/translator/pfinet/implementation.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2000, 2008, 2013 Free Software Foundation,
+[[!meta copyright="Copyright © 2000, 2008, 2013, 2014 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -166,6 +166,14 @@ In context of the item on [[/contributing]].
<braunr> rekado: development pace on the hurd has always been slow, no need
to apologize
+
+### IRC, freenode, #hurd, 2014-02-12
+
+ <braunr> youpi: btw, the patch you finally decided to write yourself making
+ pfinet continue on driver failure is as expected quite handy :)
+ <youpi> :)
+
+
## MAC Addresses
[[!tag open_issue_hurd]]
@@ -192,6 +200,82 @@ In context of the item on [[/contributing]].
<youpi> it's not plugged inside pfinet anyway
+## IRC, freenode, #hurd, 2014-01-15
+
+ <braunr> 2014-01-14 23:06:38 IPv4 socket creation failed: Computer bought
+ the farm
+ <braunr> :O
+ <youpi> hum :)
+ <youpi> perhaps related with your change for "lo" performance?
+ <braunr> unlikely
+ <youpi> I don't see what would have changed in pfinet otherwise
+ <braunr> mig generated code if i'm right
+ <braunr> lib*fs
+ <braunr> libfshelp
+ <braunr> looks plenty enough
+ <braunr> teythoon's output has been quite high, it's not so suprising to
+ spot such integration issues
+
+
+### IRC, freenode, #hurd, 2014-01-16
+
+ <braunr> teythoon: so, did you see we have bugs on the latest hurd packages
+ :)
+ <braunr> for some reason, exim4 starts nicely on darnassus, but not on
+ another test vm
+ <braunr> and there is a "deallocate invalid name" error at boot time
+ <braunr> it's also present with your packages
+ <teythoon> yes
+
+ <braunr> not being able to start exim4 and other servers on some machines,
+ apparently randomly, is a bit frightening to me
+ <braunr> as the message says, "most probably a bug"
+ <teythoon> yes
+ <braunr> so we have to get rid of it as soon as possible so we can get to
+ the more interesting stuff
+ <teythoon> but there is no way to attribute this message to a process
+ <braunr> well, for those at boot time, there is
+ <teythoon> ?
+ <braunr> if i disable exim, i don't get it :p
+ <teythoon> oh ?
+ <braunr> but again, it doesn't occur on all machines
+ <braunr> and that part is the one i don't like at all
+ <teythoon> still, is it in exim, pfinet, pflocal, ... ?
+ <teythoon> no way to answer that
+ <braunr> ah right sorry
+ <braunr> it's probably pfinet, since exim says computer bought the farm on
+ a socket
+ <braunr> pflocal had its same pid
+ <teythoon> ok
+ <braunr> and after an upgrade, i don't reproduce that
+ <braunr> good, in a way
+ <braunr> there still is the one, after auth
+ <teythoon> yes
+ <teythoon> i'm seeing that too
+ <braunr> (as in "exec init proc auth"
+ <braunr> shouldn't be too hard to fix
+ <braunr> i'll settle on this one after i'm done with libps
+ <gnu_srs> (15:21:34) braunr: it's probably pfinet, since exim says computer
+ bought the farm on a socket:
+ <gnu_srs> remember my having problems with removing a socket file, maybe
+ related, probably not pfinet then?
+ <braunr> gnu_srs: unlikely
+ <braunr> that pfinet bug may have been completely transient
+ <braunr> fixed by upgrading packages
+ <gnu_srs> braunr: k!
+
+ <braunr> and exim4 keeps crashing on my hurd instance at home
+ <braunr> (pfinet actually)
+ <braunr> uh, ok, a stupid typo ..
+ <braunr> teythoon: --natmask in the /servers/socket/2 node, but correct
+ options in the 26 one .... :)
+
+
+### IRC, freenode, #hurd, 2014-01-17
+
+ <teythoon> braunr: *phew*
+
+
# Reimplementation, [[!GNU_Savannah_task 5469]]
## [[community/gsoc/project_ideas/tcp_ip_stack]]
@@ -205,6 +289,10 @@ In context of the item on [[/contributing]].
<braunr> hm, why not
<braunr> i would still prefer using code from netbsd
<braunr> especially now with the rump kernel project making it even easier
+
+[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel
+and Rump Kernels*.
+
<youpi> well, whatever is easy to maintain up to date actually
<braunr> netbsd's focus on general portability normally makes it easy to
maintain
@@ -225,3 +313,93 @@ In context of the item on [[/contributing]].
Cloudius OSv apparently have isolated/re-used a BSD networking stack,
<http://www.osv.io/>, <https://github.com/cloudius-systems/osv>.
+
+
+## IRC, freenode, #hurd, 2014-02-06
+
+ <akshay1994> Hello Everyone! Just set up my Hurd system. I need some help
+ now, in selecting a project on which i can work, and delving further into
+ this.
+ <braunr> akshay1994: what are you interested in ?
+ <akshay1994> I was going through the project ideas. Found TCP/IP Stack, and
+ CD Audio grabbing interesting.
+ <braunr> cd audio grabbing ?
+ <braunr> hm why not
+ <braunr> akshay1994: you have to understand that, when it come to drivers,
+ we prefer reusing existing implementations in contained servers than
+ rewriting ourselves
+ <braunr> the networking stack project would be very interesting, yes
+ <akshay1994> Yes. I was indeed reading about the network stack.
+ <akshay1994> So we need an easily modularise-able userspace stack, which we
+ can run as a server for now.
+ <akshay1994> And split into different protocol layers later.
+ <braunr> hum no
+ <braunr> we probably want to stick to the model we're currently using with
+ pfinet
+ <braunr> for network drivers, yes
+ <braunr> i strongly suspect we want the whole IPv4/IPv6 networking stack in
+ a single server
+ <braunr> and writing glue code so that it works on the hurd
+ <braunr> then, you may want to add hooks for firewall/qos/etc...
+ <braunr> (although i think qos should be embedded to)
+ <braunr> sjbalaji: i also suggest reusing the netbsd networking stack,
+ since netbsd is well known for its clean portable code, and it has a
+ rather large user base (compared to us or other less known projects) and
+ is well maintained
+ <braunr> the rump project might make porting even easier
+
+[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel
+and Rump Kernels*.
+
+ <akshay1994> okay! I was reading the project idea, where they mention that
+ a true hurdish stack will use a set of translator processes , each
+ implementing a different protocol layer
+ <braunr> a true hurdish stack would
+ <braunr> i strongly doubt we'll ever have the man power to write one
+ <braunr> i don't really see the point either to be honest :/
+ <akshay1994> haha!
+ <braunr> but others have better vision than me for these things so i don't
+ know
+ <akshay1994> So, what are the problems we are facing with the current
+ pfinet implementation?
+ <braunr> it's old
+ <braunr> meaning it doesn't implement some features that may be important,
+ and has a few bugs due to lack of maintenance
+ <braunr> maintenance here being updating the code base with a newer
+ version, and we don't particularly want to continue grabbing code from
+ linux 2.2 :)
+ <akshay1994> I see. I was just skimming through google, about userspace
+ network stacks, but I think I might need to first understand how the
+ current one works and interacts with the system, before proceeding
+ further!
+ <braunr> yes
+ <braunr> the very idea of a userspace stack itself has little implications
+ <braunr> it basically means it doesn't run in system mode, and instead of
+ directly calling functions, it uses RPCs to communicate with other parts
+ of the system
+
+ <akshay1994> braunr: I looked at the netBSD net-stack, and also how hurd
+ (and mach) work. I'm starting with the hacking guide. Seems a little
+ difficult :p
+ <akshay1994> But i feel, I'll get over it. Any tips?
+ <braunr> akshay1994: it's not straightforward
+ <akshay1994> I know. Browsing through pfinet gave me an idea, how complex a
+ thing I'm trying to deal with in first try :p
+
+
+### IRC, freenode, #hurd, 2014-02-09
+
+ <antrik> braunr: the point of a hurdisch network stack is the same as a
+ hurdish block layer, and in fact anything hurdish: you can do things like
+ tunelling in a natural manner, rather than needing special loopback code
+ and complex control interfaces
+ <braunr> antrik: i don't see how something like the current pfinet would
+ prevent that
+
+
+# IRC, freenode, #hurd, 2013-10-31
+
+ <braunr> looks like there is a deadlock in pfinet
+ <braunr> maybe triggered or caused by my thread destruction patch
+
+[[open_issues/libpthread/t/fix_have_kernel_resources]].
diff --git a/hurd/translator/pflocal.mdwn b/hurd/translator/pflocal.mdwn
index fdcc39f1..6cb01e18 100644
--- a/hurd/translator/pflocal.mdwn
+++ b/hurd/translator/pflocal.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2000, 2008, 2013 Free Software Foundation,
+[[!meta copyright="Copyright © 2000, 2008, 2013, 2014 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -33,3 +33,37 @@ implementation).
(maybe not so interesting case).
<pinotree> pflocal does not support it
<gnu_srs> Is that of interest at all?
+
+
+## IRC, freenode, #hurd, 2014-01-14
+
+ <braunr> sudo -s eats 100 cpu :/
+ <braunr> possibly because of pflocal
+ <braunr> only change on pflocal (notwithstanding the libraries) is
+ "pflocal: improve the demuxer functions"
+ <braunr> teythoon: why did you change the order of the function calls in
+ sock_demuxer ?
+ <youpi> for efficiency iirc
+ <braunr> yes, looks reasonable
+
+
+### IRC, freenode, #hurd, 2014-01-16
+
+ <braunr> i suspect the "improve the demuxer functions" changes may have
+ hard-to-understand side effects
+ <teythoon> yes, mostly being faster
+ <braunr> ah, the latest sudo has been fixed
+ <braunr> haha :)
+ <teythoon> ^^
+ <braunr> that one is easy to understand :)
+ <braunr> sudo was looping around calls to pflocal
+ <braunr> and exim crashed because of pfinet
+ <braunr> and those servers were only affected by these changes, other than
+ the library ones which don't seem to apply at all
+ <braunr> but with sudo being fixed, i'm not sure it's relevant any more
+ <teythoon> i'd say being faster could easily cause hard-to-understand side
+ effects
+ <braunr> ah, yes
+ <braunr> being faster isn't the side effect itself ;p
+ <braunr> nice, sudo was bugged on linux too, its behaviour matched its hurd
+ version perfectly
diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn
index 75bfb8fd..39840e99 100644
--- a/hurd/translator/proc.mdwn
+++ b/hurd/translator/proc.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation,
+Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -102,3 +103,68 @@ It is stated by `/hurd/init`.
< braunr> teythoon: i agree with you on proc process-to-task mapping
< braunr> that's something i intend to completely rework on propel
< braunr> in a way similar to how pid namespaces work on linux
+
+
+# PID "Races"
+
+## IRC, freenode, #hurd, 2014-01-26
+
+ <quotemstr> Does Hurd have anything that generally solves PID races?
+ <youpi> what kind of race are you thinking about?
+ <youpi> I'm not sure, but I guess keeping a reference to a task port will
+ prevent the proc server from recycling the corresponding pid
+ <quotemstr> Yep.
+ <quotemstr> How does the Hurd avoid the obvious denial-of-service attack
+ that results?
+ <youpi> well quotas would probably be enough
+ <youpi> that's not a new issue :)
+ <quotemstr> Fair enough.
+ <quotemstr> Returning to the POSIX-y world after a few year stint over in
+ NT-land, it's infuriating that it's still not possible to write a
+ reliable killall(1) under Linux or the BSDs.
+ <quotemstr> I'm glad Hurd solves the problem. :-)
+ <braunr> but it doesn't
+ <braunr> how can you write a reliable killall ?
+ <youpi> so keeping a reference to the task port is not enough?
+ <braunr> i'm not sure
+ <braunr> first i'd like quotemstr to clearly define the reliability problem
+ of killall
+ <quotemstr> braunr: The possibility that a PID might be used between the
+ time you decide to kill it and the time you actually kill it.
+ <braunr> well, it would have to wrap around for that
+ <quotemstr> braunr: So? It's possible.
+ <braunr> i guess that's what you refer to
+ <braunr> ok
+ <braunr> well yes, it's possible to easily create a routine that atomically
+ increases the number of references on a task/process when looking it up
+ <braunr> preventing its removal from the list of processes reported by the
+ proc server
+ <quotemstr> Like OpenProcess? :-) Would this reference count be
+ automatically decremented if the task owning the reference is killed?
+ <braunr> it would clearly not be a "posixy killall" then, but i suppose we
+ don't care about that at all
+ <braunr> no
+ <quotemstr> Oh.
+ <braunr> destroying an object doesn't remove its references
+ <quotemstr> So it's possible to leak the reference and prevent reuse of
+ that PID forever.
+ <braunr> hardly
+ <braunr> for that, killall would have to run a long time
+ <quotemstr> braunr: No, I'm talking about our hypothetical killall itself
+ being killed after taking out a reference on another process, but before
+ releasing it
+ <braunr> but a malicious killall could
+ <braunr> when a task is destroyed, its capability space is destroyed too
+ <braunr> removing all the references it previously had
+ <quotemstr> Ah, I see.
+ <braunr> the leaks we have occur in servers
+ <braunr> which sometimes act as clients to other servers
+ <braunr> and run forever
+
+
+# Crashes due to rpctrace
+
+## IRC, freenode, #hurd, 2014-02-18
+
+ <braunr> something is wrong in the proc server
+ <braunr> rpctrace is often causing it to crash ..
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index 018db7b2..8ac48a59 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2010, 2011, 2012, 2013, 2014 Free Software
+Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -348,6 +348,35 @@ Disadvantage is that every program using this needs to be patched.
This is used in `[LLVM]/lib/Support/Unix/Path.inc`.
+### IRC, OFTC, #debian-hurd, 2013-11-10
+
+ <mjt> Hello. Does hurd have /proc/self/exe equivalent, to "re-exec myself"
+ ?
+ <youpi> no, only argv[0]
+ <mjt> busybox uses /proc/self/exe by default to re-exec itself when running
+ one of its applets, or failing that, tries to find it in $PATH. I guess
+ it doesn't work on hurd... :)
+ <mjt> and argv0 is unreliable
+ <youpi> some discussion on the hurd wiki talks about using Dl_info DLInfo
+ <youpi> which contains DLInfo.dli_fname
+ <youpi> err, I mean, callling dladdr(&main, &DLInfo);
+ <youpi> this is kernel-agnostic, provided one uses glibc
+ <mjt> um. -ldl. nice for static linking
+ <mjt> gcc t.c -ldl -static
+ <mjt> ./a.out
+ <mjt> fname=AVA� �j
+ <mjt> bah :)
+ <mjt> (it just prints dli_fname)
+ <teythoon> :/
+ <youpi> ah, yes, that won't work with static linking
+ <teythoon> fixing /proc/self is on my todo list, it shouldn't be too hard
+ <youpi> since in that case it's the exec server which sets the process up,
+ not dl.so
+ <teythoon> but we do not have the exe link either
+ <mjt> (the above test run was on linux not on hurd, fwiw_
+ <mjt> )
+
+
# `/proc/[PID]/fd/`
## IRC, freenode, #hurd, 2012-04-24
@@ -502,6 +531,23 @@ Also used in `[GCC]/intl/relocatable.c`:`find_shared_library_fullname` for
<camm`> thanks
+## IRC, freenode, #hurd, 2014-02-22
+
+ <ignaker> i'm trying to implement proc/maps
+ <ignaker> actually I can't well evaluate complexity of tasks. However, I
+ appreciate your comments
+ <braunr> the complexity can be roughly estimated from the number of
+ components involved
+ <braunr> proc/maps involves procfs, ports, virtual memory, and file systems
+ <braunr> the naive implementation would merely be associating names to
+ memory objects, and why not, but a more complete one would go ask file
+ system servers about them
+ <braunr> perhaps more
+ <braunr> although personally i'd go for the naive one because less
+ dependencies usually means better reliability
+ <braunr> something similar to task_set_name could do the job
+
+
# `/proc/[PID]/mem`
Needed by glibc's `pldd` tool (commit
diff --git a/hurd/translator/term.mdwn b/hurd/translator/term.mdwn
index 667677a7..5ae52abe 100644
--- a/hurd/translator/term.mdwn
+++ b/hurd/translator/term.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -190,6 +190,12 @@ The *term* translator implements POSIX termios discipline.
<braunr> there, patches pushed :)
+### IRC, freenode, #hurd, 2014-02-07
+
+ <braunr> btw, as a note, there really are leaks in terminals
+ <braunr> i managed to get a term server eat up to 300M of memory yesterday
+
+
## `screen` Logout Hang
[[!tag open_issue_hurd]]
diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn
index 8c332d84..72400121 100644
--- a/hurd/translator/tmpfs/discussion.mdwn
+++ b/hurd/translator/tmpfs/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation,
+[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -19,6 +19,8 @@ License|/fdl]]."]]"""]]
* [[!GNU_Savannah_bug 26751]]
+[[!toc]]
+
# [[Maksym_Planeta]]
@@ -467,3 +469,35 @@ License|/fdl]]."]]"""]]
privilege of their owner
<braunr> privileges should be decoupled from identity
<teythoon> yes
+
+
+## IRC, freenode, #hurd, 2013-11-08
+
+ <teythoon> braunr: I'm investigating this port leak of mine
+ <teythoon> well, I thought I introduced one
+ <teythoon> but I'm not too sure anymore
+ <teythoon> the setting is this
+ <teythoon> i start an active tmpfs translator, bind it to foo
+ <teythoon> then, i create foo/bar with a passive translator entry
+ <teythoon> i access foo/bar, the passive translator is started
+ <teythoon> my test suite now covers several methods of making that
+ translator go away
+ <teythoon> killing it with 15 or 9 is fine, i.e. does not make the first
+ tmpfs leak ports
+ <teythoon> however, doing settrans -g foo/bar does for some reason
+ <teythoon> i think my code is fine, i spent considerable time on tracking
+ down this problem, always thinking that i must have introduced it
+ <teythoon> but another thing just cought my eye, the first tmpfs translator
+ says this when i do settrans -g foo/bar:
+ <teythoon> tmpfs/tmpfs: pthread_create: Resource temporarily unavailable
+ <teythoon> could it be that a no-sender notification is ignored b/c the
+ handler thread failed to start ?
+ <braunr> teythoon: i saw this pthread error too
+
+
+# IRC, freenode, #hurd, 2014-02-09
+
+ <gg0> remounting tmpfs doesn't work if in use
+ http://paste.debian.net/plain/80937/
+ <gg0> you will also get a pthread_create: Resource temporarily unavailable
+ <youpi> iirc the pthread_create warning happens for any kind of translator