diff options
Diffstat (limited to 'community/gsoc/project_ideas')
| -rw-r--r-- | community/gsoc/project_ideas/language_bindings.mdwn | 42 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/object_lookups.mdwn | 472 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/valgrind.mdwn | 4 |
3 files changed, 513 insertions, 5 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 88ffc633..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 @@ -69,3 +69,473 @@ In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]]. <neal> braunr: That's called protected payload. <neal> braunr: The idea is that the kernel appends data to the message in flight. + + +## IRC, freenode, #hurd, 2013-10-24 + + <teythoon> and, with some effort, getting rid of the hash table lookup by + letting the kernel provide the address of the object (iirc neil knew the + proper term for that) + <braunr> teythoon: that is a big interface change + <teythoon> how so + <braunr> optimizing libihash and libpthread should already be a good start + <braunr> well how do you intend to add this information ? + <braunr> ok, "big" is overstatement, but still, it's a low level interface + change that would probably break a lot of things + <teythoon> store a pointer in the port structure in gnumach, make that + accessible somehow + <braunr> yes but how ? + <teythoon> interesting question indeed + <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 + <teythoon> ok, so we need to provide an update path + <teythoon> but once done, the change to hurd will be minimal, patching + libports should cover most of that + <braunr> normally yes + <teythoon> so this amounts to messing with gnumach and mig and designing a + clever way to make the update process safe + + <braunr> libihash is known to show high collision rates + <teythoon> right, libihash + <teythoon> it could use an integer hash function on the keys to distribute + them better + <braunr> i think that's already what it tries to do + <braunr> so merely using a better hash algorithm such as murmur should do + the job + <braunr> or use another data structure altogether + <teythoon> no, it does no hashing of its own on the keys + <braunr> are you sure ? + <teythoon> well, it uses only prime numbers as sizes, and computes key % + size + <braunr> well that's hashing .. :) + <teythoon> but this is not really a good hash + <braunr> yes + <braunr> isn't that what i said ? + <teythoon> right + <teythoon> ok, I didn't get that ;) + <teythoon> also, the sizes start quite small, 3, 7, 19... + <teythoon> and each time the hash table is grown, all items will have to be + updated + <braunr> which is why we could consider another data structure + <teythoon> or, for starters, to thin out that list of sizes + <braunr> my personal preference being radix trees + <teythoon> I assume you have an implementation handy? + <braunr> yes + <teythoon> cool :D + <braunr> but good hashing is excellent too + <braunr> radix trees have their own issues + <teythoon> braunr: http://burtleburtle.net/bob/hash/integer.html + <braunr> i use thomas wang's hashing function in x15 + <braunr> or rather, my own personal c utility library, since x15 doesn't + hash anything currently + <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/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn index 93731dd7..37da7385 100644 --- a/community/gsoc/project_ideas/valgrind.mdwn +++ b/community/gsoc/project_ideas/valgrind.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 |