diff options
39 files changed, 1429 insertions, 261 deletions
diff --git a/community.mdwn b/community.mdwn index 9443f123..be1edb8f 100644 --- a/community.mdwn +++ b/community.mdwn @@ -30,6 +30,8 @@ Further ways of getting in contact or getting information: [[LiveJournal]] +[identi.ca](http://identi.ca/group/hurd) + [[Orkut]] [[FaceBook]] diff --git a/community/weblogs/ArneBab/2011-04-06-application-python-test.mdwn b/community/weblogs/ArneBab/2011-04-06-application-python-test.mdwn index 8bc338f4..4c20afa1 100644 --- a/community/weblogs/ArneBab/2011-04-06-application-python-test.mdwn +++ b/community/weblogs/ArneBab/2011-04-06-application-python-test.mdwn @@ -1,92 +1 @@ -Improving Python support (fixing testsuite failures) -========================== - -## Contact information - -- Name: Arne Babenhauserheide -- E-Mail Address: arne_bab@web.de -- IRC-nick: ArneBab @ freenode -- Jabber-ID: arne@jabber.fsfe.org -- Phone-number: XXXXXXXXX -- GnuPG key: http://draketo.de/inhalt/ich/pubkey.txt - -## Who I am - -I am a physics student from Heidelberg, Germany, a passionate free software user and roleplayer, and I started contributing to the Hurd in minor ways about 5 years ago. Now my coding skills are good enough (and I have enough time) that I feel ready to tackle a GSoC project - and I want to take the chance GSoC offers and do a focussed effort for contributing to free software before I am no longer a student. I married 4 years ago and now have a 5½ month old son whoose happy laughing can make you forget everything around you - or at least it does that to me, but what else could you expect to hear from his father about him ;) - -## Project - -For this years GSoC I want to fix all testsuite errors python on the Hurd, which on the one hand ensures, that we have no unexpected errors in Python applications and on the other hand is a dependency for a full featured PyHurd. - -## Preliminary Schedule - -*from simple fixes to complex ones.* - -… TODO as soon as the testsuite finished and the results are stored → grep + decide. - -## Initial Fix - -… TODO - -## Detailed answers - -### What I have to learn, and what I already know - -I need to incrementally learn details of the implementation of Python and the Hurd while I move from one testsuite breakage to the next. - -I know Python quite well and I know the rough workings of the Hurd and can code in C and C++. - -### Why did you choose this project idea? What do you consider most appealing about it? - -I want the PyHurd project to succeed, and I love Python and the concepts behind the Hurd. So I want full Python support on the Hurd. Every testsuite breakage is a possible stumbling point for Python programs, which is very hard to debug for a Python programmer, as it lies within the platform (Python on Hurd) and not in his/her own code. - -### Have you been involved in any free software ("Open Source") projects yet? Which projects, how long, and in what way have you been involved? Have you been active in the Hurd project/Hurd community before? - -I worked on documentation and news for the Hurd, wrote two plugins and the usage guide for Mercurial and created a bunch of personal Python projects. Also I generally try to nudge other Hurd developers into the direction of actually getting the system useful for people (and communicating its strengths) - and do the same for the freenet project. - -In my opinion, my major contribution to the Hurd is the Month of the Hurd, a try at fixing the Hurds reputation for never being finished. To achieve that goal, the Month of the Hurd only lists actually testable successes for which I can easily describe how they get the Hurd closer to its vision, ideally those which are already committed. - -### Please briefly describe the Hurd, including the goals, architecture etc. Also, what makes you interested in the Hurd? Why do you want to work on it? What is your vision of it's future development? - -The Hurd offers much greater freedom for users compared to Linux, because every user can change his/her environment to a much greater extent. - -Also it allows for easier low-level tinkering, making it possible for hobby-hackers to work on stuff which in linux requires dabbling with kernel-sources. Also it makes it much easier to test these low-level work, so a community can spawn which informally shares low-level hacks, giving a much bigger momentum for low-level work. - -And it allows for containment of potentially dangerous applications using subhurds. As a very simple example, I can open a webbrowser without giving it access to the internet and just add that capability later, when I really want to go online (as opposed to just showing local files). - -But mainly: - - settrans -a ftp\: /hurd/hostmux /hurd/ftpfs / - dpkg -i ftp://ftp.gnu.org/…/*.deb - -And that’s only the beginning. - -### Are you subscribed to the bug-hurd@gnu.org mailing list? (See http://lists.gnu.org/mailman/listinfo/bug-hurd ) - -Yes :) - -### Do you have a permanent internet connection, especially during the time of the summer session? Are you able and willing to hang out on the Hurd IRC channel regularly? (As in: Running the IRC client more or less permanently and checking for activity now and then.) If it turns out that your mentor lives in a different time zone, could you shift your day/night rhythm to better match that of your mentor and other Hurd developers? - -Yes, a permanent internet connection as well as a permanently running computer. Since I’m used to also work later in the evening (on hobby projects), the time zone should not be a major issue. - -### When does your university term end, when are your exams, and when does the next term begin? - -I have a clean timetable for the summer: No exams anymore. - -### How much time do you intend to spend on your GSoC project per day/week during the summer months? - -I plan to spend at least 40 hours per week on the PyHurd. - -### What other major activities will you engage in during the summer? (Moving apartments, longer vacations, other obligations, etc.) If any, how do you intend to make sure you will be able to dedicate sufficient time to your project nevertheless? - -Finding a job for after the GSoC. This should not take too much time, all in all, but rather mean short out-times now and then. - -### How do you intend to make sure that your code will keep on being maintained and supported properly after the end of the GSoC program? - -I plan to get the Python and the Hurd fixes upstream, in the case of Python by pushing all code to a clone of the official Python repository¹ and trying to get the Python community to accept the changes, and in the case of fixes in the Hurd by getting it integrated in the main repositories as soon as possible. - -¹: http://bitbucket.org/ArneBab/cpython - -### Anything else you want to add to your application? - -Alterrnately I would also like to work on [[Python bindings for the Hurd|community/gsoc/project_ideas/language_bindings]]. Both tasks together (PyHurd and Testsuite) work towards having Python as first-class citizen on the Hurd, adding all of the Python standard library to the options for using the Hurd. +Cancelled. See [[community/weblogs/ArneBab/2011-04-06-application-pyhurd]] instead. diff --git a/community/weblogs/ArneBab/porting-simple-packages.mdwn b/community/weblogs/ArneBab/porting-simple-packages.mdwn new file mode 100644 index 00000000..becea251 --- /dev/null +++ b/community/weblogs/ArneBab/porting-simple-packages.mdwn @@ -0,0 +1,72 @@ +# Quick porting guide for simple packages + +*If you want to help port a package with simple issues to the Hurd, please read on.* + +*just imagine joe C-doodler stumbling over some GNU philosophy and thinking “hey, I’ve got 2 free hours, why not help the Hurd?”* +*for him I’d like to have a guide (and for me, the faulty-memory-does-too-many-things :) )* + +*a short guide “how to do simple ports” broken down to command line level: how to get the list of simple packages (youpi told me that here), how to get the source, how to test the fix, how to submit the fix.* + +## Setup an instant Hurd development environment + +See [[Instant Development Environment|contributing#index5h2]] - just follow the command to get a Hurd running in Qemu. + +## Getting the list of failed packages + + wget http://people.debian.org/~sthibault/failed_packages.txt.gz + gunzip failed_packages.txt.gz + +## Finding a simple task + + grep PATH_MAX failed_packages.txt -B 2 + +Each of these packages is likely to be simple to fix. The output looks like this: + + … + -- + tex/lilypond_2.12.3-7 by buildd_hurd-i386-mozart [optional:uncompiled:bp{-100}:calprio{-63}:days{258}] + Reasons for failing: + > file-name.cc:88: error: 'PATH_MAX' was not declared in this scope + -- + … + +in this case, lilypond is the package. + +Other simple tasks can be found on [[hurd/porting/guidelines]]. + +## Downloading the package source and installing dependencies + + apt-get source PACKAGE + apt-get build-dep PACKAGE + +For example + + apt-get source lilypond + apt-get build-dep lilypond + +## Fix the package + +See [[hurd/porting/guidelines]] for help on fixing the package. + +Notes: + +* char path[4096] is evil. Use dynamic allocation (if you can). +* use stuff like if (x < sysconf(_SC_PATH_MAX)) {} +* if need be, make it conditional + +\#ifdef PATH_MAX +old, POSIX-violating code +\#else +GNU, better code +\#endif + +## Test the fix (compile, run tests) + + cd PACKAGE + dpkg-buildpackage -B + +Also check the packages README for instructions. + +## Submit the fix + +See [[hurd/running/debian/patch_submission]]. diff --git a/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn b/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn new file mode 100644 index 00000000..592f6b39 --- /dev/null +++ b/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn @@ -0,0 +1,44 @@ +*answer to http://blog.flameeyes.eu/2011/05/15/just-accept-it-truth-hurds .* + +Thanks for explaining your reasons. As answer: + +Firstoff: FUSE is essentially an implementation of parts of the translators system (which is the main building block of the Hurd) to Linux and NetBSD recently got a port of the translators system¹. That’s the main contribution to other projects I see. + +¹: http://netbsd-soc.sourceforge.net/projects/hurdt/ + +On the bare technical side, the translator-based filesystem stands out: The filesystem allows for making arbitrary programs responsible for displaying a given node (which can also be a directory tree) and to start these programs on demand. To make them persistent over reboots, you only need to add them to the filesystem node (for which you need the right to change that node). Also you can start translators on any node without having to change the node itself, but then they are not persistent and only affect your view of the filesystem without affecting other users. These translators are called active, and you don’t need write permissions on a node to add them. + +The filesystem implements stuff like Gnome VFS and KDE network transparency on the filesystem level, so they are available for all programs. And you can add a new filesystem as simple user, just as if you’d just write into a file “instead of this node, show the filesystem you get by interpreting file X with filesystem Y” (this is what you actually do when setting a translator but not yet starting it (passive translator)). + +One practical advantage of this is that the following works: + + settrans -a ftp\: /hurd/hostmux /hurd/ftpfs / + dpkg -i ftp://ftp.gnu.org/path/to/*.deb + +The shell sees normal directories (beginning with the directory “ftp:”), so shell expressions just work. + +You could even define a Gentoo mirror translator (`settrans mirror\: /hurd/gentoo-mirror`), so every program could just access mirror://gentoo/portage-2.2.0_alpha31.tar.bz2 and get the data from a mirror automatically: `wget mirror://gentoo/portage-2.2.0_alpha31.tar.bz2` + +Or you could add a uniounmount translator to root which makes writes happen at another place. Every user is able to make a readonly system readwrite by just specifying where the writes should go. But the writes only affect his view of the filesystem. + +Starting a network process is done by a translator, too: The first time something accesses the network card, the network translator starts up and actually provides the device. This replaces most initscripts in the Hurd: Just add a translator to a node, and the service will persist over restarts. + +It’s a surprisingly simple concept, which reduces the complexity of many basic tasks needed for desktop systems. + +And at its most basic level, Hurd is a set of protocols for messages which allow using the filesystem to coordinate and connect processes (along with helper libraries to make that easy). + +Also it adds POSIX compatibility to Mach (while still providing access to the capabilities-based access rights underneath, if you need them). You can give a process permissions at runtime and take them away at will. For example you can start all programs without permission to use the network (or write to any file) and add the permissions when you need them. + +And then there are subhurds (essentially lightweight virtualization which allows cutting off processes from other processes without the overhead of creating a virtual machine for each process). But that’s an entire post of its own… + +And the fact that a translator is just a simple standalone program means that these can be shared and tested much more easily, opening up completely new options for lowlevel hacking, because it massively lowers the barrier of entry. + +And then there is the possibility of subdividing memory management and using different microkernels (by porting the Hurd layer, as partly done in the NetBSD port), but that is purely academic right now (search for Viengoos to see what its about). + + +So in short: The translator system in the Hurd is a simple concept which makes many tasks easy, which are complex with Linux (like init, network transparency, new filesystems, …). Additionally there are capabilities, subhurds and (academic) memory management. + +Best wishes, +Arne + +PS: I decided to read your post as “please give me technical reasons to dispell my emotional impression”. diff --git a/community/weblogs/ArneBab/technical-advantages-of-the-hurd/discussion.mdwn b/community/weblogs/ArneBab/technical-advantages-of-the-hurd/discussion.mdwn new file mode 100644 index 00000000..49b64509 --- /dev/null +++ b/community/weblogs/ArneBab/technical-advantages-of-the-hurd/discussion.mdwn @@ -0,0 +1,248 @@ +## Followup discussion in IRC + +IRC, freenode, #hurd, 2011-05-15 + +<dl> +<dt><LibreMan></dt><dd> ArneBab: hi, I read the hurd rant by flameeyes and your response ... I'm following Hurd for some time and would like to ask some questions about it, would you mind? :)</dd> +<dt><ArneBab></dt><dd> please ask :)</dd> +<dt><ArneBab></dt><dd> I don’t mind (as long as I have the time - which I have right now)</dd> +<dt><LibreMan></dt><dd> ok, so essentially I'm trying to figure out, as flameeyes probably is, whether reasons behind developing Hurd are more philosophical/value based or are there real-world technical advantages to it as well</dd> +<dt><ArneBab></dt><dd> antrik: I think his original remark was meant as part-jokingly remark to an aquaintance - which seems fitting, when you keep in mind that flameeyes works very hard and very much on Gentoo, hardly the most popular distro (but the one I like most).</dd> +<dt><ArneBab></dt><dd> LibreMan: the reasons for working on the Hurd are a little bit different for every contributor.</dd> +<dt><ArneBab></dt><dd> (or rather: vastly different :) )</dd> +<dt><LibreMan></dt><dd> as I'm reading about it and your reposne as well, I'm not sure the techical advantages you list would have any real world effect on usability of the OS, do you think they would?</dd> +<dt><ArneBab></dt><dd> I think they would</dd> +<dt><LibreMan></dt><dd> ArneBab: yeah, sure ... my reasons for supporting Hurd are philosophical/value based ... I'll say that outright</dd> +<dt><ArneBab></dt><dd> for example you enter an FTP address in your filebrowser. No problem. Then you want to grep the file contents.</dd> +<dt><ArneBab></dt><dd> you go into the shell and first need to get the files (completely inconvenient)</dd> +<dt><-- npnth (~npnth@pdpc/supporter/active/npnth) hat das Netzwerk verlassen (Disconnected by services) +<dt><ArneBab></dt><dd> or you use gnome and kde programs, and both access the same URL, but cache 2 times.</dd> +<dt><LibreMan></dt><dd> ArneBab: isn't that solved by mounting it?</dd> +<dt><ArneBab></dt><dd> or you want to implement your own desktop and need to do that network transarency stuff yourself.</dd> +<dt><ArneBab></dt><dd> You can’t really mount everything - especially not without root rights.</dd> +<dt><ArneBab></dt><dd> and that’s just one aspect.</dd> +<dt><ArneBab></dt><dd> But that’s only the technical side (he only wanted to hear that)</dd> +<dt><LibreMan></dt><dd> the thing is all these advantages seem too trivial to support a wholly new OS to be developed ... but maybe I'm mistaken, that's why I'm asking, I would love to be good techical reasons for Hurd ... but are not aware of any so far</dd> +<dt><ArneBab></dt><dd> What interests me the most as that I as user can change my environment without affecting others.</dd> +<dt><ArneBab></dt><dd> s/as/is/</dd> +<dt><ArneBab></dt><dd> the main community part is (and I think I missed that), that any server is just a userspace program.</dd> +<dt><ArneBab></dt><dd> it can be exchanged just like any other program</dd> +<dt><antrik></dt><dd> ArneBab: yeah, I found the original remark after following the other links... though it's rather painful to trace the conversations :-)</dd> +<dt><LibreMan></dt><dd> ArneBab: yeah, I understand that ... but what practical advantage would that give me I do not see ... as a server administrator for example</dd> +<dt><ArneBab></dt><dd> I can write an improved filesystem and pass it to you for testing, and you test it only for a backup snapshot of your disk without rebooting.</dd> +<dt><ArneBab></dt><dd> As server admin, you don’t need to install all drivers users could need.</dd> +<dt><ArneBab></dt><dd> the users can just install what they need themselves.</dd> +<dt><antrik></dt><dd> it certainly didn't sound half-joking though... and if it was meant privately, identi.ca is clearly NOT the right place</dd> +<dt><ArneBab></dt><dd> LibreMan: You simply provide a base which reduces the number of things people need to install.</dd> +<dt><LibreMan></dt><dd> ArneBab: but do not I have to give them access to raw HW too then?</dd> +<dt><ArneBab></dt><dd> antrik: I prefer to always assume good faith :)</dd> +<dt><ArneBab></dt><dd> brb</dd> +<dt><ArneBab></dt><dd> child</dd> +<dt><ArneBab></dt><dd> re</dd> +<dt><LibreMan></dt><dd> well, I do not see that people not able to install their own drivers on a server would be any problem currently</dd> +<dt><LibreMan></dt><dd> that's my point ... is seems to solve "problems" that are not really actual real world problems ...</dd> +<dt><ArneBab></dt><dd> LibreMan: no, you just give them a safe device, where a server makes sure they don’t do illegal things.</dd> +<dt><antrik></dt><dd> LibreMan: most of the advantages are not directly visible, unless you do very specific things, where traditional systems impose limits</dd> +<dt><ArneBab></dt><dd> For me network transparency is a realworld problem</dd> +<dt><ArneBab></dt><dd> as is that I can’t give a program network access later</dd> +<dt><antrik></dt><dd> but it makes many things easier, which in the end will translate into advantages for everyone I believe</dd> +<dt><ArneBab></dt><dd> “log out and in again to play games”</dd> +<dt><ArneBab></dt><dd> (after adding yourself to the games group)</dd> +<dt><ArneBab></dt><dd> or better still: Always start with minimal rights and only add what is really needed.</dd> +<dt><ArneBab></dt><dd> There’s no reason why a program should have access to my audio hardware without me granting it.</dd> +<dt><ArneBab></dt><dd> That way I could even run malicious software without having to fear compromising my system.</dd> +<dt><antrik></dt><dd> LibreMan: I could come up with situations where it could help you as an administrator; but this is not really helpful. you won't really understand the advantages until you get into a specific situation that is hard to do on Linux for example, and much easier on the Hurd</dd> +<dt><LibreMan></dt><dd> ArneBab: well, then it becomes a tradeoff between security and user friendliness ... I do not think that problem is unsolvable currently, I think it is a design decision not to "solve it" as wast majority of users do not actually need or want it</dd> +<dt><ArneBab></dt><dd> LibreMan: Time and again I find myself sitting in front of my linux box and thinking “damn, this woul be so easy in the Hurd”</dd> +<dt><ArneBab></dt><dd> (I do most of my work on a Linux box)</dd> +<dt><ArneBab></dt><dd> Gentoo GNU/Linux with KDE and Emacs</dd> +<dt><LibreMan></dt><dd> antrik: yeah, could you give me an example of something that is hard on linux but easy under hurd? with real world implications for real use cases :)</dd> +<dt><ArneBab></dt><dd> LibreMan: Get a hg/git log of a repo on an ftp server</dd> +<dt><antrik></dt><dd> LibreMan: no, it's *not* a tradeoff. the whole point is that the Hurd architecture allows users to customize their environment *without* compromising the security of the system</dd> +<dt><ArneBab></dt><dd> antrik LibreMan: I think there we have one point: When you use Linux you are used to thinking of the Linux limits as the absolute limits.</dd> +<dt><LibreMan></dt><dd> antrik: the point is, wast majority of users do not need that ... AFAIK</dd> +<dt>-*- youpi is fed up with using sudo just to mount an iso image +<youpi></dt><dd> really</dd> +<dt><Tekk_></dt><dd> youpi: dbus</dd> +<dt><ArneBab></dt><dd> LibreMan: just wait for the first strong linux worm which spreads in a game and requires sudo for install… </dd> +<dt><youpi></dt><dd> (and it's just one of the strongest examples)</dd> +<dt><youpi></dt><dd> Tekk_: ??</dd> +<dt><antrik></dt><dd> LibreMan: ArneBab already gave you various exmples. including at least one that works out of the box</dd> +<dt><Tekk_></dt><dd> youpi: with dbus you don't need root permissions</dd> +<dt><youpi></dt><dd> Tekk_: and you can mount any iso?</dd> +<dt><antrik></dt><dd> (others would require some additional coding)</dd> +<dt><ArneBab></dt><dd> Tekk_: but something needs them.</dd> +<dt><Tekk_></dt><dd> youpi: oh, iso...</dd> +<dt><LibreMan></dt><dd> ArneBab: why would a game need sudo to install? :)</dd> +<dt><youpi></dt><dd> Tekk_: yes, iso</dd> +<dt><youpi></dt><dd> or $WHATEVER_FS</dd> +<dt><Tekk_></dt><dd> youpi: sec</dd> +<dt><ArneBab></dt><dd> LibreMan: yes, I would ask that, too. But the general Ubuntu user?</dd> +<dt><youpi></dt><dd> or sshfs, or ftpfs, etc.</dd> +<dt>-*- ArneBab had hoped you’d catch that :) +<LibreMan></dt><dd> the area where I can imagine hurd being better is virtualization</dd> +<dt><antrik></dt><dd> LibreMan: again, the "general Ubuntu user" won't directly see the benefits. but he will see them when developers use them to implement nice features that would be much harder to implement elsewhere</dd> +<dt><LibreMan></dt><dd> making everything cloudy is a big trend nowadays and hurd could provide additional flexibility there ... or no? I'm really just guessing based on what I read</dd> +<dt><antrik></dt><dd> it's a bad trend</dd> +<dt><ArneBab></dt><dd> LibreMan: it could give me more options when I have to work on another ones computer. After all it was conceived in the time of dumb terminals - which now comes back.</dd> +<dt><LibreMan></dt><dd> ArneBab: oh well, if we are talking about user stupidity then no OS is going to help ;)</dd> +<dt><antrik></dt><dd> I'm not sure whether the Hurd help with "making things cloudy", but it's not something I'd consider an advantage anyways :-)</dd> +<dt><ArneBab></dt><dd> LibreMan: The OS can reduce the impact of user stupidity (called DAU in german: „Dümmster anzunehmender User“ → “dumbest conceivable user”)</dd> +<dt><antrik></dt><dd> as for virtualization, indeed there is a *very* close relation between that and microkernel systems, which most people fail to see...</dd> +<dt><LibreMan></dt><dd> antrik: the "cloud" is coming if we like it or not ... it better run on FOSS if it comes ;)</dd> +<dt><Tekk_></dt><dd> you know, you gues have a huge advantage</dd> +<dt><Tekk_></dt><dd> guys*</dd> +<dt><Tekk_></dt><dd> people have waited forever and written you off</dd> +<dt><ArneBab></dt><dd> LibreMan: just think about the difference between a GNU/Linux distro and Windows XP where you were admin at all times.</dd> +<dt><Tekk_></dt><dd> and as duke nukem forever shows, that's a good thing ;P</dd> +<dt><antrik></dt><dd> in fact, the only fundamental difference is that a VM makes the subenvironment look more or less like a real machine, while in traditional microkernel systems different interfaces are used</dd> +<dt><ArneBab></dt><dd> LibreMan: A Hurd system would go one step further.</dd> +<dt><ArneBab></dt><dd> You’d even need a password more seldomly, reducing the incentive to just work as admin.</dd> +<dt><ArneBab></dt><dd> Reason: There are less things which can really badly impact the system.</dd> +<dt><antrik></dt><dd> LibreMan: when talking about "the cloud", people usually mean things that are fundamentally incompatible with the idea of free software</dd> +<dt><antrik></dt><dd> (you don't have control over the software running web services)</dd> +<dt><ArneBab></dt><dd> antrik: but the cloud just means “I’m on a different computer”. AGPLv3 is cool there :)</dd> +<dt><LibreMan></dt><dd> antrik: yeah, that's the common bussines practice but it doesn't have to be ... AGPL ;)</dd> +<dt><antrik></dt><dd> ArneBab: well, actually "the cloud" means something different to everyone ;-)</dd> +<dt><LibreMan></dt><dd> I do not have any problem with a cloud running AGPL software</dd> +<dt><ArneBab></dt><dd> antrik: well, yes :)</dd> +<dt><antrik></dt><dd> ArneBab: but generally it relies on using programs on foreign machines, controlled by someone else. AGPL doesn't change that</dd> +<dt><LibreMan></dt><dd> freedombox is going to be a "cloud" too</dd> +<dt><antrik></dt><dd> LibreMan: that's not what most people mean by "cloud"</dd> +<dt><LibreMan></dt><dd> at least I hope so</dd> +<dt><ArneBab></dt><dd> I don’t have control over my webserver. I can’t run a real Python there. Hurd could change that (though that will take a lot of coding: the conceptual options are there)</dd> +<dt><ArneBab></dt><dd> LibreMan: what could interest you: http://www.gnu.org/software/hurd/community/weblogs/ArneBab/niches_for_the_hurd.html</dd> +<dt><ArneBab></dt><dd> “Niches of the Hurd”</dd> +<dt><LibreMan></dt><dd> what I mean by "the cloud" is what Eben Moglen explaied it as ... the technology which make it possible to forget about the "iron" and move servers around seamlessly</dd> +<dt><LibreMan></dt><dd> ArneBab: thank.. going to look at it</dd> +<dt><antrik></dt><dd> LibreMan: that's actually more or less what used to be called "grid computing" before the cloud hype</dd> +<dt><LibreMan></dt><dd> antrik: well ... yes, essentially</dd> +<dt><antrik></dt><dd> LibreMan: but most people mean many other things too when talking about "clouds"</dd> +<dt><antrik></dt><dd> and anyways, you can't really forget about the iron. there is a middle layer which you don't have control of</dd> +<dt><LibreMan></dt><dd> antrik: sure, I would say that most people do not know what they mean :)</dd> +<dt><Tekk_></dt><dd> hmm</dd> +<dt><Tekk_></dt><dd> ArneBab: I can see a big place for virtualization in browsers</dd> +<dt><Tekk_></dt><dd> I mean, with everyone so worried about the code getting executed there, we just have GNUBrowse run in it's own little environment all closed off</dd> +<dt><ArneBab></dt><dd> Tekk_: me too: safe subenvironments.</dd> +<dt><LibreMan></dt><dd> the reason I follow Hurd is because i would LOVE to have viable GPLv3 OS as opposed to GPLv2 Linux</dd> +<dt><antrik></dt><dd> that's not a good reason</dd> +<dt><LibreMan></dt><dd> there are people hard at work subverting Linux</dd> +<dt><antrik></dt><dd> first of all, we'd have to get rid of all Linux code</dd> +<dt><LibreMan></dt><dd> locking it down ... and Linus doesn't seem to care</dd> +<dt><antrik></dt><dd> also, if that's all you care about, it would be less work to implement a simple monolithic kernel from scratch</dd> +<dt><LibreMan></dt><dd> antrik: so why is hurd a good idea if it's so much harder to develop?</dd> +<dt><-- azeem (~mbanck@p5DF41DDE.dip0.t-ipconnect.de) hat das Netzwerk verlassen (Ping timeout: 240 seconds) +<LibreMan></dt><dd> antrik: I thought that was the reason all along ... to develop GNU mopatible kernel</dd> +<dt><Tekk_></dt><dd> LibreMan: what do you mean GNU compatible?</dd> +<dt><LibreMan></dt><dd> Tekk_: the philosophy of GNU</dd> +<dt><Tekk_></dt><dd> ah, yes they've always needed a gnu kernel</dd> +<dt><LibreMan></dt><dd> the reason why it was created in a first place</dd> +<dt><ArneBab></dt><dd> LibreMan: I just added a missing part in the article: </dd> +<dt><ArneBab></dt><dd> “And the fact that a translator is just a simple standalone program means that these can be shared and tested much more easily, opening up completely new options for lowlevel hacking, because it massively lowers the barrier of entry.</dd> +<dt><ArneBab></dt><dd> ”</dd> +<dt><LibreMan></dt><dd> ok, next question :) why is it so hard to make Hurd work?</dd> +<dt><ArneBab></dt><dd> because we are so few people… </dd> +<dt><LibreMan></dt><dd> I mean, it's in developement for 20 years or so, no?</dd> +<dt><Tekk_></dt><dd> LibreMan: it's never been done before too</dd> +<dt><LibreMan></dt><dd> ArneBab: well, one person developed Linux</dd> +<dt><ArneBab></dt><dd> One person make Linux basically work</dd> +<dt><Tekk_></dt><dd> LibreMan: there has *never* been a full microkernel outside of research, which is what hurd plans to be</dd> +<dt><Tekk_></dt><dd> LibreMan: yeah, one person made linux kinda work in a year, then basically handed it off to everyone to help</dd> +<dt><LibreMan></dt><dd> but if it's so much complicated to develop, is it worth it?</dd> +<dt><Tekk_></dt><dd> LibreMan: and that was with a well trodden path that everyone knwos</dd> +<dt><ArneBab></dt><dd> But for the Hurd to basically work means it already provides far more options than waat Linux did.</dd> +<dt><ArneBab></dt><dd> That’s why the foundation is harder: It makes everything else easier.</dd> +<dt><ArneBab></dt><dd> But at the moment it works.</dd> +<dt><ArneBab></dt><dd> And I think I’ll just repeat that: The Hurd works. It is not feature complete, but all the really hard parts work.</dd> +<dt><ArneBab></dt><dd> Missing are many of the hard (but not really hard) parts, like adding drivers.</dd> +<dt><ArneBab></dt><dd> (and then there are ultra hard features which are possible but currently layed off, but now I get into beat-em-up speech :) )</dd> +<dt><LibreMan></dt><dd> I would define "works" as I can install it right now and run stable system ... I do not think it worls in those terms</dd> +<dt><ArneBab></dt><dd> LibreMan: that I’d define as production system</dd> +<dt><youpi></dt><dd> LibreMan: define "stable"</dd> +<dt><Tekk_></dt><dd> LibreMan: I'm pretty sure linux didn't "work" by your definition when linus passed it off</dd> +<dt><ArneBab></dt><dd> But I can start a Hurd right now and code in it.</dd> +<dt><LibreMan></dt><dd> ArneBab: yeah, that's waht "works" means for me :)</dd> +<dt><ArneBab></dt><dd> I can start emacs</dd> +<dt><youpi></dt><dd> LibreMan: I wouldn't even call my linux "stable"</dd> +<dt><youpi></dt><dd> as I just need to unplug my external USB hdd to make it crash...</dd> +<dt><youpi></dt><dd> while in a hurd system, it'd just crash the corresponding ext2fs daemon only</dd> +<dt><LibreMan></dt><dd> youpi: well yes :) but you can function on it pretty successfully ...</dd> +<dt><ArneBab></dt><dd> LibreMan: Frankly all I’m missing for a production environment are USB support and Audio.</dd> +<dt><youpi></dt><dd> you can on a hurd system too</dd> +<dt><ArneBab></dt><dd> (and it should work on an OLPC)</dd> +<dt><LibreMan></dt><dd> youpi: without USB and sound? :P</dd> +<dt><ArneBab></dt><dd> Both are driver issues. No problem in the kernel.</dd> +<dt><youpi></dt><dd> I seldomly use USB and sound actually</dd> +<dt><youpi></dt><dd> and never for my actual work</dd> +<dt><-- Tekk_ (~user@2002:474d:d1e9:0:21d:72ff:fe24:4c37) hat das Netzwerk verlassen (Remote host closed the connection) +--></dt><dd> Tekk_ (~user@2002:474d:d1e9:0:21f:3aff:fe54:7cc3) hat #hurd betreten</dd> +<dt><LibreMan></dt><dd> youpi: yeah, but how many users can ay that?</dd> +<dt><youpi></dt><dd> so what?</dd> +<dt><youpi></dt><dd> how many users can install linux?</dd> +<dt><youpi></dt><dd> does that make it unsuccessful?</dd> +<dt><LibreMan></dt><dd> many people actually</dd> +<dt><youpi></dt><dd> well, many people don't care about USB and sound either</dd> +<dt><youpi></dt><dd> depends what you mean by "many"</dd> +<dt><LibreMan></dt><dd> compared to how many do not mind having USB and sound ...</dd> +<dt><youpi></dt><dd> just like depends what you mean by "stable"</dd> +<dt><youpi></dt><dd> so _basically_ it works</dd> +<dt><youpi></dt><dd> not for all users on earth of course</dd> +<dt><youpi></dt><dd> not for all linux users of course</dd> +<dt><youpi></dt><dd> but for a lot of them already</dd> +<dt><ArneBab></dt><dd> LibreMan: USB and Sound are just driver issues.</dd> +<dt><ArneBab></dt><dd> They are not part of the core functionality.</dd> +<dt><Tekk_></dt><dd> LibreMan: usb keyboards and mice work though</dd> +<dt><LibreMan></dt><dd> ArneBab: sure, but that doesn't matter ... user doen't care about the technicalities ...</dd> +<dt><Tekk_></dt><dd> I think</dd> +<dt><ArneBab></dt><dd> LibreMan: But for the Hurd it means that it’s no general unsolved problem, but just an issue of too little coders to do the work.</dd> +<dt><LibreMan></dt><dd> if it's driver, kernel, microkernel whatever ... does it work or not, that's what it comes down to</dd> +<dt><ArneBab></dt><dd> s/too little/too few/</dd> +<dt><LibreMan></dt><dd> so it's a matter of attracting more people to work on it</dd> +<dt><ArneBab></dt><dd> LibreMan: yes</dd> +<dt><ArneBab></dt><dd> The Arch people helped a lot with that, because 2 distributions is not just 2× one distribution (in it’s outside effect)</dd> +<dt><ArneBab></dt><dd> But we need more people who do the easy work.</dd> +<dt><ArneBab></dt><dd> relatively easy… </dd> +<dt><ArneBab></dt><dd> porting the 10-15% packages which just have PATH_MAX issues.</dd> +<dt><LibreMan></dt><dd> so there would need to be sufficient motivations for them to join developement ... so far I do not see any different than Free Software ideals</dd> +<dt><ArneBab></dt><dd> for example</dd> +<dt><ArneBab></dt><dd> jupp</dd> +<dt><ArneBab></dt><dd> plus some cool options.</dd> +<dt><ArneBab></dt><dd> and experimenting in low-level</dd> +<dt><ArneBab></dt><dd> “ever wanted to write your own filesystem from scratch - and test it without wrecking your box?”</dd> +<dt><LibreMan></dt><dd> I do not understand why FSF does not do something similar to GSoC</dd> +<dt><ArneBab></dt><dd> LibreMan: I assume “too little money”…</dd> +<dt><Tekk_></dt><dd> LibreMan: hurd is in the gsoc</dd> +<dt><LibreMan></dt><dd> yeah, that would be the obvious answer :) and the right onw I guess</dd> +<dt><ArneBab></dt><dd> Besides: antrik, do you know how jkkenig fares?</dd> +<dt><Tekk_></dt><dd> LibreMan: gsoc is a per project thing, and most of them don't need the help</dd> +<dt><ArneBab></dt><dd> jkoenig</dd> +<dt><LibreMan></dt><dd> Tekk_: I know ... I just do not like that a company like Google needs to sponsor it and "we" are not selfsufficient</dd> +<dt><ArneBab></dt><dd> LibreMan: well, too few people are used to pay for what they like instead of for what requires payment.</dd> +<dt><ArneBab></dt><dd> But that is changing.</dd> +<dt><LibreMan></dt><dd> ArneBab: exactly ...</dd> +<dt><LibreMan></dt><dd> things like Flattr are trying to change that mentalty</dd> +<dt><ArneBab></dt><dd> Besides (stable): Hurd runs the Hurd wiki.</dd> +<dt><ArneBab></dt><dd> http://www.bddebian.com/~hurd-web/</dd> +<dt><LibreMan></dt><dd> I'm quite surprised I did not know about this http://www.fossfactory.org</dd> +<dt><LibreMan></dt><dd> I was planning to make such a website myself ...</dd> +<dt><LibreMan></dt><dd> I do not understand why it doesn't get more publicity ... the way Kickstarted does</dd> +<dt>-*- ArneBab goes lurker, sons here +<jkoenig></dt><dd> ArneBab, I have exams till friday, I should be more present after that</dd> +<dt><Tekk_></dt><dd> what does the hello world translator do? XD</dd> +<dt><ArneBab></dt><dd> Tekk_: content = hello</dd> +<dt><antrik></dt><dd> ArneBab: I have no idea about the status of GSoC</dd> +<dt><antrik></dt><dd> I haven't even read my mails for a couple of weeks; so you probably know more than me</dd> +<dt><antrik></dt><dd> Tekk_: provide a pseudo-file with "hello world" as contents</dd> +<dt><Tekk_></dt><dd> ah</dd> +<dt><antrik></dt><dd> BTW, gvfs is actually my favourite example of why the Hurd architecture makes sense</dd> +<dt><antrik></dt><dd> they implemented an extra GNOME-specific VFS layer, that is mostly redundant with the kernel one, adding complexity, overhead, and not integrated with the rest of the system -- and the only reason they need it is because the kernel VFS of traditional systems is too limited</dd> +<dt><antrik></dt><dd> with the Hurd's decentralized VFS, they could have implemented everything they need trivially right in the system VFS layer</dd> +<dt><antrik></dt><dd> the question is not really what features are possible with the Hurd architecture: given enough effort, any feature can be implemented with any architecture. it's the amount of effort that differs, making some things *feasible* that are not on other systems</dd> +<dt><Tekk_></dt><dd> see: windows ME</dd> +<dt><antrik></dt><dd> there is no reason for example why things like isolated subenvironments couldn't be implemented on Linux. (and it fact it's clearly moving in that direction, with the virtualisation hype) -- but it requires a shitload of kernel changes. while on Hurd all it needs is a little userspace programming</dd> +<dt><antrik></dt><dd> and every new feature added to Linux container solutions require further kernel hacking</dd> +<dt><antrik></dt><dd> or every new feature added to FUSE</dd> +<dt><antrik></dt><dd> and so on</dd> +</dl> + +[[!tag open_issue_documentation]] diff --git a/contributing/web_pages/news.mdwn b/contributing/web_pages/news.mdwn index a700c3ad..54fa788d 100644 --- a/contributing/web_pages/news.mdwn +++ b/contributing/web_pages/news.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2010, 2011 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,103 +9,28 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title="""How to prepare and publish "a month of the Hurd" for the last +[[!meta title="""How to prepare and publish a "Month of the Hurd" for the last month"""]] -We prepare *a month of the Hurd* in a public git branch (`master-news_next`), -and merge that one into `master` once we want to publish the news. The idea is -to record to-be-published changes on that branch at they time they arise, and -then publish them en bloc at the end of the month. +We prepare a *Month of the Hurd* in the file [[moth_next]]. The idea is +to record to-be-published changes in that file at they time they arise, and +then publish them en bloc at the end of the month. There are instructions for +[[writing_the_moth]]. -As this is done on a separate branch, there are two options: you can have -separate repositories (*clones*, or *checkouts*; what you get from `git clone`) -for the `master` and `master-news_next` branches, or you can deal with both in -the same repository. Having separate repositories you don't have to remember -which branch you're on, and don't have to switch between branches before -beginning to edit files, and it doesn't matter -- as no switching between -branches is needed -- if you have uncomitted changes to some files. On the -other hand, you may want to keep it all in one repository, to save disk space, -and for shuffling different branches' commits being (a bit) easier. + * At the end of the month: prepare for publishing the MotH, then send the raw + Markdown text to the mailing list, asking for feedback. -For practical work that means to use the following commands: + * ..., and publish. - * create a local branch for `master-news_next` - - $ git fetch - $ git checkout -b master-news_next origin/master-news_next - - * if you already have created a local branch `master-news_next`: update to - the latest version of it - - $ git checkout master-news_next - $ git pull --rebase - - * edit - - Always do check which branch you're on (asterisk in the first column of - `git branch`'s output), and only then begin to do your changes and commit - them. - - We should not update news items that have already been published (that is, - on <http://www.gnu.org/software/hurd/news.html>; no problem for the - [[staging area|web_pages#staging_area]]), as the system will always also - update the RSS feeds, etc., causing the old news item to reappear on feeds, - which is a bit of a nuisance. - - * at the beginning of a month: create a new news entry - - $ cp contributing/web_pages/news/skeleton.mdwn news/YYYY-MM.mdwn - $ # edit the new file, then add the changes in git - $ git add news/YYYY-MM.mdwn - $ git commit -m "Begun the news entry for YYYY-MM." - - That is, use the [[news skeleton|skeleton]] as a template for the new - news snippet. It also includes a list of the places to watch for news. - - * check the outgoing changes - - $ git log --reverse -p -C origin/master-news_next..master-news_next - - * push the changes - - $ git push origin master-news_next - - * if push fails, pull and rebase the local changes on top of the remote - changes - - $ git pull --rebase - - This will only happen if someone else has been installing commits into - `origin`'s `master-news_next` branch since the last time you - synchronized to it. - - Note that this might cause some conflicts to arise -- if the remote - repository contains commits that conflict with any that you've been - recording in your local repository. For this reason, you might want to - already do this *rebase* before beginning you local edits, simply to - shorten the time frame in which such conflicts can arise. - (Theoretically, in the very rare case of very much concurrent editing - going on, you'd have to repeat this again (and again...) before - succeeding to push your changes.) - - * at the end of the month: prepare for publishing the news + $ git mv contributing/web_pages/news/moth_next.mdwn news/YYYY-MM.mdwn Edit the news entry's *meta date* value to the timestamp when the news - entry is [[published|news]]. We have to set that one manually, as - otherwise the timestamp of the news entry file's creation will be taken, - which is (much) earlier, and not what we want. We do not set the *meta - updated* value, as it's correct to update that one upon further - modifications of the news entries. - - * ... and publish - - $ git checkout master - $ git pull --rebase - $ git merge master-news_next + entry is published. We have to set that one manually, as otherwise the + timestamp of the news entry file's creation will be taken, which is (much) + earlier, and not what we want. We do not set the *meta updated* value, as + it's correct to update that one upon further modifications of the news + entries. + + $ git cp contributing/web_pages/news/skeleton.mdwn contributing/web_pages/news/moth_next.mdwn + $ git commit -m 'MotH YYYY-MM.' $ git push origin master - - That means, for publishing we merge `master-news_next` into `master`. - After that merge, work for the next month's news item can continue on - `master-news_next`. - - Arne Babenhauserheide uses a [[merge-news]] script for doing this. diff --git a/contributing/web_pages/news/merge-news b/contributing/web_pages/news/merge-news deleted file mode 100644 index 33c01b7b..00000000 --- a/contributing/web_pages/news/merge-news +++ /dev/null @@ -1,13 +0,0 @@ -#!/bin/sh - -# merge into master -git checkout master -git pull --rebase -git merge master-news_next - -# push master -git push origin master - -# switch back to master-news_next -git checkout master-news_next -git pull --rebase diff --git a/contributing/web_pages/news/moth_next.mdwn b/contributing/web_pages/news/moth_next.mdwn new file mode 100644 index 00000000..1d543634 --- /dev/null +++ b/contributing/web_pages/news/moth_next.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +<!-- Date when the news item is (to be) pulished (important for RSS feeds). +Will be set by tschwinge when publishing. +[[!meta date="YYYY-MM-DD HH:MM UTC"]] +--> + +<!-- This is just a skeleton. Use it to create a new MotH. --> + +A month of the Hurd: *TODO*, *TODO*, and *TODO*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +<!--basic structure of a MotH entry. Adapt, reduce and add points as needed. At the end, try to make the text flow as a whole.--> + +This month [hurd hacker] [item] + +Also … + +[our hackers] … + +Mainly thanks to … + +Additionally … + +And … + +[reason for contibuting to the Hurd] + +<!--see [[contributing/web_pages/news/writing_the_moth]] for additional information on writing the MotH.--> + +"""]] diff --git a/contributing/web_pages/news/skeleton.mdwn b/contributing/web_pages/news/skeleton.mdwn index 9867fd21..1d543634 100644 --- a/contributing/web_pages/news/skeleton.mdwn +++ b/contributing/web_pages/news/skeleton.mdwn @@ -13,7 +13,9 @@ Will be set by tschwinge when publishing. [[!meta date="YYYY-MM-DD HH:MM UTC"]] --> -A month of the Hurd: *TODO* / *TODO* / *TODO*. +<!-- This is just a skeleton. Use it to create a new MotH. --> + +A month of the Hurd: *TODO*, *TODO*, and *TODO*. [[!if test="included()" then="""[[!toggle id=full_news text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" else=" @@ -21,44 +23,22 @@ else=" [[!cut id="full_news" text=""" -Watch these places for news: - - * GNU - - * <http://lists.gnu.org/archive/html/bug-hurd/YYYY-MM/threads.html> - - * <http://lists.gnu.org/archive/html/commit-hurd/YYYY-MM/threads.html> - - * <http://lists.gnu.org/archive/html/help-hurd/YYYY-MM/threads.html> - - * <http://lists.gnu.org/archive/html/web-hurd/YYYY-MM/threads.html> - - * <http://lists.gnu.org/archive/html/hurd-devel/YYYY-MM/threads.html> - - * <http://sourceware.org/ml/libc-alpha/YYYY-MM/> - - Also Git log. - - * (<http://sourceware.org/ml/libc-hacker/YYYY-MM/>) - - * (<http://sourceware.org/ml/glibc-cvs/YYYY-qQ/>) - - Better use the Git log. +<!--basic structure of a MotH entry. Adapt, reduce and add points as needed. At the end, try to make the text flow as a whole.--> - * <http://lists.gnu.org/archive/html/l4-hurd/YYYY-MM/threads.html> +This month [hurd hacker] [item] - * Debian +Also … - * <http://lists.debian.org/debian-hurd/YYYY/MM/> +[our hackers] … - * <http://lists.debian.org/debian-glibc/YYYY/MM/> +Mainly thanks to … - * Arch Hurd +Additionally … - * <http://www.archhurd.org/news.php> +And … - * <http://planet.archhurd.org/> +[reason for contibuting to the Hurd] - * (<http://lists.archhurd.org/devel/maillist.html>) +<!--see [[contributing/web_pages/news/writing_the_moth]] for additional information on writing the MotH.--> """]] diff --git a/contributing/web_pages/news/writing_the_moth.mdwn b/contributing/web_pages/news/writing_the_moth.mdwn new file mode 100644 index 00000000..82a25088 --- /dev/null +++ b/contributing/web_pages/news/writing_the_moth.mdwn @@ -0,0 +1,77 @@ +[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] + +# Short Guide for Writing the MotH + + +## Individual News Items + +The basic structure for a news item is as follows: *\[person with](link) did +\[task with}(link to testable code/patch) which brings us further towards +\[[goal]] by [short, easily understandable description of the contribution]*. + +Each news item should show a step towards the mission of the Hurd. From +[[community/weblogs/antrik/hurd-mission-statement]] you can +glean the following basic goals: + + * Better support for day-to-day desktop use (more packages, more stable, more + drivers, easier to setup, ...). + * More user freedom and possibilities for programs/translators. + * Technical advancement. + * More unique or at least interesting features. + * Attract more developers and/or users. + +The reason for this structure is to resolve the problem that many people think +that the Hurd won't ever be finished by concentrating on the improvements and +the steps towards completing our mission -- but only once they have actually +been done (to avoid showing anything which might become vaporware). + + +## Sources for News Items + +Watch these places for news: + + * GNU + + * <http://lists.gnu.org/archive/html/bug-hurd/YYYY-MM/threads.html> + + * <http://lists.gnu.org/archive/html/commit-hurd/YYYY-MM/threads.html> + + * <http://lists.gnu.org/archive/html/help-hurd/YYYY-MM/threads.html> + + * <http://lists.gnu.org/archive/html/web-hurd/YYYY-MM/threads.html> + + * <http://lists.gnu.org/archive/html/hurd-devel/YYYY-MM/threads.html> + + * <http://sourceware.org/ml/libc-alpha/YYYY-MM/> + + Also Git log. + + * (<http://sourceware.org/ml/libc-hacker/YYYY-MM/>) + + * (<http://sourceware.org/ml/glibc-cvs/YYYY-qQ/>) + + Better use the Git log. + + * <http://lists.gnu.org/archive/html/l4-hurd/YYYY-MM/threads.html> + + * Debian + + * <http://lists.debian.org/debian-hurd/YYYY/MM/> + + * <http://lists.debian.org/debian-glibc/YYYY/MM/> + + * Arch Hurd + + * <http://www.archhurd.org/news.php> + + * <http://planet.archhurd.org/> + + * (<http://lists.archhurd.org/devel/maillist.html>) @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -35,6 +35,8 @@ Porting glibc to a specific architecture is non-trivial. * [[open_issues/secure_file_descriptor_handling]] + * [[signal/signal_thread]] + ## Concepts diff --git a/glibc/signal.mdwn b/glibc/signal.mdwn index 67028fef..84153cff 100644 --- a/glibc/signal.mdwn +++ b/glibc/signal.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2010, 2011 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,7 +10,7 @@ is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] The [[*UNIX signalling mechanism*|unix/signal]] is implemented for the GNU Hurd -by means of a separate *signal-handling [[thread]]* that is part of every +by means of a separate *[[signal_thread]]* that is part of every [[process]]. This makes handling of signals a separate thread of control. * [[SA_SIGINFO, SA_SIGACTION|open_issues/sa_siginfo_sa_sigaction]] diff --git a/glibc/signal/signal_thread.mdwn b/glibc/signal/signal_thread.mdwn new file mode 100644 index 00000000..28855dbd --- /dev/null +++ b/glibc/signal/signal_thread.mdwn @@ -0,0 +1,93 @@ +[[!meta copyright="Copyright © 2011 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]] + + <braunr> bugs around signals are very tricky + <braunr> signals are actually the most hairy part of the hurd + <braunr> and the reason they're aynchronous is that they're handled by a + second thread + <braunr> (so yes, every process on the hurd has at least two threads) + <svante_> braunr: How to solve the asynch problem then if every process has + two threads? + <braunr> the easiest method would be to align ourselves on what most other + Unices do + <braunr> establish a "signal protocol" between kernel and userspace + <braunr> with a set of signal info in a table, most likely at the top of + the stack + <braunr> but this is explicitely what the original Mach developers didn't + want, and they were right IMO + <braunr> having two threads is very clean, but it creates incompatibilites + with what POSIX requires + <braunr> so there might be a radical choice to make here + <braunr> and i doubt we have the resources to make it happen + <svante_> What is the advantage of having two threads per process, a per + the original design? + <braunr> it's clean + <braunr> you don't have to define async-signal-safe functions + <braunr> it's like using sigwait() yourself in a separate thread, or + multiplexing them through signalfd() + <svante_> Regardless of the advantages, isn't two threads per process a + waste of resources? + <braunr> sure it is + <braunr> but does it really matter ? + <braunr> mach and the hurd were intended to be "hyperthreaded" + <braunr> so basically, a thread should consume only a few kernel resources + <braunr> in GNU Mach, it doesn't even consume a kernel stack because only + continuations are used + <braunr> and in userspace, it consumes 2 MiB of virtual memory, a few table + entries, and almost no CPU time + <svante_> What does "hyperthreaded" mean: Do you have a reference? + <braunr> in this context, it just means there are a lot of threads + <braunr> even back in the 90s, the expected number of threads could scale + up to the thousand + <braunr> today, it isn't much impressive any more + <braunr> but at the time, most systems didn't have LWPs yet + <braunr> and a process was very expensive + <svante_> Looks like I have some catching up to do: What is "continuations" + and LWP? Maybe I also need a reference to an overview on multi-threading. + <ArneBab> Lightweight process? + http://en.wikipedia.org/wiki/Light-weight_process + <braunr> svante_: that's a whole computer science domain of its own + <braunr> yes + <braunr> LWPs are another names for kernel threads usually + <braunr> continuations are a facility which allows a thread to store its + state, yield the processor to another thread, and when it's dispatched + again by the scheduler, it can resume with its saved state + <braunr> most current kernels support kernel preemption though + <braunr> which means their state is saved based on scheduler decisions + <braunr> unlike continuations where the thread voluntarily saves its state + <braunr> if you only have continuations, you can't have kernel preemption, + but you end up with one kernel stack per processor + <braunr> while the other model allows kernel preemption and requires one + kernel stack per thread + <svante_> I know resources are limited, but it looks like kernel preemption + would be nice to have. Is that too much for a GSoC student? + <braunr> it would require a lot of changes in obscure and sensitive parts + of the kernel + <braunr> and no, kernel preemption is something we don't actually need + <braunr> even current debian linux kernels are built without kernel + preemption + <braunr> and considering mach has hard limitations on its physical memory + management, increasing the amount of memory used for kernel stacks would + imply less available memory for the rest of the system + <svante_> Are these hard limits in mach difficult to change? + <braunr> yes + <braunr> consider mach difficult to change + <braunr> that's actually one of the goals of my stalled project + <braunr> which I hope to resume by the end of the year :/ + <svante_> Reading Wikipedia it looks like LWP are "kernel treads" and other + threads are "user threads" at least in IBM/AIX. LWP in Linux is a thread + sharing resources and in SunOS they are "user threads". Which is closest + for Hurd? + <braunr> i told you + <braunr> 14:09 < braunr> LWPs are another names for kernel threads usually + <svante_> Similar to to the IBM definition then? Sorry for not remembering + what I've been reading. diff --git a/hurd/running.mdwn b/hurd/running.mdwn index 752107f1..a51b40cf 100644 --- a/hurd/running.mdwn +++ b/hurd/running.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] There are several different ways to run a GNU/Hurd system: @@ -15,7 +15,7 @@ There are several different ways to run a GNU/Hurd system: * [[microkernel/mach/gnumach/ports/Xen]] - In Xen * [[Live_CD]] * [[QEMU]] - In QEMU -* [[vbox]] - In VirtualBox +* [[VirtualBox]] - In VirtualBox * [[vmware]] (**non-free!**) * [[FlashHurd]] - From a flash stick diff --git a/hurd/running/debian/after_install.mdwn b/hurd/running/debian/after_install.mdwn index 15ca9c83..62fd3574 100644 --- a/hurd/running/debian/after_install.mdwn +++ b/hurd/running/debian/after_install.mdwn @@ -29,7 +29,8 @@ If the NIC was detected: # settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a 192.168.1.3 -g 192.168.1.1 -m 255.255.255.0 -In order to use DHCP, you need to install the `dhcp-client` package and run `dhclient eth0` etc. +Or read about how to configure [[DHCP]]. + # Setup GRUB diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn new file mode 100644 index 00000000..f316981d --- /dev/null +++ b/hurd/running/debian/dhcp.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2011 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_porting]] + +In order to use DHCP, you need to install the `ifup` and `isc-dhcp-client` +packages, and manually create the following two symbolic links: + + # ln -s ../rcS.d/S06ifupdown-clean ../rcS.d/S11networking /etc/rc.boot/ + +During execution at boot time, the `S11networking` script will emit some error +messages while trying to configure the loopback interface. These are not +fatal. + +Debian GNU/Hurd doesn't currently execute's Debian standard `/etc/rcS.d/*` boot +scripts, but has its own `/libexec/rc` script -- which integrates scripts from +`/etc/rc.boot/` instead. diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 67a1be7c..4766b2be 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -230,9 +230,7 @@ If you just want to access the internet from within QEMU, you can setup pfinet f # settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0 # echo "nameserver 10.0.2.3" > /etc/resolv.conf -Alternately DHCP does work now: - - # dhclient eth0 +If you are on [[Debian GNU/Hurd|debian]], you can even use [[debian/DHCP]]. To get ssh working: diff --git a/hurd/running/vbox.mdwn b/hurd/running/virtualbox.mdwn index 475abf4a..02ab88e7 100644 --- a/hurd/running/vbox.mdwn +++ b/hurd/running/virtualbox.mdwn @@ -5,10 +5,15 @@ 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]]."]]"""]] -## Installation +[[!meta title="VirtualBox"]] + +<http://www.virtualbox.org/> + + +# Installation The disk controller has to be configured as IDE. Neither SATA nor SCSI are supported. diff --git a/hurd/status.mdwn b/hurd/status.mdwn index fe56f183..9986d8b7 100644 --- a/hurd/status.mdwn +++ b/hurd/status.mdwn @@ -41,8 +41,8 @@ out the latest development version, and send feedback to the Hurd developers. -The Hurd team doesn't create Hurd-only releases, but instead relies -on a distribution done by folks from *Debian*. +The Hurd team doesn't create Hurd-only releases, but instead relies on +a distribution done by folks from *Debian* and since 2010 also *Arch*. That Debian version closely tracks the progress of the Hurd (and often includes many new features), @@ -55,6 +55,9 @@ to test-drive the Hurd in a real life system with access to about The most recent version of the Debian port at the time of writing is *Debian GNU/Hurd L1*. +[[Arch_Hurd|hurd/running/arch_hurd]] offers *LiveCDs* for testing and +install. + That said, the last official release of the Hurd without the Debian parts was 0.2 done in 1997. diff --git a/hurd/translator/pfinet.mdwn b/hurd/translator/pfinet.mdwn index cbe50b48..f6f69ea4 100644 --- a/hurd/translator/pfinet.mdwn +++ b/hurd/translator/pfinet.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008 Free Software +[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] To configure Internet connectivity, the `pfinet` (*Protocol Family Internet*) [[translator]] must be configured. This is done using the @@ -31,5 +31,8 @@ installation. --- + * [[DHCP]]. + * [[Implementation]]. + * [[IPv6]]. diff --git a/unsorted/DhcpClient.mdwn b/hurd/translator/pfinet/dhcp.mdwn index 442f4781..17776fa5 100644 --- a/unsorted/DhcpClient.mdwn +++ b/hurd/translator/pfinet/dhcp.mdwn @@ -1,4 +1,4 @@ -# <a name="DHCP_and_the_Hurd"> </a> DHCP and the Hurd +[[!tag open_issue_hurd]] According to the following thread, no port should be needed since all the patches that have been applied, including the one concerning the thread. In fact, the thread finishes without concluding whether the patch has been applied or not. You can grab it in the thread, anyway. @@ -40,3 +40,8 @@ Neal Walfield on bug-hurd replies: We need to be able to send to the DHCP server with ip address 0.0.0.0. -- [[Main/JoachimNilsson]] - 12 Nov 2002 + +--- + +[[Debian GNU/Hurd|running/debian]] has some script hackery to get +[[running/debian/DHCP]] going. diff --git a/open_issues/address_space_memory_mapping_entries.mdwn b/open_issues/address_space_memory_mapping_entries.mdwn new file mode 100644 index 00000000..caf447dd --- /dev/null +++ b/open_issues/address_space_memory_mapping_entries.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2011 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, 2011-05-07 + + <braunr> and as a last example: memory mapping is heavily used in the hurd, + but for some reason, the map entries in an address space are still on a + linked list + <braunr> a bare linked list + <braunr> which makes faults and page cache lookups even slower diff --git a/open_issues/ext2fs_page_cache_swapping_leak.mdwn b/open_issues/ext2fs_page_cache_swapping_leak.mdwn index 607c3af4..c0d0867b 100644 --- a/open_issues/ext2fs_page_cache_swapping_leak.mdwn +++ b/open_issues/ext2fs_page_cache_swapping_leak.mdwn @@ -149,3 +149,27 @@ IRC, freenode, #hurd, 2011-04-18 <antrik> this make testing this stuff quite a lot harder... [sigh] <antrik> any suggestions how to debug this hang? <braunr> antrik: no :/ + +2011-04-28: [[!taglink open_issue_documentation]] + + <antrik> hm... is it normal that "swap free" doesn't increase as a process' + memory is paged back in? + <youpi> yes + <youpi> there's no real use cleaning swap + <youpi> on the contrary, it makes paging the process out again longer + <antrik> hm... so essentially, after swapping back and forth a bit, a part + of the swap equal to the size of physical RAM will be occupied with stuff + that is actually in RAM? + <youpi> yes + <youpi> so that that RAM can be freed immediately if needed + <antrik> hm... that means my effective swap size is only like 300 MB... no + wonder I see crashes under load + <antrik> err... make that 230 actually + <antrik> indeed, quitting the application freed both the physical RAM and + swap space + <braunr> 02:28 < antrik> hm... is it normal that "swap free" doesn't + increase as a process' memory is paged back in? + <braunr> swap is the backing store of anonymous memory, like ext2fs is the + backing store of memory objects created from its pager + <braunr> so you can view swap as the file system for everything that isn't + an external memory object diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index 1b897454..a5dd6955 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -772,3 +772,76 @@ IRC, freenode, #hurd, 2011-04-12: <braunr> FreeBSD uses a binary buddy system like Linux <braunr> the fact that the kernel allocator uses virtual memory doesn't mean the kernel has no mean to allocate contiguous physical memory ... + +2011-05-02 + + <braunr> hm nice, my allocator uses less memory than glibc (squeeze + version) on both 32 and 64 bits systems + <braunr> the new per-cpu layer is proving effective + <neal> braunr: Are you reimplementation malloc? + <braunr> no + <braunr> it's still the slab allocator for mach, but tested in userspace + <braunr> so i wrote malloc wrappers + <neal> Oh. + <braunr> i try to heavily test most of my code in userspace now + <neal> it's easier :-) + <neal> I agree + <braunr> even the physical memory allocator has been implemented this way + <neal> is this your mach version? + <braunr> virtual memory allocation will follow + <neal> or are you working on gnu mach? + <braunr> for now it's my version + <braunr> but i intend to spend the summer working on ipc port names + management + +[[rework_gnumach_IPC_spaces]]. + + <braunr> and integrate the result in gnu mach + <neal> are you keeping the same user-space API? + <neal> Or are you experimenting with something new? + <antrik> braunr: to be fair, it's not terribly hard to use less memory than + glibc :-) + <braunr> yes + <braunr> antrik: well ptmalloc3 received some nice improvements + <braunr> neal: the goal is to rework some of the internals only + <braunr> neal: namely, i simply intend to replace the splay tree with a + radix tree + <antrik> braunr: the glibc allocator is emphasising performace, unlike some + other allocators that trade some performance for much better memory + utilisation... + <antrik> ptmalloc3? + <braunr> that's the allocator used in glibc + <braunr> http://www.malloc.de/en/ + <antrik> OK. haven't seen any recent numbers... the comparision I have in + mind is many years old... + <braunr> i also made some additions to my avl and red-black trees this week + end, which finally make them suitable for almost all generic uses + <braunr> the red-black tree could be used in e.g. gnu mach to augment the + linked list used in vm maps + <braunr> which is what's done in most modern systems + <braunr> it could also be used to drop the overloaded (and probably over + imbalanced) page cache hash table + +2011-05-03 + + <mcsim> antrik: How should I start porting? Have I just include rbraun's + allocator to gnumach and make it compile? + <antrik> mcsim: well, basically yes I guess... but you will have to look at + the code in question first before we know anything more specific :-) + <antrik> I guess braunr might know better how to start, but he doesn't + appear to be here :-( + <braunr> mcsim: you can't juste put my code into gnu mach and make it run, + it really requires a few careful changes + <braunr> mcsim: you will have to analyse how the current zone allocator + interacts with regard to locking + <braunr> if it is used in interrupt handlers + <braunr> what kind of locks it should use instead of the pthread stuff + available in userspace + <braunr> you will have to change the reclamiing policy, so that caches are + reaped on demand + <braunr> (this basically boils down to calling the new reclaiming function + instead of zone_gc()) + <braunr> you must be careful about types too + <braunr> there is work to be done ;) + <braunr> (not to mention the obvious about replacing all the calls to the + zone allocator, and testing/debugging afterwards) diff --git a/open_issues/inotify_file_notice_changes.mdwn b/open_issues/inotify_file_notice_changes.mdwn index a30cd3d3..6d644788 100644 --- a/open_issues/inotify_file_notice_changes.mdwn +++ b/open_issues/inotify_file_notice_changes.mdwn @@ -40,3 +40,8 @@ IRC, freenode, #hurd, 2011-03-28 <pochu> ok, I'll try to get to it soonish <pinotree> and you should know about two of them already ;D <pochu> please remind me if I don't :) + +--- + +Apparently fanotify is cosidered inotify's successor, so we might directly go +supporting that one instead, or both. --[[tschwinge]], 2011-05-10 diff --git a/open_issues/keymap_mach_console.mdwn b/open_issues/keymap_mach_console.mdwn new file mode 100644 index 00000000..3063dd00 --- /dev/null +++ b/open_issues/keymap_mach_console.mdwn @@ -0,0 +1,40 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +IRC, freenode, #hurd, 2011-04-26 + + <guillem> pavkac: btw are you aware there's already some code to change the + keymap for the mach console (I think originally from the hurdfr guys, but + I cannot remember exactly from where I got it from :/) + <guillem> pavkac: http://www.hadrons.org/~guillem/tmp/hurd-keymap.tgz + <pavkac> guillem: No, I didn't know. I'll diff it and try to follow. + <guillem> pavkac: it would be nice to maybe integrate it properly into the + hurd + <guillem> you'll see the code is pretty basic, so extending it would be + nice too I guess :) + <pavkac> guillem: OK, I'll see to it. Unfortunately I'm quite busy this + week. Have a lot of homeworks to school. :/ + <pavkac> guillem: But, I'll find some time during weekend. + <youpi> maybe it'd be simpler to add it to the hurd package and use that + from the console-setup package indeed + <youpi> but copyright issues should be solved + <youpi> unless we simply put this into hurdextras + <guillem> ok found this: + http://www.mail-archive.com/debian-hurd@lists.debian.org/msg02456.html + <guillem> and + http://www.mail-archive.com/debian-hurd@lists.debian.org/msg01173.html + <guillem> which seems to be the original Mark's code + <guillem> AFAIR I contributed the the spanish keymap and some additional + key definitions for loadkeys + <guillem> and http://lists.debian.org/debian-hurd/2000/10/msg00130.html + <pavkac> I've fetched all. :) But I must leave, good night if you're in + Europe. :) + <guillem> pavkac: the tarball I provided should be the latest, the others + are mostly to track the provenance of the source diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn index addc29c3..18fc257e 100644 --- a/open_issues/multithreading.mdwn +++ b/open_issues/multithreading.mdwn @@ -43,6 +43,8 @@ The [[hurd/Critique]] should have some more on this. * [[Erlang-style_parallelism]] + * [[!wikipedia Actor_model]] + * [libtcr - Threaded Coroutine Library](http://oss.linbit.com/libtcr/) * <http://monkey.org/~provos/libevent/> diff --git a/open_issues/pflocal_reauth.mdwn b/open_issues/pflocal_reauth.mdwn new file mode 100644 index 00000000..839e383d --- /dev/null +++ b/open_issues/pflocal_reauth.mdwn @@ -0,0 +1,39 @@ +[[!meta copyright="Copyright © 2011 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 open_issue_hurd]] + +IRC, freenode, #hurd, 2011-04-02 + + <pinotree> youpi: i'm playing with pflocal, and noticing that a simple C + executable doesn't trigger reauthenticate + <pinotree> youpi: i've put a debug output (to file) in S_io_reauthenticate, + and with a simple C test (which uses unix sockets) it isn't called + <youpi> pinotree: it seems pflocal should return FS_RETRY_REAUTH in + retry_type + <youpi> to make glibc call reauthentication + <pinotree> pflocal? + <youpi> yes, in the dir_lookup handler + <pinotree> isn't that ext2fs? + <youpi> libtrivfs had dir_lookup() too + <youpi> trivfs_check_open_hook can be used to tweak its behavior + <pinotree> ah, missed that pflocal was using libtrivfs, sorry + <youpi> there are probably very few translators which don't use one of the + lib*fs :) + <antrik> pinotree: what are you trying to do with pflocal? + <pinotree> local socket scredentials (SCM_CREDS) + <antrik> ah + <antrik> don't really know what that is, but I remember reading some + mention of it ;-) + +--- + +See also [[pflocal_socket_credentials_for_local_sockets]] and +[[sendmsg_scm_creds]]. diff --git a/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn index 5a71412e..dfdc213c 100644 --- a/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn +++ b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn @@ -40,3 +40,7 @@ IRC, freenode, #hurd, 2011-03-28 S_io_reauthenticate cached in the sock_user struct? <youpi> yes <pinotree> nice thanks, i will try that change first + +--- + +See also [[pflocal_reauth]] and [[sendmsg_scm_creds]]. diff --git a/open_issues/python.mdwn b/open_issues/python.mdwn index 34fa81f6..403ff8aa 100644 --- a/open_issues/python.mdwn +++ b/open_issues/python.mdwn @@ -27,6 +27,11 @@ First, make the language functional, have its test suite pass without errors. [[!inline pages=community/gsoc/project_ideas/perl_python feeds=no]] + +## Analysis + + * [[select_bogus_fd]] + --- diff --git a/open_issues/rework_gnumach_ipc_spaces.mdwn b/open_issues/rework_gnumach_ipc_spaces.mdwn index 5bf0c530..b7cda227 100644 --- a/open_issues/rework_gnumach_ipc_spaces.mdwn +++ b/open_issues/rework_gnumach_ipc_spaces.mdwn @@ -10,6 +10,14 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] +IRC, freenode, #hurd, 2011-05-07 + + <braunr> things that are referred to as "system calls" in glibc are + actually RPCs to the kernel or other tasks, those RPCs have too lookup + port rights + <braunr> the main services have tens of thousands of ports, looking up one + is slow + There is a [[!FF_project 268]][[!tag bounty]] on this task. IRC, freenode, #hurd, 2011-04-23 @@ -241,3 +249,72 @@ IRC, freenode, #hurd, 2011-04-23 <braunr> so a radix ree would be the most efficient <antrik> well, if some processes really feel they must use random numbers for port names, they *ought* to be penalized ;-) + +2011-04-27 + + <braunr> antrik: remember when you asked why high numbers would be a + problem with radix trees ? + <braunr> here is a radix tree with one entry, which key is around 5000 + <braunr> [ 656.296412] tree height: 3 + <braunr> [ 656.296412] index: 0, level: 0, height: 3, count: 1, + bitmap: 0000000000000002 + <braunr> [ 656.296412] index: 1, level: 1, height: 2, count: 1, + bitmap: 0000000000004000 + <braunr> [ 656.296412] index: 14, level: 2, height: 1, count: 1, + bitmap: 0000000000000080 + <braunr> three levels, each with an external node (dynamically allocated), + for one entry + <braunr> so in the worst case of entries with keys close to the highest + values, the could be many external nodes with higher paths lengths than + when keys are close to 0 + <braunr> which also brings the problem of port name allocation + <braunr> can someone with access to a buildd which has an uptime of at + least a few days (and did at least one build) show me the output of + portinfo 3 | tail ? + <braunr> port names are allocated linearly IIRC, like PIDs, and some parts + of the kernel may rely on them not being reused often + <braunr> but for maximum effifiency, they should be + <braunr> efficiency* + <braunr> 00:00 < braunr> can someone with access to a buildd which has an + uptime of at least a few days (and did at least one build) show me the + output of portinfo 3 | tail ? + <braunr> :) + <youpi> it's almost like wc -l + <youpi> 4905: receive + <youpi> vs 4647 + <youpi> for / + <youpi> 52902: receive + <youpi> vs 52207 + <youpi> for the chroot + <braunr> even after several builds ? + <braunr> and several days ? + <youpi> that's after 2 days + <youpi> it's not so many builds + <youpi> rossini is not so old + <youpi> (7h) + <youpi> but many builds + <youpi> 70927: send + <youpi> vs 70938 + <braunr> ok + <braunr> so it seems port names are reused + <braunr> good + <youpi> yes they are clearly + <braunr> i think i remember a comment about why the same port name + shouldn't be reused too soon + <youpi> well, it could help catching programming errors + <braunr> that it helped catch bugs in applications that could + deallocate/reallote quickly + <braunr> reallocate* + <braunr> without carefuly synchronization + <braunr> careful + <braunr> damn, i'm tired :/ + <youpi> but that's about debugging + <youpi> so we don't care about performance there + <braunr> yes + <braunr> i'll try to improve allocation performance too + <braunr> using e.g. bitmaps in each external node back to the root so that + unused slots are quickly found + <braunr> i thknk that's what idr does in linux + <antrik> braunr: idr? + <braunr> antrik: a data structure used to map integers to pointers + <braunr> http://fxr.watson.org/fxr/source/lib/idr.c?v=linux-2.6 diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn index ab6af90b..0f750631 100644 --- a/open_issues/select.mdwn +++ b/open_issues/select.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -12,12 +12,23 @@ License|/fdl]]."]]"""]] There are a lot of reports about this issue, but no thorough analysis. ---- + +# `elinks` IRC, unknown channel, unknown date. - <paakku> This is related to ELinks... I've looked at the select() implementation for the Hurd in glibc and it seems that giving it a short timeout could cause it not to report that file descriptors are ready. - <paakku> It sends a request to the Mach port of each file descriptor and then waits for responses from the servers. - <paakku> Even if the file descriptors have data for reading or are ready for writing, the server processes might not respond immediately. - <paakku> So if I want ELinks to check which file descriptors are ready, how long should the timeout be in order to ensure that all servers can respond in time? + <paakku> This is related to ELinks... I've looked at the select() + implementation for the Hurd in glibc and it seems that giving it a short + timeout could cause it not to report that file descriptors are ready. + <paakku> It sends a request to the Mach port of each file descriptor and + then waits for responses from the servers. + <paakku> Even if the file descriptors have data for reading or are ready + for writing, the server processes might not respond immediately. + <paakku> So if I want ELinks to check which file descriptors are ready, how + long should the timeout be in order to ensure that all servers can + respond in time? <paakku> Or do I just imagine this problem? + +--- + +See also [[select_bogus_fd]] and [[select_vs_signals]]. diff --git a/open_issues/select_bogus_fd.mdwn b/open_issues/select_bogus_fd.mdwn new file mode 100644 index 00000000..17aced4a --- /dev/null +++ b/open_issues/select_bogus_fd.mdwn @@ -0,0 +1,55 @@ +[[!meta copyright="Copyright © 2011 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]] + + +# Python + +IRC, freenode, #hurd, 2011-04-13 + + <abeaumont> ok, cause of first python testsuite failure located, now the + hard part, how to best fix it :) + <abeaumont> how to redesign the code to avoid the problem... that's the + hard part, mostly cause i lack contextual info + <abeaumont> tschwinge: the problem is pretty much summarized by this + comment in _hurd_select (in glibc): /* If one descriptor is bogus, we + fail completely. */ + <pochu> does POSIX say anything about what to do if one fd is invalid? + <pochu> and the other question is why python is calling select() with an + invalid fd + <abeaumont> pochu: yep, it says it should not fail completelly + <pochu> then that's our bug :) + <pinotree> abeaumont: just note that (at least on debian) some tests may + hang forever or cause hurd/mach to die + <pinotree> abeaumont: see in the debian/rules of the packaging of each + pythonX.Y source + <pinotree> ... there's a list of the tests excluded from the test suite run + <abeaumont> well, to be precise, python has a configure check for + 'broken_poll' which hurd fails, and therefore python's select module is + not built, and anything depending on it fails + <abeaumont> broken_poll checks exactly for that posix requirement + <abeaumont> the reason for python using a non-existant + descriptor... unknown :D + <pochu> we should fix select to not fail miserably in that case + <pinotree> abeaumont: we have a patch to fix the broken poll check to + actually disable the poll module + <pochu> pinotree: but the proper fix is to fix select(), which is what + abeaumont is looking at + <abeaumont> pinotree: i'd say that's exactly what python's configure check + does itself -- disable building the select module + <pochu> abeaumont: what pinotree means is that the check is broken, see + http://patch-tracker.debian.org/patch/series/view/python2.6/2.6.6-8/hurd-broken-poll.diff + <pinotree> yes, the configure check for poll does the check, but not + everything of the poll module gets disabled (and you get a build failure) + +--- + +See also [[select]] and [[select_vs_signals]]. diff --git a/open_issues/select_vs_signals.mdwn b/open_issues/select_vs_signals.mdwn new file mode 100644 index 00000000..bbd69d00 --- /dev/null +++ b/open_issues/select_vs_signals.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2011 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]] + + +# `sudo` + +`sudo [task]` hands after finishing `[task]`. + +IRC, freenode, #hurd, 2011-04-02 + + <youpi> the sudo bug is select() not being able to get interrupted by + signals + +--- + +See also [[select]] and [[select_bogus_fd]]. diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn index 1f4de59c..2deec7e8 100644 --- a/open_issues/sendmsg_scm_creds.mdwn +++ b/open_issues/sendmsg_scm_creds.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -89,3 +89,7 @@ IRC, unknown channel, unknown date. <youpi> (since it's just about letting the application reading from the message structure) <pinotree> yep <youpi> ok, good :) + +--- + +See also [[pflocal_socket_credentials_for_local_sockets]] and [[pflocal_reauth]]. diff --git a/open_issues/sigpipe.mdwn b/open_issues/sigpipe.mdwn new file mode 100644 index 00000000..0df3560e --- /dev/null +++ b/open_issues/sigpipe.mdwn @@ -0,0 +1,345 @@ +[[!meta copyright="Copyright © 2011 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 open_issue_hurd]] + +[[!GNU_Savannah_bug 461]] + +IRC, freenode, #hurd, 2011-04-20 + + <svante_> I found a problem from 2002 by Marcus Brinkmann that I think is + related to my problems: http://savannah.gnu.org/bugs/?461. He has a test + file called pipetest.c that shows that SIGPIPE is not triggered reliably. + <svante_> Cited from the bug report: The attached test program does not + trigger SIGPIPE reliably, because closing the read end of the pipe + happens asynchronously. The write can succeed because the read end might + not have been closed yet. + <svante_> I have debugged this program on both Hurd and Linux, and the + problem in Hurd remains:-( + <svante_> Anybody looked into the almost ten year old + bug:http://savannah.gnu.org/bugs/?461 this one is definitely related to + the build problems of e.g. ghc6 and ruby1.9.1. Should I mention this on + the ML? + <youpi> that could be it indeed + <youpi> does th bug still happen? + <azeem> depends on: new interface io_close + <azeem> which depends on: POSIX record locking + <svante_> youpi: Yes it does, I've tested the pipetest.c file submitted by + Marcus B on both Linux and Hurd + <azeem> that would've maybe been a nice GSOC task + <youpi> azeem: err, the contrary for posix record locking, non ? + <azeem> argh + <azeem> why would POSIX record locking depend on this? + <azeem> well anyway, then have POSIX record locking be a GSOC task :) + <azeem> I wasn't aware that would also fix ruby and ghc building :) + <youpi> http://permalink.gmane.org/gmane.os.hurd.devel.readers/265 + <youpi> (for io_close stuff) + <youpi> http://comments.gmane.org/gmane.os.hurd.devel.readers/63 actually + <azeem> I guess if they didn't implement it/agreed on something back then + it'd be quite hard to do it now + <svante_> azeem: marcus recently showed up here. Maybe he can help out/has + ideas? + <azeem> well yeah + <azeem> but marcus was the junior guy back then + <azeem> <marcus> but it's a very hurdish solution (ie, complex, buggy, and + not implemented) + <azeem> maybe we can go for something simpler + <youpi> azeem: what is this quote about? + <azeem> don't remember + <azeem> not io_close I'd say + +2011-04-21 + + <antrik> svante_: why do you think the problem you see in ruby and ghc is + related to async close() ? + +2011-04-22 + + <svante_> Well: the test case I'm running on ruby is giving me an EBADF + after 8 successful loops, and tracing within eglibc points towards + __mutex_lock_solid or __spin_lock, __spin_lock_solid from + mach/lock-intern.h from cthreads. + +2011-04-23 + + <antrik> srs1: yeah, I saw it... but I still wonder what makes you think + this is related to async FD closing? + <srs1> antrik: Every test case showing the problems are related to fd.h and + the functions there, especially the ones used in the function: + _HURD_FD_H_EXTERN_INLINE struct hurd_fd *_hurd_fd_get (int fd) and so is + the pipetest from Marcus too. + <srs1> I have not yet been able to trace further with gdb since most + variables are optimized out and adding print statements does not work, at + least not yet. Now I'm trying to build eglibc with -O1 to see if the + optimized out variables are there or not. + <youpi> srs1: he means the ghc6 issue + <youpi> (and the ruby issue) + <srs1> youpi: Yes, the ghc6 and ruby ends at the functions I mentioned in + fd,h + <srs1> Both ghc6 and ruby programs are writing to a file when the error + happens. If they are using a pipeline or not I don't know yet, I think it + is a regular file write. + <srs1> I can send your the ruby program if you like: It is a c-file so + debugging is possible. ghc6 is worse, since that program cannot be + debugged directly with gdb. + <antrik> pipetest also results in the program hanging in locking stuff?... + <srs1> pipetest does not hang, but gives no output as it should. Running it + in gdb with single stepping shows the correct behavior, but then gdb + hangs if I try to single stepping further, continue at the right place + works! + <antrik> I haven't looked at the pipetest program. do you have the link + handy? + <antrik> never mind, got it + <antrik> srs1: that sounds like a GDB problem... + <youpi> most probably, yes + <youpi> (and I've always seen issues like this in gdb on hurd) + <antrik> actually I think it's expected... the RPC handling code has some + explicit GDB hooks AIUI; trying to single-step into this code is probably + expected to wreck havoc... + <youpi> well, it should have some sane behavior + <youpi> even if it's "skip to next point where it's debuggable" + <antrik> srs1: note that there is no BADF involved in the pipetest AIUI... + +2011-04-28 + + <antrik> what is the actual problem you are seeing BTW? + <gnu_srs1> antrik: in ruby the problem is: Exception `IOError' at + tool/mkconfig.rb:12 - closed stream + <gnu_srs1> Triggered by ruby:io.c:internal_read_func() calling + sysdeps/mach/hurd/read.c returning a negative number of bytes read. + <abeaumont> gnu_srs1: why do you think that error is locking related? + <gnu_srs1> This happens after 8 iterations of the read loop with 8192 bytes + read each time. + <abeaumont> but that doesn't involve locking at all, does it? + <gnu_srs1> I think it is, if there is a pipepline set up?? + <gnu_srs1> Also the ghc6 hang ends up in hangs in sysdeps/mach/hurd/read.c + traced into fd.h where all things happen (including setting locks and + mutexes) + <braunr> what locking ? + <braunr> stdio locking is different from file locking + <braunr> and a pipe doesn't imply file locking at all + <abeaumont> read may block on pipes, but it's unrelated to flock + <gnu_srs1> Look into the file fd.h, maybe you can describe things + better. I'm not fluent in this stuff. + <gnu_srs1> Has a pipe has a file descriptor associated to it? What about a + file read/write? + <abeaumont> a pipe provides 2 file descriptors, one for reading and another + one for writting + <abeaumont> i may give a look at that if i manage to build glibc + succesfully... + <gnu_srs1> Take a look at the realevant code from fd.h: + http://pastebin.com/kesBpjy4 + <abeaumont> the ruby error happens just trying to build ruby1.9? + <abeaumont> gnu_srs1: from what you said, the error occurs while reading, + so i don't see how it can be related to that code + <abeaumont> you already got a descriptor if you're reading from it + <gnu_srs1> I have not tried anything else than ruby1.9.1. I can send you + the ruby debug setup and files if you are interested. + <abeaumont> gnu_srs1: ok, i'll try to build ruby1.9.1 later... let's see if + i can build glibc first + <gnu_srs1> abeaumont: well, the read suddenly returns -1 bytes read, + resulting in a file descriptor of -1 (instead of +3). + <abeaumont> gnu_srs1: i see + <antrik> gnu_srs1: are you sure the hang really happens in _hurd_fd_get()? + could you give us a backtrace? + <antrik> gnu_srs1: there are many reasons why read() can return -1; errno + should indicate the reason. unfortunately, I can't make much out of + ruby's "translation" of the error :-) + <gnu_srs1> antrik: In the ruby case there is no hang: The steam is closed + by read() giving an error code !=0. This triggers things in the ruby + code: A negative number of bytes read and a negative fd results, and an + error error is triggered in the ruby code. + <gnu_srs1> antrik: See http://pastebin.com/eZmaZQJr + <antrik> gnu_srs1: yes, this all sounds perfectly right. the question is + *why* read() returns an error code. we'd need to know what error it is + exactly, and in what situation it occurs. tracing the libc code is not at + all useful here + <antrik> uhm... 1073741833 is errno?... + <gnu_srs1> BTW: I think the error code is EBADF (badfile descriptor?). The + integer version of it is 1073741833, see the pastebin i linked to. + <antrik> you could use perror() to get something more readable :-) + <antrik> or error() with the right arguments + <gnu_srs1> I used integer when printing, but looking into fd.h I think it + is EBADF (I did get this result once in gdb) + <antrik> fd.h won't tell you anything. most error codes are generated by + the server, not by libc + <antrik> BADF might be generated in libc when ruby tries to read on FD -1 + <antrik> (no idea why it tries to do that... perhaps there is actually + something wrong/stupid in ruby's error handling) + <gnu_srs1> Well I single-stepped in fd.h using gdb and printing err gave + EBADf. err is declared as: error_t err in read.c + <antrik> at which point did you single-step? while fd was still 3? + <gnu_srs1> I don't think the problem is in ruby, it is in mach/hurd! + Similar problems with ghc, python-apt, etc + <gnu_srs1> Yes, fd=3 was not changed. I cannot trace into fd.h from + read.c. That is the problem with all cases! Need to leave for a while + now. + <antrik> sorry, I don't see *anything* similar in the ghc failure. + <antrik> I don't know about python-apt + <antrik> for the ghc case, I'd like to see a GDB backtrace from the point + where it is hanging + <antrik> just to be clear: anything I/O-related will involve fd.h + somewhere. that doesn't in any way indicate the problems are related. in + fact the symptoms you described are very different, and I'm pretty + certain these are completely different issues + <gnu_srs1> antrik: Here is a backtrace, + http://pastebin.com/wvCiXFjB. Numbers 6,7,8 are from the calling Haskell + functions. They cannot be debugged by gdb. Nice to see that somebody is + showing interest at last:-/ + <antrik> hm... I wonder whether the _hurd_intr_rpc_msg_in_trap is a result + of the ^C? + <antrik> if so, it seems to be a "normal" bloking read() operation. so + again probably not related to libc code at all + <gnu_srs1> Where is this blocking read() code located mach/hurd? + <antrik> io_read() is implemented by whatever server handles the FD in + question + <antrik> I guess rpctrace will be more helpful here than GDB... to see what + the program is trying to do here + <gnu_srs1> Why don't I get there with gdb? + <antrik> err... the server is a different process + <antrik> you are only tracing the client code + <gnu_srs1> OK, here is a rpctrace for ruby: + http://pastebin.com/sdPiKGBW.Nice programs you have, no manual pages, and + the program hang + <gnu_srs1> s/http://pastebin.com/sdPiKGBW.Nice + /http://pastebin.com/sdPiKGBW. BTW: Nice/ + <gnu_srs1> antrik: Do you want the rpctrace of the ghc hang too? If that is + the case, do you need the whole file. From the ruby case the last part + looked most interesting: + libpthread/sysdeps/generic/pt-mutex-timedlock.c: assert (mutex->owner != + self); + <antrik> gnu_srs1: hm... you get that assertion only with rpctrace? guess + it doesn't work properly then :-( + <gnu_srs1> Is it visible on the client side? + <antrik> gnu_srs1: that assertion *is* from the client side. I'm just + surprised that apparently it's only triggered when you run it in rpctrace + <antrik> how did you invoke rpctrace? + <gnu_srs1> rpctrace "command with options" > rpctrace.out 2>&1 + <antrik> well, I'd like to know the "command with options" part :-) + <gnu_srs1> OK: for ruby: ./miniruby ./ tool/mkconfig.rb as before. + <antrik> OK, so it just runs the ruby interpreter and no other processes + <gnu_srs1> No other processes involved! + <abeaumont> gnu_srs1: i can reproduce the ruby error, no let's dig in it :D + <antrik> gnu_srs1: rpctrace for ghc could be useful too... but if it's too + long, pasting only the last bit might suffice + <gnu_srs1> antrik: OK, will do that. Do you find anything interesting? + <gnu_srs1> abeaumont: Using gdb: gdb ./miniruby; (gdb) break io.c:569; c8; + break fd.h:72 or break read.c:27 and you are there. Beware of gdb + hanging, so you need another terminal to kill -9 gdb (sometimes a reboot + is needed :-( + <antrik> gnu_srs1: no, the ruby rpctrace is useless; apparently rpctrace + makes it break before reaching the relevant part :-( + <abeaumont> thanks gnu_srs1 + <gnu_srs1> antrik: Hope for better luck with ghc: + http://pastebin.com/dgcrA05t + <antrik> hm... it hangs at proc_dostop() again... whatever that means + +2011-05-07 + + <gnu_srs> One question about ruby: I know where the problems occur in ruby + code. Can I switch to the kernel thread just before in gdb to single step + from there? + <youpi> you can put a breakpoint, can't you? + <antrik> gnu_srs: kernel thread? + <gnu_srs> Yes, but will single stepping from there lead me to the Hurd + code. I have not succeeded to do that yet! + <youpi> you mean the translator code? + <gnu_srs> Well, Roland did call it the signal thread, there are at least + two threads per process, a signal thread and a main (user) thread. + <youpi> then it's a thread in gdb + <youpi> just use the thread gdb commands to access it + <gnu_srs> I do find two threads in gdb, yes. But following only the user + thread does not lead me to the cause of the problems. + <gnu_srs> And following the other (signal thread) has not been successful + so far. + <youpi> multithreading debugging in gdb is painful yes + <youpi> single-step isn't really an option in it + <antrik> gnu_srs: well, as I said before, the cause is probably not in the + libc code anyways. it would be much more relevant to find out what the FD + in question is, and what "special" thing Ruby does to it to trigger the + problematic behaviour... + <youpi> it's simpler to put printfs etc. + <antrik> youpi: well, printf doesn't work in the FD code :-) + <youpi> you can make it work + <youpi> open /dev/mem, write to 0xb8000 + <youpi> I'm not even joking + <gnu_srs> I have printfs in the ruby code. And at some parts in eglibc (but + it is not possible to put them at all places I want, as mentioned before) + <antrik> sure, there are ways to debug this code too... but I don't think + it's useful. so far there is no indication that this will help finding + the actual issue + <gnu_srs> The problem is not file descriptors. It is that an ongoing read + suddenly returns -1 bytes read. And then the ruby code assigns a negative + file descriptor in the exception handling. + <youpi> a *read* ? + <youpi> with errno == 0 ? + <gnu_srs> Yes, a read! + <youpi> how ruby comes to assigning a negative fd from that? + <youpi> does it somehow close the fd? + <gnu_srs> The errno reported from the read is EBADF! + <youpi> did you try to rpctrace it? + <gnu_srs> I don't bother too much about ruby exception handling. The error + has already happened in the read operation. And that lead me to eglibc + code.... and so on... + <youpi> do you know what kind of file this fd was supposed to be on? + <youpi> sure, that's debugging + <gnu_srs> Yes I did rpctrace, but that was not successful. rpctrace just + hang! Buggy code? + <antrik> youpi: I assume that's Ruby's way to indicate that the FD is not + valid anymore, after the previous error + <youpi> does the program fork? + <youpi> antrik: possibly + <youpi> rpctrace has known issues, yes + <youpi> gnu_srs: did you trace close()s by hand with printfs? + <gnu_srs> Ho w to find out if it forks? + <youpi> what does rpctrace stop on ? + <gnu_srs> Well, I don't remember. Antrik? + <antrik> proc_dostop() IIRC + <antrik> or something like that + <gnu_srs> I did not find any close() statements in the code I debugged. + <youpi> ok, proc_dostop() is typically a sign of fork() + <youpi> gnu_srs: that doesn't necessarily mean it's not called + <antrik> gnu_srs: I think his point is that something else might close the + FD, causing the error you see + <youpi> anything can happen in the wild :) + <antrik> gnu_srs: as I said before, the next step is to find out what this + FD is, and what happens to it... + <gnu_srs> antrik: Any ideas how to find out? + <youpi> what is the backtrace? + <gnu_srs> Well I know the fd number, it is either 3 or 5 in my tests. Does + the number matter? + <youpi> yes, it's not std{in,out,err} + <gnu_srs> How to get a backtrace of a program that does not hang? + <youpi> make it hang at the point of failure + <youpi> when read returns -1 + <youpi> so you know who did the read + <gnu_srs> I have to run the loop several times before the number of bytes + read is -1. + <youpi> you mean running the program several times ? + <youpi> or just let the loop continue for some time? + <pinotree> if it's the latter, you can add breakpoints with conditions + <gnu_srs> No the read loop runs for 7 iterations, and fails the 8th time! + <youpi> then make it hang when read() returns -1 + <Mr_Spock> could you paste your code somewhere? + <youpi> when debugging, you're allowed to do all kinds of ugly things, you + know ;) + <gnu_srs> OK, I'll try that. + <gnu_srs> MR_Spock: The easiest way would be to try to build + ruby1.9.1. Then I can help you from where it fails. + <gnu_srs> pinotree: How to give a breakpoint with a condition? + <pinotree> break where if condition + <youpi> see help break + <youpi> oh, there's even a thread condition nowadays, good + <gnu_srs> Thanks for the discussion. I have to get into the real world for + a while now. To be continued. + <antrik> gnu_srs: well, if you already know that the loop runs several + times before the error occurs, you apparently already looked at the + higher-level code that is relevant here... + <youpi> but it may be generic code, and not tell what calls it diff --git a/open_issues/system_call_mechanism.mdwn b/open_issues/system_call_mechanism.mdwn new file mode 100644 index 00000000..5598148c --- /dev/null +++ b/open_issues/system_call_mechanism.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2011 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, 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 diff --git a/unsorted/KnownHurdLimits.mdwn b/unsorted/KnownHurdLimits.mdwn index 51d66b50..4e7b7620 100644 --- a/unsorted/KnownHurdLimits.mdwn +++ b/unsorted/KnownHurdLimits.mdwn @@ -9,10 +9,6 @@ There are needed by OpenSSH. * In progress, see [[translator/random]] -* No DHCP client - * promising information [Jan 2005](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html), needs an update - * See [[DhcpClient]] - need to update TCP/IP server. - * Missing bits of POSIX * See [[Distrib/SystemAPILimits]] diff --git a/user/El_Dream_Machine.mdwn b/user/El_Dream_Machine.mdwn index ac3a0cfc..f6f03779 100644 --- a/user/El_Dream_Machine.mdwn +++ b/user/El_Dream_Machine.mdwn @@ -8,6 +8,9 @@ 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]]."]]"""]] +**May 19, 2011** - Very difficult to do my comic on the Hurd I encountered problems of inspiration... I missed the second page but I started again [http://art9libre.tuxfamily.org/gaetan-02.php](http://art9libre.tuxfamily.org/gaetan-02.php) +I project to share the scenario (CC-BY-SA/Licence Art Libre). + **January 13, 2011** - My story comics on the Hurd continues. I think I can introduce you to page 2 in a month. **January 11, 2011** - The goal was to install the Hurd in VirtualBox... |