path: root/service_solahart_jakarta_selatan__082122541663/hurd_101.mdwn
diff options
Diffstat (limited to 'service_solahart_jakarta_selatan__082122541663/hurd_101.mdwn')
1 files changed, 360 insertions, 0 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/hurd_101.mdwn b/service_solahart_jakarta_selatan__082122541663/hurd_101.mdwn
new file mode 100644
index 00000000..e55b0e8e
--- /dev/null
+++ b/service_solahart_jakarta_selatan__082122541663/hurd_101.mdwn
@@ -0,0 +1,360 @@
+[[!meta copyright="Copyright © 2011, 2013, 2014 Free Software Foundation,
+[[!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
+(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
+ < 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
+ - 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
+ <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:
+ <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 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.