From eccdd13dd3c812b8f0b3d046ef9d8738df00562a Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 25 Sep 2013 21:45:38 +0200 Subject: IRC. --- hurd/debugging/rpctrace.mdwn | 39 +++ hurd/libstore.mdwn | 37 ++- hurd/libstore/part.mdwn | 133 ++++++++- hurd/running/debian/dhcp.mdwn | 97 ++++++- hurd/subhurd.mdwn | 376 ++++++++++++++++++++++++- hurd/translator.mdwn | 5 +- hurd/translator/eth-filter.mdwn | 26 ++ hurd/translator/examples.mdwn | 8 +- hurd/translator/exec.mdwn | 8 +- hurd/translator/ext2fs.mdwn | 63 +++++ hurd/translator/fifo.mdwn | 48 ++++ hurd/translator/hostmux.mdwn | 15 + hurd/translator/httpfs.mdwn | 100 +++++++ hurd/translator/nsmux.mdwn | 27 +- hurd/translator/pfinet.mdwn | 9 +- hurd/translator/pfinet/implementation.mdwn | 164 +++++++++++ hurd/translator/pflocal.mdwn | 28 +- hurd/translator/proc.mdwn | 22 ++ hurd/translator/procfs/jkoenig/discussion.mdwn | 10 + hurd/translator/ufs.mdwn | 38 +++ 20 files changed, 1229 insertions(+), 24 deletions(-) create mode 100644 hurd/translator/eth-filter.mdwn create mode 100644 hurd/translator/fifo.mdwn create mode 100644 hurd/translator/httpfs.mdwn create mode 100644 hurd/translator/ufs.mdwn (limited to 'hurd') 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 + + about rpctrace, it poses as the kernel for its children, parses + and relays any messages sent over the childrens message port, right? + teythoon: rpctrace doesn't "poses as the kernel" + well, it's close enough + 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? + yes + + # Issues and Patches [[!tag open_issue_hurd]] @@ -186,6 +197,34 @@ See `rpctrace --help` about how to use it. wish: make rpctrace decode the results of io_stat rpcs +* IRC, freenode, #hurd, 2013-07-29 + + imho rpctrace is kind of a mess right now :-/ we should move the + parsing code to a library + that would also be useful for valgrind, it should have to do + basically the same + +* IRC, freenode, #hurd, 2013-07-29 + + and I tried to rpctrace a subhurd, but rpctrace died on a + assertion failure, some msg had an unexpected type or something + rpctrace dies on select + and guess what, the boot tool does call select on the console it + emulates + that's a shame, that'd be really useful for me + it might not be hard to fix + but i've never looked into it :/ + i only saw that rpctrace expects the common RPC message types + and select is all but a common RPC + so the type of the messages involved is slightly different + and the assertion chokes on that + rpctrace.c is huge and hand written, it'd be nice if the parser + was created from the procedure definitions + and thinking of that, mig does exactly that, one would only need + some glue code + select is partially hand written + 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]] + + 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? + teythoon: "store code" ? + libstore + the hurd libstore ? + yes + hum, what paper ? + braunr: + http://users.student.lth.se/cs07fh9/2009-hammar-hurd-mobility.pdf + how nice + braunr: http://www.gnu.org/software/hurd/news/2010-01-31.html + it raises an important point btw, the authentication done by + processes on the Hurd is one sided, only the client authenticates at the + server + yes + 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. + 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 + + Hello, guys. Is there a way to know where partition starts on + hurd. E.g. given hd0s1 get "2048 sectors" + yes, it's the storeinfo RPC + let me find you a pointer + 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 ... + phcoder: Mmm, I guess you never got the userland-part.patch + upstream + ah, yes ,you did + I mean the find_hurd_root_device function + grub was previously using file_get_storage_info + youpi: find_hurd_root_Device/file_get_storage info is about + translating / -> /dev/hd0s1. Current problem is in step hd0s1 -> + hd0,msdos1 + yes, but iirc file_get_storage_info might work for hd0s1 itself + I see, let me try this + youpi: file_get_storage gives offset=0 size=partition size + (file_get_storage) damn + and name=hd0s1 + ah, that might be because we're still using in-kernel partition + table, instead of the parted partition table + looks like file_get_storage would be useful to get block size + though + 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? + 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 + I don't think there is any ioctl/RPC to get the kernel partition + table + youpi: is it using Linux partition code with some glue? + phcoder: the kernel partition table, yes + 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 + I know + that's why we want to migrate to the parted-based partition table + support + (which also brings us much better support than the old linux2.0 + code :) ) + youpi: I've looked into code and must say that I dislike what I + see: partitions handled in ide/ahci/sd/... + phcoder: which code? + youpi: gnumach + sure, that's not what we want in the end + grep -r start_sect + it's just the legacy linux way of doing partition support + Well Linux at least gives a meaningful ioctl + couldn't find any hint of it in gnumach + we didn't bother to add one since the parted way is supposed to be + what we have in the end + youpi: I can't make our code follow sth that might be the case in + the future + why not? + that's the way we will go + it's not just hypothetic + we just can't continue maintaining disk drivers in the kernel + so it won't be in the kernel + youpi: if I do then GRUB won't work on current GNU/Hurd anymore + can't you also keep the old code? + as a fallback when the proper way does not work (yet) + More hairs... :( + How do I check for it? offset == 0 isn't proper as partitions may + start at 0 + but checking than name still refers to partition is probably the + right way + I don't see what you mean + (about name) + youpi: I mean that we need a way to know that current code is + used and not future parted-based code + phcoder: I understand that for the offset ==0 thing + but I didn't understand the phrase you wrote just after that + 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 + ah, ok + yes, if the name is the same, it means it's not actually a + partition + youpi: current gnumach code makes fake devices out of partitions + yes + youpi: with settrans command you told, I get num_ints = 0 + phcoder: odd, I do get information, e.g.: + hurd:/tmp# settrans -c /tmp/mysd0s1 /hurd/storeio -T typed + part:1:device:sd0 + hurd:/tmp# storeinfo mysd0s1 + device (0x200): sd0: 512: 83905: 42959360: 63+83905 + storeinfo: myhd0s1: Operation not supported + do you actually have an hd0 device? + yes + youpi: I typed parted instead of part + Now it works + good :) + youpi: what is expected timeline on migration to part interface? + there's no real timeline + like everything, it'll happen when somebody actually looks at how + to achieve it + perhaps it'll be easy, perhaps not. IIRC there is still an issue + with the swapper + youpi: sounds like we're stuck will fallback code for at least + couple of years + possibly, entirely depends on people taking the task + 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 + 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 + youpi: and since we very rarely drop support this code is + probably stuck for good + as long as it's not used whenever we get to move to parted-based + partitioning, it's not too bad + 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: + + yay, I fixed the path of the dhcp leases file... + ... and now dhclient dies of a buffer overflow + fortunately the fix is rather simple, anyone who cares about + the security of his box just has to stop using isc software + the code is full of stuff like char foo[100]; /* surely + that's enough */ + 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) + so? + dunno, might have been fixed or not + ^^ yeah sure + A lot of software has these limitations and PATH_MAX, + MAXPATHLEN issues :( + having a limitation is not a problem per-se + no, only software written in c has these kind of problems + the problem is not checking whether the limits are hit + well, looking at the source of isc-dhcp my time is better + spent making another dhcp client work on hurd + also reading up on bug #616290 does make me want to avoid + touching it ever + hehe + teythoon: somebody was offering an alternative to the isc + dhcpclient, but I think it was rejected by Samuel? + why would he do that? + probably for compliance + He probably thought they would release a new version soon, is + 4.3.0 out yet? + well, as soon as my fixes for ifupdown go in, dhclient will + start crashing + no, there is no new version released + no major one that is + 4.2.5 is out + can't you just increase the buffer size, where is the problem + exactly? + I have no idea + The Hurd patches are not in 4.2.5, they were promised for + 4.3.0a1. + Still the buffer overflow problem might be present in 4.2.5 + if patched to build on Hurd. + there, darnassus now has a fully featured git/gitweb service + :) + btw, I managed to reproduce the crash reliably + rm /var/lib/dhcp/*; dhclient -v /dev/eth0 ... *boom* + ditch the -v, everything works, and now that there is a + lease file, you can add the -v again and it works + ew :) + and what has dhclient.c to say for its defense? + log_info("%s", ""); + hm, not much :/ + + IRC, freenode, #hurd, 2013-08-22: + + uh, the isc-dhcp situation is a huge pita, the source on + -ports does not compile anymore :/ + + IRC, freenode, #hurd, 2013-08-23: + + teythoon: Was it the slash in the network interface names + that caused the buffer overflow in dhclient? + gnu_srs: no, previously no dhcp leases file was written and + everything was fine + teythoon: did you really develop your patch against that old + version of ifupdown? + gnu_srs: now it is written, and for some reason dhclient + crashes *iff* -v is given *and* there is no previous lease file + pinotree: no, I did not. that was only reportbug including + information from my desktop machine without asking me + but when I first looked at ifupdown it was still a 6000 + lines noweb file >,< + that was fun + which version is it against? + hg tip + + IRC, freenode, #hurd, 2013-08-30: + + 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? + tschwinge: ah, most interesting, I didn't realize that you + stumbled across this as well + to be honest I don't know what's going on there, I only + observed what I wrote in my report + 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) + 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 + + Never dared to try a subhurd, any link to the howto? + 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 + gnu_srs: and you need a separate filesystem translator (i.e. not + /) for that + the easiest way is to add another virtual disk to you qemu setup + use the qemu image directly + simplest way to set up a subhurd + just change fstab from the host before the first boot to avoid + making the subhurd use the same hd0 drive as the host + 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 + + btw, is there a way to get dde-based networking into a subhurd? + the wiki instructions look like they're for the mach driver + and starting the dde translator inside the subhurd does not work + for me + that's probably a good thing though + the netdde process will need privileged access to mach + for hardware access + you can't easily use netdde from a subhurd, unless with a + different nic + i usually rebuild mach with in kernel devices so both the main and + subhurd can share on nic + one* + could a port to netdde perhaps forwarded to the subhurd? + zengh da wrote the eth-multiplexer for that iirc + it's a matter of making it appear as an eth0 device on the master + port aiui + zheng* + yes, I looked at that + what is the master port? + on a plain hurd system it's the port that privileged processes can + use to access mach devices + in a subhurd, it's the same for the subhurd, to access some devices + that you choose to give access to + its real name is the "device master port" + ah yes + + +#### IRC, freenode, #hurd, 2013-08-10 + + teythoon: use eth-multiplexer to use the NIC within a + subhurd. that's exactly what it was created for. + 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 + but I really don't see the reason to, when eth-multiplexer is + available + (IMHO running an eth-multiplexer on top of netdde should be the + default setup in fact) + 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 + (you will definitely need that for using netdde in a subhurd, + regardless whether through eth-multiplexer or directly) + + +#### IRC, freenode, #hurd, 2013-09-15 + + I wonder if we can modify the boot program so that it passes + ports from the mother hurd to the subhurd + so that we could pass in a port to the eth-multiplexer + or use like /hurd/remap as the root translator for the subhurd + eth-multiplexer was created exactly for that iirc, + so it's probably already done somewhere + + +#### IRC, freenode, #hurd, 2013-09-16 + + braunr: regarding subhurd did you mean to install + sthibault/hurd-i386/debian-hurd.img.tar.gz + on a separate partition and booting using the instructions for + subhurds on the web. + gnu_srs: yes + be careful that the subhurd doesn't use the same partition as the + main hurd, that's all + what about changing fstab? + 12:17 < braunr> be careful that the subhurd doesn't use the same + partition as the main hurd, that's all + gnu_srs: yes, you need to change the fstab + currently it is used for fscking stuff, so if it points to your + main partition it will cause severe corruption + gnu_srs: you also have to specify the right partition in the + servers.boot file + fstab of the subhurd image? + yes + how to unpack the .img file (just to be sure)? + gnu_srs: you don't need to, just use the img file as secondary + hard disk image + Then how should I be able to change fstab of the image? + boot your hurd box, mount the partition and change it + I missed something here: on my partition /my_chroot I have have + the file debian-hurd-20130504.img + 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 ... + That is the same as installing another cd image, where does the + subhurd come into play? + 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/, probably /dev/hd1s1 + BTW: unpacking was problematic: tar: debian-hurd-20130504.img: + Cannot seek to 2147696640 (2G limitations) + I wonder why you did this on your hurd system in the first + place... + I thought I could use that partition, /my_chroot as a chroot + place. So it won't work for subhurds? + 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 + braunr suggested an even easier way, download the .img file and + use it as secondary hard disk + you ended up doing kind of both + I tried once with debootstrap and that created a disaster... + how so? + The install errored out, and the whole filesystem (including /) + was left in a broken state. Maybe I tried + that without using a separate partition. Don't remember any + longer. So you say it's safe now? + I used it successfully to setup my subhurd + and you have your subhurd in a separate partition, installed from + there too, as root? + the web page only mentions crosshurd, and that failed for you? + yes, having a separate partition is (currently) necessary to run + a subhurd + yes, I used debootstrap as root, afaics that is necessary + and yes, as I said the other day, I tried crosshurd first and it + failed + then again, I fail to see any reason to use crosshurd these days + it's only a wrapper around debootstrap anyway, using it with + --foreign and fixing up stuff later + one has more control over the process if one uses debootstrap + directly + I still don't dare to do it yet. I'll create another image using + netinst with a separate partition and try out first. + When installing a new image using netinst.iso (2013-06-30) and + rebooting /proc does not get mounted? + gnu_srs: is that a statement or a question? + A statement. + it's not customary to end statements with question marks ;) + s/mounted?/mounted, why?/ + well, you seem to be the last person to perform such an + installation, so you are in the perfect position to answer this question. + cat /var/log/dmesg? + On other images I have: fsysopts /proc; /hurd/procfs + --clk-tck=100 --stat-mode=444 --fake-self=1 + gnu_srs: no, check the installation log + gnu_srs: and what does showtrans say? + showtrans /proc; + which log file to look for? + the installation log, somewhere in /var/log probably + I only find /proc in /var/log/installer/syslog, mainly printing + out errors not finding /proc/mounts + iirc the /proc translator should be set during the hurd package + configuration + you should probably look for that part in the log + 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. + that part + debootstrap: /hurd/procfs -c and in-target: /hurd/procfs -c No + errors + I don't understand what that means + please explain in more details + see: http://paste.debian.net/41195/ + makes much more sense :) + Where is the 'Setting up translators' done? I cannot find + anything in /var/lib/dpkg/info/hurd* or /etc/init.d/... + /usr/lib/hurd/setup-translators, called in hurd.postinst + tks:) + Hi, when installing a new image with debootstrap to /chroot the + script boot/servers.boot is already there (as well as in /boot/ + grub) + Is it OK to use that file to boot the subhurd? + using /boot/servers.boot or /chroot/boot/servers.boot (if the + /chroot partition is unmounted it cannot be used?) + and how to unmount /chroot: umount does not work? + 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) + I know I should issue settrans command, but I'm not yet fluent in + translators. + sorry:-/ + Now this, after a reboot: unknown code P 30 while trying to open + /dev/hd0s3 (/chroot) + Disk write protected: use the -n option to do a read-only check + of the device. + fsysopts /dev/&hd0s1 --writable: Operation not supported?? + OK, I'm giving up for now, no subhurd:-( and a broken install. + Which terminal to use in rescue mode, TERM is not set, + dumb,mach,hurd does not work with nano? + e2fsck /dev/ho0s3; e2fsck: Unknown code P 2 while trying to open + /dev/ho0s3; Possibly non-existent device? + mke2fs /dev/hd0s3; /dev/hd0s3 is not a block special device.; + Proceed anyway? (y,n) n: What's going on (hd0s3 not mounted)?? + anybody, help? + after removing and creating the partition again:mke2fs + /dev/hd0s3, , mke2fs: Unknown code P 13 while trying to determine + filesystem size: What's going on? + Where to find the glibc-2.13 versions which used to be at + debian-ports?. + seems they can be found on snapshot.debian.org + + +#### IRC, freenode, #hurd, 2013-09-17 + + teythoon: Installing subhurd via debootstrap on partition + /chroot fails miserably. Install hangs, and after reboot \rm -r + /chroot/* fails for dev and proc + Are there translators running there already? I have not + booted the subhurd. + translators for hd0s3 (/chroot) are storeio and + ex2fs.static. Do I have to stop them to be able to clean out + /chroot? + mount -v /chroot; settrans -a /chroot /hurd/ext2fs + /dev/hd0s3; + ext2fs: /dev/hd0s3: panic: main: device too small for + superblock (0 bytes); + mount: cannot start translator /hurd/ext2fs: Translator + died + Please, somebody! + don't ask to ask, just ask, right? + we've already told you everything you need + just get it right + for example, i told you to be careful about fstab so that + the subhurd wouldn't use the main hurd partition + but you managed to screw that + good job + I installed the subhurd in a partition /chroot /dev/hd0s3 + using debootstrap + i don't know deboostrap, it may be broken, use the disk + image youpi maintains + ant the install screwed up with debootstrap + ok; then I cannot use a partition, but another disk in + kvm, e.g. hdb? + gnu_srs: hd1 + something is fishy with glibc, definitely, that's why I'm + trying to set up a subhurd to revert to 2.13-39 + hi, when trying to boot a subhurd: /hurd/ext2fs.static: + hd0s3: Gratuitous error; bye + gnu_srs: why hd0s3 ? + it should be hd1s1 + I'm still using a separate partition /my_chroot + /hd0s3. Will switch to hd1 next. teythoon? + the servers.boot script use absolute + paths:/hurd/ext2fs.static and /lib/ld.so.1 /hurd/exec, + shouldn't they be relative to /my_chroot? + no + they're actually from your host + teythoon: please, how did you succeed to boot a subhurd + in a partition? + using debootstrap + gnu_srs: from my shell history: + : 1374672426:0;debootstrap sid /mnt + http://http.debian.net/debian/ + : 1374673020:0;cp /etc/hosts /etc/resolv.conf /mnt/etc + : 1374673048:0;cp /etc/passwd /etc/shadow /mnt/etc + teythoon: so it does work fine ? + great + yes, why wouldn't it? + gnu_srs: I then remounted that partition r/o and used + the servers.boot file from the wiki to boot it + braunr: why wouldn't it? (you do mean the debootstrap + part, don't you?) + teythoon: i don't know + i've heard it wasn't maintained any more + not being maintained is a good reason for something to + become unusable/untrustable with time + o_O it is at the heart of d-i, isn't it? + I actually do most Debian installations using + debootstrap directly + ah + ok :) + teythoon: even hurd ones ? + braunr: well, just the subhurd installation, but that + went as expected + good + Finally: I found the reason for Gratuitous error, I used + the /boot/servers.boot script, + that being different to the one on the wiki:-/ + Is it possible to copy files between a host hurd and + subhurd, what about access to eth0? + Hi, when starting the subhurd I see some warnings/error: + http://paste.debian.net/41963/ + 1) A spelling error execunable-> executable + 2) libports: invalid destination port + 3) mach-defpager: another already running + "execunable" is not a typo, but just "exec" and "unable + ..." without a space-type character + OK, sounds more plausible + Ah, the printouts are mixed, no bug + When setting up nework in the subhurd: /hurd/pfinet: + file_name_lookup /dev/eth0: Translator died + /hurd/pfinet: device_open(/dev/eth0): (os/device) no such + device + settrans: /hurd/pfinet: Translator died + + +#### IRC, freenode, #hurd, 2013-09-18 + + priority does not matter much + memory manager is not really surprising, there's indeed already one + what is actually the problem? + So these are merely warnings? + gnu_srs: yes + Real problems are I cannot set up networking, e.g. wget ...: + Connecting to ... failed: Address family not supported by protocol. + gnu_srs: did you give the subhurd a network card? + How? + and do I need to set up fstab, for now it's empty. + I just installed the base with dbootstrap + gnu_srs: -f option of boot + e2fsck will need fstab for sure + otherwise it can't divine what should be checked + 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. + it's not used at all + maybe better to put in the subhurd one there then, with a + comment? + no, since /boot/servers.boot is supposed to be used for machine + boot + not subhurd boot + what about putting a copy of the suhurd one there, with a + different name? + probably a good idea, yes + matter of making it happen + the wiki page on subhurd does not say how to set up networking, + only that you can do it. + matter of adding the information + I remember it's the -f option of boot + make it work, and add the information for others + I could try, but don't know how to add a network card to the + subhurd, and e.g. how to set up swap + see -f option + of boot? + "gnu_srs: -f option of boot" + if you could read what we write, that'd make things happen way + faster + yes I saw your comment above, it was just to be 100% sure:-D + device_file=/dev/eth0 or something else? + eth0 is used by the host already + did you read boot --help ? + iirc it's not a problem, both will receive all frames + yes I did + then I don't see where you took device_file from + at least in that form + --device=device_name=device_file + that means rather something like --device=foo=bar + so -f /dev/eth0 is correct usage then? + didn't you see that in what I wrote, there was a "=" in there? + -f is the short option, --device is the long, I don't see the + need for = in the short option? + in the long option there are *two* = + yes, but in the short no? + why not? + long -> short usually drops one = + to summarize: -f=/dev/eth0 or --device=eth_sub=/dev/eth0? + why shouldn't there be a eth_sub in the short version? + 10:15:49) youpi: long -> short usually drops one = + yes, it drops the = + but nothing else + if the long option needs some information, the short needs it too? + -? + correct now? -f eth_sub=/dev/eth0 or --device=eth_sub=/dev/eth0? + yes + 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]] + + ok, so as usual we actually *already* have a firewall + it's the eth-filter translator from zheng da + it has just never been really pushed forward... + good news :) + well, the bad news is that it probably doesn't support connection + tracking + since it's just bpf + using the libpcap syntax + well, a stateless fw should do for Debian/Hurds needs for now, + right? + yes + 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 -* httpfs translator +* [[httpfs]] translator @@ -28,7 +28,7 @@ or $ cd tmp/ $ ls -l -* ftpfs translator +* [[ftpfs]] translator @@ -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 -a -m -g -* Console translator -- setting up virtual consoles +* [[Console]] translator -- setting up virtual consoles $ console -d vga -d pc_mouse -d pc_kbd -d generic_speaker /dev/vcs -* iso9660fs translator -- 'mounting' your cdrom +* [[iso9660fs]] translator -- 'mounting' your cdrom 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 + + I always had some trouble with dropping a rebuild ext2fs.static + into my test system and I never figured out why + I just followed a hunch and stripped the binary, and all of the + sudden it works + any ideas why? + teythoon: I quick search found me: + and + . + tschwinge: ugh, thanks for the pointers ;) + teythoon: They won't help too much I fear. Anyway, good + intuition (or whatever) ;-) that you found this out. + 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, ), + 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 + boundary by stripped/unstripped), it'd segfault or not. Burnt + several days on that before Samuel (IIRC) eventually figured it out. + tschwinge: well, thanks anyway ;) + + +## Increased Memory Consumption + +### IRC, freenode, #hurd, 2013-09-18 + + ext2fs is using a ginormous amount of memory on darnassus since i + last updated the hurd package :/ + i wonder if my ext2fs large store patches rework have introduced a + regression + the order of magnitude here is around 1.5G virtual space :/ + it used to take up to 3 times less before that + looks like my patches didn't make it into the latest hurd package + teythoon: looks like there definitely is a new leak in ext2fs + :/ + memory only + the number of ports looks stable relative to file system usage + braunr: I tested my patches on my development machine, it's up + for 14 days (yay libvirt :) and never encountered problems like this + i've been building glibc to reach that state + hm, that's a heavy load indeed + could be the file name tracking stuff, I tried to make sure that + everything is freed, but I might have missed something + teythoon: simply running htop run shows a slight, regular increase + in physical memory usage in ext2fs + old procfs stikes again? :) + braunr: I see that as well... curious... + 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 + how knows, maybe completely unrelated + the tracking patch isn't that big, I've gone over it twice today + and it still seems reasonable to me + hm + + # Documentation * 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 + + seems fifos started dying, as they should. am i wrong? + ( http://bugs.debian.org/629184 ) + so you're saying the bug should be closed? + best to comment on the bug then + i didn't hear anyone working on it, so i'm a bit surprised + could be due to lower-level fixes to glibc or so + and given often(:|) i'm wrong, i was asking + in two years there have been various changes in glibc and hurd + (for example the switch to pthreads) + yeah seems fixed. mknod'ing one then removing it, doesn't leave any + process around + cool + then please follow-up on the bug and/or close it + sure + the pleasure of closing it/them is yours + 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 + gg0: wdym? + gg0: got an example? + http://bugs.debian.org/629184 + 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 **/ftp** is accessed, the first directory is interpreted as ho You can see the new created translator in the process list: **ps ax | grep ftpsfs** . You shoud see **/hurd/ftpfs / ftp.yourhost.com** . -- [[Main/PatrickStrasser]] - 13 Jul 2004 + + +# Open Issues + +## IRC, freenode, #hurd, 2013-09-21 + +[[!tag open_issue_hurd]] + + ls /http://:/ + the image came with a global translator though I see it doesn't + grokk the alternate port notation. + oh right + I shall return to the fine documentation + it's a hostmux, it doesn't understand ports + 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 + + + + +# Documentation + +## IRC, freenode, #hurd, 2013-09-03 + +[[!tag open_issue_documentation]] + + hi, why I can't cd to /http:/richtlijn.be/~larstiq/hurd/ to do + grep? + this is not ftp + it works for other file + ? + I can't cd to ~larstiq, I don't know why + http is not a filesystem protocol + while httpfs could try in representing it as such, it is not + something reliable + ok, it's not reliable + I expect it can expose dir like browser + so, the translator just know href from home page, and one by + one + uh? + if ...:80/a/b/c.png exits, but not has a href in homepage, so I + can't cd to a, right? + you are looking things from the wrong point of view + a web server can do anything with URLs, including redirecting, + URL rewriting and whatever else + so, how to understand httpfs's idea? + how httpfs list dir? + check its code + en, no need it's not reliable + it's not work, it's enough + I have an idea, for the file system, we explore dir level by + level, but for http, we change full path one + once time + 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 + once the file exits, mark all the parent directory as normal + color? + congzhang: you can find more info about httpfs here: + http://nongnu.org/hurdextras/ + congzhang: you're still looking at http from the wrong point of + view + there are no directories nor files + you start a request for a URL, and you get some content back (in + case there's no error) + you mean httpfs just for kidding? + 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 + congzhang: you can only get a list of files if the web server + responds with an index of files + "files" + The readme explains how httpfs does its thing: + http://cvs.savannah.gnu.org/viewvc/*checkout*/httpfs/README?root=hurdextras + if I can't cd to /http:/host/a/b how to get + /http:/host/a/b/c.html, even the file exist? + you don't cd in http + cd is for changing directory, which does not apply to a protocol + like http which is not fs-oriented + yes, I agree with you, http was not fs-oriented + so httpfs was not so useful + You can access the document directly, though, can't you? + rekado: I try once more + I can't + so, the httpfs need some extend, http protocol was not fs + oriented, so need some extend to make it work with file system + http is not designed for file system usage, so extending it is + useless + or, httpfs was not so useful + there are many other protocols for file systems + I don't think so + i do + if we can't make it more useful, remove it from hurd rep, or + extend it more useful + add some more rule, to make it work with file system + no + some paradox in it + which paradox? + for http vs file system + ??? + tree oriented and star topology oriented? + 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. oh http://jl-icase.home.comcast.net/~jl-icase/LinuxTCP2.html +## IRC, freenode, #hurd, 2013-09-03 + +In context of the item on [[/contributing]]. + + About this task: "Make pfinet OK with the ethernet device going + away." --- how can I test this? How can I remove the ethernet device? + settrans on the ethernet device, handled by the netdde + translator + that is, make it go away (settrans -fg) + Ah, I see. + Thanks + check its status before with showtrans + then, after having made it go away, set it again + 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. + How can I figure out which of the four network devices is actually + used? + rekado: the file system is used to open files, i.e. access + services + it's not used to revoke access + once pfinet has obtained a port to the network device, it keeps it + oh, yes, of course. Sorry, this is all very + new to me. + 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? + rekado: the idea is to make pfinet able to cope with a driver + crash + Can I trigger a driver crash for test purposes? (Or do I have to + build a purposefully broken driver first?) + use kill + Oh, good. + iirc, netdde doesn't restart correctly :x + you'll probably have to fix it a bit + i guess there is some persistent state that prevents it from + reinitializing correctly + okay + 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? + rekado: incubator branch + Okay. Thank you for your patience. I'll play with this in the + next few days. + enjoy + :) + + +### IRC, freenode, #hurd, 2013-09-05 + + When I kill the /hurd/netdde process I can no longer access the + network (as expected); + To restore connectivity I run "settrans -g eth0 /hurd/devnode -M + /dev/netdde eth0" from the /dev directory. + When I access the network again everything is fine. (I do see a + message telling me "irq handler 11: release an dead delivery port" + ) + Is it the goal to avoid having to run settrans again to run netdde + after it crashes or is killed? + you don't need to run settrans again + that should get triggered automatically + Hmm, after killing netdde I get "Resource lost" when using wget. + It doesn't seem to be restarted automatically. + try again + the first wget makes pfinet try to use netdde and fail, thus crash + the second wil respawn pfinet + ideally pfinet shouldn't die, that's a TODO mentioned in the + "contributing page" + Ah, so that's what should be prevented. + it's just a matter of making pfinet be fine with errors from the + eth translator, and simply reopen it instead of dying + That's the thing I've been trying to figure out. + when I run wget a second (or third) time I get a different error; + "Name or service not known." + It's only okay again when I use settrans + maybe the devnode translator also needs some fixing + it's odd that I don't have the issue though + I'm using the qemu image, updated just yesterday. + same here + anyway, now you know where to put your hands :) + yes, thanks a lot. + + +### IRC, freenode, #hurd, 2013-09-07 + + in pfinet/ethernet.c:ethernet_open there's an assertion: + edev->ether_port == MACH_PORT_NULL + This is violated when netdde was killed and the device is + reopened. + I'm not sure what should be done: destroy the port before + reopening or drop the assertion? + If I drop the assertion, Mach seems to handle this just fine. + Says "irq handler 11: release an [sic] dead delivery port" and + then carries on without problems. + Is this a warning or an error, or can this be ignored? + (or none of the above?) + + +### IRC, freenode, #hurd, 2013-09-08 + + 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. + It doesn't work, though, when only netdde has been killed. + With devnode still around device_open fails with "(ipc/send) + invalid destination port" + I don't know where device_open is defined and why this error is + returned. + I guess the error refers to the "master_device" port returned by + file_name_lookup() in ethernet_open() + Why would file_name_lookup() return an invalid port when netdde is + dead but devnode is still running? + rekado: maybe because devnode needs to perform a fresh lookup as + well + + +### IRC, freenode, #hurd, 2013-09-09 + + braunr: re devnode: devnode only performs a single lookup in + parse_opt(), i.e. at start-up. + I'll try to understand devnode enough to patch it. + rekado: that's the problem + 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"]]. + + I submitted two patches to the mailing list. I've tested them on + Debian GNU/Hurd but based them on the incubator/dde branch. + rekado: awesome, reliability fixes are very much welcome + + +### IRC, freenode, #hurd, 2013-09-18 + + youpi: my apologies for the delay in getting back to you with + improvements to my pfinet/devnode patches. Been very busy. + 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 + + what command will show me the MAC address of an interface? + ah, too bad inetutils-ifconfig doesn't seem to be showing it + I don't think we already have a tool for that + it would be a matter of patching inetutils-ifconfig + + +## Routing Tables + +[[!tag open_issue_hurd]] + + +### IRC, freenode, #hurd, 2013-09-21 + + 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? + I don't think there is a tool for that yet + 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 + + Hi, is SO_REUSEADDR supported at all on Hurd? I can only find two + entries: + in libdde-linux26 and pfinet/linux-src, and the functionality + seems to be unimplemented. + gnu_srs: pfinet supports it + gnu_srs: grep talks about pfinet/linux-src/net/core/sock.c: + case SO_REUSEADDR: + two times + Yes, and that is the implementation? + I wrote a test for AF_INET and it works, but not for AF_UNIX + (maybe not so interesting case). + pflocal does not support it + 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 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 + + 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 + so it appears in top and friends + braunr: noted, that should be easy + 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]]."]]"""]] it "just" needs to be commited :) 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 + + teythoon: should procfs now have $pid/mounts files pointing to + ../mounts? + 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]] + + There might be a copyright problem: well, there seems + BSD-4clauses in the code: + http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/ufs/alloc.c + braunr, tschwinge: Do you have any info on that? 4-clause BSD and + GPL on the same code are a license incompatibility… + Arne`: I've put it onto my (long) TODO list. + Easiest solution might be: rm -rf ufs. + will these affected code rewritten? or just modify license? + only the regents of the University of California could choose + to modify the license. + nalaginrut: one can't modify a licence if one is not the author + we can simply dump the code + s/author/owner/ + 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. + tschwinge: or maybe extract the ufs stuff in an own repo, to be + imported as branch in incubator or own hurd/ufs.git? + Sure, why not. -- cgit v1.2.3