diff options
51 files changed, 2559 insertions, 176 deletions
diff --git a/advantages.mdwn b/advantages.mdwn index 19706a89..a7d5b399 100644 --- a/advantages.mdwn +++ b/advantages.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2001, 2002, 2008, 2010, 2011 Free Software +[[!meta copyright="Copyright © 2001, 2002, 2008, 2010, 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -59,7 +59,7 @@ See also [[unsorted/hurd-migr]] ([[!taglink open_issue_documentation]]). 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. +is designed to be [[easily modified and extended|extensibility]]. 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 diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index 6eece956..efd29841 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -57,13 +57,27 @@ subprojects. --> -# Applying for a Task +Applications for 2012 are closed. -<!-- +# Accepted projects -Applications for 2011 are closed. +## Disk I/O Performance Tuning ---> +by Maksym Planeta + +See the project's +[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/mcsim/46002). + +## Virtualization Using Hurd Mechanisms + +by Pierre Thierry + +See the project's +[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/nowhereman/36001) +and [[complete proposal|gsoc/2012/virt/proposal]]. + + +# Possible projects We have a list of [[project_ideas]], and students are likewise encouraged to submit their own project proposals. Please follow our @@ -86,7 +100,6 @@ with Hurd development, even outside of the GSoC context. Please don't hesitate to contact us regarding mentoring even if it's not GSoC time at the moment, or if you aren't a student anyway. - # History In 2006 and [[2007]], we participated in GSoC under the umbrella of the GNU diff --git a/community/gsoc/2012/virt/proposal.mdwn b/community/gsoc/2012/virt/proposal.mdwn new file mode 100644 index 00000000..d89f45d5 --- /dev/null +++ b/community/gsoc/2012/virt/proposal.mdwn @@ -0,0 +1,95 @@ +[[!meta title="Original proposal"]] + +*This is the proposal as it has been submitted to Google Summer of +Code.* + +# The name of the project + +Virtualization Using Hurd Mechanisms + +# Summary + +The goal is to create tools that let a user create a set of servers +that implement a Hurd environment and the necessary resources, with +the possibility of relying on existing servers in the parent Hurd for +some of them, instead of creating them. + +# Benefits + +This project will permit to create isolated systems but with far more +flexibility than traditional virtualization tools, because the degree +of isolation can be changed and possibly not only at creation time, +and communication and sharing of subsystems can be arranged between +isolated systems. + +# Deliverables + +D1 — User stories for the toolset, that will later serve as examples +for the documentation + +D2 — Exhaustive but concise documentation of the set of needed servers +making a working Hurd system (as much for me as for future users of +the tool, building and linking to existing Hurd documentation) + +D3 — Low-level tool to create a working Hurd environment (possibly +with strong limitations on the shape of the resources used by the +environment, most probably on the underlying filesystem) + +D4 — Fake or noop servers for the documented set of needed servers, to +be provided instead of working ones, where a feature is to be denied +to a Hurd environnement + +D5 — Proxy servers, where desirable, to provide access to servers +outside the environment (in ocaps terminology, caretakers) + +D6 — Extension of the low-level tool from D3 to remove its +unreasonable limitations + +D7 — High-level tools to easily create environments and run programs +in them (akin respectively to debootstrap and schroot) + +D8 — If possible, extensions to the D5 and D7 tools to enable dynamic +modifications of the features and authority granted to environments +and creation of multiple interconnected environments + +# Plan + +I intend to develop using the Scrum method, with sprints of two weeks, +which mean that each two weeks, I will present at least one new +working feature, working incrementally towards the full deliverable. I +will also push my code at least once a day to a public Git hosting, +including topic branches, so my progress can be followed easily. + +I intend to start from crosshurd and see how I can hook in its process +of creation to allow being provided alternatives. Depending on how +crosshurd is malleable to those changes, a modified crosshurd will +either be a learning-stage prototype or the base of the +implementation. + +To reuse Git terminology, once plumbing tools (i.e. tools that take +detailed invocation information for each server) are working fine, +I'll move on to porcelain tools, the final UI (i.e. tools that provide +sensible default options, aliases mechanisms, etc.). + +# Communication + +I'm usually easy to reach through both email and jabber, so those and +IRC will be my main way to inform my mentor and ask questions. I'll +setup an ikiwiki to have a summary of the exchanges and the temporary +documentation of the project (i.e. documentation that doesn't fit with +the code yet). + +# Qualification + +Thansk to or because of my participation to the Hurd mailing lists, +I've been utterly contaminated by the concept of POLA a few years +ago. Since then, I've been longing, almost in a painful way, for a +object-capability flavour of Debian. Having to deal in my previous day +jobs with virtualization tools like Xen and VMWare when I knew there +would be no need for paravirtualization or emulation to isolate +systems in an object-capability OS only made it worst. + +Now most of the code I produce naturally becomes capability oriented, +even if my underlying platform, programming language or OS, doesn't +provide true capabilities. And creating true POLA systems and making +it possible for others to benefit from POLA is now one of my dreams. diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 5d42b5c6..8ce10ffa 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -98,7 +98,6 @@ other: language_bindings, gnat, gccgo, perl_python. --> [[!inline pages="community/gsoc/project_ideas/secure_chroot" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/package_manager" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/download_backends" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/libgtop" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/maxpath" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/gnat" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/gccgo" show=0 feeds=no actions=yes]] diff --git a/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn b/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn new file mode 100644 index 00000000..befd680a --- /dev/null +++ b/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn @@ -0,0 +1,64 @@ +[[!meta copyright="Copyright © 2012 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_hurd]] + + +# IRC, freenode, #hurd, 2012-04-22 + + <youpi> btw, I was wondering, when working on namespace mangling, did they + think about automatitioning ? + <youpi> autopartitioning, I meant + <youpi> i.e. with a foo.img file, open foo.img,,part1 + <braunr> what are you referring to with namespace mangling + <youpi> and voila + <youpi> I don't remember the exact term they used + <braunr> you mean there is a hurd library that parses names and can direct + to different services depending on part of the name ? + <youpi> namespace-based_translator_selection + <youpi> yes + <braunr> i thought it only handled directories + <braunr> well, the classical path representation + * civodul finds it ugly + <youpi> civodul: because of potential conflict, and the not-too-nice ",," + part? + <youpi> actually I wonder whether using directory access would be nicer + <youpi> i.e. you have a foo.gz, just open foo.gz/gunzip to get the unzipped + content + <youpi> and for foo.img.gz, open foo.img.gz/gunzip/part/1 + <civodul> youpi: because of the interpretation of special chars in file + names + <civodul> users should be free to use any character they like in file names + <civodul> foo.gz/gunzip looks nicer to me + <youpi> ok, so we agree + <youpi> that said, the user could choose the separator + <youpi> the namespace can be not run by root for everybody, but just for + your shell, run by yourself + <antrik> civodul: the user can't use any character anyways... '/' and '\0' + are reserved :-P + <civodul> antrik: '/' isn't quite reserved on the Hurd :-) + <civodul> you could implement dir_lookup such that it does something + special about it + <civodul> (server-side) + <antrik> civodul: as for overloading '/', although I haven't thought it + through entirely, I guess that would work for nodes that present as files + normally. however, it would *not* work for directory nodes + <antrik> which would be quite a serious limitation IMHO + <antrik> I can think of various kinds of useful directory translators + <antrik> what's more, one of the main use cases I originally had in mind is + a policy filter + <antrik> you could pass a directory name with a appropriate filter applied + to tar for example, so it wouldn't try to follow any translators + <antrik> I don't see why taking an obscure prefix like ,, would be much of + a problem in practice anyways + <antrik> (also, it doesn't strictly prevent the user from having such file + names... you just need to escape it if accessing such files through the + namespace multiplexer. though admittedly that would need some special + handling in *some* programs to work properly) diff --git a/faq/how_many_developers/discussion.mdwn b/faq/how_many_developers/discussion.mdwn index 6ca47c9a..8e4c487a 100644 --- a/faq/how_many_developers/discussion.mdwn +++ b/faq/how_many_developers/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 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 @@ -8,6 +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]]."]]"""]] + # IRC, freenode, #hurd, 2011-05-22 <silver_hook> Since apparently Hurd's aim is a very stable and transparent @@ -59,3 +60,6 @@ License|/fdl]]."]]"""]] <antrik> the Hurd doesn't almost work for anyone <antrik> actually, you should probably reread the whole paper. it's essentially an analysis why the Hurd failed compared to Linux + + +# [[open_issues/mission_statement]] diff --git a/faq/which_microkernel/discussion.mdwn b/faq/which_microkernel/discussion.mdwn index 7ea131e9..ffdc6720 100644 --- a/faq/which_microkernel/discussion.mdwn +++ b/faq/which_microkernel/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 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 @@ -50,13 +50,15 @@ All in all, I still think my text was better. If you have any conerns with it, please discuss them... -# IRC, freenode, #hurd, 2011-09-27 +# seL4 + +## IRC, freenode, #hurd, 2011-09-27 <cjuner> Does anyone remember/know if/why not seL4 was considered for hurd-l4? Is anyone aware of any differences between seL4 and coyotos? -## 2011-09-28 +## IRC, freenode, #hurd, 2011-09-29 <antrik> cjuner: the seL4 project was only at the beginning when the decision was made. so was Coyotos, but Shapiro promised back then that @@ -92,3 +94,27 @@ please discuss them... matters to take away anything useful from more detail ;-) ) <antrik> I could try to explain the issues I mentioned for Coyotos (as far as I understand them), but would that really help you? + + +# Xnu (Darwin) + + +## IRC, freenode, #hurd, 2012-03-30 + + <mel__> did people consider to port Hurd to Darwin? i.e. replace GNU Mach + with Darwin? + <braunr> no + <braunr> well, quickly only + <mel__> wouldn't it be a reasonable idea? + <mel__> after all, Darwin is production-ready and contains a Mach side. + <braunr> not more than fixing gnumach itself, or using linux instead + <mel__> well. + <braunr> those implementations have diverged with time + <mel__> i see + <mel__> the fsf should pay people for fixing gnu mach then. :) + <antrik> mel__: indeed someone consided Xnu (the actual kernel of Darwin) a + while back; but I think he shelved the idea again. not sure about the + exact reasons + <antrik> Xnu implements a few improvements that might be helpful; but it + doesn't address the really fundamental issues that matter for a true + multiserver system... diff --git a/hurd/console.mdwn b/hurd/console.mdwn index f7230011..55581870 100644 --- a/hurd/console.mdwn +++ b/hurd/console.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2011 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2011, +2012 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 @@ -9,6 +9,11 @@ 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]]."]]"""]] +[[!toc]] + + +# Architecture: client and server + The Hurd console's implementation is broken into two pieces each running on it's own process, the console client and server. @@ -79,9 +84,9 @@ blocking operations and a blocked `input_dequeue` necessarily needs an `ports_manage_multithreaded` API. ---- +# Old stuff -/!\ old content; [[!taglink open_issue_documentation]]: cleanup needed. +[[!taglink open_issue_documentation]]: cleanup needed. The below is a reworked version of Marcus Brinkmann's [letter to the debian-hurd list](http://lists.debian.org/debian-hurd/2002/debian-hurd-200209/msg00054.html). It describes how to setup the new console server for the Hurd. I am testing this right now, so this document is a work in progress. @@ -357,3 +362,101 @@ An [experimental plugin to load XKB keymaps](http://kilobug.free.fr/hurd/xkb-0.3 Added examples that use repeaters needed by X. -- [[Main/OgnyanKulev]] - 18 Sep 2004 + + +# IRC, freenode #hurd, 2012-04-23 + + <Tekk_> is there any way to get copy/paste in hurd? + <Tekk_> with the console server + <Tekk_> like you get with gpm + <youpi> Tekk_: by implementing it + <antrik> Tekk_: that's something for the console client, not the server + <antrik> (or perhaps both? not entirely sure) + <Tekk_> antrik: I'm not entirely sure how the client works + <Tekk_> does it start a new client with each tty? + <Tekk_> or one client handles all of them? + <youpi> the client only should be enough + <youpi> it handles all input already anyway + <youpi> the client handles all ttys + <youpi> it just hops over them according to alt-Fx shortcuts + <antrik> Tekk_: there is only one client for all, but a separate console + *server* for each tty + <Tekk_> antrik: ah, the ever confusing X scheme + <antrik> no + <antrik> the client handles multiplexing and actual terminal I/O + <antrik> the servers handle the state of the virtual terminals, and provide + the device nodes + <antrik> this doesn't fit with the X scheme in any way + <antrik> (where everything is basically in one big monolithic server + process) + <Tekk_> antrik: I mean that you're running multiple servers and there's one + big client running on the other end + <Tekk_> which always pretty well confuses everyone to start with + <antrik> I totally fail to see the connection + <antrik> there is usually one X server, with potentially many clients + <Tekk_> nevermind + <Tekk_> doesn't really matter to anything + <Tekk_> so yeah, copy/paste would be in the client? + <antrik> unless you mean a termial server, running actual client programs, + connected to various terminals, running X servers... which is where it + gets confusing in a way ;-) + <antrik> but there is really no relation at all here + <Tekk_> antrik: exactly ;) + <Tekk_> I meant in the traditional sense, where you're on a thin client + running an X server and the remote server is running X clients + <Tekk_> copy/paste probably isn't really too bad + <antrik> applications are also clients of the terminal server processes; + but having a completely different role (and using completely different + requests) than the console client + <Tekk_> you have a buffer, when something is highlighted you strncpy the + highlighted text into the buffer. when middle click happens you send the + text to the right virtual terminal + <antrik> right. what I was considering is whether the pasting (and possibly + also grabbing) the text might be done through some separate protocol + implemented in the console server, rather than the ordinary console + client interfaces... but probably no need for that + <Tekk_> nah, as long as you have a way of getting a highlighted area and + then the text contained in it + <Tekk_> and then of course a way to insert text where the cursor is, but + I'm pretty sure you can safely assume that one :P + <antrik> well, the client has a way to send keystrokes to the server, + obviously. the question here is whether pretending the pasting is + keystrokes is good enough, or whether it might be useful to have an + explicit way to push the pasted stuff to the server + <antrik> (the cursor position is relevant only for echo) + <Tekk_> antrik: I'll try to grab the console source some time this week and + take a look + <Tekk_> maybe I can try to get it working + <antrik> good luck :-) + <antrik> it's probably not too hard + <Tekk_> I'm sure I'll need it :) + <antrik> the whole console machinery is quite hard to grasp (and I still + find myself confused sometimes, although I gained a pretty good + understanding I think when writing my thesis) + <antrik> but for this specific task, not much knowlegde should be needed + about the various confusing aspects + <Tekk_> hmm. looks like copy/paste won + <Tekk_> 't be a quick thing, actually + <Tekk_> wait, no. there must be a way to get mouse events + <Tekk_> how else could you move the mouse.. + <Tekk_> (with by moving your mouse, not cons_mouse_move) + <Tekk_> by moving your mouse* + <Tekk_> started typing something different + + +# Graphics/Higher Resolution + +## IRC, freenode #hurd, 2012-04-24 + + <Tekk_> does the console support higher resolutions yet? + <youpi> no + <youpi> it's just textonly + <antrik> Tekk_: the main reason why I originally started on the KGI work + was to get a graphical console... but I never finished that part + <antrik> (since KGI is obsolete anyways) + <antrik> BTW, there is a KMS-based userspace console now for Linux... I + guess it should be easy to adapt to other systems having KMS support + <antrik> I don't think it actually makes much sense for Linux, as it's one + of the hardest and least profitable things to move out of a monolithic + kernel... + <antrik> well, not hardest I guess; but most problematic diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn index 809bf7b1..19b371c1 100644 --- a/hurd/running/debian/qemu_image.mdwn +++ b/hurd/running/debian/qemu_image.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 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 @@ -15,7 +15,7 @@ Usage: $ wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz $ tar -xz < debian-hurd.img.tar.gz - $ qemu -net nic,model=rtl8139 -net user -hda debian-hurd-*.img + $ qemu -m 512 -net nic,model=rtl8139 -net user -hda debian-hurd-*.img Just in case you were wondering: the *root* password is *root*. diff --git a/hurd/running/gnu/create_an_image.mdwn b/hurd/running/gnu/create_an_image.mdwn index c7a97a4e..8784a826 100644 --- a/hurd/running/gnu/create_an_image.mdwn +++ b/hurd/running/gnu/create_an_image.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2012 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]]."]]"""]] Creating a bootable qemu image from a root filesystem and bootloader @@ -17,7 +18,7 @@ Creating a bootable qemu image from a root filesystem and bootloader 2. Use a live CD (better to have a lighter OS like system rescue CD to make the process faster) and the image created to boot. - qemu -cdrom /dev/cdrom -hda <imagename.img> -boot d + qemu -m 512 -cdrom /dev/cdrom -hda <imagename.img> -boot d 3. Once system is booted use a partition editing tool (like fdisk, cfdisk, parted, gparted, qtparted ...) to partition the image. @@ -64,7 +65,7 @@ Creating a bootable qemu image from a root filesystem and bootloader 11. Run qemu to boot into your brand new system - qemu -hda <hard disk image.img> -fda grub.img -boot a + qemu -m 512 -hda <hard disk image.img> -fda grub.img -boot a Happy Hacking !! diff --git a/hurd/running/installtips.mdwn b/hurd/running/installtips.mdwn deleted file mode 100644 index 3f95f9b5..00000000 --- a/hurd/running/installtips.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -[[!meta copyright="Copyright © 2012 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]]."]]"""]] - -HERE STARTS YOUR NEW CONTENT -- remove everything from here on, including this -line. - -By creating this page, you agree to assign copyright for your contribution to -the Free Software Foundation, <http://www.fsf.org/>. The Free Software -Foundation promises to always use a free documentation license (as per our -criteria of free documentation) when publishing your contribution. We grant -you back all your rights under copyright, including the rights to copy, modify, -and redistribute your contributions. - -We're requiring these copyright assignments, so that we'll easily be able to -include your contributions in official GNU documentation, such as the GNU Hurd -Reference Manual, etc. Send email to <hurd-maintainers@gnu.org> if there are -questions. diff --git a/hurd/running/live_cd.mdwn b/hurd/running/live_cd.mdwn index c9360594..1eb9b8e0 100644 --- a/hurd/running/live_cd.mdwn +++ b/hurd/running/live_cd.mdwn @@ -8,7 +8,7 @@ MiB: <http://www.superunprivileged.org/hurd/tiny-cd/> Use it like this: - $ qemu -cdrom hurd-tiny-cd-20060722.iso + $ qemu -m 512 -cdrom hurd-tiny-cd-20060722.iso A more recent Live CD can be found at <http://teythoon.cryptobitch.de/hurd/livecd/hurd-live-install-1273300101.iso.xz>. @@ -16,7 +16,7 @@ It can be run with qemu via $ wget http://teythoon.cryptobitch.de/hurd/livecd/hurd-live-install-1273300101.iso.xz $ xz -d hurd-live-install-1273300101.iso.xz - $ qemu -cdrom hurd-live-install-1273300101.iso + $ qemu -m 512 -cdrom hurd-live-install-1273300101.iso These [[!wikipedia LiveCD]]s should be useful for those who want to try out the Hurd before they commit to installing it on their hard disks. In addition to diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index fcf58d8a..b64c576f 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -28,7 +28,8 @@ Note that the following images are unofficial ones: they have been prepared by volunteers and may not have been tested extensively. * [Disk image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) - with a short intro on translators. Just start it with 'qemu *disk_image.img*'. + with a short intro on translators. Just start it with `qemu -m 512 + disk_image.img`. It should work without any of the configuration below. If you want to know what you can do with it, please have a look at [[its_wikipage|hurd/running/qemu/babhurd_image]]. And when you use it, please [tell me your experience with it](http://draketo.de/contact)! - [[community/weblogs/ArneBab]] @@ -272,7 +273,7 @@ This is the recommended way to work with a Command Line Interface (CLI) since al a) with ssh (assuming you have installed openssh-server) - $ kvm -m 1024 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img & + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img & Logging in to the running Hurd: @@ -289,7 +290,7 @@ Copying files: b) with telnet (assuming you have installed a telnet server, like telnetd) - $ kvm -m 1024 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -hda hurd-install.qemu & + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -hda hurd-install.qemu & Logging in to the running Hurd: @@ -330,7 +331,7 @@ Now it is time to start-up your QEMU Hurd system and get networking going in the **Important:** Remember you may need to use the `-M isapc` or `-isa` flag if using an older version of the gnumach package. - $ qemu -hda hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap + $ qemu -m 512 -hda hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap Once you have logged in as `root` run the `pfinet` translator with values that apply to your network. Think of your QEMU client as another computer in your network. diff --git a/hurd/running/qemu/babhurd_image.mdwn b/hurd/running/qemu/babhurd_image.mdwn index c0952fcf..855e8f51 100644 --- a/hurd/running/qemu/babhurd_image.mdwn +++ b/hurd/running/qemu/babhurd_image.mdwn @@ -5,8 +5,8 @@ What this little Hurd image can do This is the README file accompanying a [disk\_image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) for -[[running_the_GNU/Hurd_via_qemu|hurd/running/qemu]]. To run the disk image, just use *'qemu -disk_image.img'*. +[[running the GNU/Hurd via qemu|hurd/running/qemu]]. To run the disk image, +just use `qemu -m 512 disk_image.img`. You can find the custom *.bashrc* used to tell the user about it as well as this text itself in the Mercurial repository [hurd_intro](http://bitbucket.org/ArneBab/hurd_intro). diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index b8e595d3..f2117ead 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -31,7 +31,7 @@ flexible.) Vice versa, it is also possible to use a subhurd to debug the To run a subhurd, you need an additional partition with an installed Hurd system. In principle, you can also use your main partition in read-only mode; but this obviously will create severe limitations. Usually, you will want a -complete independant system. +complete independent system. The system for the subhurd is a normal Hurd installation, which could just as well run standalone. You can use any of the various possible installation diff --git a/hurd/translator/devfs.mdwn b/hurd/translator/devfs.mdwn index 8784e998..a9cc307f 100644 --- a/hurd/translator/devfs.mdwn +++ b/hurd/translator/devfs.mdwn @@ -12,7 +12,7 @@ License|/fdl]]."]]"""]] in there in a dynamic fashion -- as compared to static passive translator settings as they're used now. -`devfs` has not yet been written. +`devfs` has not yet been written. [[!tag open_issue_hurd]] --- @@ -23,6 +23,8 @@ path is resident at all times. # IRC, freenode, #hurd, 2012-01-29 +[[!tag open_issue_documentation]] + <pinotree> what would be an hurdish way to achieve something like the various system (udev, devfs, devd, etc) for populating devices files automatically according to the found system devices? @@ -37,3 +39,35 @@ path is resident at all times. /dev directory with unique device names... probably need some unionfs-like translator that collects the individual driver nodes in an intelligent manner + + +# IRC, freenode, #hurd, 2012-04-22 + + <antrik> braunr: I don't think it's a problem that translators are invoked + when listing /dev + <antrik> the problem is that they linger around although they are very + unlikely to be needed again any time soon + <youpi> for now it's not too much a problem because there aren't too many + <youpi> but that can become problematic + <pinotree> a devfs on /dev could also fill it with new devices + <youpi> but only with the ones that actually exist + <pinotree> yeah + <braunr> antrik: i mean, the hurd may lack a feature allowing the same + translator to be used for several nodes not hierarically related + <braunr> antrik: or rather, it's a special case that we should implement + differently + <braunr> (with e.g. a devfs that can route requests for different nodes to + a same translator + <braunr> ) + <antrik> I agree BTW that some intermediary for /dev would be helpful -- + but I don't think it should actually take over any RPC handling; rather, + only redirect the requests as appropriate (with the actual device nodes + in a hierarchical bus-centric layout) + <braunr> right + <antrik> braunr: actually, the Hurd *does* have a feature allowing the same + translator to be attached to several unrelated nodes + <braunr> i keep getting surprised :) + <antrik> though it's only used in very few places right now + <youpi> pfinet and ptys at least ? + <antrik> yeah, and console client IIRC + diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index fff2e74b..ad79c7b9 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -1,18 +1,23 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 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]]."]]"""]] + # Implementation * [[filetype]] option + * [[Hurd-specific_extensions]] + + * [[Page_cache]] + ## Large Stores diff --git a/hurd/translator/ext2fs/hurd-specific_extensions.mdwn b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn new file mode 100644 index 00000000..774f1cf3 --- /dev/null +++ b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2012 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]] + + +# IRC, freenode, #hurd, 2012-04-20 + + <Tekk_> what are the extensions to ext2? + <Tekk_> that hurd uses + <braunr> tha ability to store passive translator command lines in the + inodes + <braunr> the* + <antrik> well, also a fourth set of permission bits, and an "author" field + <braunr> right + <antrik> both very obscure features that better never existed... diff --git a/hurd/translator/ext2fs/page_cache.mdwn b/hurd/translator/ext2fs/page_cache.mdwn new file mode 100644 index 00000000..e8a964ed --- /dev/null +++ b/hurd/translator/ext2fs/page_cache.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2012 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]] + +This is not at all specific to ext2fs, so should be integrated elsewhere. + + +# IRC, freenode, #hurd, 2012-04-22 + + <Tekk_> is there any particular reason ext2fs takes so much memory? + <Tekk_> it beats everything on my system hands down at 100 MB + <youpi> ext2fs contains the page cache + <youpi> so it's no wonder it takes memory + <youpi> it's all the mapped files + <Tekk_> any way I can cut down on that? + <Tekk_> my system only has 512 meg :/ + <youpi> gnumach is supposed to automatically cut it down as needed + <youpi> what is the actual symptom that you see? + <Tekk_> youpi: 360 MB of memory usage when I'm doing nothing + <Tekk_> oh, is it just intelligent enough to cut down when I'm using more + memory? + <youpi> Tekk_: yes + <Tekk_> awesome. I was worried :) diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 339fab50..e7fdf46e 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012 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 @@ -218,3 +219,61 @@ Needed by glibc's `pldd` tool (commit # `/proc/self/exe` [[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]] + + +# `/proc/[PID]/fd/` + +## IRC, freenode, #hurd, 2012-04-24 + + <antrik> braunr: /proc/*/fd can be implemented in several ways. none of + them would require undue centralisation + <antrik> braunr: the easiest would be adding one more type of magic lookup + to the existing magic lookup mechanism + <antrik> wait, I mean /proc/self... for /proc/*/fd it's even more + straighforward -- we might even have a magic lookup for that already + <pinotree> i guess the ideal thing would be implement that fd logic in + libps + <antrik> pinotree: nope. it doesn't need to ask proc (or any other server) + at all. it's local information. that's what we have the magic lookups for + <antrik> one option we were considering at some point would be using the + object migration mechanism, so the actual handling would still happen + client-side, but the server could supply the code doing it. this would + allow servers to add arbitrary magic lookup methods without any global + modifications... but has other downsides :-) + <gnu_srs> youpi: How much info for /proc/*/fd is possible to get from + libps? Re: d-h@ + <youpi> see my mail + <youpi> I don't think there is an interface for that + <youpi> processes handle fds themselves + <youpi> so libps would have to peek in there + <youpi> and I don't remember having seen any code like that + <gnu_srs> 10:17:17< antrik> wait, I mean /proc/self... for /proc/*/fd it's + even more straighforward -- we might even have a magic lookup for that + already + <gnu_srs> pinotree: For me that does not ring a bell on RPCs. Don't know + what magic means,, + <youpi> for /proc/self/fd we have a magic lookup + <youpi> for /proc/pid/fd, I don't think we have + <gnu_srs> magic lookup* + <gnu_srs> magic lookup == RPC? + <youpi> magic lookup is a kind of answer to the lookup RPC + <youpi> that basically says "it's somewhere else, see there" + <youpi> the magic FD lookup tells the process "it's your FD number x" + <youpi> which works for /proc/self/fd, but not /proc/pid/fd + <civodul> youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that + could be used + <civodul> `msgport' should have --get-fd, actually + <youpi> civodul: I assumed that the reason why msgport doesn't have it is + that it didn't exist + <youpi> so we can get a port on the fd + <youpi> but then how to know what it is? + <civodul> youpi: ah, you mean for the /proc/X/fd symlinks? + <civodul> good question + <civodul> it's not designed to be mapped back to names, indeed :-) + <antrik> youpi: yeah, I realized myself that only /proc/self/fd is trivial + <antrik> BTW, in Linux it's nor real symlinks. it's magic, with some very + strange (but useful in certain situations) semantics + <antrik> not real symlinks + <antrik> it's very weird for example for fd connected to files that have + been unlinked. it looks like a broken symlink, but when dereferencing + (e.g. with cp), you get the actual file contents... diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn index 1d441c7d..bdee0f78 100644 --- a/hurd/translator/tmpfs/discussion.mdwn +++ b/hurd/translator/tmpfs/discussion.mdwn @@ -376,3 +376,55 @@ License|/fdl]]."]]"""]] <mcsim> Anyway all these are just translators, so there shouldn't be any problems. <mcsim> pinotree: works + + +## IRC, freenode, #hurd, 2012-03-22 + + <mcsim> Hello. Is it normal that when i try to run du at directory where + translator is mounted it says that directory is 'Not a directory'? Here + are some examples with different filesystems: paste.debian.net/160699 + First is ramdisk+ext2fs, second is tmpfs, third is ext2fs. + <civodul> i can't reproduce the problem with ext2fs + <civodul> perhaps you can try rpctracing it to see where ENOTDIR comes from + <mcsim> civodul: when I run du io_stat_request ipc is called. But reply is + ((os/kern) invalid address). Where is server code for this ipc? I only + found its definition in defs file and that's all. + <civodul> mcsim: server code is in libdiskfs + ext2fs, for instance + <mcsim> civodul: Does io_stat_request have changed name in server code? I + just can't find it. Here are my grep results fore io_stat_request (i was + grepping in root of hurd repository: paste.debian.net/160708 + <youpi> remove _request + <youpi> it's just io_stat + <mcsim> youpi: thank you + + +## IRC, freenode, #hurd, 2012-04-08 + + <mcsim> youpi: I've corrected everything you said, and pushed code to new + branch mplaneta/tmpfs/master-v2 + <youpi> mcsim: all applied, thanks ! + <youpi> I'll probably test it a bit and upload a new version of hurd + <youpi> mcsim: it seems to be working fine indeed! + <mcsim> youpi: thank you for all your reviews, suggestions you gave and + corrections you made :) + <youpi> and it seems translators indeed work there too + <youpi> hopefully it'll work to run the debian installer + <youpi> that'd permit to solve memory consumption + <pinotree> (so tmpfs works really fine now? great!) + <youpi> I could reboot with tmpfs on /tmp and build a package there, yes + <mcsim> youpi: yes, I've compiled several packages already, but it does not + give big advantage in performance. + <youpi> I wasn't really looking for performance, but for correctness :) + <youpi> are you using writeback for your /, actually ? + <youpi> argl, /run gets triggered before mach-defpager is started + <youpi> the X11 socket works there too + <youpi> gnu_srs: might your mouse issue with Xorg be related with vnc usage + too? + <youpi> it seems ENOSPC works fine too + <mcsim> youpi: as to writeback. I think yes, because default pager is asked + to write data only when this data is evicted. + <youpi> I'm talking about kvm + <mcsim> youpi: I use real computer. + <youpi> ok + <youpi> but that indeed means writeback of ext2fs works, which is a good + sign :) diff --git a/news/2010-04-30.mdwn b/news/2010-04-30.mdwn index da4c0183..0b50122d 100644 --- a/news/2010-04-30.mdwn +++ b/news/2010-04-30.mdwn @@ -43,7 +43,7 @@ else="[[!paste id=full_news]]"]] > Mainly thanks to *Jose Luis Alarcon Sanchez*, we now have a [new QEMU > image](http://lists.debian.org/debian-hurd/2010/04/msg00098.html). It can be -> run with a simple `qemu -hda debian-hurd-17042010-qemu.img`. +> run with a simple `qemu -m 512 -hda debian-hurd-17042010-qemu.img`. > *Thomas Schwinge* updated [our glibc maintenance > repository](http://git.savannah.gnu.org/cgit/hurd/glibc.git/?h=tschwinge/Roger_Whittaker) diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn index ca2063a5..31359da3 100644 --- a/open_issues/boehm_gc.mdwn +++ b/open_issues/boehm_gc.mdwn @@ -332,3 +332,16 @@ It has last been run and compared on 2010-11-10, based on CVS HEAD sources from make libgc use RTMIN+5/6, like done on most of other OSes <youpi> but we don't have RT signals, do we? <pinotree> right :( + + +### IRC, freenode, #hurd, 2012-03-21 + + <pinotree> civodul: given we have to realtime signals (so no range of + signals for them), libgc uses SIGUSR1/2 instead of using SIGRTMIN+5/6 for + its thread synchronization stuff + <pinotree> civodul: which means that if an application using libgc then + sets its own handlers for either of SIGUSR1/2, hell breaks + <civodul> pinotree: ok + <civodul> pinotree: is it a Debian-specific change, or included upstream? + <pinotree> libgc using SIGUSR1/2? upstream + <civodul> ok diff --git a/open_issues/bpf.mdwn b/open_issues/bpf.mdwn index 2a8c897a..e24d761b 100644 --- a/open_issues/bpf.mdwn +++ b/open_issues/bpf.mdwn @@ -562,3 +562,26 @@ This is a collection of resources concerning *Berkeley Packet Filter*s. DDE accordingly <braunr> antrik: i agree <braunr> antrik: eth-multiplexer would be the right place + + +## IRC, freenode, #hurd, 2012-04-24 + + <gnu_srs> braunr: Is BPF fully supported by now? Can it be used for + isc-dhcp? + <braunr> gnu_srs: bpf isn't supported at all + <braunr> gnu_srs: instead of emulating it, i added a hurd-specific module + in libpcap + <braunr> if isc-dhcp can use libpcap, then fine + <braunr> (otherwise we could create a hurd-specific patch for dhcp that + uses the in-kernel bpf filter implementation) + <braunr> gnu_srs: can't it use a raw socket ? + <youpi> it can + <youpi> it's just that the shape of the patch to do so wasn't exactly how + they needed it + <youpi> so they have to rework it a bit + <youpi> and that takes time + <braunr> ok + <braunr> antrik: for now, we prefer encapsulating the system specific code + in libpcap, and let users of that library benefit from it + <braunr> instead of implementing the low level bpf interface, which + nonetheless has some system-specific variants .. diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn index b0b38a2a..725af646 100644 --- a/open_issues/dde.mdwn +++ b/open_issues/dde.mdwn @@ -200,6 +200,37 @@ At the microkernel davroom at [[community/meetings/FOSDEM_2012]]: <antrik> right +# IRC, freenode, #hurd, 2012-02-19 + + <youpi> antrik: we should probably add a gsoc idea on pci bus arbitration + <youpi> DDE is still experimental for now so it's ok that you have to + configure it by hand, but it should be automatic at some ponit + + +## IRC, freenode, #hurd, 2012-02-21 + + <braunr> i'm not familiar with the new gnumach interface for userspace + drivers, but can this pci enumerator be written with it as it is ? + <braunr> (i'm not asking for a precise answer, just yes - even probably - + or no) + <braunr> (idk or utsl will do as well) + <youpi> I'd say yes + <youpi> since all drivers need is interrupts, io ports and iomem + <youpi> the latter was already available through /dev/mem + <youpi> io ports through the i386 rpcs + <youpi> the changes provide both interrupts, and physical-contiguous + allocation + <youpi> it should be way enough + <braunr> youpi: ok + <braunr> youpi: thanks for the details :) + <antrik> braunr: this was mentioned in the context of the interrupt + forwarding interface... the original one implemented by zhengda isn't + suitable for a PCI server; but the ones proposed by youpi and tschwinge + would work + <antrik> same for the physical memory interface: the current implementation + doesn't allow delegation; but I already said that it's wrong + + # IRC, freenode, #hurd, 2012-02-20 <youpi> I was a bit wary of including the ton of dde headers in hurd-dev @@ -374,3 +405,49 @@ At the microkernel davroom at [[community/meetings/FOSDEM_2012]]: <youpi> because hardware is slow anyway <ArneBab> jupp <ArneBab> but it is important to see that in real life + + +# IRC, freenode, #hurd, 2012-04-01 + + <youpi> antrik: I wonder whether you could actually not route the IRQs to a + non-zero ring, AIUI you can in the x86 IDT table + <antrik> youpi: you mean having a userspace server for each (non-timer) + interrupt? + <antrik> youpi: how would a userspace IRQ handler interact with the + scheduler? + <youpi> antrik: it doesn't necessarily have to + <youpi> provided that it's trusted + <antrik> youpi: how would you do CPU time accounting if there is no + interaction with the scheduler?... + <youpi> antrik: you don't necessarily want to care about it + <antrik> youpi: well, that would mean that all drivers handling interrupts + would have to be trusted to not use more than a very small part of CPU + time... + <youpi> yes + <youpi> which is usually needed for interrupt handlers anyway + <antrik> youpi: nah, the bottom handler only has to do very basic stuff; + afterwards, we can pass off to "normal" driver processes, scheduled just + like other processes... but that requires some interaction between the + IRQ handler and the scheduler I think + <youpi> the IRQ handler can wake up a thread, yes + <youpi> no need for anything special there + <antrik> so the userspace IRQ server would just decide what process to wake + up, and then call the scheduler to do a normal task switch? I guess + that's possible; but I'm not sure it would buy much... + <youpi> it would permit userland to quickly react to the IRQ + <youpi> such as acknowledge it to the hardware etc. + <antrik> yeah, but my point is that I don't see much benefit in having this + part of the code isolated in a userspace process... it has to be trusted + anyways, and it's pretty trivial too + <youpi> I never said it was a good idea + + +# IRC, freenode, #hurd, 2012-04-06 + + <braunr> oh i forgot about my work on pcap + <braunr> is devnode (or devopen or whatever) in the upstream repository now + ? + <antrik> can't say for sure, but I'd be surprised... don't remember seeing + any movement in that regard :-( + <braunr> wasn't it needed for dde ? + <antrik> hm... good point diff --git a/open_issues/extern_inline.mdwn b/open_issues/extern_inline.mdwn index a56d4902..a3a22b16 100644 --- a/open_issues/extern_inline.mdwn +++ b/open_issues/extern_inline.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2012 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 @@ -10,7 +10,10 @@ License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] -IRC, unknown channel, unknown date. +[[!toc]] + + +# IRC, unknown channel, unknown date <tschwinge> youpi: Did you ever review the Savannah hurd branch master-fix_extern_inline? <youpi> why static inlines instead of extern lines ? @@ -72,3 +75,35 @@ IRC, unknown channel, unknown date. <youpi> especially since the semantic has changed over time and according to standards :) <tschwinge> And then GCC changing that according to C99. <tschwinge> Yes. + + +# IRC, freenode, #hurd, 2012-03-14 + + <youpi> + http://anonscm.debian.org/gitweb/?p=pkg-hurd/hurd.git;a=blob;f=debian/patches/extern_inline_fix.patch;h=b9eacbff97dc56e99a69ddb601a5fc948f6e44a7;hb=HEAD + <youpi> maybe review it, and then we apply it + <pinotree> + http://patch-tracker.debian.org/patch/series/view/hurd/20120222-1/extern_inline_fix.patch + ;) + <civodul> youpi: the #ifdef __USE_EXTERN_INLINES in there and the extra + "extern" decls look wrong to me + <youpi> iirc USE_EXTERN_INLINES is needed + <youpi> otherwise it's not compliant + <youpi> or maybe it's for -O0 + <youpi> anyway IIRC it's needed + <civodul> when !defined __USE_EXTERN_INLINES, you end up with extern decls + with no corresponding definition + <youpi> yes + <youpi> they are defined in the code + <civodul> where? + <youpi> there's a special .c file in each lib + <youpi> libdiskfs/extern-inline.c + <youpi> etc + <civodul> oooh, right + <youpi> extern inline means that anyway + <youpi> the compiler is allowed to not always inline + <civodul> yes + <civodul> that looks good to me, then + <civodul> youpi: can you apply it, with proper authorship & co.? + <civodul> (no rush, though) + <youpi> sure diff --git a/open_issues/file_system_exerciser.mdwn b/open_issues/file_system_exerciser.mdwn index 4277e5e7..c51863b9 100644 --- a/open_issues/file_system_exerciser.mdwn +++ b/open_issues/file_system_exerciser.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 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 @@ -13,3 +13,17 @@ License|/fdl]]."]]"""]] Test our file system implementations with the File System Exerciser. * <http://codemonkey.org.uk/projects/fsx/> + + +# Alternatives + + +## fs_mark + + +### IRC, freenode, #hurd, 2012-04-30 + + <pinotree> mcsim: http://sourceforge.net/projects/fsmark/ + <pinotree> mcsim: just saw it in debian's NEW queue and from the + description it seemed like something it could be helpful for you + <pinotree> (and in general to test fs'es) diff --git a/open_issues/fork_deadlock.mdwn b/open_issues/fork_deadlock.mdwn new file mode 100644 index 00000000..6b90aa0a --- /dev/null +++ b/open_issues/fork_deadlock.mdwn @@ -0,0 +1,65 @@ +[[!meta copyright="Copyright © 2012 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_glibc]] + +This started appearing when Jérémie's [[glibc]] signal patches were integrated: +very sporadically, but still now and then, `fork` will hang, as follows, and +typically in `/bin/sh`. + +From a `libtool` invocation: + + #0 0x0107b13c in swtch_pri () at /build/eglibc-Q9jlik/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x0107c9c4 in __spin_lock_solid (lock=0x125080c) at spin-solid.c:27 + No locals. + #2 0x01091427 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55 + No locals. + #3 _hurd_sigstate_lock (ss=0x1250008) at hurdsig.c:172 + No locals. + #4 0x011261ec in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235 + No locals. + #5 __fork () at ../sysdeps/mach/hurd/fork.c:706 + env = {{__jmpbuf = {18784244, 19197896, 1, 16925832, 16925460, 17980399}, __mask_was_saved = 0, __saved_mask = 33}} + pid = 0 + err = <optimized out> + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1250008 + threads = 0x0 + nthreads = 0 + stopped = 1 + i = 6 + [...] + + +Another one in `dash`: + + #0 0x0105927c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x0105ac44 in __spin_lock_solid (lock=0x123580c) at spin-solid.c:27 + No locals. + #2 0x010701c7 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55 + No locals. + #3 _hurd_sigstate_lock (ss=0x1235008) at hurdsig.c:172 + No locals. + #4 0x011048f0 in _hurd_critical_section_unlock (our_lock=0x1235008) at ../hurd/hurd/signal.h:235 + ss = 0x1235008 + pending = <optimized out> + #5 __fork () at ../sysdeps/mach/hurd/fork.c:706 + env = {{__jmpbuf = {18780148, 19087304, 134621988, 0, 16938700, 17842902}, __mask_was_saved = 0, __saved_mask = 4294967295}} + pid = 0 + err = 0 + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1235008 + threads = 0x0 + nthreads = 0 + stopped = 1 + i = 6 + [...] diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index b15c880a..1ce47560 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -39,29 +39,12 @@ git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..sourcewa Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 (2012-02-28) sources|source_repositories/glibc]]. - * t/dup3 - - [[tschwinge]] is not convinced that - 22542dcc89805af8d9bd9209129259d2737372b5 (and then also - ff3f3a789ba08b656dbaa3901091b6410bb883f8) are correct. - - * 94b7cc3711b0b74c1d3ae18b9a2e019e51a8e0bf -- dup3 changes; relevant for - `t/dup3`: hidden def. ed690b2f24bbc4d9c541fc81a7c67e6dc5678a96 -- why - not for dup3, too? Because it is a syscall (that is always inlined)? - * `t/hurdsig-fixes` hurdsig.c: In function '_hurd_internal_post_signal': hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized] hurdsig.c:1168:12: note: 'pending' was declared here - * `t/init-first.c` - - Follow up here: [[!message-id "20070722171859.GN25744@fencepost.gnu.org"]] - or [[!message-id "87mxe4kwws.fsf@gnu.org"]]. Close [[!GNU_Savannah_bug - 17647]]. Debian: [[!message-id "E1Qup1U-0006Zc-39@vasks.debian.org"]] - (part of Ludo's patch; the part that is not harmful to GCC 4.4). - * `t/kernel-features.h_includes` Before running `tg update`, review for additional changes: @@ -202,11 +185,88 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 `CLOCK_REALTIME_ALARM`, `O_PATH`, `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27), `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`) - `clock_adjtime`, `fallocate`, `fallocate64`, `getcontext` (and - `setcontext`), `name_to_handle_at`, `open_by_handle_at`, - `process_vm_readv`, `process_vm_writev`, `sendmmsg`, + `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`, + `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `sendmmsg`, `setns`, `sync_file_range` + * `chflags` + + IRC, OFTC, #debian-hurd, 2012-04-27: + + <Steap> Does anyone have any idea why int main(void) { return + chflags(); } will compile with gcc but not with g++ ? It says + that "chflags" was not declared in this scope. + <Steap> I get the same error on FreeBSD, but including sys/stat.h + makes it work + <Steap> Can't find a solution on Hurd though :/ + <youpi> the Hurd doesn't have chflags + <youpi> apparently linux neither + <youpi> what does it do? + <Steap> change flags :) + <Steap> Are you sure the Hurd does not have chflags ? Because gcc + does not complain + <youpi> there is no chflags function in /usr/include + <youpi> but what flags does it change? + <Steap> According to the FreeBSD manpage, it can set flags such as + UF_NODUMP, UF_IMMUTABLE etc. + <youpi> Hum, there is actually a chflags() definition + <youpi> but no declaration + <youpi> so actually chflags is supported, but the declaration was + forgotten + <youpi> probably because since linux doens't have it, it has never + been a problem up to now + <youpi> so I'd say ignore the error for now, we'll add the + declaration + + * `getcontext`/`setcontext` + + Needed for [[gccgo]]. + + IRC, freenode, #hurd, 2012-04-19: + + <gnu_srs> How much work/knowledge is needed to implement + getcontext/setcontext? + <gnu_srs> Any already implemented alternatives available? + <youpi> x86 registers knowledge, as well as unix signal masks + <youpi> there's the linux implementation that can be taken as an + exxample, but the signal part has to be rewritten + <gnu_srs> Well, it's a pity they are not implemented. That's the + remaining hurdle to get gccgo working :-( + <youpi> uh :/ + <gnu_srs> Everything builds, but the testsuite fails due to these + missing functions. + <gnu_srs> Regarding getcontext/setcontext they seem to be written + in assembly for linux but the code is not very long. + <gnu_srs> How much effort would it be to write something similar + for Hurd? Anybody fluent in asm? + <gnu_srs> And registers and signals. + <tschwinge> gnu_srs: Signals is the key thing -- everything else we + can probably just copy. I have never/not yet looked at it, + though. + <gnu_srs> For kfreebsd it is written in C: kern_context.c, 3/4 in + one file: getcontext, setcontext, swapcontext, not makecontext. + <gnu_srs> Dunno how much assembly calls used though. + <gnu_srs> Hi, any preferences about implementing get/setcontext in + C or Asm? + <tschwinge> gnu_srs: I think these will have to be implemented in + assembly. Based on the Linux x86 variants. + + IRC, freenode, #hurd, 2012-04-20: + + <tschwinge> youpi: Your understanding of that is better than mine + -- the *context stuff can't be very useful at the moment, because + when the user changes uc_stack.ss_sp (which the glibc tests are + doing), we're losing access to the _hurd_threadvars. Correct? + <tschwinge> At least the getcontext test works, the other get a + SIGILL. + <tschwinge> others + <tschwinge> _hurd_threadvars issue is just guessing. + <youpi> tschwinge: yes, threadvars are on the stack + <youpi> threadvars is not much code, it should just work, but care + has to be taken on the libpthread/libthread side, which does some + initialization + <tschwinge> OK, that at least matches my understanding. + * `syncfs` We should be easily able to implement that one. @@ -264,6 +324,35 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14 * `timespec_get` (74033a2507841cf077e31221de2481ff30b43d51) + * `waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`) + + IRC, freenode, #hurd, 2012-04-20: + + <pinotree> in glibc, we use the generic waitflags.h which, unlike + linux's version, does not define WEXITED, WNOWAIT, WSTOPPED, + WCONTINUED + <pinotree> should the generic bits/waitflags.h define them anyway, + since they are posix? + <youpi> well, we'd have to implement them anyway + <youpi> but otherwise, I'd say yes + <pinotree> sure, but since glibc headers should expose at least + everything declared by posix, i thought they should be defined + anyway + <youpi> that might bring bugs + <youpi> some applications might be #ifdefing them + <youpi> and break when they are defined but not working + <pinotree> i guess they would define them to 0, andd having them to + non-zero values shouldn't break them (since those values don't do + anything, so they would act as if they were 0.. or not?) + <youpi> no, I mean they would do something else, not define them to + 0 + <pinotree> like posix/tst-waitid.c, you mean? + <youpi> yes + + For specific packages: + + * [[octave]] + * Create `t/cleanup_kernel-features.h`. * Add tests from Linux kernel commit messages for `t/dup3` et al. diff --git a/open_issues/glibc/getlogin_r.mdwn b/open_issues/glibc/getlogin_r.mdwn new file mode 100644 index 00000000..9980ea1f --- /dev/null +++ b/open_issues/glibc/getlogin_r.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2012 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="getlogin_r"]] + +[[!tag open_issue_glibc]] + + +# IRC, freenode, #hurd, 2012-04-23 + + * pinotree spots how our getlogin_r() implementation uses a static + buffer... + <braunr> oO + <pinotree> braunr: yeah, the _r means "reentrantbutnotreally" xD + <braunr> pinotree: that's amazing .. + <antrik> pinotree: without having checked the actual implementation, that + doesn't sound like a problem... + <antrik> caching doesn't break reentrancy. the problem with the plain + getlogin() is that a static buffer is *returned to the user* + <pinotree> antrik: http://paste.debian.net/164727/ + <braunr> ah, caching + <pinotree> i don't think this is caching at all + <antrik> pinotree: OK, not actually caching... but same effect as far as I + can tell + <antrik> pinotree: or is it the fixed size of the temporary variable you + are concerned about? + <pinotree> antrik: my concern was about the "static" of the buffer used for + the get_login rpc + <antrik> pinotree: I'm not sure that's a problem. can the login actually + ever change for a running process? + <pinotree> dunno + <pinotree> but if so, it would be pointless to do the rpc every time + instead of just once + <antrik> pinotree: true + * pinotree would just make it non-static and be safe + <antrik> pinotree: well, one might argue that allocating a KiB of stack + space is not very friendly, especially in a low-level library... + <antrik> not sure what the general policy is about such things in libc diff --git a/open_issues/glibc/octave.mdwn b/open_issues/glibc/octave.mdwn new file mode 100644 index 00000000..b12b7558 --- /dev/null +++ b/open_issues/glibc/octave.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2012 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_glibc]] + + +# IRC, OFTC, #debian-hurd, 2012-04-23 + + <pinotree> diffing the octave i386 vs hurd-i386 build logs gives + interesting surprises + <youpi> checking whether this system has an arbitrary file name length + limit... no | checking whether this system has an arbitrary + file name length limit... yes + <youpi> ? + <pinotree> not only that + <youpi> checking whether getcwd handles long file names properly... yes + | checking whether getcwd handles long file names properly... no, but it + is partly worki+ + <youpi> ? + <pinotree> -checking whether fdopendir works... yes + <pinotree> +checking whether fdopendir works... no + <pinotree> (- is i386, + is hurd-i386) + <pinotree> -checking whether getlogin_r works with small buffers... yes + <pinotree> +checking whether getlogin_r works with small buffers... no + <pinotree> -checking for working mkstemp... yes + <pinotree> +checking for working mkstemp... no + <pinotree> +checking for working nanosleep... no (mishandles large + arguments) diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index d29e316c..9feb30c8 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -2101,3 +2101,35 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. branch in master ? <youpi> I was considering as soon as mcsim gets his paper <braunr> right + + +# IRC, freenode, #hurd, 2012-02-22 + + <mcsim> Do I understand correct, that real memory page should be + necessarily in one of following lists: vm_page_queue_active, + vm_page_queue_inactive, vm_page_queue_free? + <braunr> cached pages are + <braunr> some special pages used only by the kernel aren't + <braunr> pages can be both wired and cached (i.e. managed by the page + cache), so that they can be passed to external applications and then + unwired (as is the case with your host_slab_info() function if you + remember) + <braunr> use "physical" instead of "real memory" + <mcsim> braunr: thank you. + + +# IRC, freenode, #hurd, 2012-04-22 + + <braunr> youpi: tschwinge: when the slab code was added, a few new files + made into gnumach that come from my git repo and are used in other + projects as well + <braunr> they're licensed under BSD upstream and GPL in gnumach, and though + it initially didn't disturb me, now it does + <braunr> i think i should fix this by leaving the original copyright and + adding the GPL on top + <youpi> sure, submit a patch + <braunr> hm i have direct commit acces if im right + <youpi> then fix it :) + <braunr> do you want to review ? + <youpi> I don't think there is any need to + <braunr> ok diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn new file mode 100644 index 00000000..75fcdd88 --- /dev/null +++ b/open_issues/gnumach_page_cache_policy.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2012 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_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-26 + + <braunr> another not-too-long improvement would be changing the page cache + policy + <youpi> to drop the 4000 objects limit, you mean ? + <braunr> yes + <youpi> do you still have my patch attempt ? + <braunr> no + <youpi> let me grab that + <braunr> oh i won't start it right away you know + <braunr> i'll ask for it when i do + <youpi> k + <braunr> (otherwise i fell i'll just loose it again eh) + <youpi> :) + <braunr> but i imagine it's not too hard to achieve + <youpi> yes + <braunr> i also imagine to set a large threshold of free pages to avoid + deadlocks + <braunr> which will still be better than the current situation where we + have either lots of free pages because tha max limit is reached, or lots + of pressure and system freezes :/ + <youpi> yes diff --git a/open_issues/gnumach_rpc_timeouts.mdwn b/open_issues/gnumach_rpc_timeouts.mdwn new file mode 100644 index 00000000..68cfcb5a --- /dev/null +++ b/open_issues/gnumach_rpc_timeouts.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2012 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_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-28 + + <pinotree> uhm, apparently mach cannot handle timeouts for rpc's of more + than (2^(sizeof(mach_msg_timeout_t) * 8) - 1) / HZ + <pinotree> it seems that how ticks are calculated in mach, it becomes 0 + <pinotree> +because of diff --git a/open_issues/gnumach_vm_map_red-black_trees.mdwn b/open_issues/gnumach_vm_map_red-black_trees.mdwn new file mode 100644 index 00000000..17263099 --- /dev/null +++ b/open_issues/gnumach_vm_map_red-black_trees.mdwn @@ -0,0 +1,154 @@ +[[!meta copyright="Copyright © 2012 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_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-23 + + <braunr> btw, i'm running a gnumach version using red-black trees for vm + map entries + <antrik> braunr: sounds fashionable ;-) + <youpi> braunr: with some perf improvement? + <braunr> looks promising for our ext2fs instances showing several thousands + of map entries + <braunr> youpi: i'm not using it for lookups yet + <braunr> but the tree is there, maintained, used for both regular and copy + maps, and it doesn't crash + <youpi> good :) + <braunr> antrik: isn't it ? :) + <braunr> youpi: and the diff stat is like 50/15 + <antrik> braunr: what's the goal of using the fashionable trees? + <braunr> antrik: speeding up lookups in address spaces + <antrik> braunr: so the idea is that if we have a heavily fragmented + address space, the performance penalty is smaller? + <braunr> yes + <antrik> OK + <antrik> I take it you gave up on attempts to actually decrease + fragmentation?... + <braunr> it's not as good as reducing fragmentation, which requires + implementing a powerful merge, but it's still better + <braunr> yes + <braunr> it's too messy for my brain :/ + <antrik> I see + <antrik> oh + <braunr> it will add some overhead though + <youpi> I guess log(n) ? + <braunr> but if there is a significant performance gain, it'll be worth it + <braunr> yes + <braunr> i was more thinking about the memory overhead + <antrik> right now it's a linear list? + <youpi> I don't think we care nowadays :) + <braunr> antrik: yes + <antrik> ouch + <braunr> antrik: yes ... :> + <braunr> the original authors expected vm maps to have like 30 entries + <braunr> so they used a list for the maps, and a hash table for the + object/offset to physical page lookups + <braunr> there is a small lookup cache though, which is a nice optimization + <braunr> my code now uses it first, and falls back to the RB tree if the + hint didn't help + <antrik> braunr: well, don't forget to check whether it actually *is* still + an optimisation, when using fashionable trees ;-) + <braunr> antrik: i checked that already :) + <braunr> i did the same in x15 + <antrik> I see + <braunr> both bsd and linux uses a similar technique + <braunr> use* + <braunr> (well, bsd actually use what is done in mach :) + <antrik> (or perhaps the other way around... ;-) ) + <braunr> i don't think so, as the bsd vm is really the mach vm + <braunr> but we don't care much + <antrik> oh, right... that part actually went full circle + <braunr> youpi: i have a patch ready for test on machines with significant + amounts of map entries (e.g. the buildds ..) + <braunr> youpi: i won't have time for tests tonight, are you interested ? + <braunr> (i've been running it for 15 minutes without any issue for now) + <youpi> I'd say post to the list + <braunr> ok + <youpi> braunr: your patch uses the rb tree for lookups, right? + <youpi> braunr: the buildd using rbtree seems swift + <youpi> but maybe it's just a psychologic effect :) + <youpi> the chroot ext2fs already has 1392 lines in vminfo + <youpi> an rbtree can't hurt there :) + <youpi> braunr: it really seems faster + <youpi> the reboot might have helped too + <youpi> benchmarks shall say + <youpi> for now, I'll just let ironforge use it + <antrik> youpi: it's always fast after a reboot ;-) + <youpi> sure + <youpi> but still + <youpi> I mean + <youpi> *obviously* the reboot has helped + <youpi> but it might not be all + <youpi> at least it feels so + <youpi> and obviously only benchmarks can say + <antrik> the major benefit AIUI is rather that the slowdown happening over + time will be less noticable + +[[performance/degradation]]. + + <youpi> "over time" is actually quite fast + <youpi> ext2 fills up very quickly when you build a package + <youpi> it went up to 1700 lines very quickly + <youpi> and stabilized around there + <antrik> yeah, it can be very fast under heavy load + <youpi> that's why I say reboot seems not all + <youpi> it's already not so fresh + <youpi> with 1700 lines in vminfo + <antrik> well, I don't know how much of the slowdown I'm experiencing + (after doing stuff under memory pressure) is actually related to VM map + fragmentation... + <antrik> might be all, might be none, might be something in between + <youpi> then try his patch + <antrik> guess I should play a bit with vminfo... + <antrik> well, currently I actually experience pretty little slowdown, as + for certain reasons (only indirectly related to the Hurd) I'm not running + mutt on this machine, so I don't really have memory pressure... + + +## IRC, freenode, #hurd, 2012-04-24 + + <braunr> youpi: yes, it uses bst lookups + <braunr> youpi: FYI, the last time i checked, one ext2fs instance had 4k+ + map entries, and another around 7.5k + <braunr> (on ironforge) + + +## IRC, freenode, #hurd, 2012-04-24 + + <youpi> braunr: $ sudo vminfo 624 | wc -l + <youpi> 22957 + <youpi> there's no way it can not help :) + <braunr> youpi: 23k, that's really huge + + +## IRC, freenode, #hurd, 2012-04-26 + + <braunr> youpi: any new numbers wrt the rbtree patch ? + <youpi> well, buildd times are not really accurate :) + <youpi> but what I can tell is that it managed to build qtwebkit fine + <braunr> ok + <youpi> so the patch is probably safe :) + <braunr> i'll commit it soon then + <youpi> I'd say feel free to, yes + <braunr> thanks + + +## IRC, freenode, #hurd, 2012-04-27 + + <braunr> elmig: don't expect anything grand though, this patch is mostly + useful when address spaces get really fragmented, which mainly happens on + buildds + <braunr> (and it only speeds lookups, which isn't as good as reducing + fragmentation; things like fork still have to copy thousands of map + entries) + +[[glibc/fork]]. diff --git a/open_issues/largefile.mdwn b/open_issues/largefile.mdwn new file mode 100644 index 00000000..a6f76a0e --- /dev/null +++ b/open_issues/largefile.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2012 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_hurd]] + + +# IRC, freenode, #hurd, 2012-04-26 + + <pinotree> i kind of understood why (at least in some parts) largefile doesn't seem to work properly + <pinotree> libdiskfs/io-seek.c, SEEK_SET case: cred->po->filepointer = offset; + <pinotree> offset is off_t, which becomes off64_t when compiled with largefile, but filepointer seems to be... int + <pinotree> at least in libdiskfs/diskfs.h, while in libnetfs/netfs.h seems ok (loff_t) + <pinotree> diskfs.h is a public header though :/ + <youpi> well, we can change the soname to mark ABI change diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn index 614f1271..c5054b7f 100644 --- a/open_issues/libpthread.mdwn +++ b/open_issues/libpthread.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012 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 @@ -25,43 +26,19 @@ There is a [[!FF_project 275]][[!tag bounty]] on this task. [[!inline pages=community/gsoc/project_ideas/pthreads feeds=no]] +## IRC, freenode, #hurd, 2012-04-26 -# pthread/stubs issue w/ dlopen'ed libraries + <pinotree> youpi: just to be sure: even if libpthread is compiled inside + glibc (with proper symbols forwarding etc), it doesn't change that you + cannot use both cthreads and pthreads in the same app, right? -IRC, freenode, #hurd, 2010-01-24 +[[Packaging_libpthread]]. - <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed - libraries - <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs, - we're the only one with such configuration - <pinotree> i was looking at the gcc 4.4 patch hurd-pthread.diff, could it - be it does not set THREADLIBS in the configure.ac switch case? - <youpi> that's expected - <youpi> on linux the libc provides hooks itself, on hurd-i386 it's - pthread-stubs - <pinotree> why not explicitly link to pthread though? - <youpi> because there is no strict need to, for applications that don't - need libpthread - <youpi> the dlopen case is a tricky case that pthread-stubs had not thought - about - <pinotree> hm - <pinotree> what if the pthread stubs would be moved in our glibc? - <youpi> that's what we should do yes - <youpi> (ideally) - <youpi> but for this we need to build libpthread along glibc, to get it - really working - <youpi> and that's the tricky part (Makefile & such) which hasn't been done - yet - <pinotree> why both (stubs + actual libpthread)? - <youpi> because you need the stubs to be able to call the actual libpthread - <youpi> as soon libpthread gets dlopened for instance - <youpi> +as - <pinotree> i see - <youpi> (remember that nptl does this if you want to see how) - <youpi> (it's the libc files in nptl/) - <youpi> (and forward.c) - <guillem> also if libpthreads gets integrated with glibc don't we need to - switch the hurd from cthreads then? Which has been the blocker all this - time AFAIR? - <youpi> we don't _need_ to - <guillem> ok + <youpi> it's the same libpthread + <youpi> symbol forwarding does not magically resolve that libpthread lacks + some libthread features :) + <pinotree> i know, i was referring about the clash between actively using + both + <youpi> there'll still be the issue that only one will be initialized + <youpi> and one that provides libc thread safety functions, etc. + <pinotree> that's what i wanted to knew, thanks :) diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn new file mode 100644 index 00000000..f9195540 --- /dev/null +++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn @@ -0,0 +1,58 @@ +[[!meta copyright="Copyright © 2012 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="libpthread: CLOCK_MONOTONIC"]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +[[!message-id "201204220058.37328.toscano.pino@tiscali.it"]] + + +# IRC, freenode, #hurd- 2012-04-22 + + <pinotree> youpi: what i thought would be creating a + glib/hurd/hurdtime.{c,h}, adding _hurd_gettimeofday and + _hurd_clock_{gettime,settime,getres} to it and making the current .c in + sysdeps call those + <youpi> yep + <youpi> that's unfortunate, but that's what nptl actually does + <pinotree> this way we could add inside hurdtime.c the mapped time stuff + too + <pinotree> most probably a noobish question, but why does rt link to + pthread? + <youpi> no idea :) + <youpi> possibly due to aio implementation + <youpi> ./sysdeps/pthread/aio_cancel.c + <youpi> probably due to that + <youpi> (and others) + + +## IRC, freenode, #hurd- 2012-04-23 + + <youpi> pinotree: about librt vs libpthread, don't worry too much for now + <youpi> libpthread can lib against the already-installed librt + <youpi> it does work + <pinotree> youpi: wouldn't that cause a dependency loop? + <youpi> pinotree: what dependency loop? + <pinotree> youpi: librt wouldd link to pthread, no? + <youpi> and ? + <youpi> I don't think it's an issue that .so link with each other + <pinotree> it isn't? + <youpi> well, try + * pinotree never did that + <youpi> but I don't think it will pose problem + <youpi> well, perhaps initialization order + <youpi> anyway, I now have packages built, I'll test that + <youpi> pinotree: ok, it seems it doesn't work indeed :) + <youpi> early in initialization + <youpi> pinotree: the initialization bug might actually not be due to librt + at all + <youpi> pinotree: yes, things work even with -lrt + <pinotree> wow diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index fb665c67..05a07ef2 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 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 @@ -10,7 +10,52 @@ License|/fdl]]."]]"""]] [[!tag open_issue_libpthread]] -IRC, OFTC, #debian-hurd, 2011-07-21. +[[!toc]] + + +# IRC, freenode, #hurd, 2010-01-24 + + <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed + libraries + <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs, + we're the only one with such configuration + <pinotree> i was looking at the gcc 4.4 patch hurd-pthread.diff, could it + be it does not set THREADLIBS in the configure.ac switch case? + <youpi> that's expected + <youpi> on linux the libc provides hooks itself, on hurd-i386 it's + pthread-stubs + <pinotree> why not explicitly link to pthread though? + <youpi> because there is no strict need to, for applications that don't + need libpthread + <youpi> the dlopen case is a tricky case that pthread-stubs had not thought + about + <pinotree> hm + <pinotree> what if the pthread stubs would be moved in our glibc? + <youpi> that's what we should do yes + <youpi> (ideally) + <youpi> but for this we need to build libpthread along glibc, to get it + really working + +[[Packaging_libpthread]]. + + <youpi> and that's the tricky part (Makefile & such) which hasn't been done + yet + <pinotree> why both (stubs + actual libpthread)? + <youpi> because you need the stubs to be able to call the actual libpthread + <youpi> as soon libpthread gets dlopened for instance + <youpi> +as + <pinotree> i see + <youpi> (remember that nptl does this if you want to see how) + <youpi> (it's the libc files in nptl/) + <youpi> (and forward.c) + <guillem> also if libpthreads gets integrated with glibc don't we need to + switch the hurd from cthreads then? Which has been the blocker all this + time AFAIR? + <youpi> we don't _need_ to + <guillem> ok + + +# IRC, OFTC, #debian-hurd, 2011-07-21 <youpi> there's one known issue with pthreads <youpi> you can't dlopen() it diff --git a/open_issues/linux_as_the_kernel.mdwn b/open_issues/linux_as_the_kernel.mdwn index f14b777e..1d84d777 100644 --- a/open_issues/linux_as_the_kernel.mdwn +++ b/open_issues/linux_as_the_kernel.mdwn @@ -40,3 +40,198 @@ Richard's X-15 Mach re-implementation: the whole talk; but they mentioned similar possibilities to what I'm envisioning here :-) + +## IRC, freenode, #hurd, 2012-03-28 + + <mel__> is there currently any work going on with respect to + Mach-alternatives? + <antrik> mel__: no + <antrik> we have other priorities to take care of :-) + <braunr> antrik: i still intend to try giving linux a "mach personality" :) + <braunr> antrik: but i don't have much time for development currently :( + <mel__> antrik: which means that the hope is that Mach can be turned into + something really well working (i.e. secure/scalable/etc.)? + <antrik> mel__: yes, that's the venue we are pursuing + <antrik> (and IMHO the right one... though the Linux layer mentioned by + braunr is also one of my favourite projects, that we should pursue *in + parallel* to the existing Mach-based implementation) + <mel__> what is this Linux Layer exactly? + <mel__> a Linux instance running on top of Mach in parallel to Hurd + serverS? + <braunr> mel__: not exactly + <braunr> mel__: it would involve adding a mach layer on top of linux + actually + <braunr> mel__: so that linux can be used as a mach kernel + <mel__> Ah! + <mel__> Running Hurd on top of Linux + <mel__> :-D + <mel__> Funny + <braunr> ironic, yes + <braunr> but very pragmatic + <mel__> and THEN + <antrik> yeah. I most like the name: Hurd Emulation Layer on + Linux... i.e. HELL :-) + <mel__> we use a device driver framework something so that we can use Linux + device drivers in Hurd! + <mel__> on top of Linux.... + <braunr> yes + <braunr> i guess a transition phase would include using in kernel drivers + directly for a while + <mel__> and somebody is working on that? + <antrik> mel__: well, for using Linux drivers we are persuing DDE, which + allows us doing that with Mach as well + <braunr> then grabbing them out of the kernel and into dde + <braunr> not yet + <antrik> (in fact we have been using Linux drivers since forever... they + just haven't been updated for ages) + <mel__> I would _guess_ that it is not that hard. + <braunr> it's not + <mel__> Basically one would need to implement the message passing interface + thing in linux I guess. + <braunr> and many exported kernel objects like tasks, threads, etc.. + <braunr> and implement all the RPCs normally implemented by the kernel + <braunr> but it's doable + <antrik> mel__: the IPC aspect is one part, but probably the less tricky + one. the external pager interface is really the crucial element + <mel__> uh + <mel__> yeah + <mel__> hooking into linux virtual memory stuff + <mel__> sounds delicate + <braunr> it's true that some interactions between the linux VM and file + systems (the linux equivalent of our pagers) is synchronous + <braunr> but i don't think it would be that hard considering the amount of + facilities available in linux + <braunr> it's just work, takes time, needs debugging, reviewing, testing, + etc.. + <lcc> hurd on top of linux. how would that work? + <braunr> 15:30 < braunr> antrik: i still intend to try giving linux a "mach + personality" :) + <braunr> lcc: 7 system calls and a few hundreds of RPCs on top, the + internal magic of course, and voila .. + <antrik> of course porting Mach still requires work + <mel__> that would then be GNU/Hurd/Linux + <mel__> :-) + <antrik> hehe + <braunr> eh + <antrik> braunr: BTW, are you more thinking of a userspace solution on top + of standard Linux mechanisms, or additions to Linux itself?... + <antrik> (we probably talked about it already, but I don't remember all the + details...) + <braunr> antrik: adding to linux + <antrik> do you think a pure userspace solution would be realistic at all? + (at the expense of some performance of course) + <mel__> it's probably comparable to the qemu vs. qemu/kvm thing + <antrik> yeah, I guess that pretty much sums it up... + <braunr> antrik: i don't know :/ + <antrik> OK + <lcc> how challenging is it to port mach? + <antrik> lcc: it requires good low-level knowledge of the platform in + question. having that, I guess it shouldn't be too hard to add the + necessary code in Mach... + <antrik> TBH I'm not sure how much knowledge of Mach internals is required + <braunr> the pmap module is the main thing to port + <antrik> braunr: well, sartakov seemed to have most trouble with the + scheduler when he attempted the ARM port... + <braunr> that's strange + <antrik> at least there was quite a long thread where he asked about how + task switching works in Mach + <braunr> ok + <braunr> that would be interesting + <braunr> i thought intereacting with the hardclock was enough + + +## IRC, freenode, #hurd, 2012-04-05 + + <braunr> antrik: don't you think HELL is worth a try for the GSoC btw ? + <antrik> braunr: definitely. I haven't managed to rework the project ideas + list at all this year... but it's something I wanted there for a long + time + + <youngrw> just out of curiousity, what is HELL ? + <antrik> Hurd Emulation Layer on Linux + <braunr> youngrw: it can be described in several ways + <braunr> youngrw: basically, it's a mach interface on top of linux + <youngrw> implementing I suppose both the IPC mechanism and memory + management interface? + <mel__> youngrw: basically that. more generally: implement everything in + order to let Hurd run on that layer. + <antrik> well, it's slightly more complicated in my view... it's basically + anything that allows running a Hurdish environment on top of + GNU/Linux. it might be simply an implementation/emulation of Mach + mechanisms; but it also *might* work on a slightly higher level... + <youngrw> antrik: how might HELL operate at the slighty higher level like + you describe? + <antrik> let's call it low-level HELL and high-level HELL ;-) + <antrik> (a more descriptive name would be hurdenv... but HELL is so much + more catchy :-) ) + <antrik> so, high-level HELL... basically, the idea would be not to emulate + the kernel facilities and run all the real Hurd servers; but instead to + use special servers implementing the Hurd interfaces, but on top of + standard Linux facilities + <antrik> hurdish programs could run in such an environment, as long as they + aren't too low-level + <antrik> I wonder whether generic RPC interfaces could be implemented with + some side channel tunneled though the ordinary Linux FS interfaces... + <antrik> so translators would be loaded as FUSE modules for example, but + could still present generic interfaces + <youngrw> That's actually pretty different from what I was expecting + <antrik> what were you expecting? + <youngrw> maybe something where the entire kernel interface is emulated by + a running user process, like a kind of virtual machine + <youngrw> I hope that makes sense--I may be using my words incorrectly. + <antrik> youngrw: that would be in the low-level HELL category + <youngrw> antrik: right; I had the misconception that the level was defined + by how it made use of the underlying linux system + <youngrw> and that different HELL designs would always implement the mach + interface + + +## IRC, freenode, #hurd, 2012-04-06 + + <braunr> antrik: i think we have diverging ideas about how to use linux for + the hurd + <braunr> antrik: what you seem to want are really emulation componants, + like e.g. ext2fs and pfinet actually using the linux implementation + <braunr> (correct me if i'm mistaken) + <braunr> whereas my project is to make linux behave as a mach clone + <antrik> braunr: as I said, I consider both variants -- either a high-level + HELL or a low-level HELL + <braunr> ok + <antrik> (or perhaps a mix of both) + <braunr> a mix would be best imho + <antrik> yeah, probably + <braunr> so we have the real hurd, the real mach interface, and a set of + native translators (e.g. ext2fs) along some emulating their functionality + using linux code (e.g. a hypothetical ext4fs) + <antrik> I don't think we would have emulation servers for individual Linux + filesystems. rather, a generic server interfacing with the Linux VFS + tree... + <braunr> ok + + <antrik> braunr: BTW, I think I mentioned a couple of years ago that the + most realistic route towards a modern Mach in my opinion would be taking + a modern BSD (or Linux), and redo what the original Mach developers did + -- i.e. add the Mach-specific features, and drop the unnecessary UNIX + stuff + <braunr> antrik: :) + <braunr> we had discussions about it some time ago yes + <antrik> later I realised that it's better *not* to drop the UNIX + interfaces, but rather to keep them in parallel :-) + <braunr> antrik: for what purpose ? + <braunr> (i can imagine a few, but i'd like to know your idea) + <antrik> for the purpose of HELL :-) + <braunr> well hell would be the implementation, but what do you keep these + unix interfaces for ? + <antrik> i.e. people being able to play around with a Hurd environment + while staying with their existing system + <braunr> yes, i see + <braunr> i was considering doing that for development, yes + <braunr> uml first, and then i realized i wouldn't need it :) + <braunr> then i remembed netbsd and its syscall emulation layer + <antrik> also we might leverage some "foreign" userspace infrastructure + that way, such as udev + <antrik> (in the case of Linux that is... not sure whether NetBSD has + something similar at all ;-) ) + <braunr> i'll have to check, it's been a long time since i've really used + it + <braunr> they must use a pure devfs instance now diff --git a/open_issues/mission_statement.mdwn b/open_issues/mission_statement.mdwn index d136e3a8..17f148a9 100644 --- a/open_issues/mission_statement.mdwn +++ b/open_issues/mission_statement.mdwn @@ -47,3 +47,614 @@ License|/fdl]]."]]"""]] <antrik> heh, nice: http://telepathy.freedesktop.org/wiki/Rationale <antrik> most of this could be read as a rationale for the Hurd just as well ;-) + + +# IRC, freenode, #hurd, 2012-04-06 + + <braunr> LibreMan: the real feature of the hurd is its extensibility + +[[/Extensibility]], [[/advantages]]. + + <braunr> LibreMan: (though it could be improved even further) + <LibreMan> braunr: yeah, I keep reading that ... but that sounds too + abstract, I can not imagine what useful could that provide to the actual + users + <braunr> LibreMan: say fuse, but improved + <braunr> LibreMan: do you see how useful fuse is ? + <braunr> if so, you shouldn't have trouble imagining the gap between linux + without fuse and linux with fuse is about the same as linux with fuse and + the hurd + <braunr> and yes, it's abstract + <braunr> translators are not only about file systems + <LibreMan> braunr: well, its main advantage is that it's running in + user-space and therefore doesn't need root priviledges to mount whatever + fs you want? + <braunr> no + <braunr> you don't need to change the kernel, or implement weird tricks to + get what you want working + <LibreMan> braunr: okay, but there is fuse for Linux ... so the + difference/advantages need to be between Linux WITH fuse and Hurd + <braunr> that's what i'm saying + <LibreMan> the issue I have is that I do not see why anyone would have any + incentive to switch to Hurd + <braunr> there isn't much, which is why we stick with unix instead of, + e.g. plan9 or other advanced systems + <pinotree> try to use fuse on a server where there is no fuse installed + <LibreMan> if I want fuse-like functionallity I just install FUSE, no need + for Hurd ... so the reson to use it is not there + <braunr> LibreMan: read what i wrote + <braunr> using the hurd compared to using linux with fuse is about the same + as using linux with fuse compared to using linux without fuse + <LibreMan> braunr: ah, sorry ... I see + <braunr> it's a step further + <braunr> in theory, developers can add/remove the components they want, + making system development faster and more reliable + <braunr> where with unix, you need stuff like user mode linux or a virtual + machine + <LibreMan> braunr: but in practice it was the opposite so far :) + <braunr> not really + <braunr> it's a lack of manpower + <braunr> not a problem of partice versus theory + <braunr> practice* + <LibreMan> braunr: what do you think are the reasons why Hurd developement + is so slow if it should be faster in theory? + +[[faq/how_many_developers]]. + + <braunr> 17:30 < braunr> it's a lack of manpower + <braunr> pay someone to do the job + <braunr> :p + <LibreMan> braunr: then why does Linux get the manpower but Hurd doesn't? + <braunr> $$ + <LibreMan> braunr: ?? + <braunr> linux developers are paid + <LibreMan> because companies are using it :) + <braunr> yes + <LibreMan> why are they not using Hurd then? + <braunr> because it wasn't reliable enough + <LibreMan> Linux wasn't either at some point + <braunr> sure + <braunr> but when it became, the switch towards its use began + <braunr> now that they have something free and already working, there is no + point switching again + <LibreMan> paid devs join only AFTER volunteers got it to the stage that it + was useful to companies + <braunr> well linux was easier to develop at the beginning (and is still + today because of several kernel hacking features) + <braunr> it followed the traditional unix model, nothing was really new + about it + <LibreMan> braunr: exactly! that's why I think that Hurd needs to have very + compelling technical advantages to overcome that barrier + <braunr> few people/companies really care about such technical advantages + <braunr> they don't care if there are ugly tricks to overcome some problems + <LibreMan> you mean about such that Hurd can provide, right? + <braunr> it's not elegant, but most of the time they're not even aware of + it + <braunr> yes + <LibreMan> that's eaxctly my point ... most people do not care if it's + "elegant" from a programmers POV, they care whether it WORKS + <braunr> well yes + <braunr> what's your point ? + <LibreMan> all I see about Hurd is how "elegant" it is ... but that doesn't + matter if it doesn't provide any practical advantages + <braunr> you want us to expose a killer feature amazing enough to make the + world use our code ? + <LibreMan> well, I want Hurd to succeed and try to identify the resons it + doesn't + <braunr> it does, but not to the point of making people use it + <braunr> unix *is* good enough + <braunr> same reason plan9 "failed" really + <LibreMan> define your idea of Hurd succeeding then, I thought it was to + make it useful to the point that people use it :) + <braunr> there are many other attempts to make better system architectures + <braunr> it is + <braunr> people are still using windows you know, and i really don't see + why, but it does the work for them + <LibreMan> <braunr> you want us to expose a killer feature amazing enough + to make the world use our code ? --- YES ;) + <braunr> other people can think about the same between unix and the hurd + <braunr> LibreMan: well too bad, there is none, because, again, unix isn't + that bad + <braunr> it doesn't prevent us from making a better system that is usable + <LibreMan> to explain my take on this - there are two kind of people, those + who care about philosophy behind software (and its consequences, FSF + etc.) and those who don't + <LibreMan> it's the job of those who do care to make the sw so good that + those who do not care switch to it = victory :) + <LibreMan> as I said the reasons I want Hurd to succeed are more + "political" than technical ... I do not know how many Hurd devs agree + with that kind of sentiment but I'd rather want a GNU project to be in + the forefront than that of a "benevolent dictator" that doesnt' really + care about user freedom + <LibreMan> from thechnical POV I agree that Linux isn't that bad ... it's + quite good, it's the "behind the scenes" stuff I do not like about it + <LibreMan> I'm kind of confused right now ... what exactly is to point of + Hurd then? I thought it was to make it good enough or better than Linux + so users start using it (privatly or corporate) + <LibreMan> is this just a research project that isn't intended to be used + by "general population"? + <braunr> LibreMan: it's an operating system project + <braunr> some people try to make it as good as it can be, but it's not easy + <braunr> it's not a pet or research only system + <LibreMan> braunr: I see what it is ... I'm struggling to see what is the + point of it being an "OS project", what's its intended purpose + <braunr> but it doesn't suit all the needs for a general OS yet + <braunr> LibreMan: a general purpose OS like most free unices + <LibreMan> what are the motivations behind making it as good as it can be + <braunr> for us developers ? + <LibreMan> yes + <braunr> for me, the architecture + <LibreMan> whe you say that linux is goos enough then what's the point? + <braunr> we can do better + <LibreMan> for you it's just a hobby that doesn't have any real goal except + challenging yourself to do it? + <braunr> because of lack of time, you could say that + <LibreMan> so you want Hurd to challenge Linux one day, right? + <braunr> challenging isn't the point + <braunr> i'd like to be able to use it for my needs + <LibreMan> well, that wasn't the right choise of word but to be better than + Linux + <braunr> again, you miss the point + <braunr> i don't care much about hurd vs linux + <LibreMan> your own needs, so you do not want others to use it? + <braunr> i care about the hurd and what i do + <braunr> others would think the same + <braunr> they would want it to work for their needs + <LibreMan> I'm asking about you, do YOU want others to use it? is that one + of your goals? + <braunr> not really + <braunr> i let them do what they want + <LibreMan> ah I see, so it is kind of a hobby project for you - you're + doing to for yourself and your own needs + <LibreMan> and don't care if anyone else uses it or not + <braunr> yes, i don't care much about the politics around such projects tb + <braunr> tbh + <LibreMan> is this kind of sentiment prevalent is the Hurd dev community? + <braunr> i don't work on software to break any benevolent dictator or + anyone in particular + <braunr> i don't know + <braunr> i'd say so, yes + <braunr> but not sure + <braunr> i'm not saying they don't care about freedom, don't get me wrong + <braunr> i'd say we sure prefer free software over open source + <braunr> but i don't think people work on the hurd specifically for these + reasons, rather than the technical ones + <LibreMan> interesting ... from the presentation of the project by + outsiders I got the impression that it is significantly about freedom, + GNU - that those are the main drivers + <braunr> if it really was so, we would have grabbed a bsd variant, + relicenced it with GPLv3, and call it FreeGNU or NetGNU + <LibreMan> and that's how I approached the project ... maybe I was wrong, + I'm kind of disappointed if that's so :) I care about those things a + great deal, in fact that's the only reason I care about Hurd really + + <lcc> the hurd is designed to offer more freedom, in various ways, to the + user. freedom from the admin. + <lcc> right? + <braunr> lcc: that's embedded in the term "extensibility", yes + <braunr> lcc: but there are technical solutions for that on other systems + as well now + + <antrik> as for the Hurd, people who said they are interested in it only + because of freedom aspects *never* contributed anything significant + <antrik> *all* serious contributors are motivated at least equally by the + technical merits; often more + <antrik> (though the fact that it's a GNU project is what has brought many + developers here in the first place...) + <LibreMan> antrik: I would phrase it the other way - why do people who have + contributed significantly not care about freedom that much? or ... how do + you know they don't? + <antrik> most of us *do* care about freedem. but it's not our primary + motivation. the freedom aspects are just not strong enough to motivate + anyone alone + <antrik> as braunr already pointed out, if the sole purpose was creating a + GNU kernel, there would be *much* more promising venues for that + <LibreMan> I do not think so ... if you someone where to just take BSD and + rebrand it as AWSOMEnewGNUkernel it wouldn't be looked upon too favorably + <LibreMan> there is an honor aspect to it, to have something developed by + the community that stands by it + <LibreMan> so I do not think it would work + <antrik> BSD has forked countless times, and several of these forks became + very popular. I don't see why a GNU one shouldn't do well enough + <antrik> bat that's beside the point. writing a new boring monolithic + UNIX-like kernel from scratch is not that hard + <antrik> (as Linus has proven, amonst others...) + <antrik> if the sole purpose would be having a GNU kernel, I'd be strongly + advocating writing a new monolithic kernel from scratch + <LibreMan> antrik: ah, snap! not that hard you say? with all the features + Linux has? sure, it's not hard to make a kernel that barely boots but + that's not the point, is it? :) + <antrik> (yes, even now, with the Hurd being almost usable, I still think + it would be easier to get a new monolithic kernel to production quality) + <LibreMan> antrik: and here is was braunr who was pitching extensibility + and faster developement of Hurd as its advantage - and here you come + saying that it would be easier to write monolithic kernel from scratch + <LibreMan> get your story striaght guys ;) + <antrik> the Hurd makes it easier to develop new features. it's not easier + to get it production-ready in the first place + <LibreMan> antrik: what's the difference of developing a feature that makes + it "production ready" and another one that make it "production ready" for + a different use? + <antrik> features don't make a system production ready + <LibreMan> what makes a system production ready? + <LibreMan> what do you consider a "production"? + <antrik> supporting enough use cases that a non-trivial number of users + have their needs covered; and being stable enough that it's not annoying + to use + <LibreMan> either it is easier to develop or it isn't ... either it is + modular from it's core or it isn't + <antrik> well, not only stable enough, but also performant, secure etc. + <antrik> wrong + <LibreMan> are you saying that the fruits of its modularity will show only + after enough modules have been written? + <antrik> a modular system with strong isolation is inherently more + complicated to get right + <LibreMan> that sure is a weird argument to make ... + <LibreMan> right ... but when you get it right, the further development is + much easier? + <antrik> depends. making fundamental changes to how the system works will + always be tricky. but adding new stuff that doesn't require fundamental + changes, building on the existing foundations, is way easier + <antrik> we believe that once we have the fundamentals mostly right, most + things people will be adding will fall into the latter catogory + <antrik> category + <LibreMan> o what's missing to Hurd before it "got it right" and the fast + pace development kicks in? + <antrik> but so far most of the work is in the former category, meaning + progress is slow + <LibreMan> because from readin the site it seems the core is pretty much + done ... what it needs are all the translators, drivers, user-space tools + to make use of that core - is that impression wrong? + <antrik> you are missing the point. there is no unified "development pace" + measurement. it is easier to add certain things right now. but to get the + system production ready, it still requires considerable work on the hard + parts + <antrik> well, it's not as simple ;-) + <LibreMan> are you sure the work on "the hard parts" is ever going to be + done? :) + <antrik> the core is working, but it is still missing some features, and + it's missing lots of performance optimisation and bug fixing + <LibreMan> it seems more hard parts pop up every time you think it is + almost production ready + <antrik> also, we know today that the core could work much better in some + regards if we make some major changes. not a priority right now, but + something that will have to be addressed in the long run to seriously + compete with other systems + <antrik> well, no software is ever done :-) + <antrik> but I hope we will get to a point where the hard parts work well + enough for most people + <LibreMan> in fact I remember the design of Hurd was specifically chose by + RMS because he thought it would be easier to implement modular system - + that was 20 yeras ago? :) + <antrik> yes, and he admitted later that he was totally wrong on that :-) + <LibreMan> yeah, that was one unlucky choice for GNU ... + <antrik> who knows. it's hard to estimate what would have happened it GNU + chose a different route back then + <LibreMan> so ... Hurd is a hobby project for you too? + <LibreMan> or ... what do you hope to achieve by working on Hurd? + <LibreMan> I'm really interested in the motivations of people behind Hurd + as I'm kind of surprised it's not that much freedom and GNU ... + <antrik> it's a hobby project for everyone -- nobody gets paid for working + on it + <antrik> in the long run, I hope the Hurd to be a good platform for my + higher-level ideas. I have a vision of a desktop environment working + quite differently from what exists today; and I believe the extensible + architecture of the Hurd makes it easier to implement these ideas + <LibreMan> that's not what I meant as you may have guessed from my line of + reasoning so far + <LibreMan> yeah, that's my definition of a hobby project :) not whether one + gets payed to do it or not but whether one does it to satisfy their own + curiosity + <antrik> well, curiosity is clearly too narrow + <LibreMan> as far as I'm concerned I'd have a more "political" goal of + influencing the wider world to move toward more freedom + <antrik> but hackers never work on volunteer projects except to scratch + their own itch, or to work on something they are genuinely interested + in. nobody hacks free software just to save the world + <LibreMan> I find some technical aspects very interesting and fun but if + they wouldn't further the goal of more freedom they'd be without purpose + to me + <antrik> just think of the GNU high priority projects list -- it has zery + effect + <antrik> zero + <LibreMan> yeah ... and I think that is a real shame + <LibreMan> I keep thinking that it's because most hackers do not realize + the importance of freedom and the consequences of not having it + <antrik> it's a shame that some people at the FSF seem to believe they can + tell hackers what to work on :-P + <LibreMan> I do not think anybody at FSF actually believes that + <LibreMan> they believe as I do that we can persuade hackers to work on + things after they themselves recognise the significance of it + <antrik> no. there are many many hackers who genuinely believe in + supporting software freedom (both in the Hurd and in other GNU projects) + -- but there are none who would work on projects they are not personally + interested in because of that + <LibreMan> well, how does one become "personally interested" in a project? + surely it's not something you;re born with ... after recognising a + significance of some project some may become personally interested in it + - and that's the point ;) + <antrik> well, if I you mean nobody realises that software freedom is so + important they should work on it instead of doing things they actually + enjoy... they yes, I guess you are right :-P + <antrik> significance is subjective. just because something may be + important to the general public, doesn't mean I personally care about it + <LibreMan> you keep projecting your own concerns into it + <LibreMan> just because you're not interested in something doesn't mean + someone else isn't + <LibreMan> you approach it from the POV that omebody is telling YOU what + you should do ... + <LibreMan> that is not the case + <antrik> LibreMan: well, but there are obviously things no hackers care + about -- or otherwise there would be no need for the high priority + projects list... it's a list of things that would be important for + software freedom, but nobody is interested in working on. and having a + list of them won't change that fact + <LibreMan> antrik: why do you feel entitled to speak for all hackers? the + projects are high priority exactly because there isn;t enough people + working on them, if they were they wouldn't be high priority :) + <LibreMan> so maybe you have cause and effect mixed up ... + <LibreMan> there is no need to list office suite as hight priority because + there is LibreOffice, if there wasn't I'm sure it would be right there on + the priority list + <antrik> LibreMan: err... how is that different from what I said? + <antrik> these projects are there because there are not enough people + working on them -- i.e. hackers are not interested in them + <LibreMan> you said it in a way the implied that hackers are not interested + in working on projects that are required for providing freedom - but + mostly there are, it's just a few project where aren't - and those are + listed as high priority to bring attention to them + <LibreMan> well, maybe after seeing them on a high priority list some + hackes become interested in them - that is the point :) + <antrik> yes, that's what I implied. the fact that there are projects + hackers aren't working on, although they would be important for software + freedom, proves that this is not sufficient motivation for volunteers + <antrik> if software freedom alone would motivate hackers, there would be + enough people working on important projects + <LibreMan> who ever claimed that freedom alone motivated hackers? :) + <antrik> but there aren't. we have the list, and people are *still* not + working on these projects -- q.e.d. + <LibreMan> I do not get what you're trying to prove + <antrik> the track record so far clearly shows that hackers do *not* become + interested in working on these projects just because they are on the list + <antrik> err... you pretty much claimed that Hurd hackers should be + motivated by freedom alone + <antrik> and expressed great disappointment that we aren't + <braunr> LibreMan: you expected the hurd developers to share the common + goal of freedom mainly, and now you're saying you don't think hackers + would work for freedom alone ? + <LibreMan> freedom mainly == freedom alone? + <braunr> antrik: would you see an objection to using netbsd as a code base + for a mach clone ? + <braunr> LibreMan: you said share the common goal of freedom + <LibreMan> you're twisting my word to suit your own line of reasoning + <braunr> implying we all agree this is the priority + <LibreMan> being a priority doesn't mean it is there "alone", does it? + <braunr> it means it's the only one + <LibreMan> in another words, do you reject the possibility of enjoying + working on a project and doing it for freedom? because it seems you + somehow do not allow for that possibility + <braunr> if we agree on it, we can't have multiple priorities per people + <braunr> yes, that's what we're saying + <braunr> freedom isn't a goal + <braunr> it's a constraint + <braunr> the project *has* to be free + <LibreMan> so if you;re doing something to achieve freedom you can not BY + DEFINITION enjoy it? :D + <braunr> LibreMan: more or less, yes + <braunr> i enjoy the technical aspect, i advocate freedom + <LibreMan> then I've just disproven you :) I do things for freedom and + enjoy them + <braunr> no, not for freedom + <LibreMan> yes, for freedom + <braunr> i'm telling you it's not what motivates me to write code + <LibreMan> if I did not believe in freedom I wouldn't do them + <LibreMan> and I'm not talking about you + <braunr> i believe in freedom, my job consists of developing mostly + proprietary software + <braunr> how can you disprove me if you're not talking about me on this ? + <LibreMan> you said it's not possible IN PRINCIPLE, well antrik did and you + agreed - if you did not follow his line of argument then do not try to + continue where he left off ;) + <braunr> what project have you worked on ? + <LibreMan> my personal ones, nothing big + <braunr> so you're not a hacker, you're excluded from the group considered + <LibreMan> I'll tell you when it cathes on :) + <braunr> (bam) + <LibreMan> so now you decide who is and is not a hacker, well ... :) + <braunr> :) + <LibreMan> but ok, let's not talk about me I concede that I'm a lousy one + if any :) + <LibreMan> what about RMS, do you consider him a hacker? + <braunr> i think he became a hacker for other reasons than freedom + <LibreMan> would you say he is not motivated by freedom (if that can be + even concieved of)? :) + <braunr> and sees freedom as necessary too + <braunr> i can't say, i don't know him + <antrik> braunr: nope. in fact we discussed this in the past. someone even + worked on GSoC project bringing Hurd/Mach features to NetBSD -- but AFAIK + nothing came out of it + <braunr> antrik: ok + <LibreMan> well, he is pretty vocal with plenty of writings ... on the + other hand you seemed to know me well enough to proclaim me a non-hacker + <braunr> i don't know why he worked on emacs and gcc rather than the hurd + :p + <braunr> but something other than freedom must have motivated such choices + <antrik> I'm uncertain though whether NetBSD is a more useful base than + Linux. it would offer advantages on the licensing front, but it would not + offer the advantage that people could just run it on their existing + systems... + <LibreMan> gcc seems pretty significant for Linux lol + <braunr> antrik: true + <LibreMan> or GNU + <braunr> antrik: there are already system call stubs, and the VM is very, + very similar + <braunr> LibreMan: the hurd was too, at the time + <LibreMan> he can not work on everything + <braunr> so he ahd to choose, and based his choice on something else than + freedom (since all these projects are free) + <braunr> i guess he enjoyed emacs more + <antrik> LibreMan: RMS is not much of a practicing hacker anymore + nowadays... + <antrik> braunr: yeah, that's another advantage of using NetBSD as a + base... it might be easier to do + <braunr> LibreMan: what was your original question again ? + <braunr> i've been somewhat ironic since that trademark stuff, i'm serious + again now + <antrik> LibreMan: again, freedom is a factor for many of us; but not the + primary motivation + <antrik> (as braunr put, being free software is mandatory for us; but that + doesn't mean the main reason for working on the Hurd is some indirect + benefit for the free software movement...) + <LibreMan> braunr: the original goal was to understand the strong points of + Hurd to I can help communicate them to other hackers who might be + interested in Hurd + <LibreMan> because I wanted it to succeed to advance freedom more + <antrik> LibreMan: well, practice what you preach ;-) + <LibreMan> but now that I've founf that not even devs themselves are that + much interested in freedom I do not have that desire anymore + <antrik> you will hardly motivate other hackers to work on something you do + not even work on yourself... + <LibreMan> and focus my attention somewhere else + <antrik> [sigh] + <braunr> well, you can now state that the hurd has an elegant architecture + allowing many ugly hacks to disappear, and that it doesn't yet handle + sata drives or usb keys or advandced multicast routing or ... + <antrik> LibreMan: how about you listen to what we are saying? + <LibreMan> antrik: so I should work on everything in the world that + advances freedom or shut up? + <antrik> LibreMan: we *are* interested in freedom. we would work on nothing + else than a free software system. it's just not the primary motivation + for working on the Hurd + <antrik> if you primary motivation is advancing free software, the Hurd is + probably indeed not the right project to work on. other projects are more + important for that + <antrik> and that's got nothing to do with our priorities + <antrik> it's simply a matter of what areas free software is most lacking + in. the kernel is not one of them. + <braunr> antrik: my primary concern with netbsd are drivers + <LibreMan> I naively assumed that people working on a GNU project will + share GNU vlaues, instead I find that some of them poke fun at its high + priority projects + <braunr> i poke fun at you + <braunr> because you think trademark has any real value on the free + software community + <LibreMan> braunr: I see, congratulations ... I hope you enjoy it + <antrik> if there were no suitable free software kernels around, many + people might work on the Hurd mostly to advance free software. but as it + stands, having a GNU kernel is secondary + <braunr> yes, freedom is a primary goal when there are no free alternatives + <antrik> LibreMan: you are accusing us of not sharing GNU values, which is + quite outrageous I must say + <braunr> LibreMan: actually no, i'd prefer converstation with someone who + understands what i'm saying + <braunr> even if he contradicts me, like antrik often does + <braunr> (but he's usually right) + <braunr> LibreMan: you just don't want to accept some (many) of us are here + more for technical reasons than ethical ones + <LibreMan> antrik: well, some of your reasoning and tone would seem to + suggest so ... + <braunr> i didn't see antrik being particularly aggressive, but personally, + i react badly to stupidity + <LibreMan> braunr: WHAT? I've never said anything about what you should or + should not do or believe + <braunr> you clearly expected something when you first arrived + <LibreMan> I said I personally expected more enhusiastic people concerning + GNU and freedom but that was my personal expectaion and my personal + disappointment + <antrik> what makes you think we are not enthusiastic about GNU and + software freedom? + <braunr> more enthusiastic is vague, you expected us to be some sort of + freedom fighters + <antrik> just for the record, I'm part of the German core team of the FSFE + <braunr> i even stated early that we're mostly part of the free software + rather than open source movement, and you still find our point of view + disappointing + <antrik> still, it's not my major motivation for working on the Hurd + <antrik> I don't see any contradiction in that + <LibreMan> I don;t know maybe I misunderstand you, I do not mean any + disrespect + <braunr> me neither + <LibreMan> maybe "hackers" truly do think differently than I expected them + to in general and it's not specific to Hurd + <braunr> well the very word hacker describe someone interested by "hacking" + down something to get to understand it + <braunr> it's strongly technical + <LibreMan> antrik: why are you a core team member of th FSFE? what do you + do there and why? is that not motivated by the desire for more freedom? + <braunr> and we're lucky, many of them aren't deeply concerned with money + and secrecy, and prefer being open about their work + <braunr> you still don't get it ... + <antrik> LibreMan: of course it is + <antrik> and hacking free software in general also is (partly) motivated by + that + <antrik> but hacking on the Hurd specifically not so much + <braunr> 20:23 < antrik> LibreMan: we *are* interested in freedom. we would + work on nothing else than a free software system. it's just not the + primary motivation for working on the Hurd + <braunr> he already answered your question there + <antrik> (as I already said, it *is* in fact part of the motivation in my + case... just not the major part) + <LibreMan> antrik: but if it ever achieved wide success and you would be + asy on a "board" to decide future direction would you choose for exacmple + to prevent TiVO-ization over wider adpotion? + <braunr> we already answered that too + <antrik> LibreMan: that's actually not even for us to decide, as long as we + are an official GNU project + <antrik> but of course we are a GNU project because we *do* believe in + software freedom, and obviously wouldn't accept Tivoisation + <braunr> (and our discussion about using netbsd as a code base is a + relevant example of license concerns) + <LibreMan> I'm really trying to get to the core of "not motivated by + freedom" but being "interested in freedom" ... I really do not get that, + if you are interested in freedom wouldn't you want a project you work on + being used to advance it as much as possible and therefore be also + motivated to do it the best while enjoying it to achieve the goal of more + freedom since you value it that much? + <braunr> LibreMan: except for the GPLv2 vs GPLv3 debate, i don't see where + there can be a conflict between freedom and technical interest + <LibreMan> braunr: the issues around freedom are mainly not technical + ... GPLv2 and GPLv3 is also not about technical interests + <braunr> that's my problem with you, i fail to see where the problem you + think of is + <LibreMan> it tends to be about the possibility to extract money and impose + your will on the users which turns out to be highly profitable and + politicaly desirable in some instances + <LibreMan> of course it's technically the best to open-source but how are + you going to sell a product like that? that is the main question + troubling most corporations + <LibreMan> ok, I'm not going to bore you any more ;) I found out what I + needed to know ... now I'm going to try to forget about Hurd and focus on + something else where my help can be more effective at achieving what I + want ;) good luck with your endavours + <antrik> LibreMan: of course we hope for the Hurd to advance the cause of + freedom, just like any free software we would work on... still, it's not + the primary reason why we work on the Hurd, instead of the myriads of + other free software projects out there + + +# IRC, freenode, #hurd, 2012-04-09 + + <antono> what is the most impressive thing about hurd you wold like to + promote? + <antono> killing feature + <antono> i've created some simple hurd screencasts here + http://shelr.tv/records/search?utf8=%E2%9C%93&q=hurd + <antono> but probably i could share something more interesting :) + <antrik> antono: if we had such an obvious killer feature, we wouldn't have + to struggle ;-) + <antrik> the problem is that the advantages of the Hurd architecture are + too abstract for the vast majority of people to take them seriously + <antrik> IMHO the most interesting part of the Hurd is the fully + decentralised (and thus infinitely extensible) VFS mechanism + <antrik> but even that is very abstract... + <antono> antrik: cand i do somenthing relly fundamental with hurd + translator? + <antono> for example i hate old school unix FHS + <antono> I would like to have only /Users/me and /System/GNU + <antono> and i would like to only see it, but behinde the scenes it should + be Debian with FHS layout + <antono> is it possible? + <antrik> antono: of course. not sure translators offer much advantage over + FUSE in this case though... it doesn't really change the functionality of + the VFS; only rearranges the tree a bit + <antrik> (might even be doable with standard Linux features) diff --git a/open_issues/o_exec.mdwn b/open_issues/o_exec.mdwn new file mode 100644 index 00000000..3f77a0f2 --- /dev/null +++ b/open_issues/o_exec.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2012 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="O_EXEC"]] + +[[!tag open_issue_glibc open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-04-24 + + <pinotree> interesting, glibc on every OS except hurd (so including linux + too) does not define O_EXEC + <pinotree> can somebody please help me understand a POSIX behaviour? + <pinotree> it's about fexecve: + http://pubs.opengroup.org/onlinepubs/9699919799/functions/fexecve.html + <pinotree> basically, it seems to me (reading the "errors" and "application + usage" sections) that O_EXEC for open() the fd is not mandatory, and if + not used fexecve will check for file permission at call time? + <pinotree> because currently libdiskfs and libnetfs require the fd to be + open with O_EXEC + <braunr> "Since execute permission is checked by fexecve(), the file + description fd need not have been opened with the O_EXEC flag" + <braunr> this one makes it clear checking for O_EXEC is wrong + <braunr> it looks like O_EXEC is only needed when you want to have files + for which only the execution permission is set + <braunr> but not the read one + <braunr> (i don't understand the "and write" part though) + <braunr> "exec will fail if the mode of the file associated with fd does + not grant execute permission to the calling process at the time fexecve() + is called." + <braunr> this one strengthens the impression you have, that fexecve indeed + checks file permissions at the time it's called + <braunr> pinotree: hope it helps + <pinotree> so it implies the following: + <pinotree> O_RDONLY → exec works if the file is readable + <braunr> exec works if the file is readable and/or executable (although + without read permissions you can't check it) + <braunr> (well, fexecve) + <pinotree> O_EXEC → exec requires that the permission of the file at + fexecve() time have +x + <braunr> i'd say ye so far + <braunr> yes + <pinotree> so we need to fix lib{disk,net}fs then + <braunr> seems so + <pinotree> enlighting, merci braunr + <braunr> de rien + <pinotree> :) diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn index fa3d4312..d243aaaa 100644 --- a/open_issues/packaging_libpthread.mdwn +++ b/open_issues/packaging_libpthread.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012 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 @@ -10,9 +11,13 @@ License|/fdl]]."]]"""]] [[!tag open_issue_libpthread open_issue_glibc]] -IRC, #hurd, 2010-07-31 +[[!toc]] - <tschwinge> My idea was to have a separate libpthread package. What do you think about that? + +# IRC, freenode, #hurd, 2010-07-31 + + <tschwinge> My idea was to have a separate libpthread package. What do you + think about that? <youpi> in the long term, that can't work with glibc <youpi> because of the thread stub stuff @@ -21,30 +26,114 @@ IRC, #hurd, 2010-07-31 <youpi> it's not really possible to keep synchronized <youpi> because you have to decide which package you unpack first <youpi> (when upgrading) - <tschwinge> Hmm, how is that different if two shared libraries are in one package vs. two packages? It isn't atomic either way? Aren't sonames / versioned library packages solving that? + <tschwinge> Hmm, how is that different if two shared libraries are in one + package vs. two packages? It isn't atomic either way? Aren't sonames / + versioned library packages solving that? <tschwinge> ... for incompatible forward changes? <youpi> that'd be a mess to maintain - <youpi> Drepper doesn't have this constraint and thus adds members of private fields at will - <tschwinge> OK, but how is it different then if the libpthread is in the Hurd package? + <youpi> Drepper doesn't have this constraint and thus adds members of + private fields at will + <tschwinge> OK, but how is it different then if the libpthread is in the + Hurd package? <youpi> I'm not saying it's better to have libpthread in the Hurd package <tschwinge> OK. - <youpi> I'm saying it's useless to package it separately when Drepper makes everything to have us put it along glibc + <youpi> I'm saying it's useless to package it separately when Drepper makes + everything to have us put it along glibc <tschwinge> Then, to goal is to have it in glibc? <tschwinge> OK. :-) - <tschwinge> OK, I can accommodate to that. Isn't not that we'd want to switch libpthread to something else so quickly. - <tschwinge> So our official goal is to have libpthread in glibc, at least for Debian purposese? + <tschwinge> OK, I can accommodate to that. Isn't not that we'd want to + switch libpthread to something else so quickly. + <tschwinge> So our official goal is to have libpthread in glibc, at least + for Debian purposese? <youpi> for any port purpose <tschwinge> Ack. - <youpi> provided you're using glibc, you're deemed to ship libpthread with it + <youpi> provided you're using glibc, you're deemed to ship libpthread with + it <youpi> because of the strong relations Drepper puts between them - <youpi> (just to remind: we already have bugs just because our current libpthread isn't bound enough to glibc: dlopen()ing a library depending on libpthread doesn't work, for instance) - <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread isn't used + <youpi> (just to remind: we already have bugs just because our current + libpthread isn't bound enough to glibc: dlopen()ing a library depending + on libpthread doesn't work, for instance) + <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread + isn't used <pinotree> (would be nice to not have those issues anymore...) - <tschwinge> So -- what do we need to put it into glibc? We can make libpthread a Git submodule (or move the code; but it's shared also for Neal's viengoos, so perhaps the submodule is better?), plus some glibc make foo, plus some other adaptions (stubs, etc.) - <tschwinge> Does that sound about right, or am I missing something fundamental? + <tschwinge> So -- what do we need to put it into glibc? We can make + libpthread a Git submodule (or move the code; but it's shared also for + Neal's viengoos, so perhaps the submodule is better?), plus some glibc + make foo, plus some other adaptions (stubs, etc.) + <tschwinge> Does that sound about right, or am I missing something + fundamental? <youpi> I actually don't know what a git submodule permits :) <youpi> looks like a good thing for this, yes - <tschwinge> Unfortunately I can't allocate much time at the moment to work on this. :-/ - <youpi> well, as long as I know where we're going, I can know how to package stuff in Debian - <tschwinge> That sounds like a plan to me. libpthread -> glibc as submodule. - <youpi> (note: actually, the interface between glibc and the libpthread is the responsibility of the libpthread: it gives a couple of .c files to be shipped in libc.so) + <tschwinge> Unfortunately I can't allocate much time at the moment to work + on this. :-/ + <youpi> well, as long as I know where we're going, I can know how to + package stuff in Debian + <tschwinge> That sounds like a plan to me. libpthread -> glibc as + submodule. + <youpi> (note: actually, the interface between glibc and the libpthread is + the responsibility of the libpthread: it gives a couple of .c files to be + shipped in libc.so) + + +# IRC, freenode, #hurd, 2012-04-21 + + <youpi> had you tried to build libpthread as a glibc addon? + <tschwinge> youpi: No, I only know about libpthread in Hurd build system, + and libpthread stand-alone (with the Auto* stuff that I added), but not + yet as a glibc add-on. + <youpi> k + <youpi> I'm trying it atm + <tschwinge> Oh, OK. + <youpi> that should fix the no-add-needed issue in gcc/binutils, as well as + the pthread_threads assertion errors in threaded plugins + <youpi> (once I add forward.c, but that part should not be hard) + <pinotree> that means also less use of pthread-stubs^ + <pinotree> ? + <youpi> tschwinge: do you remember whether sysdeps/mach/bits/spin* are used + by anybody? + <youpi> they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and + come in the way when building in glibc + <youpi> also, any reason for using ia32 and not i386? glibc uses the latter + <youpi> pinotree: rid of pthread-stubs yes + <pinotree> \o/ + <tschwinge> youpi: You mean sysdeps/mach/i386/machine-lock.h? No idea + about that one, sorry. + <youpi> I'm talking about libpthread + <youpi> not glibc + <tschwinge> Oh. + <tschwinge> sysdeps/ia32/bits/spin-lock.h:# define + __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0) + <tschwinge> Anyway, no idea about that either. + <youpi> that one is meant to be used with the spin-lock.h just below + <youpi> +-inline + <youpi> also, I guess signal/ was for the l4 port? + <tschwinge> youpi: I guess so. + <youpi> tschwinge: I have an issue with sysdeps pt files: + sysdeps/hurd/pt-getspecific.c is not looked for by libc ; symlinking into + sysdeps/mach/hurd/pt-getspecific.c works + <youpi> we don't have a non-mach sysdeps directory? + <pinotree> youpi: if you add sysdeps/mach/hurd/Implies containing only + "hurd", does sysdeps/hurd work? + <youpi> ah, right + <pinotree> youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or + in libpthread/sysdeps/mach/hurd?) + <youpi> pinotree: it worked, it was for libpthread + <youpi> good: I got libpthread built and forward working + + +## IRC, freenode, #hurd, 2012-04-23 + + <youpi> phew + <youpi> confirmed that moving libpthread to glibc fixes the gcc/binutils + no-add-needed issue + + +## IRC, freenode, #hurd, 2012-04-27 + + <pinotree> youpi: wouldn't be the case to rename ia32 subdirs to i386 in + libpthread? + <pinotree> after all, Makefile hardcodes it, Makefile.am sets the variable + for it, and glibc expects i386 + <youpi> I know, I've asked tschwinge about it + <youpi> it's not urging anyway + <pinotree> right diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn index b6851edd..d6a98070 100644 --- a/open_issues/performance/io_system/read-ahead.mdwn +++ b/open_issues/performance/io_system/read-ahead.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 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 @@ -10,9 +10,18 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach open_issue_hurd]] -[[community/gsoc/project_ideas/disk_io_performance]] +[[!toc]] -IRC, #hurd, freenode, 2011-02-13: + +# [[community/gsoc/project_ideas/disk_io_performance]] + + +# 2011-02 + +[[Etenil]] has been working in this area. + + +## IRC, freenode, #hurd, 2011-02-13 <etenil> youpi: Would libdiskfs/diskfs.h be in the right place to make readahead functions? @@ -28,9 +37,8 @@ IRC, #hurd, freenode, 2011-02-13: portability <youpi> it's not in posix indeed ---- -IRC, #hurd, freenode, 2011-02-14: +## IRC, freenode, #hurd, 2011-02-14 <etenil> youpi: I've investigated prefetching (readahead) techniques. One called DiskSeen seems really efficient. I can't tell yet if it's patented @@ -51,13 +59,8 @@ IRC, #hurd, freenode, 2011-02-14: <braunr> oh, madvise() stuff <braunr> i could help him with that ---- - -[[Etenil]] is now working in this area. - ---- -IRC, freenode, #hurd, 2011-02-15 +## IRC, freenode, #hurd, 2011-02-15 <etenil> oh, I'm looking into prefetching/readahead to improve I/O performance @@ -281,9 +284,8 @@ IRC, freenode, #hurd, 2011-02-15 pretty good description of the necessary changes... unfortunately, these are not publicly visible IIRC :-( ---- -IRC, freenode, #hurd, 2011-02-16 +## IRC, freenode, #hurd, 2011-02-16 <etenil> braunr: I've looked in the kernel to see where prefetching would fit best. We talked of the VM yesterday, but I'm not sure about it. It @@ -299,3 +301,91 @@ IRC, freenode, #hurd, 2011-02-16 the right place is the VM subsystem [[clustered_page_faults]] + + +# 2012-03 + + +## IRC, freenode, #hurd, 2012-03-21 + + <mcsim> I thought that readahead should have some heuristics, like + accounting size of object and last access time, but i didn't find any in + kam's patch. Are heuristics needed or it will be overhead for + microkernel? + <youpi> size of object and last access time are not necessarily useful to + take into account + <youpi> what would usually typically be kept is the amount of contiguous + data that has been read lately + <youpi> to know whether it's random or sequential, and how much is read + <youpi> (the whole size of the object does not necessarily give any + indication of how much of it will be read) + <mcsim> if big object is accessed often, performance could be increased if + frame that will be read ahead will be increased too. + <youpi> yes, but the size of the object really does not matter + <youpi> you can just observe how much data is read and realize that it's + read a lot + <youpi> all the more so with userland fs translators + <youpi> it's not because you mount a CD image that you need to read it all + <mcsim> youpi: indeed. this will be better. But on other hand there is + principle about policy and mechanism. And kernel should implement + mechanism, but heuristics seems to be policy. Or in this case moving + readahead policy to user level would be overhead? + <antrik> mcsim: paging policy is all in kernel anyways; so it makes perfect + sense to put the readahead policy there as well + <antrik> (of course it can be argued -- probably rightly -- that all of + this should go into userspace instead...) + <mcsim> antrik: probably defpager partly could do that. AFAIR, it is + possible for defpager to return more memory than was asked. + <mcsim> antrik: I want to outline what should be done during gsoc. First, + kernel should support simple readahead for specified number of pages + (regarding direction of access) + simple heuristic for changing frame + size. Also default pager could make some analysis, for instance if it has + many data located consequentially it could return more data then was + asked. For other pagers I won't do anything. Is it suitable? + <antrik> mcsim: I think we actually had the same discussion already with + KAM ;-) + <antrik> for clustered pageout, the kernel *has* to make the decision. I'm + really not convinced it makes sense to leave the decision for clustered + pagein to the individual pagers + <antrik> especially as this will actually complicate matters because a) it + will require work in *every* pager, and b) it will probably make handling + of MADVISE & friends more complex + <antrik> implementing readahead only for the default pager would actually + be rather unrewarding. I'm pretty sure it's the one giving the *least* + benefit + <antrik> it's much, much more important for ext2 + <youpi> mcsim: maybe try to dig in the irc logs, we discussed about it with + neal. the current natural place would be the kernel, because it's the + piece that gets the traps and thus knows what happens with each + projection, while the backend just provides the pages without knowing + which projection wants it. Moving to userland would not only be overhead, + but quite difficult + <mcsim> antrik: OK, but I'm not sure that I could do it for ext2. + <mcsim> OK, I'll dig. + + +## IRC, freenode, #hurd, 2012-04-01 + + <mcsim> as part of implementing of readahead project I have to add + interface for setting appropriate behaviour for memory range. This + interface than should be compatible with madvise call, that has a lot of + possible advises, but most part of them are specific for Linux (according + to man page). Should mach also support these Linux-specific values? + <mcsim> p.s. these Linux-specific values shouldn't affect readahead + algorithm. + <youpi> the interface shouldn't prevent from adding them some day + <youpi> so that we don't have to add them yet + <mcsim> ok. And what behaviour with value MADV_NORMAL should be look like? + Seems that it should be synonym to MADV_SEQUENTIAL, isn't it? + <youpi> no, it just means "no idea what it is" + <youpi> in the linux implementation, that means some given readahead value + <youpi> while SEQUENTIAL means twice as much + <youpi> and RANDOM means zero + <mcsim> youpi: thank you. + <mcsim> youpi: Than, it seems to be better that kernel interface for + setting behaviour will accept readahead value, without hiding it behind + such constants, like VM_BEHAVIOR_DEFAULT (like it was in kam's + patch). And than implementation of madvise will call vm_behaviour_set + with appropriate frame size. Is that right? + <youpi> question of taste, better ask on the list + <mcsim> ok diff --git a/open_issues/resource_management_problems/zalloc_panics.mdwn b/open_issues/resource_management_problems/zalloc_panics.mdwn index 09710022..9c29b07c 100644 --- a/open_issues/resource_management_problems/zalloc_panics.mdwn +++ b/open_issues/resource_management_problems/zalloc_panics.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2005, 2007, 2008, 2010 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2005, 2007, 2008, 2010, 2012 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 @@ -54,3 +54,46 @@ I started various other experiments with creating child processes (fork bombs), * After opening/leaking lots of ports to /dev/null (32768 it seems), the NULL translator somehow becomes disfunctional, and a new instance is started While most of these Observations clearly show an exhaustion of kernel memory which is not surprising, some of the oddities seem to indicate problems that might deserve further investigation. + + +# IRC, freenode, #hurd, 2012-04-01 + + <mel__> antrik: i just found + http://www.gnu.org/software/hurd/open_issues/resource_management_problems/zalloc_panics.html + -- that is from 2007. is this still the current status? + <youpi> mel__: probably + <mcsim> mel__: gnumach has no more zalloc allocator, so I doubt if it could + be a problem. + +[[gnumach_memory_management]]. + + <youpi> mcsim: but it still has an allocator + <youpi> which can run out of resources + <mcsim> AFAIR, now there is no such limit. + <youpi> err, there is + <youpi> the size of your RAM :) + <mcsim> In zalloc appearing of this message didn't depend of available size + of free ram. + <youpi> then update the description, but I'm still getting allocation + errors, when userland makes crazy things like creating millions of tasks + <mcsim> At least it could appear when there still was free memory + <youpi> and that's not surprising + <youpi> sure, I know that *some* limits have been removed, but there + weren't so many, and I have seen cases where it's simply mach running out + of memory + <youpi> also, we have a limited amount of virtual addressing space + <antrik> mel__: this writeup is outdated in several regards. *some* of the + observations might still be relevant, but nothing that seems + particularily important + <antrik> the zalloc panics have pretty much disappeared after the default + zalloc zone size has been considerably extended (which was not possible + before because of some bug) + <mel__> i see + <antrik> but as mcsim pointed out, with the new allocator not relying on a + fixed-sized zalloc zone at all, they are even less likely, and should + happen only if all memory is exhausted + <antrik> I guess this outdated report can just be dropped + <mcsim> I think, that now it is problem rather of absence of OOM-killer or + resource manager + <antrik> mcsim: right :-) + <antrik> (and we have separate articles about that) diff --git a/open_issues/syslog.mdwn b/open_issues/syslog.mdwn index 2e902698..19cba82e 100644 --- a/open_issues/syslog.mdwn +++ b/open_issues/syslog.mdwn @@ -1,4 +1,19 @@ -IRC, unknwon channel, unknown date. +[[!meta copyright="Copyright © 2010, 2011, 2012 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_hurd]] + +[[!toc]] + +# IRC, unknown channel, unknown date <tschwinge> scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725 I see that you intend(ed) to use syslog for logging debug messages. I @@ -16,7 +31,7 @@ IRC, unknwon channel, unknown date. doesn't help if I restart syslogd). -IRC, freenode, #hurd, 2011-08-08 +# IRC, freenode, #hurd, 2011-08-08 < pinotree> wow, `logger` + a simple C udp server can cause havoc < pinotree> youpi: ever seen something like @@ -70,3 +85,23 @@ IRC, OFTC, #debian-hurd, 2011-11-02: <tschwinge> Yep. What I've been doing ever since, is deinstall all *syslog* packages. <tschwinge> This ``fixed'' all syslog() hangs. + + +# IRC, freenode, #hurd, 2012-03-28 + + <braunr> i can see lots of CRON processes hanging around + <braunr> pinotree: crontab -l was hanging too when trying to quickly see + what went wrong + <braunr> so it may be an unreleased lock of some kind + <antrik> braunr: do you have syslog installed by any chance?... + <antrik> IIRC that bug has never been fixed :-( + <braunr> yes syslogd is running + <antrik> that's probably the culprit then + <braunr> ok + <braunr> i'll just disable it for now then + <antrik> the error has existed for years + <antrik> was similar for me though: for a long time I have been hearing + about this issue, and only suddenly I started experiencing it myself... + <antrik> it depends on how many things are actually logged. IIRC the hang + happens when some client sends 128 messages to syslog or something like + that diff --git a/open_issues/system_call_mechanism.mdwn b/open_issues/system_call_mechanism.mdwn index 5598148c..68418097 100644 --- a/open_issues/system_call_mechanism.mdwn +++ b/open_issues/system_call_mechanism.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 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 @@ -10,8 +10,47 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] -IRC, freenode, #hurd, 2011-05-07 +[[!toc]] + + +# IRC, freenode, #hurd, 2011-05-07 <braunr> very simple examples: system calls use old call gates, which are the slowest path to kernel space <braunr> modern processors have dedicated instructions now + + +# IRC, freenode, #hurd, 2012-04-22 + + <braunr> rah: basically, system calls are slower on mach because they use + call gates instead of newer sysenter/sysexit + <youpi> braunr: sysenter/exit is a x86_64 thing + <braunr> rah: apart from that, the code can't get much simpler, and *I* + know, for i have studied it, and wrote a compatible version in a clone + attempt + <youpi> braunr: on a x86_64 port we'd probably use sysenter/exit + <braunr> youpi: no there are 32-bits instructions, i don't remember if + they're called sysenter, it's in my thesis though so i'm sure of it :) + <youpi> braunr: ah, the other part + <youpi> is linux-x86 using them? + <braunr> youpi: yes, glibc uses them + <youpi> and does it really change much nowadays? + <youpi> what is the actual difference between int 80 and sysenter? + <braunr> less checking + <youpi> checking what? + <youpi> the idt? + <braunr> ring levels for example + <youpi> well, checking a ring is fast :) + <braunr> depending on the original and requested levels, there are lookups + in tables + <braunr> sysenter always assume 3 to 0 and 0 to 3 for sysexit + <youpi> ah, also it assumes things about segments + <youpi> so that indeed makes context things simpler + <braunr> right + <braunr> but mach doesn't uses int 0x80 + <braunr> it uses an lcall + <braunr> which is a bit slower from what I could read some time ago + <braunr> (not sure if it's still relevant) + <youpi> actually in 64bit mode I had to catch lcall from the invalid + instruction trap + <youpi> perhaps it got dropped in 64bit mode diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn index 70c3c6dc..25168fce 100644 --- a/open_issues/user-space_device_drivers.mdwn +++ b/open_issues/user-space_device_drivers.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2011, 2012 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 @@ -64,7 +65,7 @@ Also see [[device drivers and IO systems]]. ## System Boot -IRC, freenode, #hurd, 2011-07-27 +### IRC, freenode, #hurd, 2011-07-27 < braunr> btw, was there any formulation of the modifications required to have disk drivers in userspace ? @@ -88,6 +89,11 @@ IRC, freenode, #hurd, 2011-07-27 < Tekk_> mhm < braunr> s/disk/storage/ +### IRC, freenode, #hurd, 2012-04-25 + + <youpi> btw, remember the initrd thing? + <youpi> I just came across task.c in libstore/ :) + # Plan diff --git a/sidebar.mdwn b/sidebar.mdwn index 862b42ac..7143329d 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -13,16 +13,6 @@ Welcome to... [[!img /logo/boxes-redrawn.png link=/logo]] ... the GNU Hurd! --- -[[!template id=highlight text="""**Breaking News** - ---- - -The **Google Summer of Code 2012** is on! If you're a student, consider -applying for a GNU Hurd project -- details to be found on our -*[[community/GSoC]] page*."""]] - ---- - * **[[Home|/index]]** * **[[Community]]** * [[Contact_Us]] diff --git a/unsorted/MakeImage.mdwn b/unsorted/MakeImage.mdwn index 95b928c4..b3485771 100644 --- a/unsorted/MakeImage.mdwn +++ b/unsorted/MakeImage.mdwn @@ -53,7 +53,7 @@ I use this for testing OSKit... ## <a name="Booting_Qemu"> Booting Qemu </a> - qemu -user-net -isa -boot d -cdrom grub.iso -hda gnu.img + qemu -m 512 -user-net -isa -boot d -cdrom grub.iso -hda gnu.img The switch `-isa` is for current gnumach.gz on hda. diff --git a/user/Maksym_Planeta.mdwn b/user/Maksym_Planeta.mdwn index a0a9c788..e31ee2b7 100644 --- a/user/Maksym_Planeta.mdwn +++ b/user/Maksym_Planeta.mdwn @@ -9,10 +9,18 @@ is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!toc]] +#GSoC 2012 - Disk I/O Performance Tuning + +14.05.12 + +First of all I'm going to do 2 programs. First will work as server, it will create an object and share it with second. Second will try to access to this object. This will cause page fault and kernel will refer to first program (server). This way I will be able to track how page faults are resolved and this will help me in debugging of readahead. IFR: server probably can use some of hurd's libraries, but it has to handle m_o_* RPC's on it's own. TODO: Find out how supply second program (client) with new object. NB: be sure that client will cause page fault, so that server always will be called (probably any caching should be disabled). + #Notes on tmpfs ## Current state +Finished + 26.01.12 Infinite fsx on ext2fs: |