From d21f5abf22c950e3533062458c655839e5a5f499 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 6 Sep 2010 06:24:48 +0200 Subject: faq/sharing_the_user_space: New. --- faq/sharing_the_user_space.mdwn | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 faq/sharing_the_user_space.mdwn (limited to 'faq') diff --git a/faq/sharing_the_user_space.mdwn b/faq/sharing_the_user_space.mdwn new file mode 100644 index 00000000..7d09ccc0 --- /dev/null +++ b/faq/sharing_the_user_space.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +*Question:* Could it be possible to have a system installation where you can +dual-boot using either the [[Linux]] kernel, or the GNU Hurd, so that +everything but the kernel is shared? + +*Answer:* Given that both Linux and GNU Hurd are using the [[ELF]] binary +format, this could indeed be made possible, if all programs agreed to rely on +only one abstraction layer, for example the standard C library ([[glibc]]). +(Additionally, for example for system calls that are not covered by glibc +calls, you'd need to be able to reliably trap and emulate these.) However, +Linux' and the GNU Hurd's [[ABI]]'s have sufficiently diverged, so that this is +not easy to do. That's why you can't currently install a system in this way, +but you need a separate installation of the userspace suited for the Linux +kernel, or the GNU Hurd. -- cgit v1.2.3 From 1e67a761cbfa94a69cec2f5709d23d7983cd0fc1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 25 Nov 2010 11:55:21 +0100 Subject: Talk about advantages, challenges, how many developers, why so few developers. --- advantages.mdwn | 71 ++++++++++++++++++ challenges.mdwn | 21 ++++++ .../gsoc/project_ideas/language_bindings.mdwn | 2 +- faq/how_many_developers.mdwn | 25 +++++++ faq/why_so_few_developers.mdwn | 27 +++++++ hurd/advantages.mdwn | 67 ----------------- hurd/challenges.mdwn | 16 ---- index.mdwn | 8 +- open_issues/benefits.mdwn | 86 --------------------- .../benefits_of_a_native_hurd_implementation.mdwn | 87 ++++++++++++++++++++++ ...implementing_hurd_on_top_of_another_system.mdwn | 45 +++++------ open_issues/multiprocessing.mdwn | 18 ++--- tag.mdwn | 5 ++ 13 files changed, 276 insertions(+), 202 deletions(-) create mode 100644 advantages.mdwn create mode 100644 challenges.mdwn create mode 100644 faq/how_many_developers.mdwn create mode 100644 faq/why_so_few_developers.mdwn delete mode 100644 hurd/advantages.mdwn delete mode 100644 hurd/challenges.mdwn delete mode 100644 open_issues/benefits.mdwn create mode 100644 open_issues/benefits_of_a_native_hurd_implementation.mdwn (limited to 'faq') diff --git a/advantages.mdwn b/advantages.mdwn new file mode 100644 index 00000000..18e6506b --- /dev/null +++ b/advantages.mdwn @@ -0,0 +1,71 @@ +[[!meta copyright="Copyright © 2001, 2002, 2008, 2010 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]]."]]"""]] + +The GNU Hurd has a number of enticing features: + +It's free software, so anybody can use, modify, and redistribute it under the +terms of the [[GNU General Public License (GPL)|GPL]]. + +It's compatible as it provides a familiar programming and user environment. +For all intents and purposes, the Hurd provides the same facilities as a modern +[[Unix]]-like kernel. The Hurd uses the [[GNU C Library|glibc]], whose +development closely tracks standards such as ANSI/ISO, BSD, POSIX, Single Unix, +SVID, and X/Open. + +Unlike other popular kernel software, the Hurd has an object-oriented structure +that allows it to evolve without compromising its design. This structure will +help the Hurd undergo major redesign and modifications without having to be +entirely rewritten. + +The Hurd is built in a very modular fashion. Other Unix-like kernels (Linux, +for example) are also modular in that they allow loading (and unloading) some +components as kernel modules, but the Hurd goes one step further in that most +of the components that constitute the whole kernel are running as separate +user-space processes and are thus using different address spaces that are +isolated from each other. This is a multi-server design based on a +[[microkernel]]. It is not possible that a faulty memory dereference inside +the [[TCP/IP stack|hurd/translator/pfinet]] can bring down the whole kernel, +and thus the whole system, which is a real problem in a monolothic Unix kernel +architecture. + +One advantage of the Hurd's separation of kernel-like functionality into +separate components ([[servers|hurd/translator]]) is that these can be +constructed using different programming lanugages -- a feature that is not +easily possible in a monolithic kernel. Essentially, only an interface from +the programming environment to the [[RPC]] mechanism is required. (We have a +[[project proposal|community/gsoc/project_ideas/language_bindings]] for this, +if you're interested.) + + + +The Hurd is an attractive platform for learning how to become a kernel hacker +or for implementing new ideas in kernel technology. Every part of the system +is designed to be easily modified and extended. + +It is possible to develop and test new Hurd kernel components without rebooting +the machine. Running your own kernel components doesn't interfere with other +users, and so no special system privileges are required. The mechanism for +kernel extensions is secure by design: it is impossible to impose your changes +upon other users unless they authorize them or you are the system +administrator. + +The Hurd is real software that works right now. It is not a research project +or a proposal. You don't have to wait at all before you can [[start +using|hurd/running]] and [[developing|contributing]] it. + + diff --git a/challenges.mdwn b/challenges.mdwn new file mode 100644 index 00000000..5368ae4e --- /dev/null +++ b/challenges.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +The GNU Hurd has a lot of [[advantages]], but there are challenges, too. + +Even though they're quite popular in the simpler embedded space, there is no +successful true multi-server [[microkernel]] system for general-purpose desktop +use yet. This is still an ongoing research effort. (TODO: add references.) + +Likewise, resource scheduling in distributed operating system kernels is a +research topic. For example, read more about it on the relevant [[Open Issues +page|open_issues/multiprocessing]]. + +TODO: more to come. [[!tag open_issue_documentation]] diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn index 460b380b..c8a02390 100644 --- a/community/gsoc/project_ideas/language_bindings.mdwn +++ b/community/gsoc/project_ideas/language_bindings.mdwn @@ -20,7 +20,7 @@ However, in practice this is not as easy as it should, because creating translators and other servers is quite involved -- the interfaces for doing that are not exactly simple, and available only for C programs. Being able to easily create simple translators in RAD languages is highly desirable, to -really be able to reap the advantages of the Hurd architecture. +really be able to reap the [[advantages]] of the Hurd architecture. Originally Lisp was meant to be the second system language besides C in the GNU system; but that doesn't mean we are bound to Lisp. Bindings for any popular diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn new file mode 100644 index 00000000..a553df21 --- /dev/null +++ b/faq/how_many_developers.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 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="How many developers are working on the GNU Hurd?"]] + +Not many. One handful work on it in their free time, and another two +handful do help with [[Debian GNU/Hurd|hurd/running/debian]] and +[[hurd/running/Arch_Hurd]] packaging. Also, an additional handful of +former developers are still availble for answering technical questions, +but are not really participating in the current development anymore. + +For reaching out to new developers, we're participating in [[Google's +Summer of Code program|community/gsoc]]. Likewise, any interested party +(*you*!) are very welcome to start [[contributing]]. Mentoring is +possible, too, to help you get started. + +Continue reading some speculation about [[why so few developers]] are working +on the GNU Hurd. diff --git a/faq/why_so_few_developers.mdwn b/faq/why_so_few_developers.mdwn new file mode 100644 index 00000000..a2740abc --- /dev/null +++ b/faq/why_so_few_developers.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2010 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="Why are there so few developers working on the GNU +Hurd?"]] + +[[There aren't working a lot of people on the GNU +Hurd|how_many_developers]]. Why is this? + +We can only speculate. One major problem might be that the +[[architectural benefits|advantages]] are generally perceived as very +abstract, with little practical benefits. We don't have many tools to +present actually making use of the possibilities. + +Another reason is that it's been taking too long. Most people don't +believe it will ever be ready for production use, and thus would consider +involvement a waste of time. This latter point is invalid, of course, as +learning can never be a waste of time. The same holds for the +[[challenges]] raised by the GNU Hurd -- we can only learn and improve +upon working on them. diff --git a/hurd/advantages.mdwn b/hurd/advantages.mdwn deleted file mode 100644 index 254e33f6..00000000 --- a/hurd/advantages.mdwn +++ /dev/null @@ -1,67 +0,0 @@ -[[!meta copyright="Copyright © 2001, 2002, 2008, 2010 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]]."]]"""]] - -The GNU Hurd has a number of enticing features: - -It's free software, so anybody can use, modify, and redistribute it under the -terms of the [[GNU General Public License (GPL)|GPL]]. - -It's compatible as it provides a familiar programming and user environment. -For all intents and purposes, the Hurd provides the same facilities as a modern -Unix-like kernel. The Hurd uses the [[GNU C Library|glibc]], whose development -closely tracks standards such as ANSI/ISO, BSD, POSIX, Single Unix, SVID, and -X/Open. - -Unlike other popular kernel software, the Hurd has an object-oriented structure -that allows it to evolve without compromising its design. This structure will -help the Hurd undergo major redesign and modifications without having to be -entirely rewritten. - -The Hurd is built in a very modular fashion. Other Unix-like kernels (Linux, -for example) are also modular in that they allow loading (and unloading) some -components as kernel modules, but the Hurd goes one step further in that most -of the components that constitute the whole kernel are running as separate -user-space processes and are thus using different address spaces that are -isolated from each other. This is a multi-server design based on a -[[microkernel]]. It is not possible that a faulty memory dereference inside -the [[TCP/IP stack|translator/pfinet]] can bring down the whole kernel, and -thus the whole system, which is a real problem in a monolothic Unix kernel -architecture. - -One advantage of the Hurd's separation of kernel-like functionality into -separate components ([[servers|translator]]) is that these can be constructed -using different programming lanugages -- a feature that is not easily possible -in a monolithic kernel. Essentially, only an interface from the programming -environment to the [[RPC]] mechanism is required. - - - -The Hurd is an attractive platform for learning how to become a kernel hacker -or for implementing new ideas in kernel technology. Every part of the system -is designed to be easily modified and extended. - -It is possible to develop and test new Hurd kernel components without rebooting -the machine. Running your own kernel components doesn't interfere with other -users, and so no special system privileges are required. The mechanism for -kernel extensions is secure by design: it is impossible to impose your changes -upon other users unless they authorize them or you are the system -administrator. - -The Hurd is real software that works right now. It is not a research project -or a proposal. You don't have to wait at all before you can [[start -using|running]] and [[developing|contributing]] it. diff --git a/hurd/challenges.mdwn b/hurd/challenges.mdwn deleted file mode 100644 index 640b95c9..00000000 --- a/hurd/challenges.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -[[!meta copyright="Copyright © 2010 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]]."]]"""]] - - - -The GNU Hurd has a lot of [[advantages]], but there are challenges, too. - -There is no successful true multi-server [[microkernel]] system for desktop use -yet. Though, they are quite popular in the simpler embedded space. diff --git a/index.mdwn b/index.mdwn index 249b2091..9520a438 100644 --- a/index.mdwn +++ b/index.mdwn @@ -31,7 +31,7 @@ computing environment as possible. --- -[[!toc]] +[[!toc levels=2]] ## News @@ -122,6 +122,12 @@ For more details, please read our writeup on the [[current_state_of_the_GNU_Hurd|hurd/status]]. +### Advantages and Challenges + +The GNU Hurd operating system design provides [[advantages]], but uncovers new +[[challenges]], too. + + ## How is this site arranged? The menu on the upper right corner provides a rough structuring about the diff --git a/open_issues/benefits.mdwn b/open_issues/benefits.mdwn deleted file mode 100644 index da1248c8..00000000 --- a/open_issues/benefits.mdwn +++ /dev/null @@ -1,86 +0,0 @@ -[[!meta copyright="Copyright © 2010 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]]."]]"""]] - -[[!tag open_issue_documentation]] - -What are the benefits of a native GNU/Hurd system, now that Linux et al. can do -so much (think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux, -etc.). - -It is possible to begin [[implementing_Hurd_on_top_of_another_system]], but... - -IRC, #hurd, August / September 2010 - - ArneBab: but Neal and I were not happy with that alone. We were - looking for deeper improvements to the system, for, I think, sound reasons. - That is what brought us to the L4/Coyotos technologies - ArneBab: as you are writing a kernel in user space, you can still do - kernel improvements there - ArneBab: if you take it very far, you end up with a kernel that runs - Linux in user space (just flip the two) for the drivers - ArneBab: that is what the L4 people did with the DDE - -([[DDE]]) - - ArneBab: so, with these different cuts, there are different - opportunities. on the one end, you can run Linux as normal and get some of - the Hurd features such as translators in some programs. At the other end, - you can do whatever you want and run some linux code for the drivers or none - at all. - ArneBab: one of the big questions then becomes: at which point can - the advantages offered by the Hurd be realized? - ArneBab: and that's not entirely clear to me - when I worked on this with Neal, we pushed further and further into - need-to-change-everything land - while the current efforts on the Hurd seem to be more equivalent to - the could-run-it-in-userspace-on-top-of-Linux camp - marcusb: for that I think we need a way to move towards them step by - step. Would it be possible to get the advantages of better resource - allocation with a Viengoos in userspace, too? - and when that is stable, just switch over? - ArneBab: I don't know. I suspect these people will know before us: - http://lxc.sourceforge.net/ - something like implementing flip points: flip Linux with Hurd to Hund - with Linux. Flip Mach with L4 to L4 with Mach. - lxc sounds interesting. - note that these efforts address security concerns more than other - concerns - so they will get isolation long before sharing is even considered - but some of the issues are the same - once you allow malware to do what it wants, it's a small step to also - allow the user to what he wants :) - it kinda looks like hacking it where it doesn’t really fit again… - there I ask myself when the point comes that doing a cleaner design - offsets the popularity - they are pushing more and more stuff into userspace - which is a good thing (to me) - it’s hard to clearly describe how, but even though I like having more - stuff in userspace, the way it is bolted onto Linux doesn’t feel good for me. - FUSE is cool, but if I use it, I am at a disadvantage compared to a - non-fuse user - while in the Hurd, these additional options are on eqal footing. - ArneBab: are they pushing more and more into user space? I don't - think so. I see more of the reverse, actually - or maybe both - FUSE, lxd and scheduling in userspace move to userspace - well, KMS moved to the kernel - to avoid flickering when switching between X and the console? - marcusb: Do you experience FUSE lxc and such being secondclass in - Linux, too, or is that just a strange feeling of me? - marcusb: and that splits the users into those who can get stuff into - the kernel and those who can only work in userspace – which I don’t really - like. - That’s one more advantage of the Hurd: eqal footing for all (except - the Mach hackers, but they have a very limited terrain) - ArneBab: but UML kernel module is minimal, and Linus didn't have a - principled objection to it (but just wanted a more general solution) - ArneBab: as a side note, although people keep complaining, the linux - kernel seems to be growing steadily, so getting stuff into the kernel doesn't - seem too hard. 8-O diff --git a/open_issues/benefits_of_a_native_hurd_implementation.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn new file mode 100644 index 00000000..34e49e86 --- /dev/null +++ b/open_issues/benefits_of_a_native_hurd_implementation.mdwn @@ -0,0 +1,87 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!tag open_issue_documentation]] + +What are the benefits of a native GNU/Hurd system, now that Linux et al. can do +so much? Think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux +and other virtualization techiques, and so on. + +It is possible to begin [[implementing_Hurd_on_top_of_another_system]], but... + +IRC, #hurd, August / September 2010 + + ArneBab: but Neal and I were not happy with that alone. We were + looking for deeper improvements to the system, for, I think, sound + reasons. That is what brought us to the L4/Coyotos technologies + ArneBab: as you are writing a kernel in user space, you can still + do kernel improvements there + ArneBab: if you take it very far, you end up with a kernel that + runs Linux in user space (just flip the two) for the drivers + ArneBab: that is what the L4 people did with the DDE + +([[DDE]]) + + ArneBab: so, with these different cuts, there are different + opportunities. on the one end, you can run Linux as normal and get some + of the Hurd features such as translators in some programs. At the other + end, you can do whatever you want and run some linux code for the drivers + or none at all. + ArneBab: one of the big questions then becomes: at which point + can the advantages offered by the Hurd be realized? + ArneBab: and that's not entirely clear to me + when I worked on this with Neal, we pushed further and further + into need-to-change-everything land + while the current efforts on the Hurd seem to be more equivalent + to the could-run-it-in-userspace-on-top-of-Linux camp + marcusb: for that I think we need a way to move towards them step + by step. Would it be possible to get the advantages of better resource + allocation with a Viengoos in userspace, too? + and when that is stable, just switch over? + ArneBab: I don't know. I suspect these people will know before + us: http://lxc.sourceforge.net/ + something like implementing flip points: flip Linux with Hurd to + Hund with Linux. Flip Mach with L4 to L4 with Mach. + lxc sounds interesting. + note that these efforts address security concerns more than other + concerns + so they will get isolation long before sharing is even considered + but some of the issues are the same + once you allow malware to do what it wants, it's a small step to + also allow the user to what he wants :) + it kinda looks like hacking it where it doesn’t really fit again… + there I ask myself when the point comes that doing a cleaner + design offsets the popularity + they are pushing more and more stuff into userspace + which is a good thing (to me) + it’s hard to clearly describe how, but even though I like having + more stuff in userspace, the way it is bolted onto Linux doesn’t feel + good for me. + FUSE is cool, but if I use it, I am at a disadvantage compared to + a non-fuse user + while in the Hurd, these additional options are on eqal footing. + ArneBab: are they pushing more and more into user space? I don't + think so. I see more of the reverse, actually + or maybe both + FUSE, lxd and scheduling in userspace move to userspace + well, KMS moved to the kernel + to avoid flickering when switching between X and the console? + marcusb: Do you experience FUSE lxc and such being secondclass in + Linux, too, or is that just a strange feeling of me? + marcusb: and that splits the users into those who can get stuff + into the kernel and those who can only work in userspace – which I don’t + really like. + That’s one more advantage of the Hurd: eqal footing for all + (except the Mach hackers, but they have a very limited terrain) + ArneBab: but UML kernel module is minimal, and Linus didn't have + a principled objection to it (but just wanted a more general solution) + ArneBab: as a side note, although people keep complaining, the + linux kernel seems to be growing steadily, so getting stuff into the + kernel doesn't seem too hard. 8-O diff --git a/open_issues/implementing_hurd_on_top_of_another_system.mdwn b/open_issues/implementing_hurd_on_top_of_another_system.mdwn index 1d7a1e50..7e88e322 100644 --- a/open_issues/implementing_hurd_on_top_of_another_system.mdwn +++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn @@ -21,8 +21,8 @@ IRC, #hurd, August / September 2010 silver_hook: the Hurd can also refer to the interfaces of the filesystems etc, and a lot of that is really just server/client APIs that - could be implemented on any system that has transferable rights to message - capabilities. + could be implemented on any system that has transferable rights to + message capabilities. silver_hook: it's surprising how few systems *have* transferable rights, though! silver_hook: usually it is added as an afterthought @@ -33,23 +33,24 @@ IRC, #hurd, August / September 2010 youpi: it's described in the Stevens series even [...] ArneBab: well, let me put it this way. the Linux kernel has no - interface to manipulate another tasks's virtual address space, ie you can't - map/unmap stuff in another process - ArneBab: you would have to use ptrace and load some stub code in that - process to make that happen. - ArneBab: so for complete transparent manipulation, you need a kernel - module + interface to manipulate another tasks's virtual address space, ie you + can't map/unmap stuff in another process + ArneBab: you would have to use ptrace and load some stub code in + that process to make that happen. + ArneBab: so for complete transparent manipulation, you need a + kernel module that is what the User Mode Linux kernel module does - ArneBab: so say you use the User Mode Linux kernel module for that - one feature. Then you can do everything that User Mode Linux can do, which, - I assure you, includes running subhurds :) + ArneBab: so say you use the User Mode Linux kernel module for + that one feature. Then you can do everything that User Mode Linux can + do, which, I assure you, includes running subhurds :) it can be a bit tricky to implement those features, but it is not harder than writing a kernel in the first place - So, if I got an admin to install User Mode Linux and Mach emulation, - I’d get the flexibility (and independence from admin decisions) I have in the - Hurd? - ArneBab: one problem is that you still use Linux. For those who want - to get rid of Linux for political reasons, that would mean complete failure + So, if I got an admin to install User Mode Linux and Mach + emulation, I’d get the flexibility (and independence from admin + decisions) I have in the Hurd? + ArneBab: one problem is that you still use Linux. For those who + want to get rid of Linux for political reasons, that would mean complete + failure ArneBab: if you have UML kernel module, you can implement Mach in user space ArneBab: in fact, John Tobey did this a couple of years ago, or @@ -57,10 +58,10 @@ IRC, #hurd, August / September 2010 ([[tschwinge]] has tarballs of John's work.) - ArneBab: or you can just implement parts of it and relay to Linux for - the rest - the point is, that if you don't care for kernel improvements, and are - sufficiently happy with the translator stuff, it's not hard to bring the Hurd - to Linux or BSD + ArneBab: or you can just implement parts of it and relay to Linux + for the rest + the point is, that if you don't care for kernel improvements, and + are sufficiently happy with the translator stuff, it's not hard to bring + the Hurd to Linux or BSD -(Continue: [[benefits]].) +Continue reading about the [[benefits of a native Hurd implementation]]. diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn index 7b4f2611..224c0826 100644 --- a/open_issues/multiprocessing.mdwn +++ b/open_issues/multiprocessing.mdwn @@ -11,7 +11,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] We would expect that fine-grained, compartmentalized systems, that is, -microkernel-based multi-server systems in particular, would be ideal condidates +microkernel-based multi-server systems in particular, would be ideal candidates for applying multiprocessing. That is, however, only true from a first and inexperienced point of view: there are many difficulties. @@ -19,14 +19,14 @@ inexperienced point of view: there are many difficulties. IRC, #hurd, August / September 2010 silver_hook: because multi-server systems depend on inter-process - communication, and inter-process communication is many times more expensive - across cpus - silver_hook: so you either force interrelated work on the same cpu, - or suffer heavy penalties. and in a typical fine-grained object system, all - objects are interconnected! - silver_hook: resources in today's systems, even in a single node with - one cpu, but more so in a network, are very non-uniform. scheduling these - resources efficiently is a huge problem. restricting the resource + communication, and inter-process communication is many times more + expensive across cpus + silver_hook: so you either force interrelated work on the same + cpu, or suffer heavy penalties. and in a typical fine-grained object + system, all objects are interconnected! + silver_hook: resources in today's systems, even in a single node + with one cpu, but more so in a network, are very non-uniform. scheduling + these resources efficiently is a huge problem. restricting the resource distribution policies in the way microkernel systems tend to do is posing serious research challenges diff --git a/tag.mdwn b/tag.mdwn index e96e88d5..6051de3b 100644 --- a/tag.mdwn +++ b/tag.mdwn @@ -23,6 +23,11 @@ Most of them should be self-explanatory. GNU/Hurd|hurd/running/debian]] distribution, but not yet in the upstream sources. + * *open_issue_documentation* + + Use for tagging pages / items that need to be handled / improved for + documentation purposes. + * *open_issue_porting* A list of open issues in porting software to run on GNU/Hurd systems. This -- cgit v1.2.3 From 38368072b37bf73dda26dac536e4aa6cf13c67e4 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 29 Nov 2010 13:41:16 +0100 Subject: system_call: New. --- community/gsoc/project_ideas/libcap.mdwn | 8 ++++---- community/gsoc/project_ideas/libcap/details.mdwn | 8 ++++---- community/gsoc/project_ideas/secure_chroot.mdwn | 11 ++++++----- community/gsoc/project_ideas/valgrind.mdwn | 8 ++++---- extensibility.mdwn | 9 +++++---- faq/sharing_the_user_space.mdwn | 2 +- glibc.mdwn | 13 +++++++++++-- glibc/fork.mdwn | 20 +++++++++++++------- hurd/glibc/hurd-specific_api.mdwn | 11 ++++++----- hurd/networking.mdwn | 11 ++++++----- hurd/ng/microkernelcoyotos.mdwn | 4 +++- hurd/ng/trivialconfinementvsconstructorvsfork.mdwn | 18 ++++++++++++++---- hurd/translator/wishlist_2.mdwn | 12 +++++++++++- qemu.mdwn | 12 ++++++------ system_call.mdwn | 19 +++++++++++++++++++ 15 files changed, 113 insertions(+), 53 deletions(-) create mode 100644 system_call.mdwn (limited to 'faq') diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn index 1346203d..18c49c48 100644 --- a/community/gsoc/project_ideas/libcap.mdwn +++ b/community/gsoc/project_ideas/libcap.mdwn @@ -1,12 +1,12 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2010 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Implementing libcap"]] @@ -33,7 +33,7 @@ probably doable without previous experience with either, though. David Hedberg applied for this project in 2010, and though he didn't go through with it, -he fleshed out many [[libcap/details]]. +he fleshed out many [[details]]. Possible mentors: Samuel Thibault (youpi) diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn index aa27a84e..85695978 100644 --- a/community/gsoc/project_ideas/libcap/details.mdwn +++ b/community/gsoc/project_ideas/libcap/details.mdwn @@ -5,8 +5,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Details on implementing libcap"]] @@ -59,7 +59,7 @@ Each process has a three bit fields representing each of the three sets (P, E and I). Each bit field is currently built up of two (32 bit) integers to be able to hold the 33 currently defined capabilities (see linux/capability.h). Each process further has a bounding set which -bounds the permitted set. Two syscalls handles the setting and getting +bounds the permitted set. Two [[system call]]s handles the setting and getting of capabilities; *capset* and *capget*. Some related functionality can also be controlled by calling *prctl*: the right to read/drop the bounding capabilities (PR_CAPBSET_READ/PR_CAPBSET_DROP) and whether @@ -428,7 +428,7 @@ the following (also detailed somewhat in the same article): * Execute process as root (or setuid) to gain all capabilities. -* Use the prctl system call to enable keepcaps for the process +* Use the prctl [[system call]] to enable keepcaps for the process (same(?) effect as enabling SECURE_NO_SETUID_FIXUP for the process). keepcaps should be off by default. diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn index feb30a7c..57739861 100644 --- a/community/gsoc/project_ideas/secure_chroot.mdwn +++ b/community/gsoc/project_ideas/secure_chroot.mdwn @@ -1,17 +1,18 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Secure chroot Implementation"]] As the Hurd attempts to be (almost) fully [[UNIX]]-compatible, it also implements a -`chroot()` system call. However, the current implementation is not really +`chroot` [[system call]]. However, the current implementation is not really good, as it allows easily escaping the `chroot`, for example by use of [[passive_translators|hurd/translator]]. @@ -20,7 +21,7 @@ workaround changing the behavior of passive translators in a `chroot`; changing the context in which passive translators are executed; changing the interpretation of filenames in a chroot; to reworking the whole passive translator mechanism. Some involving a completely different approach to -`chroot` implementation, using a proxy instead of a special system call in the +`chroot` implementation, using a proxy instead of a special [[system call]] in the filesystem servers. See diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn index c6fc7459..7d68e82d 100644 --- a/community/gsoc/project_ideas/valgrind.mdwn +++ b/community/gsoc/project_ideas/valgrind.mdwn @@ -18,7 +18,7 @@ although they work on Linux. Even more importantly, it will help finding bugs in the Hurd servers themselfs. To keep track of memory use, -Valgrind however needs to know how each system call affects the validity of memory regions. +Valgrind however needs to know how each [[system call]] affects the validity of memory regions. This knowledge is highly kernel-specific, and thus Valgrind needs to be explicitely ported for every system. @@ -26,11 +26,11 @@ Such a port involves two major steps: making Valgrind understand how kernel traps work in general on the system in question; and how all the individual kernel calls affect memory. The latter step is where most of the work is, -as the behaviour of each single system call needs to be described. +as the behaviour of each single [[system call]] needs to be described. Compared to Linux, Mach (the microkernel used by the Hurd) has very few kernel traps. -Almost all system calls are implemented as RPCs instead -- +Almost all [[system call]]s are implemented as RPCs instead -- either handled by Mach itself, or by the various Hurd servers. All RPCs use a pair of mach\_msg() invocations: one to send a request message, and one to receive a reply. @@ -62,7 +62,7 @@ The goal of this task is at minimum to make Valgrind grok Mach traps, and to implement the generic RPC handler. Ideally, specific handling for RPCs needing it should also be implemented. -Completing this project will require digging into Valgrind's handling of system calls, +Completing this project will require digging into Valgrind's handling of [[system call]]s, and into Hurd RPCs. It is not an easy task, but a fairly predictable one -- there shouldn't be any unexpected difficulties, diff --git a/extensibility.mdwn b/extensibility.mdwn index 01b1f3b1..17cd5e51 100644 --- a/extensibility.mdwn +++ b/extensibility.mdwn @@ -1,17 +1,18 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] An extensible system is one that enables extensibility. Enabling extensibility means providing non-privileged mechanisms to extend existing objects and to introduce new objects. [[UNIX]] is generally not an extensible system as it does -not generally facilitate the hooking of system calls. For instance, there is +not generally facilitate the hooking of [[system call]]s. For instance, there is no way to hook into the virtual file system. This has motivated the introduction of separate, parallel interfaces by both the GNOME and KDE projects to provide users a more integrated view of their objects. diff --git a/faq/sharing_the_user_space.mdwn b/faq/sharing_the_user_space.mdwn index 7d09ccc0..ec880827 100644 --- a/faq/sharing_the_user_space.mdwn +++ b/faq/sharing_the_user_space.mdwn @@ -15,7 +15,7 @@ everything but the kernel is shared? *Answer:* Given that both Linux and GNU Hurd are using the [[ELF]] binary format, this could indeed be made possible, if all programs agreed to rely on only one abstraction layer, for example the standard C library ([[glibc]]). -(Additionally, for example for system calls that are not covered by glibc +(Additionally, for example for [[system call]]s that are not covered by glibc calls, you'd need to be able to reliably trap and emulate these.) However, Linux' and the GNU Hurd's [[ABI]]'s have sufficiently diverged, so that this is not easy to do. That's why you can't currently install a system in this way, diff --git a/glibc.mdwn b/glibc.mdwn index f47efc03..2eba3667 100644 --- a/glibc.mdwn +++ b/glibc.mdwn @@ -6,8 +6,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="GNU C Library"]] @@ -31,6 +31,15 @@ Porting glibc to a specific architecture is non-trivial. # Implementation Details + * [[hurd/glibc/Hurd-specific API]] + + * [[open_issues/secure_file_descriptor_handling]] + + +## Individual functions + +Some of these are well-known as [[UNIX]] [[system call]]s. + * [[environment_variables]] * [[fork]] diff --git a/glibc/fork.mdwn b/glibc/fork.mdwn index c9efd1f4..e8556a91 100644 --- a/glibc/fork.mdwn +++ b/glibc/fork.mdwn @@ -8,7 +8,7 @@ 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]]."]]"""]] -On [[Unix]] systems, `fork` is a rather simple system call. +On [[Unix]] systems, `fork` is a rather simple [[system call]]. Our implementation in [[glibc]] is and needs to be rather bulky. @@ -22,12 +22,13 @@ which requires a small number of [[RPC]] for each of them. In sum, [[this affects performance|open_issues/performance/fork]] when new processes are continuously being spawned from the shell, for example. -Often, a `fork` call will eventually be followed by an `exec`, which will in -turn close (most of) the duplicated port rights. Unfortunately, this cannot be -known at the time the `fork` executing, so the code calling `fork` has to be -modified, and the `fork`, `exec` combo be replaced by a `posix_spawn` call, for -example, to avoid this work of duplicating each port right, then closing each -again. +Often, a `fork` call will eventually be followed by an `exec`, which [[may in +turn close|open_issues/secure_file_descriptor_handling]] (most of) the +duplicated port rights. Unfortunately, this cannot be known at the time the +`fork` executing, so in order to optimize this, the code calling `fork` has to +be modified instead, and the `fork`, `exec` combo be replaced by a +`posix_spawn` call, for example, to avoid this work of duplicating each port +right, then closing each again. As far as we know, Cygwin has the same problem of `fork` being a nontrivial operation. Perhaps we can learn from what they're been doing? Also, perhaps @@ -51,6 +52,11 @@ they have patches for software packages, to avoid using `fork` followed by ([[!taglink open_issue_glibc]]). +## Related + + * [[secure file descriptor handling]]. + + # External * [*How fork(2) ought to be*](http://www.greenend.org.uk/rjk/fork.html) by diff --git a/hurd/glibc/hurd-specific_api.mdwn b/hurd/glibc/hurd-specific_api.mdwn index aeb63d91..75220279 100644 --- a/hurd/glibc/hurd-specific_api.mdwn +++ b/hurd/glibc/hurd-specific_api.mdwn @@ -1,17 +1,18 @@ -[[!meta copyright="Copyright © 2002, 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2007, 2008, 2010 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Hurd-specific glibc API"]] These functions have meaning only under Hurd. They are needed to get port -names that are used in native Hurd API (the RPC calls to servers). The `.defs` +names that are used in native Hurd API (the [[RPC]]s to servers). The `.defs` and `.h` files can be found in `/include/hurd` when all development files are installed (Debian package `hurd-dev`.) Note that `.defs` are not included in C programs -- they are used to produce `.h` files. @@ -157,7 +158,7 @@ programs -- they are used to produce `.h` files.

