diff options
Diffstat (limited to 'hurd/translator')
| -rw-r--r-- | hurd/translator/auth.mdwn | 228 | ||||
| -rw-r--r-- | hurd/translator/discussion.mdwn | 165 | ||||
| -rw-r--r-- | hurd/translator/ext2fs.mdwn | 332 | ||||
| -rw-r--r-- | hurd/translator/mtab/discussion.mdwn | 552 | ||||
| -rw-r--r-- | hurd/translator/pfinet/implementation.mdwn | 180 | ||||
| -rw-r--r-- | hurd/translator/pflocal.mdwn | 36 | ||||
| -rw-r--r-- | hurd/translator/proc.mdwn | 68 | ||||
| -rw-r--r-- | hurd/translator/procfs/jkoenig/discussion.mdwn | 50 | ||||
| -rw-r--r-- | hurd/translator/term.mdwn | 8 | ||||
| -rw-r--r-- | hurd/translator/tmpfs/discussion.mdwn | 36 |
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 961711f3..bac32906 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]] @@ -2496,6 +2502,548 @@ Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a? <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 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 b3b5e703..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 @@ -78,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 87ff0248..54de54c2 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 78c83276..834ef9bd 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 @@ -197,6 +197,12 @@ separation enabled there is this problem, and once disabled it goes away. <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 |