diff options
86 files changed, 2210 insertions, 106 deletions
diff --git a/community.mdwn b/community.mdwn index 101e15a8..9443f123 100644 --- a/community.mdwn +++ b/community.mdwn @@ -36,6 +36,8 @@ Further ways of getting in contact or getting information: [Advogato.org -- Hurd Project page](http://advogato.org/proj/HURD/) +[[Media_Appearances]] + --- # Hurd User Groups @@ -48,3 +50,8 @@ Further ways of getting in contact or getting information: * [Hurdfr.org](http://www.hurdfr.org/) * [HurdIt](http://hurd-it.sf.net/) * [HurdUk](http://uwhug.org.uk/) + +# Other Community Pages + + * [GNU Hurd Sverige](http://hurd.mtb-tech.se/) -- A Swedish website + about the GNU Hurd diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn index 570a9581..0618bbe6 100644 --- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn +++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 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 @@ -27,6 +28,8 @@ implementing unit checks in other parts of the Hurd codebase...) issues; but it wouldn't document the work in terms of actual code produced, and thus it's not suitable for a GSoC project...) +[Linux' *sparse*](https://sparse.wiki.kernel.org/) could be worth looking at. + This task requires experience with debugging locking issues in multithreaded applications. diff --git a/community/gsoc/project_ideas/pthreads.mdwn b/community/gsoc/project_ideas/pthreads.mdwn index 61c8c079..a33187f6 100644 --- a/community/gsoc/project_ideas/pthreads.mdwn +++ b/community/gsoc/project_ideas/pthreads.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 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 @@ -10,7 +11,7 @@ is included in the section entitled [[!meta title="Convert Hurd Libraries and Servers to pthreads"]] -[[!tag open_issue_pthread]] +[[!tag open_issue_libpthread]] The Hurd was originally created at a time when the [pthreads standard](http://www.opengroup.org/onlinepubs/009695399/basedefs/pthread.h.html) diff --git a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn index ff169b0a..6f0af07e 100644 --- a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn +++ b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn @@ -94,16 +94,16 @@ sounds like an interesting option.*" *"While I believe this can be applied to any kind of applications, I'm personally most interested in more efficient and powerful desktop environments -- these considerations are in fact what got me seriously -interested in the Hurd. +interested in the Hurd.* -Even more specifically, I've done most considerations (though by far not +*Even more specifically, I've done most considerations (though by far not all) on modular web browsing environments. Those interested can read up -some of my thoughts on this: +some of my thoughts on this:* http://sourceforge.net/mailarchive/message.php?msg_name=20080909073154.GB821%40alien.local -(Just skip the text mode browsing stuff -- the relevant part is the long +*(Just skip the text mode browsing stuff -- the relevant part is the long monologue at the end... I really should put these ideas into my blog.)"* @@ -127,7 +127,15 @@ or even: * cp ftp://foo/bar/ogg play -that's KDEs fabled network transparency on the filesystem / shell level. +that's KDEs fabled network transparency on the filesystem / shell level (where it belongs to be desktop agnostic). + +* add temporary filesystems anywhere via `settrans -a NODE /hurd/ext2fs` + +* make everything temporarily writeable without really changing it via [[hurd/translator/unionfs]]. + +* Read tar archives and mbox files via `ls foo.tar.gz,,tarfs` and `ls foo.mbox,,mboxfs`, respectively → [[hurd/translator/nsmux]]. + +* Use stuff like the new akonady (personal information) framework in KDE more efficiently from the shell. Reality check diff --git a/contributing.mdwn b/contributing.mdwn index 12be38aa..3a713520 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010 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 @@ -46,8 +46,7 @@ meant when people are talking about GNU/Hurd systems. This system has mostly been designed and implemented [[in the '90s|history]]. It works and is usable. -For example, these web pages are rendered on a [GNU/Hurd -system](http://www.bddebian.com/cgi-bin/uptime). +For example, these web pages have been rendered on a GNU/Hurd system. You can try it out for yourself: for getting access, installing [[Debian_GNU/Hurd|hurd/running/debian]] will probably be the easiest and most diff --git a/documentation.mdwn b/documentation.mdwn index 8559eff1..d96cb24b 100644 --- a/documentation.mdwn +++ b/documentation.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2010 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 @@ -17,8 +17,6 @@ Documentation for... * [[MIG|microkernel/mach/mig/documentation]] -# [[Unix]] Programming +# General - * *The C Programming Language* by Brian W. Kernighan and Dennis M. Ritchie, - [order from - Amazon](http://www.amazon.com/Programming-Language-Prentice-Hall-Software/dp/0131103628/ref=pd_bxgy_b_img_a) + * [[Media_Appearances]] @@ -93,7 +93,9 @@ in the *unstable* branch of the Debian archive. * [[libstore]] * [[libchannel]] * [[libhello_example]] -- Hurd library example + * [[libtrivfs]] * [[libnetfs]] -- short introductory material + * [[libihash]] * [[IO_Path]] * [[Porting]] * [[Debugging]] diff --git a/hurd/advantages.mdwn b/hurd/advantages.mdwn index a181a942..ba3a134b 100644 --- a/hurd/advantages.mdwn +++ b/hurd/advantages.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2001, 2002, 2008 Free Software Foundation, +[[!meta copyright="Copyright © 2001, 2002, 2008, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -58,3 +58,11 @@ but it does have a number of enticing features: The Hurd is real software that works Right Now. It is not a research project or a proposal. You don't have to wait at all before you can start using and developing it. + +--- + +One advantage of the Hurd's separation of kernel-like functionality into +separate components ([[servers|translator]]) is that these can be constructed +using different programming lanugages, a thing that is not easily possible in a +monolithic kernel. Essentially, only an interface from the programming +environment to the RPC mechanism is required. diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index 46f40508..de46c08d 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -18,6 +18,8 @@ See `rpctrace --help` about how to use it. # Issues and Patches +[[!tag open_issue_hurd]] + * <http://savannah.gnu.org/patch/?2104> -- don't assert that local port names are valid * <http://savannah.gnu.org/bugs/?3939> -- `rpctrace`d program hangs when signal @@ -26,10 +28,26 @@ See `rpctrace --help` about how to use it. programs hang * <http://savannah.gnu.org/patch/?5580> -- more readable output +* IRC, unknown channel, unknown date + + <youpi> how to rpctrace a translator ? + <youpi> ah, just settrans /usr/bin/rpctrace... + <youpi> hum, it hung, and killing it got a Mach panic (thread in unexpected + state) ... + +* IRC, unknown channel, unknown date + + <antrik> hm... for a funny effect, try running rpctrace on + /servers/socket/1, and then use dpkg... ;-) -# TODO +* IRC, unknown channel, unknown date. - <youpi> how to rpctrace a translator ? - <youpi> ah, just settrans /usr/bin/rpctrace... - <youpi> hum, it hung, and killing it got a Mach panic (thread in unexpected - state) ... + <youpi> the problem of rpctrace is that it's a man in the middle :) + <youpi> so in principle, by design authentication stuff shouldn't work + <antrik> I don't think the Hurd auth mechanism in any way prevents or tries to prevent man-in-the-middle... + <youpi> maybe, but just try, you'll see all kinds of issue as soon as you have authentication stuff + <youpi> and the basic reason is that being a man in the middle needs special care + <youpi> which rpctrace doesn't completely do + <antrik> it's a while since I have dived into rpctrace; but AIUI, it should work just fine if the proxying is done properly + <antrik> note that there is a number of known bugs in rpctrace, for which zhengda has sent patches... though I haven't reviewed all of them I think + <antrik> there are some nasty Mach operations that are really hard to proxy -- but I don't think the auth mechanism needs any of these... diff --git a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn index 1e8c4ef6..b7cfc3c9 100644 --- a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn +++ b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 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 +34,4 @@ using the appropriate glibc magic (`setvbuf`). Otherwise you'll see text in the output files only if either glibc herself decides to flush (after some KiB of text) the after translator exits. -It is a [[!taglink open_issue_hurd]] to decide / implement / fix that -(all?) running (passive?) translators' output should show up on the -console / syslog. +There is also a [[related open issue|open_issues/translator_stdout_stderr]]. diff --git a/hurd/libfshelp.mdwn b/hurd/libfshelp.mdwn new file mode 100644 index 00000000..4eda91b6 --- /dev/null +++ b/hurd/libfshelp.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +TODO. + + +# Open Issues + +[[!tag open_issue_hurd]] + + * IRC, unknown channel, unknown date + + <flavioc> antrik, i had some problems with CLISP. it goes into an infinite loop when there's no stdin or stdout (fshelp closes them when a translator starts). At first I tried to patch it but CLISP has very intricate dependencies on them, so I just created a wraper program (run-lisp-trans) that opens /dev/null as stdin and stdout and then exec's clisp + <marcus> flavioc, antrik: I would suggest to modify libfshelp to start translators with stdin/stdout mapped to /dev/null. + <marcus> or is there a good reason not to? + <flavioc> marcus, the problem is in clisp :-), it should not expect that stdin/stdout are always open + <marcus> flavioc: I agree, but there is really no point in making it hard. many programs will fail if stdin, stdout or stderr are not occupied. historically, they expect them to be there, so IMO libfshelp should be changed + <marcus> flavioc: it's a simple solution, works everywhere and shouldn't do any harm :) + <flavioc> marcus, I see. should I propose that on the mailing list? :-) + <marcus> flavioc: it might be simpler to just crack the svn server and sneak it in :) + <marcus> if you submit a patch I will look at it and check it in if it is ok + <marcus> and see if Roland is still watching ... :D diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn new file mode 100644 index 00000000..770770c7 --- /dev/null +++ b/hurd/libihash.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU_Free_Documentation_License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + + * Hurd libihash + + * old + + * new + + * hurd-l4 libhurd-ihash + + * [[viengoos libhurd-ihash|microkernel/viengoos/projects/new_hash_function]] + + IRC, unknown channel, unknown date + + <neal> so, we need a new ihash implementation + <neal> marcusb: When 80% full, the collision rate is very high. + <neal> marcusb: I tested using 512mb / 4096 entries + <neal> marcusb: Changing the load factor to 30% resulted in my program running more than an order of magnitude faster. + <marcusb> yeah, it shouldn't get so full + <marcusb> don't we do an exponential back-off in the array size? + <marcusb> of course it's clear we can do much better + <marcusb> the ihash algo is very simple + <marcusb> I'm not even sure it makes much sense to have a generic library + + +# Alternatives? + + * glibc + + * include/inline-hashtab.h + + * locale/programs/simple-hash.h + + * misc/hsearch_r.c + + * NNS; cf. f46f0abfee5a2b34451708f2462a1c3b1701facd + + * <http://cmph.sourceforge.net/> + + * <http://libhashish.sourceforge.net/> + + * <http://www.azillionmonkeys.com/qed/hash.html> diff --git a/hurd/libnetfs.mdwn b/hurd/libnetfs.mdwn index a2bf47ee..8625f8bc 100644 --- a/hurd/libnetfs.mdwn +++ b/hurd/libnetfs.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 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,7 +34,7 @@ which is, generally speaking, seriously different from *libnetfs*. All in all, *libnetfs* is the library you would choose when you want to write a translator which will show a file (or a directory) in a modified way (for example, if you'd like to show only *.sh* files or -make an archive look unpacked). As different from *libtrivfs*, using +make an archive look unpacked). As different from *[[libtrivfs]]*, using *libnetfs*, you can show to your clients not just a single file, but a whole directory tree. @@ -229,7 +230,7 @@ performance or to solve specific problems. ##Synchronization is Crucial A *libnetfs* programmer shall always keep in mind that, as different -from *libtrivfs*-based translators, *libnetfs*-based translators are +from *[[libtrivfs]]*-based translators, *libnetfs*-based translators are always multithreaded. To guard data against damage each node incorporates a lock. Moreover, each light node usually contains a lock, too. This happens because *libnetfs* nodes and light nodes are diff --git a/hurd/libports.mdwn b/hurd/libports.mdwn index f9aa518f..28274338 100644 --- a/hurd/libports.mdwn +++ b/hurd/libports.mdwn @@ -14,3 +14,7 @@ ports|microkernel/mach/port]]. It is documented in the [[Reference_Manual]]. *libports* is not (at least, not for now) a generalization / abstraction of Mach ports to the functionality the Hurd needs, that is, it is not meant to provide an interface independently of the underlying [[microkernel]]. + +*libports* does not itself depend on *[[libthreads]]*, but the appropriate +threading hooks are used if present, that is if *[[libthreads]]* is used by +another component. diff --git a/hurd/libtrivfs.mdwn b/hurd/libtrivfs.mdwn new file mode 100644 index 00000000..b15aeabe --- /dev/null +++ b/hurd/libtrivfs.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 1994, 1996, 1998, 1999, 2000, 2001, 2002, 2003, +2004, 2005, 2007, 2008, 2009, 2010 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]]."]]"""]] + +Certain [[translator]]s do not need to be very complex, because they represent +a single file rather than an entire directory hierarchy. The *trivfs library*, +which is declared in `<hurd/trivfs.h>`, does most of the work of implementing +this kind of translator. This library requires the [[iohelp|libiohelp]] and +[[ports|libports]] libraries. + +Using `libtrivfs` is not the only way to implement such a single-file +translator, but is a convenient abstraction: the library hides a lot of +low-level stuff and you just have to provide a number of call-back functions +and symbols in order to get a functioning (for file I/O, etc.) node in the file +system. + + +# Further Reading + + * In the *[[The_GNU_Hurd_Reference_Manual|reference_manual]]*: + <http://www.gnu.org/software/hurd/doc/hurd_6.html#SEC48>. + + * In the *[[Hurd_Hacking_Guide]]*: + <http://www.gnu.org/software/hurd/hacking-guide/hhg.html#An-Example-using-trivfs>. diff --git a/hurd/running/arch_hurd.mdwn b/hurd/running/arch_hurd.mdwn index 6635f415..cc2ad0f2 100644 --- a/hurd/running/arch_hurd.mdwn +++ b/hurd/running/arch_hurd.mdwn @@ -11,3 +11,13 @@ License|/fdl]]."]]"""]] [[!meta title="Arch Hurd"]] <http://www.archhurd.org/> + +From the website: + +*Welcome to the Arch Hurd website. Arch Hurd is a derivative work of Arch Linux porting it to the GNU Hurd system with packages optimised for the i686 architecture.* +*…* +*We are attempting to bring the spirit of Arch Linux to the Hurd, and if you'd like to help us achieve that, we'd love to hear from you.* + +Status as of 2010-07-31: + +* LiveCD with [installation guide](http://wiki.archhurd.org/wiki/Installation_Guide). diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index 92904d19..c197ad0e 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -4,6 +4,7 @@ Working distributions of GNU/Hurd: GNU/Hurd distributions in early stages of development: +* [[Arch|arch_hurd]] (features a LiveCD) * [[Gentoo]] * [[GNU]] diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index 44ba4dff..75020cb2 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -18,6 +18,12 @@ and [[pfinet]]) and thus translates object invocations into calls appropriate for the backing store (e.g., ext2 file system, nfs server, etc.). +Another way of putting it is that it translates from one representation of a +data structure into another representation, for example from the on-disk +[[ext2|ext2fs]] data layout to a traditional file system hierarchy, or from a +XML file to a virtual hierarchical manifestation. This translation can be a +bidirectional process, but it need not be. + A translator is usually registered with a specific file system node by using the [[`settrans`|settrans]] command. @@ -108,3 +114,28 @@ Read about translator [[short-circuiting]]. * [[wishlist_1]] * [[wishlist_2]] + + +# Internally + +## `*_demuxer` Functions + + * IRC, unknown channel, unknown date + + <jim-crow> what is a main idea of _demuxer functions in translators? + <neal> jim-crow: Think of a web server. + <neal> jim-crow: A typical web server must process many different requests. + <neal> jim-crow: There are different types of requests. + <neal> jim-crow: For instance, static pages and dynamically gnereated content. + <neal> the static pages are processed by one function + <neal> and the dynamic pages by another + <neal> the thing that makes the decision which of these functions to pass the request to is the demuxer. + <jim-crow> neal: ok, I see + <jim-crow> but what is actually it doing in trivfs_demuxer? + <neal> it looks at the message id and calls the right server stub + <jim-crow> for example it calls trivfs_io_server function, but I can't find its implementation + <jim-crow> that's my main question :-) + <neal> look at the files mig generates + <jim-crow> neal: ok, thanks + <jim-crow> neal: is this functions where actually stubs are called? + <neal> I think so. diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index 441fb00f..69d035db 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 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 @@ -8,11 +9,20 @@ 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]]."]]"""]] +# Issues + The `ext2fs` translator from the upstream Hurd code base can only handle file systems with sizes of less than roughly 2 GiB. +[[!tag open_issue_hurd]] + A patch exists to lift this limitation (and is being used in the [[Debian_GNU/Hurd_distribution|running/debian]]), but it introduces another incompatibility: `ext2fs` then only supports block sizes of 4096 bytes. Smaller block sizes are commonly automatically selected by `mke2fs` when using small backend stores, like floppy devices. + + +# Documentation + +<http://www.nongnu.org/ext2-doc/> diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn index 996ffd6d..5afee0c6 100644 --- a/hurd/translator/pfinet/ipv6.mdwn +++ b/hurd/translator/pfinet/ipv6.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 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 @@ -51,10 +52,6 @@ Quite the same, but with static IPv6 address assignment: -A 2001:4b88:10e4:0:216:3eff:feff:4223/64 -G 2001:4b88:10e4::1 -# Binaries +# Missing Functionality -For your convenience -- this work is not yet available in the Debian packages --- binaries of a patched (multicast reception) GNU Mach kernel (including -default driver set and debugging support) and a stripped pfinet translator -(named `pfinet6` here) are being provided at -<http://brokenpipe.de/GnuHurd/pfinet6/> +Amongst other things, support for [[IOCTL]]s is missing. diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn new file mode 100644 index 00000000..ef041a23 --- /dev/null +++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn @@ -0,0 +1,73 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +\#hurd, freenode, 2010 + + <slpz> humm... why does tmpfs try to use the default pager? that's a bad idea, and probably will never work correctly... + * slpz is thinking about old issues + <slpz> tmpfs should create its own pagers, just like ext2fs, storeio... + <slpz> slopez@slp-hurd:~$ settrans -a tmp /hurd/tmpfs 10M + <slpz> slopez@slp-hurd:~$ echo "foo" > tmp/bar + <slpz> slopez@slp-hurd:~$ cat tmp/bar + <slpz> foo + <slpz> slopez@slp-hurd:~$ + <slpz> :-) + <pochu> slpz: woo you fixed it? + <slpz> pochu: well, it's WIP, but reading/writing works... + <slpz> I've replaced the use of default pager for the standard pager creation mechanism + <antrik> slpz: err... how is it supposed to use swap space if not using the default pager? + <antrik> slpz: or do you mean that it should act as a proxy, just allocating anonymous memory (backed by the default pager) itself? + <youpi> antrik: the kernel uses the default pager if the application pager isn't responsive enough + <slpz> antrik: it will just create memory objects and provide zerofilled pages when requested by the kernel (after a page fault) + <antrik> youpi: that makes sense I guess... but how is that relevant to the question at hand?... + <slpz> antrik: memory objects will contain the data by themselves + <slpz> antrik: as youpi said, when memory is scarce, GNU Mach will start paging out data from memory objects to the default pager + <slpz> antrik: that's the way in which pages will get into swap space + <slpz> (if needed) + <youpi> the thing being that the tmpfs pager has a chance to select pages he doesn't care any more about + <antrik> slpz: well, the point is that instead of writing the pages to a backing store, tmpfs will just keep them in anonymous memory, and let the default pager write them out when there is pressure, right? + <antrik> youpi: no idea what you are talking about. apparently I still don't really understand this stuff :-( + <youpi> ah, but tmpfs doesn't have pages he doesn't care about, does it? + <slpz> antrik: yes, but the term "anonymous memory" could be a bit confusing. + <slpz> antrik: in GNU Mach, anonymous memory is backed by a memory object without a pager. In tmpfs, nodes will be allocated in memory objects, and the pager for those memory objects will be tmpfs itself + <antrik> slpz: hm... I thought anynymous memory is backed by memory objects created from the default pager? + <antrik> yes, I understand that tmpfs is supposed to be the pager for the objects it provides. they are obviously not anonymoust -- they have inodes in the tmpfs name space + <antrik> but my understanding so far was that when Mach returns pages to the pager, they end up in anonymous memory allocated to the pager process; and then this pager is responsible for writing them back to the actual backing store + <antrik> am I totally off there?... + <antrik> (i.e. in my understanding the returned pages do not reside in the actual memory object the pager provides, but in an anonymous memory object) + <slpz> antrik: you're right. The trick here is, when does Mach return the pages? + <slpz> antrik: if we set the attribute "can_persist" in a memory object, Mach will keep it until object cache is full or memory is scarce + <slpz> or we change the attributes so it can no longer persist, of course + <slpz> without a backing store, if Mach starts sending us pages to be written, we're in trouble + <slpz> so we must do something about it. One option, could be creating another pager and copying the contents between objects. + <antrik> another pager? not sure what you mean + <antrik> BTW, you didn't really say why we can't use the default pager for tmpfs objects :-) + <slpz> well, there're two problems when using the default pager as backing store for translators + <slpz> 1) Mach relies on it to do swapping tasks, so meddling with it is not a good idea + <slpz> 2) There're problems with seqnos when trying to work with the default pager from tasks other the kernel itself + <slpz> (probably, the latter could be fixed) + <slpz> antrik: pager's terminology is a bit confusing. One can also say creating another memory object (though the function in libpager is "pager_create") + <antrik> not sure why "meddling" with it would be a problem... + <antrik> and yeah, I was vaguely aware that there is some seqno problem with tmpfs... though so far I didn't really understand what it was about :-) + <antrik> makes sense now + <antrik> anyways, AIUI now you are trying to come up with a mechanism where the default pager is not used for tmpfs objects directly, but without making it inefficient? + <antrik> slpz: still don't understand what you mean by creating another memory object/pager... + <antrik> (and yeat, the terminology is pretty mixed up even in Mach itself) + <slpz> antrik: I meant creating another pager, in terms of calling again to libpager's pager_create + <antrik> slpz: well, I understand what "create another pager" means... I just don't understand what this other pager would be, when you would create it, and what for... + <slpz> antrik: oh, ok, sorry + <slpz> antrik: creating another pager it's just a trick to avoid losing information when Mach's objects cache is full, and it decides to purge one of our objects + <slpz> anyway, IMHO object caching mechanism is obsolete and should be replaced + <slpz> I'm writting a comment to bug #28730 which says something about this + <slpz> antrik: just one more thing :-) + <slpz> if you look at the code, for most time of their lives, anonymous memory objects don't have a pager + <slpz> not even the default one + <slpz> only the pageout thread, when the system is running really low on memory, gives them a reference to the default pager by calling vm_object_pager_create + <slpz> this is not really important, but worth noting ;-) diff --git a/media_appearances.mdwn b/media_appearances.mdwn new file mode 100644 index 00000000..4311f08b --- /dev/null +++ b/media_appearances.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +This is a collection of Hurd-related media appearances. + + * Marcus Brinkmann, *The GNU Hurd - Lessons and Perspective*, from the + [OpenWeekend](http://openweekend.cz/) 2004 conference organized by the + Silicon Hill club. + <http://video.google.com/videoplay?docid=-7449462856350014702> diff --git a/microkernel/mach/documentation.mdwn b/microkernel/mach/documentation.mdwn index 926a2cba..fc6e59c2 100644 --- a/microkernel/mach/documentation.mdwn +++ b/microkernel/mach/documentation.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, +2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -9,8 +9,9 @@ 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]]."]]"""]] - - [Meet Mach](http://www.stepwise.com/Articles/Technical/MeetMach.html), a - summary of Mach's history and main concepts. + * [*Meet Mach* by James + Scott](http://beefchunk.com/documentation/macosx-programming/Meet_Mach.pdf), + a summary of Mach's history and main concepts. * *[[The_GNU_Mach_Reference_Manual|gnumach/reference_manual]]*. diff --git a/microkernel/viengoos/projects/new_hash_function.mdwn b/microkernel/viengoos/projects/new_hash_function.mdwn index 1747511d..d0374720 100644 --- a/microkernel/viengoos/projects/new_hash_function.mdwn +++ b/microkernel/viengoos/projects/new_hash_function.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 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 @@ -17,3 +18,5 @@ overhead. Find a better algorithm. There can either be one that is appropriate in the general case or one that works well in a relevant, specific case, e.g., viengoos/object.c uses a hash to find the object corresponding to a frame, which is keyed on its physical address. + +Note that this applies to the Hurd's [[hurd/libihash]], too. diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn b/open_issues/automatic_backtraces_when_assertions_hit.mdwn new file mode 100644 index 00000000..1cfacaf5 --- /dev/null +++ b/open_issues/automatic_backtraces_when_assertions_hit.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <azeem> tschwinge: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion `! __spin_lock_locked (&ss->critical_section_lock)' failed. + <youpi> it'd be great if we could have backtraces in such case + <youpi> at least just the function names + <youpi> and in this case (static), just addresses would be enough diff --git a/open_issues/automatically_checking_port_deallocation.mdwn b/open_issues/automatically_checking_port_deallocation.mdwn new file mode 100644 index 00000000..fb8cfd01 --- /dev/null +++ b/open_issues/automatically_checking_port_deallocation.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date. + + <youpi> we really need something that is able to automatically check port deallocation + <youpi> at least for the trivial cases, for which we do have bugs I'm currently fixing... + <pochu> test suite? :) + <pochu> won't magically find them though, so not what you've asked for... + <youpi> test suites can trigger some of the bugs yes + <youpi> which is already a good thing + <youpi> of course the coverage can't be perfect + <youpi> one of the bugs I fixed happened only for setuid binaries for instance diff --git a/open_issues/bash_interrupted_system_call.mdwn b/open_issues/bash_interrupted_system_call.mdwn new file mode 100644 index 00000000..9feab6ff --- /dev/null +++ b/open_issues/bash_interrupted_system_call.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 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, unknown channel, unknown date. + + <virtuoso015> i seem to be getting this message from the shell "-bash: /dev/fd/62: Interrupted system call" + <virtuoso015> is it significant ? + <youpi> I've seen this issue already yes + <youpi> it's not + <youpi> it's bash not handling EINTR properly + <antrik> youpi: so this is actually a bug in bash, not Hurd generating a bogus error? + <youpi> well, it's Hurd generating an error which bash doesn't expect to see diff --git a/open_issues/chroot_difference_from_linux.mdwn b/open_issues/chroot_difference_from_linux.mdwn new file mode 100644 index 00000000..f2009bd8 --- /dev/null +++ b/open_issues/chroot_difference_from_linux.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +\#hurd, freenode, 2010 + + <cfhammar> weird, even fd = open("/"), chroot("/tmp/chroot"), openat(fd, "/tmp/chroot/..) opens /tmp/chroot in linux + <pochu> cfhammar: isn't that expected? + <cfhammar> pochu: well, i didn't expect it :-) + <cfhammar> pochu: in hurd, /tmp gets opened, which i think is more natural + <pochu> cfhammar: oh right, didn't notice the ".." :-) diff --git a/open_issues/debootstrap.mdwn b/open_issues/debootstrap.mdwn new file mode 100644 index 00000000..8e6c4900 --- /dev/null +++ b/open_issues/debootstrap.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +\#hurd, freenode, 2010 + + <azeem_> you know, you would really help the Hurd if you tried debootstrap instead + <tschwinge> Oh? Does that have everying in place by now? + <azeem_> applying the patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498731#25 + <azeem_> they are waiting for feedbacl + <azeem_> feedback* + +\#hurd, freenode, June (?) 2010 + + <azeem_> jd823592: if you want to use debootstrap, you should apply a patch + <azeem_> and test + <azeem_> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=debootstrap_hurd.patch;att=1;bug=498731 + <azeem_> we desperately need somebody to test the patch diff --git a/open_issues/dir-lookup_authority.mdwn b/open_issues/dir-lookup_authority.mdwn new file mode 100644 index 00000000..64866eb5 --- /dev/null +++ b/open_issues/dir-lookup_authority.mdwn @@ -0,0 +1,68 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <cfhammar> I have discovered a bug in the dir-lookup protocol though + <cfhammar> Currently, I'm investigating the bug a bit further + <cfhammar> when doing dir-lookups with several path components, the look-up is done with the authority of the user who opened the directory, as opposed to the user doing the lookup + <cfhammar> e.g, consider foo/bar/baz, where bar can only be used by its owner and foo and baz are world readable + <cfhammar> if foo is opened, then transferred to another user, he can open baz, which he shouldn't be able to + <cfhammar> this is possible where foo/bar/baz is within a single translator, and the lookup is done in a single dir-lookup + <antrik> cfhammar: I'm not sure this is a bug + <cfhammar> I have a test case that triggers the bug, and another that doesn't which currently confuses me + <antrik> cfhammar: it's probably not very usual to pass around open directory ports; but if somebody does it, it's probably actually desired that it keeps the authority + <antrik> it's kinda consistent with passing normal FDs + <cfhammar> antrik: it should only allow accesses to entries not sub-entries + <cfhammar> antrik: it isn't allowed in Linux atleast, and I'm guessing it's mandated by posix + <cfhammar> also note that a more common scenario is a process that opens a directory and then drops authority + <cfhammar> probably more common, that is + <antrik> cfhammar: I'm not really familiar with directory access functions... I wasn't even aware that it's possible to pass around directory FDs + <antrik> but if it is, it would indeed be good to know what POSIX says about this + <antrik> cfhammar: I don't see how this is related?... + <cfhammar> antrik: after the process has dropped authority it can still make lookups in directories that it should no longer be able to + <antrik> cfhammar: interesting point... + <antrik> cfhammar: do you think this is fixable? + <cfhammar> antrik: Not without (defacto) changing the interface + <cfhammar> e.g only looking up a singe path component at a time + <cfhammar> or doing the auth check lazily on io_reauthenticate + <antrik> cfhammar: yeah, obviously it's not possible without an API change. I just wonder whether it's possible without throwing the current auth/lookup mechanism overboard alltogether... + <cfhammar> antrik: both my solutions are only minor changes to the API, but fairly major in the sense that we need to change all callers :-( + <cfhammar> diskfs_S_dir_lookup is a very large function, for example + <antrik> cfhammar: OK + <antrik> cfhammar: I wonder whether there is a possible transition path without breaking all existing installations... + <cfhammar> we could provide a new RPC while supporting the old one + <cfhammar> note that changing fs.defs only affects glibc and the Hurd, normal apps should be fine + <antrik> cfhammar: have you posted your findings to the ML yet? + <cfhammar> No, I'm still investigating why my second test-case doesn't trigger the bug + <cfhammar> Intrestingly it's the one using all POSIX functions... + <cfhammar> Perhaps its a bug that maskes the lookup bug ;-) + <antrik> I guess there is some quirk which you do not fully understand yet :-) + <cfhammar> Oh, there's always a new quirk to find in the Hurd :-) + <cfhammar> antrik: seems that dir_lookup isn't buggy after all + <cfhammar> antrik: as all FDs are reauthenticated on setauth + <antrik> ah + <cfhammar> antrik: and (presumably) ports are unauthenticated and reauthenticated when transfered + <antrik> yeah, that's the idea behind the auth protocol... + <antrik> users obtain specific capabilities by authenticating generic ports against their own ID + <cfhammar> I didn't really have a coherent view on how open flags are handled on reauth + <cfhammar> it seems open flags always win, so that a O_READ port that is unauthed is still readable + <antrik> not sure what you mean + <cfhammar> if I open a file to read it, then reauth it with a user that isn't permitted to read it, I can still read from it + <cfhammar> (as it should be) + <cfhammar> by contrast permission to do lookups in a directory is determined by who authed it + <cfhammar> so I won't be able to do lookups after a reauth, if it's not permitted by the file bits + <youpi> Mmm, openat should however be able to + <youpi> since you've first opened the directory with the auth + <cfhammar> it isn't since open FDs are reauthed on setauth + <cfhammar> not sure whether it should though, Linux behaves the same way atleast + <cfhammar> though it could be done with POSIX.2008's O_SEARCH open flag diff --git a/open_issues/e2fsck_i_file_acl_hi.mdwn b/open_issues/e2fsck_i_file_acl_hi.mdwn new file mode 100644 index 00000000..6a0632ac --- /dev/null +++ b/open_issues/e2fsck_i_file_acl_hi.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2010 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, unknown channel, unknown date. + + <Duck> something's broken in ext2, fsck, or the like + <Duck> /dev/hd0s1: i_file_acl_hi for inode 81872 (/proc) is 32, shoud be 0. + <Duck> youpi: the other problem is probably related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526524 + <Duck> i'll just check when it is fixed + <antrik> youpi: I've seen a lot of these fsck errors since the upgrade to 1.41.x + <antrik> youpi: seems to happen whenever a passive translator is still active while the machine reboots + <Duck> antrik: ho, so in my example this could be related to procfs then + <antrik> Duck: don't know... I got it with various terminal-related nodes + <antrik> other translators get terminated before ext2 it seems, so the problem doesn't happen there + <antrik> unless the machine crashes of course + <antrik> ah, right, it told you that it's the /proc node :-) + <antrik> was it the only node it complained about? + <antrik> Duck: ^ + <Duck> antrik: yes, the only one + <youpi> so it's most probably i + <youpi> t + <Duck> but currently i don't have much translators around besides the base install + <antrik> that's strange... my theory about translators active at reboot seems wrong then + <youpi> well, maybe procps is not behaving properly + <youpi> procfs* + <antrik> youpi: I doubt it. I regularily get the same issue with various term nodes; and when the machine crashes rather than rebooting cleanly, many other nodes as well + <youpi> k + <antrik> but it's always passive translator nodes diff --git a/open_issues/elinks.mdwn b/open_issues/elinks.mdwn new file mode 100644 index 00000000..ee372971 --- /dev/null +++ b/open_issues/elinks.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +IRC, unknown channel, 2008-05-26 and later + + <paakku> In elinks/src/network/state.h, there is an assumption that values of errno are between 0 and 100000. Now looking at glibc-2.5/sysdeps/mach/hurd/bits/errno.h, I see that you're using values outside this range. Have there been problems because of this? + <youpi> eeerf + <youpi> I had never seen a program assuming that + <youpi> that sucks + <paakku> It can be fixed, but that'd require some work, so I'd like to first have a clear idea of the effects. + <youpi> fixed where ? + <paakku> in elinks + <youpi> k + <paakku> by allocating just one number from our enum connection_state for system errors, and then stashing the errno value in a separate variable. + <paakku> Anyway, if you see this cause any user-visible bugs in ELinks, please report. + + <kahmalo> I mentioned here on 2008-05-26 that ELinks assumes errno values are between 0 and 100000 whereas the Hurd uses other values. I fixed this in ELinks last weekend; the most recent 0.12 and 0.13 snapshots should include the fix. If you find any remaining errno assumptions, please post to: http://bugzilla.elinks.cz/show_bug.cgi?id=1013 + <kahmalo> or to one of our mailing lists. + <kahmalo> I guess the pflocal select() bug http://savannah.gnu.org/bugs/?22861 is the primary hindrance to running ELinks on the Hurd. Has any decision been made on how that will be fixed? diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn new file mode 100644 index 00000000..1806983a --- /dev/null +++ b/open_issues/exec.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <youpi> oh my, disabling gzip/bzip2 support makes apt preconfigure hang + <youpi> support in exec* I meant + + <youpi> now a funny bug: if I disable gzip/bzip2 support from exec + <youpi> trying to run a zero-byte file hangs diff --git a/open_issues/extern_inline.mdwn b/open_issues/extern_inline.mdwn new file mode 100644 index 00000000..a56d4902 --- /dev/null +++ b/open_issues/extern_inline.mdwn @@ -0,0 +1,74 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <tschwinge> youpi: Did you ever review the Savannah hurd branch master-fix_extern_inline? + <youpi> why static inlines instead of extern lines ? + <youpi> +in + <youpi> static inlines can lead to space waste where it isn't inlined + <tschwinge> Are you sure about that -- I don't think so. + <tschwinge> At least with 99 inlining. + <youpi> what can the compiler do where it isn't inlined ? + <youpi> include a copy + <youpi> thus space waste + <youpi> 00000000004004b1 t f + <youpi> 00000000004004d5 t f + <youpi> I've juste checked + <youpi> two copies of my inline function + <youpi> one per .o + <tschwinge> Yes, but isn't it expected tobe that way? ARen't these functions those that are never included in a libarary, as opposed to those which I switched to __extern_inline in the next patch? + <tschwinge> It's been a long time that I had a look at this... + <tschwinge> The problem with the patch from the Debian package is that the functions didn't end up in the libraries anymore. + <youpi> ah you mean these are private functions and thus shouldn't be exposed (unexpected_reply for instance) + <youpi> but the duplication issue still holds + <youpi> the functions not ending up in the library is a concern indeed + <tschwinge> That's what my second patch fixes, I think. + <youpi> grah, callisto rebooted for no reason + <youpi> ah, indeed the second patch fixes things correctly + <youpi> uh, indeed it's --dbg-package=hurd in there + <youpi> how odd + <youpi> tschwinge: for the libftpconn case, yes unexpected_reply should probably be a static inline + <tschwinge> Is this true: + <tschwinge> static inline -- either inline or emit a local symbol vs. extern inline -- either inline or emit a reference to an external symbol. + <youpi> so as to not expose it + <youpi> for other cases we can keep an extern inline as they are just programs + <tschwinge> Then everything that's not expected to end up in a libarary must be static inline, as otherwise, when the compiler can't inline, there wouldn't be a reference to it available. + <youpi> and that avoids duplicate code + <youpi> yes + <youpi> but as long as you provide the extern inlines by compiling an xinl.c there's no problem + <tschwinge> Sure, that'd be the alternative. + <youpi> for libraries you need to take care of the symbols you want to export (which can thus be in xinl.c), and those you don't want to export (and thus keep static inlines) + <tschwinge> So you say it'd be better to do that (xinl.c) instead of static inline? + <youpi> for programs, you can just keep them all extern inlines + <youpi> yes, it shares code + <youpi> it's only in the case of symbols that shouldn't be exported by the library that we need to use static inlines + <tschwinge> ANd in .c files that are part of programs I'd also use extern inline or static inline? + <youpi> for programs just always use extern lines + <youpi> +in + <youpi> as you don't care about symbol exposure + <youpi> unless the inline is defined in a .c file of course, in that case it's useless to make it extern + <tschwinge> But then I also always need xinl.c files for those, which we apparently don't have in a few places. + <youpi> yes + <tschwinge> But probably didn't notice so far, as the functions could always be inlined. + <youpi> probably because we used to have luck + <youpi> yes + <tschwinge> Yes, I was thinking about the term/munge.c thing. + <tschwinge> OK, I think I get it now. Then I'll try to fix this accordingly. + <tschwinge> But not now. Thanks for the help! + <youpi> ok, thanks + <tschwinge> It was quite a bit confusing to me. + <tschwinge> Due to the mostly reversed definition of extern inline in glibc (I think). + <youpi> inline definitely is confusing + <youpi> especially since the semantic has changed over time and according to standards :) + <tschwinge> And then GCC changing that according to C99. + <tschwinge> Yes. diff --git a/open_issues/fdisk.mdwn b/open_issues/fdisk.mdwn new file mode 100644 index 00000000..ece8fc89 --- /dev/null +++ b/open_issues/fdisk.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + + Command (m for help): w + The partition table has been altered! + + Calling ioctl() to re-read partition table. + *Segmentation fault* + +Changes have been saved, though. + +Perhaps realted to the [[BLKRRPART_IOCTL]]? diff --git a/open_issues/fsync.mdwn b/open_issues/fsync.mdwn new file mode 100644 index 00000000..d36a75ad --- /dev/null +++ b/open_issues/fsync.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date + + <youpi> azeem: I think I found why apt-get throws Hurd down sometimes + <youpi> the problem is that it basically write(file, 20MB); fsync(); + <youpi> i.e. it throws a storm of dirty-writeback to ext2fs + <youpi> which thus goes into throttling threads + <youpi> since posix explicitely says that fsync() can be void, I think I'll patch apt-get on the buildd + <youpi> (that bug has bitten me too many times in the past days to let it go further) + <youpi> for now it works + * youpi crosses fingers diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn index 76832165..3209d5b0 100644 --- a/open_issues/gcc.mdwn +++ b/open_issues/gcc.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 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 @@ -47,4 +48,4 @@ Additionally: * [[`libmudflap`|libmudflap]]. - * [[C++]]. + * [[Boehm_GC]]. diff --git a/open_issues/gcc/boehm_gc.mdwn b/open_issues/gcc/boehm_gc.mdwn new file mode 100644 index 00000000..2ee88a2b --- /dev/null +++ b/open_issues/gcc/boehm_gc.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gcc]] + +IRC, unknown channel, unknown date. + + <tschwinge> youpi: The Debian GCC 4.3 package also has this change: + <tschwinge> --- boehm-gc/dyn_load.c.orig 2007-08-13 09:10:48.215678000 +0200 + <tschwinge> +++ boehm-gc/dyn_load.c 2007-08-13 09:11:09.743969000 +0200 + <tschwinge> @@ -26,7 +26,7 @@ + <tschwinge> * None of this is safe with dlclose and incremental collection. + <tschwinge> * But then not much of anything is safe in the presence of dlclose. + <tschwinge> */ + <tschwinge> -#if (defined(__linux__) || defined(__GLIBC__)) && !defined(_GNU_SOURCE) + <tschwinge> +#if (defined(__linux__) || defined(__GLIBC__) || defined(__GNU__)) && !defined(_GNU_SOURCE) + <youpi> yes, these are needed + <youpi> and that's the kind of fix needed for java + +--- + +<http://lists.debian.org/debian-hurd/2000/03/msg00305.html> diff --git a/open_issues/gdb_config.mdwn b/open_issues/gdb_config.mdwn new file mode 100644 index 00000000..4f031c8f --- /dev/null +++ b/open_issues/gdb_config.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gdb]] + + * Have a look at config/i386/i386gnu.mh. + + * configure.tgt + + * glibc-tdep et al. also for GNU/Hurd? diff --git a/open_issues/gdb_qemu_debugging_gnumach.mdwn b/open_issues/gdb_qemu_debugging_gnumach.mdwn new file mode 100644 index 00000000..d3105f50 --- /dev/null +++ b/open_issues/gdb_qemu_debugging_gnumach.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gdb open_issue_gnumach]] + +\#hurd, freenode, June (?) 2010 + + <jkoenig> is there a way to get gdb to map addresses as required when debugging mach with qemu ? + <jkoenig> I can examine the data if I manually map the addresses th 0xc0000000 but maybe there's an easier way... + <youpi> jkoenig: I haven't found a way + <youpi> I'm mostly using the internal kdb + diff --git a/open_issues/glibc_ioctls.mdwn b/open_issues/glibc_ioctls.mdwn new file mode 100644 index 00000000..14329d0f --- /dev/null +++ b/open_issues/glibc_ioctls.mdwn @@ -0,0 +1,72 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <pinotree> d'oh, broken defines for ioctl()! + <pinotree> http://paste.debian.net/45021/ ← any idea about this? looks like something fishy with the SIO* defines + <pinotree> tschwinge: ↑ know anything about this? + <pinotree> #define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← looks like it is missing for bits/ioctls.h + <pinotree> eglibc patch submitted-ioctl-unsigned-size_t.diff should be pimped a bit + + <pinotree> youpi: while trying to compile ossp-uuid (needed by pgsql 8.4, needed by various other stuff), i found a bug in a hurd libc header + <youpi> that's possible + <pinotree> it has a ioctrl() using an id with a value having type 'struct arpreq' + <youpi> ah, that's not a bug then + <youpi> see the ioctl section of the porting page of the wiki + <pinotree> due to the sort of "mangling" done in bits/ioctrls.h, there should be an helper macro for the size of the struct arpreq + <pinotree> +#define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← adding this before any header was enough + * pinotree looks + <youpi> it's not to be done so simply + <youpi> see the page :) + <youpi> I'm afraid _IOT_arpreq can't be properly defined + * pinotree is not finding it... + <pinotree> the closest i see is http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html + <youpi> that's it yes + <youpi> I mean, that's the kind of thing + <youpi> but not the wiki page, let me look + <youpi> http://www.gnu.org/software/hurd/hurd/porting/guidelines.html + <pinotree> i also saw a glib patch adding few types like that (char, short, int) + <youpi> yes that's the same kind of thing + <pinotree> i see + <youpi> setting it to _IOT_SIMPLE(struct arpreq) would probably work with 32bit gnumach and 32bit userland, but may not with e.g. 64bit gnumach and 32bit userland and such + <pinotree> hmmm, sockaddr,sockaddr,int,sockaddr,char[16] + <pinotree> so basically it would support at most 3 elements in a passed struct? + <pinotree> s/elements/fields/ + <youpi> 3 kinds of fields + <youpi> as you provide a count + <pinotree> youpi: so basically: #define _IOT_arpreq _IOT (_IOTS (struct sockaddr), 3, _IOTS (int), 1, _IOTS (char), 16) ? + <pinotree> ie the order of the fields in the struct does not matter, it seems? + <youpi> the order of the fields does matter + <youpi> as this encodes how mig will read the struct to send them + <pinotree> uhm + <youpi> also, _IOTS(struct sockaddr) won't work + <pinotree> yeah i should define it too + <youpi> no, it even needs to be replaced by its content + <pinotree> ah + <pinotree> it is possible to compose the _IOTS()? + <pinotree> (to build structs with more than 3 kind of fields) + <youpi> no + <pinotree> d'oh + <youpi> that's a hard shortcoming of the whole ioctl encoding + * pinotree scratches his head + <youpi> there's no way but redefining ioctl(), really + <youpi> it was a funny trick to encode it this way, but unrealistic + <pinotree> i see, yes + <youpi> not to mention ioctls which contain pointers, which just can not be passed to mig + <pinotree> indeed + <youpi> actually it's not mach's ioctl issue + <youpi> as mach doesn't know ioctl + <youpi> but the hurd ioctl interface + <pinotree> right + <youpi> which might end up in mach, other processes, other machines, etc. + * pinotree s/Mach/Hurd/ :) diff --git a/open_issues/glibc_libpthread_robust_mutexes.mdwn b/open_issues/glibc_libpthread_robust_mutexes.mdwn new file mode 100644 index 00000000..a92c984d --- /dev/null +++ b/open_issues/glibc_libpthread_robust_mutexes.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +libpthread: glibc 44e2ad5ab8c21dbfed3e384ba2ed31d7a8fc4744 +998e5fc14595229101561d76282036839e5b66ab -- The robust mutex functions are in +POSIX 2008. + +--- + +IRC, #hurd, unknown date. + + <youpi> neal: bad news: you remember the PTHREAD_RECURSIVE_MUTEX_INITIALIZER that points to a global __pthread_recursive_mutexattr? + <youpi> that doesn't work + <youpi> because some libraries like libstdc++ do not link against libpthread, while still using pthread_mutex_lock/unlock (counting on them being provided by either libc or libpthread-stubs) + <CIA-1> sthibaul-guest * r626 pkg-hurd/hurd/trunk/debian/ (changelog patches/series): + <CIA-1> * debian/patches/libpthread_rwlock_initializer.patch: Disable patch for now: + <CIA-1> our initializer does not work when the application does not link against + <CIA-1> libpthread. + + <CIA-1> sthibaul-guest * r629 pkg-hurd/hurd/trunk/debian/ (changelog patches/series): do not disable adding PTHREAD_RWLOCK_INITIALIZER, that's not the one that poses problems + <CIA-1> sthibaul-guest * r630 pkg-hurd/hurd/trunk/debian/ (3 files in 2 dirs): + <CIA-1> * debian/patches/libpthread_no_recursive_mutex_initializer.patch: New patch + <CIA-1> to drop undefined references to __pthread_recursive_mutexattr. + + <youpi> I'm thinking about how to fix the PTHREAD_RECURSIVE_MUTEX_INITIALIZER + <youpi> instead of a pointer to a static attribute variable, which posed problem + <youpi> could we perhaps consider that page 0 is never mapped + <youpi> and thus not only pointer 0 but also 1 2, etc. are invalid + <neal> I think that is a good solution + <youpi> and use them as special values + <neal> alternatively, we could assume that -PAGESIZE is never valid + <youpi> that makes us test it in all pthread_mutex_* functions, but it's not so bad + <neal> I'm not sure which is better + <youpi> why isn't it? + <neal> because the kernel is mapped there normally + <youpi> the kernel could be elsewhere + <neal> true + <youpi> in a 64bit adressing space for instance + <neal> I think your solution is a good one + <youpi> ok + + <CIA-1> sthibault * r633 pkg-hurd/hurd/trunk/debian/ (3 files in 2 dirs): + <CIA-1> * debian/patches/libpthread_recursive_mutex_initializer.patch: New patch + <CIA-1> to fix the recursive mutex initializers usage in libraries not linking + <CIA-1> against libpthread. diff --git a/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn b/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn new file mode 100644 index 00000000..47f104c6 --- /dev/null +++ b/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <youpi> you can hardcode DTV_OFFSET as 4 for now + <youpi> it's the offset of the dtv field in the tcbhead_t structure from hurd/libpthread + <tschwinge> youpi: May very well be that I'm misunderstanding something, but wouldn't it rather be the offset of tcb in __pthread + the offset of dtv in tcbhead_t (which indeed is 4)? + <youpi> what you don't know is that DTV_OFFSET is not relative to __pthread, but to the tls segment + <tschwinge> Oh, aha. Thanks. + <youpi> and drepper abused the fact that in nptl __pthread appears at the start of the tls segment + +kFreeBSD, glibc: + + ++#if 0 + + DTV_OFFSET offsetof(struct pthread, header.dtv) + ++#else + ++DTV_OFFSET offsetof(struct _pthread_descr_struct, p_header.data.dtvp) + ++#endif diff --git a/open_issues/glusterfs.mdwn b/open_issues/glusterfs.mdwn new file mode 100644 index 00000000..68518938 --- /dev/null +++ b/open_issues/glusterfs.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 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, unknown channel, unknown date. + + <antrik> "GlusterFS is one of the most sophisticated file system in terms of features and extensibility. It + <antrik> borrows a powerful concept called Translators from GNU Hurd kernel." + <antrik> seems to be more similar to libstore than actual translators, though diff --git a/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn b/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn new file mode 100644 index 00000000..2df74301 --- /dev/null +++ b/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn @@ -0,0 +1,142 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date. + + <antrik> youpi: I have found an interesting Mach problem, but I'm a bit scared of debugging it... + <antrik> (it is related to VM stuff) + <antrik> I have a memory region that is mapped by the iopl device (it's an mmio region -- graphics memory to be precise) + <antrik> when gdb tries to read that region with vm_read() (for a "print" command), it triggers a general protection trap... + <youpi> antrik: does the general protection trap kill the whole kernel or just gdb? + <antrik> kernel + <antrik> kernel: General protection trap (13), code=0 + <antrik> pmap_copy_page(41000000,49f2000,1,0,1) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../i386/i386/phys.c:62 + <antrik> vm_object_copy_slowly(209c1c54,41000000,1000,1,20994908) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1150 + <antrik> vm_object_copy_strategically(209c1c54,41000000,1000,20994908,2099490c) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1669 + <antrik> vm_map_copyin(209ba6e4,2c000,1000,0,25394ec8) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_map.c:3297 + <antrik> vm_read(209ba6e4,2c000,1000,208d303c,25394f00) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_user.c:228 + <antrik> _Xvm_read(2095cfe4,208d3010,0,1fff3e48,2095cfd4) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/kern/mach.server.c:1164 + <antrik> ipc_kobject_server(2095cfd4,2095cfe4,28,127ca0,0) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../kern/ipc_kobject.c:201 + <antrik> mach_msg_trap(1024440,3,28,30,2c) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../ipc/mach_msg.c:1367 + <antrik> Bad frame pointer: 0x102441c + <antrik> BTW, is it useful at all to write down the paramenters as well?... + <antrik> argments I mean + <youpi> in the trace you mean? + <antrik> yes + <youpi> apparently the problem here is that the call to vm_fault_page() didn't perform its task + <youpi> which address is faulty? + <antrik> not sure what you mean + <youpi> ah shit the gpf wouldn't tell you + <youpi> does examine 49f2000 work? + <youpi> oh, wait, 4100000, that can't work + <youpi> +0 + <youpi> which physical address is your mmio at? + <antrik> haven't tried it... but I can provoke the fault again if it helps :-) + <youpi> we have the 1GB limitation issue + <antrik> oh... lemme check + <youpi> no need to, I think the problem is that + <youpi> the iopl driver should check that it's not above phys_last_addr + <antrik> it's only vm_read() that fails, though... + <antrik> the actual program I debugged in gdb works perfectly fine + <youpi> yes, but that's because it's accessing the memory in a different way + <youpi> in the case of direct reads it just uses the page table + <youpi> in the case of vm_read() it uses kernel's projection + <youpi> but in that case it's not in the kernel projection + <antrik> phys = 1090519040 + <youpi> that's it, it's beyond 1GB + <youpi> there's not much to do except changing mach's adressing organization + <antrik> yeah, that's the 0x41000000 + <antrik> hm... I guess we could make the vm_read() bail out instead of crashing?... + <youpi> yes + <youpi> but there are a lot of places like this + <antrik> still, it's not exactly fun when trying to debug a program and the kernel crashes :-) + <youpi> right :) + <antrik> I could try to add the check... if you tell me where it belongs ;-) + <youpi> antrik: it's not just one place, that's the problem + <youpi> it's all the places that call pmap_zero_page, pmap_copy_page, copy_to_phys or copy_from_phys + <youpi> and since we do want to let the iopl device create such kind of page, in principle we have to cope with them all + <youpi> pmap_zero_page should be ok, though + <youpi> the rest isn't + <antrik> is that tricky, or just a matter of doing it in all places? + + <antrik> hm... now it crashed in "normal" usage as well... + <antrik> hm... a page fault trap for a change... + <antrik> hm... now gdb tried to vm_read() something that is mapped to physical address 0x0... + <antrik> so I guess I fucked something up in the mapping code + <antrik> is it expected that such a vm_read() causes a kernel page fault, though?... + <antrik> youpi: ^ + <youpi> nope + <youpi> in principle the check for validity of the page is done earlier + <youpi> physical address 0x0 makes sense, though + <antrik> OK, here is the trace: + <antrik> Kernel page fault (14), code=0 at address 0x0 + <antrik> pmap_copy_page(0,6e54000,1,0,1) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../i386/i386/phys.c:62 + <antrik> vm_object_copy_slowly(20a067b0,0,1000,1,0acacec) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1150 + <antrik> vm_object_copy_strategically(20a067b0,0,1000,20acacec,20acacf0) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1669 + <antrik> vm_map_copyin(20a0f1c4,120d000,1000,0,253cdec8) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_map.c:3297 + <antrik> vm_read(20a0f1c4,120d000,1000,20a5703c,253cdf00) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_user.c:228 + <antrik> _Xvm_read(20a52c80,20a57010,253cdf40,20ae33cc,20a52c70) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/kern/mach.server.c:1164 + <antrik> ipc_kobject_server(20a52c70,20a52c80,28,20873074,20873070) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../kern/ipc_kobject.c:201 + <antrik> mach_msg_trap(10247d0,3,28,30,2f) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../ipc/mach_msg.c:1367 + <antrik> Bad frame pointer: 0x10247ac + <antrik> seems to be exactly the same, except for the different arguments... + <antrik> hm... interesting... it *does* write something to the framebuffer, before it crashes... + <antrik> (which unfortunately makes it a bit hard to read the panic message... ;-) ) + <LarstiQ> heh :) + <antrik> wait, it must write to something else than the frame buffer as well, or else the debugger should just paint over the crap... + <antrik> or perhaps it crashes so hard that the debugger doesn't even work? ;-) + <antrik> hm... I guess the first thing I should actually do is finding out what's up with e2fsck... this make testing crashes kinda annoying :-( + <antrik> oh, "interesting"... I ran it on one of my other hurd partitions, and it complained about an endless number of files... (perhaps all) + <antrik> however, the value for the normal files was different than for the passive translator nodes + <antrik> it doesn't happen only on crashes; it seems that all passive translators that are still in use at time of shutdown (or crash) have the offending bit set in the inode + <antrik> ouch... seems it doesn't write into the framebuffer after all, but rather scribbles all over the first 4 MiB of memory -- which includes also the VGA window, before it goes on killing the kernel... + <youpi> which iopl driver are you using ? + <antrik> ? + <youpi> the one from the debian patch? + <youpi> upstream, gnumach doesn't have an iopl device any more + <antrik> I guess so... standard Debian stuff here + <antrik> oh. how does X map the memory, then? + <youpi> X does yes + <antrik> ? + <youpi> X uses the iopl() device to access the video memory, yes + <youpi> I don't know if that was what you were asking for, but that's what I meant by my answer :) + <antrik> yeah, I know how it does *currently* do it -- I stole the code from there :-) + <antrik> my question is, how is X supposed to get at the framebuffer, when there is no iopl device anymore? + <youpi> ah, I hadn't noticed the "how" word + <youpi> in Debian there is + <LarstiQ> !debian → !x? + <youpi> the clean "access device memory" interface is yet to be done + <antrik> err... that sounds like Xorg philosophy + <youpi> what, to wait for a nice interface ? + <antrik> "let's kill the old stuff, fuck regressions... maybe someone will figure out how to do it with the new stuff at some point. if not, not our problem" + <youpi> that's also a GNU philosophy + <youpi> ah, that one + <antrik> anyone know how device_map() is supposed to behave? the documentation isn't really clear... + <antrik> my understanding was then when an offset is specified, then the resulting object will be relative to that object; i.e. the offset of a later vm_map() on this object is applied on top of the object's internal offset... + <antrik> but that doesn't seem to be how it works for the iopl device, if I read the xf86 code correctly... + <antrik> yeah, the offset parameter seems a nop when doing device_map() on the iopl device diff --git a/open_issues/gnumach_tlb_flushing.mdwn b/open_issues/gnumach_tlb_flushing.mdwn new file mode 100644 index 00000000..45d0730d --- /dev/null +++ b/open_issues/gnumach_tlb_flushing.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date. + + <tschwinge> gianluca, youpi: Why the value 32 for the TLB flushing decision, by the way? + <youpi> completely arbitrary + <tschwinge> I thought whether that might perhaps be worth a macro definition with a comment? + <verte> what's the typical TLB size these days? + <youpi> tschwinge: right + <youpi> note that the 32 value would be probably different between native and xen + <gianluca> tschwinge: just arbitrary diff --git a/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn b/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn new file mode 100644 index 00000000..b1eaf9a5 --- /dev/null +++ b/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2009, 2010 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, #hurd, 2009-08-25 + + <cfhammar> also I fixed (what I think is) a bug in hurd_file_name_lookup_retry when opening FDs with FS_RETRY_MAGIC + <cfhammar> it didn't actually reopen the FD, rather it just (effectively) duped it + <scolobb> cfhammar: That's great! I think I had some problems because of not being able to truly reopen a port to a file. + <antrik> cfhammar: what is the difference, and why do you consider it a bug?... + <cfhammar> antrik: for one thing you can't change open modes, and it doesn't reset the file cursor + <cfhammar> (which I actually needed, though I could have done it manually) + <cfhammar> antrik: and also it isn't consistant with linux + <cfhammar> you can trigger the bug from the shell: cat /dev/fd/3 3>> /tmp/foo + <antrik> cfhammar: I can't say that I understand the test case... but I can at least confirm that it behaves differently on Hurd and on Linux :-) diff --git a/open_issues/kvm.mdwn b/open_issues/kvm.mdwn new file mode 100644 index 00000000..6dfffc9a --- /dev/null +++ b/open_issues/kvm.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +Issues when running Hurd under KVM: un-synced filesystems, etc. No problems +with Virtualbox. + +2010-07-28, #hurd + + <youpi> pochu: you were the one reporting issues with qemu/kvm and hurd, right? + <youpi> is your machine somehow smp (like multicore for instance) + <youpi> ? + <pochu> youpi: yes, it's a Core 2 Duo + <pochu> so 2 cores + <youpi> ok, you might want to try to bind qemu/kvm + <youpi> e.g. install hwloc, and prepend "hwloc-bind 1 --" before the qemu/kvm command line + <pochu> ok, ty + +2010-07-31, GNU Mach commit 039176372b4271f370ef38eb2ee5d43923a5b28b. diff --git a/open_issues/libasyncns.mdwn b/open_issues/libasyncns.mdwn new file mode 100644 index 00000000..bbd34bff --- /dev/null +++ b/open_issues/libasyncns.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +IRC, unknown channel, unknown date. + + <pinotree> tschwinge: btw, would you be able to tell if and what's wrong with a socket-related problem? + <pinotree> it is reproducible with a very small self-contained C library + <pinotree> http://0pointer.de/lennart/projects/libasyncns/ + <pinotree> it has a test case with it, which fails + <pinotree> tschwinge: if that can ring some bell, imho the problem is related to SOCK_STREAM sockets created with socketpair and used with send/recv diff --git a/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn b/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn new file mode 100644 index 00000000..1e4a6acb --- /dev/null +++ b/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <tschwinge> By the way: your libdiskfs ., .. fix -- is that relevant for libnetfs as well? (Didn't look it up so far.) + <youpi> it could be a good idea to protect netfs users directly from there yes + <tschwinge> But probably the backend (e.g., NFS server) would protect us in the netfs case, right? + <youpi> possibly, but we could have locking issues in between like in libdiskfs + <youpi> and POSIX says it's invalid anyway + <youpi> so we'd probably better just forbid it diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn index 68195758..16b6d098 100644 --- a/open_issues/libpthread.mdwn +++ b/open_issues/libpthread.mdwn @@ -8,7 +8,7 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!tag open_issue_glibc open_issue_pthread]] +[[!tag open_issue_glibc open_issue_libpthread]] GSoC project idea: [[community/gsoc/project ideas/pthreads]] diff --git a/open_issues/libpthread_weak_symbols.mdwn b/open_issues/libpthread_weak_symbols.mdwn new file mode 100644 index 00000000..6f135979 --- /dev/null +++ b/open_issues/libpthread_weak_symbols.mdwn @@ -0,0 +1,50 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +IRC, unknown channel, unknown date. + + <youpi> btw, the issue with pthread_cancel is tricky + <youpi> I'm afraid there might be no fix + <youpi> clean fix, I mean + <pinotree> oh, hm + <pinotree> where it the problem located, actually? + <youpi> it's a lot more than just one place + <youpi> in some c++ header there is a weak reference to pthread_cancel + <youpi> libpthreadstubs0 provides a weak definition of pthread_cancel, which can suit well + <youpi> problem comes when also linking with a library which pulls libpthread + <youpi> oops no libpthreadstubs0 doesn't provide a weak definition of pthread_cancel + <youpi> it couldn't implement it anyway + <youpi> and the problem here is that the linker seems to be looking for pthread_cancel in the libpthreadstubs0 library, not libpthread + <youpi> and can't find it + <youpi> I don't know how this translate to english, but we're “walking on eggs + <youpi> ” on this issue + <pinotree> i see + <youpi> i.e. we already know we're not respecting the ELF standard + <youpi> we need a feature that is not in the standard to make pthread symbols working + <youpi> the solution would be to integrate libpthread into the glibc + <pinotree> you mean in the sources, but still providing separate libc.so and libpthread.so? + <youpi> yes + <pinotree> would that be difficult/tricky? + <youpi> because that permits to put pthread_* functions forwarding directly in the glibc, as is done on linux + <youpi> problem is upstream, you know... + <youpi> if we put libpthread there, it'll be difficult for us to maintain it + <pinotree> ah, the friendly ulrich mate? + <youpi> we already have difficults to get almost trivial patches commited + <youpi> and the "yes I'll handle it someday" Roland mate + <youpi> Roland is supposed to be the GNU part maintainer, but he doesn't have a box running at the moment + <youpi> what we could do is to do it in Debian for the moment + <pinotree> yeah + <pinotree> iirc eglibc is maintained within git, isn't it? + <pinotree> maybe you could do a hurd branch, putting all the hurd patches and the pthread sources, and then releasing from that + <youpi> we're already moving to something like that, yes + <youpi> at least for all the other glibc patches we have + <youpi> maybe we'll just do that on sourceware actually diff --git a/open_issues/lisp_cross-compile.mdwn b/open_issues/lisp_cross-compile.mdwn new file mode 100644 index 00000000..c9100aec --- /dev/null +++ b/open_issues/lisp_cross-compile.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +flaviocruz-soc2008-lisp-branch: lisp stuff can't be cross-compiled. diff --git a/open_issues/lsof.mdwn b/open_issues/lsof.mdwn new file mode 100644 index 00000000..2cbf2302 --- /dev/null +++ b/open_issues/lsof.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +We don't have a `lsof` tool. Perhaps we could cook something with having a +look at which ports are open at the moment (as [[`portinfo`|hurd/portinfo]] +does, for example)? diff --git a/open_issues/ltrace.mdwn b/open_issues/ltrace.mdwn new file mode 100644 index 00000000..cf0df759 --- /dev/null +++ b/open_issues/ltrace.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <youpi> it'd be good to have ltrace eventually + <youpi> rpctrace has too many issues to be usable + <youpi> (and a lot of them are hard to fix iirc) + <youpi> ltrace traces library calls + <youpi> in principle it should just work at the dynamic linker stage, so should be portable diff --git a/open_issues/mach-defpager_vs_defpager.mdwn b/open_issues/mach-defpager_vs_defpager.mdwn new file mode 100644 index 00000000..d6976706 --- /dev/null +++ b/open_issues/mach-defpager_vs_defpager.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +\#hurd, 2010, end of May / beginning of June + + <cfhammar> whats the difference between mach-defpager and defpager? + <cfhammar> i'm guessing defpager is a hurdish version that uses libstore but was never finished or something + <cfhammar> found an interesting thread about it: http://mirror.libre.fm/hurd/list/msg01232.html + <slpz> antrik: an interesting thread, indeed :-) + <pochu> slpz: btw is mach-defpager linked statically but not called mach-defpager.static on purpose? + <slpz> antrik: also, I can confirm that mach-defpager needs a complete rewrite ;-) + <slpz> pochu: I think the original defpager was launched by serverboot + <slpz> pochu: that could be the reason to have it static, like ext2fs + <slpz> and since there's no need to execute it again during the normal operation of the system, they probably decided to not create a dynamically linked version + <slpz> (but I'm just guessing) + <slpz> of perhaps they wanted to prevent mach-defpager from the need of reading libraries, since it's used when memory is really scarce (guessing again) diff --git a/open_issues/magic_translator_machtype.mdwn b/open_issues/magic_translator_machtype.mdwn new file mode 100644 index 00000000..1c62b762 --- /dev/null +++ b/open_issues/magic_translator_machtype.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2008, 2010 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]]."]]"""]] + +[[!meta title="/hurd/magic machtype"]] + +[[!tag open_issue_hurd open_issue_glibc]] + + tschwinge@clubber:~ $ settrans -ca machtype /hurd/magic machtype + tschwinge@clubber:~ $ l mach<TAB>Connection to clubber.bddebian.com closed. + thomas@dirichlet:~ $ ssh clubber + Warning: Permanently added '[clubber.bddebian.com]:2251' (RSA) to the list of known hosts. + Last login: Tue Dec 30 08:52:58 2008 from dslb-084-057-196-016.pools.arcor-ip.net + tschwinge@clubber:~ $ cat machtype + Segmentation fault + tschwinge@clubber:~ $ l machtype + Segmentation fault + tschwinge@clubber:~ $ l mach<TAB>Connection to clubber.bddebian.com closed. diff --git a/open_issues/mig_error_reply.mdwn b/open_issues/mig_error_reply.mdwn new file mode 100644 index 00000000..21a5b217 --- /dev/null +++ b/open_issues/mig_error_reply.mdwn @@ -0,0 +1,68 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_mig]] + +\#hurd, freenode, 2010-05-19 + + <cfhammar> ugh, mig server stubs generated from *_reply.defs don't call the server functions when the reply is an error, since the message size is too small... + <cfhammar> term seems to get around it by turning of type checking + <cfhammar> s/of/off + <cfhammar> but streamio doesn't + <cfhammar> luckily the only other program that makes use of a *_reply.defs is crash, and crash_reply.defs' routines only return an error code so it isn't affected + <slpz> cfhammar: could you point me to a stub with that problem? + <cfhammar> slpz: trans/device_replyServer.c:_Xdevice_open_reply (in build dir) + <slpz> cfhammar: So, if I understand it correctly, the problem is that GNU Mach generated stub doesn't properly set the size of the message if there's an error in the function, thus the type checking in user generated stub discards the reply + <cfhammar> slpz: the size is correct, error messages contain just a return value + <cfhammar> slpz: it is the type checking that is at fault imho + <slpz> cfhammar: even when a server wants to return an error, the size of the message should be the same as the reply structure previously defined + <slpz> cfhammar: on the other hand, I can't understand why streamio is using device_open_request (async RPC) instead of device_open (sync RPC)... + <cfhammar> slpz: the server does not always know the proper size, e.g. when it doesn't understand the message + <slpz> cfhammar: what do you mean by "doesn't understand the message"? + <cfhammar> slpz: if it doesn't implement that interface or is the wrong type, etc. + <cfhammar> slpz: in that case the mig stub needs to send out a generic error reply + <cfhammar> slpz: i don't know why streamio uses it either + <slpz> cfhammar: OK, now I see your point. If the server answers with a generic error code (as MIG_*), device_open_reply will not be called, and device_open_request doesn't get an error. + <slpz> cfhammar: good catch :-) + <cfhammar> slpz: all errors are handled the same way, MIG_* is just an example of why it does so + <slpz> cfhammar: on an unrealted note, I think we should get rid of all asynchronous messages sent from the user to the kernel, since they aren't asynchronous except for sending the reply to a different port (the process is really done by the thread calling mach_msg) + <cfhammar> slpz: i'm not not all that familiar with the low-level parts of message passing so i can't really comment + <slpz> cfhammar: in that point I disagree. If the server function can understand the message (so there isn't a MIG_* error), it can send a reply message with the proper size + <cfhammar> slpz: it could, but what is the advantage if we still need to handle generic errors? + <cfhammar> slpz: "sending the reply to a different port", different from what? + <slpz> cfhammar: to differentiate between message marshalling errors and errors generated by the called function + <slpz> cfhammar: in a synchronous RPC, the same call to mach_msg will send the request and receive the reply by providing a mig generated reply port + <slpz> cfhammar: but in an asynchronous, the reply is received by a port previously generated by the function requesting the message + <cfhammar> slpz: ah, that's a clever optimization + <slpz> cfhammar: if the "asynchronous" message is sent to the kernel, the thread calling for mach_msg will execute the server's function, but the reply will be sent to one of these previously generated ports + <slpz> cfhammar: actually you have a synchronous operation replying to a different port. That doesn't make much sense to me :-) + <antrik> slpz: note that most kernel functions can be implemented by userspace servers, in which case they could be really async... + <cfhammar> slpz: not sure how differentiating mig errors from server errors is useful... + <slpz> antrik: define "most kernel functions" ;-) + <cfhammar> slpz: if nothing else kernel rpcs can be proxied, e.g. rpctrace + <slpz> cfhammar: well, think of device_open_request. If the result is not a mig error, you can still device_open_reply an expect it to properly process the return code from the message + <cfhammar> slpz: it should be able to handle all kinds of errors anyway, the result should be the same as with syncronous rpcs + <slpz> cfhammar: yes, you're right. User generated stub should be able to fill the reply with the error code and call to the reply function. + <slpz> cfhammar: Then someone needs to introduce some changes in MiG's magic... + <cfhammar> slpz: yes, a flag to generate reply side of an interface would be ideal + <cfhammar> slpz: then we could toss out *_reply.defs altogether + <slpz> cfhammar: well, that's a different change from what I was thinking + <cfhammar> slpz: how would you change it? + <slpz> cfhammar: just generating stubs which, in case of error, will properly call to the reply function with the error code in its arguments + <cfhammar> slpz: ah yes, i considered that as well, but i don't think mig can actually distinguish the error code from any other int argument + <cfhammar> slpz: i should double check it though + <slpz> cfhammar: I tag can be used to point to argument of this nature + <slpz> cfhammar: s/I/A/ + <cfhammar> slpz: oh, it already is tagged with retcode, intresting + <slpz> cfhammar: OMG, I'm thinking like MiG! ;-P + <cfhammar> slpz: is that a good or bad ; + <cfhammar> slpz: ;-) + <slpz> cfhammar: I don't know, but it's somewhat scary ;-) + <cfhammar> slpz: apparently retcode is only there for comatibility, mig just ignores it... diff --git a/open_issues/neals_hurd-misc_papers.mdwn b/open_issues/neals_hurd-misc_papers.mdwn new file mode 100644 index 00000000..7f4e1e3b --- /dev/null +++ b/open_issues/neals_hurd-misc_papers.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +<http://walfield.org/pub/people/neal/papers/hurd-misc/> + + <tschwinge> neal: We could put that into the wiki some day, I think. + <neal> sure diff --git a/open_issues/nptl.mdwn b/open_issues/nptl.mdwn new file mode 100644 index 00000000..daec8b11 --- /dev/null +++ b/open_issues/nptl.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_libpthread open_issue_glibc]] + +IRC, #hurd, 2010-07-31 + + <tschwinge> Other question: how difficult is a NPTL port? Futexes and some kernel interfaces for scheduling stuff etc. -- what else? + <youpi> actually NPTL doesn't _require_ futexes + <youpi> it just requires low-level locks + <youpi> Mmm, it seems to be so only in principle + <youpi> I can see futex names here and there in the generic code + <youpi> looks like Drepper isn't disciplined enough in that area either + <tschwinge> (well, why would he...) + <youpi> I'm not sure we really want to port NPTL + <tschwinge> OK. + <youpi> Drepper will keep finding things to add + <youpi> while the interface between glibc and libpthread isn't increasing _so_ much + <tschwinge> ... and even less so the interfavce that actual applications are using. + <tschwinge> We'd need to evaluate which benefits NPTL would bring. diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn new file mode 100644 index 00000000..7594ae76 --- /dev/null +++ b/open_issues/packaging_libpthread.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_libpthread open_issue_glibc]] + +IRC, #hurd, 2010-07-31 + + <tschwinge> My idea was to have a separate libpthread package. What do you think about that? + <youpi> in the long term, that can't work with glibc + <youpi> because of the thread stub stuff + <youpi> it's not really possible to keep synchronized + <youpi> because you have to decide which package you unpack first + <youpi> (when upgrading) + <tschwinge> Hmm, how is that different if two shared libraries are in one package vs. two packages? It isn't atomic either way? Aren't sonames / versioned library packages solving that? + <tschwinge> ... for incompatible forward changes? + <youpi> that'd be a mess to maintain + <youpi> Drepper doesn't have this constraint and thus adds members of private fields at will + <tschwinge> OK, but how is it different then if the libpthread is in the Hurd package? + <youpi> I'm not saying it's better to have libpthread in the Hurd package + <tschwinge> OK. + <youpi> I'm saying it's useless to package it separately when Drepper makes everything to have us put it along glibc + <tschwinge> Then, to goal is to have it in glibc? + <tschwinge> OK. :-) + <tschwinge> OK, I can accommodate to that. Isn't not that we'd want to switch libpthread to something else so quickly. + <tschwinge> So our official goal is to have libpthread in glibc, at least for Debian purposese? + <youpi> for any port purpose + <tschwinge> Ack. + <youpi> provided you're using glibc, you're deemed to ship libpthread with it + <youpi> because of the strong relations Drepper puts between them + <youpi> (just to remind: we already have bugs just because our current libpthread isn't bound enough to glibc: dlopen()ing a library depending on libpthread doesn't work, for instance) + <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread isn't used + <pinotree> (would be nice to not have those issues anymore...) + <tschwinge> So -- what do we need to put it into glibc? We can make libpthread a Git submodule (or move the code; but it's shared also for Neal's viengoos, so perhaps the submodule is better?), plus some glibc make foo, plus some other adaptions (stubs, etc.) + <tschwinge> Does that sound about right, or am I missing something fundamental? + <youpi> I actually don't know what a git submodule permits :) + <youpi> looks like a good thing for this, yes + <tschwinge> Unfortunately I can't allocate much time at the moment to work on this. :-/ + <youpi> well, as long as I know where we're going, I can know how to package stuff in Debian + <tschwinge> That sounds like a plan to me. libpthread -> glibc as submodule. + <youpi> (note: actually, the interface between glibc and the libpthread is the responsibility of the libpthread: it gives a couple of .c files to be shipped in libc.so) diff --git a/open_issues/populate_hurd_git_with_submodules_etc.mdwn b/open_issues/populate_hurd_git_with_submodules_etc.mdwn new file mode 100644 index 00000000..c89b95e9 --- /dev/null +++ b/open_issues/populate_hurd_git_with_submodules_etc.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!meta title="populate hurd.git with submodules, etc."]] + +Populate the top-level *[Savannah]/hurd.git* with a bunch of submodules +(various translators; everything that's intersting), have it serve as sort of a +tested distribution (because the submodules are versioned), plus adding build +machinery / cross-compilation support, etc. diff --git a/open_issues/pth.mdwn b/open_issues/pth.mdwn index bf9c70d7..12bf5098 100644 --- a/open_issues/pth.mdwn +++ b/open_issues/pth.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 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 @@ -10,8 +11,18 @@ is included in the section entitled [[!tag open_issue_porting]] +IRC, unknown channel, unknown date. + <azeem> seems pth still doesn't work <bddebian> Doesn't build or doesn't work? <azeem> both <azeem> some configure test keep grinding the CPU, same for the test suite <azeem> which apparently runs pth_init() and never returns + + <azeem> actually, pth fails to build right now + <azeem> pth_mctx.c:477: error: request for member '__pc' in something not a structure or union + + <azeem> I know the pth test suite fails (it locks up the machine) or used to fail, so I guess porting work for pth would be needed + <azeem> < marcusb> from reading the pth/PORTING document, porting libpth shouldn't be too hard... + + <youpi> dropped pth [from the channel's topic], as we think we know why it fails (sigaltstack is bogus) diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn index ab233dbb..1723d7d3 100644 --- a/open_issues/resource_management_problems.mdwn +++ b/open_issues/resource_management_problems.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 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 @@ -24,3 +25,5 @@ These issues are what Neal Walfield is working on with his new kernel # Examples * [[configure max command line length]] + + * [[zalloc_panics]] diff --git a/unsorted/ZallocPanics.mdwn b/open_issues/resource_management_problems/zalloc_panics.mdwn index 0b00d7ec..09710022 100644 --- a/unsorted/ZallocPanics.mdwn +++ b/open_issues/resource_management_problems/zalloc_panics.mdwn @@ -1,3 +1,18 @@ +[[!meta copyright="Copyright © 2005, 2007, 2008, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +Written by antrik / Olaf Buddenhagen, last updated: 12 Apr 2007. + The Hurd sometimes crashes with a kernel panic saying someting like: "Panic: zalloc failed: zone map exhausted". These panics are generally caused by some kind of kernel resource exhaustion, but there are several differnt reasons for that. @@ -39,5 +54,3 @@ I started various other experiments with creating child processes (fork bombs), * After opening/leaking lots of ports to /dev/null (32768 it seems), the NULL translator somehow becomes disfunctional, and a new instance is started While most of these Observations clearly show an exhaustion of kernel memory which is not surprising, some of the oddities seem to indicate problems that might deserve further investigation. - --- antrik (Last update: 12 Apr 2007) diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn new file mode 100644 index 00000000..ab6af90b --- /dev/null +++ b/open_issues/select.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +There are a lot of reports about this issue, but no thorough analysis. + +--- + +IRC, unknown channel, unknown date. + + <paakku> This is related to ELinks... I've looked at the select() implementation for the Hurd in glibc and it seems that giving it a short timeout could cause it not to report that file descriptors are ready. + <paakku> It sends a request to the Mach port of each file descriptor and then waits for responses from the servers. + <paakku> Even if the file descriptors have data for reading or are ready for writing, the server processes might not respond immediately. + <paakku> So if I want ELinks to check which file descriptors are ready, how long should the timeout be in order to ensure that all servers can respond in time? + <paakku> Or do I just imagine this problem? diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn new file mode 100644 index 00000000..1f4de59c --- /dev/null +++ b/open_issues/sendmsg_scm_creds.mdwn @@ -0,0 +1,91 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <pinotree> Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2722 + <pinotree> 2722: Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2724 + <pinotree> \o/ + <youpi> \o/ + <pinotree> the patch is even short, after all: http://paste.debian.net/54795/ + --- a/sysdeps/mach/hurd/sendmsg.c + +++ b/sysdeps/mach/hurd/sendmsg.c + @@ -18,6 +18,7 @@ + + #include <errno.h> + #include <string.h> + +#include <unistd.h> + #include <sys/socket.h> + #include <sys/un.h> + + @@ -45,6 +46,7 @@ + mach_msg_type_number_t amount; + int dealloc = 0; + int i; + + struct sockaddr_storage sa; + + /* Find the total number of bytes to be written. */ + len = 0; + @@ -122,6 +124,34 @@ + err = EIEIO; + } + + + memset (&sa, 0, sizeof (struct sockaddr_storage)); + + if (addr) + + { + + memcpy (&sa, addr, addr_len); + + } + + else + + { + + getsockname (fd, (struct sockaddr *) &sa, &addr_len); + + } + + addr = (struct sockaddr_un *) &sa; + + if (message && (addr->sun_family == AF_LOCAL)) + + { + + struct cmsghdr *cm; + + struct msghdr *m = (struct msghdr *) message; + + for (cm = CMSG_FIRSTHDR (m); cm; cm = CMSG_NXTHDR (m, cm)) + + { + + if (cm->cmsg_level == SOL_SOCKET && cm->cmsg_type == SCM_CREDS) + + { + + struct cmsgcred *cred = (struct cmsgcred *) CMSG_DATA (cm); + + cred->cmcred_pid = __getpid (); + + cred->cmcred_uid = __getuid (); + + cred->cmcred_euid = __geteuid (); + + cred->cmcred_gid = __getgid (); + + cred->cmcred_ngroups = getgroups (sizeof (cred->cmcred_groups) / sizeof (gid_t), cred->cmcred_groups); + + } + + } + + } + + + err = HURD_DPORT_USE (fd, + ({ + if (err) + <youpi> what checks that the pid is correct? + <youpi> and uid, etc. + <pinotree> hm? + <youpi> credential is not only about one claiming to the other his uid & such + <youpi> it's about the kernel or whatever authority tell to an end the identity of the other end + <pinotree> yep + <pinotree> but given that the data is then send to pflocal, this code is the last part that runs on the application side + <youpi> pflocal could as well just request the info from proc + <youpi> it will have to anyway, to check that it's true + <pinotree> hm + <pinotree> yeah, though about that, chose this approach as "quicker" (of course not definitive) + <youpi> well at least it shows we're able to transmit something :) + <pinotree> well it just manipulates the data which gets send nicely already ;) + <youpi> but really, it's most probably up to pflocal to check authentication from proc and give it to the other end + <youpi> the application sender part would be just the RPC authentication calls + <youpi> Mmm, just realizing: so receiver part already exists actually, right? + <youpi> (since it's just about letting the application reading from the message structure) + <pinotree> yep + <youpi> ok, good :) diff --git a/open_issues/sudo_date_crash.mdwn b/open_issues/sudo_date_crash.mdwn new file mode 100644 index 00000000..53303abc --- /dev/null +++ b/open_issues/sudo_date_crash.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date. + + <grey_gandalf> I did a sudo date... + <grey_gandalf> and the machine hangs diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn new file mode 100644 index 00000000..f1fbb4e0 --- /dev/null +++ b/open_issues/sync_but_still_unclean_filesystem.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +\#hurd, 2010, end of May / beginning of June + + [runnign sync, but sill unclean filesystem at next boot] + <slpz> guillem: when libpager syncs an object, it sends an m_o_lock_request and waits (if the synchronous argument was specified) for a m_o_lock_completed. But m_o_lock_completed only means that dirty pages have been sent to the translator, and this one still needs to write them to the backing storage + <slpz> guillem: there's no problem if sync() returns before actually writting the changes to disk, but this also happens when shutting down the translator + <slpz> guillem: in theory, locking mechanisms in libpager should prevent this from happening by keeping track of write operations, but this seems to fail in some situations diff --git a/open_issues/syslog.mdwn b/open_issues/syslog.mdwn new file mode 100644 index 00000000..778933a7 --- /dev/null +++ b/open_issues/syslog.mdwn @@ -0,0 +1,7 @@ +IRC, unknwon channel, unknown date. + + <tschwinge> scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725 I see that you intend(ed) to use syslog for logging debug messages. I thought I'd point you to http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html -- no idea if that's still an issue or what went wrong at that time. Perhaps you can have a look? + <scolobb> tschwinge: Thanks for information! Currently I'm logging some debug messages to a simple file, but I'll now check whether the issue you've pointed out is still present. + <scolobb> tschwinge: I am getting absolutely abnormal results: when I call syslog() from a simple C program for the first time, the message goes to the system log. However, any further calls to syslog() do just nothing... I am able to send something to syslog only after reboot (it doesn't help if I restart syslogd). + + diff --git a/open_issues/threads_issues.mdwn b/open_issues/threads_issues.mdwn new file mode 100644 index 00000000..aec216e0 --- /dev/null +++ b/open_issues/threads_issues.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +List of issues w.r.t. the Hurd's many-threads paradigm. + +[[!tag open_issue_hurd]] + + * [[fsync]] diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn new file mode 100644 index 00000000..25a74456 --- /dev/null +++ b/open_issues/translate_fd_or_port_to_file_name.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_hurd]] + +\#hurd, freenode, June (?) 2010 + + <pochu> is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port? + <marcusb> there is a way + <pochu> marcusb: which one would that be? + <marcusb> I forgot + <marcusb> there is an implementation in libc + <marcusb> realpath has a similar job + <marcusb> but that's not what I mean + <marcusb> pochu: maybe I am misremembering. But it was something where you keep looking up .. and list that directory, looking for the node with the ID of the node you had .. for + <marcusb> maybe it works only for directories + <marcusb> yeah + <marcusb> pochu: check the getcwd() implementation of libc + <marcusb> sysdeps/mach/hurd/getcwd.c + <marcusb> _hurd_canonicalize_directory_name_internal + * pochu looks + <pochu> marcusb: interesting + <pochu> though that is for dirs, and doesn't seem to be extensible to files, as you cannot lookup for ".." under a file + <marcusb> right + <pochu> oh you already said that :) + <marcusb> actually, I am not sure that's correct + <marcusb> it's probably correct, but there is no reason why looking .. up on a file couldn't return the directory it's contianed in + <pochu> I don't know the interfaces or the Hurd internals very well yet, but it would look strange to me if you could do that + <marcusb> the hurd is strange + <pochu> it sounds like if you could `ls getcwd.c/..` to get sysdeps/mach/hurd/ :-) + <marcusb> yep + <pochu> ok. interesting + <marcusb> you wouldn't find "ls foo.zip/.." very strange, wouldn't you? + <pochu> I guess not if `ls foo.zip` listed the contents of foo.zip + <marcusb> there you go + <marcusb> or the other way round: would you be surprised if "cat somedir" would work? + <pochu> I think so. if it did, what would it do? + <marcusb> originally, cat dir would list the directory content! + <marcusb> in the old unix times + <pochu> I was surprised the first time I typed `vi somedir` by accident + <marcusb> and some early BSDs + * pochu feels young :-) + <marcusb> he don't worry, I didn't see those times either + <marcusb> technically, files and directories are implemented in the same way in the hurd, they both are objects implementing the fs.defs interface + <marcusb> which combines file and directory operations + <marcusb> of course, files and directories implement those functions differently + <antrik> marcusb: do you know why this behavior (cat on directories) was changed? diff --git a/open_issues/translator_environment_variables.mdwn b/open_issues/translator_environment_variables.mdwn new file mode 100644 index 00000000..cae5a494 --- /dev/null +++ b/open_issues/translator_environment_variables.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <cfhammar> BTW, is settrans -a supposed to clear all env variables? + <cfhammar> or can I consider it a bug ;-) + <cfhammar> scolobb: yeah, seems the problem is in libfshelp + <scolobb> cfhammar: Are you talking about fshelp_start_translator_long? + <scolobb> (I can remember that it does something to the environment indeed) + <cfhammar> scolobb: yes, I think it's the culprit + <cfhammar> clearing the environment makes sense for passive translators I guess, but not active ones + <scolobb> Hm, searching ``env'' in hurd/libfshelp/start-translator-long.c gives me nothing :-( + <scolobb> I think the problem might be in the fact that fshelp_start_translator_long just doesn't copy the environment, but I may be wrong. + <cfhammar> scolobb: yeah, that's my guess also + <scolobb> Well, I don't know proc, but there might be a way to copy the environment to a task when you know its ID, what do you think? + <scolobb> I can see proc_set_arg_locations in process.defs, which sees to set something connected with environment, but I'm not sure whether it suits your needs. + <cfhammar> scolobb: it seems that the env isn't passed to file_exec in fshelp_start_translator_long + <scolobb> cfhammar: Yeah, that's right + <scolobb> I wonder what could the motivation for not passing the environment to a child process + <cfhammar> hmm... fshelp_start_translator_long parameterizes everything except env... + <cfhammar> perhaps there needs to be a fshelp_start_translator_longer ;-) diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn new file mode 100644 index 00000000..e0828b28 --- /dev/null +++ b/open_issues/translator_stdout_stderr.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +Decide / implement / fix that (all?) running (passive?) translators' output +should show up on the (Mach / Hurd) console / syslog. diff --git a/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn b/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn new file mode 100644 index 00000000..5d3c3aab --- /dev/null +++ b/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn @@ -0,0 +1,148 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd open_issue_glibc]] + +bug-hurd email from 2010-07-28: *O_NOTRANS & O_NOFOLLOW* + +2010-07-29, #hurd + + <antrik> cfhammar: I think that touches on a rather fundamental problem... it's always hard to decide how to handle translators, as the most useful approach depends a lot on context + <antrik> this was actually part of the idea behind namespace-based translator selection + <cfhammar> or perhaps we should just drop the whole O_NOFOLLOW == O_NOTRANS and only apply it for link like translators + <pochu> cfhammar: from what I read in [glibc]/hurd/lookup-retry.c, the problem is that some translators can lie about that + <antrik> cfhammar: at some point I considered the possibility of adding a couple of special flags describing translators ("link" and "device" being some, but also introducing a few new ones) to decide standard behaviour in various situations + <pochu> so you can't really know whether they are links without O_NOTRANS + <cfhammar> pochu: yeah, this would have to be considered carefully + <pochu> antrik: care to explain what namespace based translator selection means? :) + <antrik> pochu: the basic idea is that you add special suffixes to the file name during a lookup, which change the behaviour of lookups + <antrik> the most basic use would be adding a suffix that automatically runs an annonymous translator on the file + <cfhammar> antrik: doesn't stat cover most of those flags (except for firmlink i guess) + <antrik> (scolobb mostly implemented that part) + <antrik> but the idea was also to selectively activate/deactivate static translators based on patterns + <antrik> (this is implemented partially, but recursion is completely missing so far) + <antrik> cfhammar: some of them, yes. but I think there are some cases where the standard stat information is not enough to decide on useful handling + <antrik> let's take the example of a translator that mangles the underlying file -- like xmlfs, mboxfs etc. + <antrik> these aren't device file nor links, but should not really be handled like "normal" (store) filesystems either + <antrik> hm... is there any information in the stat that indicates mount points? + <antrik> I guess that would be good enough to flag "normal" filesystems + <pochu> I'm not sure I understand. you add a suffix during a lookup, based on what? whatever, including e.g. flags? + <antrik> pochu: well, an exmple would be "cat foo.gz,,u" + <antrik> where "u" would be a shorthand for "unzip" + <antrik> and it would launch a translator that uncompresses the underlying file + <pochu> what if there are a foo.gz and a foo.gz,,u files? + <antrik> (I think storeio with gzip store can do that... though some more generic translator might be useful, to cover other compression/archieve types as well) + <antrik> pochu: than you are SOL ;-) + <antrik> pochu: I chose ",," as the suffix after some careful examination that this is *extremely* unlikely to occur in normal use + <antrik> pochu: actually, we introduced an escaping scheme too, so it is still possible to access files with ",," in the name... but that's of limited use, as programs not aware of this will still break + <cfhammar> hmm i wonder why glibc handles O_NOFOLLOW to begin with, since the test it does presumes trust in the containing directory the fs could do it just as securely + <antrik> cfhammar: the FS could do what? + <pochu> another problem I've found is that an open(symlink, O_RDONLY | O_NOFOLLOW, 0) should fail with ELOOP according to POSIX, but it doesn't fail on Hurd + <antrik> pochu: yeah, saw that + <antrik> shouldn't be too hard to fix I hope?... + <cfhammar> antrik: libc test whether the node is a symlink or a (trusted) root owned translator, which it would follow + <pochu> antrik: probably not, though I haven't looked at it closely + <antrik> cfhammar: in what situation would the filesystem do the test? + <antrik> cfhammar: and what advantage would it have over the current approach? + <antrik> pochu: OK + <cfhammar> antrik: the point of the test is to approximate symlink vs. mount point but the fs seems to be in a better position to answer this + <antrik> cfhammar: why? I think this information should be fully available to glibc... if it's not, I'd consider this a bug, or at least a major omission + <cfhammar> antrik: well take fifos for instance, they should be considered part of the containing filesystem but would not by glibc + <cfhammar> antrik: we could make an exception in glibc for fifos but not for other future situations in new translators + <cfhammar> antrik: i mean, we could but this leaves control at the translators hand and let different translators handle things their own way + <cfhammar> generally, it seems more flexible to leave policy to servers rather than to bake it into the (implicit) protocol (which glibc implements) + <antrik> cfhammar: I don't see though why handling it in the filesystem would help here... if the filesystem has the information about how the translator should be handled, it can pass it to the clients + <antrik> hm... that's actually a tricky point. we have many situations where we have to choose between handling things in the client library or server-side... I'm haven't really formed an opinion yet which is preferable in general + <pochu> with cfhammar's proposal, you wouldn't need O_NOTRANS when you specify O_NOFOLLOW, right? + <cfhammar> pochu: i don't think my proposal would even work with O_NOTRANS + <antrik> cfhammar: hm, perhaps we are talking past each other. do you want the handling to be in the filesystem containing the underlying node, or in the actual translator implementing the node? + <antrik> hrm + <cfhammar> antrik: the containing filesystem + <cfhammar> (since this is a security issue) + <pochu> yeah, otherwise the trust issue would still be there + <antrik> then why wouldn't it work with O_NOTRANS? + <antrik> BTW, what security issue are you talking about? do you mean the fact that a translator can redirect the lookups to another file, but hide the fact that it's a link? + <pochu> antrik: I mean the O_NOTRANS & O_NOFOLLOW comment in [glibc]/hurd/lookup-retry.c + <cfhammar> antrik: because O_NOTRANS means don't follow translators (including symlinks) and O_NOFOLLOW means don't follow (any) link but do follow translators + <antrik> pochu: I must admit that I never fully understood what that one is about :-) + <cfhammar> antrik: i imagine O_NOTRANS|O_NOFOLLOW == O_NOTRANS + <antrik> cfhammar: I see + <antrik> cfhammar: but I guess that's totally orthogonal from handling in glibc vs. handling in the FS?... + <pochu> AFAIU, it's that if you do an open(translator, O_NOFOLLOW, 0), the translator can lie about it being a symlink. So you need to do an O_NOTRANS lookup + <pochu> hence hurd/hurdlookup.c adds O_NOTRANS if O_NOFOLLOW is present in flags + <antrik> ah, OK + <antrik> so the idea here is that instead of doing that, glibc would only pass on O_NOFOLLOW, and the filesystem would handle the O_NOTRANS part itself + <cfhammar> antrik: if you have O_NOTRANS the filesystem will never follow any translators including non-link ones, so it can't really handle O_NOFOLLOW to exclude link translators + <cfhammar> antrik: yeah + <antrik> AIUI the problem is that with the current scheme, using O_NOFOLLOW will also ignore non-link translators? + <cfhammar> antrik: exactly, including fifos + <cfhammar> antrik: of course, there's still the problem of determining that it is a non-link translator + <antrik> cfhammar: but why can't this be fixed keeping the current scheme? wouldn't it suffice for glibc to ask the filesystem whether there is a link (with O_NOTRANS), and if not, do the actual lookup without O_NOTRANS?... + <pochu> antrik: there's still the problem of translators lying about them being symlinks or not, right? so instead of a blacklist (is it a symlink?) you would need a whitelist + <antrik> pochu: sure. I just don't see how an implementation in the filesystem would do any better on that score than one in glibc + <cfhammar> antrik: the fs is better at maintaining the whitelist, e.g. you could have different whitelist for different translators + <cfhammar> antrik: the fs also knows who own the fs, so it could make exeptions for the owner's translators + <cfhammar> like glibc does for the root user, currently + <antrik> I'm not really convinced so far that having these policies in the filesystem is really preferable to having them in the client-side library... + <cfhammar> antrik: we want to put /hurd/fifo in the whitelist for all users but we can't determine whether an active translator on the underlying node is /hurd/fifo or not, but the FS can if it started the translator itself + <cfhammar> antrik: of course, this can also be done by hiding the /hurd/fifo translator so that glibc doesn't do the test in the first place + <cfhammar> antrik: but this isn't pretty, you'd have to proxy it afaics :-/ + <antrik> cfhammar: TBH, I don't like the whole whilelisting idea + <antrik> seems to me this is really just another manifestation of the infamous firmlink problem + <antrik> as I said in past discussions, I tend to think that the only way to fix it *properly* is changing the way authentification is handled + <antrik> we actually discussed this at some point... when crossing translator boundries, the client shouldn't use it's full permissions on the new translator, but rather the intersection of it's own permissions and that of the parent translator + <antrik> this way, "secret" links should cease to be dangerous... + <cfhammar> yeah, but that'll take way too long for poor pochu ;-) + <antrik> cfhammar: true... but I'm not convinced that a whitelisting hack in the meantime is really worthwhile + <cfhammar> antrik: we already have a whitelisting hack (root user's translators), we're just moving it to the filesystem and adding /hurd/fifo + <antrik> cfhammar: nope, allowing all root translators is a general policy, not a whitelisting hack + <antrik> not elegant either, but a very different class + <cfhammar> antrik: i don't remember the details but fixing firmlink problem seemed to require some fundamental changes, it might even turn out to be unfeasible + <antrik> BTW, it's still not clear to my why the filesystem is supposed to have a better idea which translators to whitelist than glibc?... + <cfhammar> antrik: huh, i don't think i've seen that policy elsewhere, only for root clients not servers + <cfhammar> antrik: for one it can keep track of if the current active translator is the current passive one, and thus know which program it runs + <antrik> do I get it right that in the case of fifo, the client can't generally trust the user running the translator, and thus the idea is instead to trust the translator program?... + <cfhammar> O_NOFOLLOW implies that the client does not trust the file not to redirect it anywhere and we know /hurd/fifo will not do this + <antrik> cfhammar: was that a "yes"?... + <cfhammar> antrik: yes + <antrik> hm... I think I already said it in the context of object migration: I really don't like the idea of trust based on the program being executed... + <antrik> this workaround also has other shortcomings: what if the transaltor is started actively? + <cfhammar> hmm the owner of the translator could hijack it and the fs wouldn't know + <antrik> I must admit though that I don't see another short-term solution either :-( + <antrik> oh, right, that's another problem + <cfhammar> seems like the fs must implement the fifo itself (or atleast hide the /hurd/fifo translator behind a proxy) + <antrik> BTW, what is the specific manifestation of the problem with fifos being ignored on NOFOLLOW? + <pochu> there are two problems + <pochu> one is that with O_NOFOLLOW, it's ext2fs who checks the file permissions, and denies it (dunno the reason for that) + <pochu> the other one is that if you stat the fifo with O_NOFOLLOW and without it, the device will look different (and thus cp believes the file has changed and fails) + <pochu> that's because an stat on the fifo will return the fifo translator's PID as the device + <antrik> ah + <pochu> while one with O_NOFOLLOW will return the partition device + <antrik> so the specific problem here is that the stat info is differenet with the fifo translator than without + <pochu> I'm not sure whether it would be correct & possible to return the device of the parent translator in libtrivfs, instead of the PID + <pochu> yes + <pochu> that, and the permission one (they are different) + <pochu> though both would be solved if O_NOFOLLOW didn't imply O_NOTRANS :) + <antrik> what exactly do you mean by "device" here? + <pochu> I mean st_dev in struct stat + <antrik> well, I wonder whether the permission problem shouldn't actually be considered a bug in fifo. i sthere a good reason why the permissions are not propagated to the underlying node, as with most other translators? + <pochu> I don't think that's the problem + <antrik> what else? + <pochu> it's rather that if you open the fifo with O_NOTRANS, you don't get the underlying node, and then it's ext2fs (and so libdiskfs) who checks the permissions, and it denies them for whatever reason + <pochu> antrik: libdiskfs/dir-lookup.c has this: + <pochu> if (((type == S_IFSOCK || type == S_IFBLK || type == S_IFCHR) + <pochu> >------- && (flags & (O_READ|O_WRITE|O_EXEC))) + <pochu> >------- || (type == S_IFLNK && (flags & (O_WRITE|O_EXEC)))) + <pochu> >-------error = EACCES; + <pochu> so it returns EACCES for the fifo + <pochu> I wonder whether there's a good reason (that I'm missing) for that + <cfhammar> pochu: i think the reason might be that ext2fs denies access because it does not implement those file types itself + <cfhammar> i.e. ext2fs expects them to be opened without O_NOTRANS + <cfhammar> (or opened exclusively for non rwx reasons such as stat or settrans) diff --git a/open_issues/viengoos_make_clean.mdwn b/open_issues/viengoos_make_clean.mdwn new file mode 100644 index 00000000..af2920e7 --- /dev/null +++ b/open_issues/viengoos_make_clean.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_viengoos]] + +IRC, unknown channel, unknown date. + + <neal> tschwinge: If I do a make clean n the root directory, follow that with a configure, configure fails with: configure: error: C compiler cannot create executables + <neal> this is in config.log: /home/neal/src/hurd-l4/build/lib/gcc/i686-pc-viengoos-gnu/4.2.2/../../../../i686-pc-viengoos-gnu/bin/ld: cannot find -lc + <neal> rt + <tschwinge> neal: Should make clean also remove srcdir/gcc/gcc and binutils, as you do it with newlib? + <neal> I'd prefer it not to + <neal> as I use make clean to prep the tree for new configure changes + <neal> and build gcc takes a long time + <neal> (as does newlib, but newlib in this case needs to be rebuilt) diff --git a/open_issues/viengoos_tls_gcc.mdwn b/open_issues/viengoos_tls_gcc.mdwn new file mode 100644 index 00000000..92499903 --- /dev/null +++ b/open_issues/viengoos_tls_gcc.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_viengoos]] + +IRC, unknown channel, unknown date. + + <neal> tschwinge : I'm trying to enable tls for viengoos. This requires compiling gcc with --enable-tls, which enables threading, which pulls in libpthread, which requires newlib headers. + <neal> tschwinge : Unfortunately, I don't see how to install the newlib headers without having gcc + <neal> tschwinge : Have you got any ideas? diff --git a/open_issues/xen_domu_with_ro_hd.mdwn b/open_issues/xen_domu_with_ro_hd.mdwn new file mode 100644 index 00000000..efbd2d18 --- /dev/null +++ b/open_issues/xen_domu_with_ro_hd.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!meta title="Xen domU with a read-only HD"]] + +[[!tag open_issue_xen]] + +read-only hd3 + + foobar:~# e2fsck /dev/hd3 + e2fsck 1.40.11 (17-June-2008) + re-open, hd3 count 5 + re-open, hd3 count 6 + /dev/hd3 was not cleanly unmounted, check forced. + Pass 1: Checking inodes, blocks, and sizes + Pass 2: Checking directory structure + Pass 3: Checking directory connectivity + Pass 4: Checking reference counts + Pass 5: Checking group summary information + /dev/hd3: 2729/262144 files (0.2% non-contiguous), 34116/524288 blocks + Error writing block 1 (Attempt to write block from filesystem resulted in short write). Ignore error<y>? yes + + foobar:~# e2fsck /dev/hd3 + e2fsck 1.40.11 (17-June-2008) + re-open, hd3 count 7 + re-open, hd3 count 8 + e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/hd3 + Could this be a zero-length partition? diff --git a/public_hurd_boxen/installation.mdwn b/public_hurd_boxen/installation.mdwn index ca74a4c6..67878f1a 100644 --- a/public_hurd_boxen/installation.mdwn +++ b/public_hurd_boxen/installation.mdwn @@ -14,6 +14,11 @@ This page documents how installation of a new machine is being done on This method uses *[install_crosshurd](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=install_crosshurd)*. +Another option might be switching to <http://www.informatik.uni-koeln.de/fai/> +or a equivalent system. + +Steps for *install_crosshurd*: + * Enable loggin with screen (`C-a H`). * \# lvcreate ... diff --git a/public_hurd_boxen/installation/snubber.mdwn b/public_hurd_boxen/installation/snubber.mdwn index dbbade9f..2fd52d4f 100644 --- a/public_hurd_boxen/installation/snubber.mdwn +++ b/public_hurd_boxen/installation/snubber.mdwn @@ -13,11 +13,13 @@ License|/fdl]]."]]"""]] apache2-mpm-worker build-essential git-core gitweb ikiwiki inetutils-inetd less libtext-csv-perl netcat nullmailer perlmagick screen texinfo - $ find /etc/rc*/ | grep syslog | sudo xargs rm +Yet more: + + * libemail-send-perl (for my *sendmail vs. ikiwiki* patch) - Yet more: +## [[open_issues/syslog]] - * libemail-send-perl (for my *sendmail vs. ikiwiki* patch) + $ find /etc/rc*/ | grep syslog | sudo xargs rm # `~hurd-web/` diff --git a/source_repositories.mdwn b/source_repositories.mdwn index 5789cf86..41ca37be 100644 --- a/source_repositories.mdwn +++ b/source_repositories.mdwn @@ -192,3 +192,13 @@ really need to, you can clone it like this: ## List of Interesting Repositories * web pages: git://flubber.bddebian.com/~hurd-web/hurd-web + + +# Debian Git repositories + +IRC, #hurd, 2010-07-31 + + <tschwinge> git-buildpackage is to be used to build these new Debian repositories, I guess? + <youpi> well, the Vcs-Git control header is about everything people need to know, I believe :) + <youpi> git-buildpackage is just mostly an easy way to build the .orig.tar.Gz from the tag + <youpi> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html diff --git a/tag/open_issue_documentation.mdwn b/tag/open_issue_documentation.mdwn new file mode 100644 index 00000000..eb7f87a2 --- /dev/null +++ b/tag/open_issue_documentation.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 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]]."]]"""]] + +[[!meta title="open_issue_documentation"]] + +[[!map +pages="tagged(open_issue_documentation)" +show=title]] diff --git a/tag/open_issue_pthread.mdwn b/tag/open_issue_libpthread.mdwn index 0ccb1002..b4b7723e 100644 --- a/tag/open_issue_pthread.mdwn +++ b/tag/open_issue_libpthread.mdwn @@ -8,8 +8,8 @@ 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]]."]]"""]] -[[!meta title="open_issue_pthread"]] +[[!meta title="open_issue_libpthread"]] [[!map -pages="tagged(open_issue_pthread)" +pages="tagged(open_issue_libpthread)" show=title]] diff --git a/user/jkoenig.mdwn b/user/jkoenig.mdwn index fd02c328..6045f936 100644 --- a/user/jkoenig.mdwn +++ b/user/jkoenig.mdwn @@ -183,43 +183,77 @@ installer kindof works, with documented manual intervention required** so that the mirror is authenticated in the target system as well. (2010-07-12) -* Fix grub for user-space partitions (expected 2010-07-12) - * Currently, when using user-space partitions, - grub-probe detects the whole device rather than the partition +* (./) Fix grub for user-space partitions (2010-07-16) + * grub-probe detects the whole device rather than the partition as the device behind /boot/grub. Consequently, grub-install fails. * One approach would be to replace /dev/hd* by kernel devices for file systems as well as for swap partitions. - * On the other hand, grub-probe will need to be fixed - sooner or later for user-space partition support, - and parsing the fsysopts would possibly be an option. + > {X} this makes the installer crash, + > possibly due to cache coherency issue between hdX and hdXsY. -* **d-i/installer/build**: (expected 2010-07-12) + * (./) GRUB2 kern/emu/getroot.c + [patched](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00059.html) + to support part stores. + +* (./) Fix finish-install to skip `finish-install.d/90console` on Hurd + (2010-07-17) + +* (./) Avoid starting unnecessary /dev translators in a burst (2010-07-20) + * Use debootstrap use the extracted /usr/lib/hurd/setup-translators + to create device and server nodes in /target, + then firmlink the whole /target/dev and /target/servers + to the outer system. + * Make hurd.postinst not touch them on initial install. + +* (./) Fix mach-defpager for file and part stores on larger devices + * Use DEVICE_GET_RECORDS instead of DEVICE_GET_SIZE, which overflows an int + (2010-07-22) + +**Milestone (2010-07-22): +installer works but it's still somewhat ugly and broken** + +* (./) Ship the uft-8 font for the hurd console + (2010-07-22) + * Upload a version of bogl with youpi's patch for Hurd. + (see [[!debbug 589987]]) + * Fix the hurd console for fonts with 16 pixels wide glyphs + (ie. handle the 8-wide glyph in there correclty) + * Support double-width glyphs (2010-07-24) + * {X} However the reduced font can't be loaded yet, + so make installer/build/Makefile + ship the whole `/usr/src/unifont.bgf` + as `/usr/share/hurd/vga-system.bgf`. + +* (./) Make the installer used the extended capabilities of the Hurd console + (2010-07-23) + * Set an UTF-8 locale in `/lib/debian-installer.d/S41term-hurd`. + * localechooser: set the language display level to 3 + when using the hurd console. + +* **d-i/installer/build**: (expected soon) * publish the patch I use * sort out the changes suitable for inclusion and ask youpi and/or debian-boot@l.d.o to commit them -**Milestone (expected 2010-07-12): -installer works but it's still somewhat ugly and broken** - * call for testing and fix the bugs -* See if it would be possible to avoid accessing devices - when firmlinking them into the target system. - * Who does that? - * find should prune them as instructed, - and avoid a stat/readdir as a result - * showtrans shouldn't access the translator itself - * firmlink should access the target only when it is used - -* In the same vein, permissions on underlying nodes - are probably broken when created by hurd through `MAKEDEV -k`, - and doing the actual chmod/chown accesses the device +* Bug in setup-translators/MAKEDEV: + permissions are broken for nodes re-created through `MAKEDEV -k`, + because MAKEDEV's chmod/chown reaches the pre-existing translator * Maybe settrans could be made to accept -o/--owner and -p/--perm, to set the permissions for the underlying node? * Silence the "no kernel" warning somehow. +* Investigate the wget/libc/pfinet/whatever bug which corrupts Packages.gz, + see the IRC log for 2010-07-23, around 1am UTC+0200 + +* Try to resolve problems with udebs which are uninstallable on hurd-i386, + such as installation-locale and partman-whatever. + +* Provide `/proc/cmdline -> 2/cmdline`, or something. + * Prepare a NMU for genext2fs (which is orphaned), and ask youpi to sponsor the upload. @@ -236,16 +270,17 @@ installer works but it's still somewhat ugly and broken** * Network configuration on the installed system. This includes porting ifupdown and isc-dhcp-client, which are currently uninstallable on hurd-i386. +* Also, better DHCP support during and after installation * improve the [initrd situation](FIXME: link to bug-hurd post): ajust the ramdisk support in Mach, - use tmpfs if possible, - possibly add `module -nounzip` to grub2. + use tmpfs if possible. + * mklibs{,-copy}: test library reduction, make it copy the ld.so -> ld.so.1 symlink. + * hurd console fonts -* better DHCP support during and after installation **Milestone (expected 2010-07-19): it works great and it's beautiful** diff --git a/user/kam.mdwn b/user/kam.mdwn index 66b48e58..8ee68866 100644 --- a/user/kam.mdwn +++ b/user/kam.mdwn @@ -65,9 +65,9 @@ Stage 1: ####26th of May - 28th of May: -* port OSF Mach's clustered pagein during 'page faults' ( [src]/vm/vm_fault.c ) -* port "cluster_size" attribute of memory objects from OSF Mach. -* port "behavior" attribute of vm_map entries from OSF Mach. +* (./) port OSF Mach's clustered pagein during 'page faults' ( [src]/vm/vm_fault.c ) +* (./) port "cluster_size" attribute of memory objects from OSF Mach. +* (./) port "behavior" attribute of vm_map entries from OSF Mach. ####29th of May - 2nd of June: @@ -89,7 +89,7 @@ Stage 2: ####5th of July - 7th of July: -* Added "cluster_size" attribute to Neal Walfield's patch for the pager library. +* (./) Add "cluster_size" attribute to Neal Walfield's patch for the pager library. --- @@ -97,14 +97,14 @@ Stage 3: ####8th of July - 15th of July: -* Patch the diskfs library to use the new pager library API. -* Patch the ext2fs disk paging related routines to use the new pager library API. -* Patch the mach-defpager API to use the new pager library API. +* (./) Patch the diskfs library to use the new pager library API. +* (./) Patch the ext2fs disk paging related routines to use the new pager library API. ####16th of July - 19th of July: -* Testing the current patches, if possible. +* Testing the current patches. +* Stuck in compiling code ( http://30.media.tumblr.com/tumblr_l5ie1bb2u91qbjipvo1_500.jpg ) , so I started reading some documentation meanwhile ( [0] , [1] ). --- @@ -112,7 +112,8 @@ Stage 4: ####19th of July - 31th of June: -* Port the rest of the translators to the new pager library API +* Check OSF Mach's mach-defpager. +* Patch (or port OSF Mach's default pager) HURD's mach-defpager to use the new gnumach's RPCs. --- @@ -137,6 +138,15 @@ TODO: * Update the documentation of GNU Mach with the new interfaces. -* Revise and finish the code related to default_memory_manager management in GNU Mach. [done] +* (./) Revise and finish the code related to default_memory_manager management in GNU Mach. [done] * Port the vm_page "clustered" attribute. [ to mark that the page wasn't requested but was paged-in as part of the cluster ]. + + +--- + + +# Readings + +[0] http://www.nongnu.org/ext2-doc/ext2.html +[1] http://kerneltrap.org/node/452 diff --git a/user/pochu.mdwn b/user/pochu.mdwn index 164f8900..18e90de3 100644 --- a/user/pochu.mdwn +++ b/user/pochu.mdwn @@ -26,25 +26,17 @@ truly GNU/Hurd issues (and not problems in the projects themselves), fixing them. ## Timeline -* May 24th: Students begin coding for their GSoC projects -* May 31st: GLib and GNU coreutils done -* June 8th: End of classes -* June 28th: Python done -* July 9th: End of exams -* July 12th: Perl done -* July 16th: Mid-term evaluations deadline -* August 1st: DebConf +* July 18th: GLib finished. +* July 22nd: coreutils finished. +* July 25th: All Perl failures investigated. +* August 5th: Perl finished. +* August 8th: All Python failures investigated. +* August 16th: Python finished. * August 16th: Firm 'pencils down' date - ## TODO -* Send copyright paperwork back to the FSF. -* Bug 28934: Address comments on the patches. -* Bug 29655: Submit to libc-alpha when the copyright assignment is on file. -* Implement getsockopt() in hurd/pflocal/socket.c -* Send a summary to bug-hurd explaining the O_NOFOLLOW & O_NOTRANS problem. * Investigate why coreutils' nice test fails. - +* Analyze Perl's testsuite failures. ## Documentation * [Towards a New Strategy of OS Design, an architectural overview by Thomas Bushnell, BSG](http://www.gnu.org/software/hurd/hurd-paper.html) @@ -54,6 +46,41 @@ fixing them. ## Log +### July 26th - August 1st +* Tested /dev/fd/N patches and sent them for review. +* Finished SCM_RIGHTS patch. Created a minimal testcase without using + glibc to demonstrate the socket_send/recv failure with non-socket + fds. Sent the testcase and the patch for review. +* Investigated cp issues with O_NOFOLLOW & O_NOTRANS. Sent a mail to + bug-hurd explaining both issues and possible solutions. + +### July 19th - July 25th +* Initial SCM_RIGHTS implementation. Seems to work when sending pipes, but + fails miserably when sending fds from an open syscall. No idea why yet. +* Fixed memleaks in sendmsg() while implementing SCM_RIGHTS. Patch accepted + upstream. +* Had to build glibc thrice because the system crashed and the fs was totally + corrupted. I'll build stuff in a separate partition as suggested from now on. + Doesn't help. It turns out the issue seems to be with kvm, or at least it's + only reproducible for me there. I've switched to VirtualBox and there are no + filesystem issues there. +* Addressed comments in the /dev/fd/N patches. Need to test them (when I can + build glibc and Hurd without the system crashing). + +### July 14th - July 18th +* Catched up with email. +* Prepared a patch to implement getsockopt(fd, SOL_SOCKET, SO_TYPE, ...). + Patch committed to Hurd. +* Addressed comments in the /dev/fd/N patches and resent them. +* Investigated another glib's unix-fd failure: passing fds over a socket using + sendmsg() doesn't dup them. Created a minimal testcase. Prepared a preliminary + patch, needs testing and fixing. + +### May 26 - July 13th +* Copyright assignment on file. +* Studied a lot to finish my BSc. +* Got the linkat patch (Savannah #29655) committed upstream. + ### May 19 - May 26 * Read [MIG - The MACH Interface Generator](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps) * Worked on bug 28934. Send [patches](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html) for review. @@ -92,3 +119,18 @@ fixing them. patch for it. * Investigated coreutils' cp EACCES. Test case: 'mkfifo a && cp -R --copy-contents a b'. Problem is that O_NOFOLLOW adds O_NOTRANS. + +## Midterm Evaluation +### Accomplished +* Assigned copyright to the FSF. +* Read many documentation and source code. +* /dev/fd/N bug fixed +* Prepared a patch for getsockopt() +* Fixed linkat() problems. +* Investigated bug with O_NOFOLLOW & O_NOTRANS (needs more work). +* Investigated a glib test failure (garray). Not a Hurd issue. +### Downtime +* Studied a lot to finish my BSc. Didn't work on Hurd for a month because of + that, so that's why I couldn't make a lot of progress (this was known in + advance, although in the end the downtime was a bit larger than expected). +* There's no expected downtime from now on. |