thread_t
hurd_thread_self (void);
-
Return the current thread's thread port. This is a cheap operation (no system call), but it relies on Hurd signal state being set up.
+
Return the current thread's thread port. This is a cheap operation (no [[system call]]), but it relies on Hurd signal state being set up.

error_t
diff --git a/hurd/networking.mdwn b/hurd/networking.mdwn index ff16eb25..bdf9def2 100644 --- a/hurd/networking.mdwn +++ b/hurd/networking.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2000, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2000, 2008, 2010 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] For each supported `PF_*` protocol family, there is a file `/servers/socket/N` where `N` is the numberic value fo the `PF_*` symbol. Right now @@ -17,10 +18,10 @@ where `N` is the numberic value fo the `PF_*` symbol. Right now User programs open those files, and use the `socket_create` [[RPC]] to make a new socket. With that socket, they can use the other `socket_*` RPCs and also the `io_*` RPCs. The `socket_*` RPCs are essentially clones of the [[Unix]] -syscalls in question. +[[system call]]s in question. The only exception is `sockaddrs`, which are implemented as [[ports|libports]] -instead of the opaque data arrays they are in the syscalls. You manipulate +instead of the opaque data arrays they are in the system calls. You manipulate `sockaddr` ports with the `socket_create_address`, `socket_fabricate_address`, and `socket_whatis_address` calls. The `sockaddr` port is then used in socket calls like `socket_connect` and `socket_accept`. diff --git a/hurd/ng/microkernelcoyotos.mdwn b/hurd/ng/microkernelcoyotos.mdwn index cdf4e1bf..2340901d 100644 --- a/hurd/ng/microkernelcoyotos.mdwn +++ b/hurd/ng/microkernelcoyotos.mdwn @@ -2,7 +2,9 @@ [Coyotos](http://www.coyotos.org/index.html) is a microkernel and OS and the successor of EROS, that itself is the successor of KeyKOS. A more complete history can be found [here](http://www.coyotos.org/history.html). Its main objectives are to correcte some shortcomings of EROS, demonstrate that an atomic kernel design scales well, and (eventually) to completely formally verify both the kernel and critical system components by writing them in a new language called [bitc](http://www.bitc-lang.org/). [See [l4.verified](http://nicta.com.au/research/projects/l4.verified) for work on formally verifying an L4 microkernel.] -Coyotos is an orthogonally persistent pure capability system. It uses continuation based unbuffered asynchronous IPC (actually it's synchronous IPC with asynchronous syscalls). +Coyotos is an orthogonally persistent pure capability system. It uses +continuation based unbuffered asynchronous IPC (actually it's synchronous IPC +with asynchronous [[system calls]]). TODO: explain these terms and (more important) their consequences on system design. diff --git a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn index 4eeef6ee..0d91dee7 100644 --- a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn +++ b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn @@ -6,10 +6,11 @@ This comparison is about a simple situation: there is a parent process P, which # Trivial Confinement -For trivial confinement, there is a system call to create a process from some memory pages. P performs the following steps: +For trivial confinement, there is a [[system call]] to create a process from +some memory pages. P performs the following steps: * Allocate some memory and put the code image of the child into that memory. This can be done by P, or for example by the file system which then gives the resulting memory (space bank) to P. -* Perform the system call on that memory. The result is a capability to C. +* Perform the [[system call]] on that memory. The result is a capability to C. * Send A to C using the returned capability. Note that it is up to the implementation of the system what happens with P's access to the memory which holds the child. For example, it is probably a good idea if it is at least unmapped, so it cannot accidentily write things in it. It could even be revoked, so that it can't write things in it, even if it wants to. @@ -32,7 +33,16 @@ This mechanism is targeted at a specific use pattern, namely that a process is c # POSIX Fork -POSIX fork, or rather fork+exec, is how things are done on many current systems. It may be insightful to see it included in the comparison, especially for people who are new to the subject. There are two system calls, fork and exec. Fork will create a clone of the current process, including all the capabilities (that is, file descriptors) of the parent (except the ones which have explicitly been excluded). Exec is a system call which really goes to the filesystem, not the kernel (although on systems which use it, the filesystem usually resides in the kernel), and asks it to spawn a new process from the contents of a certain path in place of the caller. This passes all capabilities to the new process. The procedure is: +POSIX fork, or rather fork+exec, is how things are done on many current +systems. It may be insightful to see it included in the comparison, especially +for people who are new to the subject. There are two [[system call]]s, fork and +exec. Fork will create a clone of the current process, including all the +capabilities (that is, file descriptors) of the parent (except the ones which +have explicitly been excluded). Exec is a [[system call]] which really goes to +the filesystem, not the kernel (although on systems which use it, the +filesystem usually resides in the kernel), and asks it to spawn a new process +from the contents of a certain path in place of the caller. This passes all +capabilities to the new process. The procedure is: * P calls fork(), creating P'. * P' drops B. @@ -67,7 +77,7 @@ Except for the control, there is really only one other difference, and that's ad What it doesn't do is protect the code image against bugs in P. In the constructor the trusted and well-tested constructor code is handling the image, for trivial confinement the (very possibly) buggy program P. In particular, when starting a program from a file system, with trivial confinement the operation is: * Ask the file system for the code, receive a capability to a space bank with a copy (on write) of it. -* Make the system call to turn it into a program. +* Make the [[system call]] to turn it into a program. Now this isn't much more complicated than the constructor which does: diff --git a/hurd/translator/wishlist_2.mdwn b/hurd/translator/wishlist_2.mdwn index a927db55..77f39644 100644 --- a/hurd/translator/wishlist_2.mdwn +++ b/hurd/translator/wishlist_2.mdwn @@ -70,7 +70,17 @@ Here's an [idea](http://www.circlemud.org/~jelson/software/fusd/docs/node13.html * "One particularly interesting application of FUSD that we've found very useful is as a way to let regular user-space libraries export device file APIs. For example, imagine you had a library which factored large composite numbers. Typically, it might have a C interface--say, a function called `int *factorize(int bignum)`. With FUSD, it's possible to create a device file interface--say, a device called `/dev/factorize` to which clients can `write(2)` a big number, then `read(2)` back its factors. -* This may sound strange, but device file APIs have at least three advantages over a typical library API. First, it becomes much more language independent--any language that can make system calls can access the factorization library. Second, the factorization code is running in a different address space; if it crashes, it won't crash or corrupt the caller. Third, and most interestingly, it is possible to use `select(2)` to wait for the factorization to complete. `select(2)` would make it easy for a client to factor a large number while remaining responsive to other events that might happen in the meantime. In other words, FUSD allows normal user-space libraries to integrate seamlessly with UNIX's existing, POSIX-standard event notification interface: `select(2)`." +* This may sound strange, but device file APIs have at least three advantages + over a typical library API. First, it becomes much more language + independent--any language that can make [[system call]]s can access the + factorization library. Second, the factorization code is running in a + different address space; if it crashes, it won't crash or corrupt the + caller. Third, and most interestingly, it is possible to use `select(2)` to + wait for the factorization to complete. `select(2)` would make it easy for a + client to factor a large number while remaining responsive to other events + that might happen in the meantime. In other words, FUSD allows normal + user-space libraries to integrate seamlessly with UNIX's existing, + POSIX-standard event notification interface: `select(2)`." ## Mail diff --git a/qemu.mdwn b/qemu.mdwn index 19b5fb9f..d7cea5ad 100644 --- a/qemu.mdwn +++ b/qemu.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2005, 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2005, 2007, 2008, 2009, 2010 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] QEMU is free software written by Fabrice Bellard that implements a fast processor [[emulator|emulation]], allowing a user to run one operating system @@ -19,8 +19,8 @@ reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: * User mode emulation: QEMU can launch Linux processes compiled for one CPU - on another CPU. Linux system calls are converted because of endianness and - 32/64 bit mismatches. Wine and Dosemu are the main targets for QEMU. + on another CPU. Linux [[system call]]s are converted because of endianness + and 32/64 bit mismatches. Wine and Dosemu are the main targets for QEMU. * System mode emulation: QEMU emulates a full system, including a processor and various peripherials. It enables easier testing and debugging of diff --git a/system_call.mdwn b/system_call.mdwn new file mode 100644 index 00000000..197889cb --- /dev/null +++ b/system_call.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +In an [[UNIX]]-like system, a *system call* (*syscall*) is used to request all +kinds of functionality from the operating system kernel. + +A [[microkernel]]-based system typically won't offer a lot of system calls -- +apart from one central one, and that is *send message* -- but instead [[RPC]]s +will be used instead. + +In the [[GNU Hurd|hurd]], a lot of what is traditionlly considered to be a UNIX +system call is implemented (primarily by means of [[RPC]]) inside [[glibc]]. -- cgit v1.2.3