diff options
Diffstat (limited to 'hurd')
-rw-r--r-- | hurd/console.mdwn | 111 | ||||
-rw-r--r-- | hurd/dde/guide.mdwn | 4 | ||||
-rw-r--r-- | hurd/debugging/rpctrace.mdwn | 80 | ||||
-rw-r--r-- | hurd/running/debian/qemu_image.mdwn | 4 | ||||
-rw-r--r-- | hurd/running/gnu/create_an_image.mdwn | 11 | ||||
-rw-r--r-- | hurd/running/live_cd.mdwn | 4 | ||||
-rw-r--r-- | hurd/running/qemu.mdwn | 9 | ||||
-rw-r--r-- | hurd/running/qemu/babhurd_image.mdwn | 4 | ||||
-rw-r--r-- | hurd/subhurd.mdwn | 2 | ||||
-rw-r--r-- | hurd/translator/devfs.mdwn | 36 | ||||
-rw-r--r-- | hurd/translator/ext2fs.mdwn | 57 | ||||
-rw-r--r-- | hurd/translator/ext2fs/hurd-specific_extensions.mdwn | 23 | ||||
-rw-r--r-- | hurd/translator/ext2fs/page_cache.mdwn | 31 | ||||
-rw-r--r-- | hurd/translator/procfs/jkoenig/discussion.mdwn | 114 |
14 files changed, 461 insertions, 29 deletions
diff --git a/hurd/console.mdwn b/hurd/console.mdwn index f7230011..55581870 100644 --- a/hurd/console.mdwn +++ b/hurd/console.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2011 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2011, +2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -9,6 +9,11 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] +[[!toc]] + + +# Architecture: client and server + The Hurd console's implementation is broken into two pieces each running on it's own process, the console client and server. @@ -79,9 +84,9 @@ blocking operations and a blocked `input_dequeue` necessarily needs an `ports_manage_multithreaded` API. ---- +# Old stuff -/!\ old content; [[!taglink open_issue_documentation]]: cleanup needed. +[[!taglink open_issue_documentation]]: cleanup needed. The below is a reworked version of Marcus Brinkmann's [letter to the debian-hurd list](http://lists.debian.org/debian-hurd/2002/debian-hurd-200209/msg00054.html). It describes how to setup the new console server for the Hurd. I am testing this right now, so this document is a work in progress. @@ -357,3 +362,101 @@ An [experimental plugin to load XKB keymaps](http://kilobug.free.fr/hurd/xkb-0.3 Added examples that use repeaters needed by X. -- [[Main/OgnyanKulev]] - 18 Sep 2004 + + +# IRC, freenode #hurd, 2012-04-23 + + <Tekk_> is there any way to get copy/paste in hurd? + <Tekk_> with the console server + <Tekk_> like you get with gpm + <youpi> Tekk_: by implementing it + <antrik> Tekk_: that's something for the console client, not the server + <antrik> (or perhaps both? not entirely sure) + <Tekk_> antrik: I'm not entirely sure how the client works + <Tekk_> does it start a new client with each tty? + <Tekk_> or one client handles all of them? + <youpi> the client only should be enough + <youpi> it handles all input already anyway + <youpi> the client handles all ttys + <youpi> it just hops over them according to alt-Fx shortcuts + <antrik> Tekk_: there is only one client for all, but a separate console + *server* for each tty + <Tekk_> antrik: ah, the ever confusing X scheme + <antrik> no + <antrik> the client handles multiplexing and actual terminal I/O + <antrik> the servers handle the state of the virtual terminals, and provide + the device nodes + <antrik> this doesn't fit with the X scheme in any way + <antrik> (where everything is basically in one big monolithic server + process) + <Tekk_> antrik: I mean that you're running multiple servers and there's one + big client running on the other end + <Tekk_> which always pretty well confuses everyone to start with + <antrik> I totally fail to see the connection + <antrik> there is usually one X server, with potentially many clients + <Tekk_> nevermind + <Tekk_> doesn't really matter to anything + <Tekk_> so yeah, copy/paste would be in the client? + <antrik> unless you mean a termial server, running actual client programs, + connected to various terminals, running X servers... which is where it + gets confusing in a way ;-) + <antrik> but there is really no relation at all here + <Tekk_> antrik: exactly ;) + <Tekk_> I meant in the traditional sense, where you're on a thin client + running an X server and the remote server is running X clients + <Tekk_> copy/paste probably isn't really too bad + <antrik> applications are also clients of the terminal server processes; + but having a completely different role (and using completely different + requests) than the console client + <Tekk_> you have a buffer, when something is highlighted you strncpy the + highlighted text into the buffer. when middle click happens you send the + text to the right virtual terminal + <antrik> right. what I was considering is whether the pasting (and possibly + also grabbing) the text might be done through some separate protocol + implemented in the console server, rather than the ordinary console + client interfaces... but probably no need for that + <Tekk_> nah, as long as you have a way of getting a highlighted area and + then the text contained in it + <Tekk_> and then of course a way to insert text where the cursor is, but + I'm pretty sure you can safely assume that one :P + <antrik> well, the client has a way to send keystrokes to the server, + obviously. the question here is whether pretending the pasting is + keystrokes is good enough, or whether it might be useful to have an + explicit way to push the pasted stuff to the server + <antrik> (the cursor position is relevant only for echo) + <Tekk_> antrik: I'll try to grab the console source some time this week and + take a look + <Tekk_> maybe I can try to get it working + <antrik> good luck :-) + <antrik> it's probably not too hard + <Tekk_> I'm sure I'll need it :) + <antrik> the whole console machinery is quite hard to grasp (and I still + find myself confused sometimes, although I gained a pretty good + understanding I think when writing my thesis) + <antrik> but for this specific task, not much knowlegde should be needed + about the various confusing aspects + <Tekk_> hmm. looks like copy/paste won + <Tekk_> 't be a quick thing, actually + <Tekk_> wait, no. there must be a way to get mouse events + <Tekk_> how else could you move the mouse.. + <Tekk_> (with by moving your mouse, not cons_mouse_move) + <Tekk_> by moving your mouse* + <Tekk_> started typing something different + + +# Graphics/Higher Resolution + +## IRC, freenode #hurd, 2012-04-24 + + <Tekk_> does the console support higher resolutions yet? + <youpi> no + <youpi> it's just textonly + <antrik> Tekk_: the main reason why I originally started on the KGI work + was to get a graphical console... but I never finished that part + <antrik> (since KGI is obsolete anyways) + <antrik> BTW, there is a KMS-based userspace console now for Linux... I + guess it should be easy to adapt to other systems having KMS support + <antrik> I don't think it actually makes much sense for Linux, as it's one + of the hardest and least profitable things to move out of a monolithic + kernel... + <antrik> well, not hardest I guess; but most problematic diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index bf41dd79..132b36ae 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -14,6 +14,10 @@ with Debian GNU/Hurd, if your (wired) network card is not supported by the old in-kernel drivers shipped with gnumach. +NOTE: As of hurd package 20120520-1, all that is already done for you, do *not* +do anything mentioned below, and you just need to configure your TCP/IP stack by +using settrans on /servers/socket/2, or dhclient /dev/eth0. + This guide assumes that you have an installation of Debian GNU/Linux on the same machine, which helps in fetching the required packages diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index fd24f081..df6290f7 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011 Free Software +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -89,6 +89,84 @@ See `rpctrace --help` about how to use it. <pinotree> braunr: the output of rpctrace --help should tell the default dir for msgids +* IRC, freenode, #hurd, 2012-06-30 + + <mcsim> hello. Has anyone faced with problem when translator works + fine, but when it is started via rpctrace it hangs? Probably you know + what can cause this? + <antrik> mcsim: rpctrace itself is quite buggy + <antrik> zhengda once did a number of improvements, but they never went + upstream... + <youpi> well, he never explained how his fixes worked :) + <youpi> GNU/Hurd is no different from other projects in that regard: if + you don't explain how your patches work, there's low chance that they + are applied + <youpi> unless the maintainer has time to dive himself, which we don't + <pinotree> "it compiles, ship it!" + <braunr> pinotree: i guess the hurd is different in that particular + regard :p + <youpi> not different from linux + <braunr> eh, they include staging drivers now :) + <youpi> we have a sort-of staging tree as well, with netdde + <youpi> we don't really care about stability there + <antrik> youpi: actually, I think by now (and not to a small part + because of this episode) that we are too strict about patch + submission + <youpi> well, review really is needed, otherwise source gets into a bad + shape + <antrik> while zhengda's variant might not have been ideal (nobody of + us understands the workings of rpctrace enough to tell), I have + little doubt that it would be an improvement... + <youpi> it happened quite a few times that a fix revealed to be + actually bogus + <youpi> in that particular case, I agree + <youpi> the problem is that usually what happens is that questions are + asked + <youpi> and the answers never happen + <youpi> and thus the patch gets lost + <antrik> after all, when he when he submitted that patch, he had a much + better understanding of rpctrace than any of us... + <youpi> sure + <antrik> Linus is actually quite pragmatic about that. from what I've + seen, if he can be convinced that something is *probably* an + improvement over the previous status, he will usually merge it, even + if he has some qualms + <youpi> when there is a maintainer, he usually requires his approval, + doesn't he? + <antrik> in particular, for code that is new or has been in a very bad + shape before, standards shouldn't be as high as for changes to known + good code. and quite frankly, large parts of the Hurd code base + aren't all that good to begin with... + <youpi> sure + <antrik> well, sure. in this case, we should have just appointed + zhengda to be the rpctrace maintainer :-) + <antrik> BTW, as his version is quite fundamentally different, perhaps + instead of merging the very large patch, perhaps we should just ship + both versions, and perhaps drop the old one at some point if the new + one turns out to work well... + <antrik> (and perhaps I overused the word perhaps in that sentence + perhaps ;-) ) + <youpi> about that particular patch, you had needed raised a few bits + <youpi> and there was no answers + <youpi> the patch is still in my mbox, far away + <youpi> so it was *not* technically lost + <youpi> it's just that as usual we lack manpower + <antrik> yeah, I know. but many of the things I raised were mostly + formalisms, which might be helpful for maintaining high-quality code, + but probably were just a waste of time and effort in this case... I'm + not surprised that zhengda lost motivation to pursue this further :-( + <braunr> it would help a lot to get the ton of patches in the debian + packages upstream :) + <youpi> braunr: there aren't many, and usually for a good reason + <youpi> some of them are in debian for testing, and can probably be + commited at some point + <pinotree> youpi: we could mark (with dep3 headers) the ones which are + meant to be debian-specific + <youpi> sure + <antrik> well, there are also a few patches that are not exactly + Debian-specific, but not ready for upstream either... + <youpi> antrik: yes + # See Also diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn index 809bf7b1..19b371c1 100644 --- a/hurd/running/debian/qemu_image.mdwn +++ b/hurd/running/debian/qemu_image.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -15,7 +15,7 @@ Usage: $ wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz $ tar -xz < debian-hurd.img.tar.gz - $ qemu -net nic,model=rtl8139 -net user -hda debian-hurd-*.img + $ qemu -m 512 -net nic,model=rtl8139 -net user -hda debian-hurd-*.img Just in case you were wondering: the *root* password is *root*. diff --git a/hurd/running/gnu/create_an_image.mdwn b/hurd/running/gnu/create_an_image.mdwn index c7a97a4e..8784a826 100644 --- a/hurd/running/gnu/create_an_image.mdwn +++ b/hurd/running/gnu/create_an_image.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Creating a bootable qemu image from a root filesystem and bootloader @@ -17,7 +18,7 @@ Creating a bootable qemu image from a root filesystem and bootloader 2. Use a live CD (better to have a lighter OS like system rescue CD to make the process faster) and the image created to boot. - qemu -cdrom /dev/cdrom -hda <imagename.img> -boot d + qemu -m 512 -cdrom /dev/cdrom -hda <imagename.img> -boot d 3. Once system is booted use a partition editing tool (like fdisk, cfdisk, parted, gparted, qtparted ...) to partition the image. @@ -64,7 +65,7 @@ Creating a bootable qemu image from a root filesystem and bootloader 11. Run qemu to boot into your brand new system - qemu -hda <hard disk image.img> -fda grub.img -boot a + qemu -m 512 -hda <hard disk image.img> -fda grub.img -boot a Happy Hacking !! diff --git a/hurd/running/live_cd.mdwn b/hurd/running/live_cd.mdwn index c9360594..1eb9b8e0 100644 --- a/hurd/running/live_cd.mdwn +++ b/hurd/running/live_cd.mdwn @@ -8,7 +8,7 @@ MiB: <http://www.superunprivileged.org/hurd/tiny-cd/> Use it like this: - $ qemu -cdrom hurd-tiny-cd-20060722.iso + $ qemu -m 512 -cdrom hurd-tiny-cd-20060722.iso A more recent Live CD can be found at <http://teythoon.cryptobitch.de/hurd/livecd/hurd-live-install-1273300101.iso.xz>. @@ -16,7 +16,7 @@ It can be run with qemu via $ wget http://teythoon.cryptobitch.de/hurd/livecd/hurd-live-install-1273300101.iso.xz $ xz -d hurd-live-install-1273300101.iso.xz - $ qemu -cdrom hurd-live-install-1273300101.iso + $ qemu -m 512 -cdrom hurd-live-install-1273300101.iso These [[!wikipedia LiveCD]]s should be useful for those who want to try out the Hurd before they commit to installing it on their hard disks. In addition to diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index fcf58d8a..b64c576f 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -28,7 +28,8 @@ Note that the following images are unofficial ones: they have been prepared by volunteers and may not have been tested extensively. * [Disk image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) - with a short intro on translators. Just start it with 'qemu *disk_image.img*'. + with a short intro on translators. Just start it with `qemu -m 512 + disk_image.img`. It should work without any of the configuration below. If you want to know what you can do with it, please have a look at [[its_wikipage|hurd/running/qemu/babhurd_image]]. And when you use it, please [tell me your experience with it](http://draketo.de/contact)! - [[community/weblogs/ArneBab]] @@ -272,7 +273,7 @@ This is the recommended way to work with a Command Line Interface (CLI) since al a) with ssh (assuming you have installed openssh-server) - $ kvm -m 1024 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img & + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img & Logging in to the running Hurd: @@ -289,7 +290,7 @@ Copying files: b) with telnet (assuming you have installed a telnet server, like telnetd) - $ kvm -m 1024 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -hda hurd-install.qemu & + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -hda hurd-install.qemu & Logging in to the running Hurd: @@ -330,7 +331,7 @@ Now it is time to start-up your QEMU Hurd system and get networking going in the **Important:** Remember you may need to use the `-M isapc` or `-isa` flag if using an older version of the gnumach package. - $ qemu -hda hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap + $ qemu -m 512 -hda hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap Once you have logged in as `root` run the `pfinet` translator with values that apply to your network. Think of your QEMU client as another computer in your network. diff --git a/hurd/running/qemu/babhurd_image.mdwn b/hurd/running/qemu/babhurd_image.mdwn index c0952fcf..855e8f51 100644 --- a/hurd/running/qemu/babhurd_image.mdwn +++ b/hurd/running/qemu/babhurd_image.mdwn @@ -5,8 +5,8 @@ What this little Hurd image can do This is the README file accompanying a [disk\_image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) for -[[running_the_GNU/Hurd_via_qemu|hurd/running/qemu]]. To run the disk image, just use *'qemu -disk_image.img'*. +[[running the GNU/Hurd via qemu|hurd/running/qemu]]. To run the disk image, +just use `qemu -m 512 disk_image.img`. You can find the custom *.bashrc* used to tell the user about it as well as this text itself in the Mercurial repository [hurd_intro](http://bitbucket.org/ArneBab/hurd_intro). diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index b8e595d3..f2117ead 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -31,7 +31,7 @@ flexible.) Vice versa, it is also possible to use a subhurd to debug the To run a subhurd, you need an additional partition with an installed Hurd system. In principle, you can also use your main partition in read-only mode; but this obviously will create severe limitations. Usually, you will want a -complete independant system. +complete independent system. The system for the subhurd is a normal Hurd installation, which could just as well run standalone. You can use any of the various possible installation diff --git a/hurd/translator/devfs.mdwn b/hurd/translator/devfs.mdwn index 8784e998..a9cc307f 100644 --- a/hurd/translator/devfs.mdwn +++ b/hurd/translator/devfs.mdwn @@ -12,7 +12,7 @@ License|/fdl]]."]]"""]] in there in a dynamic fashion -- as compared to static passive translator settings as they're used now. -`devfs` has not yet been written. +`devfs` has not yet been written. [[!tag open_issue_hurd]] --- @@ -23,6 +23,8 @@ path is resident at all times. # IRC, freenode, #hurd, 2012-01-29 +[[!tag open_issue_documentation]] + <pinotree> what would be an hurdish way to achieve something like the various system (udev, devfs, devd, etc) for populating devices files automatically according to the found system devices? @@ -37,3 +39,35 @@ path is resident at all times. /dev directory with unique device names... probably need some unionfs-like translator that collects the individual driver nodes in an intelligent manner + + +# IRC, freenode, #hurd, 2012-04-22 + + <antrik> braunr: I don't think it's a problem that translators are invoked + when listing /dev + <antrik> the problem is that they linger around although they are very + unlikely to be needed again any time soon + <youpi> for now it's not too much a problem because there aren't too many + <youpi> but that can become problematic + <pinotree> a devfs on /dev could also fill it with new devices + <youpi> but only with the ones that actually exist + <pinotree> yeah + <braunr> antrik: i mean, the hurd may lack a feature allowing the same + translator to be used for several nodes not hierarically related + <braunr> antrik: or rather, it's a special case that we should implement + differently + <braunr> (with e.g. a devfs that can route requests for different nodes to + a same translator + <braunr> ) + <antrik> I agree BTW that some intermediary for /dev would be helpful -- + but I don't think it should actually take over any RPC handling; rather, + only redirect the requests as appropriate (with the actual device nodes + in a hierarchical bus-centric layout) + <braunr> right + <antrik> braunr: actually, the Hurd *does* have a feature allowing the same + translator to be attached to several unrelated nodes + <braunr> i keep getting surprised :) + <antrik> though it's only used in very few places right now + <youpi> pfinet and ptys at least ? + <antrik> yeah, and console client IIRC + diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index fff2e74b..8e15d1c7 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -1,18 +1,25 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + # Implementation * [[filetype]] option + * [[Hurd-specific_extensions]] + + * [[Page_cache]] + + * [[metadata_caching]] + ## Large Stores @@ -38,6 +45,48 @@ Smaller block sizes are commonly automatically selected by `mke2fs` when using small backend stores, like floppy devices. +#### IRC, freenode, #hurd, 2012-06-30 + + <braunr> at least having the same api in the debian package and the git + source would be great (in reference to the large store patch ofc) + <youpi> braunr: the api part could be merged perhaps + <youpi> it's very small apparently + <antrik> braunr: the large store patch is a sad story. when it was first + submitted, one of the maintainers raised some concerns. the other didn't + share these (don't remember who is who), but the concerned one never + followed up with details. so it has been in limbo ever since. tschwinge + once promised to take it up, but didn't get around to it so far. plus, + the original author himself mentioned once that he didn't consider it + finished... + <youpi> antrik: it's clearly not finished + <youpi> there are XXXs here and there + <braunr> it's called an RC1 and RC2 is mentioned in the release notes + <antrik> youpi: well, that doesn't stop most other projects from commiting + stuff... including most emphatically the original Hurd code :-) + <youpi> what do you refer to my "that" ? :) + <braunr> "XXX" + <youpi> right + <youpi> at the time it made sense to delay applying + <youpi> but I guess by nowadays standard we should just as well commit it + <youpi> it works enough for Debian, already + <youpi> there is just one bug I nkow about + <youpi> the apt database file keeps haveing the wrong size, fixed by e2fsck + <pinotree> youpi: remember that patch should be fixed in the offset + declaration in diskfs.h + <youpi> I don't remember about that + <youpi> did we fix it in the debian package? + <pinotree> nope + <youpi> you had issues when fixing it, didn't you? + <youpi> (I don't remember where I can find the details about this) + <pinotree> i changed it, recompiled hurd and installed it, started a perl + rebuild and when running one of the two lfs tests it hard locked the vm + after ext2fs was taking 100% cpu for a bit + <pinotree> i don't exclude i could have done something stupid on my side + though + <youpi> or there could just be actual issues, uncovered here + <youpi> which can be quite probable + + # Documentation * <http://e2fsprogs.sourceforge.net/ext2.html> diff --git a/hurd/translator/ext2fs/hurd-specific_extensions.mdwn b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn new file mode 100644 index 00000000..774f1cf3 --- /dev/null +++ b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + + +# IRC, freenode, #hurd, 2012-04-20 + + <Tekk_> what are the extensions to ext2? + <Tekk_> that hurd uses + <braunr> tha ability to store passive translator command lines in the + inodes + <braunr> the* + <antrik> well, also a fourth set of permission bits, and an "author" field + <braunr> right + <antrik> both very obscure features that better never existed... diff --git a/hurd/translator/ext2fs/page_cache.mdwn b/hurd/translator/ext2fs/page_cache.mdwn new file mode 100644 index 00000000..e8a964ed --- /dev/null +++ b/hurd/translator/ext2fs/page_cache.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +This is not at all specific to ext2fs, so should be integrated elsewhere. + + +# IRC, freenode, #hurd, 2012-04-22 + + <Tekk_> is there any particular reason ext2fs takes so much memory? + <Tekk_> it beats everything on my system hands down at 100 MB + <youpi> ext2fs contains the page cache + <youpi> so it's no wonder it takes memory + <youpi> it's all the mapped files + <Tekk_> any way I can cut down on that? + <Tekk_> my system only has 512 meg :/ + <youpi> gnumach is supposed to automatically cut it down as needed + <youpi> what is the actual symptom that you see? + <Tekk_> youpi: 360 MB of memory usage when I'm doing nothing + <Tekk_> oh, is it just intelligent enough to cut down when I'm using more + memory? + <youpi> Tekk_: yes + <Tekk_> awesome. I was worried :) diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 339fab50..182b438b 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -67,7 +68,7 @@ IRC, #hurd, around October 2010 owner, but always with root group -# `/proc/$pid/stat` being 400 and not 444, and some more +# `/proc/[PID]/stat` being 400 and not 444, and some more IRC, freenode, #hurd, 2011-03-27 @@ -186,7 +187,7 @@ IRC, freenode, #hurd, 2011-07-22 server anyway, I think. -# `/proc/mounts`, `/proc/$pid/mounts` +# `/proc/mounts`, `/proc/[PID]/mounts` IRC, freenode, #hurd, 2011-07-25 @@ -218,3 +219,110 @@ Needed by glibc's `pldd` tool (commit # `/proc/self/exe` [[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]] + + +# `/proc/[PID]/fd/` + +## IRC, freenode, #hurd, 2012-04-24 + + <antrik> braunr: /proc/*/fd can be implemented in several ways. none of + them would require undue centralisation + <antrik> braunr: the easiest would be adding one more type of magic lookup + to the existing magic lookup mechanism + <antrik> wait, I mean /proc/self... for /proc/*/fd it's even more + straighforward -- we might even have a magic lookup for that already + <pinotree> i guess the ideal thing would be implement that fd logic in + libps + <antrik> pinotree: nope. it doesn't need to ask proc (or any other server) + at all. it's local information. that's what we have the magic lookups for + <antrik> one option we were considering at some point would be using the + object migration mechanism, so the actual handling would still happen + client-side, but the server could supply the code doing it. this would + allow servers to add arbitrary magic lookup methods without any global + modifications... but has other downsides :-) + <gnu_srs> youpi: How much info for /proc/*/fd is possible to get from + libps? Re: d-h@ + <youpi> see my mail + <youpi> I don't think there is an interface for that + <youpi> processes handle fds themselves + <youpi> so libps would have to peek in there + <youpi> and I don't remember having seen any code like that + <gnu_srs> 10:17:17< antrik> wait, I mean /proc/self... for /proc/*/fd it's + even more straighforward -- we might even have a magic lookup for that + already + <gnu_srs> pinotree: For me that does not ring a bell on RPCs. Don't know + what magic means,, + <youpi> for /proc/self/fd we have a magic lookup + <youpi> for /proc/pid/fd, I don't think we have + <gnu_srs> magic lookup* + <gnu_srs> magic lookup == RPC? + <youpi> magic lookup is a kind of answer to the lookup RPC + <youpi> that basically says "it's somewhere else, see there" + <youpi> the magic FD lookup tells the process "it's your FD number x" + <youpi> which works for /proc/self/fd, but not /proc/pid/fd + <civodul> youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that + could be used + <civodul> `msgport' should have --get-fd, actually + <youpi> civodul: I assumed that the reason why msgport doesn't have it is + that it didn't exist + <youpi> so we can get a port on the fd + <youpi> but then how to know what it is? + <civodul> youpi: ah, you mean for the /proc/X/fd symlinks? + <civodul> good question + <civodul> it's not designed to be mapped back to names, indeed :-) + <antrik> youpi: yeah, I realized myself that only /proc/self/fd is trivial + <antrik> BTW, in Linux it's nor real symlinks. it's magic, with some very + strange (but useful in certain situations) semantics + <antrik> not real symlinks + <antrik> it's very weird for example for fd connected to files that have + been unlinked. it looks like a broken symlink, but when dereferencing + (e.g. with cp), you get the actual file contents... + + +# `/proc/[PID]/maps` + +## IRC, OFTC, #debian-hurd, 2012-06-20 + + <pinotree> bdefreese: the two elfutils tests fail because there are no + /proc/$pid/maps files + <pinotree> that code is quite relying on linux features, like locating the + linux kernel executables and their modules, etc + <pinotree> (see eg libdwfl/linux-kernel-modules.c) + <pinotree> refactor elfutils to have the linux parts executed only on linux + :D + <bdefreese> Oh yeah, the maintainer already seems really thrilled about + Hurd.. Did you see + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041 ? + <pinotree> kurt is generally helpful with us (= hurd) + <pinotree> most probably there he is complaining that we let elfutils build + with nocheck (ie skipping the test suite run) instead of investigate and + report why the test suite failed + + +# IRC, freenode, #hurd, 2011-06-19 + + <pinotree> jkoenig: procfs question: in process.c, process_lookup_pid, why + is the entries[2].hook line repeated twice? + <jkoenig> pinotree, let me check + <jkoenig> pinotree, it's probably just a mistake, there's no way the second + one has any effect + <pinotree> jkoenig: i see, it looked like you c&p'd that code accidentally + <jkoenig> pinotree, it's probably what happened, yes. + + +# IRC, freenode, #hurd, 2012-06-30 + + <pinotree> btw, what do you think about making jkoening's procfs master the + real master? + <youpi> probably a good idea + <youpi> it does work quite well, except a few pidof hangs + <pinotree> surely better than the old one :) + <youpi> yes :) + + +# `/proc/[PID]/cwd` + +## IRC, freenode, #hurd, 2012-06-30 + + * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying + on "internal" (but exported) glibc functions |