summaryrefslogtreecommitdiff
path: root/hurd
diff options
context:
space:
mode:
Diffstat (limited to 'hurd')
-rw-r--r--hurd/console.mdwn111
-rw-r--r--hurd/dde/guide.mdwn4
-rw-r--r--hurd/running/debian/qemu_image.mdwn4
-rw-r--r--hurd/running/gnu/create_an_image.mdwn11
-rw-r--r--hurd/running/live_cd.mdwn4
-rw-r--r--hurd/running/qemu.mdwn9
-rw-r--r--hurd/running/qemu/babhurd_image.mdwn4
-rw-r--r--hurd/subhurd.mdwn2
-rw-r--r--hurd/translator/devfs.mdwn36
-rw-r--r--hurd/translator/ext2fs.mdwn13
-rw-r--r--hurd/translator/ext2fs/hurd-specific_extensions.mdwn23
-rw-r--r--hurd/translator/ext2fs/page_cache.mdwn31
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn61
13 files changed, 287 insertions, 26 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/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..ad79c7b9 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -1,18 +1,23 @@
-[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 Free Software
+Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
# Implementation
* [[filetype]] option
+ * [[Hurd-specific_extensions]]
+
+ * [[Page_cache]]
+
## Large Stores
diff --git a/hurd/translator/ext2fs/hurd-specific_extensions.mdwn b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn
new file mode 100644
index 00000000..774f1cf3
--- /dev/null
+++ b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn
@@ -0,0 +1,23 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+
+# IRC, freenode, #hurd, 2012-04-20
+
+ <Tekk_> what are the extensions to ext2?
+ <Tekk_> that hurd uses
+ <braunr> tha ability to store passive translator command lines in the
+ inodes
+ <braunr> the*
+ <antrik> well, also a fourth set of permission bits, and an "author" field
+ <braunr> right
+ <antrik> both very obscure features that better never existed...
diff --git a/hurd/translator/ext2fs/page_cache.mdwn b/hurd/translator/ext2fs/page_cache.mdwn
new file mode 100644
index 00000000..e8a964ed
--- /dev/null
+++ b/hurd/translator/ext2fs/page_cache.mdwn
@@ -0,0 +1,31 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+This is not at all specific to ext2fs, so should be integrated elsewhere.
+
+
+# IRC, freenode, #hurd, 2012-04-22
+
+ <Tekk_> is there any particular reason ext2fs takes so much memory?
+ <Tekk_> it beats everything on my system hands down at 100 MB
+ <youpi> ext2fs contains the page cache
+ <youpi> so it's no wonder it takes memory
+ <youpi> it's all the mapped files
+ <Tekk_> any way I can cut down on that?
+ <Tekk_> my system only has 512 meg :/
+ <youpi> gnumach is supposed to automatically cut it down as needed
+ <youpi> what is the actual symptom that you see?
+ <Tekk_> youpi: 360 MB of memory usage when I'm doing nothing
+ <Tekk_> oh, is it just intelligent enough to cut down when I'm using more
+ memory?
+ <youpi> Tekk_: yes
+ <Tekk_> awesome. I was worried :)
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index 339fab50..e7fdf46e 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
+Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -218,3 +219,61 @@ Needed by glibc's `pldd` tool (commit
# `/proc/self/exe`
[[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]]
+
+
+# `/proc/[PID]/fd/`
+
+## IRC, freenode, #hurd, 2012-04-24
+
+ <antrik> braunr: /proc/*/fd can be implemented in several ways. none of
+ them would require undue centralisation
+ <antrik> braunr: the easiest would be adding one more type of magic lookup
+ to the existing magic lookup mechanism
+ <antrik> wait, I mean /proc/self... for /proc/*/fd it's even more
+ straighforward -- we might even have a magic lookup for that already
+ <pinotree> i guess the ideal thing would be implement that fd logic in
+ libps
+ <antrik> pinotree: nope. it doesn't need to ask proc (or any other server)
+ at all. it's local information. that's what we have the magic lookups for
+ <antrik> one option we were considering at some point would be using the
+ object migration mechanism, so the actual handling would still happen
+ client-side, but the server could supply the code doing it. this would
+ allow servers to add arbitrary magic lookup methods without any global
+ modifications... but has other downsides :-)
+ <gnu_srs> youpi: How much info for /proc/*/fd is possible to get from
+ libps? Re: d-h@
+ <youpi> see my mail
+ <youpi> I don't think there is an interface for that
+ <youpi> processes handle fds themselves
+ <youpi> so libps would have to peek in there
+ <youpi> and I don't remember having seen any code like that
+ <gnu_srs> 10:17:17< antrik> wait, I mean /proc/self... for /proc/*/fd it's
+ even more straighforward -- we might even have a magic lookup for that
+ already
+ <gnu_srs> pinotree: For me that does not ring a bell on RPCs. Don't know
+ what magic means,,
+ <youpi> for /proc/self/fd we have a magic lookup
+ <youpi> for /proc/pid/fd, I don't think we have
+ <gnu_srs> magic lookup*
+ <gnu_srs> magic lookup == RPC?
+ <youpi> magic lookup is a kind of answer to the lookup RPC
+ <youpi> that basically says "it's somewhere else, see there"
+ <youpi> the magic FD lookup tells the process "it's your FD number x"
+ <youpi> which works for /proc/self/fd, but not /proc/pid/fd
+ <civodul> youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that
+ could be used
+ <civodul> `msgport' should have --get-fd, actually
+ <youpi> civodul: I assumed that the reason why msgport doesn't have it is
+ that it didn't exist
+ <youpi> so we can get a port on the fd
+ <youpi> but then how to know what it is?
+ <civodul> youpi: ah, you mean for the /proc/X/fd symlinks?
+ <civodul> good question
+ <civodul> it's not designed to be mapped back to names, indeed :-)
+ <antrik> youpi: yeah, I realized myself that only /proc/self/fd is trivial
+ <antrik> BTW, in Linux it's nor real symlinks. it's magic, with some very
+ strange (but useful in certain situations) semantics
+ <antrik> not real symlinks
+ <antrik> it's very weird for example for fd connected to files that have
+ been unlinked. it looks like a broken symlink, but when dereferencing
+ (e.g. with cp), you get the actual file contents...
generated by cgit v1.2.3 (git 2.46.0) at 2025-03-04 10:29:01 +0000