[[!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 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]]."]]"""]] (See Wikipedia page for the meaning of [[!wikipedia "101_(term)"]].) Not the first time that something like this is proposed... # IRC, freenode, #hurd, 2011-07-25 [failed GNU/Hurd project] < antrik> gnu_srs1: I wouldn't say he was on track. just one of the many many people who insist on picking a hard task; realizing that indeed it's hard; and going into hiding < antrik> we see that happen every couple of months < cluck> maybe we need a "hurd 101" < cluck> getting a teacher and setting up a regularly held "class" for hurd noobs < Tekk_> cluck: what would that include? < cluck> explaining core concepts, giving out "homework" (small tasks), etc [[Anatomy_of_a_Hurd_system]]. < cluck> that way "the big guys" could focus on the hard stuff and have an army of code monkeys at their disposal to write speced stuff < cluck> (then again this idea would heavily depend on available "teachers" and "students", which, going by gsoc numbers, may not be all that helpful) < Tekk_> cluck: gsoc isn't an accurate indicator < Tekk_> cluck: I'm not allowed to participate in gsoc but I'd join :P < antrik> cluck: we don't need code monkeys... we need hackers < Tekk_`> antrik: code monkeys involve into hackers < Tekk_`> under the right conditions < cluck> antrik: jokes aside some sort of triage system/training ground for newcomers could be helpful # IRC, freenode, #hurd, 2013-01-20 <zacts> so once I have written my first translators, and really understand that, what kinds of projects would you recommend to an operating systems/hurd newbie. <zacts> I am reading the minix book now as I have it, but I'm waiting on getting the modern operating systems book by the same author. <zacts> I was initially going to start working on minix, but their focus seems to be on embedded, and I want to work on a system that is more general purpose, and I like the philosophy of freedom surrounding the hurd. <zacts> I like how the hurd design allows more freedom for users of the operating system, but I would also like to incorporate ideas from minix on the hurd. mainly, rebootless updates of servers/translators. <neal> then you should study how translators work <neal> how ipc works <neal> and understand exactly what state is stored where <zacts> ok # IRC, freenode, #hurd, 2013-10-12 <ahungry> Hi all, can anyone expand on https://www.gnu.org/software/hurd/contributing.html - if I proceed with the quick start and have the system running in a virtual image, how do I go from there to being able to start tweaking the source (and recompiling ) in a meaningful way? <ahungry> Would I modify the source, compile within the VM and then what would be the next step to actually test my new changes? <braunr> ahungry: we use debian <braunr> i suggest formatting your changes into patches, importing them into debian packages, rebuilding those packages, and installing them over the upstream ones <ahungry> what about modifications to mach itself? or say I wanted to try to work on the wifi drives - I would build the translator or module or whatever and just add to the running instance of hurd? <ahungry> s/drives/drivers <braunr> same thing <braunr> although <braunr> during development, it's obviously a bit too expensive to rebuild complete packages each time <braunr> you can use the hurd on top of a gnumach kernel built completely from upstream sources <braunr> you need a few debian patches for the hurd itself <braunr> a lot of them for glibc <braunr> i usually create a temporary local branch with the debian patches i need to make my code run <braunr> and then create the true development branch itself from that one <braunr> drivers are a a dark corner of the hurd <braunr> i wouldn't recommend starting there <braunr> but if you did, yes, you'd write a server to run drivers, and start it <braunr> you'd probably write a translator (which is a special kind of 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.