diff options
Diffstat (limited to 'community')
| -rw-r--r-- | community/gsoc.mdwn | 27 | ||||
| -rw-r--r-- | community/gsoc/2013/hacklu.mdwn | 39 | ||||
| -rw-r--r-- | community/gsoc/2013/nlightnfotis.mdwn | 53 | ||||
| -rw-r--r-- | community/gsoc/project_ideas.mdwn | 4 | ||||
| -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/perl_python.mdwn | 2 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/server_overriding.mdwn | 5 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/valgrind.mdwn | 4 | ||||
| -rw-r--r-- | community/meetings.mdwn | 6 | ||||
| -rw-r--r-- | community/meetings/fosdem_2014.mdwn | 3 | ||||
| -rw-r--r-- | community/meetings/osdi_1994.mdwn | 26 | ||||
| -rw-r--r-- | community/meetings/self-organised.mdwn | 54 |
13 files changed, 582 insertions, 155 deletions
diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index 7e355ec4..e6f07822 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -11,20 +11,20 @@ License|/fdl]]."]]"""]] [[!meta title="Google Summer of Code"]] +The Google Summer of Code 2013 is over. Chances are that we will again be +participating in 2014, stay tuned. + +<!-- We're in! The GNU Hurd project is again participating in the [Google Summer of Code](http://www.google-melange.com/) under the [GNU umbrella](http://www.gnu.org/software/soc-projects/). -<!-- - As of Monday, 2013-04-22 it's the *student application period*. This will last until [Friday, 2013-05-03](http://www.google-melange.com/gsoc/events/google/gsoc2013), which is plenty of time for preparing and discussing your applications -- but please don't wait to the last minute! ---> - This year's *student application period* is over. Thanks for sending in your applications! We're now reviewing and discussing these, so please pay attention to any questions posted on your proposal's page. The Google site's @@ -37,17 +37,24 @@ with us, be it by answering the evaluators' questions on your proposal's page, or by talking to us on the [[mailing_lists]] or on [[IRC]]. At this time, it is important for us to get a good impression about the seriousness you're showing with your application. +--> +If you intend to apply for any such projects in the future, it's a good idea to +already start perparing for it now: the sooner, the better. It is a good idea to get familiar with the GNU Hurd, by reading some of our [[documentation]], and by using a GNU/Hurd system. It is also a good idea to -send in some basic patches (this has already been mentioned in our -[[student_application_form]]), or discuss with us the principal steps you're -planning on doing in your intended work area. Of course, we don't expect you +send in some basic patches (as mentioned in our +[[student_application_form]]), and talk to us on the [[mailing_lists]] or +on [[IRC]], for example about the principal steps you're +planning on doing in your intended work area. +<!-- +Of course, we don't expect you to already start working seriously on your project, but any input you're giving us will make it easier for us to justify selectiong your specific proposal. At this time, it is not quantity that matters, and it also is not *the perfect patch* we're waiting for, but it is rather that we see how you're generally able to work with the code. +--> If you have any questions, don't be shy: please ask! Nobody expects you to know everything. Even for the long-term Hurd contributors it is common to @@ -56,16 +63,14 @@ how to do `X`, can someone please help me?* And, as we're not working next to each other in a conventional office or university setup, we'll need to establish and get used to different communication channels. -[Timeline](http://www.google-melange.com/gsoc/events/google/gsoc2013). - <!-- +[Timeline](http://www.google-melange.com/gsoc/events/google/gsoc2013). As boring as it is, but the next step is waiting: we will have to wait for Google to announce the number of slots that the whole GNU project gets, and we'll be discussing with our GNU peers about how to split these up among all the GNU subprojects. - --> @@ -75,8 +80,10 @@ We have a list of [[project_ideas]], and students are likewise encouraged to submit their own project proposals. Please follow our [[student_application_form]]. +<!-- Then, don't forget to visit <http://www.google-melange.com/>, and press the button for submitting your proposal. +--> Please read up about [[contributing]] in general, and please ask any questions you might have, on the [[mailing_lists]], or on [[IRC]], for example at one of diff --git a/community/gsoc/2013/hacklu.mdwn b/community/gsoc/2013/hacklu.mdwn index b7de141b..d3e43dd6 100644 --- a/community/gsoc/2013/hacklu.mdwn +++ b/community/gsoc/2013/hacklu.mdwn @@ -1177,23 +1177,6 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]: <hacklu> tschwinge: ok , this doesn't affect me now. If I have time I will figure out it. - <teythoon> btw, what about the copyright assignment process? - <tschwinge> teythoon, hacklu: You still haven't heard from the FSF about - your copyright assignments? What's the latest you have heard? - <hacklu> tschwinge: I have wrote a emali to ask for that, but no reply. - <teythoon> tschwinge: last and only response I got was on July 1st, the - last ping with explicit request for confirmation was on July the 12th - <tschwinge> hacklu: When did you send this email? - <hacklu> tschwinge: last week. - <tschwinge> teythoon: I suggest you send another inquiry, and please put me - in CC. And if there'S no answer within a couple days (well, I'm away - until Monday...), I'll follow up. - <tschwinge> hacklu: Likewise for you; depending on when exactly ;-) you - sent the last email. (Always allow for a few days until you exect an - answer, but if nothing happend within a week for such rather simple - administrative tasks, better ask again, unfrotunately.) - <hacklu> tschwinge:ok , I will email more - <hacklu> how to understand the asyn RPC? <braunr> hacklu: hm ? <hacklu> for instance, [hurd]/proc/main.c proc_server is loop in listening @@ -1619,25 +1602,6 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]: <youpi> I'd rather let tschwinge comment on this <hacklu> youpi: ok :) - <youpi> how about the copyright assignments? did hacklu or teythoon receive - any answer? - <teythoon> youpi: I did, the copyright clerk told me that he finally got my - papers and that everything is in order now - <youpi> few! - <youpi> s/f/ph - <youpi> teythoon: you mean all steps are supposed to be done now, or is he - doing the last steps? I don't see your name in the copyright folder yet - <teythoon> youpi: well, he said that he had the papers and they are about - to be signed - <youpi> teythoon: ok, so it's not finished, that's why your name is not on - the list yet - <youpi> this paper stuff is really a pain - <hacklu> youpi: I haven't got any answer from FSF now. - <youpi> did you ping them recently? - <hacklu> I have pinged 2 week ago. - <hacklu> what you mean of ping? I just write an email to him. Is it enough? - <youpi> yes - # IRC, freenode, #hurd, 2013-08-12 @@ -1733,9 +1697,6 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]: < hacklu> hello everyone, this is my week report. http://hacklu.com/blog/gsoc-weekly-report10-174/ - < hacklu> btw, my FSF copyright assignment has been concepted. They guy - said, they have recived my mail for a while but forget to handle it. - < hacklu> but now I face a new problem, when I typed the first continue command, gdb will continue all the breakpoint, and the inferior will run until normally exit. diff --git a/community/gsoc/2013/nlightnfotis.mdwn b/community/gsoc/2013/nlightnfotis.mdwn index a9176f51..87250c62 100644 --- a/community/gsoc/2013/nlightnfotis.mdwn +++ b/community/gsoc/2013/nlightnfotis.mdwn @@ -429,25 +429,6 @@ License|/fdl]]."]]"""]] <tschwinge> nlightnfotis: But before doing that, please do the diff first, so that we know (hopefully) where the erroneous build results were coming from. - <nlightnfotis> considering the Copyright assignment files, I have sent them - from day 1 (that is the 20th of June). I have not heard anything about - those documents to date (sadly) - <nlightnfotis> what's worst is that although I have a reference number to - track those documents, their (greek postal office) tracking service sucks - so badly, that one day it's offline, the next it suggests it can't find - the object in their database, the next it says it is still in the local - post office - <nlightnfotis> let me check it out now - <nlightnfotis> still nothing from their online service - <nlightnfotis> let me call them - <nlightnfotis> tschwinge: I called the post office regarding the copyright - papers. They told me that the same day (the 20th of June) it left from - Herakleion, Crete to Athens and the same day it must have left the - country heading towards the US. They also told me it takes about 1 week - for it to arrive. - <tschwinge> nlightnfotis: OK, so probably waiting at the FSF office to be - processed. Let's allow for some more time. After all, this is not - critical for your progress. # IRC, freenode, #hurd, 2013-07-10 @@ -826,25 +807,6 @@ License|/fdl]]."]]"""]] worker threads are actually never destroyed on debian (because of a debian specific patch) - <teythoon> youpi, nlightnfotis, hacklu_: btw, what about the copyright - assignment process - <tschwinge> nlightnfotis just got his on file, so there is progress. - <tschwinge> I have email from Donald R Robertson III - <copyright-clerk@fsf.org> about that -- but it is not yet present in the - FSF copyright.list file... - <tschwinge> I think I received that email because I was CCed on - nlightnfotis' submission. - <nlightnfotis> tschwinge: I have got the papers, and they were signed by - the FSF. They stated delivery date 11 of July, but the documents were - signed on the 10th of July :P - <tschwinge> Ah, no, I received it via hurd-maintainers@gnu.org -- and the - strange thing is that not all assignments that got processed got sent - there... - <tschwinge> At the recent GNU Tools Cauldron we also discussed this in the - GCC context; and their experience was the very same. Emails get lost, - and/or take ages to be processed, etc. - <tschwinge> It seems the FSF is undermanned. - # IRC, freenode, #hurd, 2013-07-27 @@ -3035,3 +2997,18 @@ But not the [[open_issues/libpthread_dlopen]] issue? <nlightnfotis> and we wanna prove that go violates this rule right? That the stack pointer is not pointing at the initial stack <braunr> yes + + +# IRC, freenode, #hurd, 2013-10-09 + + <gnu_srs> braunr: The crash is not in the assembly code, but in the called + function from it: + <gnu_srs> pthread_sigmask (how=2, set=0xf9cac <server_block_set>, + oset=oset@entry=0x0) at ./pthread/pt-sigmask.c:29 + <gnu_srs> 29 struct __pthread *self = _pthread_self (); + <gnu_srs> Program received signal SIGSEGV, Segmentation fault. + <braunr> gnu_srs: ok so, same problem as in gcc go + <braunr> changing the stack pointer prevents libpthread from correctly + fetching thread-specific data (including _pthread_self()) correctly + <braunr> this will be fixed when threadvards are finally replaced with true + tls diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index c2c179da..39797ba0 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.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 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/perl_python.mdwn b/community/gsoc/project_ideas/perl_python.mdwn index 0dadd7c3..b63aea9f 100644 --- a/community/gsoc/project_ideas/perl_python.mdwn +++ b/community/gsoc/project_ideas/perl_python.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009, 2010, 2011 Free Software Foundation, +[[!meta copyright="Copyright © 2009, 2010, 2011, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable diff --git a/community/gsoc/project_ideas/server_overriding.mdwn b/community/gsoc/project_ideas/server_overriding.mdwn index dab5fc95..6e3d5e14 100644 --- a/community/gsoc/project_ideas/server_overriding.mdwn +++ b/community/gsoc/project_ideas/server_overriding.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 @@ -11,6 +11,9 @@ License|/fdl]]."]]"""]] [[!meta title="Server Overriding Mechanism"]] +/!\ [[!tag open_issue_documentation]] Is this completely resolved by +[[open_issues/virtualization/remap_root_translator]]? + The main idea of the Hurd is that every user can influence almost all system functionality ([[extensible_system|extensibility]]), by running private Hurd servers that replace or proxy the global default implementations. 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 diff --git a/community/meetings.mdwn b/community/meetings.mdwn index 479a9db8..1713ce3a 100644 --- a/community/meetings.mdwn +++ b/community/meetings.mdwn @@ -13,11 +13,6 @@ License|/fdl]]."]]"""]] # Upcoming -## In the Future - - * [[Self-organised]] - - # Past * [[FOSDEM_2014]] @@ -39,4 +34,5 @@ License|/fdl]]."]]"""]] * [[FOSDEM_2006]] * [[RMLL_2005]] * [[FOSDEM_2005]] + * [[OSDI_1994]] * ... diff --git a/community/meetings/fosdem_2014.mdwn b/community/meetings/fosdem_2014.mdwn index ea07bee2..655c8e2e 100644 --- a/community/meetings/fosdem_2014.mdwn +++ b/community/meetings/fosdem_2014.mdwn @@ -28,6 +28,9 @@ Bruxelles. # Microkernel-based operating systems devroom +[[!message-id desc="Announcement and CfP" +"5255453A.70302@os.inf.tu-dresden.de"]]. + <https://fosdem.org/2014/schedule/track/microkernel_based_operating_systems/> diff --git a/community/meetings/osdi_1994.mdwn b/community/meetings/osdi_1994.mdwn new file mode 100644 index 00000000..f0c4b33c --- /dev/null +++ b/community/meetings/osdi_1994.mdwn @@ -0,0 +1,26 @@ +[[!meta copyright="Copyright © 2013 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]]."]]"""]] + +[[!meta title="First Symposium on Operating Systems Design and Implementation +(OSDI '94)"]] + +<http://www.cs.utah.edu/~lepreau/osdi94/> + + * {{$bushnell_hurd}} + + +[[!ymlfront data=""" + +bushnell_hurd: + + "tutorial by Michael I. Bushnell: [*The Architecture of the GNU Hurd*](http://www.cs.utah.edu/~lepreau/osdi94/tutorials/tutorials.html#HURD) ([slides](http://www.cs.utah.edu/~lepreau/osdi94/tutorials/hurdslides.ps.gz))" + +"""]] + diff --git a/community/meetings/self-organised.mdwn b/community/meetings/self-organised.mdwn deleted file mode 100644 index 1403c115..00000000 --- a/community/meetings/self-organised.mdwn +++ /dev/null @@ -1,54 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 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]]."]]"""]] - -[[!meta title="Self-organised meeting"]] - -This meeting will be held in a to-be-determined place, at a to-be-determined time. This page hopes to help finding a good time and place, and finding out who wants to come. - -# Who wants to come? - -Please add yourself here. - -* [[Bas_Wijnen|baswijnen]] (no preference for specific times) -* [[Thomas_Schwinge|tschwinge]] -* [[Tom_Bachmann|tombachmann]] (weekend in the middle of germany would be preferred) -* [[Gianluca_Guida|GianlucaGuida]] (wherever, whenever) -* [[Samuel_Thibault|SamuelThibault]] (wherever, whenever) - -# Who will come? - -* (to be filled in when the date is set) - -# When is a good time? - -Please add any suggestions here, and add to your name above if that time is good for you. - -# Where is a good place? - -## Somewhere in Germany - -This likely has the benefit of being relatively close to most people - -<http://www.linuxhotel.de/community.html> might be a suitable venue at very -reasonable pricing. - -## Somewhere in Italy - -This likely has the benefit of better weather. ;-) - -## Venice (Italy) - -This certainly has the benefit of being in an awesome place. :-) Perhaps we shouldn't care too much about that, since we're mostly busy with ourselves anyway. Or perhaps we should: beauty helps creativity (wow, I should use this as my next catch-phrase to convince a girl to stay with me: I will fail again, but with style! Gianluca). - -# What will we do? - -There will be talks with discussions: - -* Bas will give a talk about Capability-microkernel-based operating systems, with an emphasis on how this can be useful for the Hurd. The talk hopes to get people enthousiastic for the concept, and it will be tried to keep it interesting for people who are not yet familiar with the concepts. |