From 6f9c0342f33f52a2bda98d3709fbefd678bd46d9 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 13 May 2012 06:06:11 +0200 Subject: IRC. --- hurd/console.mdwn | 111 ++++++++++++++++++++- hurd/translator/devfs.mdwn | 36 ++++++- hurd/translator/ext2fs.mdwn | 13 ++- .../ext2fs/hurd-specific_extensions.mdwn | 23 +++++ hurd/translator/ext2fs/page_cache.mdwn | 31 ++++++ hurd/translator/procfs/jkoenig/discussion.mdwn | 61 ++++++++++- 6 files changed, 265 insertions(+), 10 deletions(-) create mode 100644 hurd/translator/ext2fs/hurd-specific_extensions.mdwn create mode 100644 hurd/translator/ext2fs/page_cache.mdwn (limited to 'hurd') 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 + + is there any way to get copy/paste in hurd? + with the console server + like you get with gpm + Tekk_: by implementing it + Tekk_: that's something for the console client, not the server + (or perhaps both? not entirely sure) + antrik: I'm not entirely sure how the client works + does it start a new client with each tty? + or one client handles all of them? + the client only should be enough + it handles all input already anyway + the client handles all ttys + it just hops over them according to alt-Fx shortcuts + Tekk_: there is only one client for all, but a separate console + *server* for each tty + antrik: ah, the ever confusing X scheme + no + the client handles multiplexing and actual terminal I/O + the servers handle the state of the virtual terminals, and provide + the device nodes + this doesn't fit with the X scheme in any way + (where everything is basically in one big monolithic server + process) + antrik: I mean that you're running multiple servers and there's one + big client running on the other end + which always pretty well confuses everyone to start with + I totally fail to see the connection + there is usually one X server, with potentially many clients + nevermind + doesn't really matter to anything + so yeah, copy/paste would be in the client? + 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 ;-) + but there is really no relation at all here + antrik: exactly ;) + 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 + copy/paste probably isn't really too bad + applications are also clients of the terminal server processes; + but having a completely different role (and using completely different + requests) than the console client + 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 + 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 + nah, as long as you have a way of getting a highlighted area and + then the text contained in it + 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 + 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 + (the cursor position is relevant only for echo) + antrik: I'll try to grab the console source some time this week and + take a look + maybe I can try to get it working + good luck :-) + it's probably not too hard + I'm sure I'll need it :) + 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) + but for this specific task, not much knowlegde should be needed + about the various confusing aspects + hmm. looks like copy/paste won + 't be a quick thing, actually + wait, no. there must be a way to get mouse events + how else could you move the mouse.. + (with by moving your mouse, not cons_mouse_move) + by moving your mouse* + started typing something different + + +# Graphics/Higher Resolution + +## IRC, freenode #hurd, 2012-04-24 + + does the console support higher resolutions yet? + no + it's just textonly + Tekk_: the main reason why I originally started on the KGI work + was to get a graphical console... but I never finished that part + (since KGI is obsolete anyways) + 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 + 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... + well, not hardest I guess; but most problematic 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]] + 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 + + braunr: I don't think it's a problem that translators are invoked + when listing /dev + the problem is that they linger around although they are very + unlikely to be needed again any time soon + for now it's not too much a problem because there aren't too many + but that can become problematic + a devfs on /dev could also fill it with new devices + but only with the ones that actually exist + yeah + antrik: i mean, the hurd may lack a feature allowing the same + translator to be used for several nodes not hierarically related + antrik: or rather, it's a special case that we should implement + differently + (with e.g. a devfs that can route requests for different nodes to + a same translator + ) + 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) + right + braunr: actually, the Hurd *does* have a feature allowing the same + translator to be attached to several unrelated nodes + i keep getting surprised :) + though it's only used in very few places right now + pfinet and ptys at least ? + yeah, and console client IIRC + diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index fff2e74b..ad79c7b9 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -1,18 +1,23 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + # Implementation * [[filetype]] option + * [[Hurd-specific_extensions]] + + * [[Page_cache]] + ## Large Stores diff --git a/hurd/translator/ext2fs/hurd-specific_extensions.mdwn b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn new file mode 100644 index 00000000..774f1cf3 --- /dev/null +++ b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + + +# IRC, freenode, #hurd, 2012-04-20 + + what are the extensions to ext2? + that hurd uses + tha ability to store passive translator command lines in the + inodes + the* + well, also a fourth set of permission bits, and an "author" field + right + 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 + + is there any particular reason ext2fs takes so much memory? + it beats everything on my system hands down at 100 MB + ext2fs contains the page cache + so it's no wonder it takes memory + it's all the mapped files + any way I can cut down on that? + my system only has 512 meg :/ + gnumach is supposed to automatically cut it down as needed + what is the actual symptom that you see? + youpi: 360 MB of memory usage when I'm doing nothing + oh, is it just intelligent enough to cut down when I'm using more + memory? + Tekk_: yes + awesome. I was worried :) diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 339fab50..e7fdf46e 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -218,3 +219,61 @@ Needed by glibc's `pldd` tool (commit # `/proc/self/exe` [[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]] + + +# `/proc/[PID]/fd/` + +## IRC, freenode, #hurd, 2012-04-24 + + braunr: /proc/*/fd can be implemented in several ways. none of + them would require undue centralisation + braunr: the easiest would be adding one more type of magic lookup + to the existing magic lookup mechanism + wait, I mean /proc/self... for /proc/*/fd it's even more + straighforward -- we might even have a magic lookup for that already + i guess the ideal thing would be implement that fd logic in + libps + 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 + 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 :-) + youpi: How much info for /proc/*/fd is possible to get from + libps? Re: d-h@ + see my mail + I don't think there is an interface for that + processes handle fds themselves + so libps would have to peek in there + and I don't remember having seen any code like that + 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 + pinotree: For me that does not ring a bell on RPCs. Don't know + what magic means,, + for /proc/self/fd we have a magic lookup + for /proc/pid/fd, I don't think we have + magic lookup* + magic lookup == RPC? + magic lookup is a kind of answer to the lookup RPC + that basically says "it's somewhere else, see there" + the magic FD lookup tells the process "it's your FD number x" + which works for /proc/self/fd, but not /proc/pid/fd + youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that + could be used + `msgport' should have --get-fd, actually + civodul: I assumed that the reason why msgport doesn't have it is + that it didn't exist + so we can get a port on the fd + but then how to know what it is? + youpi: ah, you mean for the /proc/X/fd symlinks? + good question + it's not designed to be mapped back to names, indeed :-) + youpi: yeah, I realized myself that only /proc/self/fd is trivial + BTW, in Linux it's nor real symlinks. it's magic, with some very + strange (but useful in certain situations) semantics + not real symlinks + 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... -- cgit v1.2.3