diff options
96 files changed, 14503 insertions, 330 deletions
diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn index 61a3fa01..344b741c 100644 --- a/community/gsoc/project_ideas/language_bindings.mdwn +++ b/community/gsoc/project_ideas/language_bindings.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013, 2014 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -61,3 +61,41 @@ bindings](http://www.nongnu.org/hurdextras/#pith), which might serve as a reference if you want to work on Perl. Possible mentors: Anatoly A. Kazantsev (anatoly) for Python + + +# Discussion + +## [[user/jkoenig/Java]] + +## IRC, freenode, #hurd, 2013-12-19 + + <antrik_> teythoon_: I don't think wrapping libtrivfs etc. for guile + bindings is really desirable... for the lisp bindings, we agreed that + it's better to hook in at a lower level, and build more lispish + abstractions + <antrik> trivfs is a C framework; it probably doesn't map very well to + other languages -- especially non-imperative ones... + <antrik> (it is arguable whether trivfs is really a good abstraction even + for C... but that's another discussion :-) ) + <antrik> ArneBab: same for Python bindings. when I suggested ignoring + libtrivfs etc., working around the pthread problem was just a side effect + -- the real goal has always been nicer abstraction + <anatoly> antrik: agree with you + <anatoly> antrik: about nicer abstractions + <teythoon_> antrik: I agree too, but wrapping libtrivfs is much easier + <teythoon_> otherwise, one needs to reimplement lots of stuff to get some + basic functionality + <teythoon_> like a mig that emits your language + <braunr> i agree with antrik too + <braunr> yes, the best would be mig handling multiple languages + +[[!taglink open_issue_mig]]. + + <antrik> teythoon_: not exactly. for dynamic languages, code generation is + silly. just handle the marshalling on the fly. that's what the Lisp + bindings are doing (AFAIK) + <teythoon> antrik: ok, but you'd still need to parse the rpc definitions, + no? + <antrik> teythoon: yeah, you still need to parse the .defs -- unless we add + reflection to RPC interfaces... + <antrik> err, I mean introspection diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn index ca586dea..d3e17dc9 100644 --- a/community/gsoc/project_ideas/object_lookups.mdwn +++ b/community/gsoc/project_ideas/object_lookups.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 @@ -132,3 +132,410 @@ In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]]. <braunr> but murmur is better <braunr> we prefer distribution over hashing performances <braunr> https://131002.net/siphash/ + + +## IRC, freenode, #hurd, 2013-11-21 + + <teythoon> btw, about protected payloads in mach + <teythoon> I'm thinking about adding a flag to indicate that mach_msg + should return the protected payload pointer instead of the local port + field in the message header + <braunr> when would you set it ? + <braunr> i mean, how is it set ? + <teythoon> we don't really need the port name, right? and when we do, we + look it up in the referenced data structure + <teythoon> using a new rpc perhaps + <braunr> ok + <teythoon> what do you think? + <braunr> a new rpc on ports themselves, like mach_port_mod_refs i assume ? + <braunr> i think it's a good solution + <teythoon> the field is a natural_t, as far as i can see, pointers should + fit into it, right? + <teythoon> yes + <braunr> the big problem is backward compatibility + <teythoon> why? + <braunr> and your solution solves that + <teythoon> yes + <braunr> hum + <braunr> natural_t was originally intended to be as large as the machine + word + <braunr> but it may no longer stay true + <braunr> i think youpi decided to keep it an int and not a long in his + x86_64 branch + <braunr> mach uses a trick for in-kernel port rights + <braunr> where the right is the port address + <teythoon> yes, I've seen that + <braunr> but i remember hearing about problems with this strategy in + 64-bits + <braunr> or maybe compat problems in mig interfaces + <braunr> i don't remember exactly + <braunr> so youpi looked at how macosx mach deals with the problem + <teythoon> well, but so far there is no 64 bit mach, so we do not need to + worry about compatibility there, no ? + <braunr> and if i'm right, they forced the ports on 32-bits + <braunr> no you're right + <braunr> we can simply force the field to 64-bits, whatever it contains + <teythoon> or change the message format from the beginning to include both + the name and the payload + <teythoon> then again, why bother + <braunr> ? + <braunr> have a 64-bits specific message format ? + <teythoon> well, it's worth discussing, no? + <braunr> maybe + <braunr> i personally don't like the idea + <teythoon> we could fix stuff + <braunr> forcing the field to 64-bits should be enough + <teythoon> right + <teythoon> do you think the idea is worth prototyping ? + <braunr> teythoon: yes + <teythoon> braunr: cool :) + <braunr> teythoon: definitely :p + <braunr> actually, doing that can remove a large part (if not all) + contention from libports + <teythoon> indeed + <braunr> i still think we should work on libihash first + +[[hurd/libihash]]. + + <braunr> converting libihash to murmur2/3 impacts more data structures + overall + <braunr> it's also much easier + <teythoon> what exactly do you mean by that + <teythoon> ? + <braunr> libports uses libihash + <teythoon> yes + <braunr> but it's not the only user + <braunr> libihash is known to have high collision rates + <braunr> that should be fixed + <teythoon> right, but what do you mean by using murmur2/3 + <braunr> that's a hashing algorithm name + <teythoon> using the integer finalizer used by murmur? + <braunr> hm + <braunr> i didn't dig the details + <braunr> and simply assumed it could be used for integer hashing as well + <teythoon> the way i see it, murmur can hash arbitrary ammounts + <braunr> if there are better integer hashing algorithms, let's just use + that + <teythoon> but that is not what we need + <braunr> yes + <teythoon> we have a fixed size integer + <braunr> but from what i remember, it's also very efficient for integer + hashing + + +## IRC, freenode, #hurd, 2013-11-22 + + <teythoon> braunr: /test-pp: msgh_protected_payload is 0x12345678 + <teythoon> :) + <braunr> :) + <teythoon> but currently I do another ipc_port_translate which is clearly + not desireable + <teythoon> the msg handling in the kernel is... involved... + <teythoon> here is the thing... there are two (kernel) threads involved, + the sender and the receiver + <teythoon> for the sender, kmsg->ikm_header.msgh_remote_port is a pointer + (thanks to ipc_port_translate) to the destination's ipc_port_t + <teythoon> that's where the protected_payload is stored + <teythoon> but at the receiving thread, the pointer is gone, replaced by a + port name + <teythoon> so currently I'm doing the lookup there again + <braunr> hum + <braunr> are you sure kmsg is the general structure for all messages ? + <braunr> or is it only for kernel messages ? + <braunr> i don't remember exactly + <teythoon> no, for all messages + <braunr> ok + <teythoon> I just need to get this pointer across cleanly + <braunr> i thought you wanted to replace that port name in the receiving + thread with the payload + <teythoon> I do + <braunr> i don't see the problem then + <teythoon> well, only the sending thread has the pointer, the receiving + thread only has the name + <braunr> i don't see what makes it hard to change it + <braunr> since that's what you want to do + <braunr> the sending thread doesn't have the pointer + <teythoon> yes it has + <braunr> well + <braunr> only for in kernel objects + <braunr> and it's an optimization + <braunr> and you shouldn't have to care much about it + <braunr> your work only involves changing how messages are received + normally + <teythoon> let me push it somewhere, so I can show you the patches + <braunr> ok + <teythoon> braunr: + http://darnassus.sceen.net/gitweb/teythoon/gnumach.git/shortlog/refs/heads/feature-protected-payload-1 + <braunr> teythoon: where should i look at ? + <teythoon> the last commit + <braunr> hm + <braunr> see what calls mach_msg_receive + <braunr> the payload flag must be handled before, when the message is + actually transferred + <braunr> ipc_kmsg_copyin perhaps + <teythoon> well + <teythoon> but this is the tricky part + <braunr> i'm not sure which of the sender or receiver code actually + performs these translations + <braunr> yes + <teythoon> b/c at this point it is not known whether the receiver has + specified the MACH_RCV_PROTECTED_PAYLOAD flag + <teythoon> or my understanding of the whole process is still somewhat off, + which might very well be... + <braunr> it's not something the receiver should set + <braunr> i.e. the flag shouldn't be set at mach_msg time + <braunr> because it's asynchronous + <braunr> it's a flag that should be set near port creation time + <teythoon> oh + <teythoon> right, I can see how that could work + <braunr> mach_reply_port(); mach_port_set_payload(); mach_msg(); + <teythoon> braunr: + http://darnassus.sceen.net/gitweb/teythoon/gnumach.git/log/refs/heads/feature-protected-payload-2 + <teythoon> I think I found the right spot + <braunr> teythoon: looks better indeed :) + <teythoon> braunr: yes, thanks for the hint :) + <braunr> teythoon: keep in mind gnumach supports moving receive rights + between tasks + <braunr> i don't think it's much of a burden but don't forget :) + <teythoon> right, if that happens, the protected payload field should + probably be just reset to 0 + <teythoon> that preserves the old default behavior + <braunr> teythoon: you shouldn't name the payload "address" though + <braunr> but really "payload" or "label" + <braunr> vm_offset_t isn't the appropriate type either + <braunr> i suggest unsigned long payload + <teythoon> braunr: noted + <braunr> what i mean is + <braunr> the payload isn't the userspace structure you want to use + <braunr> it's the value stored in that unsigned long + <braunr> whether it's used as a pointer or an array index or whatever + should be at the application discretion + <teythoon> yes, I got that + <braunr> concerning vm_offset_t, it's misused a lot, mostly for historical + reasons + <braunr> vm_offset_t is actually the ancestor of off_t + <braunr> i.e. an offset inside a *memory object* + <braunr> the size of which may differ from the size of a pointer + <teythoon> ok + <braunr> historically, physical and virtual addresses, in addition to + memory object sizes, were the same, hence the confusion + <braunr> today we might have 32-bits virtual addresses, 36-bits physical + addresses, and 44- to 64-bits file offsets + <braunr> (e.g. PAE with large file support) + + +## IRC, freenode, #hurd, 2013-11-25 + + <teythoon> braunr: the object lookup problem is worse than i assumed + <teythoon> the lookup is actually done twice... + <braunr> teythoon: isn't that usually the case :) ? + <braunr> inside gnumach ? + <teythoon> no + <teythoon> once in libports, once in the intrans function + <braunr> which intrans function ? + <braunr> can you point at an example ? + <teythoon> right + <teythoon> routine file_get_fs_options ( file: file_t; + <teythoon> file_t is special + <teythoon> mig magic + <teythoon> type file_t = mach_port_copy_send_t + <teythoon> #ifdef FILE_INTRAN + <teythoon> intran: FILE_INTRAN + <braunr> trivfs_begin_using_protid ? + <teythoon> for example, yes + <braunr> ugh + <teythoon> however, I believe that can be fixed cleanly + <teythoon> I revised my gnumach changes + <teythoon> it works surprisingly well + <braunr> gnumach is largely clean code + <teythoon> i patched libports to use the new falicilty + <teythoon> all the fs translators i tested work fine + <braunr> nice + <teythoon> tmpfs, ext2fs, nfs, hello* + <teythoon> so does exec + <braunr> very nice + <teythoon> howevcer, the bootstrap fails + <braunr> a lot more straightforward than i expected + <teythoon> i believe proc crashes + <teythoon> yes + <braunr> you can use mach_print to manually trace the bootstrap process + +[[microkernel/mach/gnumach/interface/syscall/mach_print]]. + + <teythoon> i did that + <braunr> ok + <teythoon> it's nice + <braunr> bare knives are :) + + <teythoon> uh oh, this lookup fix requires some mig changes + <braunr> teythoon: have you built some packages on it ? + <teythoon> braunr: some clang test builds + <braunr> nice + <braunr> where is mig getting in the way ? + <teythoon> yes, and i compiled lots of stuff + <braunr> any debian package ? + <teythoon> let me just push my changes somewhere... + <teythoon> no, no deb + <braunr> ok + <teythoon> braunr: + http://darnassus.sceen.net/gitweb/teythoon/gnumach.git/log/refs/heads/feature-protected-payload-3 + <teythoon> + http://darnassus.sceen.net/gitweb/teythoon/hurd.git/log/refs/heads/feature-protected-payload-1 + <teythoon> braunr: in particular, + http://darnassus.sceen.net/gitweb/teythoon/hurd.git/blob/refs/heads/feature-protected-payload-1:/libports/manage-multithread.c#l161 + + +## IRC, freenode, #hurd, 2013-11-27 + + <teythoon> btw, my protected payload work is progressing nicely + <teythoon> the system actually boots now :) + <braunr> that's great + <braunr> looking forward to seeing it in action + <teythoon> I'd love to quickly discuss my mig changes if you've got a + minute + <braunr> sure + <teythoon> ok + <teythoon> first, please look at this + http://darnassus.sceen.net/gitweb/teythoon/hurd.git/blob/refs/heads/feature-protected-payload-1:/libports/manage-multithread.c#l161 + <teythoon> in line 165, the msgh_local_port is restored + <teythoon> b/c later some intrans function might use this for the object + (re-)lookup + <braunr> yes ok + <teythoon> + http://darnassus.sceen.net/gitweb/teythoon/mig.git/commitdiff/64b7d34f90a41d017a9e1e8179c0533a97012f6f + <braunr> makes sense + <teythoon> this makes mig payload aware + <teythoon> we'd specify another intrans function that takes a label and + returns an object + <braunr> let me remind + <braunr> you said there were 3 lookups actually + <braunr> the mach one + <braunr> the libports one + <braunr> and is the intran one the last, right ? + <teythoon> yes + <teythoon> so now i optimized away the second one, the one in libports + <braunr> ok so you need intran aware functions to replace that lookup + <braunr> well + <braunr> payload aware intran functions + <teythoon> yes + <braunr> ok + <teythoon> mostly cast the label, ports_port_ref the object + <braunr> i assume they'd be pretty straightforward + <teythoon> yes + <braunr> and easy to add for all existing intran functions + <teythoon> most likely + <braunr> the proposed change looks very appropriate + <teythoon> :) + <braunr> i'd never thought about intran functions because i didn't want + that in my clone ;p + <braunr> they do add a bit of complexity + <braunr> but this upgrade path looks right + <teythoon> yes + <teythoon> I think so too + <braunr> nothing more to say :) + <braunr> it's so simple i actually don't understand how i could miss it + last time i looked + <braunr> i guess i was exhausted heh + <teythoon> thanks for the review :) + <braunr> thanks for your work + <braunr> it's been a long time since we had someone spend that much time on + the hurd + + +## IRC, freenode, #hurd, 2013-11-29 + + <teythoon> I came to believe that there is actually a lot of room for + improvement in our rpc path + + +## IRC, freenode, #hurd, 2013-12-19 + + <braunr> teythoon_: how is protected payload branch now ? + <braunr> ready for review ? + <teythoon_> the kernel and mig patch are + <teythoon_> patches + <braunr> so pending for approval rathr + <braunr> rather + <teythoon_> documentation is still missing for those ofc + <braunr> the last parts are the mig mutations iirc + <teythoon_> err, you lost me + <teythoon_> i haven't continued to work on the hurd patch series + <teythoon_> the patch series for gnu mach and mig are feature complete from + my point of view + <braunr> i mean the changes needed to remove the third lookup in the + mutation functions + <teythoon_> to do that in hurd, we need a patched mig + <braunr> i was just trying to remember correctly + <teythoon_> those patches need to be reviewed + <teythoon_> the hurd patch series is not yet working, but you can see the + approach i've taken + <braunr> yes + <braunr> ok + <teythoon_> the next thing i'd do in this regard is to fix all object + lookups + <braunr> so it didn't change from last time i looked + <teythoon_> no + <teythoon_> some code, notoriously the control port handling in the *fs + libs, uses mach_port_t for the receiver and do the lookup themself. i'd + fix that next. + + +## IRC, freenode, #hurd, 2014-01-20 + + <teythoon> i've tied up enough loose ends, that i can start working on the + protected payload stuff again + <teythoon> the next step is fixing the receiver lookups everywhere + <braunr> good :) + <teythoon> if everyone uses mig magic for that, the switch will be easy + <teythoon> undoing the hack in mach-defpager too + + +## IRC, freenode, #hurd, 2014-01-24 + + <braunr> teythoon: what are you currently working on ? protected payload ? + <teythoon> braunr: yes, i'm working with coccinelle to fix all object + lookups in the hurd + <teythoon> i figured it is easier and cleaner to just fix them instead of + converting pointers back to port names for those functions that want port + names + + +## IRC, freenode, #hurd, 2014-02-17 + + <teythoon> braunr: do you think it's okay to make the 0 payload special ? + <braunr> teythoon: for our needs, sure + <braunr> it's similar to NULL or MACH_PORT_NULL + <teythoon> yes + <teythoon> maybe i should add a symbolic name for that + <teythoon> for consistency + <braunr> but is it wise to let mach_port_set_protected_payload reset the + behaviour on a zero payload ? + <braunr> i don't think a symbolic name is needed + <braunr> or maybe + <braunr> as you want + <teythoon> what else should it do then ? + <braunr> 00:25 < braunr> but is it wise to let + mach_port_set_protected_payload reset the behaviour on a zero payload ? + <braunr> it could return invalid argument instead + <braunr> and the documentation would clearly state 0 is invalid + <braunr> but that would also prevent reverting the mode + <teythoon> yes, i consider that not really useful, but i'd be okay with the + current behavior + <teythoon> but yes, the documentation should make that clear + + +## IRC, freenode, #hurd, 2014-02-22 + + <teythoon> braunr: once the pp patch set is in gnumach, i'll make + mach-defpager use it + <teythoon> it's a good target, as it does not use libports + <teythoon> and it's currently abusing the port rename procedure for the + lookup, making the rights spill into the splay tree + <teythoon> braunr: the wiki mentioned that you once considered to remove + the ability to rename ports altogether + <braunr> teythoon: ah right + <braunr> i actually intend to keep it for x15, but only because i want port + names to blend as file descriptors + <teythoon> right, for dup and friends + <braunr> and the radix tree is a data structure that can cope decently with + not too sparsed distributions diff --git a/contributing.mdwn b/contributing.mdwn index 2e461819..e0a6c7de 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, +2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -99,6 +99,7 @@ far better to let `exec` simply set the name and record it in `task_t`. to add an RPC. glibc needs to be recompiled against the updated mach.defs to get access to it from userland. exec would probably call it from `hurd/exec/exec.c`, `do_exec()`. +Also see the discussion on [[open_issues/translate_fd_or_port_to_file_name]]. * Write a partfs translator, to which one gives a disk image, and which exposes the partitions of the disk image, using parted, and the parted-based storeio (`settrans -c foos1 /hurd/storeio -T typed diff --git a/faq/sata_disk_drives/discussion.mdwn b/faq/sata_disk_drives/discussion.mdwn index d05566b6..0b56f235 100644 --- a/faq/sata_disk_drives/discussion.mdwn +++ b/faq/sata_disk_drives/discussion.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 @@ -256,3 +256,93 @@ License|/fdl]]."]]"""]] <teythoon> youpi: hm, I think my board has no ahci controller, linux uses the sata_via module to talk to it :/ <youpi> ah :/ + + +# IRC, freenode, #hurd, 2014-02-05 + + <braunr> teythoon: i don't completely trust the driver + <teythoon> oh ? + <braunr> it doesn't work on my laptop, and i had a failure once on a "big" + partition of 128G + <teythoon> hm + <teythoon> my hardware does not implement ahci, but in qemu it works fine + for me + <braunr> well qemu is the only supported "hardware" + <teythoon> but then my partitions are not that big + <youpi> braunr: no, it does work on my laptop too + <braunr> ok + + +# IRC, freenode, #hurd, 2014-02-12 + + <braunr> youpi: hum, sorry to ask but how do you use qemu to provide sata ? + <youpi> braunr: there's an important trick: getting it on another IRQ than + the eth0 board :/ + <youpi> -device ahci,id=ahci1 + <youpi> for nothing + <youpi> -device ahci,id=ahci2 + <youpi> -drive id=root,file=/dev/${HDA}7,cache=writeback,if=none + <youpi> -device ide-drive,drive=root,bus=ahci2.1 + <braunr> ok that's close enough to what i have + <braunr> but + <braunr> i'm using /dev/sda as the backend + <braunr> instead of a regular file + <braunr> sda already containing a regular debian linux system + <braunr> and grub2 can't boot because it seems to fail reading the + partition table + <braunr> it works perfectly when accessing it as an ide disk though + <braunr> youpi: do you see any reason why grub would fail with ahci ? + <braunr> also, why ahci2._1_ instead of 0 ? + <braunr> youpi: fyi, the cd installer always booted fine here, both on my + workstation and my laptop, i did about 50 tries on each machine + <braunr> the graphical mode doesn't seem to work though + <braunr> youpi: fyi2 the grub related issue i'm having is + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692249 + <youpi> I'm using .1 because I have a /boot .0 before the / .1 :) + <braunr> humm + <braunr> you have two drives ? + <youpi> braunr: (cd installer): you mean, even in semi-graphical mode? + <braunr> one for /boot and the other for / ? + <youpi> I have 3 actually :) + <braunr> youpi: no, xorg + <braunr> ok i se + <braunr> see + <youpi> (cd installer) I'm talking about the working ones :) + <youpi> I know xorg does not boot + <braunr> ok + <braunr> so apparently, adding ,boot=on to the -drive parameter did the + trick + <youpi> k + <braunr> and now, i have a hurd system running from /dev/sda5 (the real + disk) in qemu + <youpi> for the pseudo-graphical console, I guess his monitor is too dumb + to be able to display 640x400 + <braunr> possible + <youpi> most probably because no OS uses that any more nowadays :/ + <youpi> (and that won't get better) + <braunr> so now i can debug ahci on my laptop using that :) + + <braunr> youpi: is there a known limit to the size of an ahci drive in the + gnumach driver ? + <youpi> in the driver itself, it's simply lba48 + <youpi> but the mach interface uses 32bit sector number + <youpi> thus 2TB limit + <braunr> that's plenty :) + <youpi> I have a 2TB drive :) + <youpi> so it won't be plenty for long + <braunr> 2TB for your hurd system ? + <youpi> no, for my backups etc. + <braunr> i meant plenty for our hurd instances + <youpi> but there could have been a hurd vm there + <youpi> and not necesseraly below 2TiB + + <braunr> hm, the installer doesn't detect existing partitions on an ahci + drive :/ + + +## IRC, freenode, #hurd, 2014-02-13 + + <braunr> youpi: looks like linux has trouble handling my ahci drive without + ioapic/msi + <braunr> no wonder gnumach can't either + <youpi> erf diff --git a/faq/which_microkernel/discussion.mdwn b/faq/which_microkernel/discussion.mdwn index ffdc6720..338da7d8 100644 --- a/faq/which_microkernel/discussion.mdwn +++ b/faq/which_microkernel/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2011, 2012, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -13,6 +14,65 @@ License|/fdl]]."]]"""]] [[!toc]] +# IRC, freenode, #hurd, 2011-01-12 + + <Pete-J> Hello i am just curious of the development of Hurd - what's the + current mission on the microkernel i see projects like l4 and viengoos, + will one of these projects replace Mach? or will you stick with Mach + <Pete-J> as i understand is that Mach is a first generation microkernel + that's very old in design and causes alot of issues + <Pete-J> that's where l4 and viengoos comes in - they are trying to be the + next generation Mach - am i correct? + <neal> l4 is not a drop in replacement for Mach + <neal> it doesn't actually do much resource management + <neal> for instance, you still have to implement a memory manager + <neal> this is where several issues are with Mach + <neal> l4 doesn't address those issues; it punts to the operating system + <Pete-J> and what about viengoos? + <neal> it's unfinished + <neal> and it implemented some untested ideas + <neal> i.e., parts of viengoos were research + <neal> there has not been a sufficient evaluation of those ideas to + determine whether they are a good approach + <Pete-J> meaning that viengoos is a research kernel that could aid Mach? + <neal> I'm not sure I understand your question + <Pete-J> Well is viengoos trying to be a replacement for Mach, or will + viengoos be an experiment of new ideas that could be implemented in Mach? + <Pete-J> i am sorry for my limited english + <neal> viengoos was designed with a Hurd-like user-land in mind + <neal> in that sense it was a Mach replacement + <neal> (unlike L4) + <neal> viengoos consisted of a few experiments + <neal> one could implement them in mach + <neal> but it would require exposing new interfaces + <neal> in which case, I'm not sure you could call the result Mach + <Pete-J> Well as i understand you develop two microkernels side by side, + wouldnt it be more effective to investigate viengoos more and maybe move + the focus to viengoos? + <antrik> no + <antrik> having something working all the time is crucial + <antrik> it's very hard to motivate people to work on a project that might + be useful, in a couple of years, perhaps... + <Pete-J> Well Mach is meant to be replaced one day - i see no reason to + keep on developing it just because it works at this moment + <Pete-J> *if Mach is meant to be replaced + <antrik> it's not at all clear that it will be replaced by something + completely different. I for my part believe that modifying the existing + Mach is a more promising approach + <Pete-J> as i understand man power is something you need - and by spreading + out the developers just makes the progress more slow + <antrik> but even if it *were* to be replaced one day, it doesn't change + the fact that we need it *now* + <antrik> all software will be obsolete one day. doesn't mean it's not worth + working on + <antrik> the vast majority of work is not on the microkernel anyways, but + on the system running on top of it + <Pete-J> ahh i see + <antrik> manpower is not something that comes from nowhere. again, having + something working is crucial in a volunteer project like this + <antrik> there are no fixed plans + + # Olaf, 2011-04-10 This version mixes up three distinct phases: rewrite from scratch; redesign; @@ -118,3 +178,144 @@ please discuss them... <antrik> Xnu implements a few improvements that might be helpful; but it doesn't address the really fundamental issues that matter for a true multiserver system... + + +# IRC, freenode, #hurd, 2014-02-04 + + <bwright> Is hurd still using the Mach Microkernel? + <bwright> I am assuming the L4 port failed? + <teythoon> yes / yes, i believe so + <bwright> I am currently working as an intern on seL4 a verified + microkernel variant of L4. + <bwright> I was sort of interested as to why the port failed if there are + any old mailing list posts etc. + <bwright> Obviously if it is too much trouble to dig them up that is + understandable. + <teythoon> most interesting, i'm interested in software verification as + well :) + <teythoon> there's some stuff in the wiki + <bwright> (I am writing a multiserver atm on top of it) + <teythoon> + http://www.gnu.org/software/hurd/history/port_to_another_microkernel.html + <bwright> Awesome thanks. + <braunr> bwright: iirc, l4 lacked some important asynchronous stuff + <braunr> the all synchronous model proved insufficient for an efficient + posix conforming system + <bwright> Yep, posix can get very annoying in places. + <bwright> Variants of l4 have async stuff that could probably work. + <braunr> okl4 is the only one i know of that does this + <braunr> but it may not have been the only issue + <bwright> That is the one I am working with :p + <braunr> the l4-hurd mailing list archives should tell you more about this + <bwright> Great :D + <bwright> Going to read through them and look into it. + <braunr> there was also an attempt on coyotos which failed for other + reasons related to the overall security mechanisms of the system iirc + <braunr> enjoy ;p + <bwright> On a side note I am also very interested in Multiservers. + <braunr> so are we :) + <bwright> I wouldn't mind hacking on hurd for fun in my spare time. + <braunr> it would probably be appreciated + <bwright> Currently porting a fuse implementation to L4 which is taking all + my time. But might hang out in the chat and mess around where I can. + + +## IRC, freenode, #hurd, 2014-02-06 + + <antrik> bwright: the original l4hurd was abandoned because original L4 + didn't have any capability support, and implementing them in userspace + turned out too complex and too much overhead + <antrik> capability-enhanced L4 variants were only emerging at that time; + and while they were evaluated briefly, the Hurd/L4 initiators turned to + other ideas instead. the feasability of a Hurd port on a modern L4 + variant was never evaluated deeply + <antrik> ultimately, the conclusion was that system design and microkernel + design are interwoven very tightly, and it doesn't make sense to try to + build something as complex as the Hurd on top of a microkernel not + specifically designed for it + <antrik> (this is in fact the same reason why the original Hurd on Mach + turned out so problematic...) + <cluck> antrik: fwiw i agree with what you said but it's a good idea to + keep stuff like genode in mind, in fact i'd go as far as saying that in a + microkernel it's a good thing to have interchangeable modules that can be + easily swapped :) + + +# IRC, freenode, #hurd, 2014-02-09 + + <cusement> braunr: would you share your negative opinions about + disadvantages of the existing L4s? A link to a dicussion is also fine of + course. I know my questions might be annoying, since im not deeply into + the materia yet. But Im interested in working on a open source kernel & + OS alternative suitable for mid/long term requirements, after I was + struggling with many deficits of monolithic kernels for years. + <braunr> cusement: there are two i know of: 1/ many of them are purely + synchronous, a property that makes it hard to provide some async unix + facilities like signals or select and 2/ they don't implement + capabilities, merely thread-based messaging, so capabilities would have + to be implemented in user space + <cusement> i was recently reasearching for alternatives, since i am simply + fed up with the chaotic situation with the Linux kernel + <cusement> like Mach, XNU , ... + <cusement> well, im still doing my research on alternatives, ATM i simply + found L4 to have more future potential than Mach + <braunr> cusement: can i ask you why you think that ? + <cusement> for example i like the fact that there is (at least one) L4 + variant that is proofen "right" on theoretical basis, since i am very + interested in creating a system with high security + <braunr> cusement: what do you think does the formal proof bring to a piece + of code that is, by definition, small enough to be easily audited ? + <cusement> braunr: statistics. i could also write a small piece of parser + manually, but when it comes to security, i rather prefer a parser + generator, since it ensures that it will actually create a parser that + will be secure, no metter with which grammar definition i feed it + <braunr> cusement: i agree, but the part of the system it covers is so + small it requires more justification + <braunr> cusement: any other main reason ? + <braunr> (we're not going to debate the merits of sel4 right now :)) + <azeem> cusement: if you are experienced in Linux device drivers, maybe you + want to check out DDE? + <cusement> braunr: well, i first actually have to check what the precise + scope of the L4 proof was to judge about its importance. I actually just + started to re-spawn my interest in micro kernels after years where i + abondened it for myself as being not practical relevant. + <braunr> ok + <cusement> azeem: that was actually one of the biggest reasons for me to + look at HURD. Because i am very unhappy about the chaotic driver + situation in Linux, with no isolation whatsoever. + <braunr> cusement: the hurd design is focused on quite more than that + <braunr> cusement: it's a property of practically all multiserver systems + out there to isolate each other + <braunr> other properties makes the hurd apart + <cusement> braunr: i know, but there also hybrids like XNU where drivers + are still in kernel space + <braunr> i don't consider xnu to be a multiserver system + <cusement> braunr: well, xnu also runs various fundamental services as + separate tasks / servers + <braunr> cusement: let me check + <cusement> xnu is mach based, and every mach derivative uses a multiserver + design, doesnt it? + <braunr> no + <braunr> practically all mach based systems were monoliths in userspace + <cusement> you mean kernel space + <azeem> cusement: certainly at least the NeXT/OS X Mach-based setup is not + very multiserver + <braunr> cusement: no i mean userspace + <braunr> darwin and mac os x are good examples of such systems + <cusement> braunr: so you mean individual fundamental OS tasks on XNU are + actually just processed by one server + <cusement> havent really digged too deep in XNU, because of its monolithic + driver concept + <braunr> cusement: yes + <braunr> it's basically a bsd server on top of mach + <cusement> ok, got it + <antrik> braunr: OS X actually runs the UNIX server in kernel space as well + AFAIK + + +## IRC, freenode, #hurd, 2014-02-10 + + <antrik> braunr: I believe all the "modern" L4 variants have some kind of + capability support -- though they differ in the details, and when Marcus + and Neal did the initial evaluation of the first two of them, it was not + yet clear yet whether it would suffice for the needs of the Hurd... diff --git a/glibc/file_descriptor.mdwn b/glibc/file_descriptor.mdwn index 2c56d070..78c496b1 100644 --- a/glibc/file_descriptor.mdwn +++ b/glibc/file_descriptor.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 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 @@ -11,3 +11,33 @@ License|/fdl]]."]]"""]] A [[UNIX file descriptor|unix/file_descriptor]] is implemented in [[glibc]] by using operations on objects referred to by [[Mach ports|microkernel/mach/port]]). + + +# IRC, freenode, #hurd, 2013-11-29 + +[[!tag open_issue_documentation]] + + <gnu_srs> Hi, are there any advantages to use the __USEPORT and + HURD_DPORT_USE etc macros? + <braunr> some things don't work without htem + <teythoon> I wondered that too + <teythoon> could you be more specific ? + <braunr> i can try + <braunr> __USEPORT is merely a wrapper to HURD_DPORT_USE + <braunr> HURD_PORT_USE handles concurrent access to ports + <braunr> is that enough ? + <teythoon> so not using these makes loading the port name racy ? + <braunr> shared ones, yes + <braunr> mostly, file descriptors + <teythoon> ok + <teythoon> so yes, that's reason enough ;) + <gnu_srs> so even if file descriptor ports are not accessed, it's use is + preferred? + <gnu_srs> I assume the answer is yes:-D + <braunr> gnu_srs: not accessed ? + <gnu_srs> file descriptor ports not used, but e.g. auth ports + <gnu_srs> there is code in hurd and eglibc sometimes using the macros, + sometimes not + <braunr> the macro is used when ports are shared + <braunr> or can be shared + <gnu_srs> k!, thanks diff --git a/glibc/startup.mdwn b/glibc/startup.mdwn index b7ab9d96..24553048 100644 --- a/glibc/startup.mdwn +++ b/glibc/startup.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 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 @@ -18,3 +18,17 @@ is quite hairy on GNU Hurd systems. * [[!message-id "3B7BF2B1.1417CD84@alcor.concordia.ca"]] * [[!message-id "871xc9qv6y.wl@ulysses.g10code.de"]] + + +# IRC, freenode, #hurd, 2013-12-31 + + <youpi> braunr: btw, after patching glibc and trying installing it, do you + try rebuilding hurd against it? ext2fs.static often breaks due to details + <braunr> youpi: yes + <braunr> youpi: always + <youpi> ok, good :) + <braunr> i want the rootfs to benefit from it too :) + <youpi> heh :) + <braunr> and yes, there were issues that occurred only in the rootfs + <braunr> but because of the special early state, not because of static + linking @@ -31,3 +31,176 @@ supports the multiboot standard, necessary to boot the Hurd. '$(task-create)' '$(task-resume)' module /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)' } + + +# syslinux' `mboot.c32` + +## IRC, freenode, #hurd, 2014-02-08 + + <anonymuouss> hey I am runnign debian GNU/hurd , si sthe best release? I + would like to write a guide on multibooting, GNU/linux, NetBSD, and + GNU/Hurd from the same live OS image + <anonymuouss> I can basically handle all of the linux stuff, but native + booting NetBSD and , i am guessing Hurd, are going to be pretty hard + <anonymuouss> i want to focus on using syslinux's mboot.c32 module, though + i have no ttested, i think it will boot hurd just fine + <anonymuouss> as hurd is so firmly connected to multiboot specfication.. + <anonymuouss> soem background history is that apparently there is something + wrong with FreeBSD multibooting + <anonymuouss> So it has spawned a huge amount of public testing regarding + dual booting iso9660 with GNU/linux and FreeBSD + <anonymuouss> come to find out NetBSD is actually the main group supporting + multiboot compliancy + <anonymuouss> bleh anyway, if you guys can help me will all of this, that + would be great. but either way, i wanted to gicve a long winded thanks + <anonymuouss> the main problem i am having is tell given kernel, that i + need it to load a ram based file system + <anonymuouss> with linux this is easy, just because i have used it so + much. i nkow how to attach a fileystem to the kernel, and embed a boot + command line + <youpi> anonymuouss: for the hurd case, you can have a look at the debian + installer cd, it uses some sort of initrd + <anonymuouss> lol xorg works.. i was not expecting that! + <anonymuouss> youpi: thanks + <anonymuouss> yeah looking at the live distributions has been a mainstay , + <anonymuouss> youpi: right, becasue debian will usually make their install + have an option to totally run in ram + <anonymuouss> they may have already fighured this out + <anonymuouss> I am impressed as hell with hurd kernel + <youpi> well, "they" is the same as "hurd maintainers", mostly :) + <anonymuouss> going to work picking around at this multiboot code a bit + later, looks the GNU doc on that is meant to be very educational + <anonymuouss> ok nice, so i verfied that hurd kernel is multiboot + compliant, and successfully loads with syslinux's mboot.c32 + + +## IRC, freenode, #hurd, 2014-02-09 + + <anonymuo1ss> I need to boot Hurd into ram off of iso9660 or vfat , or ext + using syslinux' mboot.c32 multiboot module. One of my reasons for + shoosing hurd kernel was multiboot compliancy to test this feature. So i + have aunique use case, of needing to load the hurd kernel an root + filesystem into memory. as using the root of the disk, is likeley + unsuitable. as with any live OS. I have acquired the components of the + debian install release. http://ftp.debian-po + <anonymuo1ss> what arguments can i pass to my multiboot "kernel" + "mboot.c32", in order to get this to boot to a simple example system ( + full functionality is not required) + <anonymuo1ss> Additionally i am willing to try putting hurd on the root + filsystem, but i would still like to boot it "natively" with the + mboot.c32 from syslinux. partially just to help expand documentation on + thier project + <anonymuo1ss> so i could use ext2 for the base i guess, if that would help + <braunr> anonymuo1ss: install debian hurd and look at the grub + configuration + <braunr> you'll have the command line arguments there + <braunr> use the preinstalled image in the topic to quickly boot one in a + virtual machine + <anonymuo1ss> that line is so long i am not sure it even will load with + systelinux + <anonymuo1ss> syslinux* + <anonymuo1ss> took me years to learn to boot linux to ram, no one helped + <anonymuo1ss> this is apparently is going to be more difficult, if i dont + get your guys help, i might be able to "install hurd" but i certainly + wont be able to use it or write about how to use it + <braunr> don't get it wrong but we're not very interested in making it boot + with syslinux + <anonymuo1ss> and multiboot code documentation is dwindling.. basically no + one gies a shit, not about syslinux, not about hurd, except for me. i + have read the same paragraphs from mailing lists 100s of times + <braunr> it works with grub, it complies with the mb spec + <anonymuo1ss> well look at how heavily it is depending on grub, i cant + reaally even pretend to understand how that works + <anonymuo1ss> and it is kind of obvious that you can not either + <braunr> no it's not + <braunr> i do + <anonymuo1ss> anyway , if you dont know how to help, it is ok + <braunr> i have implemented my own boot loader long ago + <braunr> and i have read about the boot scripts of gnu mach + <braunr> i know that part and i can help + <anonymuo1ss> i will just keep on doing all of this work on my own for fre, + with no bebefit and no help + <braunr> i won't fix the mboot code of syslinux for you though + <anonymuo1ss> well maybe sysylinux is the problem + <anonymuo1ss> it is sort of a toss up trying to decide who cares less abotu + this, hurd or syslinux + <braunr> noone cares + <anonymuo1ss> pretty even tie, for not giving a flying shit either way + <anonymuo1ss> obvious thumb down on the little guy + <anonymuo1ss> from both gnu and peter alvin + <braunr> i don't see syslinux as being something that was intended to + support anything else than linux in the first place + <anonymuo1ss> well that is where you are wrong + <braunr> no i'm not + <braunr> :) + <anonymuo1ss> obviously anything that has multiboot modules supports other + OS + <anonymuo1ss> lol + <anonymuo1ss> idiot + <braunr> if written right and well maintained + <braunr> and mboot support came very late in syslinux + <anonymuo1ss> seriosuly if you are brains behind this, i see why there are + no docs + <braunr> uh, you're the noob here, you're whining, and now you're insulting + <anonymuo1ss> no im no noob + <anonymuo1ss> im writing free guides to help people, and they are damn + concise + <braunr> if you weren't, you would understand how to adapt grub conf to + syslinux quickly + <anonymuo1ss> i have people making whole linux systems and frebsd is the + length of that damn grub line + <braunr> despite the "long line"s as you call them + <anonymuo1ss> lol + <braunr> the number of parameters is very short + <braunr> like 2 per module + <braunr> just copy them verbatim, what's hard with that ? + <antrik> anonymuouss: a followup remark regarding syslinux: does it really + have full multiboot support, including additional modules? or maybe it + only implements as much of the specification as necessary to load only + the kernel itself? + <anonymuouss> antrik: I wrote the syslinux mailing list this morning, with + details about some simple ways to download "ext2fs.static gnumach.gz + initrd.gz and ld.so.1" from + http://ftp.debian-ports.org/debian-cd/hurd-i386/current/ and package them + to boot with the syslinux "mboot.c32" from iso9660. And showed them the + proper kernel and module configuration lines from the netinstall's + "grub.cfg". So I am hoping to get a reponse soon from Peter Alvin or G + + +## IRC, freenode, #hurd, 2014-02-10 + + <anonymuouss> I am readin here in multiboot specifications, + http://www.gnu.org/software/grub/manual/multiboot/multiboot.html#Boot-modules + , that it is optional for designers of bootloaders to include this + ability to load modules. So I am guessing the syslinux devs made ample + use of that allowance. + <anonymuouss> as you were suggesting. I will try to take the code apart and + read it some. But it is looking like maybe grub is the more stabke choice + for multibooting. + <anonymuouss> probably even a bit of magic with packaging hurd would make + it possible. but only 1 out of 10,000 people even know how to properly do + that with linux kernel main, so will take some time i guess + <anonymuouss> jus to quote, because the multiboot spec is written by + someone smarter than me " While these additional modules could be + embedded in the main OS image along with the kernel itself, and the + resulting image be split apart manually by the operating system when it + receives control" + <anonymuouss> I am guessing they are referring to some remote potential for + Hurd kernel to compiled that way, though i am merely speculating + <anonymuouss> So i am hunting down docs on doing this with Hurd. Who knows + maybe somethign fun and interesting will come of it + <antrik> anonymuouss: IIRC Hurd in Xen used one-file archieves initially + before pv-grub was operational. but the "ordinary" way to load the Hurd + is using modules, which I suspect is not implemented by syslinux... + <antrik> I don't think there is another system beside the Hurd using the + modules feature of multiboot. in fact, GRUB and the multiboot + specification were originally written for the Hurd... + <anonymuouss> I am hopeful about including the files (into the kernel) for + simplicities sake, as an experiemnet. And and in the meantime, continiung + to learn about grub's model for accomplishing this. Everythign is going + fine on my ned, I am working with a simple qemu install of debian + GNU/hurd. Hopefully will be compiling some kernels later tonight. thought + i may need to switch to reral hard ware for that + <anonymuouss> thank you for the input antrik , I have not heard back from + syslinux devs yet, my guess is that they are thinking hard abotu how to + solve this, and dont want to "jump the gun" diff --git a/history/port_to_another_microkernel/discussion.mdwn b/history/port_to_another_microkernel/discussion.mdwn deleted file mode 100644 index f2161195..00000000 --- a/history/port_to_another_microkernel/discussion.mdwn +++ /dev/null @@ -1,69 +0,0 @@ -[[!meta copyright="Copyright © 2009, 2011 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -IRC, #hurd, 2011-01-12. - -[[!taglink open_issue_documentation]] - - <Pete-J> Hello i am just curious of the development of Hurd - what's the - current mission on the microkernel i see projects like l4 and viengoos, - will one of these projects replace Mach? or will you stick with Mach - <Pete-J> as i understand is that Mach is a first generation microkernel - that's very old in design and causes alot of issues - <Pete-J> that's where l4 and viengoos comes in - they are trying to be the - next generation Mach - am i correct? - <neal> l4 is not a drop in replacement for Mach - <neal> it doesn't actually do much resource management - <neal> for instance, you still have to implement a memory manager - <neal> this is where several issues are with Mach - <neal> l4 doesn't address those issues; it punts to the operating system - <Pete-J> and what about viengoos? - <neal> it's unfinished - <neal> and it implemented some untested ideas - <neal> i.e., parts of viengoos were research - <neal> there has not been a sufficient evaluation of those ideas to - determine whether they are a good approach - <Pete-J> meaning that viengoos is a research kernel that could aid Mach? - <neal> I'm not sure I understand your question - <Pete-J> Well is viengoos trying to be a replacement for Mach, or will - viengoos be an experiment of new ideas that could be implemented in Mach? - <Pete-J> i am sorry for my limited english - <neal> viengoos was designed with a Hurd-like user-land in mind - <neal> in that sense it was a Mach replacement - <neal> (unlike L4) - <neal> viengoos consisted of a few experiments - <neal> one could implement them in mach - <neal> but it would require exposing new interfaces - <neal> in which case, I'm not sure you could call the result Mach - <Pete-J> Well as i understand you develop two microkernels side by side, - wouldnt it be more effective to investigate viengoos more and maybe move - the focus to viengoos? - <antrik> no - <antrik> having something working all the time is crucial - <antrik> it's very hard to motivate people to work on a project that might - be useful, in a couple of years, perhaps... - <Pete-J> Well Mach is meant to be replaced one day - i see no reason to - keep on developing it just because it works at this moment - <Pete-J> *if Mach is meant to be replaced - <antrik> it's not at all clear that it will be replaced by something - completely different. I for my part believe that modifying the existing - Mach is a more promising approach - <Pete-J> as i understand man power is something you need - and by spreading - out the developers just makes the progress more slow - <antrik> but even if it *were* to be replaced one day, it doesn't change - the fact that we need it *now* - <antrik> all software will be obsolete one day. doesn't mean it's not worth - working on - <antrik> the vast majority of work is not on the microkernel anyways, but - on the system running on top of it - <Pete-J> ahh i see - <antrik> manpower is not something that comes from nowhere. again, having - something working is crucial in a volunteer project like this - <antrik> there are no fixed plans diff --git a/hurd/console.mdwn b/hurd/console.mdwn index 10c74bf9..411058c8 100644 --- a/hurd/console.mdwn +++ b/hurd/console.mdwn @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2011, -2012, 2013 Free Software Foundation, Inc."]] +2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -452,6 +452,17 @@ Added examples that use repeaters needed by X. <Tekk_> started typing something different +## IRC, freenode #hurd, 2013-11-28 + + <Gerhard> I see a mouse cursor, but I'm not able to copy and paste. gpm is + not in the repository, right? + <youpi> copy/paste is not actually implemented yet + <youpi> so you can move the mouse, but clicks don't do anything :o) + <teythoon> ^^ + <Gerhard> ok, thx for the feedback. + <teythoon> i always wondered if it was just me >,< + + # Graphics/Higher Resolution ## IRC, freenode #hurd, 2012-04-24 diff --git a/hurd/console/discussion.mdwn b/hurd/console/discussion.mdwn index 73d605ed..48e2009e 100644 --- a/hurd/console/discussion.mdwn +++ b/hurd/console/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -95,3 +96,136 @@ License|/fdl]]."]]"""]] <youpi> braunr: actually it seems like a bug in emacs <youpi> cud may or may not scroll the screen, depending on the implementation + + +# IRC, freenode, #hurd, 2013-12-28 + + <braunr> ahem, looks like the last xkb-data package dropped + /usr/share/X11/xkb/compat/default :/ + <ivanshmakov> braunr: Looks more like an upstream issue; check, e. g., + http://cgit.freedesktop.org/xkeyboard-config/commit/?id=882f5470713d. + <ivanshmakov> braunr: Slightly more surprising is that xkb-data 2.8 was + packaged for Debian last Sunday. While the upstream has released 2.10.1 + back in October, as per + http://www.x.org/releases/individual/data/xkeyboard-config/. + <gg0> ivanshmakov: + http://packages.qa.debian.org/x/xkeyboard-config/news/20131222T160519Z.html + <ivanshmakov> gg0: ACK, thanks. (No idea how did I read 2.10.1 as 2.8, as I + was looking on essentially the same information.) + + +## IRC, freenode, #hurd, 2013-12-30 + + <ZenWalker> on debian/hurd, with startx, show the error "cannot open + keyboard (no such file or directory)" + <braunr> ZenWalker: what version of xkb-data do you have ? + <ZenWalker> braunr: 2.10.1-1 + <braunr> ZenWalker: there is a bug in that package + <braunr> you can confirm it by spotting an error during system startup that + mentions a missing "compat/default" file + <braunr> this prevents the hurd console from starting + <braunr> and without the hurd console, xorg can't find the input device + <braunr> hopefully it will be fixed soon + <ZenWalker> braunr: yes, "couldn't open include file "compat/default"" + <ZenWalker> thanks + + +## IRC, freenode, #hurd, 2013-12-31 + + <braunr> youpi1: fyi, xkb-data doesn't provide compat/default, which + prevents the hurd console from starting + + <ZenWalker> braunr: X works with xkb-data 2.5.1-3 :) + + <braunr> maybe xkb-data isn't the problem + <braunr> maybe we need to fix the hurd-console + <braunr> youpi: we should probably fix the hurd with regard to xkb-data + before releasing the next packages + <braunr> it's very unlikely that xkb-data will be fixed + <braunr> they say compat/default is unused since march 2012 + + +## IRC, freenode, #hurd, 2014-01-01 + + <DusXMT> Is anyone else having problems with the console? + <gg0> downgrade xkb-data to + http://snapshot.debian.org/package/xkeyboard-config/2.5.1-3/#xkb-data_2.5.1-3 + <DusXMT> ty + + +## IRC, freenode, #hurd, 2014-01-04 + + <mihi> does anybody know if the fact that aptitude looks shitty on the hurd + console is a bug in the console implementation or some broken + term{cap,info} config? + <youpi> ncurses is pending a terminfo fix, possibly related + <youpi> you can try to recompile your hurd terminfo entry, adding xenl to + it, and see whether it fixes it + <mihi> hmm, just did an aptitude upgrade, and now after a restart the Hurd + console does not even start any more (did not mess with my terminfo yet) + <mihi> Couldn't open include file "compat/default" + <youpi> yes, xkb-data broke, downgrade it + <mihi> youpi, to which version? + <youpi> well, the previous one :) + <mihi> (or can aptitude or another tool show me what version I had + previously?) + <youpi> you can simply take the but-last on snapshot.debian.org + <mihi> youpi, thanks, that helped. And adding xenl to hurd.ti and + recompiling helped, too :) + + +## IRC, freenode, #hurd, 2014-01-13 + + <gnu_srs> Couldn't open include file "compat/default" from the console + <teythoon> that has been reported on the ml and as debian bug + <teythoon> a workaround is both in the upcoming hurd package as well as in + the ones i provide in hurd-ci + <gnu_srs> Any workaround for the hang in the console for now? + <teythoon> there is no hang + <teythoon> there is simply no getty + <gnu_srs> how come? + + <gnu_srs> and the xkb-data problems I thought was causing problems with the + hurd console to start, not the mach console. + <teythoon> gnu_srs: exactly, the missing xkb data prevents your + hurd-console from running + + +# IRC, freenode, #hurd, 2014-02-05 + + <bu^> btw, does the console handle other keymaps than the qwerty US one ? + Samuel thibault talked about this during his fosdem conference + <braunr> it does + <braunr> check /etc/default/hurd-console + <bu^> how ? I mean which lib does it use, because I face a similar issue + with my programms and would like a "smart" way to handle this (meaning + not reimplement something doing it worse) + <bu^> thx + <braunr> bu^: xkb + <bu^> I'm not clear with xkb and how much it is related to xorg, I would + like to be xorg independant, but the hurd console also should be and it + seems to work + <youpi> bu^: xkb is just a library + <youpi> xorg uses it + <youpi> but other applications can use it + <youpi> it just happens to be maintained by x.org people + <bu^> oh ok, nice, I'll look at it + <bu^> we are talking about this one ? + http://www.x.org/releases/current/doc/libX11/XKB/xkblib.html + <youpi> yes + <bu^> btw the way special caracters like é or à breaks the backspace + (erase) key as it will not count properly the number of caracters on the + line + <bu^> and I end up with remaining caracters I can't erase + <bu^> I also started to look for this one but didn't find a proper way to + use it as a library http://www.kbd-project.org + <youpi> bu^: probably a bogus locale + <youpi> that just works for me + + +# IRC, freenode, #hurd, 2014-02-25 + +[[!tag open_issue_hurd]] + + <gg0> to reproduce "task f5ca6e40 deallocating an invalid port 1711, most + probably a bug." just restart hurd-console diff --git a/hurd/critique.mdwn b/hurd/critique.mdwn index c432cc17..69400c5c 100644 --- a/hurd/critique.mdwn +++ b/hurd/critique.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="A Critique of the GNU Hurd Multi-server Operating System"]] @@ -18,3 +19,29 @@ is sometimes referred to as *the critique*. The paper provides a technical overview of the Hurd's architecture and critiques some of the decisions made. + + +# IRC, freenode, #hurd, 2014-02-06 + + <bwright> Just read a paper on hurd. + <bwright> Some interesting dot-dot and chroot issues were raised. + <bwright> But this was written my guess is in about 2007. + + +## IRC, freenode, #hurd, 2014-02-08 + + <antrik> bwright: both the dot-dot and chroot issues are fairly easy to + solve... of course they do indicate some more fundamental things to keep + in mind though. in fact, a few years ago we came up with a concept for + making filesystem permission handling more robust... but nobody ever got + to implementing it :-( + <antrik> bwright: this paper, I guess you are referring to the "critique"? + it was in fact written by the Hurd/L4 initiators. the observations made + in this paper are right, but IMHO they got carried away on the + conclusions -- most of the issues can be solved within the existing + framework, if you think about the actual problems seriously + <azeem> so they didn't think about it seriously? + <antrik> azeem: not in the right mindset I'd say :-) + <antrik> macrus actually said himself a while later that he probably + could/should have implemented some of the ideas within the existing + Hurd... diff --git a/hurd/debugging.mdwn b/hurd/debugging.mdwn index ae9b7bef..e0da8e76 100644 --- a/hurd/debugging.mdwn +++ b/hurd/debugging.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2013, 2014 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -53,3 +53,188 @@ License|/fdl]]."]]"""]] <braunr> a temporary receive right to get replies from servers <hacklu> so we can reuse the name which are freed before <braunr> of course + + +## IRC, freenode, #hurd, 2013-11-08 + + <teythoon> braunr: btw, portinfo --search turned out quite nice for + detecting port leaks + <braunr> teythoon: something you added i guess ? + <teythoon> braunr: just yesterday + <teythoon> braunr: portinfo.c is full of useful ideas + <teythoon> braunr: for example, with a little help of the target server + (introspection protocol for libports) we could reliably detect leaks of + ports managed with libports + <braunr> yes introspection is probably required + + +## IRC, freenode, #hurd, 2013-11-20 + + <braunr> looking forward to using portinfo --search btw :) + <teythoon> yeah, that turned out to be quite helpful + <teythoon> that reminds me of the libports introspection idea :) + <braunr> introspection ? + <braunr> i mean + <braunr> that much, or a simple name for each port ? + <teythoon> I thought about returning more information, like the port class + <braunr> class ? + <braunr> i don't think you should + <braunr> iirc, classes are deemed not very useful for hurdng + <braunr> they were supposed to be removed, leaving only buckets + <teythoon> hurdng ... ? + <braunr> which seems more appropriate + <braunr> oh :) + <teythoon> well, no need for an introspectino interface then + <braunr> http://www.gnu.org/software/hurd/hurd/ng.html + <braunr> introspection is a bit too much + <teythoon> just look at the ports in the only port set then + <braunr> but something that would be reusable in lsof + <braunr> or /proc/*/maps + <braunr> would be very nice + <teythoon> if you could just be a little more specific then I might just go + and implement it ;) + <antrik> braunr: I don't think bucket information would be useful to the + outside world; classes OTOH might + <teythoon> worked fine with the mtab translator, let's do that again ;) + <braunr> antrik: buckets aren't, clearly + <braunr> antrik: more than classes, object types + <braunr> teythoon: well cat /proc/self/maps on linux + <antrik> ain't that the same? ;-) + <braunr> i don't know + <braunr> and i'm not sure it's that easy to make classes/types something + global + <braunr> so simply returning a path, or even more generally a description + string (sometimes a path) + <braunr> should be fine + <braunr> teythoon: just consider ports are frontends to objects + <teythoon> yes + <braunr> what i'd like is something like object.toString() :p + <teythoon> right + <braunr> something that would help us gather information about objects + accessible from user applications + <braunr> what is known as open files on unix :) + <teythoon> so 1) get a list of ports managed by libports, and 2) map those + ports to strings describing the object ? + <braunr> the list isn't strictly necessary + <braunr> just associate a string description to ports + <braunr> portinfo and such already create port lists + <teythoon> and fail if the port wasn't vaild? + <teythoon> rihgt + <braunr> well + <braunr> if the port isn't valid, you can't succeed anyway + <braunr> but + <braunr> what is more likely is the port not supporting the operation + <teythoon> yes + <braunr> in which case assume the empty string + <braunr> it may not be that straightforward + <braunr> imagine reply ports in select() for example + <teythoon> so where would I put such an rpc ? + <braunr> i'm not sure + <braunr> for a time, i considered making it a kernel call + <braunr> it could be implemented in the signal thread too + <teythoon> uh, oh, that's glibc land, right... ? + <braunr> in addition to "what are you waiting on", we could have "what's + the name for that port" + <braunr> yes + <braunr> :) + <braunr> well not name + <braunr> port names refer to integers + <braunr> port desc + <teythoon> yes + <braunr> i'm not sure how it should be done + <braunr> ideally, user applications should never have any reply ports + <braunr> and we could implement it all in libports + <braunr> select (and maybe others) make it hard + <teythoon> how so ? + <braunr> such calls don't expect any kind of request + <braunr> other than what's intended + <braunr> if select gets something else than a select reply, it returns with + an error + <teythoon> so ? + <braunr> changing that to deal with unexpected requests makes the select + implementation even harder than it is + <braunr> hum so, you don't want something like a mail server to fail + because you used lsof right ? + <teythoon> why would it get unexpected requests ? + <teythoon> no + <braunr> a new rpc like "give me your description" would be unexpected for + select + <braunr> servers properly demuxing messages would already reply they don't + implement the interface + <braunr> select would return an error to its caller + <braunr> that's very different + <teythoon> ah, well, ok, but if we put it in the signal thread, then lsof + would talk to that port + <braunr> yes + <teythoon> you mentioned that as a reason not to put it in libports ? + <braunr> yes + <braunr> normal applications don't use libports + <braunr> but they do have receive rights + <teythoon> I see, yes + + +## IRC, freenode, #hurd, 2013-11-29 + + <braunr> is the format of portinfo --search ORIG_PID => ... FOUND_PID => + ... ? + <teythoon> i think so, not sure atm + <braunr> 4 -> 5: 1 => 1: send (refs: 65534) + <braunr> :/ + <braunr> hm i don't see such a right in pid 1 + <teythoon> no, frompid -> topid: port name in frompid => corresponding name + in topid + <braunr> oh ok + + +# IRC, freenode, #hurd, 2013-11-08 + +[[!tag open_issue_gdb]] + + <braunr> what i'd like personally would be gdb to be able to track threads + across address spaces, when it has the right to do so + <crocket> braunr, can gdb debug across threads? + <braunr> no + <braunr> the same is it can't follow system calls + <braunr> it can follow RPCs + <crocket> Then, I guess you have to debug multiple applications at once. + <braunr> can't* + <braunr> well + <braunr> the goal would be that + <braunr> right now, we debug them one at a time + <braunr> following our leads across applications + <braunr> it's a bit more tricky but not that hard + <teythoon> braunr: that would be nice indeed + <braunr> we're talking about cross-address-space debugging + <braunr> which is needed only when objects are shared between multiple + applications + <crocket> gdb can't do it + <braunr> but it can't do it on a monolithic system either + <braunr> people debug the kernel separately + <braunr> we debug our servers separately + <braunr> it's almost the same + <braunr> we don't debug all our servers, only those relevant in the code + path + <braunr> that's only a few + <teythoon> no it's worse for the monolithic kernel + <crocket> braunr, "Additionally, just tracking down a FS/write issue means + examining the user space process, the block device service, VFS service, + file system service and (possibly) the PCI service. If you get a blank on + that, its time to look at the IPC service. This is often easier in a + monolithic kernel." + <braunr> teythoon: depends + <braunr> crocket: agreed + <braunr> but again, such bugs are huge + <braunr> rare + <braunr> the only real class of cross-address-space bugs are leaks + <braunr> and leaks are easy to solve in practice + + +# [[open_issues/Translate_FD_or_Port_to_File_Name]] + + +# IRC, freenode, #hurd, 2014-01-30 + + <pere> btw, is there some alternative to strace? wanted to figure out why + lightdm didn't find dbus. + <pochu> there's rpctrace but that's a bit different + <youpi> there's also sotruss from recent glibc diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index d62a4387..dbd4b30b 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013 Free -Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 +Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -225,6 +225,126 @@ See `rpctrace --help` about how to use it. <braunr> select is partially hand written <braunr> but it's a special case so that's ok +* IRC, freenode, #hurd, 2013-12-11 + + <gnu_srs> teythoon: Congrats regarding rpctrace, is it now fully + functional? + <teythoon> should be + <teythoon> well, you should be able to use it on any application that uses + select + <teythoon> other than that, it's as functional as it ever was + <teythoon> i was annoyed that i couldn't rpctrace ping, and the fix was + much easier than expected + <gnu_srs> and fork is no problem anymore? + <teythoon> was it ever ? + <braunr> yes, fork and some issues + <teythoon> rpctrace should pick up any forked processes + <teythoon> oh ? + <braunr> thanks for rpctrace too + <braunr> it was indeed on the todo list for a long time + <braunr> ah fork with regard to rpctrace + <braunr> no i don't think so + <braunr> but + <braunr> rpctrace can't be a perfect proxy + <braunr> because some calls just go directly through the kernel + <teythoon> really ? + <teythoon> we could install custom functions for any such call + <braunr> system calls + <braunr> yes + <teythoon> so why couldn't it be perfect ? + <braunr> i don't see how custom functions would do the trick + <braunr> i mean + <braunr> it would help, but not guarantee applications have to use these + functions + <braunr> the real solution would be something like strace + <teythoon> huh ? + <teythoon> why wouldn't there be any guarantee like that ? + <braunr> rpctrace catches messages, not system calls + <braunr> you don't see calls to mach_reply_port() obviously + <braunr> you just hope that such reply ports are sent through messages + rpctrace will see + <teythoon> + http://www.gnu.org/software/hurd/gnumach-doc/Syscall-Emulation.html + <teythoon> sure one does + <braunr> ah that + <braunr> we don't want that :p + <teythoon> why not ? + <braunr> it's a hack + <braunr> and checking for those impacts performances a bit + <braunr> it would be better to change the system calls into RPCs + <teythoon> so ? it would only affect tasks running in rpctrace, and the + documentation does not call that interface a hack ;) + <braunr> oh i agree + <braunr> i was saying we don't want them the same way we don't want async + ipc + <teythoon> yeah sure, i agree + <braunr> but since that's how mach works, why not + <braunr> although iirc, checking for emulated syscalls is done by the + syscall entry code + <teythoon> so ? + <braunr> so it has an impact on every system call + <teythoon> we could make that a compile time option and use it in rpctrace + only when available + <teythoon> so anyone who needs good traces, could run that kind of kernel + <braunr> no need + <teythoon> for what ? + <braunr> mach and the hurd are already too slow for this to be noticeable + <braunr> let's just live with it and use syscall emulation + <teythoon> why do you say that, i mean, do you have numbers ? + <braunr> from what i see, it's a bunch of less than 5 instructions + <teythoon> ok + <braunr> i'm just being picky + <braunr> i really don't like the idea of emulated system calls + <braunr> RPCs are much cleaner + <braunr> and frankly, the system calls that i'd like to see in rpctrace are + those like mach_thread_self() + <braunr> to spot reference leaks + <braunr> not too annoying actually + +* IRC, freenode, #hurd, 2013-12-13 + + <teythoon> hm + <teythoon> i briefly looked into the haskell test suite failure youpi wrote + about + <teythoon> i looked at one of the haskell-http-conduit failures + <teythoon> i think it starts a dummy web server and does one request to + itself + <teythoon> the binary is using select, so i used the fixed rpctrace to + obtain a trace + <teythoon> it looks strange ... + <teythoon> the http request is answered before the request is sent + + <gnu_srs> teythoon: Nice to see that you added escape of non-printable + characters in rpctrace:-D + <teythoon> yeah, makes rpctrace less trippy though ;) + +* IRC, OFTC, #debian-hurd, 2014-02-20 + + * pere really misses strace. + <pere> rpctrace is not even close. + <teythoon> pere: why do you say that ? + <teythoon> pere: it is not that we couldn't write strace for mach, it + would just be very boring + <pere> teythoon: because strace tell me what a program does in details, + without too much irrelevant information, while rpctrace is just so + verbose that it is hard to see the relevant parts. + <youpi> well, they are mostly equivalent + <youpi> strace ls / gives me 200 lines, while rpctrace ls / gives me + 300 lines + <youpi> there are spurious lines like term_getctty, but otherwise it's + mostly the same level of details + <youpi> (also, mach_port_deallocate get in the way) + <pere> strace also have the great advantage for C programmers that the + output look like the equivalent C calls. + <youpi> well, twice as many lines is not so much more verbose :) + <youpi> but yes, having internal RPC names doesn't help + <youpi> another way would be to use sotruss + <pere> sotruss just gave me 'killed' + <youpi> yes, it probably needs fixing, nobody worked on it AFAIK + <youpi> that's why I said "would", not "is" :) + <pere> in the mean time, I'll just keep dreaming of something with + output like strace. :) + # See Also diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn index be20fa58..57588d55 100644 --- a/hurd/libihash.mdwn +++ b/hurd/libihash.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009, 2010, 2011, 2012, 2013 Free Software +[[!meta copyright="Copyright © 2009, 2010, 2011, 2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -22,23 +22,44 @@ License|/fdl]]."]]"""]] # Open Issues - * [[viengoos libhurd-ihash|microkernel/viengoos/projects/new_hash_function]] +## Collisions - IRC, freenode, #hurd, 2008/2009 +Viengoos: [[microkernel/viengoos/projects/new_hash_function]]. - <neal> so, we need a new ihash implementation - <neal> marcusb: When 80% full, the collision rate is very high. - <neal> marcusb: I tested using 512mb / 4096 entries - <neal> marcusb: Changing the load factor to 30% resulted in my program - running more than an order of magnitude faster. - <marcusb> yeah, it shouldn't get so full - <marcusb> don't we do an exponential back-off in the array size? - <marcusb> of course it's clear we can do much better - <marcusb> the ihash algo is very simple - <marcusb> I'm not even sure it makes much sense to have a generic - library - * [[community/gsoc/project_ideas/object_lookups]] +### IRC, freenode, #hurd, 2008/2009 + + <neal> so, we need a new ihash implementation + <neal> marcusb: When 80% full, the collision rate is very high. + <neal> marcusb: I tested using 512mb / 4096 entries + <neal> marcusb: Changing the load factor to 30% resulted in my program + running more than an order of magnitude faster. + <marcusb> yeah, it shouldn't get so full + <marcusb> don't we do an exponential back-off in the array size? + <marcusb> of course it's clear we can do much better + <marcusb> the ihash algo is very simple + <marcusb> I'm not even sure it makes much sense to have a generic + library + + +## Reader-Writer Locks + +### IRC, freenode, #hurd, 2013-12-09 + + <teythoon> btw, why don't we use rwlocks for serializing access to our + hash tables ? + <braunr> teythoon: we definitely could + <teythoon> ok + <braunr> teythoon: we definitely could use rcu *whistles* + <teythoon> should we ? + <braunr> i don't know + <teythoon> yeah, ofc + <braunr> rwlocks have some overhead compared to mutexes + <braunr> and our mutexes are already quite expensive + <braunr> our condition variables are also not optimized + + +# [[community/gsoc/project_ideas/Object_Lookups]] # Alternatives? @@ -64,3 +85,6 @@ License|/fdl]]."]]"""]] * <http://www.azillionmonkeys.com/qed/hash.html> * CCAN's htable, idtree + + * Not actually use a hashing data structure; see [[libports]], *Open Issues*, + *IRC, freenode, #hurd, 2013-11-14*. diff --git a/hurd/libports.mdwn b/hurd/libports.mdwn index 6f2cd46d..b0a0f6d5 100644 --- a/hurd/libports.mdwn +++ b/hurd/libports.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -35,3 +36,67 @@ when they are not used. ([[!taglink open_issue_hurd]]: there used to be bugs in this area, [[!message-id "87hev152we.fsf@becket.becket.net"]], but it may be fixed as of [[!message-id "20111030210045.GA4983@myhost"]], [[!GNU_Savannah_Git_hurd_hurd 9b5429e834cde56f73b8ff605e36afc7d9bb6e1b]].) + + +# Open Issues + +## Several on the [[/Open_Issues]] page + +## IRC, freenode, #hurd, 2013-11-14 + + <teythoon> # portinfo $(pgrep mach-defpager) | tail -n 1 + <teythoon> 16819001: receive + <teythoon> is that normal ? + <braunr> it can be, yes + <braunr> port names can be renamed + <braunr> there are a few occurrences in the code + <braunr> see + http://www.gnu.org/software/hurd/gnumach-doc/Port-Names.html#Port-Names + <teythoon> I know + <braunr> mach-defpager/default_pager.c: kr = mach_port_rename( + default_pager_self, + <teythoon> heh, it is a pointer + <teythoon> I thought that'd make stuff inefficient in gnumach? + <braunr> it does + <braunr> such rights are moved from a regular fast-access table to a splay + tree + <braunr> but when i looked into it, there were never more than a few dozen + rights in these trees + <braunr> (which is why i didn't merge my radix tree in gnumach) + <teythoon> I've been contemplating to replace the libihash usage in + libports with a simple array + <braunr> consider a radix tree too then :) + <teythoon> well, I did + <braunr> ok + <teythoon> but I'm not convinced that it would do better than a simple + array (or the current ihash implementation) + <braunr> really ? + <teythoon> what do you hope to gain? + <braunr> i'm practically certain it would do better than the current ihash + code + <braunr> uh, speed + <braunr> the problem with an array or a hash table is resizing + <braunr> a well tuned radix tree (say 64 ot 512 items per node) can reduce + to a simple array for the common case + <teythoon> right + <teythoon> but consider the use case + <braunr> and scale very well for massive users such as file systems which + can reach several hundred thousand rights + <teythoon> hm + <braunr> an array could be very efficient as well + <braunr> i'm just concerned about resizing + <teythoon> but this is a problem with the current implementation as well + <braunr> sure + <braunr> we're not considering keeping it anyway + <braunr> this discussion is about array vs radix tree + <braunr> the radix tree also has the advantage to efficiently deal with + sparsely populated port name spaces + <braunr> to some degree + <braunr> which is probably what you're currently concerned with about this + weird port name in defpager :) + <teythoon> http://paste.debian.net/65780/ + <teythoon> yes, but mach-defpager does not use libports + <braunr> ok + +See also discussion on [[microkernel/mach/deficiencies]], *X15*, *IRC, +freenode, #hurd, 2013-11-14*. diff --git a/hurd/libstore.mdwn b/hurd/libstore.mdwn index b2e7f7a9..45fc0860 100644 --- a/hurd/libstore.mdwn +++ b/hurd/libstore.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2013, 2014 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -65,3 +65,12 @@ feeds=no]] course, any results he got from his work really should be integrated more properly into the existing body of documents. <tschwinge> As with so many other documents/discussions/etc. ;-| + + +## IRC, freenode, #hurd, 2013-11-12 + +[[!tag open_issue_hurd]] + + <phcoder> Is it possible to specify hurd root by sth else than device name? + E.g. fs UUID? + <teythoon> phcoder: I do not believe so diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index a9acd9f9..6afa46fc 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010, 2011, -2012, 2013 Free Software Foundation, Inc."]] +2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -376,6 +376,70 @@ With Python, you can use the [`errno` module](http://docs.python.org/library/err Configure script often hardcode the library that contains dlopen & such (`-ldl`), and only for Linux. Simply add the other GNU OS cases: replace `linux*` with `linux*|gnu*|k*bsd*-gnu*` +## `struct sockaddr`, `sa_len/sa_family` + +### IRC, freenode, #hurd, 2014-02-18 + + <braunr> if there is someone here that can help, i've traced the https + issue in iceweasel down to nspr + <braunr> the problem being that the hurd uses the old 4.4bsd sockaddr + structure that includes sa_len before sa_family, and nspr directly maps + that into its own structure, assuming the internal layout is the same + <braunr> i need to change a configure script so that a macro is defined for + the hurd + <braunr> let's see if that works + <braunr> better :) + <braunr> there, ssl now works + <braunr> \o/ + <braunr> it's still the experimental one + <braunr> and there are other minor issues + <braunr> (like no logo on the about panel :p) + <cluck> that's a feature^TM + <braunr> maybe it's not a mistake + <braunr> i haven't seen that version on linux to actually compare + *** rbraun_hurd (c3445c23@gateway/web/freenode/ip.195.68.92.35) has joined + channel #hurd + <rbraun_hurd> webchat from freenode :) + <teythoon> :D + <rbraun_hurd> there is also this weird :"Failed to truncate cookie file: + Invalid argument Failed to write cookie file: Unknown error (os/kern) + 303" error + <rbraun_hurd> but i guess it's simply a matter of supporting an option in + glibc/hurd somewhere + <braunr> 18:06 CTCP VERSION reply from rbraun_hurd: qwebirc v0.91, + copyright (C) 2008-2011 Chris Porter and the qwebirc project -- + Mozilla/5.0 (X11; GNU i686-AT386; rv:27.0) Gecko/20100101 Firefox/27.0 + Iceweasel/27.0 + <braunr> hm, i didn't version the iceweasel packages :/ + <braunr> i'll rebuild them properly and put them on my repository + <braunr> oh, the freenode webchat actually runs in gnash oO + + +### IRC, freenode, #hurd, 2014-02-19 + + <braunr> http://darnassus.sceen.net/~rbraun/nspr4_hurd.patch + <braunr> in short: nsprt has its own struct sockaddr, which it assumes to + have the same layout as the native one + <youpi> doesn't kfreebsd also have sockaddr_len ? + <braunr> and of course, that's not the case on the hurd, because we use an + old 4.4bsd header that defines sa_len before sa_family, making all sorts + of tests fail in nspr + <braunr> hm + <braunr> i don't know + <braunr> we could discuss that with them + <braunr> but i doubt they don't use iceweasel :) + <youpi> it really seems kfreebsd has sa_len etc. + <youpi> kfreebsd really has sa_len + <youpi> so put it in the new case too :) + <braunr> i'll ask them first + <braunr> something in nspr might already take care of the bsd case + elsewhere + <braunr> nspr knows more about bsd systems than it knows about the hurd :) + <braunr> but with all these fixed, i could run iceweasel for a whole day at + work, multiple tabs, gnash running (things like youtube and freenode web + chat client among other things) + + ## <a name="linux_headers"> Missing `linux/types.h`, `asm/types.h`, `linux/limits.h`, `asm/byteorder.h`, `sys/endian.h`, `asm/ioctl.h`, `asm/ioctls.h`, `linux/soundcard.h` </a> These are often used (from lame rgrep results) instead of their standard equivalents: `sys/types.h` (or `stdint.h` for fixed-size types), `limits.h`, `endian.h`, `sys/ioctl.h`, `sys/soundcard.h` diff --git a/hurd/running/debian.mdwn b/hurd/running/debian.mdwn index 39c7d1a6..ac40ce79 100644 --- a/hurd/running/debian.mdwn +++ b/hurd/running/debian.mdwn @@ -22,3 +22,87 @@ *Debian GNU/Hurd*, [[MichaelBanck]], LinuxTag 2004 Karlsruhe - [[Status]] - [Archive Qualification](http://wiki.debian.org/ArchiveQualification/hurd-i386) + + +# IRC, freenode, #hurd, 2014-01-18 + + <anatoly> From http://darnassus.sceen.net/~hurd-web/hurd/running/debian/ + "Just in case you were wondering: the root password is root.". I think + it's not correct because it allows me to login witout password in hurd + console + <anatoly> Tried it in latest qemu image (from 2013 05 04) + <braunr> anatoly: you probably can change it yourself since it's a wiki + <anatoly> braunr: ok + + +# `/etc/mtab` -> `/proc/mounts` + +## IRC, freenode, #hurd, 2014-02-12 + + <braunr> hm, there is something weird + <braunr> after successfully installing (with the new installer cd), and + rebooting, system init fails because fsck can't be run on /home (a + separate partition) + <braunr> it can't fsck because at that point, /home is already mounted, and + indeed the translator is running + <braunr> teythoon: any idea what might cause that ? + <teythoon> me ? + <teythoon> no + <braunr> ok + <braunr> ah no, actually /home isn't mounted oO + <braunr> but fsck still refuses to check it, stating that reason + <braunr> hm, /etc/mtab isn't a link to /proc/mounts here, might explain + + +## IRC, freenode, #hurd, 2014-02-12 + + <braunr> yes, better with a proper symlink :) + <teythoon> good + <youpi> Mmm, what is supposed to create that symlink? + <teythoon> one debian init script did that at one time + <teythoon> i believe they dropped that + <youpi> err, but something must be creating it for newer systems + <teythoon> good point + <braunr> well, except for these small details, everything went pretty + smooth + <braunr> both on ide and ahci + <youpi> it seems /etc/mtab gets created at boot + <youpi> (on Linux I mean) + <teythoon> youpi: i cannot find the init script, but i'm sure that it was + there + <youpi> I can't find it either on the installed system... + <azeem> maybe pere or rleigh in #debian-hurd can help + + +## IRC, freenode, #hurd, 2014-02-13 + + <braunr> 6<--60(pid1698)->dir_lookup ("var/run/mtab" 4194305 0) = 0 3 + "/run/mtab" (null) + <braunr> looks like /etc/mtab isn't actually used anymore + <teythoon> it never was on hurd + <tomodach1> braunr: well it is generated i believe from mounted filesystems + <tomodach1> if its still around there is a reason for it, like posix + compatiblity perhaps? + <braunr> well the problem is that, as mentioned in pere's thread on + bug-hurd, some tools now expect /var/run/mtab instead of /etc/mtab + <braunr> and since nothing currently creates this file, these tools, such + as df, are lost + <braunr> they can't find the info they're looking for + + +## IRC, freenode, #hurd, 2014-02-17 + + <braunr> i still don't have mtab at the proper location on darnassus + <pere> is there something missing with sysvinit on hurd? + <braunr> is that normal ? + <pere> yes. I recommended fixing it in the hurd package. (BTS #737759) + <braunr> yes i saw but was there any action taken ? + <pere> did not check + <teythoon> i thought youpi mentioned that it is fixed in the libc and we + just need to rebuild coreutils or something + <pere> yes + <braunr> oh ok + <braunr> but doesn't that mean it will use /etc/mtab ? + <pere> if I was a hurd porter, I would fix it in hurd while waiting for a + fix in coreutils, just to save people for wondering about the breakage, + but I am not the most patient of developers. :) diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn index 849ff382..8846769a 100644 --- a/hurd/running/debian/dhcp.mdwn +++ b/hurd/running/debian/dhcp.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -124,3 +124,78 @@ scripts, but has its own `/libexec/rc` script -- which integrates scripts from in /dev/eth0) <teythoon> I tried to rebuild the package served on debian-ports, but that failed + + IRC, freenode, #hurd, 2014-01-03: + + <congzhang> dhcp 4.3 alpha released + <congzhang> and PATH_MAX issue was fixed + + IRC, freenode, #hurd, 2014-01-21: + + <gnu_srs> teythoon: what about this? *** stack smashing detected ***: + dhclient terminated + <teythoon> gnu_srs: well, dhclient dies + <teythoon> i've seen this, it comes and goes + <teythoon> not sure what happens, but i tend to blame it on our + custom-built dhcp package + <teythoon> from debian-ports, and it's outdated + <teythoon> it's most likely not your fault + <gnu_srs> i thought there was a new upstream by now + <teythoon> and the network configuration can be done with passive + translators as it was always done + <teythoon> there was ? + <gnu_srs> there is one recently released, haven't checked yet + <gnu_srs> in experimental: 4.3.0a1-2, does still not build out of the + box + <teythoon> there was, but it does not seem to build on the hurd + <teythoon> + https://buildd.debian.org/status/logs.php?pkg=isc-dhcp&arch=hurd-i386 + <teythoon> the most recent version is from debian-ports + + + IRC, freenode, #hurd, 2014-01-24: + + <braunr> stack smashing detected ***: dhclient terminated + <braunr> how nice + <tschwinge> braunr: dhclient: + http://news.gmane.org/find-root.php?message_id=%3C874ngfvwn4.fsf%40kepler.schwinge.homeip.net%3E + <tschwinge> braunr: And I thought, teythoon had found this to be a + buffer overflow; something like char dev[10], and for us the path to + the dev (/dev/eth0) was longer (but I may be misremebering). + <braunr> tschwinge: sounds reasonable + <tschwinge> braunr: By the way: I'm seeing this segfault all the time + during boot, but when I again run it manually (root login), it works + fine. + <braunr> tschwinge: you mean the dhclient one µ? + <tschwinge> Yes. + <braunr> mhm + <teythoon> braunr, tschwinge: i never found the cause of the dhclient + issue + <teythoon> i blame the (outdated) build on debian-ports + + + IRC, freenode, #hurd, 2014-01-30: + + <youpi> err, still nobody found the dhclient bug? + <gnu_srs> youpi: You found the dh-client bug, right? + <youpi> gnu_srs: yes, the dhclient bug was in libc, as tschwinge + guessed + <youpi> I'll probably upload a fixed glibc on debian-ports + + <gnu_srs> youpi: dhclient starts OK with libc 2.17-98~0 + + <youpi> btw, the experimental version of isc-dhcp has a newer + occurrence of PATH_MAX + <gnu_srs> :-( + <youpi> (aside from not including the needed debian files for + hurd-i386) + + * IPv6 + + IRC, freenode, #hurd, 2014-02-23: + + <gg0> seems dhclient can't also set ipv6 translator + <gg0> cheated by setting it manually, i had probably screwed it up + somehow + <gg0> exim was complaining 2014-02-23 22:26:41 IPv6 socket creation + failed: Address family not supported by protocol diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index a0b9e6da..df65eb7b 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, -2013 Free Software Foundation, Inc."]] +2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -275,6 +275,23 @@ but note that `ping` doesn't work with QEMU's user-networking stack. If you want to connect from the host system to the Hurd system running in QEMU, you can use port forwarding in QEMU or to setup something more advanced, like bridged networking. + +### IRC, freenode, #hurd, 2014-02-12 + + <braunr> youpi: also, the problems i had with regard to accessing the + debian repository were caused by a qemu bug where, in nat mode, qemu is + unable to handle dns requests if the host dns servers are ipv6 ones + <youpi> yes, we've noticed that with a student of mine + <youpi> you may be interested by a patch we submitted to qemu-devel, that + adds ipv6 support to -net user :) + <braunr> :) + <braunr> for now i directly change resolv.conf + <youpi> braunr: the issue is that you have only ipv6 nameservers, right? + <braunr> yes + <youpi> there's not much better to do than that + <youpi> (patching resolv.conf inside the guest, or apply the ipv6 patch) + + ## Port Forwarding in QEMU (In the following we assume we use kvm!) diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn index 10cfb3aa..68bbce44 100644 --- a/hurd/translator/auth.mdwn +++ b/hurd/translator/auth.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -19,3 +20,228 @@ It is stated by `/hurd/init`. [[*The_Authentication_Server*|documentation/auth]], the transcript of a talk about the details of the authentication mechanisms in the Hurd by Wolfgang Jährling. + + +## IRC, freenode, #hurd, 2013-10-31 + +[[!tag open_issue_documentation]] + + <braunr> is there an in-depth documentation somewhere about the auth server + that explains why there are "reauthenticate" operations everywhere ? + <braunr> nice, hammar's thesis does it :) + +[[hurd/documentation]], *Generalizing mobility for the Hurd*, Carl Fredrik +Hammar. + + +## IRC, freenode, #hurd, 2013-11-01 + + <gnu_srs> neal: Thanks, I'm trying to to call auth_server_authenticate + from a libc function, but that fails. That function returns MIG_NO_REPLY. + <gnu_srs> auth_user_authenticate works OK, but I need the IDs from the + auth_server_authenticate. What to do, implement a new RPC, + <gnu_srs> modify auth_user_authenticate (probably not) ? + <gnu_srs> or modify auth_server_authenticate (probably not) + <youpi> gnu_srs: show the source code you have written. MIG_NO_REPLY is not + expected, unless you called server_authenticate on the wrong port + <gnu_srs> S_auth_server_authenticate does not have any other exits than + MIG_NO_REPLY (and errors) + <gnu_srs> auth/auth.c + <youpi> yes, but it does do auth_server_authenticate_reply, which is what + matters + <youpi> i.e. what provides the answer + <youpi> (and the uids etc.) + <gnu_srs> I don't seem to be able to call that function directly from libc? + <youpi> eh? You're not supposed to call auth_server_authenticate_reply + yourself, it's auth which is supposed to + <youpi> precisely to provide the reply to the auth_server_authenticate RPC + <youpi> again, please show your source code + <youpi> there must be some mistake + <gnu_srs> Please show me how to call auth_server_authenticate and that + function returning 0 + <youpi> there are plenty of examples in the hurd source code + <youpi> e.g. ext2fs + <youpi> or libdiskfs, I can't remember where it is exactly inside ext2fs + <gnu_srs> I've tried all, on avail:( + <gnu_srs> no* + <youpi> € git grep auth_server_auth + <youpi> libiohelp/iouser-reauth.c: err = auth_server_authenticate + (authserver, + <youpi> was it so hard? + <gnu_srs> I did, and tried every combination, nothing works! + <youpi> something has to work, otherwise we'd have no uid authentication + against ext2fs + <youpi> so there must be a combination you missed + <youpi> did you understand how the authentication protocol works, for a + start? + <youpi> otherwise, random code will most probably never work, for sure :) + <gnu_srs> called from libc? + <gnu_srs> a libc function? + <youpi> being from a libc function or from an io_reauthenticate callback + does not really matter + <gnu_srs> well, random or not, please show me then + <youpi> it's already there in ext2fs + <youpi> again, if you don't understand *that* code, no need to try to write + other code, take time to understand what exactly happens in the ext2fs + case + <gnu_srs> ok, can you tell me how a function only returning MIG_NO_REPLY + can return 0 when called? + <gnu_srs> by a server or client + <youpi> maybe one thing you are missing: in the ext2fs case, we have the + sender use io_reauthenticate to provide the receiver (ext2fs) with the + reference port, in the sendmsg/recvmsg, it'll be the message which will + hold the ref port + <youpi> but otherwise it's all the same + <youpi> gnu_srs: as I said, by being called on the proper port, + <youpi> i.e. the auth port, with the ref port provided by the sender + <youpi> but again, without seeing your code, I can't divine what mistake + you may have done + <youpi> all I can do is that your code is supposed to really look very much + like the ext2fs case + <gnu_srs> there is a difference between io_reauthenticarte and + proc_reauthenticate, a subsequent call to auth_user_authenticate returns + 0 in the second case. + <youpi> i.e. _hurd_setauth in hurd/setauth.c and iohelp_reauth in + libiohelp/iouser-reauth.c + <youpi> why are you talking about io_reauthenticate an proc_reauthenticate? + <youpi> again, without seeing your source code, I can't understand what you + are talking about + <gnu_srs> first: (17:06:23) srs: ok, can you tell me how a function only + returning MIG_NO_REPLY can return 0 when called? + <youpi> and I can't afford the time to divine + <youpi> yes, that's iohelp_reauth in libiohelp/iouser-reauth.c + <youpi> for an example that works + <youpi> by using the proper ports + <youpi> if you don't get a reply, it's most probably simply because the + reply goes to the wrong port + <gnu_srs> again, where/how is the return value communicated by + auth_server_authenticate to the client/caller? + <youpi> again, it's the auth/auth.c code + <youpi> which calls auth_server_authenticate_reply + <gnu_srs> but that function ends with return MIG_NO_REPLY? + <youpi> yes, because auth_server_authenticate_reply() already did provide + the reply + <youpi> so the RPC function does not return a reply + <youpi> since it already explicitly sent one + <youpi> through auth_server_authenticate_reply + <gnu_srs> and exits earlier? + <youpi> it doesn't exit earlier + <youpi> it first calls auth_serveru_authenticate_reply + <youpi> and then returns with MIG_NO_REPLY + <gnu_srs> how the fck should i know that? + <youpi> by reading MIG documentation? + <youpi> I believe that _request/_reply mechanism is documented there + <gnu_srs> MIG magic again:( It strikes back, whatever you do to avoid it + <youpi> at least I don't think I have divined how it was working, so I must + have read that in some documentation + <youpi> it's not magic + <youpi> you just have to read the doc to understand how it works + <gnu_srs> I've not found any good doc on MIG yet. + <youpi> depends what you call "good" + <youpi> MIG is a complex thing, so documentation is complex, yes + <youpi> that can't really be avoided + <gnu_srs> mig.pdf + <gnu_srs> again: how can a function returning MIG_NO_REPLY return 0 when + called (as current implementations show)? + <youpi> again, by using the proper ports + <youpi> if not using the proper ports, the reply goes to another port + <youpi> and thus no reply + <youpi> and again, without showing the source code, we can't divine how you + didn't use the proper ports + <gnu_srs> so you mean a reply to a port is the same as the error code + returned? + <youpi> not always exactly, but basically yes + <youpi> gnu_srs: *again* , *really*, showing us what you've come up with + would very *most* probably allow us to help you + <youpi> otherwise it's just guess work and misunderstandings + <gnu_srs> FYI: there is no libc function calling auth_server_authenticate + directly + <youpi> sure + <youpi> that doesn't mean it can't + <gnu_srs> and here is one code example, not even trying to send+receive, it + is only in recvmsg.c: http://paste.debian.net/63374/ + <youpi> why is that code doing both auht_user_auth and auth_server_auth ? + <youpi> it's the sender side which is supposed to call auth_user_auth + <youpi> and why are you calling proc_reauthenticate, that has nothing to do + with the matter at stake + <gnu_srs> sorry, you can remove that part, same result + <youpi> ok but auth_user_authenticate should really go to the sender side + <youpi> s/should/must + <youpi> it is supposed to hang until auth_server_authenticate gets called + by the receiver + <youpi> so putting both on the receiver can not work + <youpi> at best auth_user_authenticate would hang, waiting for the + auth_server_authenticate which is called just after that... + <youpi> don't try random code, that can't work + <youpi> follow what I said + <youpi> in my mail + <gnu_srs> I did issue auth_user_authenticate on the send side, and + auth_server_authenticate on the receive side. + <gnu_srs> that was the path I followed, then when nothing worked,. I tried + the receive side only. + <youpi> that's why I said don't try random code + <youpi> it can't work with receive side only + <youpi> really, go as I said + <youpi> send / receive + <youpi> there must be something you made wrong + <gnu_srs> in the beginning it was not random code;) + <youpi> but it's not a reason for stabbing in the dark with random code, + that just can't work + <youpi> then stay with the code at the beginning + <youpi> and don't start writing random code + <youpi> that approach can *not* work + <gnu_srs> still when issuing __proc_reauthenticate followed by + auth_user_authenticate on the send side the port delivered is 0, + i.e. unusable + <youpi> why calling proc_reauthenticate?? + <youpi> it has nothing to do with the auth_*_authenticate protocol + <youpi> really + <youpi> what made you believe it was part of it? + <gnu_srs> dunno, if you say so;) + <youpi> it's not even mentioned in the documentation I referred to in my + mail + <youpi> again, make sure you actually *understand* the auth_*_authenticate + protocol + <gnu_srs> I found it in the already implemented code. + <gnu_srs> and process.defs + <youpi> for the proc_authenticate protocol, sure + <youpi> but that has nothing to do with the auth_*_authenticate protocol + <gnu_srs> well, the hurd documentation does not cover the proc case only + the io case, unfortunately:( Marcus, please write more documentation:-D + <youpi> it's just the same + <youpi> exactly the same + <youpi> ok, now I understand what happend: you followed some code which was + doing the auth protocol with the proc translator, not with the ext2fs + translator + <youpi> and you had *not* understood what proc_reauthenticate was doing + there + <youpi> you should have followed some code which was doing the auth + protocol with the ext2fs translator, i.e. through io_reauthenticate, of + course + <youpi> if you read random code, there's no way you can understand it of + coruse + <youpi> again, read hurd/setauth.c + <youpi> it does the reauthentication with ext2fs, through io_reauth to give + the ref prot + <youpi> s/prot/port + <youpi> io_reauth has to be replace with a port send over the socket of + course + <youpi> if that's obvious, don't write code, and ask yourself whether you + have really understood the auth protocol at all + <youpi> s/that's obvious/that's not obvious/ + <youpi> understand means being able to match the source code of setauth.c + with the explanation from marcus + <gnu_srs> I'm learning all the time, in a few years I will be able to + contribute seriously;-) but the MIG stuff, I dunno:( + <youpi> well, the problem is that it takes us a hell lot of time to explain + you things + <youpi> just because you don't seem to manage to learn without going + randomly + <gnu_srs> just reading source code is a random process, unfortunately. + <youpi> ?! + <youpi> sure not + <youpi> if you do it randomly, then it's not wonder you're getting random + <youpi> don't read it randomly + <youpi> follow paths + <youpi> I've never read code randomly, it's a loss of time and a way to + just mix everything together without understanding anything diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn index 95f5ab0c..70a6efee 100644 --- a/hurd/translator/discussion.mdwn +++ b/hurd/translator/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,6 +11,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation open_issue_hurd]] +[[!toc]] + # IRC, freenode, #hurd, 2011-08-25 @@ -45,3 +48,163 @@ License|/fdl]]."]]"""]] .. <braunr> but at least, thread consumption will correctly decrease with inactivity + + +# IRC, freenode, #hurd, 2014-01-30 + + <sjbalaji> can any one exmplain me hello translator ? I am new to hurd + <teythoon> sjbalaji: sure, what do you want to know ? + <teythoon> how to use it ? + <sjbalaji> No I mean what is the main reason of that translator. I am + familiar with Linux. + <gnu_srs> sjbalaji: start with: + https://www.gnu.org/software/hurd/hurd/documentation/translator_primer.html + <sjbalaji> I ran that example but I am still clueless about the actual + reason behind the translators and this simple hello world translator + example. + <teythoon> sjbalaji: the Hurd is a multiserver os, almost all functionality + lives in userspace servers called 'translators' + <teythoon> sjbalaji: the Hurd uses the file system as namespace to lookup + these servers + <teythoon> e.g. /servers/socket/1 is /hurd/pflocal and handles pipes and + unix socket communication + <sjbalaji> I can see from the example that a hello file is associated with + a /hurd/hello translator + <teythoon> yes + <teythoon> think of translators like FUSE-based filesystems, only more + general + <teythoon> b/c translators are not restricted to provide filesystem-like + services + <sjbalaji> So this example hello translator just adds hello world in the + associated file, am I correct ? + <teythoon> it's not adding stuff to a file + <teythoon> say you did settrans -ac /tmp/hi /hurd/hello, if you do cat + /tmp/hi, cat does some rpc calls to the started /hurd/hello program that + returns 'hello world' as the file contents + <teythoon> in a sense /hurd/hello is a 'filesystem' that provides a single + file + <sjbalaji> So is it like hello is the mount moint for that hello server ? + <teythoon> sjbalaji: yes, kind of that, but in a more general sense + <sjbalaji> teythoon: How can I see the different servers that are running + in the system ? I tried top in the terminal but it returned cannot find + /proc/version + <teythoon> sjbalaji: so it seems your procfs is not running, try as root: + settrans /proc /hurd/procfs -c + <sjbalaji> teythoon: But how does one differentiate between a server and a + normal process ? + <teythoon> one does not + <teythoon> for a rule of thumb: anything from /hurd is a translator + <teythoon> you can view a nodes passive translator record using showtrans, + e.g. showtrans /dev/hd0 + <sjbalaji> Is there something like a man page for translators ? Like how to + work with them or to figure out what services are offered by them ? + <teythoon> well, there is --help + <teythoon> also, go to /dev and /servers and look around using showtrans or + fsysopts + <sjbalaji> teythoon: What is the difference between a nodes active and + passive translator ? + <teythoon> a passive translator record is stored in the file system for the + node + <teythoon> if the node is accessed, and no translator is currently running, + it is started on demand + <teythoon> we call a running translator an active one + <sjbalaji> So the hello translator in the example is a passive one ? + <teythoon> if you used settrans foo /hurd/hello, a node foo is created with + an passive translator record + <teythoon> if you used settrans -a foo /hurd/hello, the translator is + started immediately + <sjbalaji> teythoon: What do you mean by a passive translator record ? + <teythoon> sjbalaji: it's an argv-vector encoded in the filesystem + (currently, only ext2 supports this) + <teythoon> in ext2, it is stored in a block and a os-specific field in the + inode points to that block + <sjbalaji> teythoon: I can't understand the logic behind that :( + <teythoon> this way, the servers are started on demand + <sjbalaji> But once they are invoked they are always online after that. + <teythoon> yes + <sjbalaji> I thought that the server goes down once its used + <gnu_srs> teythoon: shouldn't the passive ones time out if unused? + <teythoon> yes, that's how it was intented to be, but that has been + patched-out in debian/hurd + <gnu_srs> reason? + <teythoon> i don't know the details, but there is a race condition + +(`libports_stability.patch`.) + + +# IRC, freenode, #hurd, 2014-01-31 + + <sjbalaji> How can I see the complete control flow when I run the hello + translator example ? + + +# IRC, freenode, #archhurd, 2014-02-05 + + <CalimeroTeknik> plus I discussed quickly that idea with Richard Stallman + and he told me translators had a conception flaw that would forbid such a + system to be usable + + +## IRC, freenode, #archhurd, 2014-02-06 + + <antrik_> CalimeroTeknik: the "conceptal problem" rms told you about was + probably the simple issue that translators are always followed, even if + they are run by another user + <antrik> CalimeroTeknik: the conceptal problem is only in that the original + designers believed that would be safe, which it isn't. changing that + default policy (to be more like FUSE) wouldn't do much harm to the Hurd's + features, and it should be easy to do + <antrik> it's just nobody bothered so far, because it's not a big deal for + typical use cases + <antrik> rms isn't really in touch with Hurd development. he was made to + believe it was a fundamental issue by a former Hurd developer who got + carried away; and he didn't know enough to realise that it's really not a + big deal at all + + +# Candidates for Google Summer of Code [[community/gsoc/Project_Ideas]] + +## Extend `ls` et al. for Translators + +### IRC, freenode, #hurd, 2014-02-08 + + <youpi> heh + <youpi> I was wondering what that incoming/ directory was in my home + <youpi> ls gave me hundreds of packages + <youpi> then I remembered I had /hurd/httpfs http://incoming.debian.org/ on + it :) + <cluck> if only there were an easy and automated way to make ls and file + managers (like dired!) aware of links, mounts and translators :) + <youpi> cluck: what do you mean by "awaree"? + <cluck> someting like: lrwxrwxrwx 1 foo foo 31 Aug 21 18:01 + my_translator-23.0 -> ../some/fakefs /some_parameters* + <cluck> (yes, i realize it goes against some security practices but maybe + there could be a distinction like with soft/hard links that made it + opaque for some use cases) + + +## Passive Translators + +### IRC, freenode, #hurd, 2014-02-12 + + <braunr> well don't expect rsync to save passive translator records .. + <braunr> i recommend you save either the entire disk image or the partition + <gg0> should i expect it from tar/cp ? + <braunr> no + <braunr> i'm not even sure dumpe2fs does it + <braunr> the only reliable way is to save the block device + <azeem> might be a worthwhile GSOC + <azeem> "implement Hurd specific features in GNU utilities" + <azeem> there were some patches floating around for some things in the past + IIRC + <antrik> azeem: the plan for supporting Hurd features in FS utilities was + exposing them as xattrs, like Roland's Linux patch did... cascardos once + did some work on this, but don't remember how far he got + +[[community/gsoc/project_ideas/xattr]]. + + <antrik> you are right though that it would make for a good GSoC project... + <antrik> of course, *some* utilities would still benefit from explicit Hurd + support -- most notably ls + <azeem> IIRC there were also ls patches at one point + <antrik> can't recall that... but maybe it was befor my time ;-) diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index cfd09502..ba849cca 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013, 2014 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -214,6 +214,334 @@ That would be a nice improvement, but only after writeback throttling is impleme <teythoon> tschwinge: well, thanks anyway ;) +## IRC, freenode, #hurd, 2014-02-11 + + <gg0> task with pid 5 deallocating an invalid port 4622, most probably a + bug. + <gg0> ext2fs + <teythoon> yes, i've seen this + <teythoon> e.g. when a passive translator starts + <teythoon> i guess it is in libfshelp/translator-list.c + + +## Inode Sizes, Fragment and Block Sizes + +### IRC, freenode, #hurd, 2014-02-12 + + <gg0> this might be interesting and could make people not to fsck hurd + filesystem on linux: + <gg0> start ext2fs: ext2fs: device:hd0s1 + <braunr> ? + <gg0> : panic: get_hypermetadata: inode size 256 isn't supported + <gg0> (wait, also a bad typist) + <braunr> well, if the file system was created from the hurd, or with -o + hurd, as it ought to be, you wouldn't have this problem + <gg0> oh, good to know, especially before restoring :p + <braunr> i suspect your mkfs command to have created an ext4 fs + <gg0> nope mkfs.ext2 + <braunr> hm ok, so it seems to create 256 size inodes by default there + <gg0> i guess -o hurd would set some os-specific properties + <braunr> it merely enforces a few restrictions + <gg0> some predefined defaults + <braunr> fragments and blocks are 4k + <braunr> and apparently inodes are 128 bytes + <gg0> because it can't support bigger values? is it worth working on remove + such restrictions? + <braunr> probably not so far + <braunr> certainly not the fragment/block size restriction + <braunr> it matches the page size + <braunr> larger inode sizes could be supported if they're dependencies for + other worthwhile features such as those someone would add in an ext4 + translator + + +## Linux' `CONFIG_EXT4_USE_FOR_EXT23` + +### IRC, freenode, #hurd, 2014-02-12 + + <gg0> why the hell i have thousands of Inode 839, i_blocks is 248, should + be 256. Fix<y>? yes + <gg0> in all cases i_blocks should be +8 + <gg0> and /dev/sda1: (There are 245635 inodes containing multiply-claimed + blocks.) + <gnu_srs1> 10:50:08< gg0> start ext2fs: Hurd server bootstrap: + ext2fs[device:hd0s1] exec + <gnu_srs1> That's exactly where my image boot hangs! + <gg0> start ext2fs: Hurd server bootstrap: ext2fs[gunzip:device:rd0] exec + <AliciaC> gnu_srs1: you might want to check that linux isn't using the ext4 + module to handle ext2 and ext3 filesystems + <AliciaC> gnu_srs1: as I understand it the idea is that the ext4 module + treats them as ext2/ext3 filesystems, just avoiding code duplication from + having three separate modules for related filesystems, so it shouldn't + change it from ext2 at all, but it does do something strange with it + <AliciaC> but I'm not sure if that's the case or if it's converting it to + ext4. last I heard Hurd doesn't support anything beyond ext2 + <gnu_srs1> AliciaC: I did use ext2 when mounting from Linux: mount -t ext2 + /dev/loop0 /mnt + <gnu_srs1> and when not mounted: e2fsck /dev/loop0 + <AliciaC> gnu_srs1: I'd check the kernel config to be sure, + CONFIG_EXT4_USE_FOR_EXT23 must be disabled + <braunr> you can use the ext4 driver for ext2 + <braunr> that's not a problem here + <braunr> the problem happens long before, when the file system gets + corrupted + <braunr> you must understand why + <AliciaC> I have done some testing on this, mounting a Hurd ext2 filesystem + with the ext4 module broke it for me, an easily repeated issue + <AliciaC> mounting Debian's ext2 image and unmounting it with ext4 broke + it, resulting precisely in the kind of hang ups mentioned by gnu_srs1 and + gg0 + <braunr> interesting + <AliciaC> that's with a clean image with nothing corrupting it before hand, + tested to be working as well + <braunr> ok so the ext4 driver must ignore hurd specific stuff + <braunr> that's strange because i recall using it to perform small repairs + on darnassus and never had any issue + <braunr> even on the root file syste + <braunr> but my repairs were very quick and targetted + <AliciaC> different linux versions maybe + <AliciaC> when I was testing it I didn't even need to do anything in the + filesystem to trigger the issue, just mount and unmount + <gnu_srs1> I repaired filesystems before like this, has something happened + with later versions of Linux? + <gnu_srs1> One of my boxes is ext3 (probably worked before) another ext4 + (the one breaking things, but worked before) + <gnu_srs1> ext3 and ext4 box: CONFIG_EXT4_USE_FOR_EXT23=y same kernel + 3.12-1.amd64 + <gnu_srs1> what about mounting with bs=4096 (used by hurd) + <braunr> -t ext2 should work fine + <braunr> just don't use the ext4 driver if in doubt + <gg0> no difference between specifying -t or not, in both cases EXT4-fs + (sda1): mounting ext2 file system using the ext4 subsystem + <braunr> hmm + <braunr> you're screwed then ; + <braunr> ;p + <braunr> or maybe -t ext3 .. :) + <braunr> although i suspect ext4 would be used then too + <gg0> linux-image-3.2.0-4-amd64: + /lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko + <gg0> wheezy still has it. then something between 3.2.0 and 3.13(?) removed + it + <braunr> check the config file + <gg0> i mean ext2 module + <braunr> check if the config file enables it + <gnu_srs1> It's not: # CONFIG_EXT2_FS is not set + <gg0> 14:42 < gg0> wheezy still has it. then something between 3.2.0 and + 3.13(?) removed it + <braunr> how about retrying what you did without ever mounting from linux ? + <braunr> gg0: it wasn't clear enough that you meant removed from + configuration + <braunr> (for example, it could have been blacklisted) + <gg0> or present not as a module + <braunr> maybe yes, although it's unusual to see generic kernels embedding + file systems these days + <AliciaC> the CONFIG_EXT4_USE_FOR_EXT23 option isn't available if either + ext2 or ext3 are enabled though, even just as loadable modules + <gnu_srs1> The ext2 and ext3 modules were there in 3.10-3, not in 3.12-1 + <gnu_srs1> (14:48:59) <srs>: It's not: # CONFIG_EXT2_FS is not set -- + 3.12-1 + <gg0> https://bugs.debian.org/731072 + * gg0 rsync'ing back to new fs with 3.10 kernel + <gnu_srs1> seems like this bug was archived without being closed?? + <gg0> someone should produce a testcase and file another one btw + <gnu_srs1> but that bug was for files systems up to 4MB, not 4GB? + <gg0> i pasted it just because submitter talks about config option in + question and when was enabled + <gg0> don't we want to thank AliciaC who pointed it out and who could + precisely file a bug? :) + <gg0> filed http://bugs.debian.org/738758 + <braunr> gg0: thanks + <braunr> AliciaC: and thanks too + + +### IRC, freenode, #hurd, 2014-02-13 + + <gnu_srs> gg0: Did you create and test with an ext2 Linux image too on + 3.10/3.12? + <gnu_srs> here is a diff: http://paste.debian.net/81837/ + <gnu_srs> visible differences: Filesystem features:filetype (linux only) + and Free inodes:1268(hurd) / 1269(linux) + <AliciaC> between one created with -o Hurd and one created with -o Linux + (or no -o)? + <gnu_srs> AliciaC: -o Hurd and -b 4096 (no -o) + <AliciaC> I wonder if that would show any interesting difference between an + untouched -o Hurd ext2 image and a copy of it that has been mounted with + the ext4 module + <gnu_srs> AliciaC: here: http://paste.debian.net/81857/ + <gnu_srs> there is a difference of one in the number of free inodes! + <gnu_srs> cf the number of free inodes for linux + <AliciaC> gnu_srs: thanks :) though I don't know what to make of that, I + guess just adding an inode shouldn't break anything + <AliciaC> wait, no, removing an inode? + <AliciaC> bleh, too tired, read it wrong + <gnu_srs> this line should read:(11:37:48) srs: visible differences: + Filesystem features:filetype (linux only) and Free inodes:1268(linux) / + 1269(hurd) + <gnu_srs> There are differences in ext2.h and ext4.h in the Linux source + code wrt hurd1, hurd2 structs. + <gnu_srs> one change might be interesting: http://paste.debian.net/81864/ + <braunr> gnu_srs: probably not + <gnu_srs> If not, where to look? + <braunr> well, the first thing would be to create a (small) ext2 file + system, usable on the hurd, with a few files and directories + <braunr> save it + <braunr> mount it with the ext4 driver + <braunr> and make a binary comparison + <braunr> you could use a modified ext2fs translator to tell you exactly + what's wrong when loading the file system + <braunr> and then look at the corresponding code in the ext4 driver + <gnu_srs1> braunr: here is a binary diff of the unmounted and mounted e2fs + files: http://paste.debian.net/81896/ + <braunr> gnu_srs1: i'm not going to analyze it + <braunr> you are + <braunr> :p + <gnu_srs1> many of them can be removed: e.g. /mnt and bug000 + <braunr> ? + <gnu_srs1> many diff entries* + <braunr> but why ? + <braunr> you shouldn't have changed the content at all + <gnu_srs1> If I don't add a file, the fs is not corrupted + <gnu_srs1> this is with two vers small files created as in gg0s bug report + <gnu_srs1> very* + <braunr> ok + <braunr> i guess checking the source code first and the binary diffs next + is easier + <gnu_srs1> OK, I have to find out how the ext2fs files are organized. + <gnu_srs1> I.e. reading mke2fs source code + <braunr> no + <braunr> read the ext4 driver + <braunr> how a directory entry is created + <braunr> how a directory is saved back on the block device + <braunr> how any potential conversion could be triggered + <gnu_srs1> k, will do + <braunr> read about the ext2fs format if doing that first doesn't help + <braunr> learning a file system is complicated and long + <gnu_srs1> What is the inode size for Hurd/Linux? + <braunr> probably 128 + <gnu_srs1> same for both? + <braunr> what is "Hurd/Linux" ? + <gnu_srs1> on Hurd / on Linux + <braunr> 128 on hurd, variable on linux + <braunr> 128-512 i'd say + <gnu_srs1> ext2 on linux + <gnu_srs1> found it from dumpe2fs: 128 for both + <braunr> no, it can vary on linux + <braunr> although once a file system is built, the inode size cannot be + changed + <gnu_srs1> k, the file created with mke2fs has 128 + + +## `ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion 'block' failed.` + +### IRC, freenode, #hurd, 2014-02-19 + + <pere> "ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion + 'block' failed." in the console. + +[[user/Maksym_Planeta]] also has hit that one. + + <braunr> wow oO + <braunr> using debian hurd right ? + <pere> power cycling. + <pere> yes. + <braunr> with hurd 1:0.5.git20140203-1 and glibc 2.17-98~1 ? + <pere> braunr: not sure how to check. + <braunr> pere: dpkg -l | grep .. i suppose + <pere> gah, autofsck do not work.. :( + <braunr> it does :( + <braunr> unstable is easy to mess it seems + <pere> had to run fsck -y / manually... + <braunr> i suspect you were using a corrupted file system at mount time + <braunr> ah that + <braunr> yes it is sometimes needed + <braunr> but ext2 is reliable enough that only temporary files get their + way into lost+found + <braunr> temporary/recently created + <braunr> the crash you had, on the other hand, looks more serious + <braunr> it seems like you mounted a corrupted file system + <pere> could be. + <pere> hurd v1:0.5.git20140203-1 and libc0.3 v2.17-98~1, it seem. + <braunr> good + <braunr> you shouldn't have such problems then, i suspect a mess up on your + part + <braunr> but you're not the only one to have had weird file systems + problems lately + <pere> hah. I blame the hurd. :P + <braunr> heh :) + <pere> gah, another crash. :( + <braunr> Oo + <braunr> same assertion ? + <pere> same place, or almost the same place. + <pere> yes. + <braunr> hm + <pere> same crash. :( + <braunr> what kind of machine do you run the hurd on ? + <pere> kvm + <braunr> how much memory ? + <pere> 1G + <braunr> did you see if the system was swapping ? + <pere> no idea. + <braunr> i suggest always running top/htop on the hurd ;p + <braunr> and monitor memory usage closely + <gg0> unless pere lately mounted/fsck'ed fs in question with a recent linux + kernel, there should not be particular problems + <braunr> it definitely doesn't look like it was mounted by an ext4 driver, + no + <braunr> which means it's something else entirely and this is scary + <pere> I didn't. I fetched the prebuild image, upgraded it, switched it to + sysvinit and started working. + <braunr> sorry i can't be of more help about that + <braunr> ext2fs has been quite solid on my machines for a long time :( + <braunr> there are known assertions that trigger under some special + pressure, but that's not what you're having here + <braunr> pere: anything particular in fstab ? + <pere> nope, have not touched /etc/fstab. + <braunr> hm stupid question + <braunr> are you sure it's not full ? + <pere> nothing look full to me. + <pere> neither the disk nor the host file system. + + +### IRC, freenode, #hurd, 2014-02-20 + + <pere> braunr: do you remember my ext2fs crash from yesterday? I could + avoid it by interrupting the triggering build and running sync once in a + while. and it show up again if I do not sync in between. :) + <braunr> ? + <braunr> are you sure you're not swapping ? + <pere> I have no idea. still. :) + <braunr> again, i recommend you run top/htop and monitor that + <braunr> pere: is your patch needed to trigger the assertion ? + +[[open_issues/ti-rpc_then_nfs]]. + + <pere> braunr: well, without it, the package do not build, so yeah. :) + <braunr> ok + <pere> tested again, and is not swapping. 850MB free memory. + <braunr> ok + <braunr> so this might be a real file system bug + <braunr> let me see + <braunr> pere: libtirpc built fine here .. + <braunr> pere: do you have a separate /home partition ? + <braunr> or any separate file system for builds + <pere> braunr: nope, everything on / + <braunr> pere: i wouldn't recommend that + <braunr> there very probably are bugs in the file system code and using + separate partitions is a way to alleviate them + + +## `ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: Assertion `!diskfs_readonly' failed.` + +### IRC, freenode, #hurd, 2014-02-22 + + <gg0> login: init: notifying pfinet of shutdown...init: notifying tmpfs + none of shutdown...init: notifying tmpfs none of shutdown...init: + notifyi. + <gg0> ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: + Assertion `!diskfs_readonly' failed. + <gg0> In tight loop: hit ctl-alt-del to reboot + + # Documentation * <http://e2fsprogs.sourceforge.net/ext2.html> diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index 973fb938..ef5e8cbd 100644 --- a/hurd/translator/mtab/discussion.mdwn +++ b/hurd/translator/mtab/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2008, 2009, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -18,7 +18,7 @@ mounted file systems. This also means that commands like `df` can only work on explicitly specified mountpoints, instead of displaying the usual listing. One possible solution to this would be for the translator startup mechanism to -update the `mtab` on any `mount`/`unmount`, like in traditional systems. +update the `mtab` on any `mount`/`umount`, like in traditional systems. However, there are some problems with this approach. Most notably: what to do with passive translators, i.e., translators that are not presently running, but set up to be started automatically whenever the node is accessed? Probably @@ -1110,6 +1110,12 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. e.g. http://darnassus.sceen.net/gitweb/?p=teythoon/hurd.git;a=shortlog;h=refs/heads/feature-mtab-translator-v3-wip +### IRC, freenode, #hurd, 2013-11-20 + + <braunr> teythoon: ah thanks for making mtab multithreaded :) + <braunr> i forgot about that + + ## [[open_issues/libnetfs_passive_translators]] @@ -2587,6 +2593,548 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <teythoon> yes +### IRC, freenode, #hurd, 2013-11-06 + + <braunr> by the way, did you fix mtab for passive translators ? + <braunr> or make any progress ? + <teythoon> I just cleaned up the patch series + <braunr> ah good + <teythoon> I'm still trying to decide whether I leak any ports + + +### IRC, freenode, #hurd, 2013-11-15 + + <teythoon> btw, I haven't forgotten about the passive translator not + showing up in /proc/mounts + <teythoon> I have a patch series, the first patch seems fine, but if I + build hurd packages with the other two (those that actually hook into + dir-lookup), strange things happen + <teythoon> on the first boot, everything is fine, passive translators + showing up in /proc/mounts, nice + <teythoon> but when I reboot, the system kind-of comes back, but something + is very wrong with many (passive?) translators + <teythoon> the system never recovers, I have no idea whats going on there + <braunr> ok + <braunr> push that work in a branch somewhere for review please + <teythoon> right, thanks + <teythoon> braunr: + http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators + + +### IRC, freenode, #hurd, 2014-01-04 + + <youpi> teythoon: did you eventually get any idea about why /proc/mounts is + missing mounts? + <youpi> e.g. I have /boot as a separate partition, it doesn't show up + + +### IRC, freenode, #hurd, 2014-01-05 + + <teythoon> youpi: yes, passive translators are not currently handled + <teythoon> youpi: i have patches for that, but they produce weird results, + braunr promised to take a look + <braunr> teythoon: hum + <teythoon> ^^ + <braunr> i thought they were pending review + <braunr> ! + <braunr> where are they again ? + <teythoon> + http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators + <braunr> ok + <teythoon> they are reasonably straight-forward + <teythoon> but cause this funny issue, after the first reboot with the + patched hurd everything is fine + <teythoon> after the second reboot, everything is weird and broken badly + <braunr> right + <braunr> interesting :) + + +### IRC, freenode, #hurd, 2014-01-06 + + <braunr> teythoon: is it normal that, if ext2fs is started as an active + translator for /home, and then for another directory inside my home, mtab + only reports / and /home and not this third file system ? + <braunr> (with the hurd master version) + <braunr> (the translator for /home is run by root, but the one inside my + home is started with my uid) + <braunr> (and every component on the path is readable/crossable) + + +### IRC, freenode, #hurd, 2014-01-07 + + <teythoon_> braunr: well yes, the mtab tool/translator does not follow + translators bound to nodes not owned by root + <teythoon> braunr: try /hurd/mtab --insecure /home + <braunr> ok + <braunr> good thinking + + <teythoon> braunr: did you encounter any problems after the second reboot ? + <braunr> i'm not yet there + <braunr> work still making me busy + <braunr> and i'm trying to isolate the problem first + <braunr> that is, restrict tests to a single leaf translator + <teythoon> you reproduced the weirdness ? + <braunr> teythoon: attempting + <braunr> teythoon: first i'm trying to check a few things + <braunr> teythoon: i'm running my leaf translator as root now + <braunr> active + <braunr> and i still don't see it :/ + <braunr> one of the components in the path is not own by root + <braunr> is that a problem ? + <teythoon> no, but maybe the mtab translator should check for that... + <braunr> does it check for the node ownership or the process rights ? + <braunr> credentials, rather + <teythoon> node ownership + <braunr> ah, ok + <braunr> ok i see it now + <braunr> oh, also, it looks like settrans -g on an active translator + doesn't work, i get ebusy all the time :/ + <teythoon> oh ? + <teythoon> that could explain the fs corruption i saw + <teythoon> did i break that ? + <braunr> i don't know + <braunr> maybe + <braunr> i think it was possible in the past + + <braunr> teythoon: when isolated, your code works fine + <braunr> i'll try applying it globally + <braunr> btw, how did you do that ? + <braunr> through debian packages ? + <teythoon> i'm trying to get to the point, but i'm still not there + <teythoon> with our uber-buildbot setup i picture myself pushing to a git + repo, wait a little and get the packages from my deb repo... + <teythoon> for now, i have my hurdtest tool that i used during gsoc + <teythoon> with that i can just drop files into a directory and have that + overlayed ontop of my test image + <braunr> hum + <braunr> so you replaced the lib*fs libraries directly ? + <braunr> and the static rootfs ? + <teythoon> yes + * teythoon checks + <teythoon> hm, maybe i just missed a file, not sure anymore + + <braunr> teythoon: with the new libraries, df -h doesn't see passive + translators :/ + <teythoon> braunr: see /proc/mounts please + <braunr> same + <teythoon> or /hurd/mtab / + <teythoon> weird + <braunr> no :/ + <teythoon> b/c when i developed it, i used a test suite to check that every + combination of tmpfs/ext2fs active/passive and every way to get rid of + any translator produced the desired results + <teythoon> i'll look into this + <braunr> teythoon: when i remove the active translator i set on /home, i + get + <braunr> /dev/hd0s1 8.1G 2.0G 5.8G 26% /home + <braunr> hd0s1 being used for / :/ + <braunr> this does need reviewing + <teythoon> this is how i expect the system to react currently + <braunr> oh + <teythoon> w/o these patches + <braunr> hm ok + <braunr> well + <braunr> i'm currently using them + <teythoon> including the root fs ? + <braunr> yes + <teythoon> hmpf + <braunr> i have to mention that i merged master into it + <teythoon> i did the same + <teythoon> currently compiling... + <braunr> i only changed libdiskfs, libnetfs and libfshelp + <braunr> is there something else that should be changed ? + <braunr> (i.e. because of inlining ?) + <braunr> i guess i should rebuild a hurd package just to be sure + <kilobug> braunr: isn't the translator for / statically linked ? if so it + needs to be rebuilt (sorry if I'm saying silly things by popping out of + nowhere) + <braunr> yes i took care of that + + <braunr> teythoon: i've built a hurd package with the three patches and i + don't see passive translators at all + <teythoon> :/ + <braunr> well + <braunr> actually i see a lot of the + <braunr> them + <braunr> just not /home + + <teythoon> braunr: please see + /home/teythoon/build/hurd-upstream/test.{bash,log} + <teythoon> the latter is a log i just created on darnassus + <teythoon> it shows no failures + <teythoon> do you have another translator that is started from a passive + translator record ? + <teythoon> besides /home, if so, does that show up ? + <braunr> well, as i just said, i can actually see many of them + <teythoon> weird + <braunr> http://darnassus.sceen.net/~rbraun/mounts + <braunr> hm + <braunr> let's try without --sync= + <braunr> ah, now i can see it + <teythoon> can you give me the command line you used before + <teythoon> for the /home translator + <braunr> /hurd/ext2fs --sync=30 /dev/hd0s6 + <braunr> but hm + <braunr> i can only see /home when the passive translator is started + <braunr> is that intentional ? + <teythoon> yes + <braunr> ok + <teythoon> and it doesn't work with --sync=30 o_O + <braunr> so, actually, mtab doesn't report passive translators + <teythoon> no + <braunr> it reports active ones only, whether they're started manually or + from passive translators + <teythoon> yes + <braunr> ok + <braunr> that's good enough + <braunr> reporting passive translators wouldprobably require a complete + scan + <teythoon> yes, that was deemed not feasible + <braunr> right + <braunr> i can't reproduce any weirdness + <teythoon> good + <braunr> it seems to just work well + <braunr> except this option parsing problem + <teythoon> thanks for looking into this + <teythoon> yeah + <braunr> sur + <braunr> e + <braunr> thanks for reminding me :) + <teythoon> the actual fix is implementing fsys_get_source + <braunr> i forgot that "pending review" was my review here he + <teythoon> which should actually be file_get_source + + <braunr> teythoon: why does mtab report errors for /proc/swaps and + /xconsole ? + <teythoon> not sure + + <teythoon> btw, i build hurd packages with my patches and it reliably + wreaks havoc on my test vms ... + <braunr> now that's really weird + <braunr> are you certain everything has been cleaned since your manual + replacement of the libraries ? + <teythoon> yes, i use mainly throwaway-vms for such experiments + <braunr> ok + <teythoon> did you include the debian patches ? + <braunr> yes + <teythoon> so did i + <braunr> i based my work on my own packages + <braunr> with thread destruction + <braunr> i'll redo it from the sid ones + <braunr> but before, i guess i should share mine with you + <braunr> so you can test them in your vms + <braunr> we may simply have different configurations + <teythoon> yes + <braunr> something we might have missed just like the --sync parameter + + +### IRC, freenode, #hurd, 2014-01-08 + + <braunr> teythoon: hello + <braunr> see http://darnassus.sceen.net/~rbraun/teythoon/ for the custom + hurd packages + <braunr> they need thread destruction so get the latest gnumach package + from unstable, and the libc packages from my repository first + + +### IRC, freenode, #hurd, 2014-01-09 + + <teythoon> braunr: your packages indeed seem to work + <teythoon> and with mine i encounter a different problem, the proc server + crashes *very* early + <teythoon> this is w/o a rebuilt libc + <teythoon> different as in not the weird one i remember having back when i + wrote those patches + <braunr> hum + <braunr> you're using all my glibc/hurd packages right ? + <teythoon> your packages work fine + <braunr> i wonder if your bug is caused by + 2c9422595f41635e2f4f7ef1afb7eece9001feae + <teythoon> mine don't + <braunr> (or rather, not having it) + <braunr> look at the patches i've added + <braunr> it's included, and i remember i really needed it + <braunr> althouhg it was just about a leak + <braunr> hm + <braunr> i don't know :/ + <braunr> but i strongly suspect your patches are ok + <braunr> and something else is wrong + <teythoon> why would my packages miss that patch ? + <braunr> hum + <braunr> are you testing with your packages built from upstream sources ? + <teythoon> always + <braunr> upstream hurd against debian glibc ? + <teythoon> yes + <braunr> check the patches again + <teythoon> what patches ? + <braunr> the debian ones that you don't include + <braunr> another thing you can do is + <teythoon> err + <braunr> get the latest debian hurd package + <braunr> add your patch only + <braunr> rebuild + <teythoon> i use hurd upstream + all the debian stuff + <braunr> that's weird + <braunr> but hurd upstream has received quite a lot of patches + <braunr> please try from debian hurd + your patch only + + <teythoon> braunr: i'm afraid it might be your patch 3a3fcc81 that breaks + proc + +[[libpthread_set_stack_size]]. + + <braunr> teythoon: but anyway, it does look like your patches are actually + fine + <teythoon> yes + <braunr> i'll install my packages on darnassus and test a bit more + <teythoon> there is an issue however + <braunr> ah + <teythoon> grep sd2s1 /proc/mounts + <teythoon> /dev/sd2s1 /dev/sd2s1 /hurd/storeio writable 0 0 + <teythoon> that makes fsck think that /dev/sd2s1 is mounted + <braunr> hmpf + <teythoon> which makes debians fsck magic (when using sysvinit) drop to a + root shell at boot time + <braunr> why does it report a mount point ? + <braunr> or even a device + <braunr> why not none /dev/sd2s1 ? + <teythoon> b/c of the heuristic it uses + <teythoon> and i know, you told me it's a bad idea + <braunr> i did ? + <teythoon> probably + <braunr> hm + <braunr> we said so many things i don't remember + <braunr> but that doesn't look too hard to fix + <teythoon> well, i'll just have to make translators provide meaningful + get_source responses + <teythoon> and get rid of the heuristic + <braunr> ok + <teythoon> so if you use passive translators for the mounts, and not + /etc/fstab, you should be fine + <teythoon> my "traditional" hurd systems are + <braunr> teythoon: i'll wait a bit before deplying it on darnassus then + + +### IRC, freenode, #hurd, 2014-01-13 + + <braunr> teythoon: does your latest patch series take care of --sync ? + <teythoon> yeah, i finally got why the hurd would react strangely after an + reboot, it was umount --all removing vital passive translator records + <teythoon> i never had any issues with --sync + <braunr> ah, umount -a + <braunr> hm + <braunr> do you recall i did :) ? + <teythoon> umount -a was only run with the sysvinit scripts, that's why you + didn't see that issue, only me + <teythoon> yes, i do + <braunr> yes, i see + <teythoon> however, i'm also using --sync 30 on my fs + <braunr> ok so you couldn't reproduce that particular issue + <braunr> hum + <braunr> try --sync=30 + <teythoon> showtrans /media/scratch + <teythoon> /hurd/ext2fs --sync=30 /dev/sd1s1 + <teythoon> works fine + <braunr> now that's weird :) + <teythoon> then again, previously there was another bug + <braunr> but then the patches i've tested are not the complete series you + sent + <teythoon> in the dir lookup function, if a passive translator is started + <teythoon> say, if i first access /proc/foo, /proc/foo would be recorded, + not /proc + <teythoon> i fixed that yesterday + <braunr> ok + <teythoon> maybe it was b/c of that + <braunr> but hm + <braunr> why would /proc be recorded ? + <teythoon> now ? + <braunr> i mean, /proc should be recorded at /, and /foo at /proc + <braunr> right ? + <teythoon> yes + <braunr> and that wasn't the case ? + <teythoon> but what happened was that proc/foo was recorded as a child + translator for / + <braunr> ohh + <teythoon> yes + <braunr> i see + <braunr> well, i'm not sure it's that bug, since the translator involved + was on /home + <teythoon> same problem + <teythoon> it's unlikely that the translator was started b/c of a /home + lookup + <teythoon> much more likely that the first lookup is /home/someone + <braunr> yes + <braunr> but mtab correctly reported /home without --sync, and not when the + option was present + <braunr> and that part doesn't quite make sense to me + <teythoon> how did you trigger the startup + <teythoon> ? + <braunr> ssh i believe + <teythoon> hm + <teythoon> anyways, i could not reproduce this issue + <braunr> do you have packages somewhere i can test ? + <teythoon> yes + <braunr> oh and btw + <teythoon> http://darnassus.sceen.net/~teythoon/hurd-ci/ + <braunr> something you could do to deal with umount -a + <braunr> but i guess that's what you did already + <braunr> is to only shut the active translator down + <teythoon> + http://git.sceen.net/hurd/hurd.git/commitdiff/0033d20449b3bb558f2ea470983018db39b572aa + <teythoon> yeah, i thought about that + <teythoon> but i believe that is not the right hting to do + <braunr> yes i know but i'm not sure that's the right approach + <braunr> hm :) + <teythoon> b/c if on linux you do umount /foo && ls /foo, foo will be empty + <braunr> yours is probably more posix-friendly + <teythoon> if the passive translator lookup is left, /foo will be restarted + <braunr> ok + <teythoon> s/lookup/record/ + <braunr> that's one reason i'm not very fond of passive translators tbh + <teythoon> yep + <braunr> i'd reserve them as a user-oriented hurd-specific feature + <braunr> anything that must behave as mount/umount expects has to be active + anyway + <braunr> ok let's give a quick shot at your packages :) + + <braunr> teythoon: works fine :) + <braunr> mtab still reports console entries though + <braunr> is tha texpected ? + <teythoon> braunr: kind of + <teythoon> braunr: /bin/console is a netfs-based translator, probably for + multiplexing, dunno exactly + <braunr> i see + + +### IRC, freenode, #hurd, 2014-01-14 + + <youpi> teythoon: passive translators do work fine in mtab now, thanks :) + <braunr> indeed :) + + +### IRC, freenode, #hurd, 2014-02-11 + + <antrik> another topic: what's the rationale again behind umount removing + passive translators?... + <teythoon> antrik: umount is for compatibility with unixoid systems + <teythoon> consider umount /foo; ls /foo + <teythoon> if umount would leave the passive translator record on /foo, + /foo would be started again + <antrik> but mount never creates passive translators, right? + <antrik> so why would umount remove them? they are none of its business... + <teythoon> sure, you can see it this way + <teythoon> still, i like the way it is now, hence i implemented it this way + ;) + <youpi> teythoon: but then umount -a unmounts all passive translators + <youpi> include ~joe/http:/ + <youpi> s/include/including/ + <youpi> I tend to agree with antrik + <teythoon> i won't oppose a change of course + <teythoon> and yes, we have seen problems b/c of that. otoh those can be + fixed (and they are, i just sent a patch fixing that) + <youpi> teythoon: well, it's not only about http:, joe user may want to + mount its own iso image, or whatever + <teythoon> thats true + <teythoon> no + <teythoon> it's not + <teythoon> /proc/mounts does not contain translators bound to nodes that do + not belong to root + <teythoon> but sure, we can change umount + <braunr> i agree + <braunr> active translators can be viewed as unix mounts + <braunr> passive translators are an entirely hurdish feature + <braunr> but then, servers such as pflocal and pfinet shouldn't probably + not be passive translators + <antrik> braunr: shouldn't not? what are you trying to say? :-) + <braunr> woops + <braunr> i'm not trying to make this unconfusingly clearer + <braunr> :p + <braunr> pflocal and pfinet should probably be active translators + <antrik> why? + <braunr> hum wait + <braunr> i had a reason weeks ago + <braunr> but now it looks the opposite is better actually :p + <braunr> so that they don't appear in mounts + <braunr> but aiui, there is another property that is tested to make + translators appear in mounts + <antrik> hm... I know this question has been discussed when first talking + about an mtab translator years ago... but don't remember whether there + was any conclusion + <antrik> I think one of the ideas was that translators would opt in for + being considered as mounts... + <braunr> it makes sense to only have file systems in mounts anyway + <antrik> instead of going by the translator type, another option might be + ignoring anything that is backed by a passive translator?... + <antrik> or have a startup option (perhaps with some "smart" defaults) to + request a translator to manifest as a mount or not + <antrik> so many ideas... ;-) + + +## coreutils' `df` + +### IRC, freenode, #hurd, 2014-01-24 + + <braunr> gnu_srs: "df: Warning: cannot read table of mounted file systems: + No such file or directory" + <braunr> you should be able to fix that easily + + +### IRC, OFTC, #debian-hurd, 2014-02-03 + + <pere> /run/mtab also seem to be missing. df do not work. + <teythoon> that's a libc bug + + +### IRC, OFTC, #debian-hurd, 2014-02-05 + + <gg0> i had to ln -s /proc/mounts /var/run/mtab to make df work, what's the + proper fix? + <gg0> (here sysvinit+openrc) + <youpi> gg0: the proper fix for df is to fix the coreutils build + + <pere> I checked the mtab problem, and /etc/hurd/runsystem.gnu via + /etc/hurd/rc fixes the symlink, while runsystem.sysv do not. I suspect + /etc/init.d/checkroot.sh should fix the symlink too. + <youpi> well, atm df looks at /var/run/mtab instead of /etc/mtab only + because it hasn't been rebuilt against a recent glibc, that's all + <youpi> but we can brownpaperbag fix it, yes + <pere> right. so perhaps that is the bug to fix? + <youpi> yes, it is + <youpi> it depends on coreutils actually building + <teythoon> youpi: i thought the proper way to fix the /var/run/mtab issue + is to patch the libc ? + <youpi> it is + <teythoon> the libc defines some macro, on linux it expands to /etc/mtab, + on hurd to /var/run/mtab + <youpi> but you need to rebuild coreutils to get a fixed df + <teythoon> ok, right + <pere> should it be /var/run/mtab or /etc/mtab on hurd? the former seem + more correct, but /run/mtab give more sense given that it should be + available also before /var/ is mounted. + <youpi> to be honest, I don't really care + <youpi> and I thus tend to agree on sticking with what linux does + <youpi> to avoid issues + <youpi> as in: keep debian working mostly the same on all kernels, to avoid + issue + <youpi> s + <pere> well, linux really should move that file away from /etc/ too. :) + <youpi> pere: ok, but let's move at the same time + <youpi> rather than hitting bugs ourselves + <pere> perhaps df should use /proc/mount instead, and get rid of the + problem completely... + <youpi> that can be a way, too + + <pere> I believe <URL: http://bugs.debian.org/737759 > is a good fix for + the mtab problem. + + <rleigh> WRT /etc/mtab the main reason for keeping it is solely for + compatibility; there's no reason not to use /proc/mounts directly (or + /run/mtab if we want a kernel-agnostic location). Whether it's worth + doing something like that is debatable. + <rleigh> The main issue with doing stuff like this nowadays is that you get + shouted at by all the systemd people for making changes... + + ## Memory Leak in `translator_ihash_cleanup` ### IRC, freenode, #hurd, 2013-10-04 diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn index 3e66c870..7b2f07aa 100644 --- a/hurd/translator/pfinet/implementation.mdwn +++ b/hurd/translator/pfinet/implementation.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2000, 2008, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2000, 2008, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -166,6 +166,14 @@ In context of the item on [[/contributing]]. <braunr> rekado: development pace on the hurd has always been slow, no need to apologize + +### IRC, freenode, #hurd, 2014-02-12 + + <braunr> youpi: btw, the patch you finally decided to write yourself making + pfinet continue on driver failure is as expected quite handy :) + <youpi> :) + + ## MAC Addresses [[!tag open_issue_hurd]] @@ -192,6 +200,82 @@ In context of the item on [[/contributing]]. <youpi> it's not plugged inside pfinet anyway +## IRC, freenode, #hurd, 2014-01-15 + + <braunr> 2014-01-14 23:06:38 IPv4 socket creation failed: Computer bought + the farm + <braunr> :O + <youpi> hum :) + <youpi> perhaps related with your change for "lo" performance? + <braunr> unlikely + <youpi> I don't see what would have changed in pfinet otherwise + <braunr> mig generated code if i'm right + <braunr> lib*fs + <braunr> libfshelp + <braunr> looks plenty enough + <braunr> teythoon's output has been quite high, it's not so suprising to + spot such integration issues + + +### IRC, freenode, #hurd, 2014-01-16 + + <braunr> teythoon: so, did you see we have bugs on the latest hurd packages + :) + <braunr> for some reason, exim4 starts nicely on darnassus, but not on + another test vm + <braunr> and there is a "deallocate invalid name" error at boot time + <braunr> it's also present with your packages + <teythoon> yes + + <braunr> not being able to start exim4 and other servers on some machines, + apparently randomly, is a bit frightening to me + <braunr> as the message says, "most probably a bug" + <teythoon> yes + <braunr> so we have to get rid of it as soon as possible so we can get to + the more interesting stuff + <teythoon> but there is no way to attribute this message to a process + <braunr> well, for those at boot time, there is + <teythoon> ? + <braunr> if i disable exim, i don't get it :p + <teythoon> oh ? + <braunr> but again, it doesn't occur on all machines + <braunr> and that part is the one i don't like at all + <teythoon> still, is it in exim, pfinet, pflocal, ... ? + <teythoon> no way to answer that + <braunr> ah right sorry + <braunr> it's probably pfinet, since exim says computer bought the farm on + a socket + <braunr> pflocal had its same pid + <teythoon> ok + <braunr> and after an upgrade, i don't reproduce that + <braunr> good, in a way + <braunr> there still is the one, after auth + <teythoon> yes + <teythoon> i'm seeing that too + <braunr> (as in "exec init proc auth" + <braunr> shouldn't be too hard to fix + <braunr> i'll settle on this one after i'm done with libps + <gnu_srs> (15:21:34) braunr: it's probably pfinet, since exim says computer + bought the farm on a socket: + <gnu_srs> remember my having problems with removing a socket file, maybe + related, probably not pfinet then? + <braunr> gnu_srs: unlikely + <braunr> that pfinet bug may have been completely transient + <braunr> fixed by upgrading packages + <gnu_srs> braunr: k! + + <braunr> and exim4 keeps crashing on my hurd instance at home + <braunr> (pfinet actually) + <braunr> uh, ok, a stupid typo .. + <braunr> teythoon: --natmask in the /servers/socket/2 node, but correct + options in the 26 one .... :) + + +### IRC, freenode, #hurd, 2014-01-17 + + <teythoon> braunr: *phew* + + # Reimplementation, [[!GNU_Savannah_task 5469]] ## [[community/gsoc/project_ideas/tcp_ip_stack]] @@ -205,6 +289,10 @@ In context of the item on [[/contributing]]. <braunr> hm, why not <braunr> i would still prefer using code from netbsd <braunr> especially now with the rump kernel project making it even easier + +[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel +and Rump Kernels*. + <youpi> well, whatever is easy to maintain up to date actually <braunr> netbsd's focus on general portability normally makes it easy to maintain @@ -225,3 +313,93 @@ In context of the item on [[/contributing]]. Cloudius OSv apparently have isolated/re-used a BSD networking stack, <http://www.osv.io/>, <https://github.com/cloudius-systems/osv>. + + +## IRC, freenode, #hurd, 2014-02-06 + + <akshay1994> Hello Everyone! Just set up my Hurd system. I need some help + now, in selecting a project on which i can work, and delving further into + this. + <braunr> akshay1994: what are you interested in ? + <akshay1994> I was going through the project ideas. Found TCP/IP Stack, and + CD Audio grabbing interesting. + <braunr> cd audio grabbing ? + <braunr> hm why not + <braunr> akshay1994: you have to understand that, when it come to drivers, + we prefer reusing existing implementations in contained servers than + rewriting ourselves + <braunr> the networking stack project would be very interesting, yes + <akshay1994> Yes. I was indeed reading about the network stack. + <akshay1994> So we need an easily modularise-able userspace stack, which we + can run as a server for now. + <akshay1994> And split into different protocol layers later. + <braunr> hum no + <braunr> we probably want to stick to the model we're currently using with + pfinet + <braunr> for network drivers, yes + <braunr> i strongly suspect we want the whole IPv4/IPv6 networking stack in + a single server + <braunr> and writing glue code so that it works on the hurd + <braunr> then, you may want to add hooks for firewall/qos/etc... + <braunr> (although i think qos should be embedded to) + <braunr> sjbalaji: i also suggest reusing the netbsd networking stack, + since netbsd is well known for its clean portable code, and it has a + rather large user base (compared to us or other less known projects) and + is well maintained + <braunr> the rump project might make porting even easier + +[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel +and Rump Kernels*. + + <akshay1994> okay! I was reading the project idea, where they mention that + a true hurdish stack will use a set of translator processes , each + implementing a different protocol layer + <braunr> a true hurdish stack would + <braunr> i strongly doubt we'll ever have the man power to write one + <braunr> i don't really see the point either to be honest :/ + <akshay1994> haha! + <braunr> but others have better vision than me for these things so i don't + know + <akshay1994> So, what are the problems we are facing with the current + pfinet implementation? + <braunr> it's old + <braunr> meaning it doesn't implement some features that may be important, + and has a few bugs due to lack of maintenance + <braunr> maintenance here being updating the code base with a newer + version, and we don't particularly want to continue grabbing code from + linux 2.2 :) + <akshay1994> I see. I was just skimming through google, about userspace + network stacks, but I think I might need to first understand how the + current one works and interacts with the system, before proceeding + further! + <braunr> yes + <braunr> the very idea of a userspace stack itself has little implications + <braunr> it basically means it doesn't run in system mode, and instead of + directly calling functions, it uses RPCs to communicate with other parts + of the system + + <akshay1994> braunr: I looked at the netBSD net-stack, and also how hurd + (and mach) work. I'm starting with the hacking guide. Seems a little + difficult :p + <akshay1994> But i feel, I'll get over it. Any tips? + <braunr> akshay1994: it's not straightforward + <akshay1994> I know. Browsing through pfinet gave me an idea, how complex a + thing I'm trying to deal with in first try :p + + +### IRC, freenode, #hurd, 2014-02-09 + + <antrik> braunr: the point of a hurdisch network stack is the same as a + hurdish block layer, and in fact anything hurdish: you can do things like + tunelling in a natural manner, rather than needing special loopback code + and complex control interfaces + <braunr> antrik: i don't see how something like the current pfinet would + prevent that + + +# IRC, freenode, #hurd, 2013-10-31 + + <braunr> looks like there is a deadlock in pfinet + <braunr> maybe triggered or caused by my thread destruction patch + +[[open_issues/libpthread/t/fix_have_kernel_resources]]. diff --git a/hurd/translator/pflocal.mdwn b/hurd/translator/pflocal.mdwn index fdcc39f1..6cb01e18 100644 --- a/hurd/translator/pflocal.mdwn +++ b/hurd/translator/pflocal.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2000, 2008, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2000, 2008, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -33,3 +33,37 @@ implementation). (maybe not so interesting case). <pinotree> pflocal does not support it <gnu_srs> Is that of interest at all? + + +## IRC, freenode, #hurd, 2014-01-14 + + <braunr> sudo -s eats 100 cpu :/ + <braunr> possibly because of pflocal + <braunr> only change on pflocal (notwithstanding the libraries) is + "pflocal: improve the demuxer functions" + <braunr> teythoon: why did you change the order of the function calls in + sock_demuxer ? + <youpi> for efficiency iirc + <braunr> yes, looks reasonable + + +### IRC, freenode, #hurd, 2014-01-16 + + <braunr> i suspect the "improve the demuxer functions" changes may have + hard-to-understand side effects + <teythoon> yes, mostly being faster + <braunr> ah, the latest sudo has been fixed + <braunr> haha :) + <teythoon> ^^ + <braunr> that one is easy to understand :) + <braunr> sudo was looping around calls to pflocal + <braunr> and exim crashed because of pfinet + <braunr> and those servers were only affected by these changes, other than + the library ones which don't seem to apply at all + <braunr> but with sudo being fixed, i'm not sure it's relevant any more + <teythoon> i'd say being faster could easily cause hard-to-understand side + effects + <braunr> ah, yes + <braunr> being faster isn't the side effect itself ;p + <braunr> nice, sudo was bugged on linux too, its behaviour matched its hurd + version perfectly diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn index 75bfb8fd..39840e99 100644 --- a/hurd/translator/proc.mdwn +++ b/hurd/translator/proc.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -102,3 +103,68 @@ It is stated by `/hurd/init`. < braunr> teythoon: i agree with you on proc process-to-task mapping < braunr> that's something i intend to completely rework on propel < braunr> in a way similar to how pid namespaces work on linux + + +# PID "Races" + +## IRC, freenode, #hurd, 2014-01-26 + + <quotemstr> Does Hurd have anything that generally solves PID races? + <youpi> what kind of race are you thinking about? + <youpi> I'm not sure, but I guess keeping a reference to a task port will + prevent the proc server from recycling the corresponding pid + <quotemstr> Yep. + <quotemstr> How does the Hurd avoid the obvious denial-of-service attack + that results? + <youpi> well quotas would probably be enough + <youpi> that's not a new issue :) + <quotemstr> Fair enough. + <quotemstr> Returning to the POSIX-y world after a few year stint over in + NT-land, it's infuriating that it's still not possible to write a + reliable killall(1) under Linux or the BSDs. + <quotemstr> I'm glad Hurd solves the problem. :-) + <braunr> but it doesn't + <braunr> how can you write a reliable killall ? + <youpi> so keeping a reference to the task port is not enough? + <braunr> i'm not sure + <braunr> first i'd like quotemstr to clearly define the reliability problem + of killall + <quotemstr> braunr: The possibility that a PID might be used between the + time you decide to kill it and the time you actually kill it. + <braunr> well, it would have to wrap around for that + <quotemstr> braunr: So? It's possible. + <braunr> i guess that's what you refer to + <braunr> ok + <braunr> well yes, it's possible to easily create a routine that atomically + increases the number of references on a task/process when looking it up + <braunr> preventing its removal from the list of processes reported by the + proc server + <quotemstr> Like OpenProcess? :-) Would this reference count be + automatically decremented if the task owning the reference is killed? + <braunr> it would clearly not be a "posixy killall" then, but i suppose we + don't care about that at all + <braunr> no + <quotemstr> Oh. + <braunr> destroying an object doesn't remove its references + <quotemstr> So it's possible to leak the reference and prevent reuse of + that PID forever. + <braunr> hardly + <braunr> for that, killall would have to run a long time + <quotemstr> braunr: No, I'm talking about our hypothetical killall itself + being killed after taking out a reference on another process, but before + releasing it + <braunr> but a malicious killall could + <braunr> when a task is destroyed, its capability space is destroyed too + <braunr> removing all the references it previously had + <quotemstr> Ah, I see. + <braunr> the leaks we have occur in servers + <braunr> which sometimes act as clients to other servers + <braunr> and run forever + + +# Crashes due to rpctrace + +## IRC, freenode, #hurd, 2014-02-18 + + <braunr> something is wrong in the proc server + <braunr> rpctrace is often causing it to crash .. diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 018db7b2..8ac48a59 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012, 2013, 2014 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -348,6 +348,35 @@ Disadvantage is that every program using this needs to be patched. This is used in `[LLVM]/lib/Support/Unix/Path.inc`. +### IRC, OFTC, #debian-hurd, 2013-11-10 + + <mjt> Hello. Does hurd have /proc/self/exe equivalent, to "re-exec myself" + ? + <youpi> no, only argv[0] + <mjt> busybox uses /proc/self/exe by default to re-exec itself when running + one of its applets, or failing that, tries to find it in $PATH. I guess + it doesn't work on hurd... :) + <mjt> and argv0 is unreliable + <youpi> some discussion on the hurd wiki talks about using Dl_info DLInfo + <youpi> which contains DLInfo.dli_fname + <youpi> err, I mean, callling dladdr(&main, &DLInfo); + <youpi> this is kernel-agnostic, provided one uses glibc + <mjt> um. -ldl. nice for static linking + <mjt> gcc t.c -ldl -static + <mjt> ./a.out + <mjt> fname=AVA� �j + <mjt> bah :) + <mjt> (it just prints dli_fname) + <teythoon> :/ + <youpi> ah, yes, that won't work with static linking + <teythoon> fixing /proc/self is on my todo list, it shouldn't be too hard + <youpi> since in that case it's the exec server which sets the process up, + not dl.so + <teythoon> but we do not have the exe link either + <mjt> (the above test run was on linux not on hurd, fwiw_ + <mjt> ) + + # `/proc/[PID]/fd/` ## IRC, freenode, #hurd, 2012-04-24 @@ -502,6 +531,23 @@ Also used in `[GCC]/intl/relocatable.c`:`find_shared_library_fullname` for <camm`> thanks +## IRC, freenode, #hurd, 2014-02-22 + + <ignaker> i'm trying to implement proc/maps + <ignaker> actually I can't well evaluate complexity of tasks. However, I + appreciate your comments + <braunr> the complexity can be roughly estimated from the number of + components involved + <braunr> proc/maps involves procfs, ports, virtual memory, and file systems + <braunr> the naive implementation would merely be associating names to + memory objects, and why not, but a more complete one would go ask file + system servers about them + <braunr> perhaps more + <braunr> although personally i'd go for the naive one because less + dependencies usually means better reliability + <braunr> something similar to task_set_name could do the job + + # `/proc/[PID]/mem` Needed by glibc's `pldd` tool (commit diff --git a/hurd/translator/term.mdwn b/hurd/translator/term.mdwn index 667677a7..5ae52abe 100644 --- a/hurd/translator/term.mdwn +++ b/hurd/translator/term.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -190,6 +190,12 @@ The *term* translator implements POSIX termios discipline. <braunr> there, patches pushed :) +### IRC, freenode, #hurd, 2014-02-07 + + <braunr> btw, as a note, there really are leaks in terminals + <braunr> i managed to get a term server eat up to 300M of memory yesterday + + ## `screen` Logout Hang [[!tag open_issue_hurd]] diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn index 8c332d84..72400121 100644 --- a/hurd/translator/tmpfs/discussion.mdwn +++ b/hurd/translator/tmpfs/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -19,6 +19,8 @@ License|/fdl]]."]]"""]] * [[!GNU_Savannah_bug 26751]] +[[!toc]] + # [[Maksym_Planeta]] @@ -467,3 +469,35 @@ License|/fdl]]."]]"""]] privilege of their owner <braunr> privileges should be decoupled from identity <teythoon> yes + + +## IRC, freenode, #hurd, 2013-11-08 + + <teythoon> braunr: I'm investigating this port leak of mine + <teythoon> well, I thought I introduced one + <teythoon> but I'm not too sure anymore + <teythoon> the setting is this + <teythoon> i start an active tmpfs translator, bind it to foo + <teythoon> then, i create foo/bar with a passive translator entry + <teythoon> i access foo/bar, the passive translator is started + <teythoon> my test suite now covers several methods of making that + translator go away + <teythoon> killing it with 15 or 9 is fine, i.e. does not make the first + tmpfs leak ports + <teythoon> however, doing settrans -g foo/bar does for some reason + <teythoon> i think my code is fine, i spent considerable time on tracking + down this problem, always thinking that i must have introduced it + <teythoon> but another thing just cought my eye, the first tmpfs translator + says this when i do settrans -g foo/bar: + <teythoon> tmpfs/tmpfs: pthread_create: Resource temporarily unavailable + <teythoon> could it be that a no-sender notification is ignored b/c the + handler thread failed to start ? + <braunr> teythoon: i saw this pthread error too + + +# IRC, freenode, #hurd, 2014-02-09 + + <gg0> remounting tmpfs doesn't work if in use + http://paste.debian.net/plain/80937/ + <gg0> you will also get a pthread_create: Resource temporarily unavailable + <youpi> iirc the pthread_create warning happens for any kind of translator diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn index 2e205a9a..d79fa337 100644 --- a/microkernel/mach/deficiencies.mdwn +++ b/microkernel/mach/deficiencies.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 @@ -812,6 +813,10 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]]. <zacts> or both? <braunr> probably netbsd drivers <zacts> and if netbsd, will it utilize rump? + +[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel +and Rump Kernels*. + <braunr> i don't know yet <zacts> ok <braunr> device drivers and networking will arrive late @@ -2691,3 +2696,592 @@ freenode, #hurd, 2013-10-24*: <braunr> my plan for x15 is to make this "label" part of received messages <braunr> which means you need to change the format of messages <braunr> that is what i call a big change + + +### IRC, freenode, #hurd, 2013-10-31 + + <antrik> neal: you mentioned you want to use Genode as a base... what + exactly would you want to build on top of it, different than what the + Genode folks are doing? + +[[Genode]]. + + <neal> antrik: I want to build a secure operating system. + <neal> antrik: One focused on user security. + + <neal> braunr: You mean revoke individual send rights? + <neal> braunr: Or, what do you mean? + <neal> Or do you mean the ability to receive anotification on revocation? + <braunr> neal: yes, revoking individual send rights + <neal> I don't think it is needed in practice. + <braunr> neal: ok + <neal> But, you need a membrane object + <neal> Here's the idea: + <braunr> like a peropen ? + <neal> you have say a file server + <neal> and a proxy + <neal> a process only talks to the file server via the proxy + <neal> for the proxy to revoke access to the file object it gave out, it + needs to either use your revoke + <neal> interpose on all ipcs (which is expensive) + <neal> or use a proxy object/membrane + <neal> which basically forwards messages to the underlying object + <braunr> isn't that also interposing ? + <neal> of course + <neal> but if it is done in the kernel, it is fast + <braunr> ah in the kernel + <neal> you just walk a linked list + <braunr> what's the difference with a peropen object ? + <neal> That's another option + <neal> you use a peropen and then provide a call to force the per-open to + be closed + <neal> so the proxy now invokes the server + <neal> the issue here is that the proxy has to trust the server + <braunr> yes + <braunr> how can you not trust servers ? + <neal> that is, if the intent is to prevent further communication between + the server and the process, the server may ignore the request + <neal> in this case, you probably trust the server + <braunr> hum + <neal> but it could be that you have two processes communicating + <braunr> if the intent is to prevent communication, doesn't the client just + need to humm not communicate ? :) + <neal> the point is that the two processes are colluding + <braunr> what are these two processes ? + <neal> I'm not sure this case is of practical relevance + <braunr> ok + <neal> https://www.cs.cornell.edu/courses/cs513/2002sp/L10.html + <braunr> thanks + + +### IRC, freenode, #hurd, 2013-11-14 + + <antrik> neal: hm... I was under the impression that the Genode themselves + are also interested in user security... what is missing from their + version that you want to add? + <antrik> err... the Genode folks + <neal> antrik: I'm missing some context + <antrik> neal: a while back you said that you want to build a secure system + on top of Genode + <neal> yes + <neal> the fact that they are doing what I want is great + <neal> but there is more to a secure system than an operating system + <antrik> ah, so it's about applications+ + <antrik> ? + <neal> yes, that is part of it + <neal> it's also about secure messaging + <neal> and hiding "meta-data" + <braunr> i'm still wondering how you envision the powerbox + <neal> when a program wants the user to select a file, it makes an upcall + to the power box application + <antrik> braunr: you can probably find some paper from Shapiro ;-) + <braunr> well, sure, it looks easy + <braunr> but is there always a power box application ? + <braunr> is there always a guarantee there won't be recursive calls made by + that application ? + <braunr> how does it integrate with the various interfaces a system can + have ? + <neal> there is always a power box application + <neal> I don't know what you mean by recursive calls + <braunr> aer techniques such as remembering for some time like sudo does + applicable to a powerbox application ? + <neal> if you mean many calls, then it is possible to rate limit it + <braunr> well, the powerbox will use messaging itself + <braunr> is it always privileged ? + <braunr> privileged enough + <neal> it is privileged such like the X11 display manager is privileged and + can see all of the video content + <braunr> what else other than accessing a file would it be used for ? + <braunr> one case i think of is accessing the address space of another + application, in debuggers + <braunr> 14:56 < neal> there is always a power box application + <braunr> what would it be when logging on a terminal ? + <antrik> braunr: when running pure command line tools, you can already pass + the authority as part of the command line. however, I'm wondering whether + it really makes sense to apply this to traditional shell tools... + <braunr> that's one of my concerns + <braunr> when does it really make sense ? + <antrik> for interactive use (opening new files from within a running + program), I don't think it can be accomplished in a pure terminal + interaction model... + <braunr> and you say "you pass the authority" + <antrik> braunr: it makes sense for interactive applications + <braunr> i thought the point of the powerbox is precisely not to do that + <antrik> no, it's still possible and often reasonable to pass some initial + authority on startup. the powerbox is only necessary when further access + needs to be provided at runtime + <braunr> ok + <neal> the power box enable dynamic delegation of authority, as antrik said + <braunr> ok + <braunr> but how practical is it ? + <neal> applications whose required authority is known apriori and + max(required authority) is approximately min(required authority) can be + handled with static policies + <braunr> don't application sometimes need a lot of additional authority ? + <braunr> ok + <antrik> actally, thinking about it, a powerbox should also be possible on + a simple terminal, if we make sure the application doesn't get full + control of the terminal, but rather allow the powerbox to temporarily + take over input/output without the application being able to + interpose... so not quite a traditional UNIX terminal, but close enough + I'd say + <braunr> the terminal itself maybe ? + <antrik> hm... that would avoid having to implement a more generic + multiplexing approach -- but it would mix things that are normally quite + orthogonal... + <antrik> BTW, I personally believe terminals need to get smarter anyways + :-) + <braunr> ok + <antrik> the traditional fully linear dialog has some nice properties; but + it is also pretty limited, leading to usability problems soon. I have + some vague ideas for an approach that still looks mostly like a linear + dialog, but is actually more structured + + +## IRC, freenode, #hurd, 2013-11-04 + + <braunr> yes the learning curve [of the Hurd] is too hard + <braunr> that's an entry barrier + <braunr> this is why i use well known posix-like (or other well + established) apis in x15 + <braunr> also why i intend to make port rights blend into file descriptors + <teythoon> right + <braunr> well + <braunr> the real reason is efficiency + <braunr> but matching existing practices is very good too + + +## IRC, freenode, #hurd, 2013-11-08 + + <gnufreex> braunr, how is work on x-15 progressing? Is there some site to + check what is new? + <braunr> gnufreex: stalled for 2 months + <braunr> i'm working on the hurd for now, will get back to it later + <braunr> no site + <braunr> well + <gnufreex> so, you hit some design problem, or what? I mean why stalled + <braunr> http://git.sceen.net/rbraun/x15.git/ :p + <gnufreex> Thanks + <braunr> something like that yes + <braunr> i came across + http://darnassus.sceen.net/~rbraun/radixvm_scalable_address_spaces_for_multithreaded_applications.pdf + <gnufreex> I read that, I think I found it on Hurd site. + <braunr> and since x15 aims at being performant and scalable, it seems like + a major feature to bring in + <braunr> but it's not simple to integrate + <gnufreex> So you want to add that? + <braunr> gnufreex: yes + <gnufreex> branur, but what are the problems? + <braunr> ? + <braunr> ah + <braunr> you really want to know ? :) + <gnufreex> Well... yeah + <braunr> you need to know both x15 and radixvm for that + <braunr> for one, refcache, as described in the radixvm paper, doesn't seem + scalable + <braunr> it is in practice in their experiments, but only because they + didn't push some parameters too high + <braunr> so i need to rethink it + <gnufreex> I don't know x15... but I read radixvm paper + <braunr> next, the bsd-like vm used by x15 uses a red-black tree to store + memory areas, which doesn't need external storage + <braunr> radixvm as implemented in xv6 is only used for user processes, not + the kernel + <braunr> which means the kernel allocator is a separate implementation, as + it's done in linux + <braunr> x15 uses the same implementation for both the kernel and user maps + <braunr> which results in a recursion problem + <braunr> because a radix tree uses external nodes that must be dynamically + allocated + <gnufreex> so you would pretty much need to rewrite x15 + <braunr> no + <braunr> just vm/ + <braunr> and $arch/pmap + <braunr> and yes, pmap needs to handle per-core page tables + <braunr> something i wanted to add already but couldn't because of similar + recursion problems + <gnufreex> Yeah, vm system... but what else did you do with x15... it is at + early stage... + <braunr> multithreading + <gnufreex> That doesn't need to be rewriten? + <braunr> no + <gnufreex> Ok... good. + <braunr> physical memory allocation neither + <braunr> only virtual memory + <gnufreex> is x15 in runable state? I mean in virtual machine? + <braunr> you can start it + <braunr> but you won't go far :) + <gnufreex> What do you use as development platform? + <braunr> it basically detects memory and processors, starts idle, migration + and worker threads, and leaves + <gnufreex> Is it compilable on fedora 19 + <braunr> probably + <braunr> i use debian stable + <braunr> and unstable on the hurd + <gnufreex> ok, I will probably try it in KVM... + <braunr> better do it on real hardware too in case you find a bug + <gnufreex> I cant make new partition now... it seems my hard drive is + dying. When I get a new one I will try on real harware. + <braunr> you don't need a new partition + <braunr> the reason radixvm is important is twofold + <braunr> 1/ ipc will probably make use of the core vm operations used by + mmap and munmap + <braunr> 2/ no other system currently provides scalable + mmap/munmap/mprotect + <gnufreex> Yes, that would make x15 pretty special... + <gnufreex> But I read somewhere that you wanted to implement RCU during + summer + <gnufreex> Did you do that? + + +## IRC, freenode, #hurd, 2013-11-12 + + <braunr> neal: about secure operating systems + <braunr> i assume you consider clients providing their own memory a strong + requirement for that, right ? + <neal> no + <neal> I'm less interested in availability + <neal> or performance guarantees + <braunr> ok + <braunr> but + <braunr> i thought it was a requirement to avoid denial of service + <neal> of course + <braunr> then why don't you consider it required ? + <neal> I want something working in a reasonable amount of time :) + <braunr> agreed + <neal> more seriously: + <neal> my primary requirement is that a program cannot access information + that the user has not authorized it to access + <braunr> ok + <neal> the requirement that you are suggesting is that a program be able to + access information that the user has authorized it to access + <neal> this is availability + <braunr> i'm not following + <braunr> what's the difference ? + <neal> assume we have two programs: A and B + <neal> on Unix, if they run under the same uid, they access access each + other files + <neal> I want to fix this + <braunr> ok, that's not explicit authorization + <braunr> but is that what you mean ? + <neal> Now, assuming that A cannot access B's data and vice versa + <neal> we have an availability problem + <neal> A could prevent B from accessing its data + <neal> via a DoS attach + <neal> I'm not going to try to fix that. + <braunr> ok + <braunr> and how do you intend to allow A to access B's data ? + <braunr> i guess the powerbox mentioned in the critique + <braunr> but do you have a more precise description about something + practical to use ? + + +## IRC, freenode, #hurd, 2013-11-14 + +In context of [[hurd/libports]], *Open Issues*, *IRC, freenode, #hurd, +2013-11-14*. + + <braunr> fyi, x15 will not provide port renaming + <braunr> teythoon: also, i'm considering enforcing port names to be as + close as possible to 0 when being allocated as part of the interface + <braunr> what do you think about that ? + <teythoon> braunr: that's probably wise, yes + <teythoon> you could hand out receive ports close to 0 and send ports close + to ~0 + <braunr> teythoon: what for ? + <teythoon> well, if one stores only one kind in an array, it won't waste as + much space + <braunr> this also means you need to separate receive from send rights in + the interface + <braunr> so that you know where to look for them + <braunr> i'm not sure it's worth the effort + <braunr> using the same code for them both looks more efficient + <braunr> the right lookup code is probably one of the hottest path in the + system + <teythoon> right + <neal> one of the nice things about not reusing port names is that it helps + catch bugs + <neal> you don't want to accidently send a message to the wrong recipient + <braunr> how could you, if the same name at different times denotes + different rights ? + <neal> you forget to clean up something + <braunr> if you don't clean, how could you get the same name for a right + you didn't release ? + <neal> that's not hard to do :) + <neal> ah, you cleaned up the port right but not the name + <braunr> ah ok + <neal> destroy the port and forget that a thread is still working on a + response + <neal> the data structure says use the port at index X + <neal> X is reallocated in the mean time + <teythoon> excuse my ignorance, but gnumach *is* reusing port names, isn't + it? + <braunr> that policy is why i'm not sure i want to enforce allocation + policy in the interface :/ + <neal> This is not about a security property of the system + <neal> this is about failing fast + <neal> you want to fail as close to the source of the problem as possible + <braunr> we could make the kernel use different allocation policies for + names, to catch bugs, yes + <neal> make the index X valid again and you've potentially masked the bug + <teythoon> braunr: if you were to merge your radix tree implementation into + gnumach and replace the splay tree with it, would that make using renamed + ports fast enough so we can just rename all receive ports doing away with + the extra lookup like mach-defpager does ? + <braunr> i don't think so + <braunr> the radix tree code is able to compress its size when keys are + close to 0 + <braunr> using addresses would add 1, 2, maybe 3 levels of internal nodes + <braunr> for every right + <braunr> we could use a true integer hash table for that though + <braunr> hm no, hurd packages crash ... :/ + <teythoon> but malloc allocates stuff in a contigious space, so the + pointers should be similar in the most significant bits + <braunr> if you use malloc, yes + <teythoon> sure + <teythoon> but that'd make the radix tree representation compact, no? + <braunr> it could + <braunr> the current code only compresses near 0 + <teythoon> oh + <braunr> better compression could be implemented though + + +## IRC, freenode, #hurd, 2013-11-21 + + <teythoon> have you seen liburcu ? + <braunr> a bit, yes + <teythoon> it might be worth investigating to use it in some servers + <braunr> it is + <teythoon> the proc server comes to mind + <braunr> personally, i think all hurd servers should use rcu + <braunr> libports should use rcu + <teythoon> yes + <braunr> lockless synchronization should be a major feature of x15/propel + <braunr> present even during message passing + + +## IRC, freenode, #hurd, 2013-12-09 + + <braunr> improving our page cache with arc would be great + <braunr> it's on the todo list for x15 :> + <braunr> not sure you referred to virtual memory management though + <braunr> (actually, it's CAR, not ARC that is planned for x15) + + +## IRC, freenode, #hurd, 2013-12-30 + + <braunr> zacts: http://darnassus.sceen.net/~rbraun/x15/qemu_x15.sh + + +## IRC, freenode, #hurd, 2014-01-03 + + <braunr> oh, btw, i've started working on x15 again :> + <teythoon> saw that :) + <braunr> first item on the list: per-cpu page tables + <braunr> the magic that will make ipc extremely scalable :) + <teythoon> i'm worried about your approach tbh + <braunr> too much overhead ? + <teythoon> not on any technical level + <teythoon> but haven + <braunr> ? + <teythoon> 't there been enough reimplementation efforts that got nowhere ? + <braunr> oh that + <teythoon> ^^ + <braunr> well, i have personal constraints and frustrations with the + existing code, and my goal isn't to actually produce anything serious + until it actually gets there + <braunr> which, yes, it might not + <braunr> really, i'm doing it for fun + <teythoon> well sure + <teythoon> that's a damn good reason ;) + <braunr> and if it ever reaches a state where it can actually be used to + run stuff, i would be very happy + <braunr> and considering how it's done, i'm pretty sure things could be + built a lot faster on such a system + <teythoon> but you need to reimplement all the userspace servers as well, + and the libc stuff + <braunr> yes + <teythoon> do you plan to reimplement this from scratch or do you have + plans to 'bootstrap' propel from hurd ? + <braunr> from scratch + <teythoon> well... i'm not sure that this is feasible or even a good + idea. that's what i meant in a nutshell i guess. + <braunr> i'm familiar with that criticism + <braunr> and you may be right + <braunr> this is also why i keep working on the hurd at the same time + <teythoon> we could also talk about making hurd more easily portable + <braunr> portable with regard to what ? + <teythoon> evolving hurd and mach to the point where it might be feasible + to port hurd to another ukernel + <braunr> not so easy + <teythoon> i know + <braunr> i'm not even sure i would want that + <braunr> well, since the hurd isn't optimized at all, why not + <teythoon> why would it neccessarily hinder optimization ? + <braunr> because in practice, it's rare for a microkernel to provide all + the features the hurd would require to run really well + <braunr> the most severe issue being that they either provide asynchronous + ipc, used for signals, or only synchronous ipc, making signal and other + event-driven code hard to emulate (usually requiring separate threads) + + +## IRC, freenode, #hurd, 2014-01-20 + +[[translate_fd_or_port_to_file_name]]: + + <teythoon> i wonder if it would not be best to add a description to mach + tasks + <braunr> i think it would + <teythoon> to aid fixing these kind of issues + <braunr> in x15, i actually add descriptions (names) to all kernel objects + <teythoon> that's probably a good idea, yes + <braunr> well, not all, but many + + <braunr> i'd like to push x15 this year + <braunr> it currently is the only design of a truely scalable microkernel + that i know of + <azeem_> push how? + <braunr> spend time on it + <azeem_> k + <azeem_> do you think it will make sense to solicit outside contributions + at one point? + <braunr> yes + <braunr> the roadmap is vm system -> ipc system -> userspace (including RPC + handling) + <braunr> once we can actually do things in userspace, the priority will be + getting a shell with glibc + <braunr> people will be able to help "easily" at that point + <azeem_> just wondering, apart from scalability, did you write it for + performance, for hackability, or something else? + <braunr> it's basically the hurd architecture, including improvements from + the critique, with performance and scalability in mind + <azeem_> ok + <braunr> the main improvements i think of currently are resource + containers, lexical .. resolution, and lists of trusted users with which + to communicate + <braunr> it's strongly oriented for posix compatibility though + <teythoon> sounds nice, i like it already ;) + <azeem_> is it compatible with Mach to some degree? + <braunr> so things like running without an identity will be forbidden in + the default system personality + <braunr> no, not compatible with mach at all + <azeem_> this sounds like it is doing more than Mach did + <azeem_> braunr: ah, ok + <braunr> it's not "x15mach" any more :) + <azeem_> right, I missed out on that + + +### IRC, freenode, #hurd, 2014-01-21 + + <braunr> i also don't write anything that would prevent real-time + <teythoon> b/c that's a potential market for such an operating system ? + <braunr> yes + <teythoon> well, i can't say i don't like the sound of that ;) + <braunr> the ipc interface should be close to that of qnx + + +## IRC, freenode, #hurd, 2014-02-23 + + <cluck> braunr: have you looked at genode? + <cluck> braunr: i sometimes wonder how hard it'd be to port hurd atop it + because i find some similarities with what l4/fiasco/viengos provided + <braunr> cluck: i have, but genode seems a bit too far from posix for our + tastes + <cluck> (and yes, i realize we'd be getting farther from the hw) + <braunr> ah you really mean running the hurd on top of it + <braunr> i personally don't like the idea + <cluck> braunr: well, true, but their noux implementation proves it's not a + dealbreaker + <cluck> braunr: at least initially that'd be the best implementation + approach, no? as time went on integrating hurd servers more tightly at a + lower level makes sense but doing so from the get go would be foolhardy + <cluck> braunr: or am i missing something obvious? + <braunr> cluck: why would it be ? + <cluck> braunr: going by what happened with l4 it's too much code to port + and optimize at once + <braunr> cluck: i don't think it is + <braunr> cluck: problems with l4 didn't have much to do with "too much + code" + <cluck> braunr: i won't debate that, you have more experience than me with + hurd code. anyway that's how i'd go about it, first get it all running + then get it running fast. breakage is bad + <braunr> and you think moving from something like linux or genode to an + implementation closer to hardware won't break things ? + <cluck> braunr: yes, i read the paper, obvious unexpected shortcomings but + even had them not been there the paradigms are too different and creating + proper mappings from one model to the other would at least be time + consuming + <braunr> ye + <braunr> yes + <braunr> i'm convinved the simple approach of a small microkernel with the + proper interfacen along with the corresponding sysdeps layer in glibc + would be enough to get a small hurd like system quickly + <braunr> experience with other systems shows how to directly optimize a lot + of things from the start, without much effort + + <cluck> braunr: sorry. back to our talk, i mentioned genode because of the + nice features it has that'd be useful on hurd + <braunr> cluck: which ones do you refer to ? + <cluck> braunr: the security model is the biggest one + <braunr> how does it differ from the hurd, except for revocation ? + <cluck> braunr: then there's the ease of portability + <braunr> ? + <cluck> braunr: it's more strict + <braunr> how would that help us ? + <cluck> braunr: if hurd was running atop it we'd get extra platforms + supported almost for free whenever they did (since we'd be using the same + primitives) + <braunr> why not choose the underlying microkernel directly ? + <cluck> call me crazy but i believe code reuse is a good thing, i see + little point in duplicating existing code just because you can + <braunr> what part of genode should be reused then ? + <cluck> that's what got me thinking about genode in the first place, + ideologically they share a lot (if not most) of hurd's goals and code + wise they feel close enough to make a merge of sorts not seem crazy talk, + thus my asking if i'm missing something obvious + <braunr> i think the design is incompatible with our goals of posix + compatibility + <cluck> braunr: oh, ok. + <cluck> braunr: i was assuming that wasn't an issue, as i mentioned before + they have noux already and if hurd's servers got ported they'd provide + whatever else that was missing + <braunr> noux looks like a unix server for binary compatibility + <braunr> i'm not sure it is but that's what the description makes me think + <braunr> and if it really, then it's no different than running linux on top + of an hypervisor + <braunr> ok it's not for binary compatibility but it definitely is a + (partial) unix server + <braunr> i much prefer the way the hurd is posix compliant without any + additional layer for compatibility or virtualization + <cluck> braunr: noux is a runtime, as i understand it there's no binary + compatibility just source (ie library/api calls) + <braunr> yes i corrected that just now + <cluck> sorry, i'm having lag issues + <braunr> no worries + <cluck> braunr: anyway, how's x15 coming along? still far from being a + practical replacement? + <braunr> yes .. :( + <braunr> and it's not a replacement + <cluck> (for mach) + <braunr> no + <cluck> huh? + <braunr> it's not a replacement for the hurd + <braunr> err, for mach + <cluck> braunr: i thought you were writing it to be compatible with mach's + interfaces + <braunr> no + <braunr> it used to be that way + <braunr> but no + <cluck> braunr: what changed? + <braunr> mach ipc is too ccmplicated + <braunr> complicated* + <braunr> its supposed benefit (of allowing the creation of computer + clusters for single system images) are outdated and not very interesting + <braunr> it's error prone + <braunr> and it incurrs more overhead than it should + <cluck> no arguing there + <cluck> braunr: are you still targeting being able to run hurd atop x15 or + is it just your pet project now? + <braunr> i don't intend the hurd to run on top of it + <braunr> the reason it's a rewrite is to fix a whole bunch of major issues + in one go diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn index 7e7cfb4e..cf02471d 100644 --- a/microkernel/mach/gnumach/debugging.mdwn +++ b/microkernel/mach/gnumach/debugging.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012, 2013 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 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 @@ -135,7 +135,7 @@ update its display buffer anymore under certain conditions. # Halting the CPU and Examining Registers -IRC, freenode, #hurd, 2011-07-14: +## IRC, freenode, #hurd, 2011-07-14 <braunr> one ugly trick i use when printf isn't available is to halt the cpu @@ -146,7 +146,22 @@ IRC, freenode, #hurd, 2011-07-14: # Serial Console -IRC, freenode, #hurd, 2011-11-13: +## IRC, freenode, #hurd, 2011-11-13 <youpi> use console=com0 <youpi> to activate the console on the first serial port + + +# `ud2` instruction + +## IRC, freenode, #hurd, 2013-10-31 + + [master-x86_64] + <phcoder> GNU Mach 1.3.99 + <phcoder> Running on xen-3.0-x86_64. + <phcoder> AT386 boot: physical memory from 0x0 to 0x40000000 + <youpi> \o/ + <phcoder> well when loaded through pvgrub2 i hangs without any message + <phcoder> any pointers on debugging? + <youpi> I usually put the ud2 instruction along the path to see where it + crashes diff --git a/microkernel/mach/gnumach/interface.mdwn b/microkernel/mach/gnumach/interface.mdwn index b2451887..bfcb9ea6 100644 --- a/microkernel/mach/gnumach/interface.mdwn +++ b/microkernel/mach/gnumach/interface.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 @@ -14,3 +14,39 @@ License|/fdl]]."]]"""]] [[!map pages="microkernel/mach/gnumach/interface/*" show=title]] + + +# Proposed + +## Futex + +### Patches on bug-hurd + +### IRC, freenode, #hurd, 2014-01-20 + + <teythoon> braunr: i meant to ask about the futex stuff + <teythoon> what do you mean when you talk about the interface ? + <teythoon> i imagined something like this + <braunr> more precisely ? + <teythoon> for shared futexes, do not use a pointer, but a right + referencing a memory object, and the offset ? + <braunr> why not a pointer ? + <braunr> well, an address + <teythoon> that's how it's currently done, right ? + <teythoon> in marins prototype i mean + <braunr> yes + <braunr> it's a task/address pair + <teythoon> so the only concern is the access in the kernel ? + <braunr> hum not only no + <braunr> or yes, but there are multiple ways to access + <teythoon> i meant to say this, for me, it would be very helpful if you + were more explicit when you describe how you picture something + <braunr> i thought i did it clearly + <braunr> i even agree with what roland describes + <braunr> which looks even clearer + <braunr> also, i said i didn't picture it completely + <braunr> :) + <braunr> i didn't want to work on that, only review + <teythoon> sure, but what might be clear to you is most likely not that + clear to me + <braunr> ok diff --git a/microkernel/mach/gnumach/interface/device/time.mdwn b/microkernel/mach/gnumach/interface/device/time.mdwn index d1e9a488..18681f21 100644 --- a/microkernel/mach/gnumach/interface/device/time.mdwn +++ b/microkernel/mach/gnumach/interface/device/time.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 @@ -16,3 +16,89 @@ Typically available as `/dev/time`, [[hurd/translator/storeio]]. Using that, [[hurd/libshouldbeinlibc]]'s `<maptime.h>` provides `maptime_map` and `maptime_read`, see the [[hurd/reference_manual]]. Candidate for replacement with [[open_issues/vDSO]] code? + + +# IRC, freenode, #hurd, 2013-11-20 + + <teythoon> braunr: about the mach device interface, if i open a device, and + then create a memory mapping using device_map, does that increment the + open count of the device ? + <teythoon> can i call device_close w/o destroying the mapping directly + after mapping it ? + <antrik> teythoon: I have a vague recollection that the mapping (or more + precisely, the memory object) is not bound to the open once + established... but don't take my word on it -- it's been some years since + I played with that stuff :-) + <teythoon> antrik: yes, that would actually match my expectation + <braunr> hum + <braunr> normally, mapping increments the usage count of the resource + mapped, but not the open count + <braunr> i don't know if that's the case for mach devices + <braunr> teythoon: which mach device btw ? + <teythoon> time + <teythoon> libshouldbeinlibc/maptime.c line ~53 + <teythoon> the device is opened but never closed + <braunr> is that a problem ? + <teythoon> not sure, but I'd think so, yes + <braunr> why ? + <teythoon> the open count is incremented each time + <braunr> at map time ? + <braunr> ah no, since that's your question + <braunr> the open count is normally decremented when the send right for the + device is destroyed, which occurs when tasks exit + <teythoon> hm + <teythoon> but wouldn't only important long running servers use the mach + device ? + <braunr> all tasks do + <braunr> a simple call to gettimeofday will use it + <teythoon> well, but only privileged processes may get teh device master + port + <braunr> the device is probably accessible through some other method + <teythoon> yes. /dev/time + <teythoon> err, have you looked at the function ? ;) + <braunr> no + <braunr> which one ? + <teythoon> maptime_map + <braunr> i did once but quickly + <teythoon> if use_mach_dev, the mach device is used, /dev/time otherwise + <braunr> gettimeofday apparently uses __host_get_time + <braunr> mhmm + <braunr> ok so i was wrong + <braunr> the time device, whether it is the mach or the hurd one, seems to + be mapped only by translators + <braunr> 14:10 < teythoon> but wouldn't only important long running servers + use the mach device ? + <braunr> so yes :) + <teythoon> so we should close the device + <braunr> why ? + <teythoon> to prevent an overflow in the open count + <braunr> when is it open multiple times ? + <teythoon> isn't it ? maybe /me lacks some context ;) + <braunr> it's called once at init time + <teythoon> well, ok then + <braunr> gettimeofday-like functions then only read the mapped memory + <braunr> at least, that's how it's done in the servers i've looked at such + as pfinet + <teythoon> makes sense, yes + <braunr> something i learnt from experience and failures: check the problem + actually exists before fixing it :p + <teythoon> well, if the memory mapping is independent of the device, then + there is a problem + <teythoon> the device is kept open for no reason + <braunr> teythoon: if you can determine that the device doesn't need to + stay open for the mapping to remain, then you can close it + <braunr> otherwise, it's such a minor leak that we don't care at all + <braunr> i wouldn't even consider it a leak more than a small static + variable used at init time only + <teythoon> looks like, yes + <teythoon> also, it's only in the rootfs translator + <braunr> ? + <teythoon> only the root filesystem uses the mach device directly + <braunr> ok + <braunr> well, /dev/time too right ? + <teythoon> yes, but that is a storeio translator that does not use this + code + <braunr> yes + <braunr> hm + <teythoon> only the root filesystem uses the mach device directly *using + this function* diff --git a/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn b/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn index a169e92e..d03c9674 100644 --- a/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn +++ b/microkernel/mach/gnumach/interface/syscall/mach_print.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 @@ -88,3 +88,33 @@ License|/fdl]]."]]"""]] the caller's address space without going through a special copy-from-user function <braunr> not very portable + + +## IRC, freenode, #hurd, 2013-11-25 + + <teythoon> can we get the mach_printf function somewhere so that it's + easier to use please ? + <braunr> well + <braunr> i'm not comfortable with that + <teythoon> y not ? + <braunr> i don't consider mach_print being part of the interface yet + <teythoon> ... + <braunr> it's really a debugging call + <braunr> not always available + <teythoon> so what, let it fail if it is not + <braunr> ok + <braunr> i should change it first + <braunr> pass a size argument + <braunr> and do a proper copyin + <teythoon> cool, thanks :) + <braunr> then we could add that printf function in libshouldbeinlibc i + guess + <teythoon> that'd be nice, yes + <braunr> hm + <braunr> that would make only hurd servers able to use it though + <braunr> unless we preload it + <teythoon> well, i thought it's a staging area for libc ? + <braunr> in theory yes, in practice some functions have been stuck there + for ages + <braunr> we'll discuss that with youpi and tschwinge + <braunr> and pinotree diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index c6023786..a8a1fcbf 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 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 @@ -96,6 +96,176 @@ Download http://youpibouh.thefreecat.org/hurd-xen/pv-grub.gz into /boot, and use extra is now the path to the grub config file. + +## IRC, freenode, #hurd, 2013-11-09 + + <phcoder> youpi: would a limitation of 32 modules to hurd in pvgrub2 be a + problem? + <phcoder> *31 + <youpi> phcoder: probably not + <phcoder> youpi: ok + + <phcoder> youpi: gnumach goes into infinite loop with "warning: nsec + 0x000096dae65d2697 < lastnsec 0x000096db11dee20d". Second value stays + constant, first value loops from 0x000096da14968a59 to + 0x000096db08bf359e. Not sure if the problem is on GRUB or gnumach ide + <youpi> loops?! + <youpi> that's the time coming from the hypervisor + <youpi> not a problem from GRUB anyway + <phcoder> Yes, loops in steps of around 0x40 and comes back regularly. + <youpi> Mmm, maybe it could be grub not properly setting up + hyp_shared_info.vcpu_info[], actually + <youpi> i.e. the mfn in boot_info.shared_info + <phcoder> I don't think we write to shared page at all + <phcoder> could gnumach suffer from overflow on fast CPU? + <phcoder> next_start.shared_info = grub_xen_start_page_addr->shared_info; + <phcoder> And shared_info is machine address, so no need to adjust it + <phcoder> tsc_shift can be negative. Does gnumach handle this? + <youpi> yes + <youpi> here it's the base which doesn't change, actually + <phcoder> Do you mean this: system_time = + time->system_time; ? + <phcoder> But wait: ((delta * (unsigned64_t) mul) >> 32) + <phcoder> this overflows after 2^32 nanoseconds + <phcoder> which is about 4 seconds + <phcoder> I think this is the mistake + <phcoder> which is more or less what I see + <phcoder> Let me make a patch + <youpi> does xen have some tickless feature now? + <youpi> I'd expect the clock to get updated at least sometimes during 4 + seconds :) + <phcoder> Hm, can't compile master: + <phcoder> ./include/mach/xen.h:52:18: error: ‘MACH2PHYS_VIRT_START_PAE’ + undeclared (first use in this function) + <phcoder> #define PFN_LIST MACH2PHYS_VIRT_START_PAE + <phcoder> Here is the patch: http://paste.debian.net/64857/ + <youpi> it's defined in xen/public/arch-x86/xen-x86_32.h + <phcoder> yes it is. Let's see why it's not included + <phcoder> Hm, for some reason it pulls 64-bit headers in + <youpi> how do you cross-compile? + <youpi> I use + <youpi> ./configure --host=i686-gnu CC='gcc -m32' LD='ld -melf_i386' + <phcoder> Yes. GRUB adds those itself + <phcoder> youpi: confirmed: my patch solves the problem + <phcoder> any yes: I tried with unpatched master and it fails + <youpi> ok + <youpi> phcoder: thanks! + + <phcoder> Now I get plenty of "getcwd: cannot access parent directories: + Inappropriate file type or format". But I don't think it's grub-related + <youpi> what do you get before that? + <youpi> perhaps ext2fs doesn't get properly initialized + <youpi> which module commande line do you get in the boot log? + <youpi> perhaps it's simply a typo in there + <phcoder> http://paste.debian.net/64865/ + <youpi> $(task-create) $(task-resume) is missing at the end of the ext2fs + line indeed + <youpi> in your paste it stops at $( + <phcoder> this is at the end of my console. I believe it to be + cosmetic. Let me reset console to some sane state + <youpi> ok + <youpi> the spurious event at the start is probably worth checking up + <youpi> it looks like events that pvgrub2 should have eaten + <youpi> (in its own drivers, before finishing shutting them down) + <phcoder> when redirecting console to file: http://paste.debian.net/64868/ + <phcoder> could swapon have sth to do with it? + <youpi> I'd be surprised + <phcoder> my guess it's because I use older userland (debian about May) and + new kernel (fresh from master) + <youpi> the kernel hasn't really changed + <youpi> you could rebuild the may-debian kernel with your patch to make + sure + <youpi> but probably better trying to fix swapon first, at least + <youpi> (even if that'd surprise me) + <youpi> "trying fixiing* swapon", actually + <youpi> it makes a difference :) + <phcoder> We actually never eat event on evtchn, we look into buffers to + check for response + <youpi> ah, that's why + <youpi> you should really eat the events too + <youpi> in principle it wouldn't hurt not to, but you'd probably get + surprises + + <phcoder> youpi: would doing EVTCHNOP_reset at the end be enough? + <youpi> possibly, I don't know that one + <youpi> looks like a good thing to do before handing control, indeed + <youpi> /* Clear pending event to avoid unexpected behavior on + re-bind. */ + <youpi> evtchn_port_clear_pending(d1, chn1); + <youpi> yes, it does clear the pending events + <phcoder> http://paste.debian.net/64870/ + <phcoder> I did this: http://paste.debian.net/64871/ + <youpi> well, closing the event channels would be a good idea too + <youpi> (reset does not only clear pending events, it also closes the event + channels) + <phcoder> well we can't close console one. So it leave to close disk ones + (the ones we allocated) + <phcoder> http://paste.debian.net/64875/ + <phcoder> New log: http://paste.debian.net/64876/ (swapon fixed, given 1G + of memory) + <youpi> ok, so it really is something else + <phcoder> looks like there is a space after $(task-resume) but can't tell + if it's real or comes from message + <phcoder> tottally artefact + + <phcoder> youpi: this happens when booted in qemu with old kernel now. Now + my bet is on weird fs corruption or because I accessed it with Linux in + rw. In any case I feel like it's time to call it a port and commit + <youpi> I'd say so, yes + <phcoder> Let's look what's remaining: vfb, vkbd and vif: don't need them + for first port commit. Hm, there is an issue of default configfile. What + is pvgrub default behaviour? + <youpi> iirc it just enters the shell + <youpi> I had implemented vfb and vkbd to get the graphical support, but + that's optional indeed + <youpi> vif is useful for netboot only + <youpi> ah, no, by default it runs dhcp --with-configfile + <phcoder> youpi: port committed to trunk + <youpi> \o/ + <youpi> I was lamenting for 5 years that that wasn't happening :) + <youpi> Citrix could have asked one of his engineers to work on it, really + <phcoder> documentation on using the port is still missing though + <youpi> amazon EC2 users will be happy to upgrade from pv-grub to pv-grub2 + :) + <youpi> I asked some amazon guy at SuperComputing whether he knew how many + people were using pv-grub, but he told me that was customer private + information + <phcoder> Another interesting idea would be to switch between 64-bit and + 32-bit domains somehow + <youpi> yes, we were discussing about it at XenSource when I implemented + pv-grub + <youpi> that's not really an easy thing + <youpi> pvh would probably help there, again + <youpi> in the end, we considered that it was usually not hard to select a + 32bit or 64bit pv-grub depending on the userland bitness + <youpi> we considered adding a hypercall to change the bitness of a domU, + but that's really involved + <phcoder> Well when you discussed i386 domains were still around + <phcoder> now it's only PAE and amd64 and they are very similar. Only few + gdt differ + <youpi> well, switching from 32-PAE to 64 is not *so* hard + <youpi> since a 32bit-loaded OS can fit in 64bit + <youpi> the converse is more questionable of course + <phcoder> yes + <youpi> still, it's really not easy for the hypervisor + <youpi> it'd mean converting stuff here and there + <youpi> most probably missing things here and there :) + <phcoder> Ok, not that important anyway + <youpi> we felt it was too dangerous to promise the feature as working :) + <youpi> heh, 5000 lines patch, just like my patch adding support to Mach :) + <phcoder> BTW do you know how to check if kernel supports dom0 ? Apparently + there is feature "privilegied" and dom0 kernels are supposed to have it + in notes but my linux one doesn't even though I'm in xen now + <youpi> it's XENFEAT_dom0 + <youpi> called dom0 in the notes + <phcoder> http://paste.debian.net/64894/ + <youpi> well, maybe the hypervisor doesn't actually check it's there + <youpi> phcoder: what does grub-mkstandalone? + <phcoder> puts all modules in memdisk which is embed into core + <youpi> ah, ok + <youpi> we didn't have to care about that in grub1 indeed :) + + # Partitions You will need the following notation for the gnumach root= parameter: @@ -108,6 +278,23 @@ You will also need to use the parted storeio module for the /dev entries, for in settrans -fgap /dev/hd0s1 /hurd/storeio -T typed part:1:device:hd0 + +## IRC, freenode, #hurd, 2013-11-09 + + <phcoder> youpi: now I get "hd0: dom0's VBD 768 + (/home/phcoder/diskimg/debian-hurd-20130504.img,w) 3001MB" + <phcoder> but "start ext2fs: ext2fs: device:hd0s1: No such device or + address" + <phcoder> disk = [ + 'file:/home/phcoder/diskimg/debian-hurd-20130504.img,hda,w' ] + <phcoder> Hm, using "disk = [ 'phy:loop0,hda1,w' ]" instead worked (loop0 + is an offset loop) + <youpi> yes, xen disks don't support partitioning + <youpi> and we haven't migrated userland to userland partitioning yet + +[[hurd/libstore/part]]. + + # Miscellaneous [[Internals]]. @@ -125,3 +312,20 @@ IRC, freenode, #hurd, 2011-06-08 <braunr> youpi: does xen provide disk caching options ? <youpi> through a blktap, probably <braunr> ok + + +# IRC, freenode, #hurd, 2013-11-09 + + <phcoder> youpi: debian-hurd-20130504.img apparently has a kernel without + xen note. Do I have to do sth special to get xen kernel? + <youpi> phcoder: there's the -xen package for that + <youpi> I haven't made the kernel hybrid + <phcoder> youpi: easiest way is probably to have different entry + points. You could even just link both of them at different addresses and + then glue together though it's not very efficient + <youpi> it's also about all the privileged operations that have to be + replaced with PV operations + <youpi> PVH will help with that regard + + <phcoder> youpi: btw, I recommend compiling xen kernel for 686 and drop + non-pae diff --git a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn b/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn index 89a27b01..0ca6d91e 100644 --- a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn +++ b/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2010, 2012 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2010, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] @@ -130,3 +130,106 @@ further files (also exported ones) that serve no real value, but are being <mcsim> this parameter has name data_count <braunr> that's one of the reasons mach is confusing <braunr> i can't really tell you why, it's messy :/ + + +# [[open_issues/Code_Analysis]], *Coverity* + +## IRC, freenode, #hurd, 2014-02-03 + + <teythoon> braunr: at the end of kmem_cache_error the comment says 'never + reached'. i do not believe that to be true... + <braunr> teythoon: yes, this is a mistake + <braunr> those kmem_error calls were panics in the original version + <braunr> the comment was left over + <braunr> or rather, the panic equivalent not added + + +### IRC, freenode, #hurd, 2014-02-04 + + <teythoon> braunr: but the code relies uppon the fact that kmem_cache_error + does not return + <teythoon> the fact that it doesn't upsets static analysis tools + <teythoon> + http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2014-01-17/report-DfjC43.html#Path9 + <braunr> 21:20 < braunr> or rather, the panic equivalent not added + <braunr> teythoon: you're right + <braunr> it needs to be fixed + <teythoon> i setup a coverity project for gnu mach + <teythoon> it's interesting + <teythoon> very enterprisy >,< + <braunr> teythoon: heh + <teythoon> braunr: i assume kmem_error is supposed to panic + <teythoon> if so, i'd propose to use panic instead of printf in that macro + definition + <braunr> yes + <braunr> teythoon: again, that's how it's done in the original + implementation + <teythoon> and fix kmem_cache_error to use kmem_warn near the top of the + function + <braunr> teythoon: i suggest you use the x15 variant as a reference + (http://git.sceen.net/rbraun/x15.git/blob/HEAD:/kern/kmem.c) + <teythoon> right + + +### IRC, OFTC, #debian-hurd, 2014-02-05 + + <pere> ah, cool. <URL: https://scan.coverity.com/projects/1307 > + is now in place. :) + <teythoon> pere: it was you who made me create the coverity project + <teythoon> and it was most fruitful already + <pere> glad to hear that. :) + <pere> while the mach thread made me discover scan-build, which + seem promising but have way to few rules. + <pere> teythoon: btw, could I get access to the mach coverity + status? + <teythoon> pere: sure + <pere> I've used up all my 'join project' slots, so I suspect you + have to invite me. try pere@hungry.com + <teythoon> pere: ok + <teythoon> pere: i'm fuzzy about the roles + <teythoon> what kind of invite shall i send you ? + <pere> not sure either. + <teythoon> ok + <pere> contributor/* would be fine for me. want to check the + details, not just the overview. + <teythoon> oh + * pere looked up the role description + <teythoon> do you have a link ? + <teythoon> i can always change the role afaics + <pere> go to the member list, found it there. + <pere> (the link is project specific, it seem. + <teythoon> right, found it + <pere> gah, it gave me a new user. :( + <pere> I assumed I would be allowed to accept the invite using my + normal user. + <pere> can you try again with pere-github@hungry.com, which + hopefully will hook the invite to my github authenticated user? + <teythoon> sure + <pere> were you allowed to invite that address? + <pere> ah, I got it in my dashboard without having to do anything + more. + <pere> heh, the email I got claimed the user would not be created + unless I provided a password, but given the member list for mach, + I fail to see how that could be true. + + +### IRC, OFTC, #debian-hurd, 2014-02-06 + + <teythoon> pere: your coverity invitations are still saying 'not + accepted', did neither work ? + <pere> teythoon: one worked just fine. I got access. the other I + did not accept. + <teythoon> pere: good :) + + +### IRC, OFTC, #debian-hurd, 2014-02-25 + + <pere> I am quite impressed with the defect density of Mach, <URL: + https://scan.coverity.com/projects/1307 >. :) + <pere> 12 outstanding issues (but 54 dismissed was surprisingly + high :). + <youpi> pere: 54 dismissed because that's a pattern generated by + mig + <youpi> repeated dozens of times + +[[!tag open_issue_mig]] diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn index e6bd1bb9..96731a5d 100644 --- a/microkernel/mach/mig/documentation.mdwn +++ b/microkernel/mach/mig/documentation.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010, 2013 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010, 2013, +2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -99,3 +99,15 @@ pp. 67--77." <braunr> simple (but optimized) scatter-gather <braunr> it makes sense for mig since mach messages do include serialization metadata such as types + + +## IRC, freenode, #hurd, 2013-11-01 + + <gnu_srs> Is it possible to call server functions from user space? What + about functions returning MIG_NO_REPLY? + <neal> gnu_srs: server functions are only called from user space... + <neal> gnu_srs: Normally, servers use a server loop. When an RPC comes it, + it is processed and the processing returns some values that the server + loop returns to the client. + <neal> If the server wants to return the thread to the thread pool without + responding to the RPC, it uses MIG_NO_REPLY. diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn index edb2dccd..04273630 100644 --- a/open_issues/64-bit_port.mdwn +++ b/open_issues/64-bit_port.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 @@ -23,22 +23,8 @@ the [[microkernel/mach/gnumach/ports/Xen]] platform. <braunr> i guess it wouldn't be too hard to have a special mach kernel for 64 bits processors, but 32 bits userland only <youpi> well, it means tinkering with mig - <braunr> like old sparc systems :p - <youpi> to build the 32bit interface, not the 64bit one - <braunr> ah yes - <braunr> hm - <braunr> i'm not sure - <braunr> mig would assume a 32 bits kernel, like now - <youpi> and you'll have all kinds of discrepancies in vm_size_t & such - <braunr> yes - <braunr> the 64 bits type should be completely internal - <braunr> types* - <braunr> but it would be far less work than changing all the userspace bits - for 64 bit (ofc we'll do that some day but in the meanwhile ..) - <youpi> yes - <youpi> and it'd boost userland addrespace to 4GiB - <braunr> yes - <youpi> leaving time for a 64bit userland :) + +[[mig_portable_rpc_declarations]]. # IRC, freenode, #hurd, 2012-10-03 @@ -60,87 +46,7 @@ the [[microkernel/mach/gnumach/ports/Xen]] platform. <braunr> i think i'll go the second way with x15, so you'll have the two :) -# IRC, freenode, #hurd, 2012-12-12 - -In context of [[microkernel/mach/gnumach/memory_management]]. - - <tschwinge> Or with a 64-bit one? ;-P - <braunr> tschwinge: i think we all had that idea in mind :) - <pinotree> tschwinge: patches welcome :P - <youpi> tschwinge: sure, please help us settle down with the mig stuff - <youpi> what was blocking me was just deciding how to do it - <braunr> hum, what's blocking x86_64, except time to work on it ? - <youpi> deciding the mig types & such things - <youpi> i.e. the RPC ABI - <braunr> ok - <braunr> easy answer: keep it the same - <youpi> sorry, let me rephrase - <youpi> decide what ABI is supposed to be on a 64bit system, so as to know - which way to rewrite the types of the kernel MIG part to support 64/32 - conversion - <braunr> can't this be done in two steps ? - <youpi> well, it'd mean revamping the whole kernel twice - <youpi> as the types at stake are referenced in the whole RPC code - <braunr> the first step i imagine would simply imply having an x86_64 - kernel for 32-bits userspace, without any type change (unless restricting - to 32-bits when a type is automatically enlarged on 64-bits) - <youpi> it's not so simple - <youpi> the RPC code is tricky - <youpi> and there are alignments things that RPC code uses - <youpi> which become different when build with a 64bit compiler - <pinotree> there are also things like int[N] for io_stat_struct and so on - <braunr> i see - <youpi> making the code wrong for 32 - <youpi> thus having to change the types - <youpi> pinotree: yes - <pinotree> (doesn't mig support structs, or it is too clumsy to be used in - practice?) - <braunr> pinotree: what's the problem with that (i explcitely said changing - int to e.g. int32_t) - <youpi> that won't fly for some of the calls - <youpi> e.g. getting a thread state - <braunr> pinotree: no it doesn't support struct - <pinotree> braunr: that some types in struct stat are long, for instance - <braunr> pinotree: same thing with longs - <braunr> youpi: why wouldn't it ? - <youpi> that wouldn't work on a 64bit system - <youpi> so we can't make it int32_t in the interface definition - <braunr> i understand the alignment issues and that the mig code adjusts - the generated code, but not the content of what is transfered - <braunr> well of course - <braunr> i'm talking about the first step here - <braunr> which targets a 32-bits userspace only - <youpi> ok, so we agree - <youpi> the second step would have to revamp the whole RPC code again - <braunr> i imagine the first to be less costly - <braunr> well, actually no - <braunr> you're right, the mig stuff would be easy on the application side, - but more complicated on the kernel side, since it would really mean - dealing with 64-bits values there - <braunr> (unless we keep a 3/1 split instead of giving the full 4g to - applications) - -See also [[microkernel/mach/gnumach/memory_management]]. - - <youpi> (I don't see what that changes) - <braunr> if the kernel still runs with 32-bits addresses, everything it - recevies from or sends through mig can be stored with the user side - 32-bits types - <youpi> err, ok, but what's the point of the 64bit kernel then ? :) - <braunr> and it simply uses 64-bits addresses to deal with physical memory - <youpi> ok - <youpi> that could even be a 3.5/0.5 split then - <braunr> but the memory model forces us to run either at the low 2g or the - highest ones - <youpi> but linux has 3/1, so we don't need that - <braunr> otherwise we need an mcmodel=medium - <braunr> we could do with mcmodel=medium though, for a time - <braunr> hm actually no, it would require mcmodel=large - <braunr> hum, that's stupid, we can make the kernel run at -2g, and use 3g - up to the sign extension hole for the kernel map - - -# IRC, freenode, #hurd, 2013-07-02 +## IRC, freenode, #hurd, 2013-07-02 In context of [[mondriaan_memory_protection]]. @@ -157,8 +63,10 @@ In context of [[mondriaan_memory_protection]]. <braunr> as passed between userspace and kernel -# IRC, OFTC, #debian-hurd, 2013-10-05 +## IRC, OFTC, #debian-hurd, 2013-10-05 <dharc> and what about 64 bit support, almost done? <youpi> kernel part is done <youpi> MIG 32/64 trnaslation missing + +[[mig_portable_rpc_declarations]]. diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index a3c55063..33635b80 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.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 @@ -43,7 +43,11 @@ like Bushnell's Hurd paper. All this should be unfied and streamlined. <antrik> servers often depend on other servers for certain functionality -# IRC, freenode, #hurd, 2011-03-12 +# Bootstrap + +## [[hurd_init]] + +## IRC, freenode, #hurd, 2011-03-12 <dEhiN> when mach first starts up, does it have some basic i/o or fs functionality built into it to start up the initial hurd translators? @@ -76,6 +80,112 @@ like Bushnell's Hurd paper. All this should be unfied and streamlined. rest of the system up +## IRC, freenode, #hurd, 2014-01-03 + + <teythoon> hmpf, the hurd bootstrapping process is complicated and fragile, + maybe to the point that it is to be considered broken + <teythoon> aiui the hurd uses the filesystem for service lookup + <teythoon> older mach documentation suggests that there once existed a name + server instead for this purpose + <teythoon> the hurd approach is elegant and plan9ish + <teythoon> the problem is in the early bootstrapping + <teythoon> what if the root filesystem is r/o and there is no /servers or + /servers/exec ? + <teythoon> e. g. rm /servers/exec && reboot -> the rootfs dies early in the + hurd server bootstrap :/ + <braunr> well yes + <braunr> it's normal to have such constraints + <teythoon> uh no + <braunr> at the same time, the boot protocol must be improved, if only to + support userspace disk drivers + <teythoon> totally unacceptable + <braunr> why not ? + <teythoon> b/c my box just died and lost it's exec node + <braunr> so ? + <braunr> loosing the exec node is unacceptable + <youpi> well, linux dies too if you don't have /dev populated at least a + bit + <braunr> not being able to boot without the "exec" service is pretty normal + <braunr> the hurd turns the vfs into a service directory + <teythoon> the exec service is there, only the lookup mechanism is broken + <braunr> replacing the name server you mentioned earlier + <teythoon> yes + <braunr> if you don't have services, you don't have them + <braunr> i don't see the problem + <braunr> the problem is the lookup mechanism getting broken + <teythoon> ... that easily + <braunr> imagine a boot protocol based on a ramfs filled from a cpio + <teythoon> i do actually ;) + <braunr> there would be no reason at all the lookup mechanism would break + <teythoon> yes + <teythoon> but the current situation is not acceptable + <braunr> i agree + <teythoon> ^^ + <braunr> ext2fs is too unreliable for that + <braunr> but using the VFS as a directory is more than acceptable + <braunr> it's probably the main hurd feature + <teythoon> yes + <braunr> i see it rather as a circular dependency problem + <braunr> and if you have good ideas, i'm all ear for propel ... :> + <braunr> antrik already talked about some of them for the bootstrap + protocol + <braunr> we should sum them up somewhere if not done already + <teythoon> i've been pondering how to install a tmpfs translator as root + translator + <teythoon> braunr: we could create a special translator for /servers + <braunr> maybe + <teythoon> very much like fakeroot, it just proxies messages to a real + translator + <teythoon> but if operations like settrans fail, we handle them + transparently, like an overlay + <braunr> i consider /servers to be very close to /dev + <teythoon> yes + <braunr> so something like devfs seems obvious yes + <braunr> i don't even think there needs to be an overlay + <teythoon> y not ? + <braunr> why does /servers need real nodes ? + <teythoon> for persistence + <braunr> what for ? + <teythoon> e.g. crash server selection + <braunr> hm ok + <teythoon> network configuration + <braunr> i personally wouldn't make that persistent + <braunr> it can be configured in files and installed at boot time + <teythoon> me neither, but that's how it's currently done + <braunr> are you planning to actually work on that soon ? + <teythoon> if we need no persistence, we can just use tmpfs + <braunr> it wouldn't be a mere tmpfs + <teythoon> it could + <braunr> it's a tmpfs that performs automatic discovery and registration of + system services + <teythoon> with some special wrapper that preserves e.g. /servers/exec + <teythoon> oh + <braunr> so rather, devtmpfs + <teythoon> it is o_O :p + <braunr> ? + <braunr> what is what ? + <teythoon> well, it could be a tmpfs and some utility creating the nodes + <braunr> whether the node management is merged in or separate doesn't + matter that much i guess + <braunr> i'd personally imagine it merged, and tmpfs available as a + library, so that stuff like sysfs or netstatfs can easily be written + + +## IRC, freenode, #hurd, 2014-02-12 + + <teythoon> braunr: i fixed all fsys-related receiver lookups in libdiskfs + and surely enough the bootstrap hangs with no indication whats wrong + <braunr> teythoon: use mach_print :/ + <teythoon> braunr: the hurd bootstrap is both fragile and hard to tweak in + interesting ways :/ + <braunr> teythoon: i agree with that + <braunr> teythoon: maybe this will help : + http://wiki.hurdfr.org/upload/graphviz/dot9b65733655309d059dca236f940ef37a.png + <braunr> although i guess you probably already know that + <teythoon> heh, unicode for the win >,< + <braunr> :/ + + # Source Code Documentation Provide a cross-linked sources documentation, including generated files, like @@ -311,6 +421,9 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l <Tekk_> spiderweb: well, there's 1 advantage of minix for you :P <braunr> the main idea of mach is to make it easy to extend unix <braunr> without having hundreds of system calls + +[[/system_call]]. + <braunr> the hurd keeps that and extends it by making many operations unprivileged <braunr> you don't need special code for kernel modules any more @@ -539,6 +652,9 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l <damo22> it must translate these system calls into ipc or something <damo22> then mach handles it? <braunr> exactly + +[[/system_call]]. + <braunr> that's why i say it's not the exokernel way of doing things <damo22> ok <damo22> so does every low level hardware access go through mach?' @@ -811,3 +927,403 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l <braunr> ahungry: ctrl-c does work, you just missed something somewhere and are running a shell directly on a console, without a terminal to handle signals + + +# IRC, freenode, #hurd, 2013-11-04 + + <braunr> nalaginrut: you can't use the hurd for real embedded stuff without + a lot of work on it + <braunr> but the hurd design applies very well to embedded environments + <braunr> the fact that we're able to dynamically link practically all hurd + servers against the c library can visibly reduce the system code size + <braunr> it also reduces the TCB + <nalaginrut> what about the memory occupation? + <braunr> code size is about memory occupation + <teythoon> also, the system is composable like lego, don't need tcp - don't + include pfinet then + <braunr> the memory overheald of a capability based system like the hurd + are, well, capabilities + <braunr> teythoon: that's not an argument compared to modular kernels like + linux + <teythoon> yes it is + <braunr> why ? + <braunr> if you don't need tcp in linux, you just don't load it + <braunr> same thing + <teythoon> ok, right + <braunr> on the other hand, a traditional unix kernel can never be linked + against the c library + <braunr> much less dynamically + <teythoon> right + <nalaginrut> I think the point is that it's easy to cut, since it has + better modularity than monolithic, and could be done in userland relative + easier + <braunr> modularity isn't better + <braunr> that's a big misconception + <teythoon> also, restarting components is easier on a distributed system + <braunr> on the hurd, this is a side effect + <braunr> and it doesn't apply well + <nalaginrut> braunr: oops, misconception + <braunr> many core servers such as proc, auth, exec, the root fs server + can't be restarted at all + <teythoon> not yet + <braunr> and servers like pfinet can be restarted, but at the cost of posix + servers not expecting that + <braunr> looping on errors such as EBADF because the target socket doesn't + exist any more + <teythoon> I've been working on a restartable exec server during some of my + gsoc weekends + <braunr> ah right + <braunr> linux has kexec + <braunr> and can be patched at run time + <nalaginrut> sounds like Hurd needs something similar to generalizable + continuation + <braunr> so again, it's not a real advantage + <braunr> no + <nalaginrut> sorry serilizable + <braunr> that would persistence + <braunr> personally, i don't want it at all + <teythoon> yes it is a real advantage, b/c the means of communication + (ports) is common to every IPC method on Hurd, and ports are first class + objects + <teythoon> so preserving the state is much easier on Hurd + <braunr> if a monolithic kernel can do it too, it's not a real advantage + <teythoon> yes, but it is more work + <braunr> that is one true advantage of the hurd + <braunr> but don't reuse it each time + <nalaginrut> oh, that's nice for the ports + <teythoon> why not? + <braunr> what we're talking about here is resilience + <braunr> the fact that it's easier to implement doesn't mean the hurd is + better because it has resilience + <braunr> it simply means the hurd is better because it's easier to + implement things on it + <braunr> same for development in general + <braunr> debugging + <braunr> virtualization + <braunr> etc.. + <nalaginrut> yes, but why we stick to compare it to monolithic + <braunr> but it's still *one* property + <teythoon> well, minix advertises this feature a lot, even if minix can + only restart very simple things like printer servers + <braunr> minix sucks + <braunr> let them advertise what they can + <teythoon> ^^ + <nalaginrut> it has cool features, that's enough, no need to find a feature + that monolithic can never done + <braunr> no it's not enough + <braunr> minix isn't a general purpose system + <braunr> let's just not compare it to general purpose systems + + +# IRC, freenode, #hurd, 2013-11-08 + + <teythoon> and, provided you have suitable language bindings, you can + replace almost any hurd server with your own implementation in any + language + <crocket> teythoon: language bindings? + <crocket> Do you mean language bindings against C libraries? + <teythoon> either that or for the low level mach primitives + <crocket> For your information, IPC is independent of languages. + <teythoon> sure, that's the beauty + <crocket> Why is hurd best for replacing parts written in C with other + languages? + <teythoon> because Hurd consists of many servers, each server managing one + kind of resource + <teythoon> so you have /hurd/proc managing posix processes + <teythoon> you could reimplement /hurd/proc in say python or go, and + replace just that component of the Hurd system + <teythoon> you cannot do this with any other (general purpose) operating + system that I know of + <teythoon> you could incrementally replace the Hurd with your own + Hurd-compatible set of servers written in X + <teythoon> use a language that you can verify, i.e. prove that a certain + specification is fulfilled, and you end up with an awesome stable and + secure operating system + <crocket> Any microkernel OS fits the description. + <crocket> teythoon, Does hurd have formal protocols for IPC communications? + <teythoon> sure, name some other general purpose and somewhat + posix-compatible microkernel based operating system please + <teythoon> what do you mean by formal protocols ? + <crocket> IPC communications need to be defined in documents. + <teythoon> the "wire" format is specified of course, the semantic not so + much + <crocket> network protocols exist. + <crocket> HTTP is a transport protocol. + <crocket> Without formal protocols, IPC communications suffer from + debugging difficulties. + <crocket> Formal protocols make it possible to develop and test each module + independently. + <teythoon> as I said, the wire format is specified, the semantics only in + written form in the source + <teythoon> this is an example of the ipc specification for the proc server + http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs + <crocket> teythoon, how file server interacts with file clients should be + defined as a formal protocol, too. + <teythoon> do you consider the ipc description a kind of formal protocol ? + <crocket> + http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs can + be considered as a formal protocol. + <crocket> However, the file server protocol should be defined on top of IPC + protocol. + <teythoon> the file server protocol is in fs.defs + <teythoon> every protocol spoken is defined in that ipc description + language + <teythoon> it is used to derive code from + <braunr> crocket: not any system can be used to implement system services + in any language + <braunr> in theory, they do, but in theory only + <braunr> the main reason they don't is because most aren't posix compliant + from the ground up + <braunr> posix compliance is achieved through virtualization + <braunr> which isolates services too much for them to get useful, + notwithstanding the impacts on performance, memory, etc.. + <crocket> braunr, Do you mean it's difficult to achieve POSIX compliance + with haskell? + <braunr> crocket: i mean most l4 based systems aren't posix + <braunr> genode isn't posix + <braunr> helenos is by design not posix + <braunr> the hurd is the only multi server system providing such a good + level of posix conformance + <braunr> and with tls on the way, we'll support even more non-posix + applications that are nonetheless very common on unices because of + historical interfaces still present, such as mcontext + <braunr> and modern ones + <braunr> e.g. ruby is now working, go should be there after tls + * teythoon drools over the perspective of having go on the Hurd... + <crocket> braunr, Is posix relevant now? + <braunr> it's hugely relevant + <braunr> conforming to posix and some native unix interfaces is the only + way to reuse a lot of existing production applications + <braunr> and for the matter at hand (system services not written in c), it + means almost readily getting runtimes for other languages than c + <braunr> something other microkernel based system will not have + <braunr> imagine this + <braunr> one day, one of us could create a company for a hurd-like system, + presenting this idea as the killer feature + <braunr> by supporting posix, customers could port their software with very + little effort + <braunr> *very little effort* is what makes software attractive + <crocket> + http://stackoverflow.com/questions/1806585/why-is-linux-called-a-monolithic-kernel/1806597#1806597 + says "The disadvantage to a microkernel is that asynchronous IPC + messaging can become very difficult to debug, especially if fibrils are + implemented." + <crocket> " GNU Hurd suffers from these debugging problems (reference)." + <braunr> stackoverflow is usually a nice place + <braunr> but concerning microkernel stuff, you'll read a lot of crap + anywhere + <braunr> whether it's sync or async, tracking references is a hard task + <braunr> it's a bit more difficult in distributed systems, but not that + much if the proper debugging features are provided + <braunr> we actually don't suffer from that too much + <braunr> many of us have been able to debug reference leaks in the past, + without too much trouble + <braunr> we lack some tools that would give us a better view of the system + state + <crocket> braunr, But is it more difficult with microkernel? + <braunr> crocket: it's more difficult with distributed systems + <crocket> How much more difficult? + <braunr> i don't know + <crocket> distributed systems + <braunr> not much + <crocket> braunr, How do you define distributed systems? + <braunr> crocket: not monolithic + <crocket> braunr, Hurd is distributed, then. + <braunr> multiserver if you prefer + <braunr> yes it is + <crocket> braunr, So it is more difficult with hurd. + <crocket> How much more difficult? How do you debug? + <braunr> just keep in mind that a monolithic system can run on a + microkenrel + <braunr> we use tools that show us references + <crocket> braunr, like? + <braunr> like portinfo + <crocket> braunr, Does hurd use unix-socket to implement IPC? + <braunr> no + <braunr> unix-socket use mach ipc + <crocket> I'm confused + <braunr> ipc is provided by the microkernel, gnumach (a variant of mach) + <braunr> unix sockets are provided by one of the hurd servers (pflocal) + <braunr> servers and clients communicate through mach ipc + <crocket> braunr, Do you think it's feasible to build servers in haskell? + <braunr> why not ? + <crocket> ok + <teythoon> I've been thinking about that + <teythoon> in go, with cgo, you can call go functions from c code + <teythoon> so it should be possible to create bindings for say libtrivfs + <crocket> I'd like to write an OS in clojure or haskell. + <braunr> crocket: what for ? + <crocket> braunr, I want to see a better system programming language than + C. + <braunr> i don't see how clojure or haskell would be "better system + programming languages" than c + <braunr> and even assuming that, what for ? + <crocket> braunr, It's better for programmers. + <crocket> haskell + <crocket> haskell is expressive. + <braunr> personally i disagree + <braunr> it's better for some things + <braunr> not for system programming + <gnufreex> For system programming, Google Go is trying to replace C. But I + doubt it will. + <braunr> we may not be referring to the same thing here when we say "system + programming" + <crocket> braunr, What do you think is a better one? + <braunr> crocket: i don't think there is a better one currently + <crocket> braunr, Even Rust and D? + <braunr> i don't know them well enough + <braunr> certainly not D if it's what i think it is + <crocket> C is too slow. + <crocket> C is too slow to develop. + <braunr> depends + <braunr> again, i disagree + <braunr> rust looks good but i don't know it well to comment + <crocket> C is a tank, and clojure is an airplane. + <crocket> A tank is reliable but slow. + <crocket> Clojure is fast but lacks some accuracy. + <braunr> c is as reliable as the developer is skilled with it + <braunr> it's clearly not a tank + <braunr> there are many traps + <gnufreex> crocket: are you suggesting to rewrite Hurd in Clojure? + <crocket> no + <crocket> Why rewrite hud? + <crocket> hurd + <crocket> I'd rather start from scratch. + <braunr> which is what a rewrite is + <gnufreex> I am not expert on Clojure, but I don't think it is made for + system programming. + <gnufreex> If you want alternate language, I thing Go is only serious + candidate other than C + <crocket> Or Rust + <crocket> However, some people wrote OSes in haskell. + <braunr> again, why ? + <braunr> if it's only for the sake of using another language, i think it's + bad reason + <crocket> Because haskell provides a high level of abstraction that helps + programmers. + <crocket> It is more secure with monads. + <gnufreex> If you want your OS to become successful Free Software project, + you have to use popular language. Haskell is not. + <gnufreex> Most Haskell programmers are not into kernels + <gnufreex> They do high level stuff. + <gnufreex> So little contributors. + <braunr> crocket: so you aim at security ? + <gnufreex> I mean, candidats for contribution + <crocket> braunr, security and higher abstraction. + <braunr> i don't understand higher abstraction + <crocket> braunr, FP can be useful to systems. + <braunr> FP ? + <neal> functional programming + <braunr> right + <braunr> but you can abstract a lot with c too, with more efforts + <crocket> braunr, like that's easy. + <braunr> it's not that hard + <braunr> i'm just questioning the goals and the solution of using a + particular language + <braunr> the reason c is still the preferred language for system + programming is because it provides control over how the hardware does + stuff + <braunr> which is very important for performance + <braunr> the hurd never took off because of bad performance + <braunr> performance doesn't mean doing things faster, it means being able + to do things or not, or doing things a new way + <braunr> so ok, great, you have your amazing file system written in + haskell, and you find out it doesn't scale at all beyond some threshold + of processors or memory + <crocket> braunr, L4 is fast. + <braunr> l4 is merely an architecture abstraction + <braunr> and it's not written in haskell :p + <braunr> don't assume anything running on top of something fast will be + fast + <crocket> Hurd is slow and written in C. + <braunr> yes + <braunr> not because of c though + <crocket> Becuase it's microkernel? + <braunr> because c wasn't used well enough to make the most of the hardware + in many places + <braunr> far too many places + <crocket> A microkernel can be as fast as a monolithic kernel according to + L4. + <braunr> no + <braunr> it can't + <braunr> it can for very specific cases + <braunr> almost none of which are real world + <braunr> but that's not the problem + <braunr> again, i'm questioning your choice of another language in relation + to your goals, that's all + <braunr> c can do things you really can't do easily in other languages + <braunr> be aware of that + <crocket> braunr, "Monolithic kernel are faster than microkernel . while + The first microkernel Mach is 50% slower than Monolithic kernel while + later version like L4 only 2% or 4% slower than the Monolithic kernel ." + <braunr> 14:05 < braunr> but concerning microkernel stuff, you'll read a + lot of crap anywhere + <braunr> simple counterexample : + <braunr> the measurements you're giving consider a bare l4 kernel with + nothing on top of it + <braunr> doing thread-to-thread ipc + <braunr> this model of communication is hardly used in any real world + application + <braunr> one of the huge features people look for with microkernels are + capabilities + <braunr> and that alone will bump your 4% up + <braunr> since capabilities will be used for practically every ipc + <crocket> ok + + +# Hurd From Scratch + +## IRC, freenode, #hurd, 2013-11-30 + + <hurdmaster> because I think there is no way to understand the whole pile, + you need to go step by step + <hurdmaster> for example, I'm starting with mach only, then adding one + server, then another and on each step I have working system + <hurdmaster> that's how I want to understand it + <teythoon> you are interested in the early bootstrapping of the hurd system + ? + <hurdmaster> now I'm starting debian gnu/mach, it hungs, show me black + screen and I have no idea how to fix it + <teythoon> if you are unable to fix this, why do you think you can build a + hurd system from scratch ? + <hurdmaster> not gnu/mach, gnu/hurd I mean + <teythoon> or, you could describe your problem in more detail and one of + the nice people around here might help you ;) + <hurdmaster> as I said, it will be easier to understand and fix bugs, if I + will go step by step, and I will be able to see where bugs appears + <hurdmaster> so you should help me with that + <teythoon> and I tend to disagree + <teythoon> but you could always read my blog. you'll learn lots of things + about bootstrapping a hurd system + <teythoon> but it's complicated + <hurdmaster> http://www.linuxfromscratch.org/ + <teythoon> also, you'll need at least four hurd servers before you'll + actually see much + <teythoon> five + <teythoon> yeah, i know lfs + <hurdmaster> if somebody is interested in creating such a project, let me + know + <teythoon> you seem to be interested + <hurdmaster> yes, but I need the a real hurd master to help me + <teythoon> become one. fix your system and get to know it + <hurdmaster> I need knowledge, somebody built the system but didn't write + documentation about it, I have to extract it from your heads + <teythoon> hurdmaster: extract something from here + http://teythoon.cryptobitch.de + <teythoon> I need my head ;) + <hurdmaster> thanks + <hurdmaster> okay, what's the smallest thing I can run? + <teythoon> life of a Hurd system starts with the root filesystem, and the + exec server is loaded but not started + <teythoon> you could get rid of the exec server and replace the root + filesystem with your own program + <teythoon> statically linked, uses no unix stuff, only mach stuff + <hurdmaster> can I get 'hello world' on pure mach? + <teythoon> you could + <teythoon> hurdmaster: actually, here it is: + http://darnassus.sceen.net/gitweb/rbraun/mach_print.git/ + <teythoon> compile it statically, put it somewhere in /boot + <teythoon> make sure you're running a debug kernel + <teythoon> load it from grub instead of /hurd/ext2fs.static + <teythoon> look at the grub config for how this is done + <teythoon> let me know if it worked ;) diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn index 8cd2415a..2913eea8 100644 --- a/open_issues/boehm_gc.mdwn +++ b/open_issues/boehm_gc.mdwn @@ -528,6 +528,12 @@ restults of GNU/Linux and GNU/Hurd look very similar. <congzhang> and maybe c# hello world translate another day :) +### IRC, freenode, #hurd, 2013-12-16 + + <braunr> gnu_srs: ah, libgc + <braunr> there are signal-related problems with libgc + + ## Leak Detection ### IRC, freenode, #hurd, 2013-10-17 diff --git a/open_issues/bpf.mdwn b/open_issues/bpf.mdwn index 02dc7f87..d051c2d8 100644 --- a/open_issues/bpf.mdwn +++ b/open_issues/bpf.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2012, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -593,3 +594,61 @@ In context of the [[select]] issue. <braunr> i understand now why my bpf translator was so buggy <braunr> the condition_timedwait i wrote at the time was .. incomplete :) + + +## IRC, freenode, #hurd, 2014-02-04 + + <teythoon> btw, why is there a bpf filter in gnumach ? + <teythoon> braunr: didn't you put it there ? + <braunr> teythoon: ah yes i did + <braunr> teythoon: i completed the work of a friend + <braunr> teythoon: the original filters in mach were netf filters + <braunr> teythoon: we added bpf so that libpcap could directly upload them + to the kernel + <braunr> in order to apply filters as close as possible to the packet + source and save copies + <teythoon> so they were used with the in-kernel network drivers ? + <braunr> only by experimental code and pfinet which sets a + receive-all-inet4/6 filter + <braunr> i also have a pcap-hurd.c file for libpcap but integration is a + bit tricky because of netdde + <braunr> maybe i could work on it again some day + <braunr> it should be easy to get into the debian package at least + <teythoon> so they can still be used with a netdde-based driver ? + <braunr> i'm not sure + <braunr> the pcap-hurd.c file i wrote uses the libpcap bpf filter + <teythoon> oh, ok, i misinterpreted what you said wrt netdde + <braunr> the problem caused by netdde is about where to get packets from, + but devnode should take care of that + <teythoon> did you mean that the integration is tricky b/c when netdde is + used, a different approach is necessary and that would have to be + detected at runtime ? + <braunr> something like that + <teythoon> right + <braunr> i didn't want to detect anything + <teythoon> right + <braunr> i was waiting for things to settle but netdde is still debian only + <braunr> but that's ok, this oculd be a debian only patch for now + <teythoon> so is eth-filter the netdde equivalent or am i getting a wrong + picture here ? + <braunr> i don't know + <teythoon> it seems to implement bpf filters as well + <braunr> it could very well be + <braunr> whatever the driver, pfinet must be able to install a filter + <braunr> even if it's almost a catch-all + <teythoon> i guess it could start a eth-filter and use this, why not + <braunr> sure + + +### IRC, freenode, #hurd, 2014-02-06 + + <antrik> teythoon: the BPF filter in Mach can also be used by + eth-multiplexer or eth-filter when running on in-kernel network + drivers... in fact the implementation was finished by the guy who created + eth-multiplexer; it was not fully working before + <antrik> it's not useful at all when using netdde I believe + <antrik> teythoon: IIRC eth-filted both relies on BPF being implemented by + the layer below it (whatever it is) to do the actual filtering, as well + as implements BPF itself so any layer on top of it can in turn use BPF + <antrik> netdde should provide BPF filters too I'd say... but don't + remember for sure diff --git a/open_issues/cannot_create__dev_null__interrupted_system_call.mdwn b/open_issues/cannot_create__dev_null__interrupted_system_call.mdwn new file mode 100644 index 00000000..b0f14a17 --- /dev/null +++ b/open_issues/cannot_create__dev_null__interrupted_system_call.mdwn @@ -0,0 +1,193 @@ +[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + + +# IRC, freenode, #hurd, 2013-12-05 + + <teythoon> Creating device nodes: fd fdX std vcs hdX hdXsY hdXs1Y sdX sdXsY + sdXs1Y cdX netdde ethX loopX ttyX ptyp ptyq/sbin/MAKEDEV: 75: + /sbin/MAKEDEV: cannot create /dev/null: Interrupted system call + <teythoon> that's new + <braunr> teythoon: ouch + <teythoon> braunr: everything works fine though + <braunr> teythoon: that part isn't too surprising + <teythoon> y? + <braunr> teythoon: /dev/null already existed, didn't it ? + <teythoon> braunr: sure, yes + + +## IRC, freenode, #hurd, 2013-12-19 + + <braunr> hm + <braunr> i'm seeing those /sbin/MAKEDEV: cannot create /dev/null: + Interrupted system call messages too + + +## IRC, freenode, #hurd, 2013-12-20 + + <teythoon> braunr: interesting, I've seen some of those as well + + +## IRC, freenode, #hurd, 2014-01-26 + + <gg0> cannot create /dev/null: Interrupted system call + <gg0> + http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/26/steps/system_upgrade/logs/stdio + + +## IRC, freenode, #hurd, 2014-01-27 + + <anatoly> gg0: I had same /dev/null error after upgrading my old image + (more than 6 months old) a week ago. But I got such message only on boot + and it didn't autostart hurd console. + <anatoly> Tried to upgrade current qemu image (from topic) to reproduce it + but it works OK after upgrade + <gg0> i can reproduce it with # apt-get install --reinstall python2.7 dbus + # for instance + <gg0> http://paste.debian.net/plain/78566/ + <teythoon> gg0: i've seen those as well, but i cannot reliably reproduce it + to track it down + <teythoon> i believe it's benign though + <gg0> in shell scripts if -e is set, it aborts on failures like those + <teythoon> uh, it does? :/ + <gg0> so if this happens in prerm/postinst scripts, package is not properly + installed/removed/configured and it fails + <gg0> redirecting stdout and strerr to /dev/null shouldn't be so + problematic, anything wrong in my setup? + <gg0> can you reproduce it? + <teythoon> not reliably + <teythoon> gg0: but i do not believe that anything is wrong with your + machine + <gg0> any way to debug it? + <teythoon> having a minimal test case that triggers this reliably would be + great + <teythoon> but i fear it might be a race + + +## IRC, freenode, #hurd, 2014-01-28 + + <teythoon> have you seen the /dev/null issue ? + <braunr> yes + <teythoon> what do you make of it ? + <braunr> no idea + <teythoon> i believe it is related to the inlining work i've done + <braunr> just like the bogus deallocation at boot, it needs debugging :) + <braunr> hm i don't think so + <teythoon> no ? + <braunr> i think we saw it even before your started working on the hurd ;p + <teythoon> i've never seen it before my recent patches + <teythoon> maybe i made it worse + <braunr> not worse, just exposed more + <teythoon> right + + +## IRC, freenode, #hurd, 2014-01-29 + + <gg0> cannot reproduce "cannot create /dev/null: Interrupted system call" + on a faster VM + <gg0> might depend on that? + + +## IRC, OFTC, #debian-hurd, 2014-02-02 + + <pere> but now saw a strange message at the end of the boot: + /etc/init.dhurd-console: 55: /etc/init.d/hurd-console: cannot create + /dev/null: Interrupted system call + <gg0> oh well known on a slow VM (even old qemu/kvm btw), i can't reproduce + it on a faster/more recent one + <gg0> slow VM = gnash buildbot slave + http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/26/steps/system_upgrade/logs/stdio + <gg0> especially bad on system upgrade because it doesn't finish to run + prerm/postinst scripts :/ + + +## IRC, freenode, #hurd, 2014-02-05 + + <gg0> Creating device nodes: fd fdX std vcs hdX hdXsY/sbin/MAKEDEV: 75: + /sbin/MAKEDEV: cannot create /dev/null: Interrupted system call hdXs1Y + sdX sdXsY sdXs1Y cdX netdde ethX loopX ttyX ptyp ptyq lprX comX random + urandom kbd mouse shm. + + +## IRC, freenode, #hurd, 2014-02-11 + + <gg0> typical dist-upgrade http://paste.debian.net/plain/81346/ + <gg0> many fewer cannot create /dev/null: Interrupted system call + <gg0> on a faster machine + <teythoon> gg0: wow, so many interrupted system call messages + <teythoon> i don't get as many, but makedev produces a few every time i run + it as well + + +## IRC, OFTC, #debian-hurd, 2014-02-16 + + <pere> anyone here got any idea why upgrading initscripts fail on the hurd + gnash autobuilder, as reported on <URL: + http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/28/steps/system_upgrade/logs/stdio + >? + <gg0> pere: cannot create /dev/null: Interrupted system call + <pere> gg0: I noticed the message, but fail to understand how this could + happen. + <gg0> 13:16 < gg0> oh well known on a slow VM (even old qemu/kvm btw), i + can't reproduce it on a faster/more recent one + <gg0> 13:17 < gg0> slow VM = gnash buildbot slave + http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/26/steps/system_upgrade/logs/stdio + <gg0> 13:18 < gg0> especially bad on system upgrade because it doesn't + finish to run prerm/postinst scripts :/ + <gg0> i remember teythoon talking about something racy + <teythoon> gg0: the /dev/null issue is known for a long time + <teythoon> gg0: some of the recent work (i believe mine) has made the + problem more apparent + <teythoon> gg0: that's what braunr told me + <gg0> i see. it would be really nice fixing it. really annoying. i + workaround it by moving null away and moving it back under /dev before + halting/rebooting + + +## IRC, freenode, #hurd, 2014-02-17 + + <tschwinge> Earlier today, I upgraded my Debian GNU/Hurd installation from + several months ago, and I'm now seeing bogus things as follows; is that a + known issue? + <tschwinge> checking for i686-unknown-gnu0.5-ar... ar + <tschwinge> configure: updating cache ./config.cache + <tschwinge> configure: creating ./config.status + <tschwinge> +./config.status: 299: ./config.status: cannot create + /dev/null: Interrupted system call + <tschwinge> config.status: creating Makefile + <tschwinge> (The plus is from a build log diff.) + <azeem> 13:36 < gg0> pere: cannot create /dev/null: Interrupted system call + <azeem> 20:10 < teythoon> gg0: the /dev/null issue is known for a long time + <tschwinge> Anyone working on resolving this? I't causing build issues: + <tschwinge> checking for i686-unknown-gnu0.5-ranlib... (cached) ranlib + <tschwinge> checking command to parse nm output from gcc-4.8 + object... [...]/opcodes/configure: 6760: ./configure.lineno: cannot + create /dev/null: Interrupted system call + <tschwinge> failed + <tschwinge> checking for dlfcn.h... yes + <tschwinge> Anyway, will go researching IRC logs. + <azeem> tschwinge: (that one was from #debian-hurd) + <azeem> I assume teythoon and/or braunr can comment once he's back + <azeem> they're* + <braunr> tschwinge: we've been seing this more often lately but noone has + attempted to fix it yet + <braunr> tschwinge: if you have a reliable way to reproduce that /dev/null: + Interrupted system call error, please let us know + + +## IRC, freenode, #hurd, 2014-02-23 + + <gg0> braunr: cool. i'd vote /dev/null one as next one in your todo + <gg0> still frequent on this slow vm + http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/30/steps/system_upgrade/logs/stdio + <gg0> especially during setup-translators -k + <braunr> yes diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index 65ab52df..baa21bbb 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.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 @@ -158,6 +159,9 @@ In context of [[select]]. <braunr> my brain can't correctly compute variable sized types in mig definition files <braunr> i wanted something that would remain correct for the 64-bit port + +[[64-bit_port]], [[mig_portable_rpc_declarations]]. + <youpi> ah, you mean because tv_nsec is a long, which will not be the same type? <braunr> and tv_sec being a time_t (thus a long too) @@ -208,3 +212,129 @@ In context of [[select]]. # Candidate for [[vDSO]] code? + + +# IRC, freenode, #hurd, 2014-02-23 + + <desrt> GLib (gthread-posix.c): Unexpected error from C library during + 'pthread_condattr_setclock': Invalid argument. Aborting. + <desrt> uh oh... + <desrt> time to go digging in glibc i guess... + <braunr> what are you trying to run ? + <desrt> glib + <braunr> with what ? + <desrt> just running glib's test suite under jhbuild + <desrt> i maintain glib and i made some changes recently -- i wanted to + make sure they didn't break the hurd + <desrt> and it seems they have ;/ + <braunr> well + <braunr> the hurd doesn't completely comply with posix 2008 + <desrt> long story short: we've keyed our timed waits on condition + variables to the monotonic clock for a long time now, but we never tested + that it actually worked + <desrt> so i just added an assert -- and indeed it fails on hurd + <braunr> our glibc lies about supporting timers + <braunr> good thinking + <braunr> we don't support the monotonic clock + <desrt> clock_gettime(CLOCK_MONOTONIC) seems to work + <braunr> and you should know that, even if clock selection and timers are + available (which posix 2008 requires), it's still optional + <braunr> no, glibc lies + <desrt> !! + <braunr> our "support" is a mere hack shifting CLOCK_REALTIME + <desrt> it should at least lie consistently :) + <braunr> we need to implement CLOCK_MONOTONIC properly + <desrt> ya... that would be very nice indeed + <braunr> not that hard either + <desrt> i agree! + <braunr> we just have to do it right + <desrt> fwiw, i plan to keep this assert in glib + <braunr> yes, it's good + <desrt> is there anywhere i can file a bug to give you guys some advance + warning? + <braunr> i don't think it's needed + <braunr> we know the problem + <desrt> k -- consider yourself warned, then :) + <braunr> and it's been a bigger concern recently + <desrt> awesome. glad i don't have to do anything :) + <braunr> if it's not already done, i suggest you check for the + CLOCK_MONOTONIC option + <desrt> fwiw, i'm trying to get a regular debian/gnu/hurd build of + glib/gtk/etc setup + <braunr> regular ? + <desrt> ya... out of git master on a daily basis + <braunr> from sources ? + <braunr> oh nice + <desrt> we recently set this up for freebsd as well + <braunr> few maintainers take the pain :) + <desrt> our non-linux 'problem discovery' is a bit crap before now :/ + <braunr> i guess that's pretty normal + <braunr> i don't consider it the responsibility of the maintainers to test + every possible platform + <desrt> glib is a bit unique -- portability is our business + <braunr> taking our patches into consideration is what we ask most + <braunr> right + <desrt> and the "please take the patches" thing is something we want to + stop doing + <braunr> why ? + <desrt> mostly because we often look at a patch that someone sent a few + years ago and say "do we even still need this?" + <desrt> and have no way to know + <braunr> uh + <desrt> you would not believe how many patches like this we've + accumulated... + <braunr> but if we send it now ? :) + <desrt> braunr: new policy is roughly this: + https://wiki.gnome.org/Projects/GLib/SupportedPlatforms + <desrt> ie: fixes for issues that are general portability improvements and + POSIX compliance are welcome... + <desrt> patches that introduce platform-specific #ifdef sections are + rejected unless we have a regular builder to test that code + <braunr> i see + <braunr> again, regarding portability, don't consider CLOCK_MONOTONIC to be + readily available, check for it + <braunr> an #error would be enough but it has to be checked + <desrt> it basically comes down to: we don't want to have code in our + version control that we have no possible way of testing + <braunr> yes + <desrt> braunr: we do check for it + <braunr> ok + <desrt> we assert() if clock_gettime(CLOCK_MONOTONIC) fails + <braunr> no i mean + <desrt> as POSIX said it should if CLOCK_MONOTONIC is not supported + <desrt> if you lie to us.... well, not much we can do + <braunr> POSIX_MONOTONIC_CLOCK + <braunr> _POSIX_MONOTONIC_CLOCK + <desrt> this is actually defined to 0 on most platforms... + <desrt> which does not mean that it's unsupported -- it means that the + runtime must be ready to deal with it not actually existing at runtime + <braunr> really ? + <desrt> yes + <desrt> we used to rely on this and got a bug that we were doing it wrong + :) + <desrt> and indeed, even on linux, both with glibc and uclibc: + <desrt> /usr/include/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK + 0 + <desrt> /usr/include/uClibc/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK + 0 + <braunr> ok it's described in 2.1.6 Options + <braunr> so your check is appropriate + <desrt> so does clock_gettime(MONOTONIC) on debian/hurd get me realtime? + <braunr> either that, or a value shifted from it + <desrt> if so, i'll just hack out the condattr_setclock() check and proceed + trying to build past glib... + * desrt checks + <desrt> as it is, even the build of glib fails since we use some tools + linked against ourselves during the build process... + <desrt> 1393124084790000 1393124084790000 + <desrt> those look the same.... + <braunr> heh + <desrt> i also notice that your clocks are not very high precision :) + <braunr> that's right + <desrt> HZ = 100, i guess + <braunr> yes + <desrt> fair enough + <desrt> our mainloop doesn't support better-than-millisecond accuracy yet + anyway :) + <desrt> (although it will soon...) + <braunr> nice diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn index 67798c6a..d61d5921 100644 --- a/open_issues/code_analysis.mdwn +++ b/open_issues/code_analysis.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 @@ -87,8 +87,70 @@ There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks. * [Frama-C](http://frama-c.com/) + <teythoon> btw, I've been looking at http://frama-c.com/ lately + <teythoon> it's a theorem prover for c/c++ + <braunr> oh nice + <teythoon> I think it's most impressive, it works on the hurd (aptitude + install frama-c o_O) + <teythoon> *and it works + <braunr> "Simple things should be simple, + <braunr> complex things should be possible." + <braunr> :) + <braunr> looks great + <teythoon> even the gui is awesome, allows one to browse source code in + a very impressive way + <braunr> clear separation between value changes, dependencies, side + effects + <braunr> we could have plugins for stuff like ports + <braunr> handles concurrency oO + <nalaginrut> so you want to use Frame-C to analyze the whole Hurd code + base? + <teythoon> nalaginrut: well, frama-c looks "able" to assist in + analyzing the Hurd, yes + <teythoon> nalaginrut: but theorem proving is a manual process, one + needs to guide the prover + <teythoon> nalaginrut: b/c some stuff is not decideable + <nalaginrut> I ask this because I can imagine how to analyze Linux + since all the code is in a directory. But Hurd's codes are + distributed to many other projects + <braunr> that's not a problem + <braunr> each server can be analyzed separately + <teythoon> braunr: also, each "entry point" + <nalaginrut> alright, but sounds a big work + <teythoon> it is + <braunr> otherwise, formal verification would be widespread :) + <teythoon> that, and most tools are horrible to use, frama-c is really + an exception in this regard + * [Coverity](http://www.coverity.com/) (nonfree?) + * IRC, OFTC, #debian-hurd, 2014-02-03 + + <pere> btw, did you consider adding hurd and mach to <URL: + https://scan.coverity.com/ > to detect bugs automatically? + <pere> I found lots of bugs in gnash, ipmitool and sysvinit when I + started scanning those projects. :) + <teythoon> i did some static analysis work, i haven't used coverty + but free tools for that + <teythoon> i think thomas wanted to look into coverty though + <pere> quite easy to set up, but you need to download and run a + non-free tarball on the build host. + <teythoon> does that tar ball contains binary code ? + <teythoon> that'd be a show stopper for the hurd of course + <pere> did not investigate. I just put it in a contained virtual + machine. + <pere> did not want it on my laptop. :) + <pere> prefer free software here. :) + <pere> but I did not have to "accept license", at least. :) + + * IRC, OFTC, #debian-hurd, 2014-02-05 + + <pere> ah, cool. <URL: https://scan.coverity.com/projects/1307 > + is now in place. :) + + [[microkernel/mach/gnumach/projects/clean_up_the_code]], + *Code_Analysis, Coverity*. + * [Splint](http://www.splint.org/) * IRC, freenode, #hurd, 2011-12-04 diff --git a/open_issues/code_analysis/discussion.mdwn b/open_issues/code_analysis/discussion.mdwn index 4cb03293..45126b91 100644 --- a/open_issues/code_analysis/discussion.mdwn +++ b/open_issues/code_analysis/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 @@ -100,6 +100,146 @@ License|/fdl]]."]]"""]] https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build-2/ +### IRC, freenode, #hurd, 2013-11-04 + + <teythoon> btw, why does the nested functions stuff needs the executable + stack? for trampolines? + <braunr> yes + <teythoon> I didn't even realize that, that's one more reason to avoid them + indeed + + <teythoon> braunr: kern/slab.c (1471): vm_size_t info_size = info_size; + <braunr> yes ? + <teythoon> braunr: what's up with that? + <braunr> that's one way to silence gcc warnings about uninitialized + variables + <braunr> this warning can easily result in false positives when gcc is + unable to determine dependencies + <braunr> e.g. if (flag & FLAG_CREATE) myvar = create(); ...; ... if (flag & + FLAG_CREATE) use(myvar) + <teythoon> well, ok, that's a shortcomming of gcc + <teythoon> braunr: your way of silencing that in gcc still shows up in + scan-build and most likely any more advanced analysis tool + <teythoon> as it should of course, but it is noisy + <braunr> teythoon: there is a gcc attribute for that + <braunr> __attribute__((unused)) + <braunr> analysis tools might know that better + <teythoon> braunr: could you have a quick look at + http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-mXqstT.html#EndPath + ? + <braunr> nice + <braunr> anything else on the rbtree code ? + <teythoon> well + <teythoon> + http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-LyiOO1.html#EndPath + <teythoon> but this is of length 18, so it might be far-fetched + <braunr> ?? + <teythoon> the length of the chain of argumentation + <braunr> i don't understand that issue + <braunr> isn't 18 the analysis step ? + <teythoon> well, the greater the length, the more assumption the tool + makes, the more likely it is that it just does not "get" some invariant + <braunr> probably yes + <braunr> the code can segfault if input parameters are invalid + <braunr> that's expected + <teythoon> right, looks like this only happens if the tree is invalid + <teythoon> if in line 349 brother->children[right] is NULL + <teythoon> this is a very good target for verification using frama-c + <braunr> :) + <teythoon> the code already has many assertions that will be picked up by + it automatically + <teythoon> so what about the dead store, is it a bug or is it harmless ? + <braunr> harmless probably + <braunr> certainly + <braunr> a simple overlook when polishing + + +### IRC, freenode, #hurd, 2014-01-16 + + <mcsim> braunr: hi. Once, when I wrote a lot if inline gcc functions in + kernel you said me not to use them. And one of the arguments was that you + want to know which binary will be produced. Do you remember that? + <braunr> not exactly + <braunr> it seems likely that i advice not to use many inline functions + <braunr> but i don't see myself stating such a reason + <mcsim> braunr: ok + <mcsim> so, what do you think about using some high level primitives in + kernel + <mcsim> like inline-functions + <mcsim> ? + <braunr> "high level primitives" ? + <braunr> you mean switching big and important functions into inline code ? + <mcsim> braunr: something that is hard to translate in assembly directly + <mcsim> braunr: I mean in general + <braunr> i think it's bad habit + <mcsim> braunr: why? + <braunr> don't inline anything at first, then profile, then inline if + function calls really are a bottleneck + <mcsim> my argument would be that it makes code more readable + <braunr> https://www.kernel.org/doc/Documentation/CodingStyle <= see the + "inline disease" + <braunr> uh + <braunr> more readable ? + <braunr> the only difference is an inline keyword + <mcsim> sorry + <mcsim> i confused with functions that you declare inside functions + <mcsim> nested + <mcsim> forgot the word + <mcsim> sorry + <braunr> ah nested + <braunr> my main argument against nested functions is that they're not + standard and hard to support for non-gcc tools + <braunr> another argument was that it required an executable stack but + there is apparently a way to reliably make nested functions without this + requirement + <braunr> so, at the language level, they bring nice closures + <braunr> the problem for me is at the machine level + <braunr> i don't know them well so i'm unable to predict the kind of code + they generate + <braunr> but i guess anyone who would take the time to study their + internals would be able to do that + <mcsim> and why this last argument is important? + <braunr> because machine code runs on machines + <braunr> one shouldn't ignore the end result .. + <braunr> if you don't know the implications of what you're doing precisely, + you loose control over the result + <braunr> if you can trust the tool, fine + <kilobug> mcsim: in general, when you use something you don't really + understand how it works internally, you've a much higher risk of making + bugs or inefficient code because you just didn't realize it couldn't work + or would be inefficient + <braunr> but in the case of a kernel, it often happens that you can't, or + at least not in a straightforward way + <braunr> s/loose/lose/ + <mcsim> kilobug: and that's why for kernel programming you try to use the + most straightforward primitives as possible? + <braunr> no + <kilobug> mcsim: not necessarily the most straightforward ones, but ones + you understand well + <braunr> keeping things simple is a way to keep control complexity in any + software + <braunr> as long as you understand, and decouple complicated things apart, + you can keep things simple + <braunr> nested functions doesn't have to do with complexity + <braunr> don't* + <braunr> it's just that, since they're not standard and commonly used + outside gnu projects, they're not well known + <braunr> i don't "master" them + <teythoon> also, they decouple the data flow from the control flow + <teythoon> which in my book is bad for imparative languages + <teythoon> and support for them in tools like gdb is poor + <mcsim> braunr: I remembered nested functions because now I use C++ and I + question myself if I may use all these C++ facilities, like lambdas, + complicated templates and other stuff. + <mcsim> kilobug: And using only things that you understand well sounds + straightforward and logical + <braunr> that's why i don't write c++ code :) + <braunr> it's very complicated and requires a lot of effort for the + developer to actually master it + <braunr> mcsim: you can use those features, but sparsely, when they really + do bring something useful + + # Leak Detection See *Leak Detection* on [[boehm_gc]]. diff --git a/open_issues/crash_server.mdwn b/open_issues/crash_server.mdwn index 5182df6f..3d656082 100644 --- a/open_issues/crash_server.mdwn +++ b/open_issues/crash_server.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2010, 2011, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2009, 2010, 2011, 2013, 2014 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -248,6 +248,22 @@ one... <tschwinge> rekado: In case that's still helpful: <http://www.gnu.org/software/hurd/hurd/debugging/translator.html>. + +# IRC, freenode, #hurd, 2013-12-14 + + <gnu_srs> How to get a core dump? + <teythoon> either set CRASHSERVER to /servers/crash-dump-core for the + process you want the core file of + <teythoon> or make /servers/crash point to crash-dump-core to make this the + default for all processes + <gnu_srs> does it work now, it did not before? + <teythoon> it does for me, never had issues + <gnu_srs> k! + <teythoon> well, i believe the second option has issues + <teythoon> if two processes crash, both may write/create a file in the same + location + + --- If someone is working in this area, they may want to have a look at diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn index 4473fba0..b3bebf48 100644 --- a/open_issues/dbus.mdwn +++ b/open_issues/dbus.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 @@ -365,3 +365,138 @@ See [[glibc]], *Missing interfaces, amongst many more*, *`SOCK_CLOEXEC`*. <braunr> anyway <braunr> how do you plan to implement credential checking ? <gnu_srs> I'll mail patches RSN + + +# IRC, freenode, #hurd, 2013-11-03 + + <gnu_srs> Finally, SCM_CREDS (IDs) works:) I was on the right track all the + time, it was just a small misunderstanding. + <gnu_srs> remains to solve the PID check + <youpi> gnu_srs: it should be a matter of adding + proc_user/server_authenticate + <gnu_srs> there are no proc_user/server_authenticate RPCs? + <gnu_srs> do you mean adding them to process.defs (and implement them)? + <youpi> gnu_srs: I mean that, yes + + +# IRC, freenode, #hurd, 2013-11-13 + + <gnu_srs> BTW: I have to modify the SCM_RIGHTS patch to work together with + SCM_CREDS, OK? + <youpi> probably + <youpi> depends on what you change of course + + +# IRC, freenode, #hurd, 2013-11-15 + + <gnu_srs> Hi, any ideas where this originates, gdb? warning: Error setting + exception port for process 9070: (ipc/send) invalid destination port + <braunr> gnu_srs: what's process 9070 ? + <gnu_srs> braunr: It's a test program for sending credentials over a + socket. Have to create a reproducible case, it's intermittent. + <gnu_srs> The error happens when running through gdb and the sending + program is chrooted: + <gnu_srs> -rwsr-sr-x 1 root root 21156 Nov 15 15:12 + scm_rights+creds_send.chroot + + +## IRC, freenode, #hurd, 2013-11-16 + + <gnu_srs> Hi, I have a problem debugging a suid program, see + http://paste.debian.net/66171/ + <gnu_srs> I think this reveals a gnumach/hurd bug, it makes things behave + strangely for other programs. + <gnu_srs> How to get further on with this? + <gnu_srs> Or can't I debug a suid program as non-root? + <pochu> gnu_srs: if gdb doesn't work for setuid programs on hurd, I suppose + you could chmod -s the binary you're trying to debug, login as root and + run it under gdb + <gnu_srs> pochu: When logged in as root the program works, independent of + the s flag setting. + <pochu> right, probably the setuid has no effect in that case because your + effective uid is already fine + <pochu> so you don't hit the gdb bug in that case + <pochu> (just guessing) + <gnu_srs> It doesn't work in Linux either, so it might be futile. + <gnu_srs> trying + <pochu> hmm that may be the expected behaviour. after all, gdb needs to be + priviledged to debug priviledged processes + <gnu_srs> Problem is that it was just the suid properties I wanted to + test:( + <braunr> gnu_srs: imagine if you could just alter the code or data of any + suid program just because you're debugging it + + +## IRC, freenode, #hurd, 2013-11-18 + + <gnu_srs> Hi, is the code path different for a suid program compared to run + as root? + <gnu_srs> Combined with LD_PRELOAD? + <teythoon> gnu_srs: afaik LD_PRELOAD is ignored by suid programs for + obvious security reasons + <gnu_srs> aha, thanks:-/ + <braunr> gnu_srs: what's your problem with suid ? + <gnu_srs> I made changes to libc and tried them out with + LD_PRELOAD=... test_progam. It worked as any user (including root), + <gnu_srs> but not with suid settings. Justus explained why not. + <braunr> well i did too + <braunr> but is that all ? + <braunr> i mean, why did you test with suid programs in the first place ? + <gnu_srs> to get different euid and egid numbers + + <gnu_srs> hi, anybody seen this with eglibc-2.17-96: locale: relocation + error: locale: symbol errno, + <gnu_srs> version GLIBC_PRIVATE not defined in file libc.so.0.3 with link + time reference + <teythoon> yes, I have + <teythoon> but afaics nothing did break, so I ignored it + + +## IRC, freenode, #hurd, 2013-11-23 + + <gnu_srs> Finally 8-) + <gnu_srs> Good news: soon both SCM_CREDS _and_ SCM_RIGHTS is supported + jointly. RFCs will be sent soon. + + +## IRC, freenode, #hurd, 2013-12-05 + + <gnu_srs> I have a problem with the SCM_CREDS patch and dbus. gamin and my + test code runs fine. + <gnu_srs> the problem with the dbus code is that it won't work well with + <gnu_srs> auth_user_authenticate in sendmsg and auth_server_authenticate in + recvmsg. + <gnu_srs> Should I try to modify the dbus code to make it work? + <youpi> unless you manage to prove that dbus is not following the posix + standard, there is no reason why you should have to modify dbus + <gnu_srs> I think the implementation is correct, + <gnu_srs> but auth_user_authenticate hangs sendmsg until + auth_seerver_authenticate is executed in recvmsg. + <gnu_srs> and dbus is not doing that, so it hangs in sendmsg writing a + credentials byte. + <gnu_srs> well the credentials byte is definitely non-posix. + <gnu_srs> I found a bug related to the HURD_DPORT_USE macro too:-( + <youpi> ah, yes, auth_user_authenticate might be synchronous indeed, let me + think about it + <gnu_srs> Nevertheless, I think it's time to publish the code so it can be + commented on:-D + <youpi> sure + <youpi> publish early, publish often + + +# IRC, freenode, #hurd, 2014-01-17 + + <gnu_srs> youpi: as a start all our requested dbus changes are now + committed, and in Debian unstable + <youpi> good :) + + +# IRC, freenode, #hurd, 2014-01-30 + + <pochu> dbus has some known problems + <pere> known fixes too? + <pochu> http://www.gnu.org/software/hurd/open_issues/dbus.html + <gnu_srs> pochu: Maybe that page should be updated: + http://lists.nongnu.org/archive/html/bug-hurd/2013-12/msg00150.html + <youpi> gnu_srs: well, maybe you can do it : + <youpi> ) diff --git a/open_issues/dbus_in_linux_kernel.mdwn b/open_issues/dbus_in_linux_kernel.mdwn index caf47711..6f83db03 100644 --- a/open_issues/dbus_in_linux_kernel.mdwn +++ b/open_issues/dbus_in_linux_kernel.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -74,3 +75,90 @@ Might be interesting to watch how this develops. [AF_BUS, D-Bus, and the Linux kernel](http://www.kroah.com/log/linux/af_bus.html), Greg Kroah-Hartman, 2013-02-08. + + +# kdbus + + +## IRC, freenode, #hurd, 2014-01-28 + + <braunr> i would like to see things like dbus and zeromq use an optimized + microkernel transport one day + <teythoon> we could port kdbus >,< + <braunr> why not + <braunr> you port cgroups first + <teythoon> exactly + <braunr> :p + +[[systemd]]. + + +## IRC, freenode, #hurd, 2014-02-23 + +In context of [[linux_as_the_kernel]], *IRC, freenode, #hurd, 2014-02-23*. + + <desrt> mach seems like this really simple thing when you first explain + what a microkernel is + <braunr> and because of that, i think it's better to start the right + solution directly + <braunr> it looks simple, it's clearly not + <desrt> but i did a bit of looking into it... it's a bit non-trivial after + all :) + <braunr> mach ipc is over complicated and error prone + <braunr> it leads to unefficient communication compared to other solutions + such as what l4 does + <desrt> ya -- i hear that this is a big part of the performance hit + <braunr> that's why i've started x15 + <desrt> i was also doing some reading about how it's based on mapping + memory segments between processes + <braunr> first, it was a mach clone, but since i've come to know mach + better, it's now a "spiritual" mach successor .. :) + <desrt> these are two issues that we've been dealing with at another + level... in the design of kdbus + <braunr> ah kdbus :) + <desrt> this is something that started with my masters thesis a long time + ago... + <braunr> ah you too + <desrt> first thing we did is make the serialisation format so that all + messages are valid and therefore never need to be checked + <desrt> (old dbus format requires checks at every step on the way) + <braunr> looks interesting + <desrt> then of course we cut the daemon out + <desrt> but some other interesting things: security is super-simple... it's + based enirely on endpoints + <desrt> either you're allowed to send messages between two processes or + you're not + <desrt> there is no checking for message types, for example + <braunr> yes + <desrt> and the other thing: memory mapping is usually bad + <braunr> that's what i mean when i say mach ipc is over complicated + <braunr> it depends + <desrt> the kdbus guys did some performance testing and found out that if + the message is less than ~512k then the cost of invalidating the TLB in + order to change the memory mapping is higher than the cost of just + copying the data + <braunr> yes, we know that too + <braunr> that's why zero copy isn't the normal way of passing small amounts + of data over mach either + <desrt> nice + <desrt> i got the impression in some of my reading (wikipedia, honestly) + that memory mapping was being done all the time + <braunr> well + <braunr> no it's not + <braunr> memory mapping is unfortunately a small fraction of the + performance overhead + <desrt> that's good :) + <braunr> that being said + <braunr> memory mapping can be very useful + <braunr> for example, it's hard for us to comply with posix requirements of + being able to read/write at least 2G of data in a single call + <braunr> weird bugs occur beyond 512M iirc + <braunr> you do want memory mapping for that + <desrt> ya... for things of this size.... you don't want to copy that + through a socket :) + <braunr> monolithic kernels have it naturally, since the kernel is mapped + everywhere + <braunr> for microkernels, it's a little more complicated + <braunr> and the problem gets worse on smp + <braunr> again, that's why i preferred starting a new kernel instead of + reusing linux diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn index fe9fd8aa..9d8bf509 100644 --- a/open_issues/dde.mdwn +++ b/open_issues/dde.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 @@ -579,6 +579,41 @@ In context of [[libpthread]]. <braunr> (well high, 4 MiB/s or more) +## IRC, freenode, #hurd, 2013-11-20 + + <braunr> for example, netdde needs more reviewing and polishing + <braunr> it is known to deadlock sometimes + <teythoon> what deadlocks ? + <braunr> i'm not sure + <teythoon> ah, netdde + <teythoon> right + <braunr> yes + <teythoon> I'm seeing that to on one of my vms + <teythoon> nasty one + <braunr> i know something is wrong with the condition_wait_timeout function + for example + <teythoon> breaks sysvinit shutdown + <braunr> because it was taken without modification from libpthread + <braunr> it might be that, or something else + <teythoon> well, dhclient hangs releasing the lease + <braunr> that's still on my todo list + <teythoon> so I'm pretty sure it's related + <braunr> hm + <braunr> maybe + <braunr> :/ + + +## IRC, freenode, #hurd, 2014-02-11 + + <braunr> teythoon: looks like a netdde/pfinet freeze/deadlock + <braunr> yes a netdde deadlock + <braunr> i really have to fix that too one day :( + <teythoon> hehe :) + <braunr> the netdde locking privimites are copies of the "old" pthread + ones, instead of reusing pthread + <braunr> primitives* + + # IRC, freenode, #hurd, 2012-08-18 <braunr> hm looks like if netdde crashes, the kernel doesn't handle it @@ -602,4 +637,15 @@ In context of [[libpthread]]. partitions/media... +## IRC, freenode, #hurd, 2013-12-03 + + <gg0> how about porting linux block device layer via dde as mcsim wanted to + do? then all linux filesystems could be brought in, right? + <braunr> gg0: that should be done, but we need to correctly deal with + multiple pci devices in userspace and arbitration + <kilobug> wouldn't adding support to passive translator into Linux + filesystems be quite some work ? IIRC ext2fs needs a special "owner = + hurd" mode to handle them + + # [[virtio]] diff --git a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn index 3faa56fc..7b300ea1 100644 --- a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn +++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010, 2011, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -144,3 +144,61 @@ See also discussion about *multiboot* on [[arm_port]]. <kilobug> matlea01: you need something with multiboot support (like grub) to provide the various bootstrap modules to the kernel <matlea01> Ah, I see + + +## IRC, freenode, #hurd, 2014-02-24 + + <congzhang> hi, will grub load mach kernel to fix address? and which + address? + <congzhang> I want to use qemu gdb support to debug mach + <congzhang> need add-symble-file to right address + <youpi> congzhang: see objdump gnumach + <youpi> grub simply follows what's provided by the ELF format of the ELF + file + <nalaginrut> I think it's default value of _start in ELF, right? + <nalaginrut> hmm...the actual entry point should plus the size of + multi_boot header, at least 0xc... + <congzhang> youpi: I try that, but not works + <congzhang> I start qemu with -s + <congzhang> the /bin/console was very easy to cause black death, and I want + to use gdb to check whether the mach is death + <congzhang> I will try again later + <congzhang> Anyone know some tutorial to debug mach with qemu? + <nalaginrut> for better debug, I suggest bochs + <nalaginrut> although it's slower + <congzhang> nalaginrut: maybe it's my problem, I did not do the right thing + <congzhang> qemu with kvm was great. + <nalaginrut> qemu with kvm is cool to run, but not so cool for debug kernel + <nalaginrut> anyway, it's personal taste + <nalaginrut> you may use gdb for that + <nalaginrut> for bochs, you don't have to use external debugger + <congzhang> thanks for explain + <congzhang> does anyone succeed boot hurd with qemu multiboot boot + function? + <congzhang> with -kernel and -initrd command line parameter + <nalaginrut> I boot it with grub, in qemu, it's fine. Then I moved to + physical machine + <congzhang> boot with grub work for me too + <congzhang> I want to know whether it is possible to boot from qemu + directly + <congzhang> qemu can directly load kernel and hurd module for linux + <congzhang> nalaginrut: can you help to test whether hurd-console service + start will cause hurd black death? + <nalaginrut> I know qemu can boot Linux without MBR, but I don't know if + it's true for Hurd too + <nalaginrut> congzhang: I'm busy for other works now ;-) + <congzhang> ok, thks:) + <youpi> qemu's multiboot options don't seem to allow providing + ext2fs.static and ld.so, so I don't think it's possible + <congzhang> I try to do this, because hurd hurd-console cause system to + death very high frequency + <youpi> (because qemu doesn't implement all of multiboot) + <congzhang> qemu help show that's possible, -initrd support multi module + and parameter + <congzhang> en, I will check with them later + <youpi> how do you pass parameters to modules? + <youpi> ah, right, it's after the file name + <youpi> well, then simply try to pass the kernel, and the two modules + <youpi> with the same option as in the grub config templates + <youpi> it's fortunate that neither ext2fs nor exec need a comma on their + command line... diff --git a/open_issues/default_pager.mdwn b/open_issues/default_pager.mdwn index 9a8e9412..38c9a2be 100644 --- a/open_issues/default_pager.mdwn +++ b/open_issues/default_pager.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -35,3 +36,9 @@ License|/fdl]]."]]"""]] # [[trust_the_behavior_of_translators]] + + +# IRC, freenode, #hurd, 2013-10-30 + + <braunr> it also seems that the kernel has trouble resuming processes that + have been swapped out diff --git a/open_issues/ext2fs_libports_reference_counting_assertion.mdwn b/open_issues/ext2fs_libports_reference_counting_assertion.mdwn index 9ff43afa..2b9f28e8 100644 --- a/open_issues/ext2fs_libports_reference_counting_assertion.mdwn +++ b/open_issues/ext2fs_libports_reference_counting_assertion.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,9 @@ With that patch in place, the assertion failure is seen more often. <braunr> if this erases the thread-specific area, we can expect all kinds of wreckage <braunr> i'm not sure how to fix this though + + +# IRC, freenode, #hurd, 2014-01-29 + + <gg0> ext2fs: ../../libports/port-ref.c:30: ports_port_ref: Assertion + `pi->refcnt || pi->weakrefcnt' failed. diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn index 2b772cfc..6c14fdd4 100644 --- a/open_issues/gcc.mdwn +++ b/open_issues/gcc.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013 Free -Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 +Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -303,6 +303,47 @@ Last reviewed up to the [[Git mirror's 3a930d3fc68785662f5f3f4af02474cb21a62056 * [`-fsplit-stack`](http://nickclifton.livejournal.com/6889.html) + IRC, freenode, #hurd, 2014-01-10: + + <gnu_srs1> Hi, I assume gcc -fsplit-stack is not yet supported? + <braunr> gnu_srs1: + https://lists.gnu.org/archive/html/bug-hurd/2013-06/msg00100.html + <gnu_srs1> braunr: That's exactly where the problem is: + src/libgcc/generic-morestack.c:814:__morestack_load_mmap + <gnu_srs1> no return value recorded + <gnu_srs1> creating a call: page = mmap ((void*)0x0, 0, 4, 2, -1, 0);, + returning EINVAL + <braunr> lenght of 0 ? + <gnu_srs1> yes, __morestack_current_segment, is zero + <braunr> mmap is expected to return einval if the requested mapping has + a size of 0 .. + <braunr> i don't know what split stack is, but i remember it's a + problem for the hurd + <gnu_srs1> sorry, the address is zero from the above, and the length in + the call is zero too + <braunr> yes that's what i understood + <braunr> and i'm telling you it's normal + <braunr> the size is invalid + <gnu_srs1> libgcc/generic-morestack.c: mmap + (__morestack_current_segment, 0, PROT_READ, MAP_ANONYMOUS, -1, 0); + <braunr> well this is wrong + <gnu_srs1> and the error code stays, not being reset in subsequent + calls + <gnu_srs1> causing an error later on + <braunr> as roland says in + https://lists.gnu.org/archive/html/bug-hurd/2013-06/msg00102.html, it + should be possible to support split-stack now that we have tls + <gnu_srs1> as thomas reported + <braunr> i don't see the relation between split-stack and the mmap + invocation + <gnu_srs1> tls s in 2.17-97, right? that's the one I tried + <braunr> tls is there, but not split stack support + <braunr> and libpthread still has bugs related to changing the stack + apparently + <braunr> fixed upstream but not yet in debian packages + <braunr> unless you want to try with the thread destruction packages + <braunr> not sure it will change much though + * Also see `libgcc/config/i386/morestack.S`: comments w.r.t `TARGET_THREAD_SPLIT_STACK_OFFSET`/`%gs:0x30` usage; likely needs porting. @@ -498,6 +539,29 @@ Last reviewed up to the [[Git mirror's 3a930d3fc68785662f5f3f4af02474cb21a62056 [[!message-id "201211061305.02565.pino@debian.org"]]. + IRC, freenode, #hurd, 2014-01-08: + + <gnu_srs> How come __GLIBC__ is defined in gcc for kFreeBSD and not + GNU? They sometimes use that instead of __FreeBSD_kernel__ + <pochu> it's defined by libc's /usr/include/features.h + <gnu_srs> pochu: __GLIBC__ is defined in features.h both for GNU and + kFreeBSD, but only in gcc/cpp for kFreeBSD: touch foo.h;gcc -E -dM + foo.h|grep GLIBC + <pochu> gnu_srs: #include <stdlib.h> + <gnu_srs> pochu: they both include <features.h> + <pochu> gnu_srs: I get __GLIBC__ defined if I include features.h + <pochu> with an empty file (as suggested by your `touch foo.h') I don't + get it defined, whether on hurd or linux, but I think that's expected + <gnu_srs> pochu: might be so but it is not pre-defined in CPP, as it is + for kFreeBSD. + <gnu_srs> I think it should not be defined, or it should be defined by + all three: GNU,.kFreeBSD and Linux + <gnu_srs> an anomaly, something for tschwinge + <braunr> https://lists.debian.org/debian-bsd/2012/11/msg00016.html + <gnu_srs> braunr: good finding, I assume nothing has happened since + then? + <braunr> not likely + * [low] Does `-mcpu=native` etc. work? (For example, 2ae1f0cc764e998bfc684d662aba0497e8723e52.) @@ -535,6 +599,42 @@ Last reviewed up to the [[Git mirror's 3a930d3fc68785662f5f3f4af02474cb21a62056 A lot of Linux-specific things. + * `libcilkrts` + + IRC, freenode, #hurd, 2014-01-10: + + <youpi> bwaarf, libcilkrts in gcc-4.9 + <p2-mate> libcilkrts? + <youpi> the runtime for the cilk language I guess + <tschwinge> Yes. That most likely needs disabling for us. + <tschwinge> I'll hve a look eventually. + <tschwinge> As soon as I get + <http://news.gmane.org/find-root.php?message_id=%3C87wqjjo5kx.fsf%40kepler.schwinge.homeip.net%3E> + resolved, actually. + + [[!debbug 734973]]. + + * `WCONTINUED` + + IRC, OFTC, #debian-hurd, 2014-02-25: + + <gnu_srs> youpi: some gcc-4.9 packages (and source) are needed for + gnat-4.9 to build: Is it OK to propose this patch: + http://paste.debian.net/84079/ + --- a/src/gcc/lto_lto.c.orig 2014-02-14 19:22:14.000000000 +0100 + +++ b/src/gcc/lto/lto.c 2014-02-25 20:50:20.000000000 +0100 + @@ -2476,7 +2476,11 @@ + int status; + do + { + +#ifdef __GNU__ + + int w = waitpid(0, &status, WUNTRACED); + +#else + int w = waitpid(0, &status, WUNTRACED | WCONTINUED); + +#endif + if (w == -1) + fatal_error ("waitpid failed"); + <youpi> gnu_srs: rather ifndef WCONTINUED diff --git a/open_issues/gdb_catch_syscall.mdwn b/open_issues/gdb_catch_syscall.mdwn index 366c88f5..a875b211 100644 --- a/open_issues/gdb_catch_syscall.mdwn +++ b/open_issues/gdb_catch_syscall.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,7 +8,7 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[meta title="GDB: catch syscall"]] +[[!meta title="GDB: catch syscall"]] (gdb) catch syscall The feature 'catch syscall' is not supported on this architeture yet. diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 5aec5139..8d18d1e2 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.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 @@ -210,6 +210,14 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 * Missing interfaces, amongst many more. + IRC, freenode, #hurd, 2014-02-25: + + <tschwinge> youpi et al.: Is it a useful GSoC task to have the student + implement interfaces in glibc that we are currently missing? + <braunr> tschwinge: definitely + <braunr> posix_timers would be great + <youpi> tschwinge: probably + Many more are missing, some of which have been announced in `NEWS`, others typically haven't (like new flags to existing functions). Typically, porters will notice missing functionaly. But in case you're looking for @@ -270,6 +278,20 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 If we have all of 'em (check Linux kernel), `#define __ASSUME_ATFCTS`. + * `futimens` + + IRC, freenode, #hurd, 2014-02-09: + + <youpi> it seems apt 0.9.15.1 has troubles downloading packages + etc., as opposed to apt 0.9.15 + <youpi> ah, that version uses futimens unconditionally + <youpi> and we haven't implemented that yet + <azeem> did somebody file a bug for that apt-get issue? + <youpi> I haven't + <youpi> I'll commit the fix in eglibc + <youpi> but perhaps a bug report would be good for the kfreebsd + case + * `bits/stat.h [__USE_ATFILE]`: `UTIME_NOW`, `UTIME_OMIT` * `io/fcntl.h [__USE_ATFILE]` @@ -362,6 +384,374 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 http://darnassus.sceen.net/gitweb/savannah_mirror/glibc.git/blob/refs/heads/tschwinge/Roger_Whittaker:/hurd/hurdselect.c <braunr> this is the client side implementation + IRC, freenode, #hurd, 2014-02-14: + + <desrt> also: do you know if hurd has a modern-day poll() + replacement? ala epoll, kqueue, iocp, port_create(), etc? + <pochu_> last thing I remember was that there was no epoll + equivalent, but that was a few years ago :) + <pochu_> braunr: ^ + * desrt is about to replace gmaincontext in glib with something + more modern + * desrt really very much wants not to have to write a poll() + backend.... + <desrt> it seems that absolutely every system that i care about, + except for hurd, has a new approach here :/ + <desrt> even illumos has solaris-style ports + <azeem> desrt: I suggest you bring up the question on bug-hurd + <azeem> the poll() system call there to satisfy POSIX, but there + might be a better Hurd-specific thing you could use + <azeem> is there* + <desrt> that would be ideal + <desrt> i have to assume that a system that passes to many messages + has some other facilities :) + <desrt> *so many + <desrt> the question is if they work with fds.... + <desrt> bug-hurd doesn't seem like a good place to ask open-ended + questions.... + <azeem> it's the main development lists, it's just old GNU naming + <azeem> list* + <desrt> k. thanks. + <azeem> bug-hurd@gnu.org is the address + * desrt goes to bug... hurd + <desrt> written. thanks. + <braunr> desrt: the hurd has only select/poll + <braunr> it suffers from so many scalability issues there isn't + much point providing one currently + <braunr> we focus more on bug fixing and posix compliance right now + <desrt> fair answer + <braunr> you should want a poll-based backend + <braunr> it's the most portable one, and doesn't suck as much as + select + <braunr> very easy to write + <braunr> although, internally, our select/poll works just like a + bare epoll + <braunr> i.e. select requests are installed, the client waits for + one or more messages, then uninstalls the requests + + IRC, freenode, #hurd, 2014-02-23: + + <desrt> brings me to another question i asked here recently that + nobody had a great answer for: any plan to do kqueue? + <braunr> not for now + <braunr> i remember answering you about that + <desrt> ah. on IRC or the list? + <braunr> that internally, our select/poll implementation works just + like epoll + <braunr> on irc + <braunr> well "just like" is a bit far from the truth + <desrt> well... poll() doesn't really work like epoll :p + <braunr> internally, it does + <braunr> even on linux + <desrt> since both of us have to do the linear scan on the list + <desrt> which is really the entire difference + <braunr> that's the user interface part + <braunr> i'm talking about the implementation + <desrt> ya -- but it's the interface that makes it unscalable + <braunr> i know + <braunr> what i mean is + <braunr> since the implementation already works like a more modern + poll + <braunr> we could in theory add such an interface + <braunr> but epoll adds some complicated detail + <desrt> you'll have to forgive me a bit -- i wasn't around from a + time that i could imagine what a non-modern poll would look like + inside of a kernel :) + <braunr> what i mean with a modern poll is a scalable poll-like + interface + <braunr> epoll being the reference + * desrt is not super-crazy about the epoll interface.... + <braunr> me neither + <desrt> kevent() is amazing -- one syscall for everything you need + <braunr> i don't know kqueue enough to talk about it + <desrt> no need to do 100 epollctls when you have a whole batch of + updates to do + <desrt> there's two main differences + <desrt> first is that instead of having a bunch of separate fds for + things like inotify, timerfd, eventfd, signalfd, etc -- they're + all built in as different 'filter' types + <desrt> second is that instead of a separate epoll_ctl() call to + update the list of monitored things, the kevent() call + (epoll_wait() equivalent) takes two lists: one is the list of + updates to make and the other is the list of events to + return.... so you only do one syscall + <braunr> well, again, that's the interface + <braunr> internally, there still are updates and waits + <braunr> and on a multiserver system like the hurd, this would mean + one system call per update per fd + <braunr> and then one per wait + <desrt> on the implementation side, i think kqueue also has a nice + feature: the kernel somehow has some magic that lets it post + events to a userspace queue.... so if you're not making updates + and you do a kevent() that would not block, you don't even enter + the kernel + <braunr> ok + <desrt> hm. that's an interesting point + <desrt> "unix" as such is just another server for you guys, right? + <braunr> no + <braunr> that's a major difference between the hurd and other + microkernel based systems + <braunr> even multiserver ones like minix + <braunr> we don't have a unix server + <braunr> we don't have a vfs server or even an "fd server" + <desrt> so mach knows about things like fds? + <braunr> no + <braunr> only glibc + <desrt> oh. weird! + <braunr> yes + <braunr> that's the hurd's magic :) + <braunr> being so posix compliant despite how exotic it is + <desrt> this starts to feel like msvcrt :p + <braunr> maybe, i wouldn't know + <braunr> windows is a hybrid after all + <braunr> with multiple servers for its file system + <braunr> so why not + <braunr> anyway + <desrt> so windows doesn't have fds in the kernel either... the C + library runtime emulates them + <braunr> mach has something close to file descriptors + <desrt> which is fun when you get into dll hell -- sometimes you + have multiple copies of the C library runtime in the same program + -- and you have to take care not to use fds from one of them with + th o ther one + <braunr> yes .. + <braunr> that, i knew :) + <braunr> but back to the hurd + <braunr> since fds are a glibc thing here, and because "files" can + be implemented by multiple servers + <braunr> (sockets actually most of the time with select/poll) + <braunr> we have to make per fd requests + <braunr> the implementation uses the "port set" kernel abstraction + <desrt> right -- we could have different "fd" coming from different + places + <braunr> do you know what a mach port is ? + <desrt> not even a little bit + <braunr> hm + <desrt> i think it's what a plane does when it goes really fast, + right? + <braunr> let's say it's a kernel message queue + <braunr> no it's not a sonic boom + <desrt> :) + <braunr> ;p + <braunr> so + <braunr> ports are queues + <desrt> (aside: i did briefly run into mach ports recently on macos + where they modified their kqueue to support them...) + <braunr> queues of RPC requests usually + <desrt> (but i didn't use them or look into them at all) + <braunr> they can be referenced through mach port names, which are + integers much like file descriptors + <braunr> they're also used for replies but, except for weird calls + like select/poll, you don't need to know that :) + <braunr> a port set is one object containing multiple ports + <desrt> sounds like dbus :) + <braunr> the point of a port set is to provide the ability to + perform a single operation (wait for a message) on multiple ports + <desrt> sounds like an epoll fd.... + <desrt> is the port set itself a port? + <braunr> so, when a client calls select, it translates the list of + fds into port names, creates reply ports for each of them, puts + them into a port set, send one select request for each, and does + one blocking wait on the port set + <braunr> no, but you can wait for a message on a port set the same + way you do on a port + <braunr> and that's all it does + <desrt> does that mean that you can you put a port set inside of + another port set? + <braunr> hm maybe + <desrt> i guess in some way that doesn't actually make sense + <braunr> i guess + <desrt> because i assume that the message you sent to each port in + your example is "tell me when you have some stuff" + <braunr> yes + <desrt> and you'd have to send an equivalent message to the port + set.... and that just doesn't make sense + <desrt> since it's not really a thing, per se + <braunr> it would + <braunr> insteaf of port -> port set, it would just be port -> port + set -> port set + <braunr> but we don't have any interface where an fd stands for a + port set + <braunr> what i'm trying to tell here is that + <braunr> considering how it's done, you can easily see that there + has to be non trivial communication + <braunr> each with the cost of a system call + <braunr> and not just any system call, a messaging one + <braunr> mach is clearly not as good as l4 when it comes to that + <desrt> hrmph + <braunr> and the fact that most pollable fds are either unix or + inet/inet6 sockets mean that there will be contention in the + socket servers anyway + <desrt> i've seen some of the crazy things you guys can do as a + result of the way mach works and way that hurd uses it, in + particular + <desrt> normal users setting up little tcp/ip universes for + themselves, and so on + <braunr> yes :) + <desrt> but i guess this all has a cost + <braunr> the cost here comes more from the implementation than the + added abstractions + <braunr> mach provides async ipc, which can partially succeed + <desrt> if i spin up a subhurd, it's using the same mach, right? + <braunr> yes + <desrt> that's neat + <braunr> we tend to call them neighbour hurds because of that + <braunr> i'm not sure it is + <desrt> it puts it half way between linux containers and outright + VMs + <desrt> because you have a new kernel.... ish... + <braunr> well, it is for the same reasons hypervisors are neat + <desrt> but the kernel exists within this construct.... + <braunr> a new kernel ? + <desrt> a new hurd + <braunr> yes + <desrt> but not a new mach + <braunr> exactly + <desrt> ya -- that's very cool + <braunr> it's halfway between hypervisors and containers/jails + <braunr> what matters is that we didn't need to write much code to + make it work + <braunr> and that the design naturally guarantees strong isolation + <desrt> right. that's what i'm getting at + <braunr> unlike containers + <desrt> it shows that the interaction between mach and these set of + crazy things collectively referred to as the hurd is really + proper + <braunr> usually + <braunr> sometimes i think it's not + <braunr> but that's another story :) + <desrt> don't worry -- you can fix it when you port to L4 ;) + <braunr> eh, no :) + <desrt> btw: is this fundamentally the same mach as darwin? + <braunr> yes + <desrt> so i guess there are multiple separate implementations of a + standard set of interfaces? + <braunr> ? + * desrt has to assume that apple wouldn't be using GNU mach, for + example... + <braunr> no it's the same code base + <braunr> they couldn't + <braunr> but only because the forks have diverged a bit + <desrt> ah + <braunr> and they probably changed a lot of things in their virtual + memory implementation + <desrt> so i guess original mach was under some BSDish type thing + and GNU mach forked from that and started adding GPL code? + <braunr> something like that + <desrt> makes sense + <braunr> we have very few "non-standard" mach interfaces + <braunr> but we now rely on them so we couldn't use another mach + either + <braunr> back to the select/poll stuff + * desrt gets a lesson tonight :) + <braunr> it costs, it's not scalable + <braunr> but + <braunr> we have scalability problems in our servers + <braunr> they're old code, they use global locks + <desrt> right. this is the story i heard last time. + <braunr> probably from me + <braunr> poll works good enough for us right now + <braunr> we're more interested in bug fixes than scalability + currently + <desrt> the reason this negative impacts me is because now i need + to write a bunch more code ;p + <braunr> i hope this changes but we still get weird errors that + many applications don't expect and they react badly to those + <braunr> well, poll really is the posix fallback + <desrt> every other OS that we want to support has some sort of new + scalable epoll-type interface or is Windows (which needs separate + code anyway) + <desrt> a very large number of them have kqueue... linux has + epoll... solaris/illumos is the odd one out with this weird thing + that's sort of like epoll + <braunr> i would think you want a posix fallback for such a + commonly used interface + <braunr> hm + <desrt> braunr: hurd is pretty much the only one that doesn't + already have something better.... + <braunr> linux can be built without epoll + <desrt> and the nice thing about all of these things is that every + single one of them gives me an fd that can be polled when any + event is ready + <braunr> i don't see why anyone would do that, but it's a compile + time option ;p + <braunr> yes ... + <braunr> we don't have xxxfd() :) + <desrt> and we want to expose that fd on our API... so people can + chain gmaincontext into other mainloops + <braunr> that's expected + <desrt> so for hurd this means that i will need to spin up a + separate thread doing poll() and communicating back to the main + thread when anything becomes ready + <desrt> i was looking forward to not having to do that :) + <braunr> it matches the unix "everything is a file" idea, and + windows concept of "events" + <braunr> i understand but again, it's a posix fallback + <braunr> you probably want it anyway + <desrt> probably + <braunr> it could help new systems trying to be posix like + <desrt> i honestly thought i'd get away with it, though + <desrt> this is true... + <desrt> CLOCK_MONOTONIC is an easy enough requirement to implement + or fake.... "modern event polling framework" is another story... + + [[clock_gettime]]. + + <braunr> yes, but again, we do have the underlying machinery to add + it + <desrt> i appreciate if your priorities are elsewhere ;) + <braunr> it's just not worth the effort right now + <braunr> although we do have performance and latency improvements + in our patch queues currently + <braunr> if our network stack gets replaced, it would become + interesting + <braunr> we need to improve posix compliance first + <braunr> make more applications not choke on unecpected errors + <braunr> and then we can think of improving scalability + <desrt> +1 vote from me for implementing monotonic time :) + <desrt> (and also pthread_condattr_setclock()) + <braunr> and we probably won't implement the epoll interface ;p + <braunr> yes + <desrt> it's worth noting that there is also a semi-widely + available non-standard extension called + pthread_cond_timedwait_relative_np that you could implement + instead + <desrt> it takes a (relative) timeout instead of an absolute one -- + we can use that if it's available + <braunr> desrt: why would you want relative timeouts ? + <desrt> braunr: if you're willing to take the calculations into + your own hands and you don't have another way to base it on + monotonic time it starts to look like a good alternative + <desrt> and indeed, this is the case on android and macos at least + <braunr> hm + <desrt> not great as a user-facing API of course.... due to the + spurious wakeup possibility and need to retry + <braunr> so it's non standard alternative to a monotonic clock ? + <desrt> no -- these systems have monotonic clocks + <desrt> what they lack is pthread_condattr_setclock() + <braunr> oh right + <desrt> which is documented in POSIX but labelled as 'optional' + <braunr> so relative is implicitely monotonic + <desrt> yes + <desrt> i imagine it would be the same 'relative' you get as the + timeout you pass to poll() + <desrt> since basing anything like this on wallclock time is + absolutely insane + <desrt> (which is exactly why we refuse to use wallclock time on + our timed waits) + <braunr> sure + <braunr> i'm surprised clock_monotonic is even optional in posix + 2008 + <braunr> but i guess that's to give some transition margin for + small embedded systems + <desrt> when you think about it, CLOCK_REALTIME really ought to + have been the optional feature + <desrt> monotonic time is so utterly basic + <braunr> yes + <braunr> and that's how it's normally implemented + <braunr> kernels provide a monotonic clock, and realtime is merely + shifted from it + * `sys/eventfd.h` * `sys/inotify.h` @@ -1129,6 +1519,82 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 <gg0> ah ok you just pushed your tls. great! <braunr> tls will fix a lot of things + IRC, OFTC, #debian-hurd, 2013-11-03: + + <youpi> gg0: + <youpi> #252 test_fork.rb:30:in `<top (required)>': core dumped + [ruby-core:28924] + <youpi> FAIL 1/949 tests failed + <youpi> with the to-be-uploaded glibc + <gg0> why does it coredump? + <gg0> that's the test i had workarounded by increasing sleep from 1 + to 3 but i don't recall it coredump'ed + <gg0> *recall if + <gg0> "sleep 1" at bootstraptest/test_fork.rb:33 + <youpi> how can I run the test alone? + + IRC, OFTC, #debian-hurd, 2013-11-04: + + <youpi> gg0: ^ + <gg0> it should not take much + <gg0> run $ make OPTS=-v test + <gg0> found out how to minimize + <gg0> mkdir _youpi && cp bootstraptest/{runner,test_fork}.rb _youpi + <gg0> then run $ ./miniruby -I./lib -I. -I.ext/common + ./tool/runruby.rb --extout=.ext -- --disable-gems + "./_youpi/runner.rb" --ruby="ruby2.0 -I./lib" -q -v + <gg0> youpi: that should work + <youpi> #1 test_fork.rb:1:in `<top (required)>': No such file or + directory - /usr/src/ruby1.9.1-1.9.3.448/ruby2.0 + -I/usr/src/ruby1.9.1-1.9.3.448/lib -W0 bootstraptest.tmp.rb + [ruby-dev:32404] + <gg0> seems it can't find /usr/src/ruby1.9.1-1.9.3.448/ruby2.0 + <youpi> well it's ruby1.9.1 indeed :) + <youpi> ok, got core + <gg0> replace 2.0 with 1.9, check what you have in rootdir + <gg0> k + <youpi> Mmm, no, there's no core file + <gg0> does stupidly increasing sleep time work? + <youpi> nope + <gg0> without *context it runs "make test" fine. real problems come + later with "make test-all" + <gg0> wrt test_fork, is correspondence between signals correct? i + recall i read something about USR1 not implemented + <youpi> USR1 is implemented, it's SIGRT which is not implemented + <gg0> my next wild guess is that that has something to do with + atfork, whatever that means + <gg0> it makes 2 forks: one sleeps for 1 sec then kills -USR1 + itself, the second traps USR1 in getting current time. in the + meanwhile parent sleeps for 2 secs + + IRC, OFTC, #debian-hurd, 2013-11-07: + + <gg0> ruby2.0 just built on unstable + + IRC, OFTC, #debian-hurd, 2013-11-09: + + <gg0> youpi: just found out a more "official" way to run one test + only + http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/README.porters;h=94aff7dd3ecd9f748498f2e285b4a4313b4b8f36;hb=HEAD + <gg0> btw still getting coredumps? + + IRC, OFTC, #debian-hurd, 2013-11-13: + + <gg0> wrt the other test test_fork i suppose you made it not to + segfault anymore, it simply does fail + <youpi> I haven't taken any particular care + <youpi> didn't have any time to deal with it + + IRC, OFTC, #debian-hurd, 2013-11-14: + + <gg0> btw patches to disable *context have been backported to 1.9 + as well so next 1.9 point release should have *context disabled + <gg0> as 2.0 have + <gg0> *has + <gg0> i guess you'd like to get them reverted now + <gg0> youpi: ^ + <youpi> after testing that *context work, yes + * `sigaltstack` IRC, freenode, #hurd, 2013-10-09: @@ -1316,6 +1782,77 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 socket/socketpair, didn't we talk about them when i worked on eglibc 2.17? + * `mlock`, `munlock`, `mlockall`, `munlockall` + + IRC, freenode, #hurd, 2014-01-09: + + <gnu_srs> Hi, is mlock, mlockall et al implemented? + <braunr> i doubt it + <braunr> mlock could be, but mlockall only partially + + * [[glibc_IOCTLs]] + + * Support for `$ORIGIN` in the dynamic linker, `ld.so` + + IRC, freenode, #hurd, 2014-02-23: + + <sjamaan> + https://www.gnu.org/software/hurd/user/jkoenig/java/report.html + says $ORIGIN patches have been added to Hurd. Have those hit the + mainline codebase? + + [[user/jkoenig/java]], [[user/jkoenig/java/report]]. + + <sjamaan> It doesn't seem to work here, but perhaps I'm missing + something (I'm using the prebuilt Debian/Hurd 2014-02-11 VM + image) + <sjamaan> objdump -x says the value of RPATH is $ORIGIN + <sjamaan> But it doesn't load a library I placed in the same dir as + the binary + <braunr> sjamaan: i'm not sure + <braunr> sjamaan: what are you trying to do ? + + IRC, freenode, #hurd, 2014-02-24: + + <sjamaan> braunr: I am working on a release of the CHICKEN Scheme + compiler. Its test suite is currently failing on the stand-alone + deployment tests. Either it should work and use $ORIGIN, or the + test should be disabled, saying Hurd is not supported for + stand-alone deployment-directories + <sjamaan> braunr: The basic idea is to be able to create "appdirs" + like on OS X or PC-BSD, containing all the dependencies a program + needs, which can then simply be untarred + <braunr> sjamaan: ok so you do need $ORIGIN + <sjamaan> yeah + <sjamaan> iiuc, so does Java. Does Java work on Hurd? + <braunr> we had packages at the time jkoenig worked on it + <braunr> integration of patches may have been incomplete, i wasn't + there at the time and i'm not sure + <sjamaan> So it's safest to claim it's unsupported, for now? + <braunr> yes + <sjamaan> Thank you, I'll do that and revisit it later + + * `mig_reply_setup` + + IRC, freenode, #hurd, 2014-02-24: + + <teythoon> braunr: neither hurd, gnu mach or glibc provides + mig_reply_setup + <teythoon> i want to provide this function, where should i put it ? + <teythoon> i found some mach source that put it in libmach afaic + <teythoon> + ftp://ftp.sra.co.jp/.a/pub/os/mach/extracted/mach3/mk/user/libmach/mig_reply_setup.c + <braunr> teythoon: what does it do ? + <teythoon> braunr: not much, it just initializes the reply message + <teythoon> libports does this as well, in the + ports_manage_port_operations* functions + <braunr> teythoon: is it a new function you're adding ? + <teythoon> braunr: yes + <teythoon> braunr: glibc has a declaration for it, but no + implementation + <braunr> teythoon: i think it should be in glibc + <braunr> maybe in mach/ + For specific packages: * [[octave]] @@ -2115,6 +2652,15 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 +tst-tls-atexit-lib.c:35:3: warning: implicit declaration of function '__cxa_thread_atexit_impl' [-Wimplicit-function-declaration] * a600e5cef53e10147932d910cdb2fdfc62afae4e `Consolidate Linux and POSIX libc_fatal code.` -- is `backtrace_and_maps` specific to Linux? + + IRC, freenode, #hurd, 2014-02-06: + + <braunr> why wouldn't glibc double free detection code also print + the backtrace on hurd ? + <youpi> I don't see any reason why + <youpi> except missing telling glibc that it's essentially like on + linux + * 288f7d79fe2dcc8e62c539f57b25d7662a2cd5ff `Use __ehdr_start, if available, as fallback for AT_PHDR.` -- once we require Binutils 2.23, can we simplify [[glibc's process startup|glibc/process]] diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn index 8991d4c0..33ef8f3a 100644 --- a/open_issues/glibc/0.4.mdwn +++ b/open_issues/glibc/0.4.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 @@ -15,6 +16,8 @@ Things to consider doing when bumping the glibc SONAME. There are some comments in the sources, for example `hurd/geteuids.c`: `XXX Remove this alias when we bump the libc soname.` +[[!toc]] + # IRC, freenode, #hurd, 2012-12-14 @@ -33,3 +36,42 @@ In context of [[packaging_libpthread]]/[[libpthread]]. [[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id "4BFA500A.7030502@gmail.com"]]. + + +# `time_t` -- Unix Epoch vs. 2038 + +## IRC, freenode, #hurd, 2013-12-12 + + <azeem> because it gets discussed in #debian-devel for the Linux i386 + architecture right now: what's the deal with hurd-i386 and the 32bit + epoch overflow in 2038? + <braunr> what do you mean ? + <azeem> braunr: http://lwn.net/Articles/563285/ + <braunr> ok but what do you mean ? + <braunr> i don't think there is anything special with the hurd about that + <azeem> well, time_t is 64bit on amd64 AIUI + <braunr> it's a signed long + <azeem> so maybe the Hurd guys were clever from the start + <azeem> k, k + <braunr> our big advantage is that we can afford to break things a little + without too much trouble + <braunr> in a system at work, we use unsigned 32-bit words + <braunr> which overflows in 2106 + <braunr> and we already include funny comments that predict our successors, + if any, will probably fail to deal with the problem until short before + the overflow :> + <azeem> luckily, no nuclear reactors are running the Hurd sofar + <braunr> i wonder how the problem will be dealt with though + <braunr> ah, openbsd decided to break their abi + <azeem> yeah + <braunr> that's probably the simplest solution + <azeem> "just recompile" + <braunr> and they can afford it too + <azeem> yeah + <braunr> good to see people actually worry about it + <azeem> I guess people are getting worried about where Linux embedded is + being put into + <braunr> they're right about that + <azeem> "Please, don't fix the 2038 year issue. I also want to have some + job security :)" + <braunr> haha diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn index 5168479d..273f02fd 100644 --- a/open_issues/glibc/debian/experimental.mdwn +++ b/open_issues/glibc/debian/experimental.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 @@ -130,6 +130,101 @@ Now in unstable. <pinotree> btw i saw too the segmentation fault when generating locales +## IRC, freenode, #hurd, 2014-02-04 + + <bu^> hello + <bu^> I just updated + <bu^> Setting up locales (2.17-98~0) ... + <bu^> Generating locales (this might take a while)... + <bu^> en_US.UTF-8...Segmentation fault + <bu^> done + <gnu_srs> bu^: That's known, it still seems to work, though. If you have + the time please debug. I've tried but not found the solution yet:-( + <bu^> ok, just wanted to notify + + +## IRC, freenode, #hurd, 2014-02-19 + + <braunr> for info, the localedef segfault has been fixed upstream + <braunr> or rather, upstream has been written in a way that won't trigger + the segfault + <braunr> it is caused by the locale archive code that maps the locale + archive file in the address space, enlarging the mapping as needed, but + unmaps the complete reserved size of 512M on close + <braunr> munmap is implemented through vm_deallocate, but it looks like the + latter doesn't allow deallocating unmapped regions of the address space + <braunr> (to be confirmed) + <braunr> upstream code tracks the mapping size so vm_deallocate won't whine + <braunr> i expect we'll have that in eglibc 2.18 + <braunr> hm actually, posix says munmap must refer to memory obtained with + mmap :) + <braunr> (or actually, that the behaviour is undefined, which most unix + systems allow anyway, but not us) + + <braunr> also, before i leave, i have partially traced the localedef + segfault + <youpi> ah, cool + <braunr> localedef maps the locale archive, and enlarges the mapping as + needed + <braunr> but munmaps the complete 512m reserved area + <braunr> and i strongly suspect it unmaps something it shouldn't on the + hurd + <braunr> since linux mmap has different boundaries depending on the mapping + use + <braunr> while our glibc will happily maps stacks below text + <braunr> the good news is that it looks fixed upstream + <youpi> ah :) + <braunr> + https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6 + <braunr> see the change about close_archive + <braunr> i haven't tested it though + + +## IRC, freenode, #hurd, 2014-02-21 + + <gg0> just upgraded to 2.18, locales still segfaults + <braunr> ok + + +## IRC, freenode, #hurd, 2014-02-23 + + <braunr> ok, as expected, the localdef bug is because of some mmap issue + +[[glibc/mmap]]. + + <braunr> looks like our mmap doesn't like mapping files with PROT_NONE + <braunr> shouldn't be too hard to fix + <braunr> gg0: i should have a fix ready soon for localedef + + <braunr> youpi: i have a patch for glibc about the localedef segfault + <youpi> is that the backport we talked about, or something else? + <braunr> something else + <braunr> in short + <braunr> mmap() PROT_NONE on files return 0 + <youpi> ok + <youpi> seems like fixable indeed + <braunr> nothing is mapped, and the localdef code doesn't consider this an + error + <braunr> my current fix is to handle PROT_NONE like PROT_READ + <youpi> doesn't vm_protect allow to map something without giving read + right? + <braunr> it probably does + <braunr> the problem is in glibc + <youpi> ok + <braunr> when i say like PROT_READ, i mean a memory object gets a reference + <braunr> on the read port returned by io_map + <braunr> since it's not accessible anyway, it shouldn't make a difference + <braunr> but i preferred to have the memory object referenced anyway to + match what i expect is done by other systems + + +## IRC, freenode, #hurd, 2014-02-24 + + <youpi> braunr: ah ok + + <braunr> ok that mmap fix looks fine, i'll add comments and commit it soon + + # IRC, OFTC, #debian-hurd, 2013-06-20 <youpi> damn @@ -173,3 +268,62 @@ Now in unstable. <youpi> I'd warmly welcome a way to detect whether being the / translator process btw <youpi> it seems far from trivial + + +# glibc 2.18 vs. GCC 4.8 + +## IRC, freenode, #hurd, 2013-11-25 + + <youpi> grmbl, installing a glibc 2.18 rebuilt with gcc-4.8 brings an + unbootable system + + +## IRC, freenode, #hurd, 2013-11-29 + + <teythoon> so, what do I do? rebuild the glibc 2.18 package with gcc4.8 and + see what breaks ? + <teythoon> when I boot a system with that libc that is ? + <teythoon> I wish youpi would have been more specific, I've never built the + libc before... + <braunr> debian/rules build in the debian package + <braunr> ctrl-c when you see gcc invocations + <braunr> cd buildir; make lib others + <braunr> although hm + <braunr> what breaks is at boot time right ? + <teythoon> yes + <braunr> heh .. + <braunr> then dpkg-buildpackage + <braunr> DEB_BUILD_OPTIONS=nocheck speeds things up + <braunr> just answer on the mailing list and ask him + <braunr> he usually answers quickly + + +## IRC, freenode, #hurd, 2013-12-18 + + <gnu_srs> teythoon: k!, any luck with eglibc-2.18? + <teythoon> tbh i didn't look into this after two unsuccessful attempts at + building the libc package + <teythoon> there was a post over at the libc-alpha list that sounded + familiar + <teythoon> http://www.cygwin.com/ml/libc-alpha/2013-12/msg00281.html + <braunr> wow + <teythoon> ? + <braunr> this looks tricky + <braunr> and why ia64 only + <teythoon> indeed + <braunr> it's rare to see aurel32 ask such questions + + +## IRC, freenode, #hurd, 2014-01-22 + + <youpi> btw, did anybody investigate the glibc-built-with-gcc-4.8 issue? + <youpi> oddly enough, a subhurd boots completely fine with it + <braunr> i didn't + <teythoon> no, sorry + <youpi> I was wondering whether the bogus deallocation at boot might have + something to do + <braunr> which one ? + <braunr> ah + <braunr> yes + <braunr> maybe + <youpi> quoted earlier here diff --git a/open_issues/glibc_ioctls.mdwn b/open_issues/glibc_ioctls.mdwn index 14329d0f..3f396754 100644 --- a/open_issues/glibc_ioctls.mdwn +++ b/open_issues/glibc_ioctls.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,7 +10,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_glibc]] -IRC, unknown channel, unknown date. + +# IRC, unknown channel, unknown date <pinotree> d'oh, broken defines for ioctl()! <pinotree> http://paste.debian.net/45021/ ← any idea about this? looks like something fishy with the SIO* defines @@ -70,3 +71,101 @@ IRC, unknown channel, unknown date. <pinotree> right <youpi> which might end up in mach, other processes, other machines, etc. * pinotree s/Mach/Hurd/ :) + + +# `TIOCCONS` + +## IRC, freenode, #hurd, 2014-02-05 + + <gnu_srs> Hi, anybody have time to look at what fails with: ioctl(0, + TIOCCONS, NULL)? + <gnu_srs> found a program doing the same function call as bootlogd: + http://paste.debian.net/80231/ + <gnu_srs> rpctrace: http://paste.debian.net/80232/ + <youpi> gnu_srs: it seems there is a misunderstanding between linux and + *bsd on this one + <youpi> to be able to work on *bsd (and on hurd too), the source code + should replace its NULL parameter with the address of an integer + containing 1 + <youpi> see + http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022116.html + for the bsd implementation, for instance + <gnu_srs> youpi: replacing 0 with &i where int i=1 gives: TIOCCONS: + Inappropriate ioctl for device + <youpi> so be it, but that's clearly needed to be able to work on bsd + <youpi> and probably the implementation is just missing on the Hurd for now + <gnu_srs> jus to be clear: do you mean 0 or NULL in: ioctl(0, TIOCCONS, + NULL)? + <youpi> yes, for instance there is an implementation do_tiocsctty in glibc, + but no to_tioccons + <youpi> I mean NULL + <gnu_srs> OK, that's where I changed, the first argument id the FD + <youpi> well, when I wrote "NULL", I really meant "NULL" ... + <gnu_srs> yes sure, so you say that it is not yet implemented? + <youpi> yes, for instance there is an implementation do_tiocsctty in glibc, + but no to_tioccons + <gnu_srs> easy to do? + <youpi> no idea, I don't even know what that is suppsoed to do + <youpi> it's probably something like tiocsctty, but I don't really know + <gnu_srs> Redirecting console output to a pseudotty + <youpi> omg that ioctl is so ugly + <youpi> the way I can see it working is to add an RPC to the /dev/console + translator (i.e. /hurd/term) to give it the fd, and have /hurd/term write + to it whenever it gets writes, instead of writing to the console device + <youpi> gnu_srs: what do you need that for? + <gnu_srs> bootlogd in sysvinit use that for logging. + <gnu_srs> should I propose a patch to avoid the segfault when booting then? + <youpi> at least, yes + <youpi> *bsd will need it anyway + <gnu_srs> youpi: btw: hurd console does not work when running openrc, + neither is halt/reboot. Maybe you should try it out? + <gnu_srs> bootlogd use ioctl(0, TIOCCONS, NULL) a Linux (only) construct + <gnu_srs> ? + <youpi> gnu_srs: I had infinite time in the day, I would be able to try it + out, yes + <braunr> heh + <youpi> giving NULL to TIOCCONS is a linux-only construct, yes + <youpi> to be compatible with *BSD, you have to pass the parameter + mentioned above + <youpi> instead of NULL + <gnu_srs> well bootlogd is from sysvinit, so it is a matter if we move to + that for init. + <gnu_srs> ***checking if bootlogd segfaults on kFreeBSD too + + +# Non-constant structures as IOCTL parameter + +[[!debbug 413734]]. + + +## IRC, OFTC, #debian-hurd, 2014-02-16 + + <gg0> https://bugs.debian.org/413734 + <gg0> patch #2 has become http://paste.debian.net/plain/82412/ + <gg0> ie. almost entirely ifdef'ing DeviceEnum + <gg0> ok final patch is http://paste.debian.net/plain/82440/ + <gg0> could anyone review it, especially last 3 oss hunks? + <azeem> gg0: well probably it would be cleaner to have autoconf check for + any of the three soundcard.h include locations? + <gg0> azeem: i think if upstream is ok with 2 it could be ok with 3 too + <gg0> my concern is about linux/ in header path (hurd is not linux) and + about ways cleaner than last 2 hunks + <azeem> well yeah, #ifdef __GNU__ #include <linux/foo.h> certainly looks + ugly + <gg0> i'll ifdef ioctls only + + +### IRC, OFTC, #debian-hurd, 2014-02-17 + + <gg0> http://paste.debian.net/plain/82446/ + <gg0> https://trac.videolan.org/vlc/ticket/10696 + + +### IRC, freenode, #hurd, 2014-02-17 + + <gg0> porting vlc with http://paste.debian.net/plain/82446/ + + http://paste.debian.net/plain/82510/ + <gg0> what's the proper way to fix ioctl instead of ifdef'ing them? + <gg0> see https://bugs.debian.org/413734 + <braunr> gg0: defining them in libc + <braunr> and in servers implementing them ofc diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index 60ec7357..b36c674a 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.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 @@ -2231,6 +2231,132 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. more of them to be needed) +## IRC, freenode, #hurd, 2014-02-11 + + <braunr> youpi: what's the issue with kentry_data_size ? + <youpi> I don't know + <braunr> so back to 64pages from 256 ? + <youpi> in debian for now yes + <braunr> :/ + <braunr> from what i recall with x15, grub is indeed allowed to put modules + and command lines around as it likes + <braunr> restricted to 4G + <braunr> iirc, command lines were in the first 1M while modules could be + loaded right after the kernel or at the end of memory, depending on the + versions + <youpi> braunr: possibly VM_KERNEL_MAP_SIZE is then not big enough + <braunr> youpi: what's the size of the ramdisk ? + <braunr> youpi: or kmem_map too big + <braunr> we discussed this earlier with teythoon + +[[user-space_device_drivers]], *Open Issues*, *System Boot*, *IRC, freenode, +\#hurd, 2011-07-27*, *IRC, freenode, #hurd, 2014-02-10* + + <braunr> or maybe we want to remove kmem_map altogether and directly use + kernel_map + <youpi> it's 6.2MiB big + <braunr> hm + <youpi> err no + <braunr> looks small + <youpi> 70MiB + <braunr> ok yes + <youpi> (uncompressed) + <braunr> well + <braunr> kernel_map is supposed to have 64M on i386 ... + <braunr> it's 192M large, with kmem_map taking 128M + <braunr> so at most 64M, with possible fragmentation + <teythoon> i believe the compressed initrd is stored in the ramdisk + <youpi> ah, right it's ext2fs which uncompresses it + <braunr> uncompresses it where + <braunr> ? + <teythoon> libstore does that + <youpi> module --nounzip /boot/${gtk}initrd.gz + <youpi> braunr: in userland memory + <youpi> it's not grub which uncompresses it for sure + <teythoon> braunr: so my ramdisk isn't 64 megs either + <braunr> which explains why it sometimes works + <teythoon> yes + <teythoon> mine is like 15 megs + <braunr> kentry_data_size calls pmap_steal_memory, an early allocation + function which changes virtual_space_start, which is later used to create + the first kernel map entry + <braunr> err, pmap_steal_memory is called with kentry_data_size as its + argument + <braunr> this first kernel map entry is installed inside kernel_map and + reduces the amount of available virtual memory there + <braunr> so yes, it all points to a layout problem + <braunr> i suggest reducing kmem_map down to 64M + <youpi> that's enough to get d-i back to boot + <youpi> what would be the downside? + <youpi> (why did you raise it to 128 actually? :) ) + <braunr> i merged the map used by generic kalloc allocations into kmem_map + <braunr> both were 64M + <braunr> i don't see any downside for the moment + <braunr> i rarely see more than 50M used by the slab allocator + <braunr> and with the recent code i added to collect reclaimable memory on + kernel allocation failures, it's unlikely the slab allocator will be + starved + <youpi> but then we need that patch too + <braunr> no + <braunr> it would be needed if kmem_map gets filled + <braunr> this very rarely happens + <youpi> is "very rarely" enough ? :) + <braunr> actualy i've never seen it happen + <braunr> i added it because i had port leaks with fakeroot + <braunr> port rights are a bit special because they're stored in a table in + kernel space + <braunr> this table is enlarged with kmem_realloc + <braunr> when an ipc space gets very large, fragmentation makes it very + difficult to successfully resize it + <braunr> that should be the only possible issue + <braunr> actually, there is another submap that steals memory from + kernel_map: device_io_map is 16M large + <braunr> so kernel_map gets down to 48M + <braunr> if the initial entry (that is, kentry_data_size + the physical + page table size) gets a bit large, kernel_map may have very little + available room + <braunr> the physical page table size obviously varies depending on the + amount of physical memory loaded, which may explain why the installer + worked on some machines + <youpi> well, it works up to 1855M + <youpi> at 1856 it doesn't work any more :) + <braunr> heh :) + <youpi> and that's about the max gnumach can handle anyway + <braunr> then reducing kmem_map down to 96M should be enough + <youpi> it works indeed + <braunr> could you check the amount of available space in kernel_map ? + <braunr> the value of kernel_map->size should do + <youpi> printing it "multiboot modules" print should be fine I guess? + + +### IRC, freenode, #hurd, 2014-02-12 + + <braunr> probably + <teythoon> ? + <braunr> i expect a bit more than 160M + <braunr> (for the value of kernel_map->size) + <braunr> teythoon: ? + <youpi> well, it's 2110210048 + <teythoon> what is multiboot modules printing ? + <youpi> almost last in gnumach bootup + <braunr> humm + <braunr> it must account directly mapped physical pages + <braunr> considering the kernel has exactly 2G, this means there is 36M + available in kernel_map + <braunr> youpi: is the ramdisk loaded at that moment ? + <youpi> what do you mean by "loaded" ? :) + <braunr> created + <youpi> where? + <braunr> allocated in kernel memory + <youpi> the script hasn't started yet + <braunr> ok + <braunr> its size was 6M+ right ? + <braunr> so it leaves around 30M + <youpi> something like this yes + <braunr> and changing kmem_map from 128M to 96M gave us 32M + <braunr> so that's it + + # IRC, freenode, #hurd, 2013-04-18 <braunr> oh nice, i've found a big scalability issue with my slab allocator diff --git a/open_issues/hurd_101.mdwn b/open_issues/hurd_101.mdwn index 25822512..e55b0e8e 100644 --- a/open_issues/hurd_101.mdwn +++ b/open_issues/hurd_101.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 @@ -98,3 +99,262 @@ Not the first time that something like this is proposed... server), yes <ahungry> braunr: thanks for all the info, hittin the sack now but ill have to set up a box and try to contribute + + +# Documentation + +## IRC, freenode, #hurd, 2013-11-04 + + <stargater> i think the problem my hurd have not more developers or + contubutors is the project idears and management , eg, the most problem + is the mach kernel and documatation and the missing subsystem goals + (driver, etc) + <stargater> no i think you and other have a clue but this is not + tranzparent when i read the webpage + <teythoon> well, fwiw I agree, the documentation is lacking + <braunr> about what ? + <braunr> something that doesn't exist ? + <braunr> like smp or a generic device driver framework ? + <teythoon> no, high level concepts, design stuff + <braunr> what ? + <braunr> how come ? + <teythoon> not even the gnumach documentation is complete + <braunr> for example ? + <braunr> see http://www.sceen.net/~rbraun/doc/mach/ + <braunr> which is my personal collection of docs on mach/hurd + <braunr> and it's lacking at least one paper + <braunr> well two, since i can't find the original article about the hurd + in pdf format + <braunr> project ideas are clearly listed in the project ideas page + <stargater> braunr: do you think the mach kernel decumatation a compleat? + and you think its good documentatition about "how write a drive for mach" + and you think a answare is found why dont work smp and why is have no + arm, x64 support ? + <braunr> stargater: + http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/ + <braunr> the page is even named "project ideas" + <braunr> the mach kernel is probably the most documented in the world + <braunr> even today + <braunr> and if there is no documentation about "how to write drivers for + mach", that's because we don't want in kernel drivers any more + <braunr> and the state of our driver framework is practically non existent + <braunr> it's basically netdde + <braunr> partial support for network drivers from linux + <braunr> that's all + <braunr> we need to improve that + <braunr> someone needs to do the job + <braunr> noone has for now + <braunr> that's all + <braunr> why would we document something that doesn't exist ? + <braunr> only stupid project managers with no clue about the real world do + that + <braunr> (or great ones who already know everything there is to know before + writing code, but that's rare) + <braunr> stargater: the answer about smp, architectures etc.. is the same + <stargater> spirit and magic are nice ;-) braunr sorry, that is only my + meanig and i will help, so i ask and say what i think. when you say, hurd + and mach are good and we on the right way, then its ok for me . i wonder + why not more developer help hurd. and i can read and see the project page + fro side a first time user/developer + <braunr> i didn't say they're good + <braunr> they're not, they need to be improved + <braunr> clearly + <stargater> ok, then sorry + <braunr> i wondered about that too, and my conclusion is that people aren't + interested that much in system architectures + <braunr> and those who are considered the hurd too old to be interesting, + and don't learn about it + <braunr> consider* + <braunr> stargater: why are you interested in the hurd ? + <braunr> that's a question everyone intending to work on it should ask + <stargater> the spirit of free software and new and other operation system, + with focus to make good stuff with less code and working code for ever + and everone can it used + <braunr> well, if the focus was really to produce good stuff, the hurd + wouldn't be so crappy + <braunr> it is now, but it wasn't in the past + <stargater> a good point whas more documentation in now and in the future, + eg, i like the small project http://wiki.osdev.org/ and i like to see + more how understanding mach and hurd + <nalaginrut> I love osdev much, it taught me a lot ;-D + <braunr> osdev is a great source for beginners + <braunr> teythoon: what else did you find lacking ? + <teythoon> braunr: in my opinion the learning curve of Hurd development is + quite steep at the beginning + <teythoon> yes, documentation exists, but it is distributed all over the + internets + <braunr> teythoon: hm ok + <braunr> yes the learning curve is too hard + <braunr> that's an entry barrier + + +# IRC, freenode, #hurd, 2014-02-04 + +[[!tag open_issue_documentation]] + + <bwright> Does the GNU Mach kernel have concepts of capabilities? + <braunr> yes + <braunr> see ports, port rights and port names + <bwright> Does it follow the take grant approch + <bwright> approach* + <braunr> probably + <bwright> Can for example I take an endpoint that I retype from untyped + memory and mint it such that it only has read access and pass that to the + cspace of another task over ipc. + <bwright> Where that read minted cap enforces it may onnly wait on that ep. + <braunr> ep ? + <braunr> ah + <bwright> Endpoint. + <braunr> probably + <bwright> Alright cool. + <braunr> it's a bit too abstract for me to answer reliably + <braunr> ports are message queues + <braunr> port rights are capabilities to ports + <bwright> Not sure exactly how it would be implemented but essentially you + would have a guarded page table with 2 levels, 2^pow slots. + <braunr> port names are integers referring to port rights + <braunr> we don't care about the implementation of page tables + <bwright> Each slot contains a kernel object, which in itself may be more + page tabels that store more caps. + <braunr> it's not l4 :p + <braunr> mach is more of a hybrid + <bwright> It isn't a page table for memory. + <braunr> it manages virtual memory + <bwright> Ah ok. + <braunr> whatever, we don't care about the implementation + <bwright> So if I want to say port an ethernet driver over. + <braunr> whether memory or capabilities, mach manages them + <bwright> Can I forward the interrupts through to my new process? + <braunr> yes + <braunr> it has been implemented for netdde + <braunr> these are debian specific patches for the time being though + <bwright> Great, and shared memory set ups are all nice and dandy. + <braunr> yes, the mach vm takes care of that + <bwright> Can I forward page faults? + <bwright> Or does mach actually handle the faults? + <bwright> (Sorry for so many questions just comparing what I know from my + microkernel knowledge to mach and gnu mach) + <braunr> mach handles them but translates them to requests to userspace + pagers + <bwright> (Still have a mach paper to read) + <bwright> Alright that sounds sane. + <bwright> Does GNU mach have benchmarks on its IPC times? + <braunr> no but expect them to suck :) + <bwright> Isn't it fixable though? + <braunr> mach ipc is known to be extremely heavy in comparison with modern + l4-like kernels + <braunr> not easily + <bwright> Yeah so I know that IPC is an issue but never dug into why it is + bad on Mach. + <bwright> So what design decision really screwed up IPC speed? + <braunr> for one because they're completely async, and also because they + were designed for network clusters, meaning data is typed inside messages + <bwright> Oh weird + <bwright> So how is type marshalled in the message? + <braunr> in its own field + <braunr> messages have their own header + <braunr> and each data field inside has its own header + <bwright> Oh ok, so I can see this being heavy. + <bwright> So the big advantage is for RPC + <bwright> It would make things nice in that case. + <bwright> Is it possible to send an IPC without the guff though? + <bwright> Or would this break the model mach is trying to achieve? + <bwright> I am assuming Mach wanted something where you couldn't tell if a + process was local or not. + <bwright> So I am assuming then that IPC is costly for system calls from a + user process. + <bwright> You have some sort of blocking wait on the call to the service + that dispatches the syscall. + <bwright> I am assuming the current variants of GNU/Hurd run on glibc. + <bwright> It would be interesting to possibly replace that with UlibC or do + a full port of the FlexSC exceptionless system calls. + <bwright> Could get rid of some of the bottlenecks in hurd assuming it is + very IPC heavy. + <bwright> And that won't break the async model. + <bwright> Actually should be simpler if it is already designed for that. + <bwright> But would break the "distributed" vibe unless you had the faults + to those shared pages hit a page faulter that sent them over the network + on write. + <bwright> </end probably stupid ideas> + <kilobug> bwright: a lot of POSIX compatibility is handled by the glibc, + "porting" another libc to the Hurd will be a titanic task + <bwright> In theory exceptionless system calls work fine on glibc, it is + just harder to get them working. + <bwright> has not been done or was not explored in the paper. + <bwright> Something about it having a few too many annoying assumptions. + <bwright> Would be interesting to run some benchmarks on hurd and figure + out where the bottlenecks really are. + <bwright> At least for an exercise in writing good benchmarks :P + <bwright> I have a paper on the design of hurd I should read actually. + <bwright> After I get through this l4 ref man. + <braunr> the main bottleneck is scalability + <braunr> there are a lot of global locks + <braunr> and servers are prone to spawning lots of threads + <braunr> because, despite the fact mach provides async ipc, the hurd mostly + uses sync ipc + <braunr> so the way to handle async notifications is to receive messages + and spawn threads as needed + <bwright> Lets take a senario + <braunr> beyond that, core algorithms such as scanning pages in pagers, are + suboptimal + <bwright> I want to get a file and send it across the network. + <bwright> How many copies of the data occur? + <braunr> define send + <braunr> ouch :) + <braunr> disk drivers are currently in the kernel + <bwright> I read a block from disk, I pass this to my file system it passes + it to the app and it sends to the lwip or whatever interface then out the + ethernet card. + <braunr> and "block device drivers" in userspace (storeio) are able to + redirect file system servers directly to those in kernel drivers + <braunr> so + <braunr> kernel -> fs -> client -> pfinet -> netdde (user space network + drivers on debian hurd) + <bwright> Alright. Hopefully each arrow is not a copy :p + <braunr> it is + <bwright> My currently multiserver does this same thing with zero copy. + <braunr> because buffers are usually small + <braunr> yes but zero copy requires some care + <bwright> Which is possible. + <braunr> and usually, posix clients don't care about that + <bwright> Yes it requires a lot of care. + <bwright> POSIX ruins this + <bwright> Absolutely. + <braunr> they assume read/write copy data, or that the kernel is directly + able to access data + <bwright> But there are some things you can take care with + <bwright> And not break posix and still have this work. + <braunr> pfinet handles ethernet packets one at a time, and 1500 isn't + worth zero copying + <bwright> This depends though right? + <braunr> i'm not saying it's not possible + <braunr> i'm saying most often, there are copies + <bwright> So if I have high throughput I can load up lots of packets and + the data section can then be sectioned with scatter gather + <braunr> again, the current interface doesn't provide that + <bwright> Alright yeah that is what I expected which is fine. + <bwright> It will be POSIX compliant which is the main goal. + <braunr> not really scatter gather here but rather segment offloading for + example + <braunr> ah you're working on something like that too :) + <bwright> Yeah I am an intern :) + <bwright> Have it mostly working, just lots of pain. + <bwright> Have you read the netmap paper? + <bwright> Really interesting. + <braunr> not sure i have + <braunr> unless it has another full name + <bwright> 14.86 million packets per second out of the ethernet card :p + <bwright> SMOKES everything else. + <bwright> Implemented in Linux and FreeBSD now. + <bwright> Packets are UDP 1 byte MTU I think + <bwright> 1 byte data * + <bwright> To be correct :p + <braunr> right, i see + <bwright> Break posix again + <bwright> "More Extend" + <braunr> i've actually worked on a proprietary implementation of such a + thing where i'm currently working + <bwright> Bloody useful for high frequency trading etc. + <bwright> Final year as an undergraduate this year doing my thesis which + should be fun, going to be something OS hopefully. + <bwright> Very fun field lots of weird and crazy problems. diff --git a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn index 11bebd6e..b571b82e 100644 --- a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn +++ b/open_issues/libmachuser_libhurduser_rpc_stubs.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 @@ -107,6 +107,34 @@ License|/fdl]]."]]"""]] <antrik> now that's a good question... no idea TBH :-) +## IRC, freenode, #hurd, 2013-02-25 + + <braunr> we should also discuss the mach_debug interface some day + <braunr> it's not exported by libc, but the kernel provides it + <braunr> slabinfo depends on it, and i'd like to include it in the hurd + <braunr> but i don't know what kind of security problems giving access to + mach_debug RPCs would create + <braunr> (imo, the mach_debug interface should be adjusted to be used with + privileged ports only) + <braunr> (well, maybe not all mach_debug RPCs) + + +## IRC, freenode, #hurd, 2013-11-20 + + <braunr> [...] we have to make the mach_debug interface available + <braunr> well, i never took the time to integrate slabinfo into the hurd + repository + <braunr> because it relies on the mach_debug interface + <teythoon> ah + <braunr> while enabling that interface alone can't do harm, some debugging + functions shouldn't be usable by unprivileged applications + <braunr> so it requires some discussions + <braunr> i always delayed it because of more important stuff to do + <braunr> but slabinfo is actually very useful + <braunr> the more information we have about the system state, the better + <braunr> so it's actually important + + # IRC, freenode, #hurd, 2012-07-23 <pinotree> aren't libmachuser and libhurduser supposed to be slowly faded @@ -123,18 +151,6 @@ License|/fdl]]."]]"""]] <braunr> pinotree: libc should bring them -# IRC, freenode, #hurd, 2013-02-25 - - <braunr> we should also discuss the mach_debug interface some day - <braunr> it's not exported by libc, but the kernel provides it - <braunr> slabinfo depends on it, and i'd like to include it in the hurd - <braunr> but i don't know what kind of security problems giving access to - mach_debug RPCs would create - <braunr> (imo, the mach_debug interface should be adjusted to be used with - privileged ports only) - <braunr> (well, maybe not all mach_debug RPCs) - - # `gnumach.defs` [[!message-id diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn index 0b426884..0294b008 100644 --- a/open_issues/libpthread.mdwn +++ b/open_issues/libpthread.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 @@ -1303,6 +1303,7 @@ Most of the issues raised on this page has been resolved, a few remain. after the system has been alive for some time ? <braunr> (some time being at least a few hours, more probably days) + #### IRC, freenode, #hurd, 2013-07-05 <braunr> ok, found the bug about invalid ports when adjusting priorities @@ -1312,6 +1313,149 @@ Most of the issues raised on this page has been resolved, a few remain. [[libpthread/t/fix_have_kernel_resources]]. +#### IRC, freenode, #hurd, 2013-11-25 + + <braunr> youpi: btw, my last commit on the hurd repo fixes the urefs + overflow we've sometimes seen in the past in the priority adjusting code + of libports + + +#### IRC, freenode, #hurd, 2013-11-29 + +See also [[open_issues/libpthread/t/fix_have_kernel_resources]]. + + <braunr> there still are some leak ports making servers spawn threads with + non-elevated priorities :/ + <braunr> leaks* + <teythoon> issues with your thread destruction work ? + <teythoon> err, wait + <teythoon> why does a port leak cause that ? + <braunr> because it causes urefs overflows + <braunr> and the priority adjustment code does check errors :p + <teythoon> ^^ + <teythoon> ah yes, urefs... + <braunr> apparently it only affects the root file system + <teythoon> hm + <braunr> i'll spend an hour looking for it, and whatever i find, i'll + install the upstream debian packages so you can build glibc without too + much trouble + <teythoon> we need a clean build chroot on darnassus for this situation + <braunr> ah yes + <braunr> i should have time to set things up this week end + <braunr> 1: send (refs: 65534) + <braunr> i wonder what the first right is in the root file system + <teythoon> hm + <braunr> search doesn't help so i'm pretty sure it's a kernel object + <braunr> perhaps the host priv port + <teythoon> could be the thread port or something ? + <braunr> no, not the thread port + <teythoon> why would it have so many refs ? + <braunr> the task port maybe but it's fine if it overflows + <teythoon> also, some urefs are clamped at max, so maybe this is fine ? + <braunr> it may be fine yes + <braunr> err = get_privileged_ports (&host_priv, NULL); + <braunr> iirc, this function should pass copies of the name, not increment + the urefs counter + <braunr> it may behave differently if built statically + <teythoon> o_O y would it ? + <braunr> no idea + <braunr> something doesn't behave as it should :) + <braunr> i'm not asking why, i'm asking where :) + <braunr> the proc server is also affected + <braunr> so it does look like it has something to do with bootstrap + <teythoon> I'm not surprised :/ + + +#### IRC, freenode, #hurd, 2013-11-30 + + <braunr> so yes, the host_priv port gets a reference when calling + get_privileged_ports + <braunr> but only in the rootfs and proc servers, probably because others + use the code path to fetch it from proc + <teythoon> ah + <teythoon> well, it shouldn't behave differently + <braunr> ? + <teythoon> get_privileged_ports + <braunr> get_privileged_ports is explictely described to cache references + <teythoon> i don't get it + <teythoon> you said it behaved differently for proc and the rootfs + <teythoon> that's undesireable, isn't it ? + <braunr> yes + <teythoon> ok + <braunr> so it should behave differently than it does + <teythoon> yes + <teythoon> right + <braunr> teythoon: during your work this summer, have you come across the + bootstrap port of a task ? + <braunr> i wonder what the bootstrap port of the root file system is + <braunr> maybe i got the description wrong since references on host or + master are deallocated where get_privileged_ports is used .. + <teythoon> no, I do not believe i did anything bootstrap port related + <braunr> ok + <braunr> i don't need that any more fortunately + <braunr> i just wonder how someone could write a description so error-prone + .. + <braunr> and apparently, this problem should affect all servers, but for + some reason i didn't see it + <braunr> there, problem fixed + <teythoon> ? + <braunr> last leak eliminated + <teythoon> cool :) + <teythoon> how ? + <braunr> i simply deallocate host_priv in addition to the others when + adjusting thread priority + <braunr> as simple as that .. + <teythoon> uh + <teythoon> sure ? + <braunr> so many system calls just for reference counting + <braunr> yes + <teythoon> i did that, and broke the rootfs + <braunr> well i'm using one right now + <teythoon> ok + <braunr> maybe i should let it run a bit :) + <teythoon> no, for me it failed on the first write + <braunr> teythoon: looks weird + <teythoon> so i figured it was wrong to deallocate that port + <braunr> i'll reboot it and see if there may be a race + <teythoon> thought i didn't get a reference after all or something + <teythoon> I believe there is a race in ext2fs + <braunr> teythoon: that's not good news for me + <teythoon> when doing fsysopts --update / (which remounts /) + <teythoon> sometimes, the system hangs + <braunr> :/ + <teythoon> might be a deadlock, or the rootfs dies and noone notices + <teythoon> with my protected payload stuff, the system would reboot instead + of just hanging + <braunr> oh + <teythoon> which might point to a segfault in ext2fs + <teythoon> maybe the exception message carries a bad payload + <braunr> makes sense + <braunr> exception handling in ext2fs is messy .. + <teythoon> braunr: and, doing sleep 0.1 before remounting / makes the + problem less likely to appear + <braunr> ugh + <teythoon> and system load on my host system seems to affect this + <teythoon> but it is hard to tell + <teythoon> sometimes, this doesn't show up at all + <teythoon> sometimes several times in a row + <braunr> the system load might simply indicate very short lived processes + <braunr> (or threads) + <teythoon> system load on my host + <braunr> ah + <teythoon> this makes me believe that it is a race somewhere + <teythoon> all of this + <braunr> well, i can't get anything wrong with my patched rootfs + <teythoon> braunr: ok, maybe I messed up + <braunr> or maybe you were very unlucky + <braunr> and there is a rare race + <braunr> but i'll commit anyway + <teythoon> no, i never got it to work, always hung at the first write + <braunr> it won't be the first or last rare problem we'll have to live with + <braunr> hm + <braunr> then you probably did something wrong, yes + <braunr> that's reassuring + + ### IRC, freenode, #hurd, 2013-03-11 <braunr> youpi: oh btw, i noticed a problem with the priority adjustement @@ -1582,6 +1726,9 @@ Same issue as [[term_blocking]] perhaps? ## IRC, freenode, #hurd, 2013-01-06 <youpi> it seems fakeroot has become slow as hell + +[[pfinet_timers]]. + <braunr> fakeroot is the main source of dead name notifications <braunr> well, a very heavy one <braunr> with pthreads hurd servers, their priority is raised, precisely to @@ -2008,3 +2155,260 @@ Same issue as [[term_blocking]] perhaps? handling, but there are still a few bugs remaining <braunr> fyi, the related discussion was https://lists.gnu.org/archive/html/bug-hurd/2012-08/msg00057.html + + +## IRC, freenode, #hurd, 2014-01-01 + + <youpi> braunr: I have an issue with tls_thread_leak + <youpi> int main(void) { + <youpi> pthread_create(&t, NULL, foo, NULL); + <youpi> pthread_exit(0); + <youpi> } + <youpi> this fails at least with the libpthread without your libpthread + thread termination patch + <youpi> because for the main thread, tcb->self doesn't contain thread_self + <youpi> where is tcb->self supposed to be initialized for the main thread? + <youpi> there's also the case of fork()ing from main(), then calling + pthread_exit() + <youpi> (calling pthread_exit() from the child) + <youpi> the child would inherit the tcb->self value from the parent, and + thus pthread_exit() would try to kill the father + <youpi> can't we still do tcb->self = self, even if we don't keep a + reference over the name? + <youpi> (the pthread_exit() issue above should be fixed by your thread + termination patch actually) + <youpi> Mmm, it seems the thread_t port that the child inherits actually + properly references the thread of the child, and not the thread of the + father? + <youpi> “For the name we use for our own thread port, we will insert the + thread port for the child main user thread after we create it.” Oh, good + :) + <youpi> and, “Skip the name we use for any of our own thread ports.”, good + too :) + <braunr> youpi: reading + <braunr> youpi: if we do tcb->self = self, we have to keep the reference + <braunr> this is strange though, i had tests that did exactlt what you're + talking about, and they didn't fail + <youpi> why? + <braunr> if you don't keep the reference, it means you deallocate self + <youpi> with the thread termination patch, tcb->self is not used for + destruction + <braunr> hum + <braunr> no it isn't + <braunr> but it must be deallocated at some point if it's not temporary + <braunr> normally, libpthread should set it for the main thread too, i + don't understand + <youpi> I don't see which code is supposed to do it + <youpi> sure it needs to be deallocated at some point + <youpi> but does tcb->self has to wear the reference? + <braunr> init_routine should do it + <braunr> it calls __pthread_create_internal + <braunr> which allocates the tcb + <braunr> i think at some point, __pthread_setup should be called for it too + <youpi> but what makes pthread->kernel_thread contain the port for the + thread? + <braunr> but i have to check that + <braunr> __pthread_thread_alloc does that + <braunr> so normally it should work + <braunr> is your libpthread up to date as well ? + <youpi> no, as I said it doesn't contain the thread destruction patch + <braunr> ah + <braunr> that may explain + <youpi> but the tcb->self uninitialized issue happens on darnassus too + <youpi> it just doesn't happen to crash because it's not used + <braunr> that's weird :/ + <youpi> see ~youpi/test.c there for instance + <braunr> humpf + <braunr> i don't see why :/ + <braunr> i'll debug that later + <braunr> youpi: did you find the problem ? + <youpi> no + <youpi> I'm working on fixing the libpthread hell in the glibc debian + package :) + <youpi> i.e. replace a dozen patches with a git snapshot + <braunr> ah you reverted commit + <braunr> +a + <braunr> i imagine it's hairy :) + <youpi> not too much actually + <braunr> wow :) + <youpi> with the latest commits, things have converged + <youpi> it's now about small build details + <youpi> I just take time to make sure I'm getting the same source code in + the end :) + <braunr> :) + <braunr> i hope i can determine what's going wrong tonight + <braunr> youpi: avec mach_print, je vois bien self setté par la libpthread + .. + <youpi> mais à autre chose que 0 ? + <braunr> oui + <braunr> bizarrement, l'autre thread n'as pas la même valeur + <braunr> tu es bien sûr que c'est self que tu affiches avec l'assembleur ? + <braunr> oops, english + <youpi> see test2 + <youpi> so I'm positive + <braunr> well, there obviously is a bug + <braunr> but are you certain your assembly code displays the thread port + name ? + <youpi> I'm certain it displays tcb->self + <braunr> oh wait, hexadecimal, ok + <youpi> and the value happens to be what mach_thread_self returns + <braunr> ah right + <youpi> ah, right, names are usually decimals :) + <braunr> hm + <braunr> what's the problem with test2 ? + <youpi> none + <braunr> ok + <youpi> I was just checking what happens on fork from another thread + <braunr> ok i do have 0x68 now + <braunr> so the self field gets erased somehow + <braunr> 15:34 < youpi> this fails at least with the libpthread without + your libpthread thread termination patch + <braunr> how does it fail ? + <youpi> ../libpthread/sysdeps/mach/pt-thread-halt.c:44: + __pthread_thread_halt: Unexpected error: (ipc/send) invalid destination + port. + <braunr> hm + <braunr> i don't have that problem on darnassus + <youpi> with the new libc? + <braunr> the pthread destruction patch actually doesn't use the tcb->self + name if i'm right + <braunr> yes + <braunr> what is tcb->self used for ? + <youpi> it used to be used by pt-thread-halt + <youpi> but is darnassus using your thread destruction patch? + <youpi> as I said, since your thread destruction pathc doesn't use + tcb->self, it doesn't have the issue + <braunr> the patched libpthread merely uses the sysdeps kernel_thread + member + <braunr> ok + <youpi> it's the old libpthread against the new libc which has issues + <braunr> yes it is + <braunr> so for me, the only thing to do is make sure tcb->self remains + valid + <braunr> we could simply add a third user ref but i don't like the idea + <youpi> well, as you said the issue is rather that tcb->self gets + overwritten + <youpi> there is no reason why it should + <braunr> the value is still valid when init_routine exits, so it must be in + libc + <youpi> or perhaps for some reason tls gets initialized twice + <braunr> maybe + <youpi> and thus what libpthread's init writes to is not what's used later + <braunr> i've add a print in pthread_create, to see if self actually got + overwritten + <braunr> and it doesn't + <braunr> there is a disrepancy between the tcb member in libpthread and + what libc uses for tls + <braunr> added* + <braunr> (the print is at the very start of pthread_create, and displays + the thread name of the caller only) + <youpi> well, yes, for the main thread libpthread shouldn't be allocating a + new tcb + <youpi> and just use the existing one + <braunr> ? + <youpi> the main thread's tcb is initialized before the threading library + iirc + <braunr> hmm + <braunr> it would make sense if we actually had non-threaded programs :) + <youpi> at any rate, the address of the tcb allocated by libpthread is not + put into registers + <braunr> how does it get there for the other threads ? + <youpi> __pthread_setup does it + <braunr> so + <braunr> looks like dl_main is called after init_routine + <braunr> and it then calls init_tls + <braunr> init_tls returns the tcb for the main thread, and that's what + overrides the libpthread one + <youpi> yes, _hurd_tls_init is called very early, before init_routine + <youpi> __pthread_create_internal could fetch the tcb pointer from gs:0 + when it's the main thread + <braunr> so there is something i didn't get right + <braunr> i thought _hurd_tls_init was called as part of dl_main + <youpi> well, it's not a bug of yours, it has always been bug :) + <braunr> which is called *after* init_routine + <braunr> and that explains why the libpthread tcb isn't the one installed + in the thread register + <braunr> i can actually check that quite easily + <youpi> where do you see dl_main called after init_routine? + <braunr> well no i got that wrong somehow + <braunr> or i'm unable to find it again + <braunr> let's see + <braunr> init_routine is called by init which is called by _dl_init_first + <braunr> which i can only find in the macro RTLD_START_SPECIAL_INIT + <braunr> with print traces, i see dl_main called before init_routine + <braunr> so yes, libpthread should reuse it + <braunr> the tcb isn't overriden, it's just never installed + <braunr> i'm not sure how to achieve that cleanly + <youpi> well, it is installed, by _hurd_tls_init + <youpi> it's the linker which creates the main thread's tcb + <youpi> and calls _hurd_tls_init to install it + <youpi> before the thread library enters into action + <braunr> agreed + + +### IRC, freenode, #hurd, 2014-01-14 + + <braunr> btw, are you planning to do something with regard to the main + thread tcb initialization issue ? + <youpi> well, I thought you were working on it + <braunr> ok + <braunr> i wasn't sure + + +### IRC, freenode, #hurd, 2014-01-19 + + <braunr> i have some fixup code for the main thread tcb + <braunr> but it sometimes crashes on tcb deallocation + <braunr> is there anything particular that you would know about the tcb of + the main thread ? + <braunr> (that could help explaining this) + <youpi> Mmmm, I don't think there is anything particular + <braunr> doesn't look like the first tcb can be reused safely + <braunr> i think we should instead update the thread register to point to + the pthread tcb + <youpi> what do you mean by "the first tcb" exactly? + + +## IRC, freenode, #hurd, 2014-01-03 + + <gg0> braunr: hurd from your repo can't boot. restored debian one + <braunr> gg0: it does boot + <braunr> gg0: but you need everything (gnumach and glibc) in order to make + it work + <braunr> i think youpi did take care of compatibility with older kernels + <teythoon> braunr: so do we need a rebuilt libc for the latest hurd from + git ? + <braunr> teythoon: no, the hurd isn't the problem + <teythoon> ok + <teythoon> good + <braunr> the problem is the libports_stability patch + <teythoon> what about it ? + <braunr> the hurd can't work correctly without it since the switch to + pthreads + <braunr> because of subtle bugs concerning resource recycling + <teythoon> ok + <braunr> these have been fixed recently by youpi and me (youpi fixed them + exactly as i did, which made my life very easy when merging :)) + <braunr> there is also the problem of the stack sizes, which means the hurd + servers could use 2M stacks with an older glibc + <braunr> or perhaps it chokes on an error when attempting to set the stack + size because it was unsupported + <braunr> i don't know + <braunr> that may be what gg0 suffered from + <gg0> yes, both gnumach and eglibc were from debian. seems i didn't + manually upgrade eglibc from yours + <gg0> i'll reinstall them now. let's screw it up once again + <braunr> :) + <braunr> bbl + <gg0> ok it boots + <gg0> # apt-get install + {hurd,hurd-dev,hurd-libs0.3}=1:0.5.git20131101-1+rbraun.7 + {libc0.3,libc0.3-dev,libc0.3-dbg,libc-dev-bin}=2.17-97+hurd.0+rbraun.1+threadterm.1 + <gg0> there must a simpler way + <gg0> besides apt-pinning + <gg0> making it a real "experimental" release might help with -t option for + instance + <gg0> btw locales still segfaults + <gg0> rpctrace from teythoon gets stuck at + http://paste.debian.net/plain/74072/ + <gg0> ("rpctrace locale-gen", last 300 lines) diff --git a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn index feea7c0d..02b6ab05 100644 --- a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn +++ b/open_issues/libpthread/t/fix_have_kernel_resources.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 @@ -477,3 +478,824 @@ Address problem mentioned in [[/libpthread]], *Threads' Death*. failing bad <braunr> i just need to polish a few things, wait for youpi to finish his work on TLS to resolve conflicts, and that will be all + + +## IRC, freenode, #hurd, 2013-10-30 + + <braunr> FYI, the packages on my repository enable actual thread + destruction, and i've altered the libports_stability.patch + <braunr> it nows only sets the global timeout to 0 + <braunr> now* + <braunr> we actually can't let translator "die" on global timeout because + of a race issue + <braunr> tested for about two weeks now and no major problem sighted + <braunr> top reports processes running for 100% of their time when + terminating threads, but i expect it's simply mach/proc aggregating their + run time to the task + <braunr> 100% of cpu time + + +## IRC, freenode, #hurd, 2013-11-08 + + <braunr> teythoon: darnassus is currently running a modified glibc with + thread destruction, yes + <teythoon> braunr: did that require any fixups in Hurd that I'd have missed + ? + <braunr> no + <braunr> well + <teythoon> b/c the resulting hurd package would not boot + <braunr> actually yes + <braunr> one + <braunr> i'll push the patch somewhere + <teythoon> iirc the mach-defpager spewed some error and /hurd/init failed + to bootstrap the system + <braunr> teythoon: + http://darnassus.sceen.net/~rbraun/0001-Prevent-diskfs-translators-from-destroying-main-thre.patch + <braunr> make sure you have the proper gnumach packages too :p + <teythoon> well, that could very well account for my trouble ;) + <teythoon> uh + <teythoon> well + <braunr> gnumach implements thread destruction, glibc uses it, hurd makes + sure it doesn't exit from main + + +## IRC, freenode, #hurd, 2013-11-12 + + <braunr> ok so, calling pthread_exit() from main isn't the same as + returning from main() + <braunr> unlike what some man pages seem to say + <braunr> so loosing task info when destroying the main thread is actually a + proc bug + <braunr> ugh + <teythoon> ^^ + <braunr> or a glibc one + <teythoon> the proc server, your favorite Hurd component... + <braunr> :) + <braunr> hm :/ + <braunr> looks like command line arguments are stored on the stack of the + main thread + <braunr> and proc merely receives the addresses of those in the target task + <neal> why not just keep the main thread around? + <neal> it represents a minor resource leak, true + <braunr> yes + <braunr> that's the hack i suggested + <neal> but it is relatively small + <braunr> well no + <braunr> my hack was about diskfs translators + <braunr> it should be generalized in libpthread + <braunr> seems reasonable + <braunr> let's do it >) + + +## IRC, freenode, #hurd, 2013-11-13 + + <youpi> braunr: there is a thread destruction issue in the experimental + ocaml build, worth looking at, probably + <braunr> what do you mean ? + <youpi> ... testing 'testfork.ml': ocamlcocamlrun: + ../libpthread/sysdeps/mach/pt-thread-halt.c:51: __pthread_thread_halt: + Unexpected error: (ipc/send) invalid destination port. + <youpi> during the experimental ocaml build + <braunr> well yes + <braunr> thread recycling is buggy + <braunr> i had the choice to fix it, or implement true destruction + <braunr> i'm tweaking my patch so it leaves the main thread stack untouched + on destruction + <braunr> and it should be ready + <braunr> for review at least + + +## IRC, OFTC, #debian-hurd, 2013-11-13 + + <gg0> ironforge out of memory during ruby1.9.1 rebuild. during test which + creates 10000 threads + <gg0> ironforge out of memory during ruby1.9.1 rebuild, test which creates + 10000 threads + <gg0> i guess ironforge kernel has been rebuilt against -95, correct? + <youpi> err, what kernel? + <gg0> 23:37 < youpi> hurd needs a rebuild to be able to work with the newer + eglibc + <gg0> i mean hurd + <youpi> yes, libc0.3 breaks the old packages anyway + <gg0> wrt ENOMEM, was it expected? + <gg0> wrt disk problems, aren't there on alioth only? + <youpi> well 10,000 threads is a lot, especially on 32bit machine with 2M + default stack size + <youpi> that makes 2GiB stacks + <youpi> can't fit in a 2/2 split model, which gnumach uses + <gg0> well, though active thread should die right away, just after set x to + false, if i read it correctly + <youpi> perhaps the stacks are not correctly reused + <youpi> that's probably worth digging in libpthread + <youpi> by putting printfs, etc. + <youpi> it seems stacks are never reused indeed, damn + <youpi> I just wrote a small test that creates threads which just print + their stack address + <youpi> that takes just a few minutes to do + <gg0> i see. about reusage i guess you mean base address is kindof always + incremented + * gg0 likes being wrong + <youpi> that's it, yes + <youpi> gg0: take care, by keeping being wrong all the time, sometimes you + get right ;) + <youpi> and you are definitely right here :) + <youpi> Mmm, but the stack is really deallocated + <youpi> and the numbers wrap around + <youpi> I wonder how that is :) + <youpi> ok, creating 20 000 threads does work + <youpi> perhaps ruby does odd things which makes it not work + + +### IRC, OFTC, #debian-hurd, 2013-11-14 + + <gg0> UID PID PPID TH MSGI MSGO SZ RSS SC STAT TIME COMMAND + <gg0> 1012 16446 15473 720 987 509 1.89G 23.6M 1 Hu 0:00.15 + /home/gg0-guest/ruby/ruby1.9.git/ruby1.9.1 + -I/home/gg0-guest/ruby/ruby1.9.git/lib -W0 bootstraptest.tmp.rb + <gg0> 720 threads, stuck + <youpi> 2G SZ is very big :) + <gg0> 00:42 < youpi> perhaps ruby does odd things which makes it not work + <gg0> is that enough to file a ruby bug? as ruby suggests itself btw + <youpi> no, they will probably not be able to investigate + <youpi> but you can already check out how they create threads + <youpi> and try to reproduce the same with a small C program + <gg0> ehm on ruby2.0 with *context _enabled_ i can not reproduce it + +See [[/open_issues/glibc]] for `*context` functions. + + +## IRC, freenode, #hurd, 2013-11-14 + + <braunr> nice, i got glibc packages with thread destruction + <braunr> building hurd packages against it now + <braunr> everything seems fine + <braunr> hurd packages ready, let's see + + <gg0> ruby1.9.1 FTBFS due to a couple of tests + https://buildd.debian.org/status/fetch.php?pkg=ruby1.9.1&arch=hurd-i386&ver=1.9.3.448-1&stamp=1384265526 + <gg0> second one creates 10000 threads and machine got ENOMEM + <braunr> bootstraptest.tmp.rb: [BUG] [BUG] pthread_cond_init: Cannot + allocate memory (ENOMEM) ew + <gg0> few hours ago trying to reproduce it: + <gg0> 01:20 < gg0> UID PID PPID TH MSGI MSGO SZ RSS SC STAT + TIME COMMAND + <gg0> 01:20 < gg0> 1012 16446 15473 720 987 509 1.89G 23.6M 1 Hu + 0:00.15 /home/gg0-guest/ruby/ruby1.9.git/ruby1.9.1 + -I/home/gg0-guest/ruby/ruby1.9.git/lib -W0 bootstraptest.tmp.rb + <braunr> yes that's expected + <braunr> our stacks are 2M + <braunr> 10k threads means right over 2G of stacks + <braunr> userspace is restricted to 2G + <gg0> but if i read correctly test in question, thread should just set x to + false then die + <braunr> so ? + <gg0> and ENOMEM popped upk when there were thread count was at 720 + <braunr> hum + <braunr> 10k threads would actually be 20G + <braunr> 1k threads is 2G + <braunr> 720 is about 1.5G + <braunr> the rest is probably the ruby runtime + <gg0> youpi tried to create 10000 thread, no problem. he guessed something + wrong on ruby side + <gg0> indeed on ruby2.0 such test succeeds + <braunr> you can't create 10k threads unless you change the stack size + <braunr> hurd servers use a stack size of 64k by default which allows them + to go up to 30k iirc + <braunr> but normal applications use the default 2M + <gg0> i guess you mean 10000 threads active at the same time. test in + question should make them die after simply setting x to false, i guess + youpi's test did so as well + <braunr> no + <braunr> it's about stacks + <braunr> hm + <braunr> yes at the same time but + <braunr> thread recycling is known to be buggy + <braunr> which is what i'm currently fixing btw + <neal> what's the bug? + <braunr> neal: there are several subtle issues + <braunr> for example, joining a thread that is also calling pthread_exit + can fail badly + <neal> hmm + <neal> good that you are on it then :) + <braunr> or detaching + <braunr> i don't remember the details + <braunr> but i remember such problems + <braunr> apparently, keeping the stack of the main thread isn't enough + <braunr> :( + <braunr> for now, i'll keep the entire thread + + +## IRC, freenode, #hurd, 2013-11-15 + + <gg0> i wasn't doing anything, just some single test runs. but yes, also + that one which creates hundreds of threads + <gg0> it would like creating 10000 but goes out of memory after ~720 + <gg0> btw same tests succeed on ruby2.0, so they should be fixed by + backporting some changes + <braunr> actually it looks more like a deadlock .. + <gg0> deadlock that says ENOMEM? + <braunr> ? + <braunr> ENOMEM is returned because the test task has no more virtual + memory + <braunr> this doesn't mean the rest of the system should fail + <gg0> ok i thought you were talking about such test + <braunr> no it's something else + <braunr> a deadlock in a critical server + <braunr> the root file system maybe + <gg0> braunr: htop and ps hang. just run the test once again + <gg0> now you should still be able to login + <braunr> htop/ps hanging means one process is unable to reply to queries + sent to the message port/thread + <braunr> procfs does that to report on what a process is waiting + <braunr> it usually mean there is a bug around signals, since the message + thread is also in charge of delivering signals + <braunr> use ps -eM + <braunr> and kill -KILL + <braunr> hum + <braunr> root 954 S<o 0:00.05 /hurd/crash --dump-core + <braunr> dumping cores is known not to work most of the time + <braunr> exodar shouldn't be configured like that + <braunr> so yes, the crash server is hanging + <braunr> gg0: i've set it to crash --kill and killed the hanging crash + instances blocking top/ps + <gg0> nice + + <braunr> my thread destruction patch and tls are indeed conflicting a bit + <braunr> i suspect the tcb is used after being freed + <braunr> i think i'll simply recycle the tcb, along with the pthread + structs + <braunr> ok i think it's fine now + <braunr> there was also a small bug in the tls code, keeping a reference on + the thread port + <braunr> mach reference counting is so counter intuitive :/ + <braunr> well, error-prone + + <braunr> argh, more bugs in libc :( + <teythoon> :/ + <teythoon> but don't worry, there is always one more bug ;) + <braunr> this one might explain crashes that are long to trigger + <braunr> _hurd_self_sigstate() is implemented like this : + _hurd_thread_sigstate (__mach_thread_self ()); + <braunr> it leaks a reference on the current thread each time it's called + <teythoon> >,< + <braunr> but glibc maintains such references, so if the maximum value is + reached, and references are dropped, the value can reach 0 + <teythoon> ouch + <braunr> at which point any call on a thread will result in an invalid send + right + <braunr> and probably an assertion + <teythoon> well it's a good thing then that you found it :) + <braunr> i think it's always been there + <braunr> but it's more apparent since jknoenig's patch on signal + dispositions + <braunr> the maximum number of user references in mach is 64k + <braunr> this right leak isn't easy + <braunr> tls is very tricky heh :) + <braunr> for the main thread, tls initialization happens after the thread + creation, obviously + <braunr> but for other threads, it's initialized before starting them + <braunr> the leak was probably an overlook caused by that complexity + <braunr> teythoon: actually that leak i mentioned in _hurd_self_sigstate + has only been recently added in Convert sigstate to TLS + <braunr> so it's merely tls integration polishing + <braunr> youpi: i'm currently reviewing changes related to tls and i think + there is a bug in _hurd_self_sigstate + <braunr> calls to mach_thread_self() should be paired with + mach_port_deallocate to avoid urefs overflows + <braunr> and right leaks + <braunr> _hurd_critical_section_lock is probably affected too + <braunr> hm + <braunr> mhmm + <braunr> in glibc, hurd/hurd/signal.h, _hurd_critical_section_lock + <braunr> why is the sigstate unlocked after the call to + _hurd_thread_sigstate + <braunr> _hurd_thread_sigstate doesn't seem to lock it .. + <braunr> unless __spin_lock_init does it + <braunr> yes, leak solved :) + + +## IRC, freenode, #hurd, 2013-11-16 + + <braunr> argh, _hurd_critical_section_lock is called before the send right + on the main thread is fetched in libpthread :/ + <teythoon> is that bad ? + <braunr> the sigstate is supposed to be initialized after pthreads + <braunr> _hurd_critical_section_lock will create it if it sees there is + none + <braunr> creating the sigstate is currently what makes the send right leak + <teythoon> ok + <teythoon> it's bad then + <braunr> it may be due to my patch + <braunr> _hurd_critical_section_lock is called during pthreads + initializatio + <braunr> n + <braunr> before the sigstate for the main thread is created, but after the + pthread init routine is called + <braunr> it does indeed look like the code wasn't written with thread being + destroyed some day in mind :/ + <teythoon> braunr: btw, if you ever feel like benchmarking, sysbench has a + benchmark for threads contending for a lock + <braunr> yes i've used it before + <teythoon> was it useful for this purpose ? + <braunr> no :) + <teythoon> :/ + <braunr> we already know libpthread isn't optimized + <braunr> and felt it when we switched from cthreads + <braunr> humpf + <braunr> simply calling malloc implies a call to + _hurd_critical_section_lock + <braunr> on the other hand, unlike what some glibc comments say, this does + work + + +## IRC, freenode, #hurd, 2013-11-17 + + <braunr> looks like i've fixed all leak issues with thread destruction and + tls :) + <braunr> let's see if ext2fs.static works fine too + <youpi> braunr: \o/ + <youpi> sorry about introducing the tls ones :) + <braunr> no worries, it was expected + <braunr> and tls was really needed :) + <braunr> i mean, i expected to have some problems when rebasing on tls :p + <teythoon> braunr: this is good news, how is your rootfs translator holding + up? + <braunr> building hurd packages right now + <braunr> for now, only test applications and a few really multithreaded + ones (e.g. iceweasel) have been tested + <braunr> well, the system boots :) + <teythoon> awesome :) + <braunr> stressing the file system with git while watching youtube videos + with gnash doesn't make the system crash + <teythoon> you can actually watch yt videos on your Hurd box ? + <braunr> yes + <braunr> for a while now + <teythoon> o_O + <braunr> can't you ? + <teythoon> I never even dared to try + <braunr> hehe + <braunr> teythoon: looks stable enough to install on darnassus + + +## IRC, freenode, #hurd, 2013-11-18 + + <teythoon> braunr: wrt to your thread destruction patchset, I thought you + also had to fix the proc server ? + <braunr> teythoon: no + <braunr> the problem was in glibc + <braunr> i may have to fix proc/procfs though, because cpu time gets wrong + with the patch + <braunr> currently, it's the addition of the cpu time of all threads + <braunr> mach provides aggregate times including destroyed threads though + <teythoon> ah, I see + <braunr> one side effect is that you'll see processes sometimes taking 100% + of cpu time although the cpu is unused + <braunr> or the cpu time of a process gets reduced :) + <braunr> i guess the 100% cpu is how top sees a negative increment + <teythoon> ^^ + <braunr> gg0: do my threadterm packages help with ruby1.9 ? + <braunr> i mean, can you test with them some time ? :) + + +## IRC, freenode, #hurd, 2013-11-21 + + <braunr> youpi: ping about my question regarding error handling in the + proposed thread_terminate_release call + <youpi> I agree with what Neal said + <braunr> he didn't say anything about error handling + <braunr> see + http://lists.gnu.org/archive/html/bug-hurd/2013-11/msg00181.html + <braunr> i think i should make the call fail on first error + <braunr> it shouldn't happen, so it would merely serve to catch bugs + <braunr> it's not easily recoverable (if it's recoverable at all) + <youpi> uh, I thought he had + <youpi> I must have dreamt + + <braunr> i think i'll go ahead with thread destruction integration + + +## IRC, freenode, #hurd, 2013-11-25 + + <braunr> i've pushed the thread destruction patches for gnumach upstream + <braunr> and made a branch in glibc for that too + <teythoon> awesome :) + <braunr> youpi: i don't remember how glibc changes should be managed + <braunr> once those are applied, i'll commit in libpthread + <youpi> braunr: usually we create a topgit branch, and then we add the + patch from that to the debian repository + + +## IRC, freenode, #hurd, 2013-11-29 + + <braunr> youpi: i still have a leak somewhere with the thread destruction + patches + <braunr> maybe on the host priv port in bootstrap servers (root fs and proc + server) + <braunr> it prevents priority adjusting in libports and can easily bring + down a system because servers can start trashing a lot sooner, as it was + the case during the pthread migration + +See discussion about that on [[/open_issues/libpthread]]. + + <braunr> so i'll hunt it down before merging + + +## IRC, freenode, #hurd, 2013-12-19 + + <braunr> darnassus still has the libports priority adjustement leaks + <braunr> i'll apply a few more patches to my hurd packages + + <braunr> humpf, proc seems to have a problem getting the host priv port :/ + <teythoon> thats bad + <teythoon> what did you do ? + <braunr> i fixed all the leaks in libports when adjusting priorities + <braunr> the last one being releasing the host priv right + <braunr> and i get errors at boot time from the proc server + <teythoon> remember when i had this problem ? + <braunr> proc doesn't get the host priv port the normal way since the + normal way is to get it from proc iirc + <teythoon> ah, thought you fixed that + <braunr> so i guess the alternate way doesn't add a reference + <braunr> well the leak is fixed + <braunr> the problem you had was due to the leak which made the host priv + port reach its max uref value + <braunr> now it's just the proc server + <braunr> the system works fine though + <teythoon> for real ? + <teythoon> the proc server needs the host priv port for getting the new + tasks + <braunr> well yes + <teythoon> how can it work w/o it ? + <braunr> i don't know .. + <braunr> i guess the problem is internal to glibc + <braunr> i mean, get_priv_ports fails, but that doesn't mean the host priv + port is lost + <teythoon> could be + <teythoon> are you running a patched rootfs translator too ? + <braunr> yes + <teythoon> ok + <teythoon> b/c i remember having trouble with that + <braunr> right, the glibc call would make proc call __proc_getprivports + <braunr> hum + <braunr> teythoon: do you remember how proc gets its host priv port ? + <teythoon> from init + <teythoon> i think + <braunr> startup_procinit ? + <teythoon> possibly + <braunr> right + <braunr> so it's probably not the host priv port + <braunr> i mean, the error is about another invalid send right + <braunr> hm nope, it is on host_priv :/ + <braunr> hm ok i see, looks like a bug from a debian patch + <braunr> or rather, a bug fix not yet imported into the debian package + <braunr> teythoon: you actually fixed it in + 2c9422595f41635e2f4f7ef1afb7eece9001feae + <braunr> great :) + <teythoon> ah, that one + <braunr> i was looking at the upstream code and couldn't understand what + was going wrong + <braunr> :) + <braunr> much better + <braunr> except ps -eT doesn't work any more .. + <braunr> interestingly, with the thread destruction patch, ps -eT sometimes + work, and sometimes doesn't + <braunr> the behaviour doesn't seem to change without a reboot + <braunr> and of course, as soon as i say it, i'm proven wrong by the next + test :) + + +## IRC, freenode, #hurd, 2013-12-26 + + <braunr> __pthread_sigstate_init doesn't seem to be converted to TLS in the + upstream repository master branch + + <braunr> ah dammit, the global signal dispositions patch touches both glibc + and libpthread @#! + <braunr> what a mess + + <braunr> youpi: do you have some time to quickly review the + rbraun/thread_destruction branch in libpthread ? + <braunr> there might be conflict with some glibc patches + <braunr> or do you prefer it on the mailing list ? + <braunr> (i used a branch because it's not based on master) + <youpi> rather mail the list, yes + <braunr> ok + <youpi> it'd also be useful to write the rationale + <youpi> probably to be left as comment in the source code + <braunr> yes, that branch was for personal storage :) + <youpi> so the reader knows how things are recycled or not + <braunr> hm + <braunr> that should already be the case + <youpi> ok + <braunr> the two structures that are still recycled are the pthread struct + and tls + <braunr> it's quite obvious from pthread_alloc + <braunr> and well commented there + <braunr> for tls, it's explained in pthread_exit + + <braunr> there, thread destruction finally merged in + <braunr> and now, we can remove the ugly hacks that were done for + threadvars + <braunr> :) + <braunr> change stacks at will and support all sorts of weird languages and + runtimes + <teythoon> braunr: cool :) + + +## IRC, freenode, #hurd, 2013-12-31 + + <youpi1> braunr: I've added sigstate_locking, sigstate_thread_reference and + tls_thread_leak to the debian glibc 2.18 package + <youpi1> I believe that's complete? + <youpi1> is mach_msg_uspace_options ready for being added? Does it bring + much speedup? + <youpi1> AIUI, thread_terminate_release is the union of the branches + mentioned above? + <youpi1> (I'm cleaning up branches in the glibc repo) + <braunr> youpi1: mach_msg_uspace_options can be left over, it only affects + selects and not noticeably + <braunr> yes, those three branches are the only ones needed for thread + destruction + <youpi1> ok + <youpi> does the hurd changes depend on these changes ? + <braunr> no + <youpi> good :) + <braunr> only on tls for one of them + <braunr> (it's about the default stack size of 64k for hurd servers) + <youpi> and we have had this in debian for a long time already :) + <braunr> yes + <youpi> (how big were they before?) + <youpi> (where they a couple MiB, and thus exploding to GiBs on thousands + of threads?) + <braunr> 64k + <braunr> pthread stacks are 2M by default + <braunr> yes + + +## IRC, freenode, #hurd, 2014-01-14 + + <youpi> braunr: it seems your time change in libps made ps produce odd re + <youpi> results + <youpi> samy 10987 5 -514358:-18:-42.17 /hurd/firmlink tmp + <braunr> youpi: wow :) + <braunr> that change is supposed to run on a system where threads actually + get destroyed + <braunr> but i don't see what could trigger this side effect + <youpi> root 8629 664 56 years make -j 3 + <youpi> :) + <braunr> heh + <braunr> youpi: does the hurd package on darnassus include that patch ? + <youpi> yes + <braunr> i don't reproduce the problem :/ + <youpi> err + <braunr> what command are you using ? + <youpi> ps -feM on darnassus + <youpi> root 29642 473 7 months /usr/sbin/sshd -R + <braunr> hmmmm + <braunr> i don't see it with a make -j + <youpi> well, it's not systematic + <youpi> it's like once over two launches + <braunr> hhhhmmmmm + <youpi> it'd look like some random numbers get added + <braunr> strangely, the gcc processes started by a recursive make aren't + children of make .. + <braunr> ps -eF hurd seems to report the correct values + <braunr> even ps -eM + <braunr> oO + <braunr> ps -ef too + <braunr> the problem seems to be with ps -efM + <youpi> too bad I'm always using that :) + <braunr> another way to see it is that it makes us spot the issue ;p + + +### IRC, freenode, #hurd, 2014-01-15 + + <braunr> ok i have an idea of what goes wrong in libps + + <braunr> youpi: for some reason, ps -efM lacks the PSTAT_TASK_BASIC flag + <braunr> my patch is wrong since it doesn't try to determine whether the + stats apply to a task or a thread, but that is easy to fix + <braunr> ps -efM should nonetheless provide basic task info, obviously + <braunr> in addition, the problems i've observed with ps -T (occasional + segfaults) seem to have existed before thread destruction + <braunr> they're just strongly exposed now that the thread list can be + shrunk + + <braunr> libps is quite complicated + <braunr> even hairy, i'd say .. + + +### IRC, freenode, #hurd, 2014-01-16 + + <braunr> youpi: i think i have a proper fix for libps + <braunr> i'll commit it soon + <youpi> ok + <braunr> basically, getting system times simply set the PSTAT_THREAD_BASIC + flag + <braunr> whereas getting the run time of the terminated threads requires + PSTAT_TASK_BASIC + <braunr> i assumed it was always set in the function i changed when dealing + with a task and not a thread + <braunr> and well, that was a wrong assumtion, -M can remove it if not + strictly needed by the format + <braunr> the default format asks for suspend_count, which forces the + retrieval of task basic info, os it works with -eM + <braunr> but -f doesn't :) + <youpi> so extremely bad lucky combination of flags :) + <braunr> indeed + <braunr> i added a pstat_times using the last (!) available flag bit + <braunr> looks clean to me + <braunr> i hope there is no abi issue + <braunr> (at least everything works with the unmodified ps-hurd executable + and a new libps.so) + + <braunr> hm, small bug in the thread destruction patch :/ + + +### IRC, freenode, #hurd, 2014-01-17 + + <braunr> good, i have proper fixes for tls in the main thread and thread + termination :) + <teythoon> awesome :) + <teythoon> i've been wondering, what does it take to get the thread + destruction stuff into the debian package ? + <braunr> i still have to build test packages, look for (unlikely, heh) + regressions and work some integration details with samuel + <braunr> hum the main thread tls fixup i guess + <braunr> youpi was waiting for me to fix that + <braunr> gnumach already provides the RPC + <braunr> so it will be in glibc soon + <braunr> i just have to get those last bits right + <braunr> teythoon: i'm quite slow at integrating stuff + <teythoon> and samuel then builds packages ? + <teythoon> i mean, is our libc package build linked to the other libc + packages ? + <braunr> libpthread is applied as a patch to glibc + <braunr> and loaded as a plugin + + +## IRC, freenode, #hurd, 2014-01-17 + + <braunr> uhm, did we break fakeroot-tcp ? + <teythoon> we did ? + <youpi> fakeroot-tcp just works fine on buildds + <braunr> with fakeroot-tcp, i get + <braunr> make[4]: Entering directory + `/home/rbraun/devel/debian/packages/hurd/hurd-0.5.git20140113/libdde-linux26/contrib/include' + <braunr> rm -f .general.d + <braunr> make[4]: *** [cleanall] Killed + <braunr> when cleaning the package before building .. + + +### IRC, freenode, #hurd, 2014-01-18 + + <braunr> damn, fakeroot-tcp won't work on darnassus .. + <braunr> uh, looks like my tls/thread destruction "fixes" do cause + regressions :( + <braunr> fakeroot works fine with debian glibc + <teythoon> which one ? + <teythoon> which fakeroot i mean + <braunr> -tcp + <braunr> yes, it fails as soon as i use the patched glibc :/ + <braunr> at least it's easy to reproduce + + +### IRC, freenode, #hurd, 2014-01-20 + + <braunr> great, 3rd libc version installed on darnassus, let's see if i can + build hurd packages against that + + +### IRC, freenode, #hurd, 2014-01-21 + + <braunr> damn, fakeroot-tcp still crashes with my latest changes .... + + <braunr> darnassus looks in good shape + <braunr> youpi: ^ + <braunr> youpi: if you have other tests, feel free to do them now + <braunr> i feel confident about committing the changes, if you're ok with + it + <youpi> which changes ? + <youpi> I'm a bit lost in what you were talking about :) + <braunr> you can find them in 2 patches in /var/tmp on darnassus + <braunr> one is about fixing thread destruction + <braunr> i'm pretty certain about this one so i'll commit it directly + <braunr> the other is fixing the tcb of the main thread + +[[open_issues/libpthread]]. + + <braunr> where i simply do tcb->self = thread->kernel_thread :) + <braunr> with a comment explaining why i don't do something else like + deallocating the unused tcb + <youpi> braunr: ok, that looks good + <teythoon> braunr: awesome :) + <braunr> youpi: ok + + +### IRC, freenode, #hurd, 2014-01-22 + + <braunr> there, libpthread should be fine now + + +## IRC, freenode, #hurd, 2014-02-06 + + <braunr> youpi: in case you're planning to upgrade glibc (or not), the + thread destruction changes are complete + <braunr> youpi: darnassus has been running them for some weeks with no + visible regression + <youpi> braunr: ok, good + <youpi> including it in glibc was on my todo list indeed + <youpi> and Adam indeed plan for a 2.18 upload + <braunr> good :) + <youpi> braunr: this is up to 7c6dc6e28b2fc4b67934223f41cf080ffe58b230, + right? (Wed Jan 22, Fix up the main thread TCB) + <braunr> yes + <braunr> oh, i just saw 2.17-98~0 glibc packages on debian-ports :) + <youpi> yes, it's just to fix the dhcp crash + <braunr> ah yes, it's not 2.18 + <youpi> 2.18 is available in experimental + + <youpi> braunr: just to make sure: did you have + 983b18a6ff16f5687a9ece63a50d1831dec88609 in libc on darnassus? + <youpi> (which drops the stack size hack) + <braunr> youpi: let me check + <braunr> youpi: ah no, i don't, you're right + <youpi> well, I was just wondering, nothing make me think that was the case + :) + <youpi> what was the issue that it was raising btw? + <braunr> threadvards + <youpi> ok, b ut in which case? + <youpi> (to make sure I test that before committing) + <braunr> now that we switched to tls, i would assume the transition path to + be 1/ hurd stops defining that symbol, 2/ libpthread can stop using it + <braunr> the goal was to reduce the stack size of hurd server threads + <youpi> well, that's not my question :) I'm wondering in which precise case + that was breaking things + <braunr> youpi: i don't know, it shouldn't break + <youpi> ok + <braunr> youpi: just in case, don't forget that last one line patch i + committed last night, fakeroot can't work right without it + <braunr> (i made a minor change while reviewing before comitting, and + obviously got it wrong :p) + <youpi> ok + + <youpi> braunr: I've upgraded libpthread in debian's eglibc btw + + <braunr> + /home/rbraun/devel/debian/packages/eglibc/eglibc-2.17/build-tree/hurd-i386-libc/libc.so.phdr: + *** executable stack signaled + <braunr> from build-tree/hurd-i386-libc/elf/check-execstack.out + <braunr> i thought glibc didn't use those + <braunr> anyway it doesn't look to be the regression i'm having + <braunr> does this ring a bell : + <braunr> Encountered regressions that don't match expected failures + (debian/testsuite-checking/expected-results-i486-gnu-libc): + <braunr> test-stpcpy_chk.out, Error 1 + <braunr> TEST test-stpcpy_chk.out: __stpcpy_chk normal_stpcpy + simple_stpcpy_chk + <youpi> nope + <youpi> after what are you getting this regression? + <braunr> building glibc 2.17-97 with thread destruction patches, including + the one removing the stack size hack + <braunr> during tests + <braunr> there also are "progressions", but i'm not sure what these are + <youpi> some progressions are just luck, other seem to happen on some + platforms only + <youpi> I'm not sure you want to test 2.17 + <youpi> a lot has changed between 2.17's libpthread and 2.18's libpthread + (which is now equal to cvs's libpthread + <youpi> ) + <youpi> s/cvs/git/ + <braunr> yes + <braunr> i usually build with nocheck + + +## IRC, freenode, #hurd, 2014-02-07 + + <braunr> youpi: on a vm with hurd 1:0.5.git20140203-1, upgrading to a + patched glibc 2.17-97 that includes the patch which reverts the stack + size hack, the system reboots and works fine + <youpi> ok. I don't remember what problem I was seeing + <braunr> that version of the hurd no longer defines the symbol + <braunr> but even then, there shouldn't have been any problem + <braunr> hm, or does it + <braunr> yes, it does + <braunr> youpi: the hurd package patch mentions + <braunr> Revert this for now, will have to wait for dropping the use of + <braunr> __pthread_stack_default_size from eglibc's + libpthread_hurd_cond_wait.diff + <braunr> i wonder how it got there + <youpi> IIRC I was wondering too + <braunr> i've installed my c library on darnassus and it works fine there + too + <braunr> with older (january) hurd packages + <braunr> looks good to me + + +## IRC, freenode, #hurd, 2014-02-10 + + <teythoon> braunr: btw, do the new libc packages contain your thread + destruction work ? + <braunr> teythoon: the -98 ones on experimental ? + <braunr> i don't think they do + <braunr> the -18 ones should do diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index 3c36eb26..a825fdff 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.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 @@ -125,6 +125,108 @@ IRC, freenode, #hurd, 2011-08-17 <pinotree> and yes, it's known already, just nobody worked on solving it +# IRC, freenode, #hurd, 2014-01-28 + + <gnu_srs> braunr: Is this fixed by your recent patches? test_dbi: + ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: + <gnu_srs> __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' + failed. + <youpi> faq/libpthread_dlopen.mdwn: + ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: + __pthread_mutex_time + <gnu_srs> youpi: tks. A workaround seems to be available: + LD_PRELOAD=/lib/i386-gnu/libpthread.so.0.3 + <gnu_srs> Is that possible on a buildd? + <youpi> it would be simpler to just make the package explicitly link + libpthread + <gnu_srs> Package is libdbi-drivers, providing libdbd-sqlite3 needed by + gnucash + + +# IRC, freenode, #hurd, 2014-02-17 + + <braunr> hm ok, looks like iceweasel errors all have something to do with + the libc dns resolver + <braunr> http://darnassus.sceen.net/~rbraun/iceweasel_crash + <braunr> apparently, it's simply because the memory chunk isn't page + aligned .. + <braunr> looks like not preloading libpthread tirggers lots of tricky + issues + <braunr> anyway, apparently, the malloc/free calls in libresolv don't use + locks if libpthread isn't preloaded, which explains why the program state + looked impossible to reach and why crashes look random + <congzhang> debian linux does not have the pthread load problem. + <braunr> congzhang: it had it + <braunr> maybe not debian but i've found one such report for opensuse + + <braunr> ok the bug is simple + <braunr> for some reason, our glibc still uses a global _res state for dns + resolution instead of per thread ones + <braunr> uh, apparently, it's libpthread's job to define a __res_state + function for that :( + +## IRC, freenode, #hurd, 2014-02-18 + + <braunr> usually when i say it, it crashes soon after, so let's try it : + <braunr> i've been running iceweasel 27 fine for like 10 minutes with a + patched libpthread + <braunr> still no crash ;p + <braunr> with luck this extremely lightweight patch will fix all + multithreaded applications doing concurrent name resolution .... :) + <teythoon> nice :) + <braunr> let's try gnash .... + <braunr> uh, segfault on termination + <braunr> gnash works :) + <teythoon> sweet :) + <braunr> i'm very surprised we could live so long with that resolv bug + + +## IRC, freenode, #hurd, 2014-02-19 + + <braunr> youpi: the eglibc bug is about libresolv + <braunr> it uses a global resolver state even in multithreaded applications + <youpi> libresolv is a horrible part of glibc :) + <braunr> which is obviously bad + <braunr> yes .. :) + <braunr> here is the patch : + http://darnassus.sceen.net/~rbraun/0001-libpthread-per-thread-resolver-states.patch + <braunr> it's very short, it basically allocates a resolver state per + thread in the pthread struct, and sets the TLS variable __resp when the + thread starts + <braunr> should we make that hurd-specific ? + <braunr> or enclose that assignment with #ifdef ENABLE_TLS ? + <youpi> well, ENABLE_TLS is now always 1, iirc :) + <braunr> for the hurd, yes + <youpi> I'm surprised linux never had the issue + <youpi> no, not for the hurd + <braunr> ah + <youpi> I *had* to implement TLS for hurd because it was always 1 for + everybody :) + <braunr> ok + <braunr> so all those ifdefs could be removed and libpthread can assume tls + is enabled + <braunr> in which case my patch looks fine + <youpi> ah, thats a libpthread patch, not glibc patch + <braunr> yes + <braunr> nptl obviously did that from the start . :) + <braunr> linuxthreads had the problem a looong time ago + <youpi> ok + <braunr> i'm surprised we overlooked it for so long + <braunr> but anyway, that's a good fix + <youpi> indeed + <youpi> it seems all good to me + <braunr> well, __resp is a __thread variable + <braunr> i could add #ifdef ENABLE_TLS, but then what of the case where TLS + isn't enabled, and do we actually care ? + <braunr> #error maybe ? + <braunr> or #warning ? + <youpi> I don't think we care about the non-TLS case any more + <braunr> ok + <braunr> topgit branch i suppose ? + <youpi> well, not, hurd libpthread repo :) + <braunr> oh right ... :) + + # libthreads vs. libpthread The same symptom appears in an odd case, for instance: diff --git a/open_issues/libpthread_set_stack_size.mdwn b/open_issues/libpthread_set_stack_size.mdwn index 68f81752..21c2f18e 100644 --- a/open_issues/libpthread_set_stack_size.mdwn +++ b/open_issues/libpthread_set_stack_size.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -23,3 +24,91 @@ IRC, freenode, #hurd, 2011-10-21: <youpi> it's simply on the so-long TODO list [[glibc/t/tls-threadvar]]. + +2012-12-28: + +Hurd commit 3a3fcc811e6b50b21124a5c5a128652e788a3b67 `libports: remove the +threadvars stack size hack`. + +IRC, freenode, #hurd, 2014-01-09: + + <teythoon> braunr: i'm afraid it might be your patch 3a3fcc81 that breaks + proc + <teythoon> w/ the current debian libc that is + <teythoon> braunr: i reverted that patch and now it boots again + <gnu_srs> is alternate stack and arbitrary stack sizes supported by now, or + upcoming? + <braunr> gnu_srs: supported + <braunr> well + <braunr> considering what teythoon just said, maybe not + <gg0> need to remove __pthread_stack_default_size from + libpthread_hurd_cond_wait patch too i guess + <braunr> teythoon: i don't understand why this change has any negative + effect :/ + <braunr> or + <braunr> hm no .. + <braunr> there may be a bug in the latest glibc, where changing the stack + is allowed on the ground that threadvars have been replaced with tls, but + the libpthread stack handling code does it wrong + <braunr> see 714413a7694ff534855e9e5904899695eac6c9bb in libpthread + <braunr> which the thread destruction patches already did before it was + fixed in libpthread + <braunr> and may explain why my packages work + + +IRC, freenode, #hurd, 2014-01-14: + + <youpi> teythoon: Mmm, I tried to update to the latest hurd commits, but + init dies early at boot + <youpi> exec init proc auth, and then init crashes + <youpi> downgrading libports to previous makes the issue go away + <braunr> youpi: previous ? + <youpi> previous debian package + <braunr> which patch makes it fail ? + <youpi> I'm bisecting + <braunr> i remember teythoon saying he had failures with the patch that + removes the threadvars stack size hack + <youpi> I'll try that already, ok + <youpi> yes, boots fine without this change + <braunr> ok + <youpi> perhaps some missing patches in the current 2.17-97 glibc + <braunr> or libpthread reacting badly to new stack sizes + <braunr> is 714413a7694ff534855e9e5904899695eac6c9bb included in your glibc + ? + <braunr> (714413a7694ff534855e9e5904899695eac6c9bb from libpthread) + <braunr> or maybe that's not the problem + <braunr> anyway, it's normally fixed with the thread destruction patch + <braunr> i did test it and checked the stack size were correct + <braunr> sizes* + <youpi> yes, debian's glibc has it + <youpi> ok + <youpi> so that can wait + <braunr> is 959f7365fccd1c89be9938c2655eba9122171e6a (Drop threadvars + entirely) also in your glibc ? + <youpi> yes + <braunr> that's weird :/ + <braunr> the only thing i can think of is __pthread_stack_alloc miserably + failing with 2M stacks and "many" threads for some odd reason .. + <braunr> anyway, see you tomorrow + <gg0> hurd-i386/libpthread_hurd_cond_wait.diff keeps using + __pthread_stack_default_size. isn't it the problem? + * youpi wonders what that change is doing there + <youpi> and it's there from the start of that patch... + <braunr> + if (&__pthread_stack_default_size != NULL) + <braunr> checks if the symbol is actually resolved + <braunr> that's what allows regular applications to work + <braunr> it should be the same for hurd servers + + +# sigaltstack + +Likewise, `sigaltstack` is not usable at the moment. + +IRC, freenode, #hurd, 2014-02-25: + + <gnu_srs> braunr: are the split/alternate stack etc problems solved by now + so gccgo can work properly? + <braunr> i don't know + <braunr> i suspect it wouldn't require much work now that tls is well + supported + <youpi> alternate stack is supposed to be working diff --git a/open_issues/linux_as_the_kernel.mdwn b/open_issues/linux_as_the_kernel.mdwn index 1d84d777..2656b1a3 100644 --- a/open_issues/linux_as_the_kernel.mdwn +++ b/open_issues/linux_as_the_kernel.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -235,3 +235,34 @@ Richard's X-15 Mach re-implementation: <braunr> i'll have to check, it's been a long time since i've really used it <braunr> they must use a pure devfs instance now + + +# IRC, freenode, #hurd, 2014-02-23 + + <desrt> so crazy idea: would it be possible to have mach as a linux kernel + module? + <desrt> ie: some new binfmt type thing that could load mach binaries and + implement the required kernel ABI for them + <desrt> and then run the entire hurd under that.... + <braunr> desrt: that's an idea, yes + <braunr> and not a new one + * desrt did a bit of googling but didn't find any information about it + <braunr> desrt: but why are you thinking of it ? + <braunr> we talked about it here, informally + <desrt> braunr: mostly because running hurd in a VM sucks + <desrt> if we had mach-via-linux, we'd have: + <desrt> - no vm overhead + <desrt> - no device virtualisation + <desrt> - 64bit (physical at least) memory support + <desrt> - SMP + <desrt> - access to the linux drivers, natively + <desrt> and maybe some other nice things + <braunr> yes we talkbed about all this + <braunr> but i still consider that to be an incomplete solution + <desrt> i don't consider it to be running "the hurd" as your OS... but it + would be a nice solution for development and virtualisation + <braunr> we probably don't want to use drivers natively, since we want them + to run in their own address space, with their own namespace context + <braunr> it would, certainly + <braunr> but it would require a lot of effort anyway + <desrt> right diff --git a/open_issues/mach_migrating_threads.mdwn b/open_issues/mach_migrating_threads.mdwn index bbc6ac45..16547838 100644 --- a/open_issues/mach_migrating_threads.mdwn +++ b/open_issues/mach_migrating_threads.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 @@ -101,3 +102,17 @@ In context of [[resource_management_problems]]. <braunr> i initially downloaded osfmach sources to see an example of how thread migration was used from userspace <braunr> and they do have a special threading library for that + + +# IRC, freenode, #hurd, 2014-02-18 + + <teythoon> has anyone here ever tried to enable the thread migration bits + in gnumach to see where things break and how far that effort has been + taken ? + <braunr> without proper userspace support, i don't see how this could work + <teythoon> but is the kernel part finished or close to being finished ? + <braunr> no idea + <braunr> i don't think it is + <braunr> i didn't see much code related to that feature, and practically + none that looked like what the paper described + <braunr> some structures, but not used diff --git a/open_issues/mig_portable_rpc_declarations.mdwn b/open_issues/mig_portable_rpc_declarations.mdwn index ecfa06ae..f5f18880 100644 --- a/open_issues/mig_portable_rpc_declarations.mdwn +++ b/open_issues/mig_portable_rpc_declarations.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,8 +11,35 @@ License|/fdl]]."]]"""]] [[!tag open_issue_mig]] +[[!toc]] -# IRC, freenode, #hurd, 2011-11-14 + +# 32-Bit vs. 64-Bit Interfaces + +## IRC, freenode, #hurd, 2011-10-16 + + <braunr> i guess it wouldn't be too hard to have a special mach kernel for + 64 bits processors, but 32 bits userland only + <youpi> well, it means tinkering with mig + <braunr> like old sparc systems :p + <youpi> to build the 32bit interface, not the 64bit one + <braunr> ah yes + <braunr> hm + <braunr> i'm not sure + <braunr> mig would assume a 32 bits kernel, like now + <youpi> and you'll have all kinds of discrepancies in vm_size_t & such + <braunr> yes + <braunr> the 64 bits type should be completely internal + <braunr> types* + <braunr> but it would be far less work than changing all the userspace bits + for 64 bit (ofc we'll do that some day but in the meanwhile ..) + <youpi> yes + <youpi> and it'd boost userland addrespace to 4GiB + <braunr> yes + <youpi> leaving time for a 64bit userland :) + + +## IRC, freenode, #hurd, 2011-11-14 <braunr> also, what's the best way to deal with types such as <braunr> type cache_info_t = struct[23] of integer_t; @@ -58,7 +86,103 @@ License|/fdl]]."]]"""]] <antrik> (which I still need to follow up on... [sigh]) -# IRC, freenode, #hurd, 2013-06-25 +## IRC, freenode, #hurd, 2012-12-12 + +In context of [[microkernel/mach/gnumach/memory_management]]. + + <tschwinge> Or with a 64-bit one? ;-P + <braunr> tschwinge: i think we all had that idea in mind :) + <pinotree> tschwinge: patches welcome :P + <youpi> tschwinge: sure, please help us settle down with the mig stuff + <youpi> what was blocking me was just deciding how to do it + <braunr> hum, what's blocking x86_64, except time to work on it ? + <youpi> deciding the mig types & such things + <youpi> i.e. the RPC ABI + <braunr> ok + <braunr> easy answer: keep it the same + <youpi> sorry, let me rephrase + <youpi> decide what ABI is supposed to be on a 64bit system, so as to know + which way to rewrite the types of the kernel MIG part to support 64/32 + conversion + <braunr> can't this be done in two steps ? + <youpi> well, it'd mean revamping the whole kernel twice + <youpi> as the types at stake are referenced in the whole RPC code + <braunr> the first step i imagine would simply imply having an x86_64 + kernel for 32-bits userspace, without any type change (unless restricting + to 32-bits when a type is automatically enlarged on 64-bits) + <youpi> it's not so simple + <youpi> the RPC code is tricky + <youpi> and there are alignments things that RPC code uses + <youpi> which become different when build with a 64bit compiler + <pinotree> there are also things like int[N] for io_stat_struct and so on + <braunr> i see + <youpi> making the code wrong for 32 + <youpi> thus having to change the types + <youpi> pinotree: yes + <pinotree> (doesn't mig support structs, or it is too clumsy to be used in + practice?) + <braunr> pinotree: what's the problem with that (i explcitely said changing + int to e.g. int32_t) + <youpi> that won't fly for some of the calls + <youpi> e.g. getting a thread state + <braunr> pinotree: no it doesn't support struct + <pinotree> braunr: that some types in struct stat are long, for instance + <braunr> pinotree: same thing with longs + <braunr> youpi: why wouldn't it ? + <youpi> that wouldn't work on a 64bit system + <youpi> so we can't make it int32_t in the interface definition + <braunr> i understand the alignment issues and that the mig code adjusts + the generated code, but not the content of what is transfered + <braunr> well of course + <braunr> i'm talking about the first step here + <braunr> which targets a 32-bits userspace only + <youpi> ok, so we agree + <youpi> the second step would have to revamp the whole RPC code again + <braunr> i imagine the first to be less costly + <braunr> well, actually no + <braunr> you're right, the mig stuff would be easy on the application side, + but more complicated on the kernel side, since it would really mean + dealing with 64-bits values there + <braunr> (unless we keep a 3/1 split instead of giving the full 4g to + applications) + +See also [[microkernel/mach/gnumach/memory_management]]. + + <youpi> (I don't see what that changes) + <braunr> if the kernel still runs with 32-bits addresses, everything it + recevies from or sends through mig can be stored with the user side + 32-bits types + <youpi> err, ok, but what's the point of the 64bit kernel then ? :) + <braunr> and it simply uses 64-bits addresses to deal with physical memory + <youpi> ok + <youpi> that could even be a 3.5/0.5 split then + <braunr> but the memory model forces us to run either at the low 2g or the + highest ones + <youpi> but linux has 3/1, so we don't need that + <braunr> otherwise we need an mcmodel=medium + <braunr> we could do with mcmodel=medium though, for a time + <braunr> hm actually no, it would require mcmodel=large + <braunr> hum, that's stupid, we can make the kernel run at -2g, and use 3g + up to the sign extension hole for the kernel map + + +## IRC, freenode, #hurd, 2013-12-03 + + <azeem> I believe the main issue is redoing the RPCs in 64bit, i.e. the + Mach/Hurd interface + <braunr> mach has always been 64-bits capable + <braunr> the problem is both mach and the hurd + <braunr> it's at the system interface (the .defs of the RPCs) + <braunr> azeem: ah, actually that's why you also say + <braunr> but i consider it to be a hurd problem + <braunr> the hurd itself is defined as being a set of interfaces and + servers implementing them, i wouldn't exclude the interfaces + <braunr> that's what* + + +# Structured Data + +## IRC, freenode, #hurd, 2013-06-25 <teythoon> is there a nice way to get structured data through mig that I haven't found yet? diff --git a/open_issues/mig_strings.mdwn b/open_issues/mig_strings.mdwn new file mode 100644 index 00000000..3693fcc2 --- /dev/null +++ b/open_issues/mig_strings.mdwn @@ -0,0 +1,38 @@ +[[!meta copyright="Copyright © 2014 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_mig]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2014-02-21 + + <teythoon> grml... migs support for variable-length c strings is broken :( + <braunr> completely .. + <teythoon> no one told me :p + <braunr> noone dares + <teythoon> to tell me ? + <braunr> or anyone else ;p + <teythoon> ^^ + <teythoon> root@debian:~# pkill mtab + <teythoon> task /hurd/procfs(19) �O� deallocating an invalid port 1049744, + most probably a bug. + <braunr> :) + <teythoon> it's still an improvement >,< + <teythoon> uh the joys... + <teythoon> gnu machs mig_strncpy behaves differently from glibcs + <teythoon> the mach version always 0-terminates the target string, the libc + variant does not + <teythoon> which one should i "fix" ? + <braunr> strncpy should behave like strncpy + <teythoon> not according to the documentation in gnumach... + <braunr> people who know it expect it not to always null terminate + <braunr> you can either fix mig_strncpy, or call it mig_strlcpy diff --git a/open_issues/mig_stub_functions.mdwn b/open_issues/mig_stub_functions.mdwn index 24a582b1..474a7675 100644 --- a/open_issues/mig_stub_functions.mdwn +++ b/open_issues/mig_stub_functions.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 @@ -39,3 +39,15 @@ License|/fdl]]."]]"""]] <teythoon> btw, is there any reason why mig couldn't generate the request and reply routines from the synchronous routines? <braunr> i guess it could + + +# Compiler Optimization + +## IRC, freenode, #hurd, 2013-12-02 + + <teythoon> braunr: inlining the mach generated x_server_procedure functions + shaved 5 minutes off my hurd package build :) + <teythoon> i guess fakeroot-tcp benefits most from this... I'm going to try + this w/o fakeroot and on real hardware shortly + <braunr> teythoon: nice + <teythoon> :) diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn index 03614fae..d5c0272c 100644 --- a/open_issues/multithreading.mdwn +++ b/open_issues/multithreading.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 @@ -362,6 +362,8 @@ Tom Van Cutsem, 2009. <braunr> having servers go away when unneeded is a valuable and visible feature of modularity +[[open_issues/libpthread/t/fix_have_kernel_resources]]. + ### IRC, freenode, #hurd, 2013-04-03 @@ -381,6 +383,184 @@ Tom Van Cutsem, 2009. <braunr> ok +### IRC, freenode, #hurd, 2013-11-30 + +"Thread storms". + + <braunr> if you copy a large file for example, it is loaded in memory, each + page is touched and becomes dirty, and when the file system requests them + to be flushed, the kernel sends one message for each page + <braunr> the file system spawns a thread as soon as a message arrives and + there is no idle thread left + <braunr> if the amount of message is large and arrives very quickly, a lot + of threads are created + <braunr> and they compete for cpu time + <Gerhard> How do you plan to work around that? + <braunr> first i have to merge in some work about pagein clustering + <braunr> then i intend to implement a specific thread pool for paging + messages + <braunr> with a fixed size + <Gerhard> something compareable for a kernel scheduler? + <braunr> no + <braunr> the problem in the hurd is that it spawns threads as soon as it + needs + <braunr> the thread does both the receiving and the processing + <Gerhard> But you want to queue such threads? + <braunr> what i want is to separate those tasks for paging + <braunr> and manage action queues internally + <braunr> in the past, it was attempted to limit the amount ot threads in + servers, but since receiving is bound with processing, and some actions + in libpager depend on messages not yet received, file systems would + sometimes freeze + <Gerhard> that's entirely the task of the hurd? One cannot solve that in + the microkernel itself? + <braunr> it could, but it would involve redesigning the paging interface + <braunr> and the less there is in the microkernel, the better + + +#### IRC, freenode, #hurd, 2013-12-03 + + <braunr> i think our greatest problem currently is our file system and our + paging library + <braunr> if someone can spend some time getting to know the details and + fixing the major problems they have, we would have a much more stable + system + <TimKack> braunr: The paging library because it cannot predict or keep + statistics on pages to evict or not? + <TimKack> braunr: I.e. in short - is it a stability problem or a + performance problem (or both :) ) + <braunr> it's a scalability problem + <braunr> the sclability problem makes paging so slow that paging requests + stack up until the system becomes almost completely unresponsive + <TimKack> ah + <TimKack> So one should chase defpager code then + <braunr> no + <braunr> defpager is for anonymous memory + <TimKack> vmm? + <TimKack> Ah ok ofc + <braunr> our swap has problems of its own, but we don't suffer from it as + much as from ext2fs + <TimKack> From what I have picked up from the mailing lists is the ext2fs + just because no one really have put lots of love in it? While paging is + because it is hard? + <TimKack> (and I am not at that level of wizardry!) + <braunr> no + <braunr> just because it was done at a time when memory was a lot smaller, + and developers didn't anticipate the huge growth of data that came during + the 90s and after + <braunr> that's what scalability is about + <braunr> properly dealing with any kind of quantity + <teythoon> braunr: are we talking about libpager ? + <braunr> yes + <braunr> and ext2fs + <teythoon> yeah, i got that one :p + <braunr> :) + <braunr> the linear scans are in ext2fs + <braunr> the main drawback of libpager is that it doesn't restrict the + amount of concurrent paging requests + <braunr> i think we talked about that recently + <teythoon> i don't remember + <braunr> maybe with someone else then + <teythoon> that doesn't sound too hard to add, is it ? + <teythoon> what are the requirements ? + <teythoon> and more importantly, will it make the system faster ? + <braunr> it's not too hard + <braunr> well + <braunr> it's not that easy to do reliably because of the async nature of + the paging requests + <braunr> teythoon: the problem with paging on top of mach is that paging + requests are asynchronous + <teythoon> ok + <braunr> libpager uses the bare thread pool from libports to deal with + that, i.e. a thread is spawned as soon as a message arrives and all + threads are busy + <braunr> if a lot of messages arrive in a burst, a lot of threads are + created + <braunr> libports implies a lot of contention (which should hopefully be + lowered with your payload patch) + +[[community/gsoc/project_ideas/object_lookups]]. + + <braunr> that contention is part of the scalability problem + <braunr> a simple solution is to use a more controlled thread pool that + merely queues requests until user threads can process them + <braunr> i'll try to make it clearer : we can't simply limit the amout of + threads in libports, because some paging requests require the reception + of future paging requests in order to complete an operation + <teythoon> why would that help with the async nature of paging requests ? + <braunr> it wouldn't + <teythoon> right + <braunr> thaht's a solution to the scalability problem, not to reliability + <teythoon> well, that kind of queue could also be useful for the other hurd + servers, no ? + <braunr> i don't think so + <teythoon> why not ? + <braunr> teythoon: why would it ? + <braunr> the only other major async messages in the hurd are the no sender + and dead name notification + <braunr> notifications* + <teythoon> we could cap the number of threads + <braunr> two problems with that solution + <teythoon> does not solve the dos issue, but makes it less interruptive, + no? + <braunr> 1/ it would dynamically scale + <braunr> and 2/ it would prevent the reception of messages that allow + operations to complete + <teythoon> why would it block the reception ? + <teythoon> it won't be processed, but accepting it should be possilbe + <braunr> because all worker threads would be blocked, waiting for a future + message to arrive to complete, and no thread would be available to + receive that message + <braunr> accepting, yes + <braunr> that's why i was suggesting a separate pool just for that + <braunr> 15:35 < braunr> a simple solution is to use a more controlled + thread pool that merely queues requests until user threads can process + them + <braunr> "user threads" is a poor choice + <braunr> i used that to mirror what happens in current kernels, where + threads are blocked until the system tells them they can continue + <teythoon> hm + <braunr> but user threads don't handle their own page faults on mach + <teythoon> so how would the threads be blocked exactly, mach_msg ? + phread_locks ? + <braunr> probably a pthread_hurd_cond_wait_np yes + <braunr> that's not really the problem + <teythoon> why not ? that's the point where we could yield the thread and + steal some work from our queue + <braunr> this solution (a specific thread pool of a limited number of + threads to receive messages) has the advantage that it solves one part of + the scalability issue + <braunr> if you do that, you loose the current state, and you have to use + something like continuations instead + <teythoon> indeed ;) + <braunr> this is about the same as making threads uninterruptible when + waiting for IO in unix + <braunr> it makes things simpler + <braunr> less error prone + <braunr> but then, the problem has just been moved + <braunr> instead of a large number of threads, we might have a large number + of queued requests + <braunr> actually, it's not completely asynchronous + <braunr> the pageout code in mach uses some heuristics to slow down + <braunr> it's ugly, and is the reason why the system can get extremely slow + when swap is used + <braunr> solving that probably requires a new paging interface with the + kernel + <teythoon> ok, we will postpone this + <teythoon> I'll have to look at libpager for the protected payload series + anyways + <braunr> 15:38 < braunr> 1/ it would dynamically scale + <braunr> + not + <teythoon> why not ? + <braunr> 15:37 < teythoon> we could cap the number of threads + <braunr> to what value ? + <teythoon> we could adjust the number of threads and the queue size based + on some magic unicorn function + <braunr> :) + <braunr> this one deserves a smiley too + <teythoon> ^^ + + ## Alternative approaches: * <http://www.concurrencykit.org/> diff --git a/open_issues/nightly_builds.mdwn b/open_issues/nightly_builds.mdwn index 96567685..f6d2c311 100644 --- a/open_issues/nightly_builds.mdwn +++ b/open_issues/nightly_builds.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 @@ -29,9 +29,25 @@ Resources: * <http://buildbot.net/> + IRC, freenode, #hurd, 2013-11-15: + + <teythoon> today I discovered buildbot, and both the master as well as + the build slave works just fine out of the box on Hurd :) + <teythoon> I'd love to set one up on darnassus + <braunr> ah nice + <braunr> we use buildbot at work too + <teythoon> even better, so you already know it + <braunr> sure we can + <braunr> no i don't + <braunr> i just know we use it :) + <teythoon> k + <braunr> but that would be a good occasion to learn + <braunr> i'm a bit busy right now, have to go soon + <braunr> we'll see the details later + <teythoon> yes :) + + [[Nightly_Builds_deb_Packages]]. + * [LAVA (Linaro Automated Validation Architecture)](http://lava.readthedocs.org/) ---- - -See also [[nightly_builds_deb_packages]]. diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn index 11fc4c79..da7bdc7d 100644 --- a/open_issues/nightly_builds_deb_packages.mdwn +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -16,6 +17,13 @@ packages. * Need to have an automation to get from Hurd upstream Git branches to a branch usable in Debian. + IRC, freenode, #hurd, 2013-12-18: + + <teythoon> http://darnassus.sceen.net/~teythoon/hurd-ci/ has hurd and + mig and gnumach packages built directly from the upstream git + repository + + --- There is infrastructure available to test whole OS installations. @@ -29,3 +37,74 @@ There is infrastructure available to test whole OS installations. --- See also [[nightly_builds]]. + + +# Debian Jenkins Instance + +## IRC, OFTC, #debian-hurd, 2014-02-24 + + <pere> hi. can hurd be installed using d-i? If so, what about scripting + the installation on <URL: + http://jenkins.debian.net/view/g-i-installation/ >? + <gnu_srs> pere: d-i works for Hurd, yes, with full graphical interface I + dunno. Maybe you can ask about scripting in #hurd, more people are + present there? + <pere> gnu_srs: the scripts in questions are for jenkins. quite easy to + write (d-i preseed scripts and qemu boot rules). + +## IRC, OFTC, #debian-hurd, 2014-02-25 + + <pere> getting a automated test in jenkins running could show the status. + what is needed to boot the hurd d-i image with a preseed file using qemu? + <pere> git://git.debian.org/git/users/holger/jenkins.debian.net.git is the + repo with the jenkins build rules. + <pere> youpi: is it possible to start the hurd d-i installer with a preseed + file from the qemu command line? --append need --kernel, which I suspect + do not make sense with hurd? + <pere> can the d-i hurd installer take a preseed file at all? my initial + try failed. :( + <teythoon> i don't know + <teythoon> there has been talk here the other day about using qemus + multiboot capabilities to directly boot the hurd + +[[debugging_gnumach_startup_qemu_gdb]], *Multiboot* + + <teythoon> i always wanted to try that out + <pere> the jenkins rules to test the install uses --kernel, --initrd and + --append in qemu to specify the preseed file. without a similar method + to boot hurd, it will be hard to automate the test. rewriting the iso + might be an option, but not a very nice one. + <teythoon> i believe that it is possible to use those options to boot a + hurd + <teythoon> i'll report back to you + <pere> I tried adding an url= option to grub when booting the installer, + but it seem to be ignored. + <pere> I suspect it did not make it to /proc/cmdline, but am not sure. + <teythoon> um + <teythoon> it should + <pere> could be. I am unable to get a shell in the installer, so I do not + know. + <teythoon> root@pluto ~ # cat /proc/cmdline + <teythoon> root=device:hd0s1 + <teythoon> oh ? select expert install, then spawn a shell or something + <pere> perhaps the preseed udeb is missing, or the network support was + enabled after preseed looked for the file? + <teythoon> uh, i don't know about that stuff, youpi creates the d-i images + <pere> ok. seem to me that the d-i images do not support preseeding at the + moment. + <teythoon> pere: when i try to use qemus multiboot support to boot the + hurd, qemu crashes :/ + <teythoon> youpi: ^ did you succeed? if so, can you share how? + <pere> teythoon: nope, I concluded it didn't work, and left it to other to + fix. :) + <youpi> pere, teythoon: IIRC preseeding can be put on the gnumach kernel + command line + <youpi> but I'm wondering why you can't simply modify the disk image into + doing what you want + <youpi> or you mean reinstalling the image each time? + <pere> youpi: the point is testing the installer, and that can only be done + by using the installer. :) + <youpi> ok + <pere> I would like to see something like <URL: + http://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_lxde/lastBuild/ + > for hurd. diff --git a/open_issues/nptl.mdwn b/open_issues/nptl.mdwn index 3c84bfb0..be0270df 100644 --- a/open_issues/nptl.mdwn +++ b/open_issues/nptl.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -15,7 +16,8 @@ License|/fdl]]."]]"""]] # IRC, freenode, #hurd, 2010-07-31 - <tschwinge> Other question: how difficult is a NPTL port? Futexes and some kernel interfaces for scheduling stuff etc. -- what else? + <tschwinge> Other question: how difficult is a NPTL port? Futexes and some + kernel interfaces for scheduling stuff etc. -- what else? <youpi> actually NPTL doesn't _require_ futexes <youpi> it just requires low-level locks <youpi> Mmm, it seems to be so only in principle @@ -25,8 +27,10 @@ License|/fdl]]."]]"""]] <youpi> I'm not sure we really want to port NPTL <tschwinge> OK. <youpi> Drepper will keep finding things to add - <youpi> while the interface between glibc and libpthread isn't increasing _so_ much - <tschwinge> ... and even less so the interfavce that actual applications are using. + <youpi> while the interface between glibc and libpthread isn't increasing + _so_ much + <tschwinge> ... and even less so the interfavce that actual applications + are using. <tschwinge> We'd need to evaluate which benefits NPTL would bring. @@ -44,6 +48,63 @@ License|/fdl]]."]]"""]] <azeem> and http://lists.debian.org/debian-bsd/2013/07/msg00138.html +# IRC, freenode, #hurd, 2013-12-26 + + <nalaginrut> hm? has NPTL already supported for Hurd? + <braunr> probably won't ever be + <nalaginrut> so no plan for it? + <braunr> what for ? + <nalaginrut> no one interested in it, or no necessary adding it? + <braunr> why would you want nptl ? + <braunr> ntpl was created to overcome the defficiencies of linuxthreads + <braunr> we have our own libpthread + <braunr> (with its own defficiencies) + <braunr> supporting nptl would probably force us to implement something a + la clone + <nalaginrut> well, just inertia, now that Linux/kFreebsd has it + <braunr> are you sure kfreebsd has it ? + * teythoon thought we have clone + <nalaginrut> http://www.gnu.org/software/hurd/open_issues/nptl.html + <nalaginrut> seems someone mentioned it + <braunr> it's a "nptl-like implementation" + <nalaginrut> yes, I don't think it should be the same with Linux one, but + something like it + <braunr> but what for ? + <braunr> as mentioned in the link you just gave, "<tschwinge> We'd need to + evaluate which benefits NPTL would bring." + <nalaginrut> well, it's the note of 2010, I don't know if it's relative now + <braunr> relevant* + <nalaginrut> ah thanks + <braunr> but that still doesn't answer anything + <braunr> why are *you* talking about nptl ? + <nalaginrut> just saw pthread, then recall nptl, dunno + <nalaginrut> just asking + <braunr> :) + <nalaginrut> but you mentioned that Hurd has its own thread implementation, + is it similar or better than Linux NPTL? + <nalaginrut> or there's no benchmark yet? + <braunr> it's inferior in performance + <braunr> almost everything in the hurd is inferior performance-wise because + of the lack of optimizations + <braunr> currently we care more about correctness + <nalaginrut> speak the NPTL, I ever argued with a friend since I saw + drepper mentioned NPTL should be m:n, then I thought it is...But finally + I was failed, he didn't implement it yet... + <braunr> what ? + <braunr> nptl was always 1:1 + <nalaginrut> but in nptl-design draft, I thought it's m:n + <nalaginrut> anyway, it's draft + <nalaginrut> and seems being a draft for long time + <braunr> never read anything like that + <nalaginrut> I think it's my misread + <nalaginrut> I have to go, see you guys tomorrow + <braunr> The consensus among the kernel developers was that an M-on-N + implementation + <braunr> would not fit into the Linux kernel concept. The necessary + infrastructure which would + <braunr> have to be added comes with a cost which is too high. + + --- # Resources diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn index 772fd865..3dab6d4c 100644 --- a/open_issues/performance.mdwn +++ b/open_issues/performance.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 @@ -217,3 +217,25 @@ call|/glibc/fork]]'s case. <braunr> i'm only saying that the phoronix benchmark results are useless <braunr> because they didn't measure the right thing <hroi_> ok + + +# Optimizing Data Structure Layout + +## IRC, freenode, #hurd, 2014-01-02 + + <braunr> teythoon_: wow, digging into the vm code :) + <teythoon_> i discovered pahole and gnumach was a tempting target :) + <braunr> never heard of pahole :/ + <teythoon_> it's nice + <teythoon_> braunr: try pahole -C kmem_cache /boot/gnumach + <teythoon_> on linux that is. ... + <braunr> ok + <teythoon_> braunr: http://paste.debian.net/73864/ + <braunr> very nice + + +## IRC, freenode, #hurd, 2014-01-03 + + <braunr> teythoon: pahole is a very handy tool :) + <teythoon> yes + <teythoon> i especially like how general it is diff --git a/open_issues/performance/io_system/clustered_page_faults.mdwn b/open_issues/performance/io_system/clustered_page_faults.mdwn index a3baf30d..8bd6ba72 100644 --- a/open_issues/performance/io_system/clustered_page_faults.mdwn +++ b/open_issues/performance/io_system/clustered_page_faults.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 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 @@ -160,3 +160,6 @@ License|/fdl]]."]]"""]] immediately when he stopped attending meetings... <antrik> slpz: oh, you even already looked into vm_pageout_scan() back then :-) + + +# [[Read-Ahead]] diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn index 05a58f2e..711f7691 100644 --- a/open_issues/performance/io_system/read-ahead.mdwn +++ b/open_issues/performance/io_system/read-ahead.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 @@ -3041,3 +3041,26 @@ License|/fdl]]."]]"""]] still on my TODO list <braunr> it will get merged eventually, now that the large store patch has also been applied + + +## IRC, freenode, #hurd, 2013-12-31 + + <braunr> mcsim: do you think you'll have time during january to work out + your clustered pagein work again ? :) + <mcsim> braunr: hello. yes, I think. Depends how much time :) + <braunr> shouldn't be much i guess + <mcsim> what exactly should be done there? + <braunr> probably a rebase, and once the review and tests have been + completed, writing the full changelogs + <mcsim> ok + <braunr> the libpager notification on eviction patch has been pushed in as + part of the merge of the ext2fs large store patch + <braunr> i have to review neal's rework patch again, and merge it + <braunr> and then i'll test your work and make debian packages for + darnassus + <braunr> play with it a bit, see how itgoes + <braunr> mcsim: i guess you could start with + 62004794b01e9e712af4943e02d889157ea9163f (Fix bugs and warnings in + mach-defpager) + <braunr> rebase it, send it as a patch on bug-hurd, it should be + straightforward and short diff --git a/open_issues/pfinet_timers.mdwn b/open_issues/pfinet_timers.mdwn index 5db192e3..244ca98b 100644 --- a/open_issues/pfinet_timers.mdwn +++ b/open_issues/pfinet_timers.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 @@ -117,3 +117,61 @@ License|/fdl]]."]]"""]] <braunr> yes, schedule_timeout could need a review <braunr> actually, fakeroot rm -rf * is a good test <braunr> and it's still damn slow + + +## IRC, freenode, #hurd, 2013-11-04 + + <braunr> i think i know why fakeroot is slow no + <braunr> now + <braunr> schedule_timeout as implemented in pfinet can only be awaken by a + timeout + <braunr> even when the expected even comes in earlier + <braunr> so yes, the proper solution is to rewrite the timers using + interruptible_sleep_on_timeout (and in turn + pthread_hurd_cond_timedwait_np) + <braunr> hm no, it's still not that straightforward :( + + +## IRC, freenode, #hurd, 2013-11-05 + + <braunr> youpi: i found the bug slowing down fakeroot-tcp + <braunr> it's actually a bug that slows down anything using the loopback + device + <braunr> (although there still is a problem with fakeroot chown) + <youpi> oh! + <braunr> basically + <braunr> the loopback device calls netif_rx from its xmit function + <braunr> which is perfectly fine + <braunr> except the glue code makes mark_bh (used to raise bottom halves) + broadcast a condition + <braunr> and since netif_rx is called from within xmit, which is called + from the net_bh worker thread + <braunr> the thread itself is never waiting for the condition when it is + broadcast + <braunr> it's very simple to fix, i'll send a patch later + <braunr> netcat to netcat now consumes 100% cpu + <braunr> as does fakeroot ls -Rl + <braunr> but for some reason fakeroot chown is still extremely slow + <braunr> and i've seen deadlocks in glibc (e.g. setlocale() getting the + locale lock, which is locked again in case libfakeroot fails and calls + strerror) + <braunr> so still a bit of debugging work needed + + +## IRC, freenode, #hurd, 2013-11-06 + + <braunr> chown being slow with fakeroot-tcp can also be seen on linux + + <teythoon> did your recent patch improve the performance of fakeroot-tcp ? + <braunr> yes + <teythoon> very nice :) + <braunr> but fakeroot chown is still slow + <braunr> although it's also slow on linux + <braunr> so i'm not looking into that any more for the time being + <braunr> as long as it's not used recursively on huge directories, it's + fine + + +## IRC, freenode, #hurd, 2013-11-09 + + <teythoon> braunr: fakeroot-tcp is indeed much faster now :) diff --git a/open_issues/profiling.mdwn b/open_issues/profiling.mdwn index 545edcf6..e7dde903 100644 --- a/open_issues/profiling.mdwn +++ b/open_issues/profiling.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010, 2011, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -138,3 +138,234 @@ done for [[performance analysis|performance]] reasons. know what happen and how happen, maybe just suitable for newbie, hope more young hack like it <braunr> once it's done, everything else is just sugar candy around it + + +# IRC, freenode, #hurd, 2014-01-05 + + <teythoon> braunr: do you speak ocaml ? + <teythoon> i had this awesome idea for a universal profiling framework for + c + <teythoon> universal as in not os dependent, so it can be easily used on + hurd or in gnu mach + <teythoon> it does a source transformation, instrumenting what you are + interested in + <teythoon> for this transformation, coccinelle is used + <teythoon> i have a prototype to measure how often a field in a struct is + accessed + <teythoon> unfortunately, coccinelle hangs while processing kern/slab.c :/ + <youpi> teythoon: I do speak ocaml + <teythoon> awesome :) + <teythoon> unfortunately, i do not :/ + <teythoon> i should probably get in touch with the coccinelle devs, most + likely the problem is that coccinelle runs in circles somewhere + <youpi> it's not so complex actually + <youpi> possibly, yes + <teythoon> do you know coccinelle ? + <youpi> the only really peculiar thing in ocaml is lambda calculus + <youpi> +c + <youpi> I know a bit, although I've never really written an semantic patch + myself + <teythoon> i'm okay with that + <youpi> but I can understand them + <youpi> then ocaml should be fine for you :) + <youpi> just ask the few bits that you don't understand :) + <teythoon> yeah, i haven't really made an effort yet + <youpi> writing ocaml is a bit more difficult because you need to + understand the syntax, but for putting printfs it should be easy enough + <youpi> if you get a backtrace with ocamldebug (it basically works like + gdb), I can probably explain you what might be happening + + +## IRC, freenode, #hurd, 2014-01-06 + + <teythoon> braunr: i'm not doing microoptimizations, i'm developing a + profiler :p + <braunr> teythoon: nice :) + <teythoon> i thought you might like it + <braunr> teythoon: you may want to look at + http://pdos.csail.mit.edu/multicore/dprof/ + <braunr> from the same people who brought radixvm + <teythoon> which data structure should i test it with next ? + <braunr> uh, no idea :) + <braunr> the ipc ones i suppose + <teythoon> yeah, or the task related ones + <braunr> but be careful, there many "inline" versions of many ipc functions + in the fast paths + <braunr> and when they say inline, they really mean they copied it + <braunr> +are + <teythoon> but i have a microbenchmark for ipc performance + <braunr> you sure have been busy ;p + <braunr> it's funny you're working on a profiler at the same time a + collegue of mine said he was interested in writing one in x15 :) + <teythoon> i don't think inlining is a problem for my tool + <teythoon> well, you can use my tool for x15 + <braunr> i told him he could look at what you did + <braunr> so i expect he'll ask soon + <teythoon> cool :) + <teythoon> my tool uses coccinelle to instrument c code, so this works in + any environment + <teythoon> one just needs a little glue and a method to get the data + <braunr> seems reasonable + <teythoon> for gnumach, i just stuff a tiny bit of code into the kdb + + <teythoon> hm debians bigmem patch with my code transformation makes + gnumach hang early on + <teythoon> i don't even get a single message from gnumach + <braunr> ouch + <teythoon> or it is somethign else entirely + <teythoon> it didn't even work without my patches o_O + <teythoon> weird + <teythoon> uh oh, the kmem_cache array is not properly aligned + <teythoon> braunr: http://paste.debian.net/74588/ + <braunr> teythoon: do you mean, with your patch ? + <braunr> i'm not sure i understand + <braunr> are you saying gnumach doesn't start because of an alignment issue + ? + <teythoon> no, that's unrelated + <teythoon> i skipped the bigmem patch, have a running gnumach with + instrumentation + <braunr> hum, what is that aliased column ? + <teythoon> but, despite my efforts with __attribute__((align(64))), i see + lot's of accesses to kmem_cache objects which are not properly aligned + <braunr> is that reported by the performance counters ? + <teythoon> no + <teythoon> http://paste.debian.net/74593/ + <braunr> aer those the previous lines accessed by other unrelated code ? + <braunr> previous bytes in the same line* + <teythoon> this is a patch generated to instrument the code + <teythoon> so i instrument field access of the form i->a + <teythoon> but if one does &i->a, my approach will no longer keep track of + any access through that pointer + <teythoon> so i do not count that as an access but as creating an alias for + that field + <braunr> ok + <teythoon> so if that aliased count is not zero, the tool might + underestimate the access count + <teythoon> hm + <teythoon> static struct kmem_cache kalloc_caches[KALLOC_NR_CACHES] + __attribute__((align(64))); + <teythoon> but + <teythoon> nm gnumach|grep kalloc_caches + <teythoon> c0226e20 b kalloc_caches + <teythoon> ah, that's fine + <braunr> yes + <teythoon> nevr mind + <braunr> don't we have a macro for the cache line size ? + <teythoon> ah, there are a great many more kmem_caches around and noone + told me ... + <braunr> teythoon: eh :) + <braunr> aren't you familiar with type-specific caches ? + <teythoon> no, i'm not familiar with anything in gnumach-land + <braunr> well, it's the regular slab allocator, carrying the same ideas + since 1994 + <braunr> it's pretty much the same in linux and other modern unices + <teythoon> ok + <braunr> the main difference is likely that we allocate our caches + statically because we have no kernel modules and know we'll never destroy + them, only reap them + <teythoon> is there a macro for the cache line size ? + <teythoon> there is one burried in the linux source + <teythoon> L1_CACHE_BYTES from linux/src/include/asm-i386/cache.h + <braunr> there is one in kern/slab.h + <teythoon> but it is out of date + <teythoon> there is ? + <braunr> but it's commented out + <braunr> only used when SLAB_USE_CPU_POOLS is defined + <braunr> but the build system should give you CPU_L1_SHIFT + <teythoon> hm + <braunr> and we probably should define CPU_L1_SIZE from that + unconditionnally in config.h or a general param.h file if there is one + <braunr> the architecture-specific one perhaps + <braunr> although it's exported to userland so maybe not + + +## IRC, freenode, #hurd, 2014-01-07 + + <teythoon> braunr: linux defines ____cacheline_aligned : + http://lxr.free-electrons.com/source/include/linux/cache.h#L20 + <teythoon> where would i put a similar definition in gnumach ? + <taylanub> .oO( four underscores ?!? ) + <teythoon> heh + <teythoon> yes, four + <braunr> teythoon: yes :) + + <teythoon> are kmem_cache objects ever allocated dynamically in gnumach ? + <braunr> no + <teythoon> hm + <braunr> i figured that, since there are no kernel modules, there is no + need to allocate them dynamically, since they're never destroyed + <teythoon> so i aligned all statically declarations with + __attribute__((align(1 << CPU_L1_SHIFT))) + <teythoon> but i still see 77% of all accesses being to objects that are + not properly aligned o_O + <teythoon> ah + <teythoon> >,< + <braunr> you could add an assertion in kmem_cache_init to find out what's + wrong + <teythoon> *aligned + <braunr> eh :) + <braunr> right + <teythoon> grr + <teythoon> sweet, the kmem_caches are now all properly aligned :) + <braunr> :) + + <braunr> hm + <braunr> i guess i should change what vmstat reports as "cache" from the + cached objects to the external ones (which map files and not anonymous + memory) + <teythoon> braunr: http://paste.debian.net/74869/ + <teythoon> turned out that struct kmem_cache was actually an easy target + <teythoon> no bitfields, no embedded structs that were addressed as such + (and not aliased) + <braunr> :) + + +## IRC, freenode, #hurd, 2014-01-09 + + <teythoon> braunr: i didn't quite get what you and youpi were talking about + wrt to the alignment attribute + <teythoon> define a type for struct kmem_cache with the alignment attribute + ? is that possible ? + <teythoon> ah, like it's done for kmem_cpu_pool + <braunr> teythoon: that's it :) + <braunr> note that aligning a struct doesn't change what sizeof returns + <teythoon> heh, that save's one a whole lot of trouble indeed + <braunr> you have to align a member inside for that + <teythoon> why would it change the size ? + <braunr> imagine an array of such structs + <teythoon> ah + <teythoon> right + <teythoon> but it fits into two cachelines exactly + <braunr> that wouldn't be a problem with an array either + <teythoon> so an array of those will still be aligned element-wise + <teythoon> yes + <braunr> and it's often used like that, just as i did for the cpu pools + <braunr> but then one is tempted to think the size of each element has + changed too + <braunr> and then use that technique for, say, reserving a whole cache line + for one variable + <teythoon> ah, now i get that remark ;) + <braunr> :) + + <teythoon> braunr: i annotated struct kmem_cache in slab.h with + __cacheline_aligned and it did not have the desired effect + <braunr> can you show the diff please ? + <teythoon> http://paste.debian.net/75192/ + <braunr> i don't know why :/ + <teythoon> that's how it's done for kmem_cpu_pool + <braunr> i'll try it here + <teythoon> wait + <teythoon> i made a typo + <teythoon> >,< + <teythoon> __cachline_aligned + <teythoon> bad one + <braunr> uh :) + <braunr> i don't see it + <braunr> ah yes + <braunr> missing e + <teythoon> yep, works like a charme :) + <teythoon> nice, good to know :) + <braunr> :) + <teythoon> given the previous discussion, shall i send it to the list or + commit it right away ? + <braunr> i'd say go ahead and commit diff --git a/open_issues/robustness.mdwn b/open_issues/robustness.mdwn index a6b0dbfb..4b0cdc9b 100644 --- a/open_issues/robustness.mdwn +++ b/open_issues/robustness.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 @@ -12,6 +13,7 @@ License|/fdl]]."]]"""]] [[!toc]] + # IRC, freenode, #hurd, 2011-11-18 <nocturnal> I'm learning about GNU Hurd and was speculating with a friend @@ -167,3 +169,49 @@ License|/fdl]]."]]"""]] http://darnassus.sceen.net/gitweb/teythoon/reincarnation.git/blame/HEAD:/reincarnation.defshttp://darnassus.sceen.net/gitweb/teythoon/reincarnation.git/blame/HEAD:/reincarnation.defs < teythoon> uh >,< sorry, pasted twice < braunr> oh ok + + +## IRC, freenode, #hurd, 2014-02-01 + + <pere> btw, can hurd upgrade the kernel without reboot? + <teythoon> no + <teythoon> but since most functionality is not within the kernel, the more + interesting question is, what parts of the hurd can be replaced at + runtime + <pere> ok. what is the answer to that question? + <teythoon> no hurd server can be restarted transparently, i.e. w/o its + clients noticing that + <teythoon> however, if a server is not in use, it can be easily restarted + <teythoon> transparently restarting servers would be nice + <teythoon> and i believe it is even possible on mach + <braunr> teythoon: how ? + <teythoon> one has to retain two things, client-related state and the port + right + <braunr> doesn't that require persistence ? + <teythoon> it does + <teythoon> but i see no reason why it should not be possible to implement + this on top of mach + <braunr> maybe + <teythoon> the most crucial thing is to preserve the receive port, and to + replace the server without race-conditions + <teythoon> receive rights can be transfered using the notification + mechanism + + <antrik> braunr: restarting servers doesn't exactly require + persistance. you only need to pass the state from the old server to the + new one, rather than serialising it for on-disk storage. it's a slightly + easier requirement... + <antrik> (most notably, you don't need any magic to keep the capabilities + around -- just pass them over using normal IPC) + <teythoon> antrik: i agree, but then again, once this is in place, adding + persistence is only a little step + <antrik> teythoon: depends. if it's implemented with persistence in mind + from the beginning, it might be a fairly small step indeed; but + otherwise, it could be two entirely different things + <antrik> this also depends on the kind of persistence you want + <antrik> I must say that for the kind of persistence *I* would like, it is + indeed quite related + <teythoon> well, please elaborate a little :) + <teythoon> what do you have in mind ? + <antrik> busy right now... remind me some other time if I forget :-) + <teythoon> sure diff --git a/open_issues/serial_console.mdwn b/open_issues/serial_console.mdwn index ed6358a2..827fd211 100644 --- a/open_issues/serial_console.mdwn +++ b/open_issues/serial_console.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,7 +10,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation]] -IRC, #hurdfr, 2010-09-20 + +# IRC, freenode, #hurdfr, 2010-09-20 <youpi> tu peux compiler ton gnumach pour qu'il utilise la console série, et tu mets le port série sur la console qemu @@ -50,3 +51,56 @@ IRC, #hurdfr, 2010-09-20 <youpi> pour xen j'ai mis £ comme raccourcis <manuel> ça me paraît plus simple dans ce cas <youpi> clin d'œil à la société anglaise :) + + +# IRC, freenode, #hurd, 2014-02-20 + + <gg0> 04:06:45< gg0> ok a configuration that works w/o patching anything is + 9600 7S1 [ 7bits - parity Space - 1 stopbit ] + <gg0> 04:07:57< gg0> it displays correctly gnumach, ext2fs and following + outputs + <gg0> 04:28:05< gg0> youpi: instead if you want a patch, this one makes + gnumach default to 8N1. someone should still implement serial line + settings for ext2fs though + <gg0> seems something broke it later + <gg0> or it never worked on real hardware + <braunr> we definitely want it to work with 8N1 + <gg0> never had problems with _virtual_ serial consoles + <gg0> never = during last 2 years = since + http://git.savannah.gnu.org/gitweb/?p=hurd/gnumach.git;a=commitdiff;h=2a603e88f86bee88e013c2451eacf076fbcaed81 + <gg0> but i don't think i was on real hardware at that time + + +## IRC, freenode, #hurd, 2014-02-21 + + <gg0> yeah, i have one rebuilt trying to fix serial console (already give + up) + <teythoon> what were you trying to fix ? + <gg0> i didn't fix anything but it's been useful somehow :) + <gg0> this one http://paste.debian.net/plain/83292 + <gg0> initial messages from mach/hurd outputs like there was no line feed + <gg0> each line overwrites previous one + <gg0> then ext2fs outputs garbage + <gg0> then openrc start outputting fine + <gg0> minicom 9600 8N1 + <teythoon> this is from a real machine ? + <gg0> yep real machine + <teythoon> nice :) + <gg0> i fixed last line, last garbage, by switching c: from 38400 to 9600 + in inittab + <teythoon> i've a vt510 terminal connected to my hurd box, and i started to + make the serial setting in gnumach more configurable + <gg0> and disabling T0 + <teythoon> didn't finish it though + <gg0> physical vt510 connected to virtual hurd box? + <teythoon> no, it's a real box as well + <gg0> good. and does it behave as described/pasted above? + <teythoon> currently i do not put the mach console on the serial line + <teythoon> b/c it has a fixed baud rate of 9600 + <teythoon> and both grub and the getty are configured at a higher speed + <teythoon> hence my desire to improve gnumachs serial port setup + <gg0> i don't care much about speed. such no-line-feed behavior is quite + annoying though + <gg0> i thought it was related to CRMOD which afaiu should translate cr to + cr-lf, but i was surely missing something + <gg0> (annoying till one does ^A-A to make minicom add line feeds itself) diff --git a/open_issues/system_initialization.mdwn b/open_issues/system_initialization.mdwn index 9048b615..0df1078e 100644 --- a/open_issues/system_initialization.mdwn +++ b/open_issues/system_initialization.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,7 +10,8 @@ License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] -IRC, freenode, #hurd, 2011-03-30 + +# IRC, freenode, #hurd, 2011-03-30 <kilobug> init=/bin/sh hack doesn't work for GNU/Hurd ? <antrik> kilobug: I don't think you can override init on Hurd. the init @@ -19,6 +20,23 @@ IRC, freenode, #hurd, 2011-03-30 server to *only* do that, and then pass on to standard sysv init... with that it could actually work ---- - * [[systemd]], etc. +# IRC, freenode, #hurd, 2013-11-29 + + <teythoon> we need to make the bootstrap code more robust and fix the error + handling there + <teythoon> for example, you can kill the exec server and the rootfs w/o + /hurd/init noticing it... + <braunr> yes + <teythoon> there are plans in init.c to take over the exception port of the + essential processes + <teythoon> that could help + + +# [[hurd_init]] + + +# [[Anatomy_of_a_Hurd_System]] + + +# [[systemd]] diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn index 1f3eea03..ca910491 100644 --- a/open_issues/systemd.mdwn +++ b/open_issues/systemd.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010, 2011, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -27,7 +27,9 @@ Daniel Gollub, Stefan Seyfried, 2010-10-14. Likely there's also some other porting needed. -# IRC, OFTC, #debian-hurd, 2011-05-19 +# Discussion + +## IRC, OFTC, #debian-hurd, 2011-05-19 <pinotree> pochu: http://news.gmane.org/gmane.comp.gnome.desktop - the "systemd as dependency" and all the messages in it don't give me a bright @@ -172,7 +174,7 @@ Likely there's also some other porting needed. <azeem> anyway, I'll talk to the upstart guys about libnih -## IRC, OFTC, #debian-hurd, 2013-08-15 +### IRC, OFTC, #debian-hurd, 2013-08-15 <azeem> btw, I talked to vorlon about upstart and the Hurd <azeem> so the situation with libnih is that it is basically @@ -183,6 +185,16 @@ Likely there's also some other porting needed. patches +### IRC, OFTC, #debian-hurd, 2013-11-28 + + <azeem> teythoon: did you see they got libnih ported to kfreebsd? + <azeem> http://lists.debian.org/debian-devel/2013/11/msg00395.html + <azeem> "I haven't started looking into Hurd yet," sounds promising + <teythoon> saw that + <teythoon> i looked at libnih too + <teythoon> wrote a mail about that + + ## IRC, freenode, #hurd, 2013-08-26 < youpi> teythoon: I tend to agree with mbanck @@ -1035,6 +1047,2591 @@ Likely there's also some other porting needed. wrecks havoc on the system +## IRC, freenode, #hurd, 2014-01-03 + + <gg0> openrc on debian + https://buildd.debian.org/status/package.php?p=openrc&suite=experimental + <braunr> gg0: ah nice + + +## IRC, freenode, #hurd, 2014-01-11 + + <gnu_srs1> teythoon: is the Hurd boot now fully init compatible? I would + like to try to boot with a ported openrc in a sandbox kvm:P + + +### IRC, freenode, #hurd, 2014-01-12 + + <teythoon> gnu_srs1: yes, go ahead + <teythoon> gnu_srs1: you'll have to switch to sysvinit first + <teythoon> for that, you need patched sysvinit packages + + <gnu_srs> teythoon: do you mean the parches in #721917? + <teythoon> gnu_srs: yes, mostly, but there is one final patch missing + <gg0> uploading patched sysvinit to debian-ports? (or braunr's or + teythoon's repos) + <teythoon> gg0, gnu_srs: they are actually here + http://teythoon.cryptobitch.de/gsoc/heap/debian/ but outdated + <gnu_srs> teythoon: if the sysvinit patches are outdated, can you update + them please? and provide a package for upload to -ports (as gg0 proposed) + <teythoon> gnu_srs: i will + <gnu_srs> tks:) + + +### IRC, freenode, #hurd, 2014-01-13 + + <teythoon> gnu_srs: i updated the sysvinit patches + <teythoon> gnu_srs: for your convenience, here are packages: + http://darnassus.sceen.net/~teythoon/heap/sysvinit/ + <teythoon> gnu_srs: you have to install the sysvinit-core package first, + then the others + <teythoon> to switch to sysvinit, do update-alternatives --config runsystem + and select runsystem.sysv + <teythoon> then, do reboot-hurd and hope for the best ;) + + <gnu_srs> teythoon: thanks, will try soon. Are you submitting the updated + patches to #721917 too? + <teythoon> gnu_srs: i already did + <gnu_srs> good;-) + <gnu_srs> teythoon: rebooted with sysv:http://paste.debian.net/75925/ + <teythoon> gnu_srs: please, whenever you run into a problem, give more + context + <teythoon> which file are you talking about ? + <teythoon> also, as the postinst script advised you, you need to use + {halt,reboot}-hurd *whenever* you switch the runsystem + <teythoon> not doing so wont do any harm, but it wont work + <teythoon> shutdown: /run/initctl: No such file or directory <-- that's + what happens if you run reboot (=reboot-sysv) w/o sysvinit being run + <teythoon> if you don't get a getty on the console, check /etc/inittab + <gnu_srs> I did note see a message from any posinst script about + {halt,reboot}-hurd, only LC* related messages + <gnu_srs> A I missed it: You must use halt-hurd or reboot-hurd to halt or + reboot the + <gnu_srs> system whenever you change the runsystem. + <gnu_srs> I don't see anything suspicious in /etc/inittab, + eg. 1:2345:respawn:/sbin/getty 38400 tty1 is there + <teythoon> 7:2345:respawn:/sbin/getty 38400 console + <teythoon> then, you'll get a getty on the mach console, even if the + hurd-console does not start + <gnu_srs> teythoon: with 7:2345:respawn:/sbin/getty 38400 console in + /etc/inittab I get a (mach) console. + <gnu_srs> never seen that mentioned anywhere + <gnu_srs> anyway, the image is now booted with sysvinit. next to try will + be openrc:P + <teythoon> gnu_srs: you haven't heard of the inittab entry for the mach + console before b/c the inittab was not used before on the hurd + <teythoon> i should probably write that down in the wiki somewhere... + <youpi> shouldn't the upgrade of the sysvinit package do it too? + <youpi> (does it at least install a correct version on newer installs?) + <teythoon> it probably should / i'm not sure + + +## IRC, freenode, #hurd, 2014-01-13 + + <teythoon> gnu_srs: have you ported openrc already ? + <gnu_srs> I made it build (with temporary workarounds for PATH_MAX) but + need to change at least one file to be hurd-specific before trying to + boot + <teythoon> cool :) + <gg0> i guess not much different from http://paste.debian.net/plain/75893/ + <gg0> (i didn't say it sucks but one can find it out by taking a look) + <gnu_srs> gg0: Have you talked to zigo in #openrc?. He has partial patches + (submitted to the debian repo), you do and me too. + <gnu_srs> Maybe we should align our work. + <gnu_srs> The file to make Hurd-specific is: init.sh.GNU (you start with + copy of the Linux version, I start from a copy of the BSD version). + <gnu_srs> BTW: I don't think fstabinfo is available for GNU/Hurd! + <gnu_srs> gg0: Sorry, fstabinfo and moutinfo are parts of openrc, my bad:-D + <gnu_srs> mountinfo* + + +## IRC, freenode, #hurd, 2014-01-15 + + <gnu_srs> Hi, is these some simple way to find out the sequence of commands + executed during boot: + <gnu_srs> current using runsystem.gnu and with sysv-rc using runsystem.sysv + <gnu_srs> I need to edit on file of OpenRC before trying to boot with + it. (mainly mounting /run/*) + <gnu_srs> Is mount functional or is settrans .needed? + + +## IRC, freenode, #hurd, 2014-01-16 + + <ArneBab> gnu_srs: you are adding OpenRC? cool! + <gnu_srs> ArneBab: Working on it, will try booting when my questions here + have been answered ;-) + <teythoon> gnu_srs: mount is functional enough to boot Debian/Hurd using + sysvinit + <teythoon> gnu_srs: you could add "set -x" to runsystem.*, or add "bash" to + just drop into a shell and examine the environment interactively + <gnu_srs> teythoon: Hi, is mount a wrapper on top of settrans ...? + <teythoon> yes + <gnu_srs> how to log the boot sequence, when booting the mach console is + cleared when the hurd console starts? + <teythoon> you could just disable the hurd console + <gnu_srs> and the kvm console does not have scrolling functionality + <teythoon> it's actually the mach console that lacks this + <gnu_srs> copying manually is cumbersome, even if all is readable + <teythoon> but as a workaround you can use kvm .... -curses and use xterms + backlog + <teythoon> and c&p works then :) + <gnu_srs> tks, I'll try with that:P + + +## IRC, freenode, #hurd, 2014-01-17 + + <gnu_srs> BTW: zigo successfully booted openrc on Hurd, I haven't tried + yet,, you know things coming in between. He used my patches to create + updated ones:) + <gnu_srs> that version is now in experimental (I still have to operate away + all those PATH_MAX issues, and fins at least one sh file). + <teythoon> :/ + + +## IRC, freenode, #hurd, 2014-01-21 + + <gnu_srs> teythoon: I don't get a scrollable output when using -curses in + kvm, to be able to see all startup messages. Any other ideas? + <teythoon> gnu_srs: are you sure ? i just tested this, and it works nicely + for me + <teythoon> gnu_srs: that's how i created all the "screenshots" for my blog + posts + <gnu_srs> teythoon: kvm -m 1024 -net nic,model=rtl8139 -net + user,hostfwd=tcp::5564-:22 -curses -hda debian-hurd-20140115.img + <teythoon> ah, my bad + <teythoon> gnu_srs: try -nographic + <teythoon> oh, and maybe you need to add console=com0 to the gnumach + command line + <teythoon> b/c with -nographic, the first serial port is connected to qemus + stdio + <teythoon> sorry, i mixed this up + <gnu_srs> and how to add console=com0 to the qemu start oprtions? -kernel + and -append are Linux only + <teythoon> # grep console /etc/default/grub + <teythoon> GRUB_CMDLINE_GNUMACH="console=com0 --crash-debug" + <teythoon> and if you want grub on the serial port: + <teythoon> # grep serial /etc/default/grub + <teythoon> GRUB_TERMINAL=serial + <teythoon> GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 + --parity=no --stop=1" + <gnu_srs> teythoon: with -nographic I don't get any output at all? + <teythoon> did you run update-grub ? + <gnu_srs> aha, will do + <gnu_srs> still no scrollbar with gnome-terminal, will try with xterm and + rxvt + <gnu_srs> it works: with rxvt, tks:-D + <teythoon> good :) + <teythoon> i found -nographic to be quite handy + <gnu_srs> in /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet" and + GRUB_CMDLINE_LINUX="" #GRUB_DISABLE_LINUX_UUID=true + <gnu_srs> linux configuration parameters in a gnumach boot setup? + <teythoon> those won't be used + <teythoon> unless the grub scripts find a linux kernel in /boot + <teythoon> it's just the stock debian configuration file + <gnu_srs> nevertheless:-( + <teythoon> what ? + <gnu_srs> there could be OS-specific files: Linux, kFreeBSD, Hurd? + <teythoon> or, preferebly, one that works on every os ? like it is now ;) + <gnu_srs> OK, one that works on every OS, with a common part and + OS-specific parts? + <teythoon> that's how it is now + <teythoon> stuff with LINUX in it is used for linux + <teythoon> stuff with GNUMACH in it is used for gnumach + + +## IRC, freenode, #hurd, 2014-01-22 + + <gnu_srs> teythoon: A boot message segfault: (syv-rc specific?) + <gnu_srs> + exec /sbin/init -a + <gnu_srs> INIT: version 2.88 booting + <gnu_srs> Using makefile-style concurrent boot in runlevel S. + <gnu_srs> end_request: I/O error, dev 02:00, sector 0 + <gnu_srs> Segmentation fault + <gnu_srs> Activating swap...done. + <gnu_srs> Checking root file system...fsck from util-linux 2.20.1 + <gnu_srs> another: mount: cannot remount /proc: Invalid argument + <gnu_srs> ... + <gnu_srs> df: Warning: cannot read table of mounted file systems: No such + file or directory + <gnu_srs> openrc boots on Hurd, login (user,root) works, read-only mode so + far, have to tweak some scripts:) + <braunr> not bad + <ArneBab> gnu_srs: woah! + <ArneBab> very cool! + + +## IRC, freenode, #hurd, 2014-01-22 + + <ArneBab> I think with that you are doing the most useful thing to avoid + OpenRC: If it provides almost the same as systemd and runs on the Hurd, + then there is no technical reason for using systemd, but many against it. + <ArneBab> s/avoid OpenRC/avoid systemd/ + <ArneBab> (gah, brain is jumbled) + <Shentino> I hate systemd because it monopolizes cgroups + <Shentino> which is SUPPOSED to be a generic interface open to anyone + <Shentino> I do not want an unholy alliance in a kernel-user api + <azeem_> ArneBab: the openrc maintainer will take care it will get + communicated + <azeem_> ArneBab: also, not sure what you mean about systemd, the question + isn't so much between openrc vs. systemd, but upstart vs. systemd + <azeem_> at least for the Technical Committee decision, none of the + tech-ctte members seems to consider openrc as n realistic contender + <azeem_> s/as n/as a/ + <gnu_srs> azeem_: seem like it is so:-( + <gnu_srs> maybe in a future, if openrc gets some attention and developers, + it could become a one-for-all solution;-) + <teythoon> gnu_srs: nice :) + <teythoon> ignore the proc related message + <teythoon> gnu_srs: there is no way to associate the segfault with a + process for me, can you shed some light on which process dies ? + <teythoon> as for df complaining, you could fix this up like youpi did: + <teythoon> grep ln /etc/hurd/rc + <teythoon> ln -s /proc/mounts /var/run/mtab + <teythoon> the proper way is to fix our libc of course + <gnu_srs> teythoon: I was just coping the boot messages, I don't know + either which process segfaults + <teythoon> hm, maybe you can make openrc more verbose about what it starts + <gnu_srs> All I wrote earlier was from sysv-rc + <teythoon> ah + <teythoon> i've never seen that then + <ArneBab> azeem_: actually I think OpenRC is the only sane choice: It is + the only choice which supports other kernels. + <ArneBab> Shentino: I can’t stand systemd, because it establishes a tight + control over the init process by encouraging developers to add + dependencies to libraries which are so tightly coupled with others, that + they cannot be adapted without affecting the whole system. + <ArneBab> Shentino: But I wrote about that in much more details: + http://draketo.de/light/english/top-5-systemd-troubles TL;DR: + distributions become completely dependent on a small group and they throw + away the skills their maintainers already have (shell scripting) + <ArneBab> And systemd is Linux-only… + <ArneBab> …with no intention of changing that. + <braunr> why would debian strive to support other kernels ? + <braunr> instead of other kernels adjusting ? + <braunr> if posix introduces new apis, are we going to say no, or are we + going to try and support them ? + <braunr> the issue of multi-kernel support is completely irrelevant + <braunr> what you're saying about tight coupling is actually the only real + issue of systemd + <ArneBab> braunr: I see a difference between providing a stable API which + others can easily replicate and a running target with no intention to + become cross-kernel usable (my experience with udev suggests that they + won’t really try to keep anything stable for long). + <ArneBab> braunr: but the tight coupling is the main issue for me, too: + that creates a vulnerability for the free software community. + <braunr> no, the free software community doesn't risk much here + <braunr> it's a technical problem + <braunr> ok, yes, posix as a point of convergence is clearly not the same + as linux as an implementation that diverges + <braunr> agreed + <ArneBab> if the systemd people decide to go a certain direction which + makes it impossible to provide a certain feature while using their new + tech, then there is a problem. + <braunr> but it still implies we have to adapt + <braunr> from my point of view, multi-kernel distributions are a technical + heresy + <braunr> if you want something really efficient, you want it very well + integrated + <teythoon> i'm concerned by the linux kernel making up interfaces w/o + proper considerations + <ArneBab> braunr: in Gentoo we had all the hassle with /usr on a separate + partition. There are usecases for that, and Gentoo wanted to provide + them, but udev (now systemd) made that impossible. + <braunr> teythoon: yes i'm concerned about that too + <teythoon> we will never be able to implement the cgroup interface for + example b/c it is too badly designed + <braunr> badly ? + <braunr> it's system specific + <ArneBab> braunr: also the systemd folks could essentially hold Linus at + ransom: “We couple userspace tightly to implementation details in the + kernel, so when you break the implementation in a way which we don’t + like, you’ll break userspace in the worst possible way” + <braunr> it's very hard to design an interface without properly + understanding what it would internally imply in the implementation + <braunr> ArneBab: that's already the case + <teythoon> system specific in a way that it will be impossible to implement + on non-monolithic kernels + <braunr> teythoon: exactly + <braunr> they didn't think of that because they don't care + <braunr> and why would they ? + <braunr> it doesn't make the interface bad per se + <ArneBab> it is the case in systemd, but not in sysVinit + <braunr> well it is too + <braunr> but sysvint is less demanding + <braunr> again, the coupling is the problem + <ArneBab> yes + <braunr> systemd comes from people with other goals and interests + <ArneBab> I think everything I wrote comes down to that. + <braunr> they're very technical, very business oriented + <braunr> they want to get up to speed with competitors quickly + <braunr> they're not wrong in doing that + <braunr> it just helps understand why they get with such results + <ArneBab> A distribution would be foolish to let other people take over a + crucial part of the system when those other people have a track record of + coupling more and more parts of the system with their product. + <braunr> and i agree, i don't want it either + <braunr> but please, stop with the nonsense + <braunr> don't say openrc is the only sane one because it's the only + multikernel one + <braunr> personally, i consider that very argument almost insane itself + <braunr> considering distributions that are hardly used can really have any + weight in the decision is absurd + <ArneBab> openrc is the only sane one, because it keeps already aquired + skills useful. + <braunr> s/distributions/kernels/ + <ArneBab> (that’s my opinion) + <braunr> we have to make progress + <braunr> the init system is clearly obsolete and lacking features + <braunr> so "acquired" skills here are irrelevant too + <braunr> if it takes acquiring new skills to operate a better init system, + i'm all for it + <braunr> after all, it makes a lot more sense to me than all those fancy + languages/technologies like C# and ruby that have gained so much + popularity in so little time + <ArneBab> If you can get a similarly good init system wiothut forcing + people to learn new skills, that’s a big win. + <braunr> you probably can't + <ArneBab> OpenRC is pretty close in features to systemd + <teythoon> err + <teythoon> not even close + <braunr> teythoon is right + <braunr> openrc is just sysvinit++ + <teythoon> no + <teythoon> openrc replaces the sysv rc, not sysvinit + <braunr> ok + <teythoon> it complements it + <braunr> i wasn"'t being pedantic here + <teythoon> nicely in my opinion + <braunr> yes i like it too + <braunr> but i'm afraid it's not a complete solution + <ArneBab> I think I need to be more pedantic in what I say: A system-boot + with OpenRC is pretty close in features to a system-boot using systemd. + <braunr> on the other hand, when i see discussions about event driven + systems and handling of dependencies, it sounds like something like + openrc could do the job, and something else, system-specific, would + handle the rest + <braunr> ArneBab: i disagree + <teythoon> me too + <teythoon> ArneBab: have you actually used systemd? + <ArneBab> I have read about what it provides. + <ArneBab> My udev experience burned me pretty badly. + <braunr> udev is only one part + <braunr> but actually, coupling is both a problem and a great feature + <teythoon> yes + <braunr> it's precisely the integration of many services previously + organized in a very messy way that makes it better + <braunr> and cgroups, by accurately tracking resources, allow even better + control + <teythoon> heh, i watched lennarts recent talk about kdbus + <ArneBab> but it does so by pulling in more and more parts instead of + providing a clean interface which separate projects can use. + <braunr> again, the coupling is too tight + <braunr> it's hard to hook in between + <ArneBab> teythoon: I watched lennart troll a talk pretty badly… + <ArneBab> braunr: yes + <teythoon> he cites mach and hurd for having an nice ipc mechanism, and + linux lacking such a system + <braunr> haha + <braunr> i was expecting such comparisons :) + <ArneBab> that’s why he writes an init-system which does not run on the + Hurd… + <teythoon> ArneBab: that's trolling on your part ;) + <braunr> :) + <ArneBab> somehow yes… + <braunr> what i personally get out of this is that, in the end, proper + messaging at the kernel level is something people do want + <braunr> and if you make stuff like x use it, why not things like the + network stack and the file system + <teythoon> i wish the linux kernel would allow the kernel devs to write + nicer interfaces + <ArneBab> yes + <braunr> they're almost in the process of acknowledging the merits of + multiserver architectures :) + <teythoon> b/c they lack a proper ipc mechanism, they do stuff like ad-hoc + filesystem-based interfaces that are crappy to support on the hurd :-/ + * ArneBab has been out of the loop for too long… + <braunr> teythoon: what file system do you consider "crappy to support on + the hurd" ? + <teythoon> braunr: cgroupfs in particular + <teythoon> not crappy, but impossible + <braunr> well, that's probably because we need realy resource containers + first + <braunr> real* + <teythoon> no, we'll never be able to implement the current interface + <braunr> i didn't study it as you did so i trust you + <teythoon> braunr: + http://teythoon.cryptobitch.de/posts/cgroupfs-is-as-cgroupy-as-it-gets/ + <braunr> ok this would require proper support at the client side + <teythoon> yes + <braunr> i wouldn't say impossible but definitely not as clean as we would + want it + <braunr> far from it + <teythoon> how would you ever implement it w/o fixing the client + (i.e. fixing the interface first) ? + <braunr> the client would translate the request + <teythoon> magical write retries ? + <braunr> probably + <teythoon> uh + <braunr> clients are the only entities which know what their file + desctiptors refer to + <braunr> descriptors* + <teythoon> yes + <braunr> so writing such a request would make the client get a magic retry, + and use the proper rpc, passing the proper rights instead + <teythoon> yeah, i can see how that could work + <teythoon> but i'm not sure that we should go down this path ... + <braunr> we probably really do'nt want to :) + <braunr> i'd personally be fine if debian would allow two init systems + <teythoon> me too + <braunr> with the powerful linux-specific one still allowing sysvinit + scripts + <teythoon> in particular b/c the sysvinit scripts are already there + <braunr> from what i've read, they all provide some decent backward + compatibility with sysvinit + <teythoon> yes + <braunr> and i think we can count on the linux community to riot if, + assuming systemd was chosen, it becomes too hard to use and tweak + <braunr> again, these people want their software to be used + <braunr> so they'll probably manage something decent in the long run, + whatever is chosen + <braunr> i don't care much + <braunr> :) + <kilobug> AFAIK Debian is planning to let users chose the init system, the + discussion is only on what should be the main/default one; but I might + have misunderstood it + <braunr> that was one of the possibilities, yes + <braunr> maybe we could help the debate by agreeing on whether or not we + consider supporting ports is that important, as port maintainers, + considering we'll probably keep the ability to use sysvinit scripts + anyway + <braunr> and making that decision known + <teythoon> and stating that we consider openrc an worthwile incremental + improvement, whatever debian decides to do wrt to the default init system + <braunr> for example, yes + <braunr> we should discuss that with youpi and thomas + <braunr> tschwinge: ^ + <braunr> when they have some time later :) + + +## IRC, freenode, #hurd, 2014-01-24 + + <gnu_srs> Good news, a successful boot of Hurd with OpenRC: + http://paste.debian.net/78119/ :-) + <gnu_srs> ramains to fix the false negative for checkpath -W + <gnu_srs> remains* + <braunr> not bad + + <gnu_srs> teythoon: btw, the segfault happens when starting the bootlogd + service: + <gnu_srs> end_request: I/O error, dev 02:00, sector 0 + <gnu_srs> Segmentation fault + <teythoon> gnu_srs: nice progress :) + <teythoon> i've never seen bootlogd crash like that, though i + <teythoon> i'm not sure it is installed + <gnu_srs> how can I check / ? it is mounted RW and even if cd to /run which + is on tmpfs, fsysopts --readonly fails: + <gnu_srs> :fsysopts: /: --readonly: Device or resource busy + <gnu_srs> I don't have bootlogd installed the segfault is at: + <gnu_srs> checkroot.sh: hwclock.sh mountdevsubfs.sh hostname.sh hdparm + keyboard-setup + <gnu_srs> called by /etc/rcS.d/S06checkroot.sh + <teythoon> you should probably create this directory that it fails to + create early in the boot process + + +## IRC, freenode, #hurd, 2014-01-25 + + <antrik> braunr: being Linux-only is *part* of the "tight coupling" + strategy of the systemd cabal + <antrik> of course you could implement all the Linux-specific interfaces on + other systems; as you could implement any other interfaces relied upon or + provided by systemd components... + <antrik> (this is in fact Lennart's favourit cop-out argument whenever + someone raises concern about this) + <antrik> the problem however is that such alternative implementations + usually have prohibitive costs + <braunr> yes i know + <antrik> (and Lennart knows that perfectly well... he doesn't exactly take + pains to conceal the fact that it's a cop-out) + <antrik> their whole point is to create a tightly integrated stack of + monopolistic components, giving a shit about any possible alternatives + <antrik> this does have an obvious appeal: it *significantly* reduces the + cost of innovation within their stack + <antrik> at the same time however it kills the traditional innovation + driver in the free software eco-system, which is competition among + interchangable components + <antrik> quite frankly, it makes little sense that other distributions are + embracing systemd in droves: the tight coupling pretty much turns them + all into Fedora look-alikes, questioning the point of their very + existence... + <zacts> what is dmd? + <antrik> as for Debian considering fringe kernels in their decision, I + think it makes *perfect* sense: the real value of Debian is precisely the + fact that it supports so many different things, making it a good base to + build upon + <antrik> (it's just unfortunate that many Debian developers do not realise + this, and instead try to compete with user-oriented distributions...) + <antrik> zacts: daemon managing daemon? yet another new init system... + <zacts> yeah + <zacts> didn't know if you have an opinion on it vs systemd + <zacts> and whether or not hurd will use it.. + <antrik> hm... not sure whether I do ;-) + <braunr> antrik: one could argue an init system is hard to make + interchangeable without also making it quite poor in functionality + <antrik> the GNU system uses it, right? when using the GNU system with the + Hurd (as it's really meant to be), that would obviously mean using DMD + with Hurd. though I'm not sure whether anyone has actually tried that + combination ;-) + <braunr> just to make it clear, i'm totally not in favor of systemd + <braunr> i'm just trying to measure the value of an interchangeable init + system here + <braunr> value versus cost + <braunr> why is it bad to try to compete with user oriented distros ? + <antrik> braunr: I suspect most of the really good things about systemd + could be kept while making it somewhat more open at fairly little cost... + <antrik> braunr: because that's not Debian's strength -- and never will be + <antrik> trying to compete in this space too hard is bound to fail, at only + bears the risk of loosing the actual strengths + <braunr> antrik: sounds true + <antrik> hm... thinking about it, I'd say it actually makes more sense for + the init system to be distribution-specific than kernel-specific... + <braunr> that makes sense + <braunr> but systemd isn't just an init system + <antrik> it's really the distribution's job to create a well-integrated + system. and basically, that's what the systemd cabal is doing for + Fedora... + <antrik> it's just problematic that they have so much influence in + important upstream projects, that they are basically killing any chance + for others to integrate things in different ways + <braunr> antrik: agreed + <braunr> the tight coupling i refer to is about the init system and the + upstream projects you mention such as udev, acpid, console-kit, etc.. + <antrik> yeah... and GNOME + <braunr> is it really that coupled now ? + <antrik> don't really know; but judging from remarks people make, it must + be pretty bad + <braunr> this reminds me of the talk on gnome 3 last year at fosdem + <braunr> it would have been hilarious if gnome wasn't such an important + project + <antrik> (specifically, GNOME is now pretty much tied to logind AIUI, which + is not entirely inseparable from systemd -- but again, the cost is + prohibitive...) + <teythoon> i don't get what all the hate here is about ... + <antrik> in fact, certain people used that as an argument why Debian must + switch to systemd as init, as they are already pretty much forced to use + various of the other coupled components anyways, and trying to decouple + them is too costly for Debian... + <braunr> teythoon: hate ? here ? + <teythoon> i mean they don't do this for fun, they actually provide + something of value, right ? + <braunr> some value + <antrik> teythoon: they? + <braunr> but they remove the kind of value that made free software evolve + the way it did, as antrik said + <teythoon> the evil cabal around systemd ;) + <antrik> I didn't say "evil"... not explicitly at least ;-) + <teythoon> then again, if you are runnign linux/gnome3 and plug in a second + monitor, that one is automatically activated + <braunr> yes, that's what they want to achieve + <teythoon> that's what they achieved + <braunr> i mean, they targetted that, it's not a side effect + <teythoon> and anyone not happy with how they did that can surely provide a + nicer solution ;) + <antrik> teythoon: as I said, there are clearly good aspects to what they + are doing -- but at the same time it's very dangerous to the free + software eco-system... + <braunr> teythoon: not easily + <teythoon> antrik: i don't buy that + <braunr> i do + <teythoon> braunr: yes, not easily. that is kind of the point, right ? + <braunr> pulling projects such as gnome into a category of kernel specific + applications is dangerous + <braunr> teythoon: well, considering who they are and the means they have, + they could have spent the time to do it right for everyone + <teythoon> maybe + <antrik> err... activating a second monitor is not in any way tied to + systemd or related compontents... I think you are talking about a second + seat + <teythoon> that's another killer feature they achieved, yes + <antrik> (which is nice, but quite frankly, a niche use case in my book...) + <teythoon> maybe you're not the typical user + <antrik> I'm not. but the *typical* user definitely doesn't care about + multi-seat + <teythoon> if you say so + <teythoon> antrik: when you say it's dangerous what 'they' are doing, what + do you mean exactly ? + <teythoon> dangerous for whom ? + <antrik> asides from schools in developing countries, who try everything to + save on IT costs, I really can't think of many users for multi-seat... + <teythoon> (maybe schools all around the world trying to cut down their + costs?) + <teythoon> or like everyone, here, a $30 dongle that gives you an extra + workstation, how awesome is that ? + <antrik> teythoon: see above: they are killing the ability to combine + interchangable components, which has always been a core asset of the free + software ecosystem + <teythoon> antrik: so gnome is going for systemd, and gnome loses the + ability to be used w/o systemd + <teythoon> why do you care ? how does this affect the whole ecosystem ? + <teythoon> i really don't get why everyone is getting so upset about this + <antrik> teythoon: who cares about a dongle giving an extra workstation? + the remaining users of workstations are either corporate -- who prefer + dedicated boxes for organisational reasons -- or gamers, who want all the + power to themselves... + <braunr> teythoon: well gnome is kind of one of the major destkop software + in the free software world + <antrik> s/one of// + <teythoon> antrik: you stated that you havent used gnome3, yet you have an + opinion how tightly it should be coupled with systemd or linux + <teythoon> people who haven't used systemd or upstart have an opinion about + which one should be preferred + <braunr> teythoon: why do you think people shouldn't think about systems as + a whole ? + <antrik> teythoon: actually, I am using it (for some value of "use") -- + though in legacy mode, as my hardware can't run the new bling... + <braunr> in that case, people shouldn't be allowed to vote, because that + would require them to be politicians .. + <teythoon> it's okay to think about that + <braunr> i don't think it is + <antrik> teythoon: but seriously, whether *I* have used it is quite beside + the point. I have no illusions about being a niche user + <braunr> people don't need to use something to actually understand it + <teythoon> but i cannot stand all the whining lately in the free software + world... + <braunr> whining isn't fair + <braunr> i mean, the word + <teythoon> y ? + <braunr> it's a big problem and complaining to force a debate is important + <teythoon> yes, but "they" are solving problems, and everyone is + complaining for one reason or the other + <braunr> they are also creating problems + <braunr> and not everyone is complaining + <teythoon> as opposed to offering alternatives + <braunr> that's a major issue, a lot of people are favorable to these + changes + <teythoon> and if you don't like what "they" are building, you are free not + to use it, no ? that's a freedom too ;) + <braunr> no + <braunr> you aren't + <teythoon> what ? + <braunr> that's precisely the point + <braunr> you'll be de facto forced to use it if you want to keep using the + rest + <teythoon> i'm free not to use gnome3 + <braunr> you won't be free from using linux if you want gnome3 + <teythoon> what kind of argument is that ? + <braunr> i'm abusing the word freedom + <braunr> because it has no clear meaning in practice + <braunr> as antrik said, it's about interchangeability and portability + <braunr> and alternatives + <braunr> accepting the way systemd is designed is a major shift towards + making linux its own standard, away from the rest + <braunr> and the way it's done isn't thought to easily allow the + alternatives to keep up with the changes + <teythoon> we agreed the other day that they shouldn't create ad-hoc + interfaces like they do, yes + <braunr> well that's the whole point + <teythoon> you just talked "about the way systemd is designed" + <braunr> they could invest some more effort to make well designed + interfaces that allow changing both the dependencies and the services + provided + <teythoon> how is that related to bad interface design ? + <braunr> for me, it's almost a synonym + <braunr> and we discussed it + <teythoon> aren't tightness of coupling and quality of interfaces + completely orthogonal ? + <braunr> it is designed with a narrow set of apparently company directed + interested towards a single system, a single distribution even, and + nothing else + <braunr> no + <braunr> absolutely not, when it's about something that should be + interchangeable + <braunr> an interface that forces tight coupling is of low quality to me + <antrik> braunr: they claim it's not actually company-directed... and I + tend to believe them on *that* point TBH + <braunr> antrik: this would have been a valid reason at least + <antrik> teythoon: it's just not right that some people can no longer use + major pieces of free software just because a tiny but highly vocal cabal + decides to disrupt the whole ecosystem + <teythoon> what are you talking about ? you are free to use older versions + of the software + <braunr> i's not technically feasible + <braunr> or it would require forking to maintain + <braunr> again, it's the start of a rift + <teythoon> but, if the gnome people want to go into that direction, who are + you to say that they shouldn't ?? that's what i get the least about this + kind of argument... + <braunr> i'm part of the free software community + <braunr> more accurately, the free unix-like community + <teythoon> and you are actively developing gnome... ? + <braunr> if they want to get out of this community, they'll hurt it, and + themselves + <braunr> do you understand what a rift is ? + <teythoon> but that's their choice, no ? + <braunr> a major division ? + <braunr> so what ? + <braunr> it doesn't mean it's a good one + <teythoon> you pick the desktop environment you like next best and be done + with it ? + <braunr> it's almost public service at this point + <braunr> what if they all do the same thing ? + <teythoon> err + <teythoon> they don't + <braunr> you won't be free to do what you want because the technical + possibility will have disappeared + <braunr> kde might + <braunr> if only to compete with gnome + <teythoon> well, if you don't like hte direction a project is taking, you + fork it + <teythoon> that's what happened + <braunr> exactly .. + <teythoon> why the long faces ? + <braunr> forks increase complexity and reduce manpower + <braunr> fork == division + <braunr> forking in the free software community is normally a last resort + <teythoon> huh ? since when is this considered a bad thing ? + <braunr> it's not a bad thing per se + <braunr> it usually implies a bad situation + <teythoon> < braunr> fork == division + <teythoon> and division == rift + <braunr> think of these situations that were caused by stupid drama and + lead to the duplication of a lot of effort + <braunr> openbsd, eglibc, jenkins, to name a few + <teythoon> i don't + <teythoon> why would i ? i never created these forks + <braunr> it affects the community as a whole + <teythoon> but the people who did thought it was necessary + <braunr> the fact they could do it is good, the fact they had to do it + isn't + <braunr> they were usually forced by the situation + <braunr> and often by the stupidity of other people + <teythoon> someone forced someone else to fork a project ? with a gun or + something like this ? + <teythoon> i don't buy this ;) + <braunr> of course not .. + <braunr> eglibc was forced by the inability of drepper to accept a whole + class of patches + <braunr> openbsd because theo de raadt has some huge ego + <braunr> for jenkins, it was a licensing issue iirc + <braunr> nothing technical at all + <braunr> nothing in the interest of the community + <teythoon> err + <teythoon> it brings diversity + <braunr> no + <braunr> netbsd versus freebsd brings diversity + <teythoon> i thought that was a good thing + <braunr> openbsd was just agotistic crap + <braunr> ego* + <teythoon> if there is no diversity, why should stuff be interchangeable if + there are no alternatives? + <braunr> and netbsd and freebsd aren't exactly forks, they're both bsd + based but had different goals from the start + <braunr> that's not what i'm talking about + <braunr> eglibc isn't exactly a new libc + <braunr> it's glibc+the stuff that should have gone into it + <antrik> teythoon: the stuff the systemd cabal does builds on the work of + thousands of projects and people; yet they act as if the don't own anyone + anything, and it's fine to boot out large parts of the community whos + work they are building on + <braunr> iceweasel isn't a whole new firefox + <braunr> most often, alternatives aren't forks of one another + <braunr> if they are, they have diverged a lot + <teythoon> antrik: that is your interpretation, and i respectfully disagree + with it;) + <braunr> and usually have different goals + <braunr> that's diversity, and i'm very ok with it + <braunr> (being a hurd guy and all) + <braunr> but forking because of decisions that prevent alternatives is a + very bad reason to fork + <teythoon> again, who are you to tell a project (say gnome) what they + should do or not ? + <braunr> that question makes no sense + <braunr> we're trying to think objectively + <braunr> forget who we are + <braunr> think about what should be done + <teythoon> no such thing ;) + <braunr> ok well, in that case, i'm a very smart person who knows a lot of + things, and people had better do what i tell them ;p + <braunr> satisfied ? :) + <teythoon> yes + <teythoon> that's much better actually + <braunr> not really .. + <teythoon> it's more honest + <braunr> no it was sarcasm + <braunr> what was honest are the arguments i explained + <braunr> why care about who says them ? + <teythoon> i do + <antrik> teythoon: there is not much interpretation in there really. some + of their own statements are quite explicit... + <braunr> damn non scalable kernel .. + <teythoon> who is "their"? what statements ? + <braunr> teythoon: when building glibc, there are so many nodes to fake + that ext2fs+fakeroot allocate enough ports to starve kernel memory ... + <teythoon> if i were mr. gnome3 and you would tell me that i should cuddle + with systemd b/c that's bad for one reason or another, the first thing + i'd like to know is who is telling me that + <braunr> teythoon: why not solely consider the argument ? + <teythoon> braunr: yes, i can imagine fakeroot doing that + <antrik> teythoon: Lennart and his friends. not sure how much of these + statements I have seen written down -- part of it I heard myself from + their own mouths + <teythoon> braunr: b/c maybe i like to develop my project in the direction + i want + <braunr> that's unrelated + <teythoon> and if anyone disagrees, she may fork + <braunr> this is a debate + <teythoon> why ? + <teythoon> so now we are debating what i may develop or not ? you lost me + ;) + <braunr> a way to reach consensus + <braunr> many people are discussing so that projects like debian and gnome3 + make the best decisions + <braunr> a naive way to explain it is that the result is the sum of what + everyone likes and how louds he speaks for it + <teythoon> sure but you are not a gnome developer, no ? + <braunr> no, but again, i'm a free software community member + <braunr> and this affects the whole community + <braunr> because gnome3 is a major software component used by a lot of + people + <braunr> well, gnome at least + <teythoon> so the gnome project needs to seek consensus with everyone of + the free software community ? + <braunr> no + <braunr> that would be unanimity + <teythoon> but wrt to the systemd integration ? + <braunr> siding with systemd is starting to get away from the free software + community + <braunr> or, by bringing a lot of people along, dividing it + <teythoon> that's your interpretation + <braunr> yes + <braunr> always + <braunr> you don't have to say it, we're not doing raw science here + <braunr> it's implicit + <teythoon> i think it's important to point that out and make it explicit + <braunr> you made it several times + <braunr> we got the point + <braunr> what matters in the current discussion is whether you agree or not + and why + <braunr> and this will be your interpretation too + <braunr> and we'll see if it's convincing + <braunr> but, from experience, i expect noone will be convinced ;p + <teythoon> ^^ + <braunr> the issue is too tied with the core goals we have in mind + <teythoon> but why does it matter whether i agree or not + <teythoon> that's my point actually + <braunr> you seem to have a problem understanding the issue, i was trying + to convince you there is one + <braunr> so, if i want to achieve that, it matters + <teythoon> what core goals ? + <braunr> basic dialectic + <braunr> well, for example, for me, i want people to think of the system as + a whole + <braunr> i want something effective, technically very good, and that + respects user freedoms + <braunr> i also want alternatives, i won't explain why, let's say it's + obvious + <teythoon> i agree + <braunr> well, systemd people don't think of the system as a whole + <braunr> here, what i call "system" is very large + <braunr> it would almost equal society + <braunr> i understand why they do that + <braunr> they have the right to do that + <braunr> but then i could say i understand why people make proprietary + software, and they also have the right to do it, i still won't approve it + <braunr> it contradicts my personal goals, my personal view of how things + should be + <teythoon> i completely agree + <teythoon> but then again, what you said now and the way you said it was + very different + <braunr> maybe, it's 3am, i'm sick and exhausted :) + <teythoon> more abstract + <braunr> when i give an opinion + <braunr> actually, when anyone gives an opinion + <braunr> i consider it implicit that it's their point of view alone + <braunr> they're not enforcing anything + <braunr> merely speaking out + <teythoon> people tend to overestimate the importance of their own opinion + <braunr> hm i wouldn't say so + <braunr> and that's probably why the "who" doesn't matter a lot to me + <braunr> it would matter if the person in question had real power + <braunr> and his opinion could have a strong influence + <braunr> in which case it wouldn't be overestimated + <braunr> i could say what i think to systemd people + <antrik> teythoon: quite frankly, I'm not sure what you are complaining + about. the systemd followers are trying to impose their opinions on + various projects. other people (including braunr and me, among many + others) are voicing counter-opinions. what's wrong with that? + <braunr> but i'm pertty certain the weight they'll associate to what i tell + them will be very low :) + <braunr> antrik: he called it "annoying whining" + <braunr> i think it's the only problem + <antrik> braunr: I don't think the systemd people associate much weight to + *anything* others say... ;-) + <braunr> heh :) + <braunr> to make an historic analogy + <braunr> it seems to me they're repeating the same mistakes others did + during the unix wars + <teythoon> antrik: but when you say "the systemd followers are trying to + impose their opinion on various projects", don't you dismiss the + possibility that the gnome3 people just want to make external displays + hot-pluggable? + <braunr> of course they do + <braunr> don't you dismiss that proprietary software author just want to + make money ? + <teythoon> no + <braunr> well, if that's the only thing you keep in mind to make your + opinion, you'll miss important points + <teythoon> that is an example of course + <braunr> they're sacrificing interchangeability and starting a possibly + major rift in the community for hot pluggable displays + <braunr> it may not be worth it + <teythoon> not supporting stuff like that might make the whole ecosystem + obsolete + <braunr> i'm not saying it shouldn't be done + <braunr> i'm saying it should be done while sacrificing other important + things + <braunr> it would just take a little mort effort + <braunr> and even if it wasn't done + <teythoon> that's what i meant by "whining" + <teythoon> no offense + <braunr> what is the problem of it being "obsolete" ? + <teythoon> but talk is cheap, offering alternative solutions is hard + <braunr> isn't unix obsolete ? isn't xorg obsolete ? + <braunr> hum no + <teythoon> no one did, so they implemented their nice features + <braunr> the point isn't to offer alternative solutions + <braunr> it's to make them possible + <braunr> or at least, not deny their technical feasibility because they + don't care + <braunr> teythoon: see, "interchangeability and starting a possibly major + rift" don't look to conflict with your personal goals + <braunr> that's the point where i think i can no longer do anything to + convince you + <braunr> so i'll head to bed :) + <teythoon> heh, me too :) + <braunr> honestly, i don't care a lot + <braunr> i mean + <braunr> it won't change much for me + <braunr> but again, my brain is wired to think of things as a whole + <braunr> on that note, good night :) + <teythoon> good night :) + <antrik> teythoon: again, IT'S NOT ABOUT DISPLAYS + <antrik> believe me, I do have some understanding how display hotplugging + works + <antrik> also, the problem is not that gnome3 supports logind. the problem + is that gnome3 works *only* with logind now AIUI + <antrik> there is yet another way to state the fundamental problem + <antrik> there is a kind of social contract among free software projects: + every maintainer takes a reasonable amount of extra effort to support use + cases beyond his own. in return, his use cases are supported by other + maintainers + <antrik> the systemd guys are breaking this contract, by explicitly + refusing, up front, to take *any* effort to accomodate other projects' + needs + + +## IRC, freenode, #hurd, 2014-01-28 + + <azeem_> teythoon: + https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/EgKwQV8te7s + <teythoon> azeem_: pffff :) + <braunr> heh + <teythoon> which reminds me + <teythoon> if we want to state our position wrt the default init system + debate we should probably do it right now + <braunr> yes + <teythoon> ml or collaborative editor ? + <azeem_> well, tech-ctte chair called the vote only for the default init + system for the Linux-ports + <azeem_> the vote got shot down on technicalities, but that might stand + <azeem_> I think that is a good thing, cause it implies that not one init + system has to be adopted across all ports + <teythoon> we talked the other day that it might make sense just to state + our view and our needs + <azeem_> sure. + <azeem_> I think what's needed is (i) an init-system agnostic system to set + the enable/disable state of services (ii) possibly mandating a .ini-style + config file along the style of whatever init system gets chosen as + default for Linux, to be used by non-Linux init systems as inut + <azeem_> input* + <azeem_> just my 0.02 EUR + <teythoon> uh + <braunr> looks overkill + <teythoon> i was thinking more along the lines of 1) we have never used the + default debian init system and are cool with not using the default in the + future, 2) we intend to use sysvinit in the future, 3) to that end, we + ask the init script machinery to be left in place + <braunr> but then, people managed to write stuff like libvirt + <braunr> so who knows + <teythoon> 4) we will help maintaining it as part of our porter effort + <braunr> i agree with teythoon + <teythoon> 5) we look forward to using openrc as incremental improvement, + complementing our sysvinit boot solution + <braunr> yes that would be nice + <teythoon> i'll write a draft to debian-hurd, ok ? + <gnu_srs> openrc now has a dependency loop resolver, so parallel would + work:) + <teythoon> so is insserv, isn't it ? + <gnu_srs> there were complaints on openrc + https://bugs.gentoo.org/show_bug.cgi?id=391945 in the tech-ctte + discussions, now fixed + <azeem_> gnu_srs: please accept the fact that openrc will not be picked by + the tech-ctte for the Linux ports + <gnu_srs> azeem_: I do, I'm referring to arguments during the discussion + (history) + <azeem_> sure, just checking + <ArneBab> teythoon: your post is being used to portray systemd cgroups + treatment as the right way… + <teythoon> ArneBab: so ? + <braunr> it probably is the right way + <braunr> that's not the problem + <ArneBab> do you want to clear that up? (do I remember correctly that you + did not like that way?) + <braunr> we don't like the cgroups interface + <teythoon> i will + <braunr> not the feature + <ArneBab> braunr: that’s what I meant + <teythoon> exactly + <braunr> the feature amounts to resource containers in the hurd critique + ... + <braunr> we do want that too :) + <braunr> anatoly: you want them to rewrite cgroups ? + <braunr> err + <braunr> ArneBab: ^ + +[[dbus_in_linux_kernel]]. + + <teythoon> i've been thinking + <teythoon> maybe the magic write stuff isn't that bad after all + <braunr> :) + <braunr> i was thinking the same thing actually + <teythoon> i mean, it's not the nicest thing, but it shows how flexible our + solution is + <braunr> the hurd is a lot about glue code already so why not + <teythoon> the problem is that there is no way to test cgroupfs + <teythoon> the main user is systemd, and it requires tons of other stuff + <braunr> right + <teythoon> any other user of cgroups is also probably using other + linux-interfaces too + + +## IRC, freenode, #hurd, 2014-01-29 + + <gnu_srs> About openrc having a dependency loop resolver: <teythoon>: so is + insserv, isn't it ? + <gnu_srs> I found is_loop_detected() in insserv/listing.c but that one just + exits without telling where the loop is + + +## IRC, OFTC, #debian-hurd, 2014-01-29 + + * youpi trying the new sysvinit + <youpi> hopefully we'll then be able to at last use the proper ifup/ifdown + debian way for networking :) + <youpi> teythoon: why leaving hurd's runsystem by default rather than + sysvinit's? + <youpi> ah, another issue, too, now that /dev/vcs appears in /proc/mounts, + umountfs would umount it + <youpi> ideally umountfs would not umount passive translators + <youpi> we could blacklist /dev/vcs in umountfs, but the same issue would + happen for user-defined translators in their own home, for instance + + +## IRC, freenode, #hurd, 2014-01-30 + + <gnu_srs> booting with the new sysvinit and openrc versions: works:), but + only in recovery mode:-( Hangs before INIT: version 2.88 booting + <gnu_srs> after start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] + exec init proc authtask c1120dc8 deallocating an invalid port 134517370, + most probably a bug. + <gnu_srs> related or an openrc problem? will test with sysv-rc + <youpi> I don't have such issue with sysv-rc + <gnu_srs> k! + <gnu_srs> shouldn't recovery mode mean starting in runlevel 1, I get + runlevel 2? + <youpi> it should + <pere> gnu_srs: recovery mode normally mean single user, which is between + rcS and rc2 + <gnu_srs> I get INIT: Entering runlevel: 2 + <pere> rcS.d should really have been named rcboot.d, as that is really what + it is. + <youpi> ah, right, recovery is not single + <youpi> (single as in init 1) + <pere> runlevel 1 is not single user either. it is more a gateway into + single user. see /etc/init.d/single to see what happen at the end of + runlevel 1. + <gnu_srs> init 1 and init 2 seems to work + <gnu_srs> well, the openrc dependency loop detector has found an init + script loop, maybe it has to be fixed? + <gnu_srs> disabling the hurd console solved the dependency loop problems, + thanks openrc;-) + <gnu_srs> (have to dig deeper to see where the loop is, and how to solve + it) + + +## IRC, freenode, #hurd, 2014-01-31 + + <gnu_srs> Hi, does the hurd console work with sysv-rc: In operc I get with + #console -d vga -d pc_mouse --repeat=mouse -d pc_kbd --repeat=kbd -d + generic_speaker -c /dev/vcs + <gnu_srs> console: Console library initialization failed: Not a directory + <teythoon> gnu_srs: yes, it works with sysvrc + <teythoon> gnu_srs: check that /dev/vcs has the appropriate translator + record + <gnu_srs> showtrans /dev/vcs: empty on another box: /hurd/console + <teythoon> yes, fix that and your console will be fine + <gnu_srs> settrans /dev/vcs /hurd/console? + <gnu_srs> or should it be active? + <teythoon> no, set an passive translator record so that this will be + persistent + <gnu_srs> something is wrong: when starting the hurd console screen is + blanked (and hangs) + <gnu_srs> can I get the hurd console when running with the serial console + (to see boot messages)? + <teythoon> gnu_srs: yes, yuo can + <gnu_srs> will try that image then, tks:) + <gnu_srs> teythoon: how to create all underlying directories? ls /dev/vcs: + 1 2 3 4 5 6 + <teythoon> don't, /hurd/console takes care of that + <gnu_srs> is settrans /dev/vcs /hurd/console correct? + <teythoon> yes + <sjbalaji> What are those underlying directories representing ? + <teythoon> the hurd console is a console multiplexer + <teythoon> bringing multiple virtual consoles to the hurd + <teythoon> # showtrans /dev/tty1 + <teythoon> /hurd/term /dev/tty1 hurdio /dev/vcs/1/console + <gnu_srs> aha: console -d vga -d pc_mouse --repeat=mouse -d pc_kbd + --repeat=kbd -d generic_speaker -c /dev/vcs + <gnu_srs> task c1120e70 deallocating an invalid port 1782, most probably a + bug. + <sjbalaji> teythoon: Is it that /dev/tty1 has multiple translators ? + <teythoon> no + <teythoon> exactly one translator is bound to any given node in the vfs + <gnu_srs> something is strange with the hurd console: booting with it + enabled still runs the mach console, halting: + http://paste.debian.net/79438/ + <teythoon> what is strange about taht ? + <gnu_srs> when starting the hurd console: task c1120e70 deallocating an + invalid port 1782, most probably a bug. + <teythoon> so ? + <gnu_srs> and the paste when halting: twice + <teythoon> that is a known issue + <gnu_srs> with the hurd console? + <teythoon> how do you know it's the hurd console ? + <teythoon> that message comes from the kernel + <teythoon> currently, it is not possible to tell which process is + responsible + <teythoon> b/c the task is given as a pointer to the kernel task structure + <teythoon> not as a pid + <gnu_srs> I don't ,it is triggered by it at least + <teythoon> currently there is no way to map the former to the latter + <teythoon> why do you think it's a problem ? is something not working as + expected ? + <gnu_srs> maybe a reproducible way to hunt that bug! + <teythoon> we have one already + <teythoon> it happens every time the hurd boots + <gnu_srs> yes, hurd console does not start, even when enabled:-( + <teythoon> then please say so ;) + <gnu_srs> I did: (11:23:30) srs: something is strange with the hurd + console: booting with it enabled still runs the mach console, halting: + http://paste.debian.net/79438/ + <teythoon> where do you say that the hurd console did not start ? + <gnu_srs> maybe it is easier to hunt the bug in an already booted system + <teythoon> you just said that the mach console is still active, wich it is + even if the hurd console starts + <teythoon> yes + <teythoon> please start the hurd console by hand + <teythoon> -d current_vcs -c /dev/vcs -d vga -d pc_kbd --keymap us + --repeat=kbd -d pc_mouse --protocol=ps/2 --repeat=mouse + <teythoon> err + <teythoon> /bin/console -d current_vcs -c /dev/vcs -d vga -d pc_kbd + --keymap us --repeat=kbd -d pc_mouse --protocol=ps/2 --repeat=mouse + <gnu_srs> when I log in I have the mach console not the hurd console + <teythoon> yes, log in as root, then run that command + <gnu_srs> I've done that: (11:10:27) srs: aha: console -d vga -d pc_mouse + --repeat=mouse -d pc_kbd --repeat=kbd -d generic_speaker -c /dev/vcs + <gnu_srs> please read? + <teythoon> and you discovered in that process that /dev/vcs lacked a + translator record + <teythoon> did you run it again after fixing that ? + <gnu_srs> the reply was: (11:10:27) srs: task c1120e70 deallocating an + invalid port 1782, most probably a bug. + <teythoon> well, if you are feeling that what i ask you to do is + unreasonable, i'm not sure how i can help you + <gnu_srs> yes, the translator was running! + <teythoon> you could hunt down the port deallocation bug, that'd be awesome + and most welcomed + <teythoon> but i don't believe it is causing your console malfunction + <gnu_srs> I did what you asked for?? + <gnu_srs> I'll do it again! + <gnu_srs> ok, now I don't get that error, but still no hurd console? the + process is running, logging out and then in, no hurd console. + <gnu_srs> not possible in serial console? + <teythoon> no, the hurd console is displayed using the graphic card + <teythoon> you asked for that with -d vga ;) + <teythoon> not sure if there are any other display drivers + <teythoon> when you asked whether you can use the serial line, i assumed + you used both qemus graphic terminal and a serial console + <teythoon> try kvm ... -serial telnet::1236,server,nowait, then use telnet + localhost 1236 to connect to the serial console + <teythoon> then, you can start the hurd console over the serial console and + see whether that worked + <gnu_srs> OK; that's what I asked before. I tried with the graphic one, + I'll try again + <gnu_srs> telnet output is empty + <gnu_srs> frozen + <teythoon> did you start a getty there ? + <gnu_srs> in hurd? + <teythoon> b/c if you dropped the console=com0 argument from you gnumach + command line, the mach console will be put on the vga screen, not on the + serial console + <gnu_srs> I dropped console=com0 from grub.cfg, yes + <teythoon> ok + <teythoon> so simply no one is talking to the serial port anymore + <teythoon> did you try to start the hurd console ? + <gnu_srs> I did before, can do it again + <gnu_srs> startin the HC blanks the screen, and freezes the vga output:-( + ssh still working + <teythoon> hm + <teythoon> try ps Ax | grep tty, are there any term servers running for + /dev/tty1..6 ? + <gnu_srs> lplenty of them: http://paste.debian.net/79442/ + <teythoon> good, even gettys are there + <gnu_srs> and the console translator runs + <teythoon> hm + <gnu_srs> root 1224 5 7 months /hurd/console + <gnu_srs> root 1227 1226 7 months /bin/console -d vga -d pc_mouse + pc_mouse -d pc_kb... + <teythoon> yes, everything looks good + <teythoon> just to be sure, you are currently using the qemus graphical + frontend, right ? + <gnu_srs> yes + <teythoon> hm :/ + <teythoon> gnu_srs: do you see loginpr processes ? + <gnu_srs> nope + <teythoon> hum + <teythoon> this strikes me as odd + <teythoon> on my system, i see no gettys but only loginpr processes + <teythoon> this is b/c the hurd getty does little other than to print some + text and run the login program + <teythoon> but on your system the getty sticks around + <teythoon> is /sbin/getty really the hurd getty? it's easily recognized by + its crappieness: + <teythoon> /sbin/getty --help || echo $? + <teythoon> 1 + <gnu_srs> 1 + <teythoon> hm + <teythoon> still funny though + <teythoon> you could try to run the hurd console, then run a getty manually + <teythoon> e.g. /sbin/getty 38400 tty1 + <gnu_srs> from the ssh login? + <teythoon> yes + <gnu_srs> then the graphic display is back showing the loin prompt:P + <teythoon> weird + <teythoon> well, so most things work + <teythoon> that's a good thing + <teythoon> funny that hurds getty should get stuck like this + <gnu_srs> and the terminal is hurd:-) + <teythoon> any chance you can produce a stack trace of one of your getty + processes ? + <gnu_srs> how? + <teythoon> gdb --pid=the_pid /sbin/getty + <teythoon> then, do bt like usual + <gnu_srs> so you mean tty2-6 are broken? + <teythoon> no + <teythoon> it's just for some reason your gettys do not behave nicely when + run from init + <gnu_srs> from running tty2: bt #0 0x01087b09 in ?? () + <gnu_srs> #1 0x00000000 in ?? () + <gnu_srs> not much + <teythoon> hm :/ + <teythoon> indeed + <teythoon> our getty logs to syslog, can you see anythign of interest here + ? + <gnu_srs> Jan 31 12:00:46 debian-openrc-20140123 rsyslogd-2066: could not + load module '/usr/lib/rsyslog/imklog.so', dlopen: + /usr/lib/rsyslog/imklog.so: undefined symbol: klogAfterRun + <gnu_srs> [try http://www.rsyslog.com/e/2066 ] + <gnu_srs> nothing tty releated + <teythoon> gnu_srs: oh, i just noticed, please look into auth.log, the + getty stuff ends up there + <gnu_srs> teythoon: http://paste.debian.net/79465/ + <teythoon> well, that is interesting :) + <gnu_srs> /dev/tty1 not a directory? + <teythoon> for instance, yes + <teythoon> it says bad syntax if it was invoked in the wrong way, i.e. not + with exactly two arguments + <teythoon> that might have been you yourself, right ? + <teythoon> with getty --help i mean + <teythoon> for the not a directory message, please verify that + <teythoon> # showtrans /dev//tty1 + <teythoon> /hurd/term /dev/tty1 hurdio /dev/vcs/1/console + <teythoon> and stat /dev/vcs/1/console says it's a character special file + <gnu_srs> I used exactly: /sbin/getty --help || echo $? + <teythoon> yes, that accounts for that bad syntax message + <gnu_srs> what so bad about that? + <gnu_srs> showtrans /dev//tty1 + <gnu_srs> /hurd/term /dev/tty1 hurdio /dev/vcs/1/console + <teythoon> getty is so simple minded that it doesn't really parse its + arguments + <gnu_srs> stat: http://paste.debian.net/79469/ + <teythoon> looks nice + <teythoon> everything looks nice, i'm at my wits end here + <gnu_srs> and everything works OK with sysv-rc? + <teythoon> yes + <teythoon> by the way, are you using the sysvinit init scripts or something + openrc related ? + <gnu_srs> openrc use all the scripts in /etc/init.d + <teythoon> actually, could you try to kill -HUP 1 ? + <gnu_srs> BTW: the dependency loop detector has found many loops in those + scripts + <gnu_srs> kill -HUP 1: nothing happens + <teythoon> ok, try to kill one of those gettys and see if the one that + respawns works + <teythoon> then again, the getty should try to reopen the device every + minute until it succeeds + <gnu_srs> getty tty1 and tty2 disappeared? kill -HUP tty3 respawns + immediately + <gnu_srs> now no getty processes are left? + <gnu_srs> /dev//tty4: Not a directory etc? + <teythoon> sorry, i should have expressed myself more clearly + <teythoon> kill -HUP 1 sends a SIGHUP to sysvinit, this makes it reload + it's configuration + <teythoon> when i said kill some getty, i meant just kill some_pid + <teythoon> when you said 'kill -HUP tty3 respawns immediately', did you + mean you killed the getty that was listening on /dev/tty3, and then a new + one appeared and you got a login prompt at tty3 ? + <gnu_srs> a new pid appeared, the login prompt is on tty1 + <gnu_srs> this one? /hurd/term /dev/tty1 hurdio /dev/vcs/1/console + <teythoon> i'd like to invite you to look at daemons/getty.c + <gnu_srs> not a big piece of code: anything specific? + <teythoon> no, just look what it roughly does + <gnu_srs> not a directory is not coming from that code + <teythoon> correct + <gnu_srs> it execl-s login + <teythoon> yes + <teythoon> inevitably + <teythoon> but you do not observe this + <gnu_srs> how come when they are running? + <teythoon> this is the question that you will have to answer in order to + make any progress + <gnu_srs> I killed only one of them: kill -HUP 1031 and they all + disappeared + <teythoon> i thought along these lines: the most obvious way to stall getty + is if it never exits that loop + <teythoon> so i guessed it might be failing to open the device + <teythoon> we already observed that getty works fine if invoked by you + manually + <teythoon> the question thus is, what is different when getty is invoked by + init ? + <teythoon> if a process started by init in this way is killed, init will + restart it + <teythoon> please note, that if anyone says kill that process, she means + send a signal that results in process termination + <teythoon> and while sighup causes processes to die if the signal is not + handled, it is not the ideal signal to kill processes + <teythoon> b/c some processes handle sighup + <teythoon> like sysvinit, which reloads its configuration + <teythoon> many daemons do this + <teythoon> see 'man 7 signal' for how signals affect processes + <gnu_srs> sorry, have to leave for now, bbl and thanks a LOT so far:) + <teythoon> ok :) + <teythoon> you are welcome :) + <gnu_srs> teythoon: I'm back but cannot spend to much time on this + tonight. Maybe you should try it yourself, do you want another image on + my box? + <teythoon> it'd be nice if you put your packages somewhere + <gnu_srs> there are no special packages sysvinit (-46) and openrc (-8) + <teythoon> surely openrc with some patches ? + <gnu_srs> from #openrc: (17:37:41) srs: start with sysvinit and make it + work first! + <gnu_srs> (17:28:43) srs: zigo: Then I copied that working image to + another, and changing hostname, and continued from there. + <gnu_srs> openrc with the hurd patches for /lib/rc/sh/init.sh (v8 should be + available from experimental by now) + <teythoon> sweet :) + <teythoon> gnu_srs: maybe it was just some weird issue with your system + <teythoon> i just switched to openrc and everything seems to just work + <teythoon> i'll redo what i just did more cleanly to get a clean test vm... + <gnu_srs> nice:) + <gnu_srs> teythoon: And you got the hurd console? + <teythoon> heh, i believe so >,< + <teythoon> i didn't see it b/c i was using --nographic + <teythoon> but ps Ax looked alright + <teythoon> hrm + <teythoon> gnu_srs: i can reproduce your trouble, umount still strips the + translator record from /dev/vcs + <teythoon> at system shutdown time + <gnu_srs> so that's the reason. Additionally I have to issue halt twice + from a ssh login, see http://paste.debian.net/79517/ + <teythoon> funny indeed + <teythoon> gnu_srs: i can reliably recover the hurd console by doing + <teythoon> settrans /dev/vcs /hurd/console && service hurd-console restart + && pkill getty ; sleep 5 ; pkill getty + <teythoon> humm, as you say, halt doesn't work + + +## IRC, OFTC, #debian-hurd, 2014-02-01 + + <pere> I've just uploaded a new new sysvinit package to experimental, with + all the latest hurd fixes. + + +## IRC, freenode, #hurd, 2014-02-01 + + <gnu_srs> 17:53:28< teythoon> settrans /dev/vcs /hurd/console && service + hurd-console restart && pkill getty ; sleep 5 ; pkill getty + <gnu_srs> teythoon: Any ideas on how to solve this? + <teythoon> gnu_srs: yes, i have that on my todo list + <gnu_srs> so it is not an openrc problem? + <teythoon> gnu_srs: no + + +## IRC, freenode, #hurd, 2014-02-01 + + <teythoon> start ext2fs: Hurd server bootstrap: ext2fs[gunzip:device:rd0] + exec init proc au + <teythoon> thtask with pid 6 deallocating an invalid port 134517370, most + probably a bug. + <teythoon> :) + <teythoon> pid 6 is exec o_O + <gnu_srs> teythoon: Nice to see that you added pid numbers for error + print-outs:) + <gnu_srs> so the boot error comes from the exec sever? + <teythoon> so it seems + <gnu_srs> server* + <gnu_srs> have you found where? + <teythoon> no + + +## IRC, OFTC, #debian-hurd, 2014-02-02 + + <pere> but when I install the new packages, and run update-alternatives + --config runsystem to select sysv, the boot fail with: start ext2fs: Hurd + server bootstrap: ext2fs[device:hd0s1] exec init proc authtask c1128dc8 + deallocationg and invalid port 134517370, most probably a bug. + <pere> was that the wrong approach? + <pere> is there some way to recover when hurd fail to boot with sysvinit? + <pere> I was able to boot in recovery mode. :) + <pere> and this time sysvinit booted. saw a segfault message just after + sysvinit started, no idea what caused it. + <pere> looks like it is startpar that segfaults. + <pere> looks like the invalid port message come every time, no matter if + the boot hang or not. + <pere> I was wrong. it isn't startpar segfaulting, it is something in + rcS.d/. + <pere> bootlogd is the process segfaulting at boot. + <pere> looks like the boot success rate is 30% or so. + <pere> reported bootlogd problem as <URL: http://bugs.debian.org/737375 >. + I really miss valgrind. :) + <teythoon> pere: yes, the invalid port message is from the exec server + <teythoon> pere: i see the hurd boot process hang sometimes, no matter if i + use sysvinit or not + <teythoon> i believe it's a race condition in the ext2fs, not sure though + <pere> teythoon: but did the frequency of the hang go up with sysvinit or + not? to me it seem like that. + <teythoon> pere: yes, i believe it got worse + <teythoon> what hangs is fsysopts --update / + <teythoon> runsystem.sysv does that quite early + <pere> able to debug it? + <pere> I like the fact that runsystem.sysv set up ip at boot time, while + with .gnu, I have to run dhclient /dev/eth0 manually + <pere> it is quite confusing that hurd got two init processes with + sysvinit. one as pid 1, and another that seem to be the parent of all + internal stuff. perhaps the latter could be renamed to hurd-system or + something like that? + <pere> "sleep 0.2 # Work around a race condition (probably in the root + translator)." do not look too good... + <pere> (I increased from 0.1 to see if it help me. :) + <teythoon> did it ? + <teythoon> i plan to rename /hurd/init to /hurd/startup + +[[hurd_init]]. + + <pere> nope. :) + <pere> five boots in a row hung. :( + <pere> still no go... + <teythoon> are you using a vm or real hardware ? + <pere> vm + <pere> kvm, via virt-manager, to be exact. + <teythoon> me too + <pere> on the sixt boot, after waiting a long time between try 5 and 6 + (gave up a bit), it booted. + <pere> sleep 1 did not help either. + <teythoon> :( + <teythoon> well, it's not *that* bad for me + <teythoon> in fact recently it has been a lot better + <teythoon> you might try my packages + <teythoon> pere: here http://darnassus.sceen.net/~teythoon/hurd-ci/ + <pere> teythoon: tested it, and it seem to solve the problem. + <pere> is also rid of the strange error at the start. + <pere> teythoon: your packages even work without the sleep 0.1, at least + some of the time. :) + <pere> hm, but the success rate without sleep 0.1 is very low. I was able + to boot once, and never again. :( + <teythoon> pere: yes, i fixed the spurious port allocation today :) + <teythoon> pere: nice to hear that the sleep 0.1 i put in does increase + your chance to boot as well + + +## IRC, freenode, #hurd, 2014-02-02 + + <teythoon> gnu_srs: i found the spurious port deallocation :) + <gnu_srs> Cangrats:-D + <teythoon> trouble is, i introduced it >,< + <gnu_srs> Congrats* + <gnu_srs> Ah, you did? + <teythoon> gnu_srs: yes, in debian/patches/exec_filename_fix.patch + <teythoon> + http://darnassus.sceen.net/gitweb/teythoon/packaging/hurd.git/commitdiff/6da3e0be8fde0594bd84a13536d9d93048186790 + * teythoon . o O (diffs of diffs are trippy :) + + +### IRC, freenode, #hurd, 2014-02-03 + + <braunr> teythoon: oh nice, you found that bug :) + <teythoon> braunr: yes, once i knew where to look it was easy to fix ;) + + +### IRC, freenode, #hurd, 2014-02-05 + + <teythoon> i wonder why the port deallocation bug made the system hang when + the libc was compiled with the newer gcc + <braunr> teythoon: so it was indeed the problem ? + <teythoon> braunr: youpi said so, yes + <braunr> oh right + +[[glibc/debian/experimental]], *glibc 2.18 vs. GCC 4.8*? + + +## IRC, OFTC, #debian-hurd, 2014-02-03 + + <pere> + http://people.skolelinux.org/pere/blog/Testing_sysvinit_from_experimental_in_Debian_Hurd.html + <teythoon> :) + <teythoon> pere: sounds like your hurd-console isn't running and there is + no getty on the mach console + <teythoon> pere: you could add sth like 8:2345:respawn:/sbin/getty 38400 + console to your inittab + <pere> I'd rather wait until the hurd porters get it right in the debs. :) + <pere> I suspect upgrading the downloadable image to use the latest + packages also would help a lot. + <pere> with upgraded packages, /proc is working and pstree, pkill, top, etc + is working out of the box. :) + + +## IRC, OFTC, #debian-hurd, 2014-02-04 + + <pere> I just uploaded sysvinit with hurd support to unstable. :) + + +## IRC, freenode, #hurd, 2014-02-04 + + <gnu_srs> teythoon: Hi, the segfault during boot is coming from bootlogd, + see bug #737375 + <gnu_srs> also the output on the console is from there: end_request: I/O + error, dev 02:00, sector 0 + <teythoon> gnu_srs: interesting :) + <teythoon> gnu_srs: i believe the end_request message comes from gnumach + <youpi> yes, that's just a floppy disk access attempt + <gnu_srs> might be so yes + <youpi> it's not a "might", it's sure :) + <youpi> dev 02:00 is the flopy + <gnu_srs> k! + + +## [[glibc_IOCTLs]], `TIOCCONS` + + +## IRC, OFTC, #debian-hurd, 2014-02-04 + + <zigo> Each time I upgrade my hurd box, I cannot login into it ... + <zigo> No login prompt. + <zigo> WTF is going on? + <zigo> How to fix? + <teythoon> zigo: most likely your hurd console is not running and there is no getty started for the mach console + <zigo> teythoon: How to fix? (note: I already have the partition mounted in a loopback) + <zigo> Or maybe go in recovery mode? + <teythoon> depends + <teythoon> do you use sysvinit ? + <teythoon> do you use the hurd packages from hurd-ci ? + + +## IRC, OFTC, #debian-hurd, 2014-02-05 + + <zigo> teythoon: Sorry, didn't see your reply. I just used the Hurd image, + untar it, and apt-get update / dist-upgrade. That's it, nothing more or + less. + <zigo> teythoon: I obviously would like to install sysvinit, and later + OpenRC. That's the reason why I'm running Hurd: to make sure OpenRC works + with it without issues. + <zigo> teythoon: It seems it "sometimes work" or what??? + <zigo> I was able to repair it using the recovery mode, it seems. + <zigo> grrr... + <zigo> I got this issue again, again and again ... + <zigo> Sometimes, got the tty1, sometimes, it doesn't appear. + <zigo> That's REALLY frustrating. + <pere> zigo: and yes, the success rate for boot is not 100%. it increases + a bit by using the packages teythoon created at hurd-ci. + <pere> apparently some race condition somewhere. + <zigo> pere: So, I should just try and reboot again and again ? + <zigo> pere: Is it improving after switching to sysvinit? + <pere> once I had to boot six times before I got it running... + <pere> I was told that the race involves a call to fsysopts, and that the + success rate with sysvinit was smaller because fsysopts command was + called earlier. I can not confirm nor deny this. + <pere> with the latest packages from hurd-ci the success rate is almost + 100% again. + <zigo> pere: Where do get that? + <pere> zigo: see <URL: + http://people.skolelinux.org/pere/blog/Testing_sysvinit_from_experimental_in_Debian_Hurd.html + > + <zigo> pere: What's the "update-alternatives --config runsystem" for? + <pere> to switch to sysvinit + <zigo> Right, that's what I was missing then! :) + <pere> the new sysvinit version in unstable was built for hurd one and a + half hour ago. so soon hurd users can skip experimental for that. + <zigo> pere: I've just succeeded in booting with OpenRC! :) + <zigo> Though this console pb is REAAAALLLYYYY getting on my nerves! :) + <zigo> Also, any idea why we don't get the nice colorfull output when + booting? + <zigo> When booting with OpenRC, I've noticed that the dependency loop + detects some loops with the hurd-console thing. + <teythoon> zigo: good to hear that you got it working + <teythoon> the console problem is the following + <teythoon> when you shutdown using sysvinit, the system will run umount -a + <teythoon> it will then mistake some translators (like the one on /dev/vcs) + for file systems and remove their passive translator records + <teythoon> you can fix this by running '/usr/lib/hurd/setup-translators -k + -p' + <teythoon> you can avoid it for the time being by using reboot-hurd or + halt-hurd + <pere> teythoon: btw, how often is the hurd boot image available for + download updated? + <teythoon> not very often + <zigo> teythoon: Can I run '/usr/lib/hurd/setup-translators -k -p' + mounting my hurd image in a chroot? + <zigo> Hum... + <zigo> Probably better to do that in the recovery mode, no? :) + <youpi> dpkg-reconfigure hurd + <youpi> would be easier to type :) + <youpi> but we really need to fix that /dev/vcs unmounting + <pere> missing working getty and missing symlink from /run/mtab to + /proc/mount are the most serious problems I still see. + <zigo> The recovery mode doesn't work with OpenRC ! :( + <zigo> (it does in kFreeBSD and Linux, not with hurd ...) + <zigo> What happens is that it continues to runlevel 2. + <zigo> How can I fix then? + <youpi> pere: missing working getty? + <youpi> I don't see what issue you are referring to + <youpi> about the missing symlink, I'm wondering what is supposed to add it + <youpi> zigo: I don't know if anybody investigated it yet + <pere> youpi: yes, after boot there is no login prompt. + * pere have no idea, suspect a script in initscripts. + <zigo> youpi: I'm reffering to the fact that I have no login prompt after + boot, and that I don't know how to fix, since I don't have a recovery + mode to my disposal anymore. + <youpi> pere: but is the console started? + <youpi> (I mean the hurd console) + <zigo> pere: I suspect a wrong dependency, which OpenRC by the way, prints. + <youpi> pere: otherwise, unless you have a /dev/console getty in + /etc/inittab, it's expected you don't have a prompt + <youpi> zigo: add + <youpi> c:23:respawn:/sbin/getty 38400 console + <youpi> to your /etc/inittab + <teythoon> youpi: yes, we need to get that fixed + <youpi> grrrr + * youpi wanted to change the image file on people.d.o + <youpi> but I can't do that without downloading it on my laptop, to be able + to modify it + <youpi> I would have been, if people was a hurd system :) + <teythoon> the proper way to fix this is to implement the get_source stuff + and get rid of the heuristic in mtab.c + <pere> youpi: nope, no console process running. + <youpi> then that's why, /dev/vcs got unmounted + <pere> I already have a console getty in inittab. got it from the last + sysvinit package + * youpi should have brown-bag-fixed these bugs before this week-end + actually :) + <youpi> pere: but you don't get a getty prompt on the mach console? I don't + understand why + <youpi> it does work for me + <teythoon> brown-bag-fixed ? + <zigo> youpi: Adding that in /etc/inittab didn't fix anything. + <youpi> yes, ugly hacks uploaded to debian-ports + <youpi> zigo: even with rebooting? + <youpi> could you snapshot your screen so we can make sure what you are + actually getting? + <zigo> youpi: I did it mounting my partition in a loopback... + <zigo> Then booted up, and still couldn't see the console prompt. + <youpi> ok, but please take a snapshot, so we are sure what is actually + happening + <youpi> whether the console starts, etc. + <pere> that info passed out of the screen and is not shown after my boot, + at least. + <youpi> which info? + <youpi> again, please take a snapshot of the screen + <youpi> otherwise we are just guessing, and that's never good for debugging + <zigo> Maybe you'll find this interesting: http://paste.debian.net/80246/ + <zigo> This is the output of OpenRC booting and detecting dependency loops + in the LSB header scripts. + <pere> youpi: the info about the console being started or not. I'll show + you, give me a minute. + <youpi> zigo: well, that shouldn't be more problems than the dependency + loop already existing between rc.local and rmnologin + <pere> youpi: any loop is a fatal problem. + <youpi> how come the rc.local vs rmnologin is not a problem ? + <zigo> With sysv-rc in Debian, there's all sorts of loops that are just + silent. + <pere> I have not seen that loop on my linux system, so I am unsure what + you talk about. + <youpi> (the actual issues is simply that all three use Required-start: + $all, and thus all depend on each other) + <zigo> That's a huge pb IMO. + <youpi> pere: well, + <pere> zigo: show me one? + <youpi> rc.local:# Required-Start: $all + <youpi> rmnologin:# Required-Start: $remote_fs $all + <zigo> Yeah, the $all is just *bad*. + <pere> that is no loop. + <zigo> I do believe we should implement a lintian warning about it. + <pere> sure, $all do not behave the way most people expect, and should be + avoided as much as possible. + <pere> any other loops? + <youpi> no + <youpi> (not that I know of) + <pere> youpi: sending you the screenshot via irc. + <youpi> uh, long time no use dcc send, I don't even know where it sent it + to :o) + <pere> ok. aborting and trying another approach. + <pere> http://www.picpaste.com/booted-herd.png + <youpi> ok, so boot didn't actually finish + <youpi> that's why you don't get gettys or hurd-console (which is last) + <youpi> there must be some init script hanging in the meanwhile + <pere> logging in via ssh show no running startpar process, so I doubt that + is the case. + <pere> syslog contain this: Feb 5 10:10:27 hurdtest console[808]: Console + library initialization failed: Not a directory + <youpi> that is due to /dev/vcs not mounted + <youpi> but that should have not prevented the boot from completing... + <pere> the boot is completed, as far as I can tell. + <youpi> you can disable the hurd console in /etc/defaults/hurd-console + <youpi> do you have gettys running? + <pere> no such file. + <youpi> oops, -s + <pere> http://paste.debian.net/80251/ + <teythoon> pere: check your /etc/inittab, is there a getty for the mach + console ? + <youpi> he said yes earlier + <teythoon> oh ok + <teythoon> i wonder why it doesn't show up then + <youpi> same for me + <teythoon> if the getty cannot open the device, it will loop + <pere> ah, I was wrong. the inittab is not the one I thought. the current + one is after a reinstall, while I checked the content before that. + <teythoon> pere: check /var/log/auth.log + <pere> there is indeed no console entry in /etc/inittab. I thought it + would be copied into place during upgrades? + <teythoon> not if it exists + <teythoon> iirc + <youpi> indeed + <pere> ah, great. "cp /usr/share/sysvinit/inittab /etc/inittab" and a + reboot fixed it. :) + <youpi> phew :) + <pere> it really should try harder to update the inittab on hurd to a + working one. + <teythoon> didn't i do something like this to fix the getty path ? + <pere> yes. that was the code I expected to solve this. + <teythoon> it didn't work ? + <pere> well, I had the wrong inittab file... + <pere> btw, do hurd have the needed syscalls for bootlogd to work? + <teythoon> i haven't looked at bootlogd yet + <pere> would be nice to have a text dump of the boot when trying to figure + out what went wrong. + <teythoon> yes, that'd be nice + + <youpi> pere: could you blacklist /dev/vcs in umountfs, just like already + done for /proc|/dev|/.dev etc. ? + <youpi> so at least that case, which is really problematic, gets fixed now, + and not have to wait for another, more hurdish solution + <pere> youpi: just send patches to bts, and I'll pick it up from there. + <teythoon> nice. i'll work on the proper solution. bbl + <rleigh> teythoon: Can we add those translators to the exclusion lists in + umount[nfs]? + <rleigh> Sorry, I just noticed youpi's comment. I'm a bit behind. + <heroxbd> rleigh: good to see you! are you back to the keyboard? fully + recovered? + <rleigh> Not quite fully, but on the mend, thanks! + <heroxbd> :] + <pere> rleigh: yeah, good to see you again. I got a burst of energy and + brushed a bit on sysvinit in your absence. :) Even revitalized the + #pkg-sysvinit channel. :) + <rleigh> pere: Yes, I saw all the commit emails flying by! + <rleigh> I realistically won't be doing much for several weeks at least + though, I'm afraid. + <pere> no worries. spend your time getting well. :) it would be great to + have you on #pkg-sysvinit, though. :) + <rleigh> I'll join, no worries. I should add it to my irssi config so I + can't forget! + <heroxbd> teythoon: serial console always works, right? no matter how + hurd-console behaves. + <teythoon> heroxbd: yes + <teythoon> but you need a getty on it + <youpi> well, just like on linux :) + <teythoon> yes + <teythoon> almost + <teythoon> on mach, we have the mach console. by default that is put on the + vga screen, but you can make mach put it on a serial port using the + gnumach command line flag console=comX + <youpi> well, just like on linux :) + <heroxbd> understood, thanks! + <teythoon> oh, i didn't realize linux has this as well + <heroxbd> teythoon: you'll use it a lot on a embedded system + <heroxbd> an* + <teythoon> ok + + <gg0> plus, seems it can't cleanly umount /, at boot it fsck's it, fixes it + and auto-reboot + <youpi> it's odd that / doesn't get unmounted, don't you get a message at + "notifying ext2fs device:hd0s1 of shutown" ? + <gg0> on console last 3 lines on halt are + <gg0> Deactivating swap...swapoff: /dev/hd0s5: 4193208k swap space + <gg0> done. + <gg0> Unmounting local filesystems...done. + <gg0> INIT: no more processes left in this runlevel + <youpi> is this on reboot or on halt? + <gg0> halt + <youpi> then you should also be getting the "notifying" messages, as well + as "In tight loop: hit ctl-alt-del to reboot" message + <gg0> it umounts uncleanly on reboot too + <youpi> if you don't wait for these, there's little wonder it's not + properly unmounted + <gg0> i waited many seconds, time to rewrite 3 lines above for you for + instance (not a fast typist) + <gg0> on reboot it's harder but iirc they don't appear as well + * gg0 rebooting again + <gg0> need to wait it finishes fsck'ing + <gg0> (i should resoldering my serial cable to get back to lazily c&p) + <gg0> -ing + <gg0> many Give root password messages then + <gg0> Give root password for maintenance + <gg0> (or type Control-d to continue): + <gg0> INIT: Id "z6" respawning too fast: disabled for 5 minutes + <gg0> INIT: no more processes left in this runlevel + <gg0> i'll wait 5 mins to see what happen + <gg0> ok another dozen of Give root password and same couple of INIT above + <gg0> no, just the first INIT + <youpi> so z6 doesn't work + <youpi> i.e. /sbin/sulogin (see /etc/inittab) + <youpi> check out why that is + +[[hurd/translator/mtab/discussion]], *IRC, freenode, #hurd, 2013-06-25*, +*coreutils' `df`*. + + <youpi> [...] depends on coreutils actually building + <youpi> which depends on putting back a login package from the shadow + source package + <pere> are someone on that task? + <youpi> no idea + <youpi> IIRC I've mentioned the issue on the lists like months ago + <youpi> but probably nobody took the tas + <youpi> k + <youpi> basically it means fixing any bug that login or su from the login + package would have + <youpi> and then properly handle the migration from hurd-provided versions + to login-provided versions + <youpi> and then we would be able to build coreutils + <pere> which BTS report is this? + <youpi> I don't know if any report has been written about it + <youpi> perhaps simplest would be to build the login package, but not its + bin/login + <youpi> it seems hurd's getty uses special options of hurd'slogin + <youpi> that's probably the easiest way to go + + <gg0> sulogin seems to work fine but it shouldn't even called: + <gg0> # Normally not reached, but fallthrough in case of emergency. + <gg0> z6:6:respawn:/sbin/sulogin + <gg0> +be + <pere> I suspect a good fix is to provide a new init.d script in the hurd + package adding the symlink for hurd. + + <gg0> umountfs gets stuck at "Will now umount local filesystem:settrans + -apgf /lib/rc/init.d" + + +## IRC, freenode, #hurd, 2014-02-05 + + <gnu_srs> teythoon: Any ideas why I have to issue halt/reboot twice to make + the command succeed (from ssh login) + <gnu_srs> Is it the same issue with sysv-rc? + <teythoon> no + <gnu_srs> BTW: The segfault when booting came from bootlogd (wrong + parameters, Linux/~Linux), removing that one fixed it;-) + + +## IRC, freenode, #hurd, 2014-02-06 + + <youpi> teythoon: we really need to find the boot issue for which you added + a sleep 0.1 in runsystem.sysv + <youpi> apparently I had to move it above the mach-defpager startup, to get + a system that boots most of the time... + + <azeem> did somebody look at + http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html + ? + <braunr> azeem: interesting + <azeem> braunr: was mentioned here: http://lwn.net/Articles/584428/ + <azeem> " Systemd won't work for them, that's for sure, but nosh as a + systemd unit file compatible alternative could. " + <braunr> "I'm also very interested in seeing a discussion where the Debian + Hurd and BSD porters weigh in for themselves" + + +## IRC, OFTC, #debian-hurd, 2014-02-06 + + <gg0> on halt/reboot it can't remount readonly root because it's busy, what + makes it busy? + <gg0> by keeping /lib/rc/init.d mounted (like /dev/vcs) it shuts down + properly + <youpi> I don't know about such directory + <gg0> so seems that failed readonly remount is not a real problem because + at the end it runs halt-hurd/reboot-hurd which umount root properly + <youpi> yes + <gg0> afaiu it's a tmpfs where openrc copies "itself", kind of work + directory + <gg0> by removing it, it can't continue working + <gg0> at boot some messages are about its creation/population + <pere> why do init.d/hurd-console depend on $all? In most cases, depending + on $all is not giving you want you expect. + <youpi> because we prefer to start the console (and thus clear all the + screen) only after the boot has finished + <youpi> otherwise the console output will be messed up by the end of the + boot messages + <teythoon> youpi: there has to be a better way + <teythoon> b/c the way it is now, if one spawns a getty on the mach + console, it will mess up the hurd console as well + <youpi> well, we do want mach messages printed even with the hurd console, + at least + <teythoon> i once thought that instead of printing them the kernel could + send messages to a registered userspace daemon that could e.g. send them + to syslog + <youpi> that requires syslog to be working at all + <pere> changing $all to $local_fs seem to work fine here. + <youpi> when the kernel cries out, we'd better always be able to hear it :) + <youpi> pere: but then you have the bootup messages in the middle of the + console, don't you? + <pere> not as far as I can tell. look just the same as before. + <youpi> well, on my box it seems that it gets to start after other daemons, + by luck + <youpi> ah, perhaps getty actually clears the tty? + <youpi> then that would be ok + <teythoon> youpi: i don't think it does + <youpi> well, somehow something clears the output at least + <teythoon> i thought he hurd console does this + <youpi> it does on startup, yes + <youpi> but if it starts before other daemons + <youpi> the damons startup output gets over it + <youpi> one sees the console clear the screen, then get daemon startup + messages, and then the screen gets cleared again before the login prompt + appears + <teythoon> interesting, i haven't seen this happening + <youpi> it seems like it happens when emitting text on /dev/tty1, the + console will then clear the screen to make the way for the new output + <youpi> and since that happens on getty startup, it happens to be after all + daemon startup + <youpi> yes, that's what happens + <youpi> so considering this, I'm fine with starting the console earlier + <youpi> getting a display glitch seems to have been acceptable on Linux for + years :) + <youpi> (during boot, I mean) + <teythoon> ok + + <gg0> anyone else tried openrc? + <gg0> 15:20 < pere> yes, it did not umount properly. + <gg0> 15:36 < gg0> reboot or halt? it takes few seconds to actually + reboot/halt since the last message from openrc + <gg0> 15:39 < gg0> any typo adding such path? + * gg0 likes cross-channel pasting + <gg0> anyone else keeps getting unclean umounts even after applying + http://paste.debian.net/plain/80386/ ? + <teythoon> gg0: yes, me. worked fine, it didn't shut down properly though + <gg0> here works like a charm + <gg0> what do you mean by properly? + <gg0> i see first it can't remount root readonly but at least by not umount + path in question it continues executing scripts till actually shut it + down with something like {halt,reboot}-hurd + <gg0> *not umounting + <gg0> *shutting + <teythoon> for me it did not shut down + <gg0> you mean don't you get classic press ctrl+alt+canc to reboot message? + <teythoon> yes + <teythoon> from my perspective (and from /hurd/init's), that's not shutting + down + <teythoon> as in it did not call reboot(2) + <gg0> what are configuration not to miss besides switching runsystem to + sysv one? + <gg0> *configuration steps + <teythoon> no idea, i did nothing else but to switch to runsystem.sysv and + to install openrc thus replacing sysv-rc + <gg0> can you paste shutdown messages somewhere? + <teythoon> sure + <gg0> .o(world is failing, /me can't debug teythoon :)) + <teythoon> http://paste.debian.net/hidden/745071e6/ + <gg0> in my case i just found out that /etc/init.d/umountfs tries to umount + /lib/rc/init.d where openrc scripts are + <gg0> what if you set VERBOSE and print REG_MTPTS? something like + http://paste.debian.net/plain/80570/ + <gg0> there i got "settrans -apfg /lib/rc/init.d" which vanished with first + patch + <teythoon> http://paste.debian.net/80573/ + <gg0> ok and if you apply first patch http://paste.debian.net/plain/80386/ + <gg0> i.e. adding |/lib/rc/init.d to mount point to ignore + <teythoon> didn't help + <gg0> well output should change though + <teythoon> it does + <teythoon> but it still does not shut down + <gg0> paste please then + <teythoon> http://paste.debian.net/80576/ + <teythoon> what did you expect ? + <gg0> did you unapply VERBOSE & print REG_MTPTS? + <teythoon> yes + <teythoon> no + <teythoon> well + <gg0> seems you do, if VERBOSE is set, it prints Will now unmount local + filesystems" + <teythoon> i restored a vm snapshot, and applied both patches + <gg0> instead of "Unmounting local filesystems" + <gg0> *seems you did + <teythoon> http://paste.debian.net/80577/ + <teythoon> shall i do it again ? + <gg0> and what after "root@debian:/# halt" ? :p + <teythoon> 23:55 < teythoon> http://paste.debian.net/80576/ + <teythoon> and openrc shouting lots of stuff about breaking dependencies + <gg0> please yes do it again + <gg0> if VERBOSE is set, it prints "Will now unmount local filesystems" + instead of "Unmounting local filesystems" + <teythoon> yes, you are right + <teythoon> still, it does not work + <teythoon> http://paste.debian.net/80579/ + <gg0> i'm curious about the new REG_MTPTS, supposing /lib/rc/init.d has + been suppressed + <gg0> ok stop + <gg0> 23:47 < gg0> ok and if you apply first patch + http://paste.debian.net/plain/80386/ + <teythoon> i did + <teythoon> well, i added that path + <gg0> i don't believe so, it should ignore it if added + <teythoon> did it fix the issue for you ? + <gg0> yes + <gg0> any typo in addition? + <gg0> obviously patch is against sysvinit source but you have to apply it + to /etc/init.d/umountfs + <teythoon> obviously + <gg0> isn't it time to tell me you are kidding me yet? + <youpi> pere: thanks for the upload. I happened to realized that since it + was in collab-maint, I could as well just commit changes, I hope it's ok? + <teythoon> gg0: root@debian:~# fgrep '/lib/rc/init.d' /etc/init.d/umountfs + /|/proc|/dev|/.dev|/dev/pts|/dev/shm|/dev/.static/dev|/proc/*|/sys|/sys/*|/run|/run/*|/lib/rc/init.d) + <gg0> /dev/vcs is missing, not the latest sysvinit version + <gg0> could this affect shutdown? + <teythoon> i know + <teythoon> possibly + <gg0> what if you also add /dev/vcs to path list? + <teythoon> what then ? + <teythoon> i don't mind /dev/vcs being + <teythoon> err, 'umounted' + <teythoon> i can handle that just fine + <gg0> i mean what happens if you add /dev/vcs to path list in + /etc/init.d/umountfs as you did with /lib/rc/init.d? + <gg0> what happens = how it shutdown + <teythoon> why would it be any different ? + <gg0> no idea, seems the only change you don't have + <gg0> i just know it fixes hurd console + <teythoon> i know it fixes the hurd console b/c i was the one who broke the + hurd console in the first place ... + <gg0> quite sure there's something wrong on your side + <gg0> if it's actually among those path to ignore, it can't be added to + REG_MTPTS + <gg0> my /proc/mounts http://paste.debian.net/plain/80583 + <gg0> yours? + <gg0> i hope i'm not forgetting one change i did around + <gg0> teythoon: /proc/mounts ? + + +## IRC, OFTC, #debian-hurd, 2014-02-07 + + <gg0> teythoon: sorry for pasting reversed patches + <gg0> please apply http://paste.debian.net/plain/80587, halt and paste + output + /proc/mounts + <pere> youpi: just fine. but please join us on #pkg-sysvinit and make sure + to follow the mailing lists. + <teythoon> gg0: no, sorry, i was perfectly able to use -R on your patches, + as demonstrated by the paste i send + <teythoon> i think i'll rather just wait for the next sysvinit package and + try it again + <gg0> teythoon: i don't doubt you are able, i'm sorry because i messed up + things + <gg0> /lib/rc/init.d should not go in $REG_MTPTS + <gg0> sysvinit 2.88dsf-48 just add /dev/vcs to not-to-umount paths and make + boot consider -s for single user, nothing about umounting filesystems on + halt/reboot + <pere> the /lib/rc/init.d/ change to umountfs seem to be the wrong one, as + it do not solve the problem for me. because of this, I have not applied + it to git. + <gg0> pere: could you try to apply http://paste.debian.net/plain/80587, + halt and paste output? + <gg0> well it applies to teythoon who doesn't have /dev/vcs + <gg0> */dev/vcs change + <gg0> pere: this one applies to -48 + installed. http://paste.debian.net/plain/80615/ + <gg0> given /lib/rc/init.d is added to not-to-umount paths it can't go in + REG_MTPTS + <pere> http://picpaste.com/halt-hurd-DVEVoHnr.png + <gg0> pere: you didn't apply it + <gg0> no messages from umountfs + <gg0> which is even more weird + <pere> well, patch claimed it did. + <gg0> normally it says "Unmounting local filesystems..." + <pere> checked the file, patch is applied. + <gg0> ok i think i got it + <gg0> patch is good. it just requires booting twice _and_ removing + non-patched /etc/init.d/umountfs.* if any + <gg0> patch = adding /lib/rc/init.d + <gg0> so + <pere> which files do you need to remove? + <gg0> /etc/init.d/umountfs.* and /lib/rc/init.d/started/umountfs.* + <gg0> do you have any? + <gg0> you should just have patched umountfs under both /etc/init.d/ and + /lib/rc/init.d/started/ + <gg0> the latter is populate at boot, that's why i said twice to become + effective + <gg0> *populated + <gg0> but propably /lib/rc/init.d/started/umountfs can be fixed on the fly + <gg0> from start: + <pere> why do you need to remove these files? + <gg0> 1/ patch /etc/init.d/umountfs by adding /lib/rc/init.d to + not-to-umount path list + <pere> why are these files not ignored? + <gg0> 2/ remove /etc/init.d/umountfs.* if any (eg. .orig .new .whatever) + <gg0> pere: because it loads them at boot, you need it loads just the right + one + <gg0> 3/ reboot twice + <gg0> (3/ halt twice) + <pere> this sound very fishy to me. + <gg0> or 3/ fix umountfs files under /lib/rc/init.d/started as well + <gg0> that should make it shutdown properly right away + <pere> my halt still hang. + <gg0> pere: you have /lib/rc/init.d in both /etc/init/umountfs and + /lib/rc/init.d/started/umountfs and there are no umountfs.* around? + <gg0> problem seems to be it picks first it finds if there are more than + one + <gg0> well i could have been more precise: /lib/rc/init.d/started/umountfs + is a link to /etc/init.d one + <gg0> btw there must be just one and only one umountfs, patched + <gg0> pere: clean /etc/init.d, reboot/halt with reboot-hurd or halt-hurd, + then next sysv reboot/halt will be good + <gg0> you just need to leave patched umountfs under /etc/init.d alone + <gg0> patch has always been good, it just needs 2 reboots to be appreciated + <gg0> pere: do you have other /etc/init/umountfs* files besides patched + one? + <gg0> my guess is it takes the first and only the first which Provides: + umountfs + <gg0> 12:17 < pere> why are these files not ignored? + <gg0> 12:35 < gg0> my guess is it takes the first and only the first which + Provides: umountfs + <gg0> to confirm that, if you have umountfs and umountfs.orig, under + /started you'll find just umountfs.orig + <gg0> pere: how goes? + <gg0> teythoon: last ~40 lines + <gg0> i'm assuming you have any else umountfs.* under /etc/init.d. if you + just add /lib/rc/init.d path to the only umountfs there should not be any + problem + <pere> gg0: removing the umountfs.* files did not help, as far as I can + tell. + <pere> are you telling me that openrc caches all init.d scripts in + /lib/rc/init.d/ at boot? + <gg0> pere: yes, you can see them. which umountfs* do you have under + /lib/rc/init.d ? + <pere> the right one. :) + <gg0> only the right one? + <pere> just scared me to know that changes on the disk do not take effect + immediately with openrc. + <gg0> pere: only the right one? + <pere> yes + <gg0> here i screwed it up by forcing initscripts removal and reinstall to + reproduce it, then fixed it once again + <gg0> i should just improving the explaination :) + <gg0> pere: "removing the umountfs.* files did not help," so did you find + any? + <pere> yes, both .orig, .rej and .dpkg-old + <gg0> pere: ok you should find one of them linked under + /lib/rc/init.d/started then + <gg0> /lib/rc/init.d/started/umountfs.* + <pere> I removed them three boots ago. still halt hangs. + <gg0> pere: and current umountfs have /lib/rc/init.d in path list? + <gg0> *has + <pere> yes. + <gg0> pere: can you access via ssh to it before issuing halt? + <pere> that is how I access it normally. + <gg0> ok + <gg0> before halt df should list /lib/rc/init.d as well + <gg0> after halt it should not, do you confirm that? + <gg0> (ssh connection here is kept alive) + <pere> my ssh connection went down, but /lib/rc/init.d was mounted while it + was active. + <pere> to me it look like umountfs isn't executed at all during shutdown. + <pere> oh, well. got to work on other things now. :) + <gg0> it's correct getting no messages if there no filesystem to umount + <gg0> as it wouldn't be run at all + <zigo> pere: Hey, thanks for uploading sysv-rc -48 ! :) + <pere> you are welcome. :) + <gg0> i can't reproduce it on a VM :/ http://paste.debian.net/plain/80658/ + <gg0> ehm no, same machive, successive halt + http://paste.debian.net/plain/80659/ + <gg0> got stuck + <pere> are there any testet sysvinit patches for hurd lingering? I plan to + upload a new version tonight or tomorrow. + + +## IRC, OFTC, #debian-hurd, 2014-02-08 + + <gg0> http://paste.debian.net/plain/80854/ + <gg0> expected? + <gg0> do tmpfs and procfs need to be shown as types /hurd/tmpfs and + /hurd/procfs? + <gg0> or can they be "normalized"? + <gg0> domount mount_noupdate tmpfs shmfs /run tmpfs + -onosuid,noexec,size=10%,mode=755 + <gg0> another one is why on linux options are nosuid,noexec ^, whereas on + hurd no-suid,no-exec,... ? + <rleigh> gg0: If they need generalising, we can add $nosuid/$noexec + etc. variables to mount-functions.sh and set them appropriately for the + currently platform. + <rleigh> current platform rather + <gg0> yeah, i ask just to understand what side people prefers modifying, in + this case hurd vs sysvinit + <gg0> btw in the meanwhile i got tmpfs takes options without '-' though it + shows them with '-' in proc/mounts + <gg0> rleigh: and thanks for pointing out what looking for, little hints + saves hours in my case :) + [IRC connection closed] + + +## IRC, freenode, #hurd, 2014-02-08 + + <youpi> gnu_srs: the -49 version of sysvinit contains a fix for bootlogd + + +### IRC, freenode, #hurd, 2014-02-09 + + <gnu_srs> (16:31:17) <youpi>: gnu_srs: the -49 version of sysvinit contains + a fix for bootlogd + <gnu_srs> Nice for kFreeBSD, for Hurd it doesn't matter if we get a + segfault or an error code saying it's not implemented :-( + <youpi> segfault vs error code is really not the same + <youpi> iirc bootlogd would ignore the error + <gnu_srs> Nevertheless, bootlogd is not usable on Hurd :( + <youpi> then fix it + + +## IRC, OFTC, #debian-hurd, 2014-02-08 + + <rleigh> gg0: If the sames are set by hurd itself, then it makes sense to + adapt sysvinit to cope with that rather than altering hurd since that + would be a fairly major compatibility break. OTOH, adding support for the + Linux/FreeBSD names in addition to the hyphenated names would be good + from the point of view of better interoperability generally, not just for + sysvinit. + <rleigh> For now, getting sysvinit to support the Hurd names is easy + enough, and if you do add the Linux/FreeBSD names then the compatibility + stuff can be removed when that's available. + + +## IRC, freenode, #hurd, 2014-02-11 + + <gnu_srs> Hi, still problems with hurd console under openrc: console: + Console library initialization failed: Not a directory + <gnu_srs> and /dev/vcs is there + <youpi> gnu_srs: but is it a directory? + <gnu_srs> the output of console -d vga -d pc_mouse --repeat=mouse -d pc_kbd + --repeat=kbd -d generic_speaker -c /dev/vcs gives the response above + <gnu_srs> looks like /dev/vcs is a file. How to recreate the directory + content? + <gnu_srs> I thought it should not be removed with the latest sysvinit + package (-49) + <gnu_srs> from -48 changelog: Tell init.d/umountfs to not umount /dev/vcs, + as it break the console on Hurd. Patch from Samuel Thibault. + <youpi> gnu_srs: but did your reconfigure the hurd package to remount it ? + <gnu_srs> ? + <youpi> /dev/vcs won't magically be remounted by just not being unmounted + by sysvinit + <gnu_srs> dpkg-reconfigure hurd? + <youpi> sure + <gnu_srs> I can start the console manually, but ENABLE='true' in + /etc/default/hurd-console does not work (at least with openrc) + <youpi> does /dev/vcs becomes a mere file again with openrc? + <gnu_srs> no it's a directory with 6 entries + <youpi> does the /etc/init.d/hurd-console gets to starT? + <youpi> I'm afraid I'm really asking obvious questions that you should have + already asked for yourself + <gg0> so you mounted it and it's not a file anymore. does it work now? + <gnu_srs> it seem like the service is not started, trying to figure out + why:-D + <gnu_srs> I can restart it but it is not visible in rc-status? + + <gg0> shutdown stuck at "Asking all remaining processes to + terminate...done." (even before distupgrade btw) + <gg0> seems stuck at killall5 -18 + <teythoon> hm, that's bad + <teythoon> how do you know that ? + <gg0> /etc/init.d/sendsigs and /etc/init.d/killprocs + <gg0> (yes, switched to sysvinit and testing openrc) + <teythoon> but killall5 -18 is SIGSTOP right? + <teythoon> and if it says ...done. then killall5 has already been run + <teythoon> so, how do you know it hangs at killall5 ? + <gg0> teythoon: "done" is "log_action_end_msg 0" just after killall5 -15, + then we should get "Killing all remaining processes" or "All processes + ended within $seq seconds." + <gg0> Asking all remaining processes to terminate...killall5 -15 -o 956 # + SIGTERM...done. + <gg0> All processes ended within 1 seconds...done. + <gg0> shutdown properly this time + <teythoon> hm + <teythoon> fwiw, i've also encountered hangs, haven't investigated yet + <gg0> with openrc? + <teythoon> yes + + <gnu_srs> Is it so that with teythoons mtab translator umount -a unmounts + all passive translators, removing the translator records?? + <gnu_srs> causing pflocal (and pfinet) to disappear? + +[[hurd/translator/mtab/discussion]]. + + <azeem> gnu_srs: didn't he say that this is getting fixed in his latest + patchset? + <gnu_srs> yes, what about mine and gg0s currently hosed systems? + <gnu_srs> yes, but until the patch makes into the next release,** + <youpi> gnu_srs: pflocal and pfinet don't appear in mtab + <youpi> because they don't expose whole directories, just a trivial node + <youpi> so no, they won't get umounted by umount -a + <youpi> simply check the content of /proc/mounts + <gnu_srs> so how come I cannot recover my image? + <gnu_srs> and gg0 neither + <youpi> no idea, I've never tried openrc + <youpi> when daring new fields, you face new issues, that's no wonder + <gnu_srs> so this does not happen with sysv-rc? + <youpi> I haven't seen any of this kind of issue + <youpi> whether it's related to using openrc vs sysvrc, I have no idea + <youpi> but at least that's a candidate for sure + <gnu_srs> well in my case hurd bootstrap is stuck after ext2fs exec and + before init + <gnu_srs> ant reinstalling hurd via linux does not help + <youpi> you mean the hurd package? + <youpi> you can also try to reinstall the libc0.3 package + <youpi> normally it should be all that is needed for boot + <youpi> perhaps also some /dev entries + <gnu_srs> yes, the hurd package. I will try with libc0.3 tomorrow. Which + /dev entries, and how to create them manually? + <youpi> "perhaps" implies that I don't know + <youpi> you can as well just boot with an install CD, mount your disk, + chroot into it, and run dpkg-reconfigure hurd there to recreate + everything in /dv + <youpi> +e + + +## IRC, OFTC, #debian-hurd, 2014-02-13 + + <youpi> pere, rleigh: which script is supposed to make /etc/mtab a symlink + to /proc/mounts already? I can't find it + <pere> youpi: see /lib/init/mount-functions.sh + + +## IRC, freenode, #hurd, 2014-02-13 + + <braunr> teythoon: are the sysvinit debian packages in sid usable currently + ? + <teythoon> they are + <braunr> nice + <teythoon> youpi and pere have been busy polishing it quite a bit + <braunr> teythoon: and uhm, how does one enable sysvinit in debian ? :) + <braunr> ah, found pere's blog + <teythoon> braunr: didn't you read the postinst instructions ? :p + <teythoon> update-alternatives --config runsystem + <braunr> oh right + <braunr> got lost in the noise + <braunr> very nice + <braunr> still a few glitches i see, but it does the job + <braunr> although i'm not sure i like the lack of console prompt :/ + <braunr> i'll keep darnassus on the old runsystem until this is fixed + <teythoon> braunr: cp -p /usr/share/sysvinit/inittab /etc/inittab + <teythoon> and kill -HUP 1 + <braunr> oh + <braunr> :) + <braunr> teythoon: thanks + <braunr> teythoon: do you know why there are three tmpfs instances after + startup (/run, and in addition, /run/shm and /run/lock) instead of one on + /run ? + <braunr> sorry for being so annoying :) + <teythoon> braunr: dunno, but that is what Debian does + <braunr> https://wiki.debian.org/ReleaseGoals/RunDirectory explains it a + bit + <teythoon> root@thinkbox ~src # uname -s; mount | grep /run + <teythoon> Linux + <teythoon> tmpfs on /run type tmpfs + (rw,nosuid,noexec,relatime,size=306952k,mode=755) + <teythoon> tmpfs on /run/lock type tmpfs + (rw,nosuid,nodev,noexec,relatime,size=5120k) + <teythoon> tmpfs on /run/shm type tmpfs + (rw,nosuid,nodev,noexec,relatime,size=613900k) + <braunr> i like this /run directory + <teythoon> yep, it's nice + <braunr> ah great, i can add ,sync=30 to fstab and it's added at boot time + :) + + +## IRC, freenode, #hurd, 2014-02-17 + + <congzhang> hi, I think we should make console server separate from + hurd-console + <congzhang> if DM want start, console server need be start first + <braunr> congzhang: send patches + <congzhang> and hurd-console mark it start at the end of sysinit? + <teythoon> congzhang: i agree + <braunr> teythoon: isn't hurd-console the console server ? + <congzhang> I want to check whether it is need first + <teythoon> braunr: yes, but congzhangs point is (as i understand it) that + the backend component should be started earlier + <teythoon> then again, i know little about the hurd console + <congzhang> no, if user enable one dispaly manager, then cycle dependence + happen + <braunr> why ? + <teythoon> i believe that is a different problem, namely that our + hurd-console init script depends on $all + <teythoon> pere: ^ + <congzhang> hurd-console Required-Start： $all + <braunr> ok + <braunr> yes that's a separate issue, and easier to understand + <congzhang> teythoon: if wdm Required-Start hurd-console, then insserv + can't generate the script order, right ? + <teythoon> congzhang: possibly, i don't know for sure + <congzhang> It doesn't work , and I rename to S??wdm to later one like + S20wdm + <congzhang> but insserv will regenerate the script order in /etc/rc2.d/, I + can't depend on that + <pere> congzhang: $all means after all scripts not depending on $all, and + not what the intuitive interpretation would tell you. + <pere> the current implementation order all scripts as if $all were not + present, and then move all scripts depending on $all to the last order + number+1. + <pere> because $all is misunderstood by most users, I strongly recommend to + _not_ use $all in any init.d script. + <congzhang> pere: so to make wdm to be number+more? + <pere> congzhang: make it depend on $all and be lexically sorted after + hurd-console. :) + <congzhang> wdm need start after hurd-console, if console-driver will run + when hurd-console start + <pere> not quite sure how startpar handle that case, so it might not work + the way you want anyway. + <pere> adding a dependency on hurd-console should not hurt, though. :) + <congzhang> how make it lexically sorted after hurd-console? + <pere> w is already after h in the alphabet. :) + <congzhang> that's trick! + <pere> but startpar uses the info in /etc/init.d/.depend.* (makefile style) + to order scripts, so check what the result is there too. + <braunr> congzhang: no it's not + <congzhang> that's just cache + <braunr> congzhang: ? + <congzhang> and generated from script head? + <congzhang> the right way is Adding run-time dependencies in script + <pere> congzhang: yes. insserv called from update-rc.d generate the + .depend.* files, and startpar reads the files (and ignore the headers) + when starting scripts. + <congzhang> if the script have cycle dependence, no one can help + <pere> congzhang: if there is a cycle, update-rc.d will reject the script. + <congzhang> sure, because the system current have not runable one + <congzhang> Display Manager run before hurd-console, and never successful + for X stared failed! + <pere> what is this hurd-console stuff, btw? it sound like somthing that + should be started in rcboot.d (aka rcS.d on Debian). + <congzhang> if you install wdm, you will notice that wdm start failed + <pere> should it run before sulogin when booting into single user? + <congzhang> hurd-console mix too much thins + <teythoon> pere: it's the console multiplexes that provides /dev/tty? + <congzhang> just part of that function + <teythoon> pere: it's like screen or tmux a server-client architecture + <teythoon> the x server gets keyboard and mouse events from it iirc + <pere> right. so not needed by sulogin, I guess. because if it was, it + should start in rcS.d, not rc[2-5].d/. + <congzhang> and also start /bin/console to start keyboard and mouse driver + <teythoon> /bin/console is the frontend + <pere> and if it started in rcS.d/, it would always be started before + wdm. :) + <braunr> i think it should be started in rcS.d + <congzhang> why not essential? + <pere> braunr: when I tried, it failed. + <congzhang> https://www.gnu.org/software/hurd/hurd/console.html + <congzhang> teythoon: i want to make one disk img with default DM, and face + these problem + <braunr> pere: do you have a log of the failur e? + <congzhang> teythoon: I know you are working on the hurd init system, so I + ask you for help + <pere> braunr: only the boot message: Starting Hurd console multiplexer: + hurd-console failed! + <pere> braunr: how can I learn more? + <braunr> i don't know any easy way + <braunr> try to put the system in its early state manually + <braunr> and maybe run rpctrace on the actual console command + <braunr> if that is what really fails + <congzhang> and I found that pc_kbd may have some bug? I have high + frequence of start failed if I make it start + <congzhang> but I can't located the real source of these problem + <teythoon> pere: the console logs some messages to syslog + <pere> teythoon: looked, nothing there. :( + <pere> gah, look like I broke my hurd machine. Added rpctrace to the start + of hurd-console, and now the boot just hang there, and when I interrupt + it the kernel reboot the entire machine. :( + <braunr> pere: use rpctrace manually, don't script it + <teythoon> oh yeah, seen this as well + <pere> braunr: well, no use to test it after boot when it hang during + boot... + <teythoon> it triggers an assertion in the proc server iirc + <braunr> pere: that doesn't imply you need to script it + <congzhang> pere: qemu snapshot mode will be your friend:) + <braunr> ideally, i'd run the init system automatically up to the point i + want to run my test, and make it spawn a shell, and use that shell then + <pere> congzhang: hah. real men do to take backups. but they weep a + lot. :) + <congzhang> teythoon: runsystem.sysv has work well on my machine, just some + error infomation + <teythoon> good + + +## IRC, freenode, #hurd, 2014-02-21 + + <gnu_srs1> Hi, a general question: is ptrace available for GNU/Hurd? + <teythoon> yes + <gnu_srs1> tks, the openrc developers are working on process supervision + using it: good/bad? (compared to cgroups) + <teythoon> uh + <teythoon> i prefer the cgroups approach + <teythoon> but upstart also uses ptrace to keep track of the 'main' process + of an daemon + <teythoon> they use ptrace to follow a daemon that double forks + <gnu_srs1> teythoon: and regarding portability? + + +## IRC, freenode, #hurd, 2014-02-24 + + <braunr> sysvinit doesn't seem to handle /etc/default/locale into + consideration + + +## IRC, OFTC, #debian-hurd, 2014-02-25 + + <gg0> how about switching runsystem.sysv by default? + <youpi> now that it seems to be running fine, we could do that, yes + + # Required Interfaces In the thread starting diff --git a/open_issues/ti-rpc_then_nfs.mdwn b/open_issues/ti-rpc_then_nfs.mdwn index aa36e020..c3dd4e26 100644 --- a/open_issues/ti-rpc_then_nfs.mdwn +++ b/open_issues/ti-rpc_then_nfs.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 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 @@ -18,3 +18,88 @@ It needs some work on our side, [[!message-id Then, the Hurd's [[hurd/translator/nfs]] translator and [[hurd/nfsd]] can be re-enabled, [[!message-id "87hb2j7ha7.fsf@gnu.org"]]. + + +## IRC, freenode, #hurd, 2014-02-19 + + <pere> hi. I'm trying to port libtirpc to get rcpbind on hurd, and am + unable to find IPV6_PORTRANGE and IPV6_PORTRANGE_LOW. is this a known + problem with a known fix? + <braunr> what are they supposed to be ? + <pere> braunr: found them described in <URL: + http://www.daemon-systems.org/man/ip6.4.html >. + <braunr> "The IPV6_PORTRANGE socket option and the conflict resolution rule + are not defined in the RFCs and should be considered implementation + dependent + <braunr> " + <braunr> hm + <braunr> if we have that, they're very probably not accessible from outside + our network stack + <pere> needed feature on hurd, in other words... + <braunr> why ? + <pere> If I remember correctly, SO_PEERCRED is also missing? + <braunr> yes .. + <braunr> that one is important + <pere> braunr: you wonder why the IPV6_PORTRANGE socket option was created? + <braunr> i wonder why it's needed + <braunr> does linux have it ? + <pere> yes, linux got it. + <braunr> same name ? + <pere> it make it possible for some services to work with some + firewalls. :) + <pere> yes, same name, as far I can tell. + <braunr> they could merely bind ports explicitely, couldn't they ? + <pere> not always. + <braunr> or is it for servers on creation of a client socket ? + <pere> see <URL: + http://www.stacken.kth.se/lists/heimdal-discuss/2000-11/msg00002.html > + for an example I came across. + <braunr> i don't find these macros on linux :/ + <pere> how strange. libtirpc build on linux. + <braunr> is there a gitweb or so somewhere ? + <braunr> i can't find it on sf :/ + <pere> for <URL: http://sourceforge.net/projects/libtirpc >, you mean? + <braunr> yes + <pere> no idea. + <braunr> are you looking at upstream 0.2.4 or a particular debian package ? + <pere> I'm looking at the debian package. + <braunr> let me take a look + <pere> http://paste.debian.net/82971/ is my first draft patch to get the + source building. + <braunr> ok so + <braunr> in src/bindresvport.c + <braunr> if you look carefully, you'll see that these _PORTRANGE macros are + used in non linux code + <braunr> not very portable but it explains why you hit the problem + <braunr> try using #if defined (__linux__) || defined(__GNU__) + <braunr> also, i think we intend to implement SCM_CREDS, not SO_PEERCRED + <braunr> but consider we have neither for now + <pere> ah, definitely a simpler fix. + <braunr> pere: btw, see + https://lists.debian.org/debian-hurd/2010/12/msg00014.html + + <pere> <URL: https://bugs.debian.org/739557 > with patch reporte.d + + +## IRC, freenode, #hurd, 2014-02-20 + + <pere> new libtirpc with hurd fixes just uploaded to debian. should fix + the rpcbind build too. + + +## IRC, OFTC, #debian-hurd, 2014-02-20 + + <pere> hm, rpcbind built with freshly patched libtirpc fail to work on + hurd. no idea why. + <pere> running 'rpcinfo -p' show 'rpcinfo: can't contact portmapper: RPC: + Success' + <teythoon> o_O + <pere> I have no idea how to debug it. :( + <pere> anyway, I've found that rpcinfo is the broken part. rpcbind work, + when I test it from a remote machine. + + +## IRC, OFTC, #debian-hurd, 2014-02-21 + + <pere> failing rpcinfo -p on hurd reported as <URL: + http://bugs.debian.org/739674 >. Anyone got a clue how to debug it? diff --git a/open_issues/tmux.mdwn b/open_issues/tmux.mdwn index f71d13e1..c49a5e12 100644 --- a/open_issues/tmux.mdwn +++ b/open_issues/tmux.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 @@ -10,6 +10,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_porting]] + # IRC, freenode, #hurd, 2013-08-01 <braunr> teythoon: can you stop tmux on darnassus please ? @@ -22,3 +23,35 @@ License|/fdl]]."]]"""]] <teythoon> sometimes tmux would hang on attaching or detaching though, but overall I had less problems with tmux than with screen <teythoon> ah, I tried to start tmux on darnassus and now it hangs + + +# IRC, freenode, #hurd, 2014-02-04 + + <teythoon> braunr: whoa, i can reproduce gnu_srs' hanging ssh sessions on + darnassus + <teythoon> here goes + <teythoon> run tmux, exit the shell so that tmux quits, start tmux again + (tmux hangs now on some socket stuff), log in with ssh again, pkill tmux, + rm /tmp/tmux*/default => both ssh sessions hang and time out eventually + <braunr> why start tmux twice ? + <teythoon> dunno + <teythoon> that's what i just did, twice in a row + <teythoon> there's a bug somewhere that makes tmux hang if the socket + exists but no tmux server is running + <teythoon> maybe that contributes to to the other issuse, i don't know + <braunr> looks like an infinite loop somewhere + <gnu_srs> teythoon: Nice to set that I'm not alone having this problem:P + <braunr> teythoon: what's happening ? :) + <teythoon> ? + <braunr> on darnassus + <teythoon> not sure + <teythoon> uh, something is very wrong o_O + <teythoon> help ? + <braunr> :) + <braunr> the msg thread of a process is blocked somewhere + <braunr> preventing ps/top from completing + <braunr> looks like proc is blocked now .. + <braunr> restarting the vm + <braunr> apparently, removing buggy tmux sockets make pflocal crash + <braunr> thanks for the report :) + <teythoon> you are welcome :) diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn index 98fe0cfc..87556075 100644 --- a/open_issues/translate_fd_or_port_to_file_name.mdwn +++ b/open_issues/translate_fd_or_port_to_file_name.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010, 2011, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -156,6 +156,91 @@ License|/fdl]]."]]"""]] <braunr> see bug-hurd +## IRC, freenode, #hurd, 2013-12-05 + + <teythoon> braunr: no more room for vm_map_find_entry in 80220a40 + <teythoon> 80220a40 <- is that a task ? + <braunr> or a vm_map, not sure + <braunr> probably a vm_map + <teythoon> hm + <teythoon> let's fix this kind of reporting + <braunr> :) + <teythoon> let one process register for kernel log messages + <teythoon> make a rich interface, say klog_thread and friends + <teythoon> a userspace process gets the port name, looks it up in proc, + logs nicely to syslog + <teythoon> if noone registered for this notifications, fall back to the old + reporting + <braunr> i tend to think using internal names is probably better + <teythoon> how would i use them to see wich process caused the issue ? + <braunr> you give the name of the task + <braunr> (which means tasks have names, yes) + <teythoon> ok + <braunr> the reason is that reporting is often used for debugging + <braunr> and debugging usually means there is a bug + <braunr> if the bug prevents from reporting, it's not very useful + <braunr> and we're talking about the kernel here, the low level stuff + <teythoon> incidentally, i got myself a stuck process + <teythoon> ah, got it killed + <teythoon> braunr: so you propose to add a task rpc to set a name ? + <braunr> i don't want to push such things + <braunr> which is why this hasn't been done until now + <braunr> but that's what i'd do in x15, yes + <teythoon> y not ? + <braunr> and instead of a process registered to gather kernel messages, i'd + use a dmesg-like interface, where the kernel manages its message buffer + itself + <braunr> i didn't feel the need to + <braunr> the tools i've had until now were sufficient + <braunr> don't forget you still need to fix mtab :p + <braunr> or is it done ? + <teythoon> i sometimes see tasks deallocating invalid ports + <teythoon> no + <teythoon> there is an un-acked patche series on the list + <braunr> ok + <teythoon> so, i want to identify which process caused it + <teythoon> is that possible right now ? + <braunr> not easily, no + <teythoon> so that's a valid use case + <braunr> it is + <teythoon> good + <teythoon> :) + <teythoon> so proc would register a string describing each task and mach + would use this for printing nicer messages ? + <braunr> for example, yes + <braunr> one problem with that approach is that it doesn't fit well with + subhurds + <teythoon> *bingbingbing + <braunr> but i personally wouldn't care much, they're kernel messages + <braunr> in the future, we could make mach more a hypervisor, and register + names for each domains + <teythoon> yet unanswered proposal about hierachical proc servers on the + list... + <teythoon> that'd also fix subhurds, so that the parents processes won't + appear in the subhurd + <teythoon> making it sandboxier + <teythoon> and killall5 couldn't slaughter the host system if the subhurd + shuts down with sysvinit + + +## IRC, freenode, #hurd, 2014-01-20 + + <teythoon> i wonder if it would not be best to add a description to mach + tasks + <braunr> i think it would + <teythoon> to aid fixing these kind of issues + <braunr> in x15, i actually add descriptions (names) to all kernel objects + <teythoon> that's probably a good idea, yes + <braunr> well, not all, but many + + +## IRC, OFTC, #debian-hurd, 2014-02-05 + + <teythoon> youpi: about that patch implementing task_set_name, may i merge + the amended version ? + <youpi> yes + + # IRC, freenode, #hurd, 2011-07-13 A related issue: diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn index d6c33d30..69ec1d23 100644 --- a/open_issues/user-space_device_drivers.mdwn +++ b/open_issues/user-space_device_drivers.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2011, 2012, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2009, 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 @@ -19,7 +19,7 @@ Also see [[device drivers and IO systems]]. [[!toc levels=2]] -# Issues +# Open Issues ## IRQs @@ -250,6 +250,297 @@ A similar problem is described in <teythoon> cool :) +#### IRC, freenode, #hurd, 2014-02-10 + + <teythoon> braunr: i have a question wrt memory allocation in gnumach + <teythoon> i made a live cd with a rather large ramdisk + <teythoon> it works fine in qemu, when i tried it on a real machine it + failed to allocate the buffer for the ramdisk + <teythoon> i was wondering why + <teythoon> i believe the function that failed was kmem_alloc trying to + allocate 64 megabytes + <braunr> teythoon: how much memory on the real machine ? + <teythoon> 4 gigs + <braunr> so 1.8G + <teythoon> yes + <braunr> does it fail systematically ? + <teythoon> but surely enough + <teythoon> uh, i must admit i only tried it once + <braunr> it's likely a 64M kernel allocation would fail + <braunr> the kmem_map is 128M wide iirc + <braunr> and likely fragmented + <braunr> it doesn't take much to prevent a 64M contiguous virtual area + <teythoon> i see + <braunr> i suggest you try my last gnumach patch + <teythoon> hm + <teythoon> surely there is a way to make this more robust, like using a + different map for the allocation ? + <braunr> the more you give to the kernel, the less you have for userspace + <braunr> merging maps together was actually a goal + <braunr> the kernel should never try to allocate such a large region + <braunr> can you trace the origin of the allocation request ? + <teythoon> i'm pretty sure it is for the ram disk + <braunr> makes sense but still, it's huge + <teythoon> well... + <braunr> the ram disk should behave as any other mapping, i.e. pages should + be mapped in on demand + <teythoon> right, so the implementation could be improved ? + <braunr> we need to understand why the kernel makes such big requests first + <teythoon> oh ? i thought i asked it to do so + <braunr> ? + <teythoon> for the ram disk + <braunr> normally, i would expect this to translate to the creation of a + 64M anonymous memory vm object + <braunr> the kernel would then fill that object with zeroed pages on demand + (on page fault) + <braunr> at no time would there be a single 64M congituous kernel memory + allocation + <braunr> such big allocations are a sign of a serious bug + <braunr> for reference, linux (which is even more demanding because + physical memory is directly mapped in kernel space) allows at most 4M + contiguous blocks on most architectures + <braunr> on my systems, the largest kernel allocation is actually 128k + <braunr> and there are only two such allocations + <braunr> teythoon: i need you to reproduce it so we understand what happens + better + <teythoon> braunr: currently the ramdisk implementation kmem_allocs the + buffer in the kernel_map + <braunr> hum + <braunr> did you add this code ? + <teythoon> no + <braunr> where is it ? + <teythoon> debian/patches + <braunr> ugh + <teythoon> heh + <braunr> ok, don't expect that to scale + <braunr> it's a quick and dirty hack + <braunr> teythoon: why not use tmpfs ? + <teythoon> i use it as root filesystem + <braunr> :/ + <braunr> ok so + <braunr> update on what i said before + <braunr> kmem_map is exclusively used for kernel object (slab) allocations + <braunr> kmem_map is a submap of kernel_map + <braunr> which is 192M on i386 + <braunr> so a 64M allocation can't work at all + <braunr> it would work on xen, where the kernel map is 224M large + <braunr> teythoon: do you use xen ? + <teythoon> ok, thanks for the pointers :) + <teythoon> i don't use xen + <braunr> then i can't explain how it worked in your virtual machine + <braunr> unless the size was smaller + <teythoon> i'll look into improving the ramdisk patch if time permits + <teythoon> no it wasnt + <braunr> :/ + <teythoon> and it works reliably in qemu + <braunr> that's very strange + <braunr> unless the kernel allocates nothing at all inside kernel_map on + qemu + + +##### IRC, freenode, #hurd, 2014-02-11 + + <teythoon> braunr: http://paste.debian.net/81339/ + <braunr> teythoon: oO ? + <braunr> teythoon: you can't allocate memory from a non kernel map + <braunr> what you're doing here is that you create a separate, non-kernel + address space, that overlaps kernel memory, and allocate from that area + <braunr> it's like having two overlapping heaps and allocating from them + <teythoon> braunr: i do? o_O + <teythoon> so i need to map it instead ? + <braunr> teythoon: what do you want to do ? + <teythoon> i'm currently reading up on the vm system, any pointers ? + <braunr> teythoon: but what do you want to achieve here ? + <braunr> 12:24 < teythoon> so i need to map it instead ? + <teythoon> i'm trying to do what you said the other day, create a different + map to back the ramdisk + <braunr> no + <teythoon> no ? + <braunr> i said an object, not a map + <braunr> but it means a complete rework + <teythoon> ok + <teythoon> i'll head back into hurd-land then, though i'd love to see this + done properly + <braunr> teythoon: what you want basically is tmpfs as a rootfs right ? + <teythoon> sure + <teythoon> i'd need a way to populate it though + <braunr> how is it done currently ? + <teythoon> grub loads an ext2 image, then it's copied into the ramdisk + device, and used by the root translator + <braunr> how is it copied ? + <braunr> what makes use of the kernel ramdisk ? + <teythoon> in ramdisk_create, currently via memcpy + <teythoon> the ext2fs translator that provides / + <braunr> ah so it's a kernel device like hd0 ? + <teythoon> yes + <braunr> hm ok + <braunr> then you could create an anonymous memory object in the kernel, + and map read/write requests to object operations + <braunr> the object must not be mapped in the kernel though, only temporary + on reads/writes + <teythoon> right + <teythoon> so i'd not use memcpy, but one of the mach functions that copy + stuff to memory objects ? + <braunr> i'm not sure + <braunr> you could simply map the object, memcpy to/from it, and unmap it + <teythoon> what documentation should i read ? + <braunr> vm/vm_map.h for one + <teythoon> i can only find stuff describing the kernel interface to + userspace + <braunr> vm/vm_kern.h may help + <braunr> copyinmap and copyoutmap maybe + <braunr> hm no + <teythoon> vm_map.h isn't overly verbose :( + <braunr> vm_map_enter/vm_map_remove + <teythoon> ah, i actually tried vm_map_enter + <braunr> look at the .c files, functions are described there + <teythoon> that leads to funny results + <braunr> vm_map_enter == mmap basically + <braunr> and vm_object.h + <teythoon> panic: kernel thread accessed user space! + <braunr> heh :) + <teythoon> right, i hoped vm_map_enter to be the in-kernel equivalent of + vm_map + + <teythoon> braunr: uh, it worked + <braunr> teythoon: ? + <teythoon> weird + <teythoon> :) + <braunr> teythoon: what's happening ? + <teythoon> i refined the ramdisk patch, and it seems to work + <teythoon> not sure if i got it right though, i'll paste the patch + <braunr> yes please + <teythoon> http://paste.debian.net/81376/ + <braunr> no it can't work either + <teythoon> :/ + <braunr> you can't map the complete object + <teythoon> (amusingly it does) + <braunr> you have to temporarily map the pages you want to access + <braunr> it does for the same obscure reason the previous code worked on + qemu + <teythoon> ok, i think i see + <braunr> increase the size a lot more + <braunr> like 512M + <braunr> and see + <braunr> you could also use the kernel debugger to print the kernel map + before and after mapping + <teythoon> how ? + <braunr> hm + <braunr> see show task + <braunr> maybe you can call the in kernel function directly with the kernel + map as argument + <teythoon> which one ? + <braunr> the one for "show task" + <braunr> hm no it shows threads, show map + <braunr> and show map crashes on darnassus .. + <teythoon> here as well + <braunr> ugh + <braunr> personally i'd use something like vm_map_info in x15 + <braunr> but you may not want to waste time with that + <braunr> try with a bigger size and see what it does, should be quick and + simple enough + <teythoon> right + <teythoon> braunr: ok, you were right, mapping the entire object fails if + it is too big + <braunr> teythoon: fyi, kmem_alloc and vm_map have some common code, namely + the allocation of an virtual area inside a vm_map + <braunr> kmem_alloc requires a kernel map (kernel_map or a submap) whereas + vm_map can operate on any map + <braunr> what differs is the backing store + <teythoon> braunr: i believe i want to use vm_object_copy_slowly to create + and populate the vm object + <teythoon> for that, i'd need a source vm_object + <teythoon> the data is provided as a multiboot_module + <braunr> kmem_alloc backs the virtual range with wired down physical memory + <braunr> whereas vm_map maps part of an object that is usually pageable + <teythoon> i see + <braunr> and you probably want your object to be pageable here + <teythoon> yes :) + <braunr> yes object copy functions could work + <braunr> let me check + <teythoon> what would i specify as source object ? + <braunr> let's assume a device write + <braunr> the source object would be where the source data is + <braunr> e.g. the data provided by the user + <teythoon> yes + <teythoon> trouble is, i'm not sure what the source is + <braunr> it looks a bit complicated yes + <teythoon> i mean the boot loader put it into memory, not sure what mach + makes of that + <braunr> i guess there already are device functions that look up the object + from the given address + <braunr> it's anonymous memory + <braunr> but that's not the problem here + <teythoon> so i need to create a memory object for that ? + <braunr> you probably don't want to populate your ramdisk from the kernel + <teythoon> wire it down to the physical memory ? + <braunr> don't bother with the wire property + <teythoon> oh ? + <braunr> if it can't be paged out, it won't be + <teythoon> ah, that's not what i meant + <braunr> you probably want ext2fs to populate it, or another task loaded by + the boot loader + <teythoon> interesting idea + <braunr> and then, this task will have a memory object somewhere + <braunr> imagine a task which sole purpose is to embedd an archive to + extract into the ramdisk + <teythoon> sweet, my thoughts exactly :) + <braunr> the data section of a program will be backed by an anonymous + memory object + <braunr> the problem is the interface + <braunr> the device interface passes addresses and sizes + <braunr> you need to look up the object from that + <braunr> but i guess there is already code doing that in the device code + somewhere + <braunr> teythoon: vm_object_copy_slowly seems to create a new object + <braunr> that's not exactly what we want either + <teythoon> why not ? + <braunr> again, let's assume a device_write scenario + <teythoon> ah + <braunr> you want to populate the ramdisk, which is merely one object + <braunr> not a new object + <teythoon> yes + <braunr> teythoon: i suggest using vm_page_alloc and vm_page_copy + <braunr> and vm_page_lookup + <braunr> teythoon: perhaps vm_fault_page too + <braunr> although you might want wired pages initially + <braunr> teythoon: but i guess you see what i mean when i say it needs to + be reworked + <teythoon> i do + <teythoon> braunr: aww, screw that, using a tmpfs is much nicer anyway + <teythoon> the ramdisk strikes again ... + <braunr> teythoon: :) + <braunr> teythoon: an extremely simple solution would be to enlarge the + kernel map + <braunr> this would reduce the userspace max size to ~1.7G but allow ~64M + ramdisks + <teythoon> nah + <braunr> or we could reduce the kmem_map + <braunr> i think i'll do that anyway + <braunr> the slab allocator rarely uses more than 50-60M + <braunr> and the 64M remaining area in kernel_map can quickly get + fragmented + <teythoon> braunr: using a tmpfs as the root translator won't be straight + forward either ... damn the early boostrapping stuff ... + <braunr> yes .. + <teythoon> that's one of the downsides of the vfs-as-namespace approach + <braunr> i'm not sure + <braunr> it could be simplified + <teythoon> hm + <braunr> it could even use a temporary name server to avoid dependencies + <teythoon> indeed + <teythoon> there's even still the slot for that somewhere + <antrik> braunr: hm... I have a vague recollection that the fixed-sized + kmem-map was supposed to be gone with the introduction of the new + allocator?... + <braunr> antrik: the kalloc_map and kmem_map were merged + <braunr> we could directly use kernel_map but we may still want to isolate + it to avoid fragmentation + +See also the discussion on [[gnumach_memory_management]], *IRC, freenode, +\#hurd, 2013-01-06*, *IRC, freenode, #hurd, 2014-02-11* (`KENTRY_DATA_SIZE`). + + ### IRC, freenode, #hurd, 2012-07-17 <bddebian> OK, here is a stupid question I have always had. If you move @@ -725,7 +1016,133 @@ A similar problem is described in * <http://gelato.unsw.edu.au/IA64wiki/UserLevelDrivers> + +## The Anykernel and Rump Kernels + * [Running applications on the Xen Hypervisor](http://blog.netbsd.org/tnf/entry/running_applications_on_the_xen), Antti Kantee, 2013-09-17. [The Anykernel and Rump Kernels](http://www.netbsd.org/docs/rump/). + + +### IRC, freenode, #hurd, 2014-02-13 + + <cluck> is anyone working on getting netbsd's rump kernel working under + hurd? it seems like a neat way to get audio/usb/etc with little extra + work (it might be a great complement to dde) + <braunr> noone is but i do agree + <braunr> although rump wasn't exactly designed to make drivers portable, + more subsystems and higher level "drivers" like file systems and network + stacks + <braunr> but it's certainly possible to use it for drivers to without too + much work + <curious_troll> cluck: I am reading about rumpkernels and his thesis. + <cluck> braunr: afaiu there is (at least partial) work done on having it + run on linux, xen and genode [unless i misunderstood the fosdem'14 talks + i've watched so far] + <cluck> "Generally speaking, any driver-like kernel functionality can be + offered by a rump server. Examples include file systems, networking + protocols, the audio subsystem and USB hardware device drivers. A rump + server is absolutely standalone and running one does not require for + example the creation and maintenance of a root file system." + <cluck> from http://www.netbsd.org/docs/rump/sptut.html + <braunr> cluck: how do they solve resource sharing problems ? + <cluck> braunr: some sort of lock iiuc, not sure if that's managed by the + host (haven't looked at the code yet) + <braunr> cluck: no, i mean things like irq sharing ;p + <braunr> bus sharing in general + <braunr> netbsd has a very well defined interface for that, but i'm + wondering what rump makes of it + <cluck> braunr: yes, i understood + <cluck> braunr: just lacking proper terminology to express myself + <cluck> braunr: at least from the talk i saw what i picked up is it behaves + like netbsd inside but there's some sort of minimum support required from + the "host" so the outside can reach down to the hw + <braunr> cluck: rump is basically glue code + <cluck> braunr: but as i've said, i haven't looked at the code in detail + yet + <cluck> braunr: yes + <braunr> but host support, at least for the hurd, is a bit more involved + <braunr> we don't merely want to run standalone netbsd components + <braunr> we want to make them act as real hurd servers + <braunr> therefore tricky stuff like signals quickly become more + complicated + <braunr> we also don't want it to use its own RPC format, but instead use + the native one + <cluck> braunr: antti says required support is minimal + <braunr> but again, compared to everything else, the porting effort / size + of reusable code base ratio is probably the lowest + <braunr> cluck: and i say we don't merely want to run standalone netbsd + components on top of a system, we want them to be our system + <cluck> braunr: argh.. i hate being unable to express myself properly + sometimes :| + <cluck> ..the entry point?! + <braunr> ? + <cluck> dunno what to call them + <braunr> i understand what you mean + <braunr> the system specific layer + <braunr> and *againù i'm telling you our goals are different + <cluck> yes, anyways.. just a couple of things, the rest is just C + <braunr> when you have portable code such as found in netbsd, it's not that + hard to extract it, create some transport between a client and a server, + and run it + <braunr> if you want to make that hurdish, there is more than that + <braunr> 1/ you don't use tcp, you use the native microkernel transport + <braunr> 2/ you don't use the rump rpc code over tcp, you create native rpc + code over the microkernel transport (think mig over mach) + <braunr> 3/ you need to adjust how authentication is performed (use the + auth server instead of netbsd internal auth mechanisms) + <braunr> 4/ you need to take care of signals (if the server generates a + signal, it must correctly reach the client) + <braunr> and those are what i think about right now, there are certainly + other details + <cluck> braunr: yes, some of those might've been solved already, it seems + the next genode release already has support for rump kernels, i don't + know how they went about it + <cluck> braunr: in the talk antii mentions he wanted to quickly implement + some i/o when playing on linux so he hacked a fs interface + <cluck> so the requirements can't be all that big + <cluck> braunr: in any case i agree with your view, that's why i found rump + kernels interesting in the first place + <braunr> i went to the presentation at fosdem last year + <braunr> and even then considered it the best approach for + driver/subsystems reuse on top of a microkernel + <braunr> that's what i intend to use in propel, but we're far from there ;p + <cluck> braunr: tbh i hadn't paid much attention to rump at first, i had + read about it before but thought it was more netbsd specific, the genode + mention piked my interest and so i went back and watched the talk, got + positively surprised at how far it has come already (in retrospect it + shouldn't have been so unexpected, netbsd has always been very small, + "modular", with clean interfaces that make porting easier) + <braunr> netbsd isn't small at all + <braunr> not exactly modular, well it is, but less than other systems + <braunr> but yes, clean interfaces, explicitely because their stated goal + is portability + <braunr> other projects such as minix and qnx didn't wait for rump to reuse + netbsd code + <cluck> braunr: qnx and minix have had money and free academia labor done + in their favor before (sadly hurd doesn't have the luck to enjoy those + much) + <cluck> :) + <braunr> sure but that's not the point + <braunr> resources or not, they chose the netbsd code base for a reason + <braunr> and that reason is portability + <cluck> yes + <cluck> but it's more work their way + <braunr> more work ? + <cluck> with rump we'd get all those interfaces for free + <braunr> i don't know + <braunr> not for free, certainly not + <cluck> "free" + <braunr> but the cost would be close to as low as it could possibly be + considering what is done + <cluck> braunr: the small list of dependencies makes me wonder if it's + possible it'd build under hurd without any mods (yes, i know, very + unlikely, just dreaming here) + <braunr> cluck: i'd say it's likely + <youpi> I quickly tried to build it during the talk + <youpi> there are PATH_MAX everywhere + <braunr> ugh + <youpi> but maybe that can be #defined + <youpi> since that's most probably for internal use + <youpi> not interaction with the host diff --git a/open_issues/virtualization/fakeroot.mdwn b/open_issues/virtualization/fakeroot.mdwn index f9dd4756..7856e299 100644 --- a/open_issues/virtualization/fakeroot.mdwn +++ b/open_issues/virtualization/fakeroot.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -65,3 +66,1224 @@ License|/fdl]]."]]"""]] < youpi> that's why we still use fakeroot-sysv < teythoon> right < youpi> err, -tcp + + +## IRC, freenode, #hurd, 2013-11-18 + + <teythoon> I believe I figured out the argv[0] issue with fakeroot-hurd + <teythoon> but I'm not sure how to fix this + <teythoon> first of all, Emilios file_exec_file_name patch set works fine + <teythoon> but not with fakeroot + <teythoon> + http://git.sceen.net/hurd/hurd.git/blob/HEAD:/exec/hashexec.c#l300 + <teythoon> check_hashexec tries to locate the script file using a heuristic + <teythoon> Emilios patch improves the situation with just providing this + information + <teythoon> but then, the identity port of the "discovered" file is compared + with the id port of the script file + <teythoon> to verify if the heuristic found the right file + <teythoon> but when using fakeroot-hurd, /hurd/fakeroot proxies all + requests + <teythoon> but the exec server is outside of the /hurd/fakeroot + environment, so it gets the id port from the real filesystem + <teythoon> we could skip that test if the script name is explicitly + provided though + <teythoon> that test was meant to see whether a search through $PATH turned + up the right file + <braunr> teythoon: nice + <teythoon> braunr: thanks :) + <teythoon> unfortunately, dpkg-buildpackaging hurd with it still fails for + some reason + <teythoon> but it is faster than fakeroot-tcp :) + <braunr> even chown ? + <braunr> or chmod ? + <teythoon> dunno in detail, but the whole build is faster + <braunr> if you can try it, i'm interested + <braunr> because chown/chmod is also slow on linux with fakeroot-tcp + <teythoon> i can try... + <braunr> so it's probably not a hurd bug + <teythoon> braunr: yes, it really is + <braunr> no i mean + <braunr> chown/chmod being slow with fakeroot-tcp is probably not a hurd + bug + <braunr> but a fakeroot-tcp bug + <teythoon> chowning all files in /usr/bin takes 5.930s with fakeroot-hurd + (6.09 with startup overhead) vs 26.42s (26.59s) with fakeroot-tcp + <braunr> but try it on linux (fakeroot-tcp i mean) + <braunr> although you may want to do it on something you don't care much + about :p) + + +## IRC, freenode, #hurd, 2013-12-03 + + * teythoon is gonna hunt a fakeroot bug ... + <teythoon> % fakeroot-hurd /bin/sh -c ":> /tmp/some_file" + <teythoon> /bin/sh: 1: cannot create /tmp/some_file: Is a directory + <braunr> ah fakeroot-hurd + <teythoon> prevents installing stuff with /bin/install + <teythoon> sure fakeroot-hurd, why would i work on the slow one ? + <braunr> i don't know + <braunr> because it makes chmod/chown/maybe others horrenddously slow + <braunr> ? + <teythoon> yes, fixing this involves fixing fakeroot-hurd + <braunr> are you sure ? + <braunr> i prefer repeating just in case: i saw that problem on linux as + well + <braunr> with fakeroot-sysv + <teythoon> so ? + <braunr> i'm almost certain it's a pure fakeroot bug, not a hurd bug + <braunr> so + <teythoon> even if this is fixed, it still has to pay the socket + communication overhead + <braunr> fixing fakeroot-hurd so that i can be used instead of fakeroot-tcp + is a very good thing to do, obviously + <braunr> it* + <braunr> but it won't solve the chown/chmod speed + <braunr> (or, probably won't) + <teythoon> huh, why not ? + <braunr> 15:53 < braunr> i'm almost certain it's a pure fakeroot bug, not a + hurd bug + <braunr> when i say it's slow, i should be more precise + <braunr> it doesn't show up in top + <teythoon> yes, but why would fakeroot-hurd suffer from the same issue ? + <braunr> the cpu is almost idle + <braunr> oh right, it's a completely different tool + <braunr> my bad + <braunr> right, right, the proper way to implement fakeroot actually :) + <teythoon> yes + <teythoon> this will bring near-native speed + + +## IRC, freenode, #hurd, 2013-12-05 + + <teythoon> fakeroot-hurd just successfully built mig :) + <teythoon> hangs in dh_gencontrol when building gnumach or hurd though + <teythoon> i believe it hangs waiting for a lock + <teythoon> lock like in file lock that is + <teythoon> braunr: no more room for vm_map_find_entry in 80220a40 + <teythoon> 80220a40 <- is that a task ? + <braunr> or a vm_map, not sure + <braunr> probably a vm_map + + +## IRC, freenode, #hurd, 2013-12-06 + + <teythoon> well, aren't threads a source of endless entertainment ... ? + <teythoon> well, I found three more bugs in fakeroot-hurd + <teythoon> one of them requires fixing the locking used in fakeroot + <braunr> ouch + <teythoon> the current code does some lock cycling to aquire a lock out of + order + <braunr> cycling ? + <teythoon> in the netfs_node_norefs function + <teythoon> release and reaquire + <braunr> i see + <teythoon> which imho should be better solved with a weak reference + <teythoon> working on it, it no longer deadlocks but i broke something else + ... + <teythoon> endless fun ;) + <braunr> such things could have been done right in the beginning + <braunr> ... + <teythoon> yes, I wonder + <teythoon> libports has weak references + <teythoon> but pflocal is the only user + <braunr> hm + <teythoon> none of the lib*fs support that + <braunr> didn't i add one in libdiskfs too ? + <braunr> anyway, irrelevant + <braunr> weak references are a nice feature + <braunr> teythoon: i don't see the cycling you mentioned + <braunr> only netfs_node_refcnt_lock being dropped temporarily + <teythoon> yep, that one + <teythoon> line 145 + <teythoon> note that due to another bug this code is currently never run + <braunr> how surprising .. + <braunr> the note about some leak actually gave a hint about that + <teythoon> yeah, that leak + <teythoon> I think i'm actually very close + <teythoon> it's just so frustrating, i thought i got it last night + <braunr> good luck then + <teythoon> thanks :) + + +## IRC, freenode, #hurd, 2013-12-09 + + <teythoon> sweet, i fixed fakeroot-hurd :) + <braunr> /clap + <braunr> what was the problem ? + <teythoon> lots + <braunr> i see + <teythoon> it's amazing it actually run as well as it did + <braunr> mess strikes again + <braunr> i hate messy code .. + * teythoon is building half a hurd package using this ... stay tuned ;) + <azeem> teythoon: is this going to make building faster as well? + <teythoon> most likely, yes + <teythoon> fakeroot-tcp is known to be slow, even on linux + <braunr> teythoon: are you sure about the transparent retry patch ? + <teythoon> pretty sure, why ? + <braunr> it's about a more general issue that we didn't fix yet + <braunr> our last discussions about it lead us to agree that clients should + check the identity of a server before interacting with it + <teythoon> braunr: i don't understand, what's the problem here ? + <braunr> teythoon: fakeroot does the lookup itself, doesn't it ? + <teythoon> yes + <braunr> teythoon: but was that also the case before your patch ? + <teythoon> braunr: yes + <braunr> teythoon: then ok + <braunr> teythoon: i guess fakeroot handles requests only for a specific + set of calls right ? + <braunr> and for others, requests are directly relayed + <teythoon> braunr: yes + <braunr> and that still is the case, right ? + <teythoon> yes + <braunr> ok + <braunr> looks right since it only affects lookups + <braunr> ok then + <teythoon> well, fakeroot-hurd built half a hurd package in less than 70 + minutes + <teythoon> a new record for my box + <braunr> compared to how much before ? + <braunr> (and why half of it ?) + <teythoon> unfortunately it hung after signing the packages... some perl + process with a /usr/bin/tee child + <teythoon> killing tee made it succeed though + <teythoon> braunr: i don't build the udeb package + <braunr> oh ok + <teythoon> braunr: compared with ~75 with fakeroot-tcp and my demuxer + rework, ~80 before + <braunr> teythoon: nice + + +## IRC, freenode, #hurd, 2013-12-18 + + <teythoon> there, i fixed the last fakeroot-hurd bug + <teythoon> *whee* :) + <teythoon> i thought so many times that i got the last fakeroot bug ... + <teythoon> last as in it's in a good enough shape to compile the hurd + package that is + <teythoon> but now it is + <braunr> :) + <braunr> this will make glibc and others so much faster to build + + +## IRC, freenode, #hurd, 2013-12-19 + + <braunr> teythoon_: hum, you should make the behaviour of fakeroot-hurd on + the last client exiting optional + <teythoon_> y? + <teythoon_> fakeroot-tcp does the very same thing + <braunr> fakeroot-hurd is different + <braunr> it's part of the file system + <teythoon_> yes + <braunr> users may want it to stay around + <braunr> and reuse it without checking it's actually there + <teythoon_> but once the last client is gone, who is ever getting another + port to it ? + <teythoon_> no + <teythoon_> that cannot happen + <braunr> really ? + <teythoon_> yes + <braunr> i thought it was like remap + <braunr> since remap is based on it + <teythoon_> the same thing applies to remap + <teythoon_> only settrans has the control port + <braunr> hum + <teythoon_> and uses it once to get a protid for the working dir of the + initial process started inside the chrooted environment + <braunr> you may not want to chroot inside + <teythoon_> so ? + <teythoon_> then, you get another protid + <braunr> i'll make an example + <braunr> i create a myroot directory implemented by fakeroot + <braunr> populate it + <braunr> leave and do something else, + <braunr> i might want to return to it later + <teythoon_> ah + <teythoon_> ok, so you are not using settrans --chroot + <braunr> or maybe i'm confusing the fakeroot translator and fakeroot-hurd + <braunr> 10:48 < braunr> you may not want to chroot inside + <braunr> yes + <teythoon_> hm + <teythoon_> ok, so the patch could be changed to check whether the last + control port is gone too + <braunr> i have no idea of any practical use, but i don't see a valid + reason to make a translator go away just because it has no client + <braunr> except for resource usage + <braunr> and if it's installed as a passive translator + <braunr> although that would make fakeroot loose its state + <braunr> though remap state is on the command line so it would be fine for + it + <braunr> see what i mean ? + <teythoon_> yes i do + <braunr> fakeroot state could be saved in some db one day so it may apply, + if anyone feels the need + <teythoon_> so what about checking for control ports too ? + <braunr> i'm not too familiar with those + <braunr> who has the control port of a passive translator ? the parent ? + <teythoon_> that should cover the use case you described + <teythoon_> for the parent translator + <teythoon_> for fsys_getroot requests it has to keep it around + <teythoon_> and for more fsys stuff too + <braunr> and if active ? settrans ? who just looses it ? + <teythoon_> if settrans is used to start an active translator, the parent + fs still gets a right to the control port + <braunr> ok + <braunr> i don't have a clear view of what this implies for fakeroot-hurd + <braunr> we'd want fakeroot-hurd to clean all resources including the + fakeroot translator on exit + <teythoon_> for fakeroot-hurd (or any child translator) this means that a + port from the control port class will still exists + <teythoon_> so we do not exit + <teythoon_> oh, you're speaking of fakeroot.sh ? the wrapper script ? + <braunr> probably + <braunr> for me, fakeroot-hurd is the command line too, similar to + fakeroot-sysv and fakeroot-tcp + <braunr> and fakeroot is the translator + <teythoon_> yes, agreed + <teythoon_> fakeroot-hurd could use settrans --force --chroot ... to force + fakeroot to exit if the main chrooted process dies + <teythoon_> but that'd kill anything that outlives that process + <teythoon_> that might be legitimate, say a process daemonized + <teythoon_> so detecting that noone uses fakeroot is the much cleaner + solution + <braunr> ok + <teythoon_> also, that's what fakeroot-tcp does + <braunr> which is why i suggested an option for that + <teythoon_> why add an option if we can do the right thing without + troubling the user ? + <braunr> ah, if we can, good + <teythoon_> i think we can + <teythoon_> I'll rework the patch, thanks for the hint + <braunr> so + <braunr> just to be clear + <braunr> the way you intend it to work is + <braunr> wait for all clients and the control port to drop before shutting + down + <braunr> the control port is dropped when dettaching the translator, right + ? + <teythoon_> yes + <braunr> but hm + <braunr> what if clients spawn other processes ? + <braunr> they won't find the translator any more + <teythoon_> then, that client get's a port to fakeroot at least for it's + working dir + <teythoon_> so another protid is created + <braunr> ah yes, it's usually choorted for such uses + <braunr> chrooted + <teythoon_> so fakeroot will stick around + <braunr> but clients, even from fakeroot, might simply use absolute paths + <teythoon_> so ? + <braunr> in which case they won't find fakeroot + <teythoon_> it will hit fakeroots dir_lookup + <teythoon_> sure + <braunr> how so ? + <teythoon_> if the path is absolute, it will trigger a magic retry of some + kind + <teythoon_> so the client uses it's root dir port + <braunr> i thought the lookup would be done straight from the root fs port + .. + <teythoon_> which points to fakeroot of course + <braunr> ah, chrooted again + <teythoon_> that's the whole point + <braunr> so this implies clients are chrooted + <teythoon_> they are + <teythoon_> even if you do another chroot + <braunr> what i mean is + <teythoon_> that root port also points to a fakeroot port + <braunr> if we detach the translator, and clients outside the chroot spawn + processes, say shell scripts, they won't find the fakeroot tree + <braunr> now, i wonder if we want to actually handle that + <braunr> i'm just uncomfortable with a translator silently shutting down + because it has no client + <teythoon_> if fakeroot is detached, how are clients outside the chroot + ever supposed to get a handle to files inside the fakerooted env ? + <braunr> it makes sense for fakeroot, so the expected behaviours here aer + conflicting + <braunr> they had those before fakeroot being detached + <teythoon_> then fakeroot wouldn't go away + <braunr> right + <braunr> unless there is a race but i don't think there is + <teythoon_> there isn't + <teythoon_> i call netfs_shutdown + <braunr> clients get the rights before the parent has a chance to terminate + <teythoon_> and only shutdown if it doesn't return ebusy + <braunr> makes sense + <braunr> ok go ahead :) + <teythoon_> cool, thanks for the walk-through ;) + <braunr> on the other hand .. + <braunr> that's a complicated topic left unfinished by the original authors + <teythoon_> one of many + <braunr> having translators automatically go away when there is no client + may be a good feature + <braunr> but it only makes sense for passive translators + <braunr> and this should be automated + <braunr> the lib*fs libraries should be able to handle it + <teythoon_> or, we could go for proper persistence instead + <braunr> stay around if active, leave after a while when no more clients if + passive + <braunr> why ? + <teythoon_> clean solution + <braunr> persistence looks much more expensive to me + <teythoon_> other benefits + <braunr> i mean + <braunr> persistence looks so expensive it doesn't make sense in a general + purpose system + <teythoon_> sure, we could make our *fs libs handle this smarter at a much + lower cost + <teythoon_> don't we get a handle to the underlying file ? + <braunr> i think we do yes + <teythoon_> if that's actually a file and not a directory, we could store + data into it + <braunr> many translators are read-only + <teythoon_> so ? + <braunr> well, when we can write, we can use passive translators instead + <braunr> normally + <teythoon_> yes + <braunr> depends on the fs type actually but you're right, we could use + regular files + <braunr> or a special type of file, i don't know + <antrik> braunr: BTW, I agree that active translators should only go away + when no ports are open anymore, while passive ones can exit when control + ports are still open but no protids + <teythoon> antrik: you mean as a general rule ? + <teythoon> that leaves the question how the translator distinguishes + between having a passive translator record and not having one + <antrik> I believe I already arrived at that conclusion in some design + discussion, probaly regarding namespace-based translator selection + <antrik> teythoon: yeah, as a general rule + <teythoon> interesting + <antrik> currently there are command line arguments controling timeouts, + but they don't consider control ports IIRC + <teythoon> i thought there are problems with shutting down translators in + general + <antrik> (also, command line arguments seem inconvenient to distinguish the + passive vs. active case...) + <teythoon> yeah, but we disregard the timeouts in the debian flavor of hurd + <antrik> teythoon: err... no we don't. at least not last time I knew. are + you confusing this with thread timeouts? + <antrik> simple test: do ls -l on /dev, wait a few minutes, compare + <teythoon> what do you expect will happen ? + <antrik> the unused translators should go away + <teythoon> no + <antrik> that must be new then + <teythoon> might be, yes + <teythoon> + http://darnassus.sceen.net/gitweb/teythoon/packaging/hurd.git/blame/HEAD:/debian/patches/libports_stability.patch + <braunr> antrik: debian currently disables both the global and thread + timeouts in libports + <braunr> my work on thread destruction consists in part in reenabling + thread timeouts, and my binary packages do that well so far :) + <antrik> braunr: any idea why the global timeouts were disabled? + + +## IRC, freenode, #hurd, 2013-12-20 + + <braunr> antrik: not sure + <braunr> but i suspect there could be races + <braunr> if a message arrives while the server is going away, i'm not sure + the client can determine this and retry transparently + <antrik> good point... not sure how that is supposed to work exactly + + +## IRC, freenode, #hurd, 2013-12-31 + + <braunr> btw, we should remove the libports_stability patch and directly + change the upstream code + <braunr> if you agree, i can force the global timeout to 0 (because we're + still not sure what can go wrong when a translator goes away while a + message is being delivered to it) + <braunr> i didn't experience any slowdown with thread destruction however + <braunr> so i'm tempted to set that to an actual reasonable timeout value + of 30-300 seconds + <teythoon> braunr: if you do, please introduce a macro for the default + value so it can be changed easily + <braunr> teythoon: yes + <braunr> i don't understand why these are left as parameters tbh + <teythoon> true + <braunr> 30 seconds seems to be plenty enough + + +## IRC, freenode, #hurd, 2014-01-17 + + <braunr> time to give fakeroot-hurd a shot + <braunr> http://darnassus.sceen.net/~rbraun/darnassus_fakeroot_hurd_assert + <teythoon> braunr: (wrt fakeroot-hurd) well in my book that shouldn't + happen + <teythoon> that's why i put the assertion there ;) + <braunr> i assumed so :) + <teythoon> then again, /me does not agree with "threads" as concurrency + model >,<, and that feeling seems to be mutual :p + <braunr> ? + <teythoon> well, obviously, the threads do not agree with me wrt to that + assertion + <braunr> the threads ? + <teythoon> well, fakeroot is a multithreaded server + <braunr> teythoon: i'm not sure i get the point, are you saying you're not + comfortable with threads ? + <teythoon> that's exactly what i'm saying + <braunr> ok + <braunr> coroutines/functional i guess ? + <teythoon> csp + <teythoon> functional not so much + + +## IRC, freenode, #hurd, 2014-01-20 + +[[open_issues/libpthread]], +[[open_issues/libpthread/t/fix_have_kernel_resources]]. + + <braunr> teythoon: it's perfectly possible that the bug i had with + fakeroot-hurd have been caused by my own glibc thread related patches + <braunr> has* + <teythoon> ok + <teythoon> *phew* :p + <braunr> :) + <teythoon> i wonder if youpi could reproduce his issue on his machine + <braunr> what issue ? + <braunr> i must have missed something + <teythoon> some package failed + <teythoon> but he didn't gave any details + <teythoon> he wanted to try it on his vm first + <braunr> ok + + +## IRC, freenode, #hurd, 2014-01-21 + + <braunr> teythoon: i still get the same assertion failure with + fakeroot-hurd + <braunr> will take a look at that sometimes too + <teythoon> braunr: hrm :/ + <braunr> teythoon: don't worry, i'm sure it's nothing big + <braunr> in the mean time, there are updated hurd and glibc packages on my + repository with fixed tls and thread destruction + <teythoon> cool :) + + +## IRC, freenode, #hurd, 2014-01-23 + + <braunr> teythoon: can you briefly explain this fake reference thing in + fakeroot when you have some time please ? + <teythoon> braunr: fakeroot creates ports to hand out to clients + <teythoon> every port represents a node and references a real node + <teythoon> fakeroot allows one to set attributes, e.g. file permissions on + any node as if the client was root + <teythoon> those faked attributes are stored in the node objects + <braunr> let's focus on fake_reference please + <teythoon> once some attribute is faked, that node has to be kept alive + <teythoon> otherwise, that faked information is lost + <teythoon> so if the last peropen object is closed and some information is + faked, a fake reference is kept + <teythoon> as indicated by a flag + <braunr> hm + <teythoon> in dir lookup, if a node is looked-up that has a fake reference, + it is recycled, i.e. the flag cleared and the referecne count is not + incremented + <teythoon> so every time fakeroot_netfs_release_protid is called b/c, the + node in question should not have the fake reference flag set + <braunr> what's the relation between the number of hard links and this fake + reference ? + <teythoon> i don' + <teythoon> i don't think fakeroot has a notion of 'hard links' + <braunr> it does + <braunr> the fake reference is added on nodes with a hard link count + greater than 0 + <braunr> but i guess that just means the underlying node still exists + <teythoon> ah yes + <teythoon> right + <teythoon> currently, if the real node is deleted, the fake node is still + kept around + <braunr> let's say it's ok for now + <teythoon> that's what the comment is talking about, the one that indicates + that garbage collection could help here + <teythoon> yes + <teythoon> properly fixing this is difficult + <braunr> agreed + <braunr> it would require something like inotify anyway + <teythoon> b/c of the way file deletion works + <braunr> let's just ignore the issue, that's not what i'm hunting + <teythoon> agreed + <braunr> the assertion i have is telling us that we're dropping a fake + reference + <braunr> are we certain this isn't possible ? + <teythoon> that function is called if a client dereferences a port + <teythoon> in order to have a port in the first place, it has to get it + from a dir_lookup + <teythoon> the dir lookup turns a fake reference into a real one + <teythoon> so i'm certain of that (barring a race condition somewhere) + <braunr> ok + <braunr> netfs_S_dir_lookup grabs idport_ihash_lock (line 354) but doesn't + release it if nn == NULL (lines 388-392) + <teythoon> hm, my file numbers are slightly different o_O + <braunr> i have printfs around + <braunr> sorry :) + <teythoon> ok + <teythoon> new node unlocks it + <teythoon> new_node + <braunr> oh + <braunr> how unintuitive .. + <teythoon> yes, don't blame me ;) that's how it was + <braunr> :) + <braunr> worse, the description says "if successful" .. + <braunr> ah no, the node lock + <braunr> ok + <teythoon> yes, badly worded description + <braunr> i strongly doubt it's a race + <teythoon> how do you trigger that assertion failure ? + <braunr> dpkg-buildpackage -rfakeroot-hurd -uc -us + <braunr> for the hurd package + <braunr> very similar to one of your test cases i think + <teythoon> umm :-/ + <braunr> one thing that i find confusing is that fake_reference seems to + apply to nodes, whereas release_protid is about, well, protids + <braunr> is there a 1:1 relationship ? + <braunr> since there is a peropen in the protid, i assume not + <braunr> it may be a race actually + <braunr> np->references must be accessed with netfs_node_refcnt_lock locked + <braunr> hm no, that's not it + <teythoon> no, it's not a 1:1 relationship + <teythoon> note that the lock idport_ihash_lock serializes most operations, + despite it's name indicating that it's only for the hash table + <teythoon> the "interesting" operations being dir_lookup and release_protid + <braunr> yes + <braunr> again, that's another issue + <teythoon> why ? that's a pretty strong guarantee already + <braunr> ah yes, i was referring to scalability + <teythoon> sure + <braunr> the assertion is triggered from ports_port_deref in + ports_manage_port_operations_multithread + <teythoon> but i found it hard to reason about fakeroot, there are multiple + locks involved, two kinds of reference counting across different libs + <braunr> yes + <teythoon> yes, that's to be expected + <braunr> teythoon: do we agree that the fake reference is reused by a + protid ? + <teythoon> braunr: yes + <braunr> why is there a ref counter for the protid as well as the peropen + then ? :/ + <teythoon> funny... i thought there was no refcnt for the peropen objects, + but there is + <teythoon> but for fakeroot-hurd that shouldn't matter, right ? + <braunr> i don't know + <teythoon> here, one protid object is associated with one peropen object + <braunr> yes + <teythoon> and the other way around, i.e. it's 1:1 + <teythoon> so the refcount for those should be identical + <braunr> but i get a case where protid has a refcnt of 0 while the peropen + has 2 .. + <teythoon> umm, that doesn't sound right + <braunr> teythoon: ok, it does look like a race on np->references + <braunr> node references are protected by a global lock in lib*fs libs + <teythoon> yes + <braunr> you check it without holding it + <braunr> which means another protid can be closed at the same time, setting + the flag on the underlying node + <braunr> i'll make a proper patch soon + <teythoon> they cannot both hold the hash lock + <braunr> hm + <braunr> teythoon: actually, i don't see why that's relevant + <braunr> one thread closes its protid, sets the fakeref flag + <braunr> the other does the same, chokes on the assertion + <braunr> serially + <teythoon> i'm always a little fuzzy when exactly the references get + decremented + <teythoon> but shouldn't only the second thread set the fakeref flag ? + <braunr> well, that's not what i see + <braunr> i'll check what happens to this ref counter + <teythoon> see how my release_protid function calls netfs_release_protid + just after the out label + <teythoon> *while holding the big hash lock + <teythoon> so, any refcounting should happen while the lock is being held, + no ? + <braunr> perhaps + <braunr> now, my logs show something new + <braunr> a case where the protid being released was never printed before + <braunr> i.e. not obtained from dir_lookup + <braunr> or at least, not fakeroot dir_lookup + <teythoon> huh, where did it came from then ? + <braunr> no idea + <teythoon> only dir_lookup hands out those + <braunr> check_openmodes calls dir_lookup too + <teythoon> yes, but that's not our dir_lookup + <braunr> that's what i mean + <braunr> it bypasses fakeroot's custom dir_lookup + <braunr> but i guess the reference already exists at this point + <teythoon> bypass ? i wouldn't call it that + <braunr> you're right, wrong wording + <teythoon> it accesses files on other translators + <braunr> yes + <braunr> the netnode is already present + <teythoon> yes + <braunr> could it be the root node ? + <teythoon> i do not believe so + <teythoon> the root node is always faked + <teythoon> and is handed out to the first process in the fakeroot env for + it's current directory port + <teythoon> so you could try something that chdirs away to test that + hypothesis + <braunr> the assertion looks triggered by a chdir + <teythoon> how do you know that ? + <braunr> dh_auto_install: error: unable to chdir to build-deb + <teythoon> ah + <teythoon> well, or that is just the operation after fakeroot died and + completely unrelated + <braunr> maybe + <teythoon> can you trigger this reliably ? + <braunr> yes + <braunr> i'm trying to write a shell script for that + <teythoon> so for you, fakeroot-hurd never succeeded in building a hurd + package ? + <braunr> no + <teythoon> on darnassus ? + <braunr> yes + <teythoon> b/c i stopped working on fakeroot-hurd when it was in a + good-enough shape to build the hurd package + <teythoon> >,< + <teythoon> maybe my system is not fast enough to hit this race (if it turns + out to be one) + <braunr> some calls seems to decrease the refcount of the root node + <braunr> call* + <teythoon> have you confirmed that it's the root node ? + <braunr> almost + <braunr> i could say yes + <braunr> teythoon: actually no, it's not .. + <braunr> could be .. + <braunr> teythoon: on what node does fakeroot-hurd install the fakeroot + translator when used to build debian packages ? + <braunr> hum + <braunr> could it simply be that the check on np->references should be + moved above the assertion ? + <teythoon> braunr: it is not bound to any node, check settrans --chroot + <braunr> oh right + <braunr> teythoon: ok i mean + <braunr> does it shadow / ? + <braunr> looks very likely, otherwise the chroot wouldn't work + <teythoon> i'm not sure what you mean by shadow + <braunr> settrans --chroot cmd -- / /hurd/fakeroot ? + <teythoon> but yes, for any process in the chroot-like env every real node + is replaced, including / + <braunr> makes sense + <braunr> teythoon: moving the assertion seems to fix the issue + <braunr> intuitively, it seems reasonable to assume the fakeref flag can + only be set when there is only one reference, namely the fake reference + <braunr> (well, the fake ref, recycled by the last open) + <teythoon> no, i don't follow + <teythoon> i'd still say, that if ...release_protid is called, then there + is no way for the fake flag to be set in the first place + <teythoon> that's why i put the assertion in ;) + <braunr> on the other hand, you check the refcnt precisely because other + threads may have reacquired the node + <teythoon> but why would moving the assertion change anything ? + <teythoon> if we would do that, we'd "lose" all threads that see + np->reference being >1 + <teythoon> but for those objects the fake_reference flag should never be + set anyways + <teythoon> i cannot see why this would help + <teythoon> (does it help ?) + <teythoon> (and if it does, it points to a serious problem imho) + <braunr> i'm recreating the traces that made me think that + <braunr> to get a clearer view of what's happening + <braunr> the problem i have with the current code is this + <braunr> there can be multiple protid referring to the same node occurring + at the same time + <braunr> they are serialized by the hash table lock, ok + <braunr> but there apparently are cases where the first (of two) protids + being closed sets the fakeref flag + <braunr> and the following chokes because the flag is set + <braunr> i assume you put this refcount check because you assumed only the + last protid being closed can set the flag, right ? + <braunr> but then, why > 1 ? why not > 0 ? + <teythoon> yes, that's what i was trying to assert + <teythoon> b/c the 1 is our reference + <braunr> which one exactly ? + <teythoon> >1 is anyone *beside* us + <teythoon> ? + <braunr> hm + <braunr> you mean the reference held by the protid being destroyed + <teythoon> yes + <braunr> isn't that reference already dropped before calling the cleanup + function ? + <braunr> ah no, it's the node ref + <teythoon> yes + <braunr> released by netfs_release_protid + <teythoon> exactly + <braunr> which is called without the hash table lock held + <braunr> hm no + <braunr> it's locked + <braunr> damn my brain is slow today + <teythoon> i actually think that it's the combination of manual reference + counting and the primitive concurrency model that makes it hard to reason + about this + <braunr> well + <braunr> the model is quite simple too + <braunr> accesses to refcounters must be protected by the appropriate lock + <braunr> this isn't done here, on the assumption that all referencing + operations are protected by another global lock all the time + <teythoon> even if a model is simple, this does not mean that it is a good + model for human beings to comprehend and reason about + <braunr> i don't know + <braunr> note that netfs_drop_node is designed to be called with + netfs_node_refcnt_lock locked + <braunr> implying the refcount must remain stable between checking it and + dropping the node + <braunr> netfs_make_peropen is called without the hash table lock held in + dir_lookup + <braunr> and this increases the refcount + <braunr> although the problem is rather that something decreases it without + the lock held + <teythoon> we should port libtsan and just ask gcc -fsanitize=thread + <braunr> what about the netfs_nput call at the end of dir_lookup ? + <braunr> the fake ref should be set by the norefs function + <teythoon> that should not decrease the count to 0 b/c the caller holds a + reference too + <braunr> yes that's ugly + <braunr> ugh + <braunr> i'm unable to think clearly right now + <teythoon> as mentioned in the commit message, you cannot do something like + this in the norefs function + <teythoon> bbl ;) + <braunr> bye teythoon + <braunr> thanks for your time + <braunr> for when you come back : + <braunr> instead of maintaining this "fake" reference, why not assumeing + the hash table holds a reference, and simply count it + <braunr> the same way a cache does + <braunr> and drop that reference when removing a node, either to reflect + the current state of the underlying node, or because the translator is + being shut down ? + <braunr> why not assume* + <braunr> bbl too + <teythoon> sure, refactoring is definitively an option + + +## IRC, freenode, #hurd, 2014-01-24 + + <braunr> teythoon: ok, i'll take care of fakeroot + <teythoon> braunr: thanks. tbh i was a little fed up with that little + bugger >,< + <braunr> i can imagine + <braunr> considering the number of patches you've sent already + + <braunr> teythoon: are you sure about your call to fshelp_lock_init ? + <teythoon> yes, why do you ask ? + <teythoon> (the test case is given in the commit message) + <braunr> it doesn't look right to me to call "init" while the node is + potentially locked + <braunr> i noticed libdiskfs peropen release function takes care of + releasing locks + <braunr> it looks better to me + <teythoon> it's not about releasing the lock + <teythoon> it's about faking the file being closed which implicitly + releases the lock + <braunr> the file is being close + <braunr> closed + <braunr> since it's in the cleanup function + <teythoon> yes, but we keep it b/c the file has faked attributes + <teythoon> did you look at the problem description in the commit message ? + <braunr> we keep the node + <braunr> not the peropen + <teythoon> so ? + <teythoon> the lock is in the node + <braunr> why would libdiskfs do it in the peropen release then ? + <braunr> there is an inconsistency somwhere + <braunr> actually, the lock looks to be per open + <braunr> or rather, the lock is per node, but its status is recorded per + open + <braunr> allowing the implementation to track if a file descriptor was used + to install a lock and release it when that file descriptor goes away + <teythoon> why would the node be locked ? + <teythoon> locked in what way, file-locking locked ? + <braunr> yes + <braunr> posix explicitely says that file locks must be implicitely removed + when closing the file descriptor used to install them, so that makes + sense + <teythoon> isn't hat exactly what i'm doing ? + <braunr> no + <braunr> you're initializing the file lock + <braunr> init != unlock + <braunr> and it's specific to fakeroot, while it looks like libnetfs should + be doing it + <teythoon> libnetfs would do it + <teythoon> but we prevent that by keeping the node alive + <braunr> again, it's a per open thing + <braunr> and no, libnetfs doesn't release locks implicitely in the current + version + <teythoon> didn't we agree that for fakeroot one peropen object is + associated with one protid object ? + <braunr> yes + <braunr> and don't keep those alive + <braunr> so let them die peacefully, and fix libnetfs so it releases the + lock as it's supposed to + <braunr> and we* don't + <teythoon> we don't keep those alive + <teythoon> why would we ? + <braunr> yes that's what i wanted to say + <braunr> what i mean is + <braunr> since letting peropens die is already what is being done + <braunr> there is no need for a special handling of locks in fakeroot + <teythoon> oh + <braunr> on the other hand, libnetfs must be fixed + <teythoon> ok, that might very well be true + <teythoon> (we need to bring libnetfs and diskfs closer so that they can be + diff'ed easily) + <braunr> i just wanted to check your reason for using lock_init in the + first place + <braunr> yes .. + <braunr> teythoon: also, i think we actually do have what's necessary to + deal with garbage collection + <braunr> namely, dead-name notifications + <braunr> i'll see if i can cook something simple enough + <braunr> otherwise, merely keeping every node around is also acceptable + considering the use cases + <teythoon> dead-name notifications won't help if the real node disappears, + no ? + <braunr> teythoon: dead name notifications on the real node port :) + <braunr> teythoon: at least i can reliably build the hurd package using + fakeroot-hurd now + <braunr> let's try glibc :) + +## IRC, freenode, #hurd, 2014-01-25 + + <teythoon> braunr: awesome :) + <braunr> teythoon: hm not sure :/ + <braunr> darnassus got oom + <braunr> teythoon: could be unrelated though + <braunr> teythoon: something has apprently made /home unresponsive :( + <braunr> teythoon: i suspect bots hitting apache and in particular the git + repositories to have increased memory usage + + +## IRC, freenode, #hurd, 2014-01-26 + + <braunr> teythoon: btw, fakeroot interacts very very badly with other netfs + file systems + <braunr> e.g., listing /proc through it creates lots of nodes + <braunr> i'm not yet sure how to fix that + <braunr> using a dead name notification doesn't seem appropriate (at least + not directly) because fakeroot holds a true reference that prevents the + deallocation of the target node + + +## IRC, freenode, #hurd, 2014-01-27 + + <braunr> teythoon: good news (more or less): fakeroot is actually leaking a + lot when crossing file systems + <braunr> which means if i fix that, there is a good chance we can use it to + build all packages with it + <braunr> -with it + <teythoon> what do you mean exactly ? + <braunr> if target nodes are from /, there is no such leak + <braunr> as soon as the target nodes are from another file system, ports + rights are leaked + <braunr> that's what fills the kernel allocator actually + <teythoon> oh, so dir_lookup leaks ports when crossing translator + boundaries ? + <braunr> seems so + <teythoon> yeah, that might very well be it + <teythoon> the dir_lookup logic in lib*fs is quite involved :/ + <braunr> yes, my simple attempts were unsuccessful + <braunr> but i'm confident i can fix it soon + <teythoon> that sounds good :) + <braunr> i also remove the fake_ref flag and replace it with "accounting + the reference in the hash table" as soon as a node is faked + <teythoon> fine with me + <braunr> these will be the expected leak + <braunr> but they're far less in numbers than what i observe + <braunr> and garbage collection can be implemented later + <braunr> although i would prefer notifications a lot more + <braunr> end of the news, bbl :) + <braunr> found it :> + <teythoon> braunr: -v ;) + <braunr> err = dir_lookup (...); + <braunr> if (dir != dnp->nn->file) mach_port_deallocate (mach_task_self (), + dir); + <braunr> in other words, deallocate ports for intermediate file system root + directories .. :) + <braunr> teythoon: currently building hurd and glibc packages + <braunr> but i intend to improve some more with the addition of a default + faked state + <braunr> so that only nodes with modified faked states are retained + <teythoon> how do you mark nodes as having the default faked state ? + <braunr> i don't + <teythoon> ok, right, makes sense :) + <teythoon> this sounds awesome, thanks for following up on this + <braunr> i'm quite busy with other stuff so, with proper testing, it should + take me the week to get merged + <braunr> teythoon: well thanks for all the fixes you've done + <braunr> fakeroot was completely unusable before that + <teythoon> if you push your changes somewhere i'll integrate them into my + packages and test them + <braunr> ok + <braunr> implementing fakeroot -u could also be a good thing + <braunr> and this should work easily with that default faked state strategy + + +## IRC, freenode, #hurd, 2014-01-28 + + <braunr> teythoon: i should be able to test fakeroot-hurd with the default + faked attributes strategy today on glibc + <teythoon> braunr: very nice :) + <braunr> azeem_: do you happen to know if fakeroot -u is used by debian ? + <braunr> i mean when building packages + <teythoon> braunr: how does fakeroot-hurd perform on darnassus ? + <teythoon> i mean, does it yield a noticeable improvement over fakeroot-tcp + just like on my slow box ? + <braunr> i'm not measuring that :/ + <teythoon> ok, no problem + <braunr> and since nodes are removed from the hash table, performance might + decrease slightly + <braunr> but the number of rights is kept very low, as expected + <teythoon> that's good + <braunr> i keep seeing leaks though + <braunr> when switching cwd between file systems + <teythoon> humm + <braunr> so i assume something is wrong with the identity of . or .. + <braunr> it's so insignificant compared to the previous problems that i + won't waste time on that + <braunr> teythoon: the problem with measuring on darnassus is that it's a + public machine + <teythoon> right + <braunr> often scanned by ssh worms or http bots + +[[cannot_create__dev_null__interrupted_system_call]]. + + <braunr> but it makes complete sense to get better performance with + fakeroot-hurd + <braunr> that's actually one of the reasons i'm working on it + <braunr> if not the main one + <teythoon> :) + <teythoon> that was my motivation too + <braunr> it shows how you can get an interchangeable unix tool that + directly plugs well with the low level system + <braunr> and make it work better + <teythoon> nicely put :) + + <braunr> teythoon: i still can't manage to build glibc with fakeroot-hurd + <braunr> but i'm not sure why :/ + <braunr> there was no kernel memory exhaustion this time + <teythoon> :/ + <braunr> cp: cannot create regular file `debian/libc-bin.dirs': Permission + denied + <braunr> hum + <braunr> youpi: do you know if building debian packages requires fakeroot + -u option ? + <youpi> I don't know + <gg0> braunr: man dpkg-buildpackage says it just runs "fakeroot + debian/rules <target>" + <gg0> sources confirm that + http://sources.debian.net/src/dpkg/1.17.6/scripts/dpkg-buildpackage.pl#L465 + <braunr> gg0: ok + + +## IRC, freenode, #hurd, 2014-01-29 + + <braunr> it seems that something sets the permissions of this + debian/libc-bin.dirs file to 000 ... + <teythoon> i've seen this too + <braunr> oh + <braunr> do you think it's a fakeroot-hurd bug ? + <teythoon> have i mentioned something like this in a commit message ? + <teythoon> yes + <teythoon> it is + <braunr> ok + <braunr> i didn't see any mention of it + <braunr> but i could have missed it + <teythoon> hm, i cannot recall it either + <teythoon> but i've seen this issue with fakeroot-hurd + <braunr> ok + <braunr> it's probably the last issue to fix to get it to work for our + packages + <braunr> teythoon: i think i have a solution for that last mode bug + <braunr> fakeroot doesn't relay chmod requests, unless they change an + executable bit + <braunr> i don't see the point, and simply removed that condition to relay + any chmod request + <teythoon> braunr: did it work ? + <braunr> no + <braunr> fakeroot still consumes too many ports + <braunr> and for each file, there are at least two ports, the faked one, + and the real one + <braunr> it should be completely reworked + <braunr> but i don't have time to do that + <braunr> i'll see if it works when building from scratch + <braunr> actually, it's not even a quantity problem but a fragmentation + problem + <braunr> the function that fails is kmem_realloc .. + <braunr> ipc spaces are arrays in kernel space .... + <teythoon> it's more like three ports per file, you forgot the identity + port + <braunr> ah yes + + +## IRC, freenode, #hurd, 2014-02-03 + + <braunr> teythoon: i'll commit my changes on fakeroot tonight + <braunr> they do improve the tool, but not enough to build glibc with it + <teythoon> braunr: cool :), so how do we make it fully usable ? + <braunr> teythoon: i don't know .. + <braunr> i'll try re adding detection of nodes with no hard links for one + <braunr> but imho, it needs a rework based on what the real fakeroot does + <braunr> i won't work on it though + + <braunr> teythoon: also, it looks like i've tested building glibc with a + wrong test binary of my fakeroot version :/ + <braunr> so consider all test results irrelevant so far + + +## IRC, freenode, #hurd, 2014-02-04 + + <braunr> fakeroot-hurd might turn out to be easily usable for our debian + packages with the fixed binary :) + + <braunr> teythoon: hum, can you explain + 672005782e57e049c7c8f4d6d0b2a80c0df512b4 (trans: fix locking issue in + fakeroot) when you have time please ? + <braunr> it looks like it introduces a deadlock by calling new_node (which + acquires the hash table lock) while dir is locked, violating the hash + table -> node locking order + + <teythoon> braunr: awesome, then there still is hope for fakeroot-hurd :) + + <braunr> teythoon: i've been able to build glibc packages several times + this night + <braunr> so except for this deadlock i've seen once, it looks good + <teythoon> right + <teythoon> that deadlock + <teythoon> right, it does indeed violate the partial order of the locks :-/ + + <braunr> teythoon: can you explain why you moved the lock in attempt_mkfile + please ? + + <braunr> teythoon: i've just tested a fakeroot binary without the patch + introducing the deadlock, and glibc built without any problem + <teythoon> braunr: well, this is very good news :) + <braunr> teythoon: but i still wonder why you made this patch in the first + place, i don't want to revert it blindly and reintroduce a potential + regression + <teythoon> braunr: i thought i was fixing the order in which locks were + taken. if the commit message does not specify that it fixes an issue, + then i was probably just wrong and you can revert it + <braunr> oh ok + <braunr> good + + <braunr> teythoon: another successful build :) + <braunr> i'll commit my changes + <teythoon> awesome :) + <braunr> there might still be concurrency issues but it's much better + <teythoon> i'm curious what you did :) + <braunr> so little :) + <braunr> i was sick all week heh + <braunr> you'll se + <braunr> see + <teythoon> well, that's good actually ;) + <braunr> yes + + <braunr> teythoon: actually there was another debugging line left over, and + again, my test results are irrelevant @#! + + +## IRC, freenode, #hurd, 2014-02-05 + + <braunr> teythoon: i got an assertion about nn->np->nn not being equal to + nn atfer the hash table lookup is dir_lookup + <braunr> +failure + <teythoon> that's bad + <braunr> not over yet + <teythoon> i had a couple of those too + <teythoon> i guess it's a use after free + <braunr> yes + <teythoon> i used to poison the pointers and comment out the frees to track + them down iirc + <braunr> teythoon: one of your patches stores netnodes instead of nodes in + the hash table, citing some overwriting issue + <braunr> teythoon: i don't understand why using netnodes fixes this + <teythoon> braunr: libihash has this cookie for fast deletes + <teythoon> that has to be stored somewhere + <teythoon> the node structure has no room for it + <braunr> uh + <teythoon> yes + <teythoon> it was that bad + <braunr> ... + <teythoon> hence the uglyish back pointers + <braunr> i see + <teythoon> looking back i cannot even say why it worked at all + <braunr> well, it didn't + <teythoon> i believe libihash must have destroyed a linked list in the node + struct + <braunr> possibly + <teythoon> no, it did not >,<, but for simple tests it kind of did + <braunr> yes fakeroot sometimes corrupts memory badly .... + <braunr> and yes, turns out the assertion is triggered on nodes with 0 refs + .. + <braunr> teythoon: it looks like even the current version makes wrong usage + of the ihash interface + <braunr> locp_offset is defined as "The offset of the location pointer from + the hash value" + <braunr> and indeed, it's an intptr_t + <braunr> teythoon: hm no, it looks ok actually, forget what i said :) + <teythoon> *phew + <teythoon> :p + + <braunr> hmm, still occasional double frees in fakeroot, but it looks in + good shape for single threaded tasks like package building + + <braunr> teythoon: i've just sent my fakeroot patches + <teythoon> braunr: sweet, i'll have a closer look tomorrow :) + <braunr> teythoon: i couldn't debug the double frees though :/ + + +## IRC, freenode, #hurd, 2014-02-06 + + <braunr> btw, i'm able to successfully use fakeroot-hurd to build glibc + packages, but is there a way to make sure the resulting archives contain + the right privileges and ownerships ? + <youpi> I don't remember whether debdiff checks permissions + + <youpi> braunr: I've just got fakeroot-hurd debian/rules clean + <youpi> dh_clean + <youpi> fakeroot: ../../trans/fakeroot.c:161: netfs_node_norefs: Assertion + `np->nn->np == np' failed. + <youpi> while building eglibc + <teythoon> youpi: yes, that lockup is most annoying... :/ + <braunr> youpi: with the new version ? + <youpi> yes + <braunr> hum + <braunr> i only had rare double frees, not that any more :/ + <braunr> youpi: ok i got the error too + <braunr> still not good enough + <youpi> ok + + +## IRC, freenode, #hurd, 2014-02-07 + + <braunr> youpi: debdiff seems to handle permissions + <braunr> i've found the cause of the assertions + <youpi> braunr: groovie :) + + +## IRC, freenode, #hurd, 2014-02-08 + + <teythoon> braunr: nice :) + <braunr> http://darnassus.sceen.net/~rbraun/debdiff_report + + +## IRC, freenode, #hurd, 2014-02-10 + + <braunr> and, on a completely different topic, here is a crash i can + reproduce when using fakeroot: + http://darnassus.sceen.net/~rbraun/fakeroot_hurd_rpctrace_o_var_tmp_out_rm_rf_dir.png + + +## IRC, freenode, #hurd, 2014-02-11 + + <braunr> still working on fakeroot + <braunr> there are still races (not disturbing for package building but + still ..) + <braunr> there may be wrong right handling + <teythoon> i believe i have witnessed a fakeroot deadlock :/ + <braunr> aw + <teythoon> not sure though, buildbot killed the build process before i + could investigate + <braunr> teythoon: was it a big package ? + <teythoon> half of the hurd package + <braunr> that's not a port right overflow then diff --git a/open_issues/wine.mdwn b/open_issues/wine.mdwn index f8bb469b..842442f1 100644 --- a/open_issues/wine.mdwn +++ b/open_issues/wine.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010, 2011, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -78,3 +78,99 @@ allocation. There is kernel support for this,* however. and stack issues to be <gnu_srs> fixed for wine to run as braunr pointed out some months ago (IRC?) when we discussed wine. + + +# IRC, freenode, #hurd, 2013-12-29 + + <Andre_H> Hi, + http://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html seems + fixed in Debian GNU/Hurd 2013, do you know which patch they used? i + already asked in their channel, but well, there are only 18 people :) + <youpi> Andre_H: it hasn't been fixed in Debian GNU/Hurd. Work is discussed + on the bug-hurd mailing list + <Andre_H> youpi: thx for the info, i wonder why wine now works with some + hacks, but didn't in the past + <youpi> I guess some circumvention patch was added to wine + <youpi> does it actually really work, as in running applications for real? + <youpi> (I've nevere tried) + <Andre_H> youpi: i'm a wine developer and haven't seen circumventions for + hurd... i also just tried winelib apps last night, will try... let's say + powerpoint viewer today + <gnu_srs> Andre_H: How did you make wine run? I have patches for wine-1.4.1 + and 1.6.1 to build (so far unpublished), but it does not yet run + properly. + <gnu_srs> test case: wine notepad + <Andre_H> gnu_srs: what's happening when you try that? + <gnu_srs> Andre_H: Currently it hangs at connect() (after creating the + /tmp/.wine1000/.../socket, etc, and starting again) + <gnu_srs> seems to be some problem with the HURD_DPORT_USE macro in eglibc, + investigation ongoing + <Andre_H> gnu_srs: well, i'm using the debian distro, maybe you're on + something else? you could also pastebin your hacks, so i could have a + look. i'm about to clean mine up to send them upstream... ntdll will be + quite hard... + + +## IRC, freenode, #hurd, 2013-12-30 + + <gnu_srs> wine runs:) + <gnu_srs> It's just extremely slow.,.. + + <gnu_srs> gg0: please don't reopen #733604 , I've filed an updated one: + #7336045 + <gnu_srs> #733605 + <gg0> gnu_srs: i've reassigned it from wine-1.6 (nonexistent) to wine + (correct), then to src:wine (more correct), but between such + reassignments you closed it so found command in the latter made it + reopening + <gg0> then i realized you could mess up bugs on your own, without help :) + <gnu_srs> gg0: tks anyway, now it is src:wine and the title is right. Maybe + you should have noted me on IRC? + + <Andre_H> gnu_srs: what's your status about wine? i'm still about to get + things upstream... + <gnu_srs> Andre_H: see debian bug #733605 + + +## IRC, freenode, #hurd, 2013-12-31 + + <Andre_H> gnu_srs: i didn't need the patches for + dlls/mountmgr.sys/diskarb.c, maybe due to missing headers + + +## IRC, freenode, #hurd, 2014-01-06 + + <Andre_H> Wanted to note that + http://www.gnu.org/software/hurd/open_issues/wine.html is wrong about + socket credentials, afaik they are still not implemented but that doesn't + block Wine anymore + <Andre_H> In fact all you need to run Wine are the patches followed by + https://source.winehq.org/patches/data/101439 (not yet upstream) or see + http://wiki.winehq.org/Hurd + + <braunr> Andre_H: thanks for your report + <Andre_H> np :) + <Andre_H> braunr: can someone update + http://www.gnu.org/software/hurd/open_issues/wine.html please? + <braunr> Andre_H: well, you can :) + <Andre_H> log in with google -> check guidelines of your wiki -> try out + your wiki syntax -> laziness alarm :) + <gnu_srs> Andre_H: The reason why wine runs now is a bug in SCM_CREDS was + fixed, see the wine-devel ML. + + <gnu_srs> Andre_H: s/SCM_CREDS/SCM_RIGHTS/ + <Andre_H> gnu_srs: already updated our wiki :) + <Andre_H> gnu_srs: would you mind updating yours: + http://www.gnu.org/software/hurd/open_issues/wine.html :) + + <Andre_H> gnu_srs: two commits for wine are in now :) + + +## IRC, freenode, #hurd, 2014-01-11 + + <gnu_srs1> Andre_H: Looks like the two committed patches did not go into + wine-1.6.2:-( + <gnu_srs1> Additionally, your PATH_MAX fixes was not accepted? + <Andre_H> gnu_srs1: well, the stable branch is called stable because not + everything get's there :)7 + <Andre_H> gnu_srs1: the PATH_MAX patch needs more thinking... diff --git a/open_issues/xattr.mdwn b/open_issues/xattr.mdwn index 558c93b7..c6b9d8f7 100644 --- a/open_issues/xattr.mdwn +++ b/open_issues/xattr.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -43,3 +44,12 @@ IRC, OFTC, #debian-hurd, 2012-03-18: <pinotree> notes to self: it seems our ext2 driver comes from linux 2.3.42 or so, and in linux 2.5.46 ext2/ext3 get xattr and acl support + + +# Test Cases + +## IRC, freenode, #hurd, 2013-12-06: + + <gnu_srs> for fakeroot t.xattr test fails, a known issue? + <braunr> the test must probably be disabled + <braunr> the hurd doesn't support extended attributes currently diff --git a/source_repositories.mdwn b/source_repositories.mdwn index 19fec1e8..ee1166d4 100644 --- a/source_repositories.mdwn +++ b/source_repositories.mdwn @@ -40,6 +40,16 @@ These are mirrored on may provide faster anonymous accesses. +## IRC, freenode, #hurd, 2013-11-04 + + <teythoon> btw, why did you remove the savannah mirror stuff? + <braunr> there is a bug somewhere + <braunr> that is triggered by the glibc repository + <braunr> because a git pack file is too large + <braunr> i moved them to git.sceen.net + <teythoon> ok + + ## Branches Members of the [[Hurd Savannah group|rules/savannah group]] are allowed to create diff --git a/source_repositories/glibc.mdwn b/source_repositories/glibc.mdwn index 3935da05..e31fac61 100644 --- a/source_repositories/glibc.mdwn +++ b/source_repositories/glibc.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010, 2012, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2010, 2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -115,3 +115,24 @@ Occasionally push new tags from the sourceware repository to the Savannah one: $ git fetch sourceware $ git tag | grep ^glibc- | sed 's%^%tag %' | xargs git push savannah + + +# Open Issues + +## IRC, freenode, #hurd, 2013-12-13 + + <braunr> is it ok to store several patches in one topgit branch ? + <braunr> or is it really designed for one patch per branch ? + <braunr> fatal: ambiguous argument 'origin/youpi/tls-threadvar': unknown + revision or path not in the working tree. + <braunr> tschwinge: ^ + <braunr> tschwinge: does that ring a bell ? + <tschwinge> braunr: When/how did that happen? + <tschwinge> Has the branch been removed from the origin remote? + <tschwinge> Yes, has been deleted (on Savannah) on 2013-09-22. + <tschwinge> Are you somehow referencing that branch? + <braunr> tschwinge: tg remote --populate origin + <tschwinge> braunr: Then I'd guess that Samuel has removed that branch but + it is still referenced in some other branch's .topdeps file. I'll have a + look (but don't hold your breath.) + <braunr> tschwinge: sure diff --git a/system_call.mdwn b/system_call.mdwn index 16d706c7..45ed9dbe 100644 --- a/system_call.mdwn +++ b/system_call.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -33,3 +34,45 @@ system call is implemented (primarily by means of [[RPC]]) inside [[glibc]]. provide system services <braunr> e.G. open() is a call to a file system server (and maybe several actually) + + +# IRC, freenode, #hurd, 2013-11-02 + + <Hiryu> how do system calls work in the hurd? + <Hiryu> is it like in linux + <braunr> yes and no + <Hiryu> you set the number in %eax and then in0x80? + <Hiryu> int, even + <braunr> no + <braunr> but that's really a detail + <Hiryu> I'm just curious how the flow goes + <braunr> gnumach uses call gates, not interrupt gates + <braunr> but that's just another way to enter the kernel + <braunr> the mechanism itself is almost irrelevant, it matters only for + performances + <Hiryu> ah + <braunr> what's truely interesting is that there are very few system calls + <Hiryu> so it goes straight to gnumach, which then figures out where to + relay the call to? + <braunr> the main one being mach_msg + <braunr> yes + <braunr> one of the arguments to mach_msg is the name of a right + <braunr> (as file descriptors are names for open files) + <Hiryu> hmm okay, so we get to the kernel, go to a kernel server (one + context switch), then get back to the calling process, and that's 2 + context switches per system call? + <braunr> a receive right or send right + <braunr> no + <braunr> if you send-recv, it's only one + <braunr> but i'm not sure we do that on the hurd + <braunr> again, that's a detail + <Hiryu> what is send-recv? + <braunr> send and receive in the same system call + <Hiryu> hmm + <braunr> then, we also use system calls to denote the unix-like RPCs of the + hurd + <braunr> i mean + <braunr> i also call them system calls + <braunr> for example, read, write, stat, etc.. + <Hiryu> I see + <Hiryu> braunr: thanks diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn index 73982239..ebfa45a4 100644 --- a/user/jkoenig/java.mdwn +++ b/user/jkoenig/java.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 @@ -402,7 +403,7 @@ than some huge patchset). Send patches to <distro-pkg-dev@openjdk.java.net>. < jkoenig> there's a bug with java.nio when running javadoc, you might run into it. - * [[`SCM_CREDENTIALS`|open_issues/sendmsg/scm_creds]] + * [[`SCM_CREDENTIALS`|open_issues/sendmsg_scm_creds]] IRC, freenode, #hurd, 2011-08-03: |