summaryrefslogtreecommitdiff
path: root/hurd
diff options
context:
space:
mode:
Diffstat (limited to 'hurd')
-rw-r--r--hurd/debugging/rpctrace.mdwn39
-rw-r--r--hurd/libstore.mdwn37
-rw-r--r--hurd/libstore/part.mdwn133
-rw-r--r--hurd/running/debian/dhcp.mdwn97
-rw-r--r--hurd/subhurd.mdwn376
-rw-r--r--hurd/translator.mdwn5
-rw-r--r--hurd/translator/eth-filter.mdwn26
-rw-r--r--hurd/translator/examples.mdwn8
-rw-r--r--hurd/translator/exec.mdwn8
-rw-r--r--hurd/translator/ext2fs.mdwn63
-rw-r--r--hurd/translator/fifo.mdwn48
-rw-r--r--hurd/translator/hostmux.mdwn15
-rw-r--r--hurd/translator/httpfs.mdwn100
-rw-r--r--hurd/translator/nsmux.mdwn27
-rw-r--r--hurd/translator/pfinet.mdwn9
-rw-r--r--hurd/translator/pfinet/implementation.mdwn164
-rw-r--r--hurd/translator/pflocal.mdwn28
-rw-r--r--hurd/translator/proc.mdwn22
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn10
-rw-r--r--hurd/translator/ufs.mdwn38
20 files changed, 1229 insertions, 24 deletions
diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index 1570df4c..d62a4387 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -16,6 +16,17 @@ doing.
See `rpctrace --help` about how to use it.
+# IRC, freenode, #hurd, 2013-07-29
+
+ <teythoon> about rpctrace, it poses as the kernel for its children, parses
+ and relays any messages sent over the childrens message port, right?
+ <braunr> teythoon: rpctrace doesn't "poses as the kernel"
+ <braunr> well, it's close enough
+ <teythoon> but it intercepts messages send by its children by handing them
+ a message port different from the one provided by the kernel, doesn't it?
+ <braunr> yes
+
+
# Issues and Patches
[[!tag open_issue_hurd]]
@@ -186,6 +197,34 @@ See `rpctrace --help` about how to use it.
<pinotree> wish: make rpctrace decode the results of io_stat rpcs
+* IRC, freenode, #hurd, 2013-07-29
+
+ <teythoon> imho rpctrace is kind of a mess right now :-/ we should move the
+ parsing code to a library
+ <teythoon> that would also be useful for valgrind, it should have to do
+ basically the same
+
+* IRC, freenode, #hurd, 2013-07-29
+
+ <teythoon> and I tried to rpctrace a subhurd, but rpctrace died on a
+ assertion failure, some msg had an unexpected type or something
+ <braunr> rpctrace dies on select
+ <braunr> and guess what, the boot tool does call select on the console it
+ emulates
+ <teythoon> that's a shame, that'd be really useful for me
+ <braunr> it might not be hard to fix
+ <braunr> but i've never looked into it :/
+ <braunr> i only saw that rpctrace expects the common RPC message types
+ <braunr> and select is all but a common RPC
+ <braunr> so the type of the messages involved is slightly different
+ <braunr> and the assertion chokes on that
+ <teythoon> rpctrace.c is huge and hand written, it'd be nice if the parser
+ was created from the procedure definitions
+ <teythoon> and thinking of that, mig does exactly that, one would only need
+ some glue code
+ <braunr> select is partially hand written
+ <braunr> but it's a special case so that's ok
+
# See Also
diff --git a/hurd/libstore.mdwn b/hurd/libstore.mdwn
index 8eac39fe..b2e7f7a9 100644
--- a/hurd/libstore.mdwn
+++ b/hurd/libstore.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2013 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]]."]]"""]]
`libstore` is used to provide a generic interface to access data (read/write)
on backing stores.
@@ -15,6 +15,8 @@ on backing stores.
It more than just a thin layer between [[GNU Mach|microkernel/mach/gnumach]]
devices (`hd0` for example) and the device node below `/dev/`...
+[[!toc]]
+
# Available Stores
@@ -34,3 +36,32 @@ can be found.
pages="hurd/libstore/examples/* and !*/discussion"
show=0
feeds=no]]
+
+
+# Open Issues
+
+## IRC, freenode, #hurd, 2013-07-29
+
+[[!tag open_issue_documentation open_issue_hurd]]
+
+ <teythoon> and I read hammys paper about mobile code, is it true that the
+ store code is loaded into the client? who is the server and who is the
+ client in this context?
+ <braunr> teythoon: "store code" ?
+ <teythoon> libstore
+ <braunr> the hurd libstore ?
+ <teythoon> yes
+ <braunr> hum, what paper ?
+ <teythoon> braunr:
+ http://users.student.lth.se/cs07fh9/2009-hammar-hurd-mobility.pdf
+ <braunr> how nice
+ <tschwinge> braunr: http://www.gnu.org/software/hurd/news/2010-01-31.html
+ <teythoon> it raises an important point btw, the authentication done by
+ processes on the Hurd is one sided, only the client authenticates at the
+ server
+ <braunr> yes
+ <tschwinge> It'S also mentioned in
+ http://www.gnu.org/software/hurd/hurd/documentation.html -- but of
+ course, any results he got from his work really should be integrated more
+ properly into the existing body of documents.
+ <tschwinge> As with so many other documents/discussions/etc. ;-|
diff --git a/hurd/libstore/part.mdwn b/hurd/libstore/part.mdwn
index 5260d05d..29ef9072 100644
--- a/hurd/libstore/part.mdwn
+++ b/hurd/libstore/part.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2012, 2013 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
@@ -28,6 +29,132 @@ A similar problem is described in
[[community/gsoc/project_ideas/unionfs_boot]], and needs to be implemented.
-# TODO
+# Open Issues
-How to use, etc.
+## Documentation
+
+[[!tag open_issue_documentation]]
+
+## [[open_issues/hurd_build_without_parted]]
+
+## IRC, freenode, #hurd. 2013-09-21
+
+ <phcoder> Hello, guys. Is there a way to know where partition starts on
+ hurd. E.g. given hd0s1 get "2048 sectors"
+ <youpi> yes, it's the storeinfo RPC
+ <youpi> let me find you a pointer
+ <phcoder> in GRUB 2 files for determining device relations are a mess of
+ #if's. I try to split it into logical files and make common logic
+ uniform. Current Hurd's logic is completely different and, actually,
+ wrong. Same logic is used by Mac OS X part ...
+ <youpi> phcoder: Mmm, I guess you never got the userland-part.patch
+ upstream
+ <youpi> ah, yes ,you did
+ <youpi> I mean the find_hurd_root_device function
+ <youpi> grub was previously using file_get_storage_info
+ <phcoder> youpi: find_hurd_root_Device/file_get_storage info is about
+ translating / -> /dev/hd0s1. Current problem is in step hd0s1 ->
+ hd0,msdos1
+ <youpi> yes, but iirc file_get_storage_info might work for hd0s1 itself
+ <phcoder> I see, let me try this
+ <phcoder> youpi: file_get_storage gives offset=0 size=partition size
+ <youpi> (file_get_storage) damn
+ <phcoder> and name=hd0s1
+ <youpi> ah, that might be because we're still using in-kernel partition
+ table, instead of the parted partition table
+ <phcoder> looks like file_get_storage would be useful to get block size
+ though
+ <phcoder> youpi: is parted already used in some cases? Any reliable way to
+ check for it? Any way to access kernel partition map? Ioctl? RPC to
+ kernel?
+ <youpi> the parted table is only enabled in the debian installer for
+ now. You can set up one for yourself by running e.g. settrans -c
+ /tmp/myhd0s1 /hurd/storeio -T typed part:1:device:hd0
+ <youpi> I don't think there is any ioctl/RPC to get the kernel partition
+ table
+ <phcoder> youpi: is it using Linux partition code with some glue?
+ <youpi> phcoder: the kernel partition table, yes
+ <phcoder> youpi: that's bad. it's probably one of the least consistent
+ numbering schemes. It would imply that it only worked because only
+ simplest cases were ever tested
+ <youpi> I know
+ <youpi> that's why we want to migrate to the parted-based partition table
+ support
+ <youpi> (which also brings us much better support than the old linux2.0
+ code :) )
+ <phcoder> youpi: I've looked into code and must say that I dislike what I
+ see: partitions handled in ide/ahci/sd/...
+ <youpi> phcoder: which code?
+ <phcoder> youpi: gnumach
+ <youpi> sure, that's not what we want in the end
+ <phcoder> grep -r start_sect
+ <youpi> it's just the legacy linux way of doing partition support
+ <phcoder> Well Linux at least gives a meaningful ioctl
+ <phcoder> couldn't find any hint of it in gnumach
+ <youpi> we didn't bother to add one since the parted way is supposed to be
+ what we have in the end
+ <phcoder> youpi: I can't make our code follow sth that might be the case in
+ the future
+ <youpi> why not?
+ <youpi> that's the way we will go
+ <youpi> it's not just hypothetic
+ <youpi> we just can't continue maintaining disk drivers in the kernel
+ <youpi> so it won't be in the kernel
+ <phcoder> youpi: if I do then GRUB won't work on current GNU/Hurd anymore
+ <youpi> can't you also keep the old code?
+ <youpi> as a fallback when the proper way does not work (yet)
+ <phcoder> More hairs... :(
+ <phcoder> How do I check for it? offset == 0 isn't proper as partitions may
+ start at 0
+ <phcoder> but checking than name still refers to partition is probably the
+ right way
+ <youpi> I don't see what you mean
+ <youpi> (about name)
+ <phcoder> youpi: I mean that we need a way to know that current code is
+ used and not future parted-based code
+ <youpi> phcoder: I understand that for the offset ==0 thing
+ <youpi> but I didn't understand the phrase you wrote just after that
+ <phcoder> youpi: file_get_storage gives back a name. If this name is the
+ same as the partition we requested in the first place then it's current
+ code
+ <youpi> ah, ok
+ <youpi> yes, if the name is the same, it means it's not actually a
+ partition
+ <phcoder> youpi: current gnumach code makes fake devices out of partitions
+ <youpi> yes
+ <phcoder> youpi: with settrans command you told, I get num_ints = 0
+ <youpi> phcoder: odd, I do get information, e.g.:
+ <youpi> hurd:/tmp# settrans -c /tmp/mysd0s1 /hurd/storeio -T typed
+ part:1:device:sd0
+ <youpi> hurd:/tmp# storeinfo mysd0s1
+ <youpi> device (0x200): sd0: 512: 83905: 42959360: 63+83905
+ <phcoder> storeinfo: myhd0s1: Operation not supported
+ <youpi> do you actually have an hd0 device?
+ <phcoder> yes
+ <phcoder> youpi: I typed parted instead of part
+ <phcoder> Now it works
+ <youpi> good :)
+ <phcoder> youpi: what is expected timeline on migration to part interface?
+ <youpi> there's no real timeline
+ <youpi> like everything, it'll happen when somebody actually looks at how
+ to achieve it
+ <youpi> perhaps it'll be easy, perhaps not. IIRC there is still an issue
+ with the swapper
+ <phcoder> youpi: sounds like we're stuck will fallback code for at least
+ couple of years
+ <youpi> possibly, entirely depends on people taking the task
+ <youpi> if that becomes really pressing at some point, I'll have to do it,
+ but of course, I can not magically do everything in a glimpse
+ <phcoder> youpi: it's not pressing but just be aware that unusual
+ partitioning is likely to fail. Probably not huge issue. As to its place
+ in our code it's not ideal but it's not the only case of suboptimal
+ construction for specific systems (what we had to do because of Linux
+ caching is terrifying). I'm not going to make hurd code a scapegot of
+ more generic problem
+ <phcoder> youpi: and since we very rarely drop support this code is
+ probably stuck for good
+ <youpi> as long as it's not used whenever we get to move to parted-based
+ partitioning, it's not too bad
+ <phcoder> youpi: and Mac OS X/Darwin case is even worse. Apparently they
+ deprecated their *BSD functions (which probably don't work since they
+ don't use BSD labels) without giving any replacement.
diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn
index afa46799..849ff382 100644
--- a/hurd/running/debian/dhcp.mdwn
+++ b/hurd/running/debian/dhcp.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012, 2013 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
@@ -29,3 +30,97 @@ scripts, but has its own `/libexec/rc` script -- which integrates scripts from
* [[!debbug 616290]]
* [[Proper Hurdy DHCP support|hurd/translator/pfinet/dhcp]]
+
+ * [[!message-id desc="dhclient aborting with a stack smashing error"
+ "874ngfvwn4.fsf@kepler.schwinge.homeip.net"]]
+
+ IRC, freenode, #hurd, 2013-08-21:
+
+ <teythoon> yay, I fixed the path of the dhcp leases file...
+ <teythoon> ... and now dhclient dies of a buffer overflow
+ <teythoon> fortunately the fix is rather simple, anyone who cares about
+ the security of his box just has to stop using isc software
+ <teythoon> the code is full of stuff like char foo[100]; /* surely
+ that's enough */
+ <pinotree> note that our version of isc-dchp (the one in ports) is
+ older than the latest one available in unstable (which is still older
+ than the latest upstream releases)
+ <teythoon> so?
+ <pinotree> dunno, might have been fixed or not
+ <teythoon> ^^ yeah sure
+ <gnu_srs> A lot of software has these limitations and PATH_MAX,
+ MAXPATHLEN issues :(
+ <pinotree> having a limitation is not a problem per-se
+ <teythoon> no, only software written in c has these kind of problems
+ <pinotree> the problem is not checking whether the limits are hit
+ <teythoon> well, looking at the source of isc-dhcp my time is better
+ spent making another dhcp client work on hurd
+ <teythoon> also reading up on bug #616290 does make me want to avoid
+ touching it ever
+ <braunr> hehe
+ <gnu_srs> teythoon: somebody was offering an alternative to the isc
+ dhcpclient, but I think it was rejected by Samuel?
+ <teythoon> why would he do that?
+ <braunr> probably for compliance
+ <gnu_srs> He probably thought they would release a new version soon, is
+ 4.3.0 out yet?
+ <teythoon> well, as soon as my fixes for ifupdown go in, dhclient will
+ start crashing
+ <teythoon> no, there is no new version released
+ <teythoon> no major one that is
+ <teythoon> 4.2.5 is out
+ <gnu_srs> can't you just increase the buffer size, where is the problem
+ exactly?
+ <teythoon> I have no idea
+ <gnu_srs> The Hurd patches are not in 4.2.5, they were promised for
+ 4.3.0a1.
+ <gnu_srs> Still the buffer overflow problem might be present in 4.2.5
+ if patched to build on Hurd.
+ <braunr> there, darnassus now has a fully featured git/gitweb service
+ <teythoon> :)
+ <teythoon> btw, I managed to reproduce the crash reliably
+ <teythoon> rm /var/lib/dhcp/*; dhclient -v /dev/eth0 ... *boom*
+ <teythoon> ditch the -v, everything works, and now that there is a
+ lease file, you can add the -v again and it works
+ <braunr> ew :)
+ <teythoon> and what has dhclient.c to say for its defense?
+ <teythoon> log_info("%s", "");
+ <teythoon> hm, not much :/
+
+ IRC, freenode, #hurd, 2013-08-22:
+
+ <teythoon> uh, the isc-dhcp situation is a huge pita, the source on
+ -ports does not compile anymore :/
+
+ IRC, freenode, #hurd, 2013-08-23:
+
+ <gnu_srs> teythoon: Was it the slash in the network interface names
+ that caused the buffer overflow in dhclient?
+ <teythoon> gnu_srs: no, previously no dhcp leases file was written and
+ everything was fine
+ <pinotree> teythoon: did you really develop your patch against that old
+ version of ifupdown?
+ <teythoon> gnu_srs: now it is written, and for some reason dhclient
+ crashes *iff* -v is given *and* there is no previous lease file
+ <teythoon> pinotree: no, I did not. that was only reportbug including
+ information from my desktop machine without asking me
+ <teythoon> but when I first looked at ifupdown it was still a 6000
+ lines noweb file >,<
+ <teythoon> that was fun
+ <pinotree> which version is it against?
+ <teythoon> hg tip
+
+ IRC, freenode, #hurd, 2013-08-30:
+
+ <tschwinge> teythoon: I understand correctly that you found that
+ id:"874ngfvwn4.fsf@kepler.schwinge.homeip.net" in fact was really
+ "just" a buffer overflow in the dhclient code?
+ <teythoon> tschwinge: ah, most interesting, I didn't realize that you
+ stumbled across this as well
+ <teythoon> to be honest I don't know what's going on there, I only
+ observed what I wrote in my report
+ <teythoon> for me it started crashing once the lease file was actually
+ a valid path (i.e. not to a non-existing directory b/c of the slashes
+ in /dev/eth0)
+ <teythoon> I tried to rebuild the package served on debian-ports, but
+ that failed
diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn
index f2117ead..55bead37 100644
--- a/hurd/subhurd.mdwn
+++ b/hurd/subhurd.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2013 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
@@ -42,6 +42,22 @@ set up another Hurd on a different partition, without ever rebooting. (You can
run the `native-install` step from a chroot or already in a subhurd.)
+### IRC, freenode, #hurd, 2013-09-15
+
+ <gnu_srs> Never dared to try a subhurd, any link to the howto?
+ <teythoon> gnu_srs: I followed
+ http://www.gnu.org/software/hurd/hurd/subhurd.html though using crosshurd
+ didn't work for me, I just used debootstrap
+ <teythoon> gnu_srs: and you need a separate filesystem translator (i.e. not
+ /) for that
+ <teythoon> the easiest way is to add another virtual disk to you qemu setup
+ <braunr> use the qemu image directly
+ <braunr> simplest way to set up a subhurd
+ <braunr> just change fstab from the host before the first boot to avoid
+ making the subhurd use the same hd0 drive as the host
+ <teythoon> braunr: nice idea :)
+
+
## Booting
To boot the subhurd, you need a boot script. For historical reasons, usually
@@ -118,6 +134,362 @@ look at the number of threads (e.g. using `ps -l`), as many servers have very
characteristic thread counts.
+### IRC, freenode, #hurd, 2013-08-09
+
+ <teythoon> btw, is there a way to get dde-based networking into a subhurd?
+ <teythoon> the wiki instructions look like they're for the mach driver
+ <teythoon> and starting the dde translator inside the subhurd does not work
+ for me
+ <teythoon> that's probably a good thing though
+ <youpi> the netdde process will need privileged access to mach
+ <youpi> for hardware access
+ <braunr> you can't easily use netdde from a subhurd, unless with a
+ different nic
+ <braunr> i usually rebuild mach with in kernel devices so both the main and
+ subhurd can share on nic
+ <braunr> one*
+ <youpi> could a port to netdde perhaps forwarded to the subhurd?
+ <braunr> zengh da wrote the eth-multiplexer for that iirc
+ <youpi> it's a matter of making it appear as an eth0 device on the master
+ port aiui
+ <braunr> zheng*
+ <teythoon> yes, I looked at that
+ <teythoon> what is the master port?
+ <youpi> on a plain hurd system it's the port that privileged processes can
+ use to access mach devices
+ <youpi> in a subhurd, it's the same for the subhurd, to access some devices
+ that you choose to give access to
+ <braunr> its real name is the "device master port"
+ <teythoon> ah yes
+
+
+#### IRC, freenode, #hurd, 2013-08-10
+
+ <antrik> teythoon: use eth-multiplexer to use the NIC within a
+ subhurd. that's exactly what it was created for.
+ <antrik> I don't remember whether it's even possible to share a "raw"
+ netdde device... I don't think I ever tried that; and I don't remember
+ enough of the theory to tell whether it should be possible
+ <antrik> but I really don't see the reason to, when eth-multiplexer is
+ available
+ <antrik> (IMHO running an eth-multiplexer on top of netdde should be the
+ default setup in fact)
+ <antrik> as for actually passing on the device, that should be perfectly
+ possible with zhengda's modified subhurd... but I don't remember whether
+ that was ever merged upstream
+ <antrik> (you will definitely need that for using netdde in a subhurd,
+ regardless whether through eth-multiplexer or directly)
+
+
+#### IRC, freenode, #hurd, 2013-09-15
+
+ <teythoon> I wonder if we can modify the boot program so that it passes
+ ports from the mother hurd to the subhurd
+ <teythoon> so that we could pass in a port to the eth-multiplexer
+ <teythoon> or use like /hurd/remap as the root translator for the subhurd
+ <braunr> eth-multiplexer was created exactly for that iirc,
+ <braunr> so it's probably already done somewhere
+
+
+#### IRC, freenode, #hurd, 2013-09-16
+
+ <gnu_srs> braunr: regarding subhurd did you mean to install
+ sthibault/hurd-i386/debian-hurd.img.tar.gz
+ <gnu_srs> on a separate partition and booting using the instructions for
+ subhurds on the web.
+ <braunr> gnu_srs: yes
+ <braunr> be careful that the subhurd doesn't use the same partition as the
+ main hurd, that's all
+ <gnu_srs> what about changing fstab?
+ <braunr> 12:17 < braunr> be careful that the subhurd doesn't use the same
+ partition as the main hurd, that's all
+ <teythoon> gnu_srs: yes, you need to change the fstab
+ <teythoon> currently it is used for fscking stuff, so if it points to your
+ main partition it will cause severe corruption
+ <teythoon> gnu_srs: you also have to specify the right partition in the
+ servers.boot file
+ <gnu_srs> fstab of the subhurd image?
+ <teythoon> yes
+ <gnu_srs> how to unpack the .img file (just to be sure)?
+ <teythoon> gnu_srs: you don't need to, just use the img file as secondary
+ hard disk image
+ <gnu_srs> Then how should I be able to change fstab of the image?
+ <teythoon> boot your hurd box, mount the partition and change it
+ <gnu_srs> I missed something here: on my partition /my_chroot I have have
+ the file debian-hurd-20130504.img
+ <teythoon> gnu_srs: ah, you copied it to the partition, braunr meant to use
+ it as the secondary disk, e.g. qemu ... -hdb debian-hurd-20130504.img ...
+ <gnu_srs> That is the same as installing another cd image, where does the
+ subhurd come into play?
+ <teythoon> mount the partition on the secondary hd, fix the fstab there,
+ mount it r/o, get the servers.boot file from the wiki, modify it so that
+ it points to the right partition, execute boot servers.boot /dev/<your
+ partition>, probably /dev/hd1s1
+ <gnu_srs> BTW: unpacking was problematic: tar: debian-hurd-20130504.img:
+ Cannot seek to 2147696640 (2G limitations)
+ <teythoon> I wonder why you did this on your hurd system in the first
+ place...
+ <gnu_srs> I thought I could use that partition, /my_chroot as a chroot
+ place. So it won't work for subhurds?
+ <teythoon> well, there are several ways to setup a subhurd. one is to
+ already have a spare partition for that and use crosshurd or as I did
+ debootstrap to install a debian system there
+ <teythoon> braunr suggested an even easier way, download the .img file and
+ use it as secondary hard disk
+ <teythoon> you ended up doing kind of both
+ <gnu_srs> I tried once with debootstrap and that created a disaster...
+ <teythoon> how so?
+ <gnu_srs> The install errored out, and the whole filesystem (including /)
+ was left in a broken state. Maybe I tried
+ <gnu_srs> that without using a separate partition. Don't remember any
+ longer. So you say it's safe now?
+ <teythoon> I used it successfully to setup my subhurd
+ <gnu_srs> and you have your subhurd in a separate partition, installed from
+ there too, as root?
+ <gnu_srs> the web page only mentions crosshurd, and that failed for you?
+ <teythoon> yes, having a separate partition is (currently) necessary to run
+ a subhurd
+ <teythoon> yes, I used debootstrap as root, afaics that is necessary
+ <teythoon> and yes, as I said the other day, I tried crosshurd first and it
+ failed
+ <teythoon> then again, I fail to see any reason to use crosshurd these days
+ <teythoon> it's only a wrapper around debootstrap anyway, using it with
+ --foreign and fixing up stuff later
+ <teythoon> one has more control over the process if one uses debootstrap
+ directly
+ <gnu_srs> I still don't dare to do it yet. I'll create another image using
+ netinst with a separate partition and try out first.
+ <gnu_srs> When installing a new image using netinst.iso (2013-06-30) and
+ rebooting /proc does not get mounted?
+ <teythoon> gnu_srs: is that a statement or a question?
+ <gnu_srs> A statement.
+ <teythoon> it's not customary to end statements with question marks ;)
+ <gnu_srs> s/mounted?/mounted, why?/
+ <teythoon> well, you seem to be the last person to perform such an
+ installation, so you are in the perfect position to answer this question.
+ <gnu_srs> cat /var/log/dmesg?
+ <gnu_srs> On other images I have: fsysopts /proc; /hurd/procfs
+ --clk-tck=100 --stat-mode=444 --fake-self=1
+ <youpi> gnu_srs: no, check the installation log
+ <youpi> gnu_srs: and what does showtrans say?
+ <gnu_srs> showtrans /proc; <empty>
+ <gnu_srs> which log file to look for?
+ <youpi> the installation log, somewhere in /var/log probably
+ <gnu_srs> I only find /proc in /var/log/installer/syslog, mainly printing
+ out errors not finding /proc/mounts
+ <youpi> iirc the /proc translator should be set during the hurd package
+ configuration
+ <youpi> you should probably look for that part in the log
+ <youpi> Setting up translators: /hurd/exec /hurd/proxy-defpager
+ /hurd/pflocal (+link) /hurd/pfinet (+link) (+link) /hurd/procfs -c
+ /hurd/password crash-kill crash-suspend crash-dump-core crash.
+ <youpi> that part
+ <gnu_srs> debootstrap: /hurd/procfs -c and in-target: /hurd/procfs -c No
+ errors
+ <youpi> I don't understand what that means
+ <youpi> please explain in more details
+ <gnu_srs> see: http://paste.debian.net/41195/
+ <youpi> makes much more sense :)
+ <gnu_srs> Where is the 'Setting up translators' done? I cannot find
+ anything in /var/lib/dpkg/info/hurd* or /etc/init.d/...
+ <pinotree> /usr/lib/hurd/setup-translators, called in hurd.postinst
+ <gnu_srs> tks:)
+ <gnu_srs> Hi, when installing a new image with debootstrap to /chroot the
+ script boot/servers.boot is already there (as well as in /boot/ + grub)
+ <gnu_srs> Is it OK to use that file to boot the subhurd?
+ <gnu_srs> using /boot/servers.boot or /chroot/boot/servers.boot (if the
+ /chroot partition is unmounted it cannot be used?)
+ <gnu_srs> and how to unmount /chroot: umount does not work?
+ <gnu_srs> braunr: I'm also trying to find out what's wrong with glibc, when
+ my subhurd is up and running 2.13-39 (if possible)
+ <gnu_srs> I know I should issue settrans command, but I'm not yet fluent in
+ translators.
+ <gnu_srs> sorry:-/
+ <gnu_srs> Now this, after a reboot: unknown code P 30 while trying to open
+ /dev/hd0s3 (/chroot)
+ <gnu_srs> Disk write protected: use the -n option to do a read-only check
+ of the device.
+ <gnu_srs> fsysopts /dev/&hd0s1 --writable: Operation not supported??
+ <gnu_srs> OK, I'm giving up for now, no subhurd:-( and a broken install.
+ <gnu_srs> Which terminal to use in rescue mode, TERM is not set,
+ dumb,mach,hurd does not work with nano?
+ <gnu_srs> e2fsck /dev/ho0s3; e2fsck: Unknown code P 2 while trying to open
+ /dev/ho0s3; Possibly non-existent device?
+ <gnu_srs> mke2fs /dev/hd0s3; /dev/hd0s3 is not a block special device.;
+ Proceed anyway? (y,n) n: What's going on (hd0s3 not mounted)??
+ <gnu_srs> anybody, help?
+ <gnu_srs> after removing and creating the partition again:mke2fs
+ /dev/hd0s3, <same>, mke2fs: Unknown code P 13 while trying to determine
+ filesystem size: What's going on?
+ <gnu_srs> Where to find the glibc-2.13 versions which used to be at
+ debian-ports?.
+ <gnu_srs> seems they can be found on snapshot.debian.org
+
+
+#### IRC, freenode, #hurd, 2013-09-17
+
+ <gnu_srs> teythoon: Installing subhurd via debootstrap on partition
+ /chroot fails miserably. Install hangs, and after reboot \rm -r
+ /chroot/* fails for dev and proc
+ <gnu_srs> Are there translators running there already? I have not
+ booted the subhurd.
+ <gnu_srs> translators for hd0s3 (/chroot) are storeio and
+ ex2fs.static. Do I have to stop them to be able to clean out
+ /chroot?
+ <gnu_srs> mount -v /chroot; settrans -a /chroot /hurd/ext2fs
+ /dev/hd0s3;
+ <gnu_srs> ext2fs: /dev/hd0s3: panic: main: device too small for
+ superblock (0 bytes);
+ <gnu_srs> mount: cannot start translator /hurd/ext2fs: Translator
+ died
+ <gnu_srs> Please, somebody!
+ <gnu_srs> don't ask to ask, just ask, right?
+ <braunr> we've already told you everything you need
+ <braunr> just get it right
+ <braunr> for example, i told you to be careful about fstab so that
+ the subhurd wouldn't use the main hurd partition
+ <braunr> but you managed to screw that
+ <braunr> good job
+ <gnu_srs> I installed the subhurd in a partition /chroot /dev/hd0s3
+ using debootstrap
+ <braunr> i don't know deboostrap, it may be broken, use the disk
+ image youpi maintains
+ <gnu_srs> ant the install screwed up with debootstrap
+ <gnu_srs> ok; then I cannot use a partition, but another disk in
+ kvm, e.g. hdb?
+ <braunr> gnu_srs: hd1
+ <gnu_srs> something is fishy with glibc, definitely, that's why I'm
+ trying to set up a subhurd to revert to 2.13-39
+ <gnu_srs> hi, when trying to boot a subhurd: /hurd/ext2fs.static:
+ hd0s3: Gratuitous error; bye
+ <braunr> gnu_srs: why hd0s3 ?
+ <braunr> it should be hd1s1
+ <gnu_srs> I'm still using a separate partition /my_chroot
+ /hd0s3. Will switch to hd1 next. teythoon?
+ <gnu_srs> the servers.boot script use absolute
+ paths:/hurd/ext2fs.static and /lib/ld.so.1 /hurd/exec,
+ <gnu_srs> shouldn't they be relative to /my_chroot?
+ <braunr> no
+ <braunr> they're actually from your host
+ <gnu_srs> teythoon: please, how did you succeed to boot a subhurd
+ in a partition?
+ <gnu_srs> using debootstrap
+ <teythoon> gnu_srs: from my shell history:
+ <teythoon> : 1374672426:0;debootstrap sid /mnt
+ http://http.debian.net/debian/
+ <teythoon> : 1374673020:0;cp /etc/hosts /etc/resolv.conf /mnt/etc
+ <teythoon> : 1374673048:0;cp /etc/passwd /etc/shadow /mnt/etc
+ <braunr> teythoon: so it does work fine ?
+ <braunr> great
+ <teythoon> yes, why wouldn't it?
+ <teythoon> gnu_srs: I then remounted that partition r/o and used
+ the servers.boot file from the wiki to boot it
+ <teythoon> braunr: why wouldn't it? (you do mean the debootstrap
+ part, don't you?)
+ <braunr> teythoon: i don't know
+ <braunr> i've heard it wasn't maintained any more
+ <braunr> not being maintained is a good reason for something to
+ become unusable/untrustable with time
+ <teythoon> o_O it is at the heart of d-i, isn't it?
+ <teythoon> I actually do most Debian installations using
+ debootstrap directly
+ <braunr> ah
+ <braunr> ok :)
+ <braunr> teythoon: even hurd ones ?
+ <teythoon> braunr: well, just the subhurd installation, but that
+ went as expected
+ <braunr> good
+ <gnu_srs> Finally: I found the reason for Gratuitous error, I used
+ the /boot/servers.boot script,
+ <gnu_srs> that being different to the one on the wiki:-/
+ <gnu_srs> Is it possible to copy files between a host hurd and
+ subhurd, what about access to eth0?
+ <gnu_srs> Hi, when starting the subhurd I see some warnings/error:
+ http://paste.debian.net/41963/
+ <gnu_srs> 1) A spelling error execunable-> executable
+ <gnu_srs> 2) libports: invalid destination port
+ <gnu_srs> 3) mach-defpager: another already running
+ <pinotree> "execunable" is not a typo, but just "exec" and "unable
+ ..." without a space-type character
+ <gnu_srs> OK, sounds more plausible
+ <gnu_srs> Ah, the printouts are mixed, no bug
+ <gnu_srs> When setting up nework in the subhurd: /hurd/pfinet:
+ file_name_lookup /dev/eth0: Translator died
+ <gnu_srs> /hurd/pfinet: device_open(/dev/eth0): (os/device) no such
+ device
+ <gnu_srs> settrans: /hurd/pfinet: Translator died
+
+
+#### IRC, freenode, #hurd, 2013-09-18
+
+ <youpi> priority does not matter much
+ <youpi> memory manager is not really surprising, there's indeed already one
+ <youpi> what is actually the problem?
+ <gnu_srs> So these are merely warnings?
+ <youpi> gnu_srs: yes
+ <gnu_srs> Real problems are I cannot set up networking, e.g. wget ...:
+ Connecting to ... failed: Address family not supported by protocol.
+ <youpi> gnu_srs: did you give the subhurd a network card?
+ <gnu_srs> How?
+ <gnu_srs> and do I need to set up fstab, for now it's empty.
+ <gnu_srs> I just installed the base with dbootstrap
+ <youpi> gnu_srs: -f option of boot
+ <youpi> e2fsck will need fstab for sure
+ <youpi> otherwise it can't divine what should be checked
+ <gnu_srs> Why is the /boot/servers.boot different from the subhurd one on
+ the wiki? Is it used at all, I thought grub was in charge.
+ <youpi> it's not used at all
+ <gnu_srs> maybe better to put in the subhurd one there then, with a
+ comment?
+ <youpi> no, since /boot/servers.boot is supposed to be used for machine
+ boot
+ <youpi> not subhurd boot
+ <gnu_srs> what about putting a copy of the suhurd one there, with a
+ different name?
+ <youpi> probably a good idea, yes
+ <youpi> matter of making it happen
+ <gnu_srs> the wiki page on subhurd does not say how to set up networking,
+ only that you can do it.
+ <youpi> matter of adding the information
+ <youpi> I remember it's the -f option of boot
+ <youpi> make it work, and add the information for others
+ <gnu_srs> I could try, but don't know how to add a network card to the
+ subhurd, and e.g. how to set up swap
+ <youpi> see -f option
+ <gnu_srs> of boot?
+ <youpi> "gnu_srs: -f option of boot"
+ <youpi> if you could read what we write, that'd make things happen way
+ faster
+ <gnu_srs> yes I saw your comment above, it was just to be 100% sure:-D
+ <gnu_srs> device_file=/dev/eth0 or something else?
+ <gnu_srs> eth0 is used by the host already
+ <youpi> did you read boot --help ?
+ <youpi> iirc it's not a problem, both will receive all frames
+ <gnu_srs> yes I did
+ <youpi> then I don't see where you took device_file from
+ <youpi> at least in that form
+ <youpi> --device=device_name=device_file
+ <youpi> that means rather something like --device=foo=bar
+ <gnu_srs> so -f /dev/eth0 is correct usage then?
+ <youpi> didn't you see that in what I wrote, there was a "=" in there?
+ <gnu_srs> -f is the short option, --device is the long, I don't see the
+ need for = in the short option?
+ <youpi> in the long option there are *two* =
+ <gnu_srs> yes, but in the short no?
+ <youpi> why not?
+ <youpi> long -> short usually drops one =
+ <gnu_srs> to summarize: -f=/dev/eth0 or --device=eth_sub=/dev/eth0?
+ <youpi> why shouldn't there be a eth_sub in the short version?
+ <gnu_srs> 10:15:49) youpi: long -> short usually drops one =
+ <youpi> yes, it drops the =
+ <youpi> but nothing else
+ <youpi> if the long option needs some information, the short needs it too?
+ <youpi> -?
+ <gnu_srs> correct now? -f eth_sub=/dev/eth0 or --device=eth_sub=/dev/eth0?
+ <youpi> yes
+ <gnu_srs> k!
+
+
# Further Info
Read about using a subhurd for [[debugging_purposes|debugging/subhurd]].
diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index 37dac794..da141dc2 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -92,16 +92,19 @@ The [[concept|concepts]] of translators creates its own problems, too:
* [[exec]]
* [[proc]]
* [[pfinet]]
+* [[eth-filter]]
* [[pflocal]]
* [[hostmux]]
* [[storeio]]
* [[ext2fs]]
* [[fatfs]]
+* [[ufs]]
* [[magic]]
* [[unionfs]]
* [[nfs]]
* [[symlink]]
* [[firmlink]]
+* [[fifo]]
* ...
@@ -124,7 +127,7 @@ The [[concept|concepts]] of translators creates its own problems, too:
*These Translators are available in the [hurdextras repository](http://savannah.nongnu.org/cvs/?group=hurdextras) but not yet described on this website. They are in varying stages of Development.*
* [jfs](http://www.nongnu.org/hurdextras/#jfs)
-* [httpfs](http://www.nongnu.org/hurdextras/#httpfs)
+* [[httpfs]]
* [memfs](http://www.nongnu.org/hurdextras/#memfs)
* [notice](http://www.nongnu.org/hurdextras/#notice)
* [pith](http://www.nongnu.org/hurdextras/#pith)
diff --git a/hurd/translator/eth-filter.mdwn b/hurd/translator/eth-filter.mdwn
new file mode 100644
index 00000000..4f59b402
--- /dev/null
+++ b/hurd/translator/eth-filter.mdwn
@@ -0,0 +1,26 @@
+[[!meta copyright="Copyright © 2013 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, 2013-07-27
+
+[[!tag open_issue_hurd]]
+
+ <youpi> ok, so as usual we actually *already* have a firewall
+ <youpi> it's the eth-filter translator from zheng da
+ <youpi> it has just never been really pushed forward...
+ <teythoon> good news :)
+ <youpi> well, the bad news is that it probably doesn't support connection
+ tracking
+ <youpi> since it's just bpf
+ <youpi> using the libpcap syntax
+ <teythoon> well, a stateless fw should do for Debian/Hurds needs for now,
+ right?
+ <youpi> yes
+ <youpi> and it does work indeed
diff --git a/hurd/translator/examples.mdwn b/hurd/translator/examples.mdwn
index 867d4935..4947808e 100644
--- a/hurd/translator/examples.mdwn
+++ b/hurd/translator/examples.mdwn
@@ -16,7 +16,7 @@ or [hurd-extras](http://www.nongnu.org/hurdextras/).
cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/hurdextras co <modulename>
-* httpfs translator
+* [[httpfs]] translator
<!-- Prevent ikiwiki / Markdown rendering bug. -->
@@ -28,7 +28,7 @@ or
$ cd tmp/
$ ls -l
-* ftpfs translator
+* [[ftpfs]] translator
<!-- Prevent ikiwiki / Markdown rendering bug. -->
@@ -67,13 +67,13 @@ This is not as fast as `tar czvf newfile.tar.gz all my files`, but at least it's
$ settrans -fgca /servers/socket/2 /hurd/pfinet -i <interface> -a <ip address> -m <subnet mask> -g <gateway ip>
-* Console translator -- setting up virtual consoles
+* [[Console]] translator -- setting up virtual consoles
<!-- Prevent ikiwiki / Markdown rendering bug. -->
$ console -d vga -d pc_mouse -d pc_kbd -d generic_speaker /dev/vcs
-* iso9660fs translator -- 'mounting' your cdrom
+* [[iso9660fs]] translator -- 'mounting' your cdrom
<!-- Prevent ikiwiki / Markdown rendering bug. -->
diff --git a/hurd/translator/exec.mdwn b/hurd/translator/exec.mdwn
index 54abba7e..1dc0ea26 100644
--- a/hurd/translator/exec.mdwn
+++ b/hurd/translator/exec.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2012, 2013 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
@@ -11,4 +12,9 @@ License|/fdl]]."]]"""]]
The *exec* server, listening on `/servers/exec`, is responsible for
preparing the execution of processes.
+
+# Open Issues
+
+ * [[open_issues/exec]].
+
* [[open_issues/exec_memory_leaks]].
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index 20faed5e..e2f6b044 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -179,6 +179,69 @@ small backend stores, like floppy devices.
That would be a nice improvement, but only after writeback throttling is implemented.
+## Stripped vs. Unstripped `ext2fs.static`
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-09-17
+
+ <teythoon> I always had some trouble with dropping a rebuild ext2fs.static
+ into my test system and I never figured out why
+ <teythoon> I just followed a hunch and stripped the binary, and all of the
+ sudden it works
+ <teythoon> any ideas why?
+ <tschwinge> teythoon: I quick search found me:
+ <https://savannah.gnu.org/bugs/?8497> and
+ <http://news.gmane.org/find-root.php?message_id=%3c4090243E.2040605%40comcast.net%3e>.
+ <teythoon> tschwinge: ugh, thanks for the pointers ;)
+ <tschwinge> teythoon: They won't help too much I fear. Anyway, good
+ intuition (or whatever) ;-) that you found this out.
+ <tschwinge> teythoon: Not exactly related to stripped/unstripped per se
+ (that is, debug information), but in the past we've had an issue about
+ relro (see binutils/glibc, <http://www.airs.com/blog/archives/189>),
+ where a variable (that erroneously happend to be in such a read-only
+ section, if I remember correct) was tried to be modified -- which worked
+ "sometimes": depending on where exactly it was located in the binary
+ (which shifted around a page
+ <tschwinge> boundary by stripped/unstripped), it'd segfault or not. Burnt
+ several days on that before Samuel (IIRC) eventually figured it out.
+ <teythoon> tschwinge: well, thanks anyway ;)
+
+
+## Increased Memory Consumption
+
+### IRC, freenode, #hurd, 2013-09-18
+
+ <braunr> ext2fs is using a ginormous amount of memory on darnassus since i
+ last updated the hurd package :/
+ <braunr> i wonder if my ext2fs large store patches rework have introduced a
+ regression
+ <braunr> the order of magnitude here is around 1.5G virtual space :/
+ <braunr> it used to take up to 3 times less before that
+ <braunr> looks like my patches didn't make it into the latest hurd package
+ <braunr> teythoon: looks like there definitely is a new leak in ext2fs
+ <teythoon> :/
+ <braunr> memory only
+ <braunr> the number of ports looks stable relative to file system usage
+ <teythoon> braunr: I tested my patches on my development machine, it's up
+ for 14 days (yay libvirt :) and never encountered problems like this
+ <braunr> i've been building glibc to reach that state
+ <teythoon> hm, that's a heavy load indeed
+ <teythoon> could be the file name tracking stuff, I tried to make sure that
+ everything is freed, but I might have missed something
+ <braunr> teythoon: simply running htop run shows a slight, regular increase
+ in physical memory usage in ext2fs
+ <pinotree> old procfs stikes again? :)
+ <teythoon> braunr: I see that as well... curious...
+ <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried
+ to make sure that everything is freed, but I might have missed something
+ <braunr> how knows, maybe completely unrelated
+ <teythoon> the tracking patch isn't that big, I've gone over it twice today
+ and it still seems reasonable to me
+ <braunr> hm
+
+
# Documentation
* <http://e2fsprogs.sourceforge.net/ext2.html>
diff --git a/hurd/translator/fifo.mdwn b/hurd/translator/fifo.mdwn
new file mode 100644
index 00000000..857922fc
--- /dev/null
+++ b/hurd/translator/fifo.mdwn
@@ -0,0 +1,48 @@
+[[!meta copyright="Copyright © 2013 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]]."]]"""]]
+
+The *fifo* translator implements named pipes (FIFOs).
+
+
+# Open Issues
+
+## Not Terminating
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, OFTC, #debian-hurd, 2013-07-28
+
+ <gg0> seems fifos started dying, as they should. am i wrong?
+ <gg0> ( http://bugs.debian.org/629184 )
+ <azeem> so you're saying the bug should be closed?
+ <azeem> best to comment on the bug then
+ <gg0> i didn't hear anyone working on it, so i'm a bit surprised
+ <azeem> could be due to lower-level fixes to glibc or so
+ <gg0> and given often(:|) i'm wrong, i was asking
+ <pinotree> in two years there have been various changes in glibc and hurd
+ <pinotree> (for example the switch to pthreads)
+ <gg0> yeah seems fixed. mknod'ing one then removing it, doesn't leave any
+ process around
+ <gg0> cool
+ <azeem> then please follow-up on the bug and/or close it
+ <gg0> sure
+ <gg0> the pleasure of closing it/them is yours
+ <gg0> great job, whatever you did :)
+
+
+### IRC, OFTC, #debian-hurd, 2013-07-29
+
+ * gg0 wonders if it can close savannah one as
+ wellhttps://savannah.gnu.org/bugs/?17128
+ <pochu> gg0: wdym?
+ <pochu> gg0: got an example?
+ <gg0> http://bugs.debian.org/629184
+ <gg0> i didn't close it myself
diff --git a/hurd/translator/hostmux.mdwn b/hurd/translator/hostmux.mdwn
index 5fab2dc5..ef16505b 100644
--- a/hurd/translator/hostmux.mdwn
+++ b/hurd/translator/hostmux.mdwn
@@ -29,3 +29,18 @@ When <code>**/ftp**</code> is accessed, the first directory is interpreted as ho
You can see the new created translator in the process list: <code>**ps ax | grep ftpsfs**</code> . You shoud see <code>**/hurd/ftpfs / ftp.yourhost.com**</code> .
-- [[Main/PatrickStrasser]] - 13 Jul 2004
+
+
+# Open Issues
+
+## IRC, freenode, #hurd, 2013-09-21
+
+[[!tag open_issue_hurd]]
+
+ <jproulx> ls /http://<ip>:<port>/
+ <jproulx> the image came with a global translator though I see it doesn't
+ grokk the alternate port notation.
+ <youpi> oh right
+ <jproulx> I shall return to the fine documentation
+ <youpi> it's a hostmux, it doesn't understand ports
+ <youpi> damn, one thus can't url plain urls with that scheme
diff --git a/hurd/translator/httpfs.mdwn b/hurd/translator/httpfs.mdwn
new file mode 100644
index 00000000..dc4a62f7
--- /dev/null
+++ b/hurd/translator/httpfs.mdwn
@@ -0,0 +1,100 @@
+[[!meta copyright="Copyright © 2013 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]]."]]"""]]
+
+`httpfs` is a virtual filesystem allowing you to access web pages and files.
+
+
+# Source
+
+<http://www.nongnu.org/hurdextras/#httpfs>
+
+
+# Documentation
+
+## IRC, freenode, #hurd, 2013-09-03
+
+[[!tag open_issue_documentation]]
+
+ <congzhang> hi, why I can't cd to /http:/richtlijn.be/~larstiq/hurd/ to do
+ <congzhang> grep?
+ <pinotree> this is not ftp
+ <congzhang> it works for other file
+ <pinotree> ?
+ <congzhang> I can't cd to ~larstiq, I don't know why
+ <pinotree> http is not a filesystem protocol
+ <pinotree> while httpfs could try in representing it as such, it is not
+ something reliable
+ <congzhang> ok, it's not reliable
+ <congzhang> I expect it can expose dir like browser
+ <congzhang> so, the translator just know href from home page, and one by
+ one
+ <pinotree> uh?
+ <congzhang> if ...:80/a/b/c.png exits, but not has a href in homepage, so I
+ can't cd to a, right?
+ <pinotree> you are looking things from the wrong point of view
+ <pinotree> a web server can do anything with URLs, including redirecting,
+ URL rewriting and whatever else
+ <congzhang> so, how to understand httpfs's idea?
+ <congzhang> how httpfs list dir?
+ <pinotree> check its code
+ <congzhang> en, no need it's not reliable
+ <congzhang> it's not work, it's enough
+ <congzhang> I have an idea, for the file system, we explore dir level by
+ level, but for http, we change full path one
+ <congzhang> once time
+ <congzhang> maybe can allow user to cd any directory, and just mark as some
+ special color to make user know the translator was not sure, file exist
+ or not
+ <congzhang> once the file exits, mark all the parent directory as normal
+ color?
+ <rekado> congzhang: you can find more info about httpfs here:
+ http://nongnu.org/hurdextras/
+ <pinotree> congzhang: you're still looking at http from the wrong point of
+ view
+ <pinotree> there are no directories nor files
+ <pinotree> you start a request for a URL, and you get some content back (in
+ case there's no error)
+ <congzhang> you mean httpfs just for kidding?
+ <pinotree> that the content is a web page listing a directory on the
+ filesystem of the web server machine, or a file sent back via the
+ connection, or a complex web page, it's the same
+ <rekado> congzhang: you can only get a list of files if the web server
+ responds with an index of files
+ <pinotree> "files"
+ <rekado> The readme explains how httpfs does its thing:
+ http://cvs.savannah.gnu.org/viewvc/*checkout*/httpfs/README?root=hurdextras
+ <congzhang> if I can't cd to /http:/host/a/b how to get
+ /http:/host/a/b/c.html, even the file exist?
+ <pinotree> you don't cd in http
+ <pinotree> cd is for changing directory, which does not apply to a protocol
+ like http which is not fs-oriented
+ <congzhang> yes, I agree with you, http was not fs-oriented
+ <congzhang> so httpfs was not so useful
+ <rekado> You can access the document directly, though, can't you?
+ <congzhang> rekado: I try once more
+ <congzhang> I can't
+ <congzhang> so, the httpfs need some extend, http protocol was not fs
+ oriented, so need some extend to make it work with file system
+ <pinotree> http is not designed for file system usage, so extending it is
+ useless
+ <congzhang> or, httpfs was not so useful
+ <pinotree> there are many other protocols for file systems
+ <congzhang> I don't think so
+ <pinotree> i do
+ <congzhang> if we can't make it more useful, remove it from hurd rep, or
+ extend it more useful
+ <congzhang> add some more rule, to make it work with file system
+ <pinotree> no
+ <congzhang> some paradox in it
+ <pinotree> which paradox?
+ <congzhang> for http vs file system
+ <pinotree> ???
+ <congzhang> tree oriented and star topology oriented?
+ <pinotree> you don't make any sense
diff --git a/hurd/translator/nsmux.mdwn b/hurd/translator/nsmux.mdwn
index d156772b..6b3be79c 100644
--- a/hurd/translator/nsmux.mdwn
+++ b/hurd/translator/nsmux.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2013 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]]."]]"""]]
# nsmux
@@ -119,3 +119,24 @@ of the simplest use-case of namespace-based translator selection in
the form of translator `nsmux`. The filter is partially implemented
and this is the immediate goal. Propagating translators down
directories is the next objective.
+
+
+## Open Issues
+
+### IRC, freenode, #hurd, 2013-08-22
+
+[[!tag open_issue_hurd]]
+
+ < youpi> err, is nsmux supposed to work at all?
+ < youpi> a mere ls doesn't work
+ < youpi> I'm running it as a user
+ < youpi> echo * does work though
+ < teythoon> ah, yes, nsmux,,is,,funny :p
+ < youpi> well, perhaps but I can't make it work
+ < youpi> well, the trivial ,,hello does work
+ < youpi> but ,,tarfs doesn't seem to be working for instance
+ < youpi> same for ,,mboxfs
+ < youpi> ,,xmlfs seems to somehow work a bit, but not very far...
+ < youpi> so it seems just nobody is caring about putting READMEs wherever
+ appropriate
+ < youpi> e.g. examples in socketio/ ...
diff --git a/hurd/translator/pfinet.mdwn b/hurd/translator/pfinet.mdwn
index f6f69ea4..bf535b21 100644
--- a/hurd/translator/pfinet.mdwn
+++ b/hurd/translator/pfinet.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 2011 Free Software
-Foundation, Inc."]]
+[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 2011, 2013 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
@@ -33,6 +33,9 @@ installation.
* [[DHCP]].
+ * [[IPv6]].
+
+ * [[eth-filter]]: Firewall.
+
* [[Implementation]].
- * [[IPv6]].
diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index 9bcf62ef..2361615a 100644
--- a/hurd/translator/pfinet/implementation.mdwn
+++ b/hurd/translator/pfinet/implementation.mdwn
@@ -27,6 +27,170 @@ implementation.
<youpi> oh
<braunr> http://jl-icase.home.comcast.net/~jl-icase/LinuxTCP2.html
+## IRC, freenode, #hurd, 2013-09-03
+
+In context of the item on [[/contributing]].
+
+ <rekado> About this task: "Make pfinet OK with the ethernet device going
+ away." --- how can I test this? How can I remove the ethernet device?
+ <pinotree> settrans on the ethernet device, handled by the netdde
+ translator
+ <pinotree> that is, make it go away (settrans -fg)
+ <rekado> Ah, I see.
+ <rekado> Thanks
+ <pinotree> check its status before with showtrans
+ <pinotree> then, after having made it go away, set it again
+ <rekado> I don't think I'm doing this right... After `settrans -fg
+ /dev/eth0` I should not be able to access the network anymore, but it
+ still works.
+ <rekado> How can I figure out which of the four network devices is actually
+ used?
+ <braunr> rekado: the file system is used to open files, i.e. access
+ services
+ <braunr> it's not used to revoke access
+ <braunr> once pfinet has obtained a port to the network device, it keeps it
+ <rekado> oh, yes, of course. Sorry, this is all very
+ new to me.
+ <rekado> I'm not sure what the problem is that this task describes. In
+ what way is pfinet "not OK" with the ethernet device going away?
+ <braunr> rekado: the idea is to make pfinet able to cope with a driver
+ crash
+ <rekado> Can I trigger a driver crash for test purposes? (Or do I have to
+ build a purposefully broken driver first?)
+ <braunr> use kill
+ <rekado> Oh, good.
+ <braunr> iirc, netdde doesn't restart correctly :x
+ <braunr> you'll probably have to fix it a bit
+ <braunr> i guess there is some persistent state that prevents it from
+ reinitializing correctly
+ <rekado> okay
+ <rekado> I may need one more pointer: where can I find the netdde code?
+ Grep'ing around I only see it only mentioned as an argument to
+ /hurd/devnode; also: should I work in some incubator branch or directly
+ in the hurd repo?
+ <braunr> rekado: incubator branch
+ <rekado> Okay. Thank you for your patience. I'll play with this in the
+ next few days.
+ <braunr> enjoy
+ <rekado> :)
+
+
+### IRC, freenode, #hurd, 2013-09-05
+
+ <rekado> When I kill the /hurd/netdde process I can no longer access the
+ network (as expected);
+ <rekado> To restore connectivity I run "settrans -g eth0 /hurd/devnode -M
+ /dev/netdde eth0" from the /dev directory.
+ <rekado> When I access the network again everything is fine. (I do see a
+ message telling me "irq handler 11: release an dead delivery port"
+ <rekado> )
+ <rekado> Is it the goal to avoid having to run settrans again to run netdde
+ after it crashes or is killed?
+ <youpi> you don't need to run settrans again
+ <youpi> that should get triggered automatically
+ <rekado> Hmm, after killing netdde I get "Resource lost" when using wget.
+ <rekado> It doesn't seem to be restarted automatically.
+ <youpi> try again
+ <youpi> the first wget makes pfinet try to use netdde and fail, thus crash
+ <youpi> the second wil respawn pfinet
+ <youpi> ideally pfinet shouldn't die, that's a TODO mentioned in the
+ "contributing page"
+ <rekado> Ah, so that's what should be prevented.
+ <youpi> it's just a matter of making pfinet be fine with errors from the
+ eth translator, and simply reopen it instead of dying
+ <rekado> That's the thing I've been trying to figure out.
+ <rekado> when I run wget a second (or third) time I get a different error;
+ "Name or service not known."
+ <rekado> It's only okay again when I use settrans
+ <youpi> maybe the devnode translator also needs some fixing
+ <youpi> it's odd that I don't have the issue though
+ <rekado> I'm using the qemu image, updated just yesterday.
+ <youpi> same here
+ <youpi> anyway, now you know where to put your hands :)
+ <rekado> yes, thanks a lot.
+
+
+### IRC, freenode, #hurd, 2013-09-07
+
+ <rekado> in pfinet/ethernet.c:ethernet_open there's an assertion:
+ edev->ether_port == MACH_PORT_NULL
+ <rekado> This is violated when netdde was killed and the device is
+ reopened.
+ <rekado> I'm not sure what should be done: destroy the port before
+ reopening or drop the assertion?
+ <rekado> If I drop the assertion, Mach seems to handle this just fine.
+ <rekado> Says "irq handler 11: release an [sic] dead delivery port" and
+ then carries on without problems.
+ <rekado> Is this a warning or an error, or can this be ignored?
+ <rekado> (or none of the above?)
+
+
+### IRC, freenode, #hurd, 2013-09-08
+
+ <rekado> I have a simple patch for pfinet that lets it recover from an
+ error in ethernet_xmit when /hurd/netdde and /hurd/devnode have been
+ killed.
+ <rekado> It doesn't work, though, when only netdde has been killed.
+ <rekado> With devnode still around device_open fails with "(ipc/send)
+ invalid destination port"
+ <rekado> I don't know where device_open is defined and why this error is
+ returned.
+ <rekado> I guess the error refers to the "master_device" port returned by
+ file_name_lookup() in ethernet_open()
+ <rekado> Why would file_name_lookup() return an invalid port when netdde is
+ dead but devnode is still running?
+ <braunr> rekado: maybe because devnode needs to perform a fresh lookup as
+ well
+
+
+### IRC, freenode, #hurd, 2013-09-09
+
+ <rekado> braunr: re devnode: devnode only performs a single lookup in
+ parse_opt(), i.e. at start-up.
+ <rekado> I'll try to understand devnode enough to patch it.
+ <braunr> rekado: that's the problem
+ <braunr> it should perform a lookup every time it's opened
+
+[[!message-id "1378730237-8091-1-git-send-email-rekado@elephly.net"]],
+[[!message-id "1378731824-8928-1-git-send-email-rekado@elephly.net"]].
+
+ <rekado> I submitted two patches to the mailing list. I've tested them on
+ Debian GNU/Hurd but based them on the incubator/dde branch.
+ <teythoon> rekado: awesome, reliability fixes are very much welcome
+
+
+### IRC, freenode, #hurd, 2013-09-18
+
+ <rekado> youpi: my apologies for the delay in getting back to you with
+ improvements to my pfinet/devnode patches. Been very busy.
+ <braunr> rekado: development pace on the hurd has always been slow, no need
+ to apologize
+
+## MAC Addresses
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-09-21
+
+ <jproulx> what command will show me the MAC address of an interface?
+ <youpi> ah, too bad inetutils-ifconfig doesn't seem to be showing it
+ <youpi> I don't think we already have a tool for that
+ <youpi> it would be a matter of patching inetutils-ifconfig
+
+
+## Routing Tables
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-09-21
+
+ <jproulx> Hmmm, OK I can work around that, what about routing tables, can I
+ see them? can I add routes besides the pfinet -g default route?
+ <youpi> I don't think there is a tool for that yet
+ <youpi> it's not plugged inside pfinet anyway
+
# Reimplementation, [[!GNU_Savannah_task 5469]]
diff --git a/hurd/translator/pflocal.mdwn b/hurd/translator/pflocal.mdwn
index dc2434dc..fdcc39f1 100644
--- a/hurd/translator/pflocal.mdwn
+++ b/hurd/translator/pflocal.mdwn
@@ -1,13 +1,35 @@
-[[!meta copyright="Copyright © 2000, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2000, 2008, 2013 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]]."]]"""]]
The implementation of the `pflocal` server is in the `pflocal` directory, and
uses [[`libpipe`|libpipe]] (shared code with the [[named_pipe|fifo]]
implementation).
+
+
+# Open Issues
+
+## `SO_REUSEADDR`
+
+### IRC, freenode, #hurd, 2013-09-19
+
+ <gnu_srs> Hi, is SO_REUSEADDR supported at all on Hurd? I can only find two
+ entries:
+ <gnu_srs> in libdde-linux26 and pfinet/linux-src, and the functionality
+ seems to be unimplemented.
+ <pinotree> gnu_srs: pfinet supports it
+ <youpi> gnu_srs: grep talks about pfinet/linux-src/net/core/sock.c:
+ case SO_REUSEADDR:
+ <youpi> two times
+ <gnu_srs> Yes, and that is the implementation?
+ <gnu_srs> I wrote a test for AF_INET and it works, but not for AF_UNIX
+ (maybe not so interesting case).
+ <pinotree> pflocal does not support it
+ <gnu_srs> Is that of interest at all?
diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn
index 98940f87..d5e0960c 100644
--- a/hurd/translator/proc.mdwn
+++ b/hurd/translator/proc.mdwn
@@ -51,3 +51,25 @@ It is stated by `/hurd/init`.
it could just exec sysvinit
<teythoon> I just think it's easier to patch hurd than to remove the
assumption that init is pid 1 from sysvinit
+
+
+## IRC, freenode, #hurd, 2013-09-13
+
+ <braunr> teythoon: also, as a feature request, i'd like the proc server not
+ to have pid 0, if you have any time to do that
+ <braunr> so it appears in top and friends
+ <teythoon> braunr: noted, that should be easy
+ <teythoon> not using 0 is probably a good thing, many things use pid 0 as
+ something special
+
+
+# Process Discovery
+
+## IRC, freenode, #hurd, 2013-08-26
+
+ < teythoon> somewhat related, I do not like the way the proc server just
+ creates processes for new mach tasks it discovers
+ < teythoon> that does not play well with subhurds for example
+ < braunr> teythoon: i agree with you on proc process-to-task mapping
+ < braunr> that's something i intend to completely rework on propel
+ < braunr> in a way similar to how pid namespaces work on linux
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index fcda453e..44b8cc77 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -150,6 +150,9 @@ License|/fdl]]."]]"""]]
<youpi> it "just" needs to be commited :)
<antrik> in either case, it can't hurt to bring this up again :-)
+[[community/gsoc/project_ideas/mtab/discussion]], *IRC, freenode, #hurd,
+2013-09-07*.
+
# root group
@@ -305,6 +308,13 @@ License|/fdl]]."]]"""]]
See also [[community/gsoc/project_ideas/mtab]].
+## IRC, freenode, #hurd, 2013-09-20
+
+ <pinotree> teythoon: should procfs now have $pid/mounts files pointing to
+ ../mounts?
+ <teythoon> pinotree: probably yes
+
+
# `/proc/[PID]/auxv`
Needed by glibc's `pldd` tool (commit
diff --git a/hurd/translator/ufs.mdwn b/hurd/translator/ufs.mdwn
new file mode 100644
index 00000000..4d611e95
--- /dev/null
+++ b/hurd/translator/ufs.mdwn
@@ -0,0 +1,38 @@
+[[!meta copyright="Copyright © 2013 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]]."]]"""]]
+
+The `ufs` translator supports some kind of the Unix File System. Beware, we're
+not aware of anybody having used/tested it in ages, so maybe it is very broken
+and will eat your data.
+
+
+# IRC, freenode, #hurd, 2013-08-30
+
+[[!tag open_issue_hurd]]
+
+ <Arne`> There might be a copyright problem: <nalaginrut> well, there seems
+ BSD-4clauses in the code:
+ http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/ufs/alloc.c
+ <Arne`> braunr, tschwinge: Do you have any info on that? 4-clause BSD and
+ GPL on the same code are a license incompatibility…
+ <tschwinge> Arne`: I've put it onto my (long) TODO list.
+ <tschwinge> Easiest solution might be: rm -rf ufs.
+ <nalaginrut> will these affected code rewritten? or just modify license?
+ <mark_weaver> only the regents of the University of California could choose
+ to modify the license.
+ <youpi> nalaginrut: one can't modify a licence if one is not the author
+ <youpi> we can simply dump the code
+ <mark_weaver> s/author/owner/
+ <tschwinge> As I suppose ufs is unused/untested for a decade or so, I'd
+ have no issues with simply removing it from the tree, together with
+ ufs-fsck and ufs-utils.
+ <pinotree> tschwinge: or maybe extract the ufs stuff in an own repo, to be
+ imported as branch in incubator or own hurd/ufs.git?
+ <tschwinge> Sure, why not.
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-26 21:55:36 +0000