path: root/service_solahart_jakarta_selatan__082122541663/hurd_101.mdwn

[[!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

[[service_solahart_jakarta_selatan__082122541663/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.