diff options
52 files changed, 1603 insertions, 423 deletions
@@ -45,6 +45,8 @@ fact simply forwarded to/implemented as [[system_call]]s. * [[signal/signal_thread]] + * [[startup]] + ## Concepts @@ -56,6 +58,8 @@ fact simply forwarded to/implemented as [[system_call]]s. * [[signal]] + * [[ioctl]] + ## Individual functions diff --git a/glibc/ioctl.mdwn b/glibc/ioctl.mdwn new file mode 100644 index 00000000..e1a86f32 --- /dev/null +++ b/glibc/ioctl.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2011-10-31: + + <pinotree> is there some example of translator replying to custom ioctl's? + <pinotree> let's say you define some ioctl (those which can be represented) + using the _IOW etc macros; how would a translator (or something else) + "register" and reply to them? + <youpi> it's not an easy thing + <youpi> see hurd/hurd/tioctl.defs for instance + <youpi> that's where the 't' ioctls end up + <youpi> ('t' being the group in the _IOW macro) + <braunr> it's not that hard either + <pinotree> youpi: so you "roll" the ioctl to an ipc call with proper + parameters? + <braunr> yes + <pinotree> ah ok, i thought there was some way to hook new ioctl's, and + have libc send the whole stuff at once + <braunr> and the proper number (with a clear name) + <braunr> hm + <braunr> for many ioctls, you don't have to change libc + <youpi> yes, there's a script which produces the .defs from _IOW calls, + iirc + <youpi> or something like this + <youpi> there's also a hook thing in glibc, but for "sane" ioctls, that's + not needed + <youpi> (_hurd_lookup_ioctl_handler called by ioctl()) + <youpi> yes, see the rules in hurd/hurd/Makefile + <youpi> "The following rules assist in creating an `Xioctl.defs' file to + define RPCs that are sent primarily by ioctl commands." + <antrik> well, you can have perfectly sane ioctl()s that still can't be + expressed within the constraints of the IO* macros... but admittedly + that's rather uncommon + <antrik> (unless you consider passing of structs generally insane...) + <youpi> I didn't want to spend time on finding an appropriate adjective + instaed of "sane" + <youpi> while I knew he would understand what I meant (and you did) + <youpi> (though maybe not actually) + <youpi> by "sane", I mean, which use _IOW properly + <youpi> i.e. with a group, proper numbers, etc. + <youpi> (the imposed contraints on the parameters is obviously a flaw in + the hurdish ioctl design, and not insanity from structures) diff --git a/glibc/startup.mdwn b/glibc/startup.mdwn new file mode 100644 index 00000000..b7ab9d96 --- /dev/null +++ b/glibc/startup.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +Be it statically or dynamically linked, the *startup* of glibc-based programs +is quite hairy on GNU Hurd systems. + +[[!taglink open_issue_documentation open_issue_glibc]] + + * [[!message-id "200103081944.f28JiDk00232@delius.kettenis.local"]] + + * [[!message-id "3B7BF2B1.1417CD84@alcor.concordia.ca"]] + + * [[!message-id "871xc9qv6y.wl@ulysses.g10code.de"]] @@ -90,9 +90,9 @@ in the *unstable* branch of the Debian archive. * [[libports]] * [[libstore]] * [[libchannel]] - * [[libhello_example]] -- Hurd library example * [[libtrivfs]] * [[libnetfs]] -- short introductory material + * [[libdiskfs]] * [[libihash]] * [[libpthread]] * [[IO_Path]] diff --git a/hurd/building.mdwn b/hurd/building.mdwn index a7066465..c0d5648c 100644 --- a/hurd/building.mdwn +++ b/hurd/building.mdwn @@ -1,10 +1,5 @@ -Additional to the following text, a further [[example]] has be posted. - /!\ The following information may very well be incomplete and out-dated. - -# Building the Hurd from Source - If you want to build the Hurd libraries and servers (translators) yourself instead of just using pre-built binaries, follow these instructions. @@ -18,8 +13,10 @@ for the GNU Hurd. You can either compile on a GNU/Hurd system, or need a cross-compiler targeting GNU/Hurd. Our [[toolchain page|toolchain]] has the details. +[[!toc]] + -## Getting the Source Code +# Getting the Source Code You can chose between getting the [sources from the developers's git](http://savannah.gnu.org/git/?group=hurd): @@ -36,9 +33,9 @@ Please see the Debian [[running/debian/FAQ]] before using `apt-get source`. The unpacked source tree is around 20 MiB, and the build tree (configured with `--disable-profile`) is around 100 MiB. -## Preparing for the Build +# Preparing for the Build -### ... on Debian systems +## ... on Debian systems Building the Hurd requires the *build-essential* and *fakeroot* packages, their dependencies and additional packages that are specified by the source hurd @@ -47,13 +44,13 @@ package: # apt-get install build-essential fakeroot # apt-get build-dep hurd -### ... on non-Debian systems +## ... on non-Debian systems [TODO] -## Building +# Building -### Debian `.deb` Files +## Debian `.deb` Files Change into the directory with the downloaded / unpacked Hurd sources, e.g. @@ -71,7 +68,7 @@ process with The `.deb` packages will then drop out at the `../` directory. -### Building, but not the Debian Way +## Building, but not the Debian Way The Hurd has to be built in a separate directory: @@ -100,7 +97,7 @@ This will automatically build all libraries that are required to build the requested server or library. -## RPC IDs +# RPC IDs [TODO: update / integrate somewhere.] @@ -116,3 +113,163 @@ mapping between the number of the RPC call and its name: Now you can use this file in the following way: $ rpctrace -i ~/hurd.msgids ls + + +# Testing + +Any statically linked binaries (`make proc && (cd proc/ && make proc.static)`) +can be used directly, as they are self-contained regarding the Hurd libraries +they're using. + +Dynamically linked binaries will use the system's shared Hurd libraries, which +may be or may not be what you want. + +Check: + + $ ldd utils/ps + libhurdbugaddr.so.0.3 => /lib/libhurdbugaddr.so.0.3 (0x01036000) + libps.so.0.3 => /lib/libps.so.0.3 (0x01038000) + libihash.so.0.3 => /lib/libihash.so.0.3 (0x0104a000) + libshouldbeinlibc.so.0.3 => /lib/libshouldbeinlibc.so.0.3 (0x0104e000) + libc.so.0.3 => /lib/i386-gnu/libc.so.0.3 (0x0105a000) + libhurduser.so.0.3 => /lib/i386-gnu/libhurduser.so.0.3 (0x011eb000) + libmachuser.so.1 => /lib/i386-gnu/libmachuser.so.1 (0x01211000) + /lib/ld.so => /lib/ld.so.1 (0x00001000) + +Run: + + $ utils/ps + [...] + +For example, if you have done changes to [[libps]] and now want to test them +with `ps` (which dynamically links to libps), this is not good. To overcome +this, `LD_LIBRARY_PATH` can be used: + +Check: + + $ LD_LIBRARY_PATH="$PWD"/libps ldd utils/ps + libhurdbugaddr.so.0.3 => /lib/libhurdbugaddr.so.0.3 (0x01036000) + libps.so.0.3 => /home/thomas/tmp/hurd/git.build/libps/libps.so.0.3 (0x01038000) + libihash.so.0.3 => /lib/libihash.so.0.3 (0x0104b000) + libshouldbeinlibc.so.0.3 => /lib/libshouldbeinlibc.so.0.3 (0x0104e000) + libc.so.0.3 => /lib/i386-gnu/libc.so.0.3 (0x0105a000) + libhurduser.so.0.3 => /lib/i386-gnu/libhurduser.so.0.3 (0x011eb000) + libmachuser.so.1 => /lib/i386-gnu/libmachuser.so.1 (0x01211000) + /lib/ld.so => /lib/ld.so.1 (0x00001000) + +Run: + + $ LD_LIBRARY_PATH="$PWD"/libps utils/ps + [...] + +Additionally, a `hurd-build/lib` directory is populated with links to *all* +shared Hurd libraries. + +Check: + + $ LD_LIBRARY_PATH="$PWD"/lib ldd utils/ps + libhurdbugaddr.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libhurdbugaddr.so.0.3 (0x0102b000) + libps.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libps.so.0.3 (0x0102d000) + libihash.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libihash.so.0.3 (0x01040000) + libshouldbeinlibc.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libshouldbeinlibc.so.0.3 (0x01043000) + libc.so.0.3 => /lib/i386-gnu/libc.so.0.3 (0x0105a000) + libhurduser.so.0.3 => /lib/i386-gnu/libhurduser.so.0.3 (0x011eb000) + libmachuser.so.1 => /lib/i386-gnu/libmachuser.so.1 (0x01211000) + /lib/ld.so => /lib/ld.so.1 (0x00001000) + +Run: + + $ LD_LIBRARY_PATH="$PWD"/lib utils/ps + [...] + +Likewise, if there is a reason to, it is possible to use the system's `/bin/ps` +with a freshly built libps: + + $ LD_LIBRARY_PATH="$PWD"/libps /bin/ps + [...] + +Etc. + +And, the same is possible with [[translator]]s, too. + +Check, system's shared Hurd libraries: + + $ ldd tmpfs/tmpfs + libhurdbugaddr.so.0.3 => /lib/libhurdbugaddr.so.0.3 (0x01036000) + libdiskfs.so.0.3 => /lib/libdiskfs.so.0.3 (0x01038000) + libpager.so.0.3 => /lib/libpager.so.0.3 (0x01060000) + libiohelp.so.0.3 => /lib/libiohelp.so.0.3 (0x01069000) + libfshelp.so.0.3 => /lib/libfshelp.so.0.3 (0x0106c000) + libstore.so.0.3 => /lib/libstore.so.0.3 (0x01072000) + libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x010ba000) + libports.so.0.3 => /lib/libports.so.0.3 (0x010c1000) + libihash.so.0.3 => /lib/libihash.so.0.3 (0x010ca000) + libshouldbeinlibc.so.0.3 => /lib/libshouldbeinlibc.so.0.3 (0x010ce000) + libc.so.0.3 => /lib/i386-gnu/libc.so.0.3 (0x010da000) + libmachuser.so.1 => /lib/i386-gnu/libmachuser.so.1 (0x0126b000) + libhurduser.so.0.3 => /lib/i386-gnu/libhurduser.so.0.3 (0x01282000) + libparted.so.0 => /lib/libparted.so.0 (0x012a8000) + libuuid.so.1 => /lib/libuuid.so.1 (0x01315000) + libdl.so.2 => /lib/i386-gnu/libdl.so.2 (0x01319000) + /lib/ld.so => /lib/ld.so.1 (0x00001000) + +Check, local libdiskfs, and otherwise system's shared Hurd libraries: + + $ LD_LIBRARY_PATH="$PWD"/libdiskfs ldd tmpfs/tmpfs + libhurdbugaddr.so.0.3 => /lib/libhurdbugaddr.so.0.3 (0x01036000) + libdiskfs.so.0.3 => /home/thomas/tmp/hurd/git.build/libdiskfs/libdiskfs.so.0.3 (0x01038000) + libpager.so.0.3 => /lib/libpager.so.0.3 (0x01061000) + libiohelp.so.0.3 => /lib/libiohelp.so.0.3 (0x01069000) + libfshelp.so.0.3 => /lib/libfshelp.so.0.3 (0x0106c000) + libstore.so.0.3 => /lib/libstore.so.0.3 (0x01072000) + libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x010ba000) + libports.so.0.3 => /lib/libports.so.0.3 (0x010c1000) + libihash.so.0.3 => /lib/libihash.so.0.3 (0x010cb000) + libshouldbeinlibc.so.0.3 => /lib/libshouldbeinlibc.so.0.3 (0x010ce000) + libc.so.0.3 => /lib/i386-gnu/libc.so.0.3 (0x010da000) + libmachuser.so.1 => /lib/i386-gnu/libmachuser.so.1 (0x0126b000) + libhurduser.so.0.3 => /lib/i386-gnu/libhurduser.so.0.3 (0x01282000) + libparted.so.0 => /lib/libparted.so.0 (0x012a9000) + libuuid.so.1 => /lib/libuuid.so.1 (0x01315000) + libdl.so.2 => /lib/i386-gnu/libdl.so.2 (0x01319000) + /lib/ld.so => /lib/ld.so.1 (0x00001000) + +Check, all local shared Hurd libraries: + + $ LD_LIBRARY_PATH="$PWD"/lib ldd tmpfs/tmpfs + libhurdbugaddr.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libhurdbugaddr.so.0.3 (0x0102b000) + libdiskfs.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libdiskfs.so.0.3 (0x0102d000) + libpager.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libpager.so.0.3 (0x01056000) + libiohelp.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libiohelp.so.0.3 (0x0105e000) + libfshelp.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libfshelp.so.0.3 (0x01061000) + libstore.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libstore.so.0.3 (0x01066000) + libthreads.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libthreads.so.0.3 (0x010ae000) + libports.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libports.so.0.3 (0x010b6000) + libihash.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libihash.so.0.3 (0x010be000) + libshouldbeinlibc.so.0.3 => /home/thomas/tmp/hurd/git.build/lib/libshouldbeinlibc.so.0.3 (0x010c1000) + libc.so.0.3 => /lib/i386-gnu/libc.so.0.3 (0x010d8000) + libmachuser.so.1 => /lib/i386-gnu/libmachuser.so.1 (0x01269000) + libhurduser.so.0.3 => /lib/i386-gnu/libhurduser.so.0.3 (0x01281000) + libparted.so.0 => /lib/libparted.so.0 (0x012a7000) + libuuid.so.1 => /lib/libuuid.so.1 (0x01313000) + libdl.so.2 => /lib/i386-gnu/libdl.so.2 (0x01317000) + /lib/ld.so => /lib/ld.so.1 (0x00001000) + +Run, system's shared Hurd libraries: + + $ settrans -ca tmp-0 /usr/bin/env "$PWD"/tmpfs 32M + +Run, local libdiskfs, and otherwise system's shared Hurd libraries: + + $ settrans -ca tmp-0 /usr/bin/env LD_LIBRARAY_PATH="$PWD"/libdiskfs "$PWD"/tmpfs 32M + +Run, all local shared Hurd libraries: + + $ settrans -ca tmp-0 /usr/bin/env LD_LIBRARAY_PATH="$PWD"/lib "$PWD"/tmpfs 32M + +Likewise, if there is a reason to, it is possible to use the system's +`/hurd/tmpfs` with a freshly built libdiskfs: + + $ settrans -ca tmp-0 /usr/bin/env LD_LIBRARAY_PATH="$PWD"/libdiskfs /hurd/tmpfs 32M + +Etc. diff --git a/hurd/building/example.mdwn b/hurd/building/example.mdwn deleted file mode 100644 index 7c84b102..00000000 --- a/hurd/building/example.mdwn +++ /dev/null @@ -1,60 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008 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]]."]]"""]] - -I checked out the source code on my Ubuntu GNU/Linux system connected to the -Internet using: - - git clone git://git.sv.gnu.org/hurd/hurd.git - -I mounted the hurd directory on Ubuntu from my GNU Hurd system connected to the -LAN through NFS: - - settrans -ac /mnt /hurd/nfs ubuntu:/home/shaks/code - -Copy the hurd directory, locally. - -For compilation, you require build-essential, libc0.3-dev, hurd-dev. I used -Debian GNU Hurd K10 CDs for installation and they are available in the first -CD. - - apt-get update - apt-get install build-essential libc0.3-dev hurd-dev - -Enter into the hurd directory and start building it: - - cd hurd - mkdir build - cd build - ../configure - make - -There is a "libiohelp needed by" error. So, do a manual compilation for -libiohelp. - - cd .. - make libiohelp - cd build - make - -There is a "libiostore needed by" error. So, do a manual compilation for -libiostore. - - cd .. - make libiostore - cd build - make - -There is a "libiohelp.so: No such file or directory" error. - -Copy libiohelp/libiohelp.so file to build/libiohelp/ and re-run make, - - make - -The executables are created in the subdirectories in build/ directory. diff --git a/hurd/libdiskfs.mdwn b/hurd/libdiskfs.mdwn new file mode 100644 index 00000000..dd499785 --- /dev/null +++ b/hurd/libdiskfs.mdwn @@ -0,0 +1,42 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + + +# Paging + +In the course of Maksym's [[translator/tmpfs]] work: + +IRC, freenode, #hurd, 2011-10-24: + + <mcsim> I've compared the way pagers are handled in ext2fs and found out + that for every file new pager is created when occurs reading or writing + to this file. Is it necessary? And can one pager handle several memory + objects? + <antrik> mcsim: yes, this in necessary. one pager port corresponds to one + memory object + <antrik> mcsim: note that a pager, from the kernel's point of view, is + essentially just the port used to communicated with the process + responsible for paging the object. how your process manages multiple + pager ports is up to you + <mcsim> so, how can I attach those pager_* functions, which are declared + now in pager-stubs.c to new pager? + <mcsim> or is it done automatically with all pagers, which I create, If + only I'm not using default one? + <antrik> I'm not sure how libpager works; but I suspect it's based on + libports. you probably need a port class for the pager ports, and add the + port for each new pager your create to that class + <antrik> (of course you also need to add it to some port bucket. if you use + a single dispatcher for everything, this would be the default bucket; if + you want a separate thread for pager handling, you'd have to create an + extra bucket for the pagers) + +This is the `diskfs_get_filemap` function that a `libdiskfs` client has to +provide; used in `libdiskfs/rdwr-internal.c:_diskfs_rdwr_internal`, which in +turn is used by the [[interface/io_read]]/[[interface/io_write]] RPCs. diff --git a/hurd/libhello_example.mdwn b/hurd/libhello_example.mdwn deleted file mode 100644 index 2c5490e2..00000000 --- a/hurd/libhello_example.mdwn +++ /dev/null @@ -1,167 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008 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]]."]]"""]] - -## Howto write a Hurd library - -Build the Hurd sources: ------------------------- - -Refer to this [[hurd/building/example]]. - -Create the library files: ----------------------- - -Create a directory, say, libhello in the Hurd sources directory. - -Create a lhello.h header file: - - /* lhello.h - Example library header file. - Copyright (C) 2006 Free Software Foundation, Inc. - Written by Shakthi Kannan <shaks@shakthimaan.com>. - - This file is part of the GNU Hurd. - - The GNU Hurd is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2, or (at - your option) any later version. - - The GNU Hurd is distributed in the hope that it will be useful, but - WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - General Public License for more details. - - You should have received a copy of the GNU General Public License - along with the GNU Hurd; if not, write to the Free Software - Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ - - #ifndef _HURD_HELLO_H - #define _HURD_HELLO_H 1 - - struct hello - { - int x; - }; - - #endif /* _HURD_HELLO_H */ - -Replace filename, year, author name and e-mail address appropriately. - -Create a lhello.c file: - - /* lhello.c - Example library .c file. - Copyright (C) 2006 - Free Software Foundation, Inc. - Written by Shakthi Kannan <shaks@shakthimaan.com>. - - This file is part of the GNU Hurd. - - The GNU Hurd is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by - the Free Software Foundation; either version 2, or (at your option) - any later version. - - The GNU Hurd is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with the GNU Hurd; see the file COPYING. If not, write to - the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */ - - #include "lhello.h" - - void - print_hello (void) - { - struct hello example; - example.x = 2; - printf ("foo and bar are %d words!\n", example.x); - } - -Replace header file year, author name and e-mail address appropriately. - -Create a Makefile - - # - # Copyright (C) 2006 Free Software Foundation, Inc. - # - # This file is part of the GNU Hurd. - # - # The GNU Hurd is free software; you can redistribute it and/or - # modify it under the terms of the GNU General Public License as - # published by the Free Software Foundation; either version 2, or (at - # your option) any later version. - # - # The GNU Hurd is distributed in the hope that it will be useful, but - # WITHOUT ANY WARRANTY; without even the implied warranty of - # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - # General Public License for more details. - # - # You should have received a copy of the GNU General Public License - # along with this program; if not, write to the Free Software - # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - - dir := libhello - makemode := library - - libname := libhello - SRCS = lhello.c - installhdrs = lhello.h - LCLHDRS = $(installhdrs) - - OBJS = $(SRCS:.c=.o) - - include ../Makeconf - -Update the Makeconf file: - -Add libhello to lib-subdirs target in the top-level Makefile in the Hurd -sources. - - cd build - ../configure - make - -Testing the library -------------------- - -Write a file, say, foo.c: - - /* foo.c */ - - #define _GNU_SOURCE - - int - main (int argc, char *argv[]) - { - print_hello(); - return 0; - } - -Static compilation and linking method: - - gcc -g -o foo foo.c -L/path/to/libhello -lhello -static - -Run the example: - - ./foo - -Compilation and dynamic linking method: - - LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/libhello - gcc -g -o foo foo.c -L/path/to/libhello -lhello - -where /path/to/libhello = /path/to/hurd/build/libhello - -Run the example: - - ./foo diff --git a/hurd/libstore/examples/ramdisk/discussion.mdwn b/hurd/libstore/examples/ramdisk/discussion.mdwn new file mode 100644 index 00000000..d73bf903 --- /dev/null +++ b/hurd/libstore/examples/ramdisk/discussion.mdwn @@ -0,0 +1,72 @@ +[[!meta copyright="Copyright © 2011 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, freenode, #hurd, 2011-10-15 + + <antrik> youpi: I'm not at all talking about ordinary tmpfs. I'm talking + about the proposed variant using a separate backing store + <antrik> youpi: and as you might remember, I once came up with a crazy + passive translator command line (based on another crazy passive + translator command line from tschwinge) that can automatically do the + mkfs + <antrik> so there is really very little benefit in using something else + than ext2fs when not paging to the swap partition + <antrik> real tmpfs IMHO is mostly useful precisely because it uses the + ordinary swap, and doesn't have an explicit size limit... + <youpi> well, it is still quite a waste to bounce data betwen page cache + and memory storage + <youpi> or is ext2fs able to map the store data directly? + <youpi> then there's only the medata bounce which is spurious + <youpi> and still, even a one-liner settrans doesn't fit with the "is just + an fs alternative for the existing tmpfs-mounting scripts" + <antrik> youpi: well, if the invocation is the major concern, it would be + trivial to write a tiny wrapper binary or script that acts like a + "normal" FS... + <youpi> antrik: could you write it then? + <antrik> you mean a shell script that uses ext2fs on a memory store to act + like a "proper" tmpfs? + <youpi> I mean whatever that permits to just run mount none /tmp -t tmpfs + <youpi> and just works already nowadays + <youpi> which we could e.g. ship instead of our currently-completely bugged + tmpfs + <antrik> I suspect the mount script just looks for /hurd/tmpfs in this + case? if so, that should indeed be pretty trivial. let's see if I can dig + up my crazy command line -- turning that into a "proper" script should be + quite easy I hope... + <antrik> hm... I digged up + http://lists.gnu.org/archive/html/bug-hurd/2007-04/msg00013.html ; but I + wonder how much of it is really necessary for a generic pseudo-tmpfs... + <antrik> the major complication seems to be the chmod, which I guess we + don't need for most use cases... + <youpi> I actually don't see why it's inlined there + <youpi> doesn't the caller do it if it needs it? + <youpi> ah, well, here there is no caller, it's just a passive entry + <antrik> is it a problem that this solution needs an extra node for the + store? + <youpi> yes + <youpi> because you need to say where it resides + <youpi> and there's no safe place + <youpi> since such safe place would typically be a mounted tmpfs + <antrik> I feared that much... + <antrik> I suspect we could work around this by not attaching the store to + any node; but this a) doesn't work in a shell script, and b) is much more + involved... + <antrik> hm... can we assume /dev/fd to be present? I have a vague crazy + idea... + <youpi> yes + <antrik> I consider hacking settrans so it grows an option which allows + passing the port to the translator as an FD, instead of attaching it to + any node... this way, we could work with anonymous translators in shell + scripts :-) + <antrik> (of course that's not less work than just doing the wrapper in + C... but it could be useful in other cases) diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index efc8982a..7de9a6f2 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -306,6 +306,10 @@ Not implemented, not POSIX. Try to disable the feature in the package. There is no programming interface for the parallel port on GNU/Hurd yet. +## <a name="baud"> CBAUD </a> + +This is not actually standard; cfsetspeed, cfsetispeed, or cfsetospeed should be used instead. + ## <a name="errno"> `errno` values </a> When dealing with `errno`, you should always use the predefined error codes defined with the `E*` constants, instead of manually comparing/assigning/etc with their values. diff --git a/hurd/running/virtualbox.mdwn b/hurd/running/virtualbox.mdwn index 0731b8d6..f57fcbc3 100644 --- a/hurd/running/virtualbox.mdwn +++ b/hurd/running/virtualbox.mdwn @@ -22,7 +22,25 @@ The network controller should be configured as PCnet-PCI II or PCNet-FAST III for instance. INTEL PRO or Paravirtualized Network do not work. +## Converting from qemu image + +It is possible to convert qemu raw image to one of the formats recognized by VirtualBox, namely vdi format. + +If you are not sure if the image is a raw format, use qemu to get the information: + + qemu-img info debian-hurd-original.img + +To convert the image you need the VirtualBox package properly installed with a VBoxManage tool (which is part of the package). Convert image from raw to vdi: + + VBoxManage convertfromraw debian-hurd-original.img debian-hurd-converted.vdi --format VDI + + # Performance If [[QEMU with KVM|qemu]] is not available, VirtualBox reportedly has better performance. + +IRC, freenode, #hurd, 2011-10-31: + + <youpi> I don't know what virtualbox does with hardware emulation, but + gnumach is awfully slow to probe things there diff --git a/hurd/translator/tmpfs/notes_various.mdwn b/hurd/translator/tmpfs/notes_various.mdwn index d16210ca..d1c5cf62 100644 --- a/hurd/translator/tmpfs/notes_various.mdwn +++ b/hurd/translator/tmpfs/notes_various.mdwn @@ -212,3 +212,11 @@ License|/fdl]]."]]"""]] <antrik> seems something more broke in the meantime :-( <antrik> ah, right... but I the main problem was some other change <antrik> (or maybe it never really worked, not sure anymore) + +--- + +IRC, freenode, #hurd, 2011-10-11: + + <mcsim> There is no patch for "tmpfs crashes on filling an empty file". For + second bug there is Zheng Da's patch, but it wasn't applied (at least I + didn't found). diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn new file mode 100644 index 00000000..797d540f --- /dev/null +++ b/open_issues/64-bit_port.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2011 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_mig]] + +IRC, freenode, #hurd, 2011-10-16: + + <youpi> it'd be really good to have a 64bit kernel, no need to care about + addressing space :) + <braunr> yes a 64 bits kernel would be nice + <braunr> i guess it wouldn't be too hard to have a special mach kernel for + 64 bits processors, but 32 bits userland only + <youpi> well, it means tinkering with mig + <braunr> like old sparc systems :p + <youpi> to build the 32bit interface, not the 64bit one + <braunr> ah yes + <braunr> hm + <braunr> i'm not sure + <braunr> mig would assume a 32 bits kernel, like now + <youpi> and you'll have all kinds of discrepancies in vm_size_t & such + <braunr> yes + <braunr> the 64 bits type should be completely internal + <braunr> types* + <braunr> but it would be far less work than changing all the userspace bits + for 64 bit (ofc we'll do that some day but in the meanwhile ..) + <youpi> yes + <youpi> and it'd boost userland addrespace to 4GiB + <braunr> yes + <youpi> leaving time for a 64bit userland :) diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 64af3d00..46526641 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -13,7 +13,7 @@ License|/fdl]]."]]"""]] A bunch of this should also be covered in other (introductionary) material, like Bushnell's Hurd paper. All this should be unfied and streamlined. -IRC, freenode, #hurd, 2011-03-08 +IRC, freenode, #hurd, 2011-03-08: <foocraft> I've a question on what are the "units" in the hurd project, if you were to divide them into units if they aren't, and what are the @@ -40,7 +40,7 @@ IRC, freenode, #hurd, 2011-03-08 --- -IRC, freenode, #hurd, 2011-03-12 +IRC, freenode, #hurd, 2011-03-12: <dEhiN> when mach first starts up, does it have some basic i/o or fs functionality built into it to start up the initial hurd translators? @@ -86,3 +86,13 @@ RPC stubs. --- More stuff like [[hurd/IO_path]]. + +-- + +IRC, freenode, #hurd, 2011-10-18: + + <frhodes> what happens @ boot. and which translators are started in what + order? + <antrik> short version: grub loads mach, ext2, and ld.so/exec; mach starts + ext2; ext2 starts exec; ext2 execs a few other servers; ext2 execs + init. from there on, it's just standard UNIX stuff diff --git a/open_issues/benefits_of_a_native_hurd_implementation.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn index d796bf6b..afdcfb73 100644 --- a/open_issues/benefits_of_a_native_hurd_implementation.mdwn +++ b/open_issues/benefits_of_a_native_hurd_implementation.mdwn @@ -27,7 +27,7 @@ IRC, #hurd, August / September 2010 runs Linux in user space (just flip the two) for the drivers <marcusb> ArneBab: that is what the L4 people did with the DDE -([[DDE]]) +[[/DDE]]. <marcusb> ArneBab: so, with these different cuts, there are different opportunities. on the one end, you can run Linux as normal and get some diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn index b86ed607..246e819d 100644 --- a/open_issues/binutils.mdwn +++ b/open_issues/binutils.mdwn @@ -30,8 +30,8 @@ though, as explained below. # Configuration -Last reviewed up to the [[Git mirror's 066f3707e988b24f8f39d01f105662a814c0979a -(2011-10-11) sources|source_repositories/binutils]]. +Last reviewed up to the [[Git mirror's e605e0bc9fced128199177fff775851c7e50b4e5 +(2011-10-20) sources|source_repositories/binutils]]. * Globally @@ -108,7 +108,7 @@ Last reviewed up to the [[Git mirror's 066f3707e988b24f8f39d01f105662a814c0979a # Build Here's a log of a binutils build run; this is from our [[Git repository's -11637a710adc7baea102d0ef5975b7a92b07aea1 (2011-10-11) +6e78bdc1d64c55962d36ef29d15f06fb2415261b (2011-10-20) sources|source_repositories/binutils]], run on kepler.SCHWINGE and coulomb.SCHWINGE. diff --git a/open_issues/binutils/log_build.diff b/open_issues/binutils/log_build.diff index 79172cf6..79946f63 100644 --- a/open_issues/binutils/log_build.diff +++ b/open_issues/binutils/log_build.diff @@ -1,5 +1,5 @@ ---- /dev/fd/63 2011-10-11 14:23:15.275568065 +0200 -+++ /dev/fd/62 2011-10-11 14:23:15.275568065 +0200 +--- /dev/fd/63 2011-10-22 11:44:16.461445903 +0200 ++++ /dev/fd/62 2011-10-22 11:44:16.461445903 +0200 @@ -276,12 +276,12 @@ checking for sys/sysinfo.h... yes checking for machine/hal_sysinfo.h... no @@ -214,7 +214,7 @@ checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes -@@ -2473,7 +2452,7 @@ +@@ -2475,7 +2454,7 @@ checking for BSD- or MS-compatible name lister (nm)... nm checking the name lister (nm) interface... BSD nm checking whether ln -s works... yes @@ -223,7 +223,7 @@ checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... no checking for ld option to reload object files... -r -@@ -2494,7 +2473,7 @@ +@@ -2496,7 +2475,7 @@ checking if gcc-4.6 supports -c -o file.o... (cached) yes checking whether the gcc-4.6 linker (ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no @@ -232,7 +232,7 @@ checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes -@@ -2510,7 +2489,7 @@ +@@ -2512,7 +2491,7 @@ checking if g++-4.6 supports -c -o file.o... yes checking if g++-4.6 supports -c -o file.o... (cached) yes checking whether the g++-4.6 linker (ld) supports shared libraries... yes @@ -241,7 +241,7 @@ checking how to hardcode library paths into programs... immediate checking whether NLS is requested... yes checking for catalogs to be installed... bg da es fi fr ga id ja sv tr vi zh_CN zh_TW -@@ -2590,13 +2569,13 @@ +@@ -2592,13 +2571,13 @@ /bin/dash ../../master/ld/../ylwrap ../../master/ld/ldgram.y y.tab.c ldgram.c y.tab.h ldgram.h y.output ldgram.output -- bison -y -d updating ldgram.h (echo "/* This file is automatically generated. DO NOT EDIT! */";\ @@ -257,7 +257,7 @@ | sed -e 's/ e/ ld/g' -e 's/ ld/ /g' -e 's/[.]o//g'`; do \ echo " &ld_${f}_emulation, \\"; \ done;\ -@@ -2710,17 +2689,11 @@ +@@ -2712,17 +2691,11 @@ gcc-4.6 -DHAVE_CONFIG_H -I. -I../../master/ld -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT plugin.o -MD -MP -MF .deps/plugin.Tpo -c -o plugin.o ../../master/ld/plugin.c mv -f .deps/plugin.Tpo .deps/plugin.Po cp ../../master/ld/emultempl/astring.sed stringify.sed diff --git a/open_issues/binutils/log_install.diff b/open_issues/binutils/log_install.diff index 27dff188..100ebf5c 100644 --- a/open_issues/binutils/log_install.diff +++ b/open_issues/binutils/log_install.diff @@ -1,5 +1,5 @@ ---- /dev/fd/63 2011-10-11 14:23:22.899444227 +0200 -+++ /dev/fd/62 2011-10-11 14:23:22.903444162 +0200 +--- /dev/fd/63 2011-10-22 11:44:48.780903894 +0200 ++++ /dev/fd/62 2011-10-22 11:44:48.780903894 +0200 @@ -68,7 +68,6 @@ libtool: install: /usr/bin/install -c .libs/libbfd.a [...]/hurd/master.build.install/lib/libbfd.a libtool: install: chmod 644 [...]/hurd/master.build.install/lib/libbfd.a diff --git a/open_issues/binutils/sum.diff b/open_issues/binutils/sum.diff index a466b82c..0c612411 100644 --- a/open_issues/binutils/sum.diff +++ b/open_issues/binutils/sum.diff @@ -1,9 +1,9 @@ ---- open_issues/binutils/sum_linux 2011-10-11 14:23:39.000000000 +0200 -+++ open_issues/binutils/sum_hurd 2011-10-11 14:23:33.000000000 +0200 +--- open_issues/binutils/sum_linux 2011-10-22 11:49:33.000000000 +0200 ++++ open_issues/binutils/sum_hurd 2011-10-22 11:23:09.000000000 +0200 @@ -1,5 +1,5 @@ --Test Run By thomas on Tue Oct 11 14:12:56 2011 +-Test Run By thomas on Sat Oct 22 11:43:32 2011 -Native configuration is i686-pc-linux-gnu -+Test Run By thomas on Tue Oct 11 13:36:51 2011 ++Test Run By thomas on Fri Oct 21 12:54:58 2011 +Native configuration is i686-unknown-gnu0.3 === binutils tests === @@ -12,9 +12,9 @@ # of expected passes 90 # of unsupported tests 3 --Test Run By thomas on Tue Oct 11 14:13:19 2011 +-Test Run By thomas on Sat Oct 22 11:43:59 2011 -Native configuration is i686-pc-linux-gnu -+Test Run By thomas on Tue Oct 11 13:38:54 2011 ++Test Run By thomas on Fri Oct 21 12:56:51 2011 +Native configuration is i686-unknown-gnu0.3 === ld tests === @@ -60,20 +60,20 @@ PASS: ELF DSO small bar (size) PASS: ELF DSO foo with small bar (size) PASS: ELF DSO big bar (size) -@@ -939,13 +939,13 @@ Running [...]/hurd/master/ld/testsuite/l +@@ -940,13 +940,13 @@ Running [...]/hurd/master/ld/testsuite/l === ld Summary === --# of expected passes 671 +-# of expected passes 672 -# of expected failures 8 -+# of expected passes 661 ++# of expected passes 662 +# of expected failures 18 # of untested testcases 6 - [...]/hurd/master.build/ld/ld-new 2.22.51.20111011 + [...]/hurd/master.build/ld/ld-new 2.22.51.20111021 --Test Run By thomas on Tue Oct 11 14:13:02 2011 +-Test Run By thomas on Sat Oct 22 11:43:38 2011 -Native configuration is i686-pc-linux-gnu -+Test Run By thomas on Tue Oct 11 13:37:18 2011 ++Test Run By thomas on Fri Oct 21 12:55:21 2011 +Native configuration is i686-unknown-gnu0.3 === gas tests === diff --git a/open_issues/binutils/sum_hurd b/open_issues/binutils/sum_hurd index 7d12b17f..31f8f997 100644 --- a/open_issues/binutils/sum_hurd +++ b/open_issues/binutils/sum_hurd @@ -1,4 +1,4 @@ -Test Run By thomas on Tue Oct 11 13:36:51 2011 +Test Run By thomas on Fri Oct 21 12:54:58 2011 Native configuration is i686-unknown-gnu0.3 === binutils tests === @@ -122,7 +122,7 @@ Running [...]/hurd/master/binutils/testsuite/binutils-all/x86-64/x86-64.exp ... # of expected passes 90 # of unsupported tests 3 -Test Run By thomas on Tue Oct 11 13:38:54 2011 +Test Run By thomas on Fri Oct 21 12:56:51 2011 Native configuration is i686-unknown-gnu0.3 === ld tests === @@ -625,6 +625,7 @@ PASS: Check --gc-section/-r/-u PASS: --gc-sections -r without -e PASS: --gc-sections with note section PASS: --gc-sections with __start_ +PASS: --gc-sections with __gxx_personality PASS: --gc-sections with shared library Running [...]/hurd/master/ld/testsuite/ld-h8300/h8300.exp ... Running [...]/hurd/master/ld/testsuite/ld-i386/i386.exp ... @@ -939,12 +940,12 @@ Running [...]/hurd/master/ld/testsuite/ld-xtensa/xtensa.exp ... === ld Summary === -# of expected passes 661 +# of expected passes 662 # of expected failures 18 # of untested testcases 6 -[...]/hurd/master.build/ld/ld-new 2.22.51.20111011 +[...]/hurd/master.build/ld/ld-new 2.22.51.20111021 -Test Run By thomas on Tue Oct 11 13:37:18 2011 +Test Run By thomas on Fri Oct 21 12:55:21 2011 Native configuration is i686-unknown-gnu0.3 === gas tests === @@ -1416,5 +1417,5 @@ Running [...]/hurd/master/gas/testsuite/gas/z8k/z8k.exp ... === gas Summary === # of expected passes 346 -../as-new 2.22.51.20111011 +../as-new 2.22.51.20111021 diff --git a/open_issues/binutils/sum_linux b/open_issues/binutils/sum_linux index f765b983..09c11722 100644 --- a/open_issues/binutils/sum_linux +++ b/open_issues/binutils/sum_linux @@ -1,4 +1,4 @@ -Test Run By thomas on Tue Oct 11 14:12:56 2011 +Test Run By thomas on Sat Oct 22 11:43:32 2011 Native configuration is i686-pc-linux-gnu === binutils tests === @@ -122,7 +122,7 @@ Running [...]/hurd/master/binutils/testsuite/binutils-all/x86-64/x86-64.exp ... # of expected passes 90 # of unsupported tests 3 -Test Run By thomas on Tue Oct 11 14:13:19 2011 +Test Run By thomas on Sat Oct 22 11:43:59 2011 Native configuration is i686-pc-linux-gnu === ld tests === @@ -625,6 +625,7 @@ PASS: Check --gc-section/-r/-u PASS: --gc-sections -r without -e PASS: --gc-sections with note section PASS: --gc-sections with __start_ +PASS: --gc-sections with __gxx_personality PASS: --gc-sections with shared library Running [...]/hurd/master/ld/testsuite/ld-h8300/h8300.exp ... Running [...]/hurd/master/ld/testsuite/ld-i386/i386.exp ... @@ -939,12 +940,12 @@ Running [...]/hurd/master/ld/testsuite/ld-xtensa/xtensa.exp ... === ld Summary === -# of expected passes 671 +# of expected passes 672 # of expected failures 8 # of untested testcases 6 -[...]/hurd/master.build/ld/ld-new 2.22.51.20111011 +[...]/hurd/master.build/ld/ld-new 2.22.51.20111021 -Test Run By thomas on Tue Oct 11 14:13:02 2011 +Test Run By thomas on Sat Oct 22 11:43:38 2011 Native configuration is i686-pc-linux-gnu === gas tests === @@ -1416,5 +1417,5 @@ Running [...]/hurd/master/gas/testsuite/gas/z8k/z8k.exp ... === gas Summary === # of expected passes 346 -../as-new 2.22.51.20111011 +../as-new 2.22.51.20111021 diff --git a/open_issues/bsd_compatibility.mdwn b/open_issues/bsd_compatibility.mdwn new file mode 100644 index 00000000..5c916908 --- /dev/null +++ b/open_issues/bsd_compatibility.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2011-10-12: + + <pinotree> hm, why our sys/param.h #define's BSD? + <braunr> pinotree: because we're evil + <pinotree> is that correct? + <pinotree> (the define, not the evilness) + <braunr> pinotree: i think it's because the Hurd is closer to the BSD + interfaces, probably because of Mach (which is itself derived from + BSD4.2) + <pinotree> braunr: but mach being bsd-ish won't make the userland (glibc) + interfaces bsd-ish, will it? + <braunr> pinotree: no + <pinotree> braunr: so...? :) + <braunr> pinotree: i guesse there are bsdisms in the glibc hurd specific + code, possibly because of mach + <braunr> or they used to be bsdisms, before being standardized + <braunr> e.g. mmap + <pinotree> braunr: hrmm... + <antrik> braunr: the BSDisms are there on purpose... Hurd was originally + even meant to be binary-compatible with BSD + <antrik> nothing to do with Mach really + <braunr> antrik: ok diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn index ef319a5c..9e2ec742 100644 --- a/open_issues/dde.mdwn +++ b/open_issues/dde.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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,4 +8,25 @@ 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 redir=/dde]] +[[General Information|/dde]]. + + +# IRC, freenode, #hurd, 2011-10-18 + +[[!tag open_issue_hurd]] + + [DDE crash, or similar] + <youpi> it's fake_local_irq_disable_flags(), then raw_local_irq_disable(), + then raw_local_irq_restore(), which *does not* release the cli_lock + <youpi> the "prove it" comment is (as I expected) completely wrong + <youpi> npnth: http://paste.debian.net/137784/ + +[[137784]] + + <youpi> could you try this patch ? + <youpi> (I've not even tried to build it) + <npnth> youpi: speaking of which, it still seems to hang :/ I'll 1) double + check it applied correctly and 2) get a gdb output if it did + <youpi> npnth: could you add printing the value of unlock_refcnt? + <youpi> so we can check what's happening + <npnth> unlock_refcnt is at 0, interesting diff --git a/open_issues/dde/137784 b/open_issues/dde/137784 new file mode 100644 index 00000000..1529465b --- /dev/null +++ b/open_issues/dde/137784 @@ -0,0 +1,43 @@ +diff --git a/libdde_linux26/lib/src/arch/l4/cli_sti.c b/libdde_linux26/lib/src/arch/l4/cli_sti.c +index 051f259..6a8c460 100644 +--- a/libdde_linux26/lib/src/arch/l4/cli_sti.c ++++ b/libdde_linux26/lib/src/arch/l4/cli_sti.c +@@ -4,6 +4,8 @@ + + /* IRQ lock reference counter */ + static atomic_t _refcnt = ATOMIC_INIT(0); ++/* Refcnt value at which unlocking the cli_lock (it's not always 0) */ ++static int unlock_refcnt; + static ddekit_lock_t cli_lock; + + /* Check whether IRQs are currently disabled. +@@ -57,9 +59,6 @@ void fake_local_irq_restore(unsigned long flags) + /* Store the current flags state. + * + * This is done by returning the current refcnt. +- * +- * XXX: Up to now, flags was always 0 at this point and +- * I assume that this is always the case. Prove? + */ + unsigned long __raw_local_save_flags(void) + { +@@ -82,7 +81,7 @@ void raw_local_irq_restore(unsigned long flags) + { + Assert(cli_lock != NULL); + atomic_set(&_refcnt, flags); +- if (flags == 0) ++ if (flags == unlock_refcnt) + ddekit_lock_unlock(&cli_lock); + } + +@@ -95,7 +94,9 @@ void raw_local_irq_disable(void) + if (cli_lock == NULL) + ddekit_lock_init_unlocked(&cli_lock); + +- nested_lock(cli_lock); ++ if (nested_lock(cli_lock)) ++ /* Tell the corresponding restorer to release cli_lock */ ++ unlock_refcnt = atomic_read(&_refcnt); + atomic_inc(&_refcnt); + } + diff --git a/open_issues/dev_zero_size.mdwn b/open_issues/dev_zero_size.mdwn new file mode 100644 index 00000000..20c5147e --- /dev/null +++ b/open_issues/dev_zero_size.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2011 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, freenode, #hurd, 2011-10-18: + + <pinotree> i guess it is not normal for /dev/zero have a size of + (size_t)-1, no? + <pinotree> (it isn't (size_t)-1, but (long long)-1) + +2011-10-19: + + <pinotree> see the size you get with `stat /dev/zero` diff --git a/open_issues/device_drivers_and_io_systems.mdwn b/open_issues/device_drivers_and_io_systems.mdwn index ce50d93e..5bda0213 100644 --- a/open_issues/device_drivers_and_io_systems.mdwn +++ b/open_issues/device_drivers_and_io_systems.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2011 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 @@ -68,7 +68,7 @@ Also see [[user-space device drivers]]. # External Projects - * [[DDE]] + * [[/DDE]] * [Building Linux Device Drivers on FreeBSD](http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html) diff --git a/open_issues/fifo_O_RDWR.mdwn b/open_issues/fifo_O_RDWR.mdwn new file mode 100644 index 00000000..730e5c6f --- /dev/null +++ b/open_issues/fifo_O_RDWR.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2011 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="fifo O_RDWR"]] + +[[!tag open_issue_hurd]] + +[[!debbug 646016]] + +IRC, OFTC, #debian-hurd, 2011-10-19: + + <tschwinge> pinotree: Nice! And that open(FIFO, O_RDWR) hanging issue may + warrant investigation on the Hurd side, too -- if the other systems + behave differently, we should probably have convincing reasons for our + behavior. + <pinotree> i gue somebody working on hurd never cared about that case - i + guess it falls back to one of O_RDONLY or O_WRONLY + <pinotree> *guess diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index be262261..d3f88673 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -40,12 +40,12 @@ Last reviewed up to the [[Git mirror's 187da0aedcd9d0a2fb34477bef41549681ba1273 `t/dup3`: hidden def. ed690b2f24bbc4d9c541fc81a7c67e6dc5678a96 -- why not for dup3, too? Because it is a syscall (that is always inlined)? - * t/init-first.c + * `t/init-first.c` - Have to revert 53b56b1101fc9bb4f295f23f54e7e19f8da8da16 to keep it working - with GCC 4.4. Figure out what's going on. Also see [[glibc_init_first]]. - - There is a `RETURN_ADDRESS` macro in glibc. + Follow up here: [[!message-id "20070722171859.GN25744@fencepost.gnu.org"]] + or [[!message-id "87mxe4kwws.fsf@gnu.org"]]. Close [[!GNU_Savannah_bug + 17647]]. Debian: [[!message-id "E1Qup1U-0006Zc-39@vasks.debian.org"]] + (part of Ludo's patch; the part that is not harmful to GCC 4.4). * `t/kernel-features.h_includes` @@ -59,6 +59,8 @@ Last reviewed up to the [[Git mirror's 187da0aedcd9d0a2fb34477bef41549681ba1273 * `TLS_INIT_TP_EXPENSIVE` is unused; Hurd def. can be removed. + * [[t/tls-threadvar]] + * t/verify.h People didn't like this too much. @@ -192,8 +194,6 @@ Last reviewed up to the [[Git mirror's 187da0aedcd9d0a2fb34477bef41549681ba1273 Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 + 14d96785125abee5e9a49a1c3037f35a581750bd. - * Building with GCC 4.5, 4.6, trunk will cause different kinds of faults. - * Create `t/cleanup_kernel-features.h`. * Add tests from Linux kernel commit messages for `t/dup3` et al. @@ -371,7 +371,7 @@ Last reviewed up to the [[Git mirror's 187da0aedcd9d0a2fb34477bef41549681ba1273 # Build Here's a log of a glibc build run; this is from our [[Git repository's -8cb1875ef1e3211ec133d8eea328dbe59538c2a7 (2011-10-11) +0abded0927c62f02399658395837917548d5e281 (2011-10-14) sources|source_repositories/glibc]], run on coulomb.SCHWINGE. $ export LC_ALL=C @@ -383,7 +383,7 @@ sources|source_repositories/glibc]], run on coulomb.SCHWINGE. This takes up around 400 MiB and needs roughly 120 min on coulomb.SCHWINGE. <!-- - $ (make install_root=/INVALID && touch .go-check) 2>&1 | tee log_build_ && test -f .go-check && make -k install_root=/INVALID check 2>&1 | tee log_check + $ (make install_root=/INVALID && touch .go-check) 2>&1 | tee log_build_ && test -f .go-check && make -k install_root=/INVALID check TIMEOUTFACTOR=100 2>&1 | tee log_check $ find ./ -name \*.o -o -name \*.os -o -name \*.oS | while read f; do ~/tmp/gcc/git/contrib/compare-debug --preserve ../Roger_Whittaker.build-gcc-4.4-486.O/"$f" "$f"; done 2>&1 | less $ while read f; do (readelf -a "$f" && objdump -xDrtw "$f") > N && (cd ../Roger_Whittaker.build-gcc-4.4-486.O/ && readelf -a "$f" && objdump -xDrtw "$f") > O && diff -u O N | less; done $ find ./ -name \*.o -o -name \*.os -o -name \*.oS | while read f; do readelf -h "$f" | grep OS/ABI | (read a b && [ x"$b" != x'UNIX - System V' ] && echo "### $f: $b"); done diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn index ce6ba9d2..331632f3 100644 --- a/open_issues/glibc/debian.mdwn +++ b/open_issues/glibc/debian.mdwn @@ -37,10 +37,28 @@ fail. (Same for `libc6-dev_extra_pkg_install` in `debian/sysdeps/i386.mk`, for example.) Why is this special handling only done for `xen`, but not for `i686`? +> Samuel: Historically because it's done that way in linux-i386. I don't know +> the real reason. + Do `export LC_ALL=C` before building, otherwise the testsuite/make error messages will be different from those stored in the -`debian/testsuite-checking/expected-results-*` files. +`debian/testsuite-checking/expected-results-*` files, resulting in a spurious +build failure. + +Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]` +to build (or `build` instead of `build-arch` to build the arch-independent +stuff, too). Can interrupt with `C-c` during locale stuff or testsuite if only +interested in the build tree. + +Run `fakeroot debian/rules binary DEB_BUILD_OPTIONS=parallel=2 +[EGLIBC_PASSES=...]` to build Debian packages or `binary-arch` for just the +architecture-dependent ones. + +The latter two steps can also be combined as `dpkg-buildpackage -R'debian/rules +EGLIBC_PASSES=libc' -nc -b -uc`. `-nc` will prevent the *clean step* which +would first try to un-patch, which may conflict if you have done any edits +apter applying patches. -Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]`. -Can stop with `C-c` during locale stuff or testsuite if only interested in the -build tree. +If the Debian symbol versioning file is not up to date and the build of Debian +packages fails due to this, putting `DPKG_GENSYMBOLS_CHECK_LEVEL=0` in the +environment \`\`helps''; see `man dpkg-gensymbols`. diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn new file mode 100644 index 00000000..f6a81590 --- /dev/null +++ b/open_issues/glibc/t/tls-threadvar.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2011 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, freenode, #hurd, 2011-10-23: + + <tschwinge> youpi: If we want to replace threadvars with TLS, there is one + problem: the threadvars interface is publically exported: + /usr/include/hurd/threadvar.h. + <tschwinge> youpi: But I am somewhat inclined to say that the only user of + this is libthreads/libpthread. Do you think differently? + <youpi> tschwinge: that's very probable + <youpi> so I think we can just drop it + <youpi> (people should use TLS anyway) + +[[libpthread_set_stack_size]]. diff --git a/open_issues/glibc_init_first.mdwn b/open_issues/glibc_init_first.mdwn deleted file mode 100644 index 774b7828..00000000 --- a/open_issues/glibc_init_first.mdwn +++ /dev/null @@ -1,78 +0,0 @@ -[[!meta copyright="Copyright © 2011 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, freenode, #hurd, 2011-07-22 - - [additional init-first.c patch] - < tschwinge> civodul: The only thing I wonder about: Roland also once had - done similar changes, which I then found they didn'T work with GCC 4.1, - and backed them out in 08f53ee9d265ffdc7e0affd6acf346cceeb65559 and fixed - the issue differently in d8d27e633a7860b37fd2e3142822b640a066cc0f (and - e17cef66140d4c97710ea88bd8d12612799e1e0f). Have you reviewed this? - < tschwinge> That's in the Savannah glibc repository. - < tschwinge> And this has been in 2007, four years ago. I don't remember - all the details. - < tschwinge> And here is quite a good summary of this stuff, from - init-first.c: - < tschwinge> /* XXX This is all a crock and I am not happy with it. - < tschwinge> This poorly-named function is called by static-start.S, - < civodul> braunr: thanks; i must admit it took me a while to figure it out - ;-) - < tschwinge> which should not exist at all. */ - < tschwinge> civodul: I can imagine... :-/ - < civodul> tschwinge: re Roland's changes, that's weird; i plan to try to - reinstate his change and see if it works - < civodul> now, i won't test with GCC 4.1... - < tschwinge> Yeah... - < tschwinge> I'm happy if it works with 4.4 onwards. - < tschwinge> civodul: And it's safe (in GCC terms) to write to ``* ((void - **) __builtin_frame_address (0) + 1)'', and similar? - < tschwinge> Or should we be coding this few stuff in assembly? - < civodul> tschwinge: well, we should add a compile-time assertion for - __builtin_return_address (0) == *((void**)__builtin_frame_address (0) + - 1) - < civodul> (i think GCC can figure it out at compile-time) - < civodul> but on IA32 it should always be true - < civodul> what's the name of glibc's compile-time assert macro already? - < tschwinge> I wonder whether that might interfere with some of GCC's - optimizations? - < civodul> what? - < tschwinge> Well, it seems unclean for me to be modifying a function's - return address from within C code. - < tschwinge> civodul: I added a verify.h in the t/verify.h branch. But - people didn't really like it too much. They rather wanted to directly - inline the array[(cond)?1:-1] code. - < civodul> ok - < civodul> i remember a debate about Gnulib's verify.h - < civodul> i thought something comparable had landed eventually - < tschwinge> civodul: Oh, maybe I missed it. - < tschwinge> civodul: In init-first.c:init, what about the usage of - data[-1] in the else path (not using cthreads) -- is that good as-is? - < civodul> tschwinge: oooh, it probably needs to fixed too - < civodul> but i haven't reached that point yet ;-) - * civodul tries to cross-bootstrap GNU from scratch - < tschwinge> civodul: I'd be happy to learn what was wrong with Roland's - original idea of fixing this. Or perhaps this was a GCC 4.1 bug? Or - perhaps GCC was inlining to much, and then got confused with frames and - return addresses? - < civodul> tschwinge: Roland's change looks good to me, so it could have - been a GCC bug - < civodul> tschwinge: OK to commit the patch to t/init-first.c (with both - data[-1] replaced)? - < tschwinge> civodul: OK, if you are confident that it works with GCC 4.4 - onwards. If yes, please add your changelog snippet to .topmsg, and also - add a not that Roland's original code may in fact have been fine, and we - may have hit a compiler bug. - < civodul> tschwinge: OK, will do - < civodul> tschwinge: though regarding Roland's change, i'd prefer to - actually test and see - < tschwinge> civodul: Thanks! diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index fb3d6895..9a4418c1 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -1777,3 +1777,36 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. <braunr> an idea for when there's time <braunr> eh <antrik> hehe :-) + + +# IRC, freenode, #hurd, 2011-10-13 + + <braunr> mcsim: what's the current state of your gnumach branch ? + <mcsim> I've merged it with master in September + <braunr> yes i've seen that, but does it build and run fine ? + <mcsim> I've tested it on gnumach from debian repository, but for building + I had to make additional change in device/ramdisk.c, as I mentioned. + <braunr> mcsim: why ? + <mcsim> And it runs fine for me. + <braunr> mcsim: why did you need to make other changes ? + <mcsim> because there is a patch which comes with from-debian-repository + kernel and it addes some code, where I have to make changes. Earlier + kernel_map was a pointer to structure, but I change that and now + kernel_map is structure. So handling to it should be by taking the + address (&kernel_map) + <braunr> why did you do that ? + <braunr> or put it another way: what made you do that type change on + kernel_map ? + <mcsim> Earlier memory for kernel_map was allocating with zalloc. But now + salloc can't allocate memory before it's initialisation + <braunr> that's not a good reason + <braunr> a simple workaround for your problem is this : + <braunr> static struct vm_map kernel_map_store; + <braunr> vm_map_t kernel_map = &kernel_map_store; + <mcsim> braunr: Ok. I'll correct this. + + +# IRC, freenode, #hurd, 2011-11-01 + + <braunr> etenil: but mcsim's work is, for one, useful because the allocator + code is much clearer, adds some debugging support, and is smp-ready diff --git a/open_issues/gnumach_memory_management_2.mdwn b/open_issues/gnumach_memory_management_2.mdwn new file mode 100644 index 00000000..64aae2a4 --- /dev/null +++ b/open_issues/gnumach_memory_management_2.mdwn @@ -0,0 +1,246 @@ +[[!meta copyright="Copyright © 2011 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, freenode, #hurd, 2011-10-16: + + <youpi> braunr: I realize that kmem_alloc_wired maps the allocated pages in + the kernel map + <youpi> it's a bit of a waste when my allocation is exactly a page size + <youpi> is there a proper page allocation which would simply return its + physical address? + <youpi> pages returned by vm_page_grab may get swapped out, right? + <youpi> so could it be a matter of calling vm_page_alloc then vm_page_wire + (with lock_queues held) ? + <youpi> s/alloc/grab/ + <braunr> vm_page_grab() is only used at boot iirc + <braunr> youpi: mapping allocated memory in the kernel map is normal, even + if it's only a page + <braunr> the allocated area usually gets merged with an existing + vm_map_entry + <braunr> youpi: also, i'm not sure about what you're trying to do here, so + my answers may be out of scope :p + <youpi> saving addressing space + <youpi> with that scheme we're using twice as much addressing space for + kernel buffers + <braunr> kernel or user task ? + <youpi> kernl + <braunr> hm are there so many wired areas ? + <youpi> several MiBs, yes + <youpi> there are also the zalloc areas + <braunr> that's pretty normal + <youpi> which I've recently incrased + <braunr> hm forget what i've just said about vm_page_grab() + <braunr> youpi: is there a particular problem caused by kernel memory + exhaustion ? + <youpi> I currently can't pass the dh_strip stage of iceweasel due to this + <youpi> it can not allocate a stack + <braunr> a kernel thread stack ? + <youpi> yes + <braunr> that's surprising + <youpi> it'd be good to have a kernel memory profile + <braunr> vminfo is able to return the kernel map + <youpi> well, it's not suprising if the kernel map is full + <youpi> but it doesn't tell what allocates which p ieces + <braunr> that's what i mean, it's surprising to have a full kernel map + <youpi> (that's what profiling is about) + <braunr> right + <youpi> well, it's not really surprising, considering that the krenel map + size is arbitrarily chosen + <braunr> youpi: 2 GiB is really high enough + <youpi> it's not 2GiB, precisely + <youpi> there is much of the 2GiB addr space which is spent on physical + memory mapping + <youpi> then there is the virtual mapping + <braunr> are you sure we're talking about the kernel map, or e.g. the kmem + map + <youpi> which is currently only 192MiB + <youpi> the kmem_map part of kernel_map + <braunr> ok, the kmem_map submap then + <braunr> netbsd has used 128 MiB for yeas with almost no issue + <braunr> mach uses more kernel objects so it's reasonable to have a bigger + map + <braunr> but that big .. + <youpi> I've made the zalloc areas quite big + <youpi> err, not only zalloc area + <braunr> kernel stacks are allocated directly from the kernel map + <youpi> kalloc to 64MiB, zalloc to 64MiB + <youpi> ipc map size to 8MiB + <braunr> youpi: it could be the lack of kernel map entries + <youpi> and the device io map to 16MiB + <braunr> do you have the exact error message ? + <youpi> no more room for vm_map_find_entry in 71403294 + <youpi> no more rooom for kmem_alloc_aligned in 71403294 + <braunr> ah, aligned + <youpi> for a stack + <youpi> which is 4 pages only + <braunr> memory returned by kmem functions always return pages + <braunr> hum + <braunr> kmem functions always return memory in page units + <youpi> and my xen driver is allocating 1MiB memory for the network buffer + <braunr> 4 pages for kernel stacks ? + <youpi> through kmem_alloc_wire + <braunr> that seems a lot + <youpi> that's needed for xen page updates + <youpi> without having to split the update in several parts + <braunr> ok + <braunr> but are there any alignment requirements ? + <youpi> I guess mach uses the alignment trick to find "self" + <youpi> anyway, an alignment on 4pages shouldn't be a problem + <braunr> i think kmem_alloc_aligned() is the generic function used both for + requests with and without alignment constraints + <youpi> so I was thinking about at least moving my xen net driver to + vm_grab_page instead of kmem_alloc + <youpi> and along this, maybe others + <braunr> but you only get a vm_page, you can't access the memory it + describes + <youpi> non, a lloc_aligned always aligns + <youpi> why? + <braunr> because it's not mapped + <youpi> there's even vm_grab_page_physical_addr + <youpi> it is, in the physical memory map + <braunr> ah, you mean using the direct mapped area + <youpi> yes + <braunr> then yes + <braunr> i don't know that part much + <youpi> what I'm afraid of is the wiring + <braunr> why ? + <youpi> because I don't want to see my page swapped out :) + <youpi> or whatever might happen if I don't wire it + <braunr> oh i'm almost sure you won't + <youpi> why? + <youpi> why some people need to wire it, and I won't? + <braunr> because in most mach vm derived code i've seen, you have to + explicitely tell the vm your area is pageable + <youpi> ah, mach does such thing indeed + <braunr> wiring can be annoying when you're passing kernel data to external + tasks + <braunr> you have to make sure the memory isn't wired once passed + <braunr> but that's rather a security/resource management problem + <youpi> in the net driver case, it's not passed to anything else + <youpi> I'm seeing 19MiB kmem_alloc_wired atm + <braunr> looks ok to me + <braunr> be aware that the vm_resident code was meant for single page + allocations + <youpi> what does this mean? + <braunr> there is no buddy algorithm or anything else decent enough wrt + performance + <braunr> vm_page_grab_contiguous_pages() can be quite slow + <youpi> err, ok, but what is the relation with the question at stake ? + <braunr> you need 4 pages of direct mapped memory for stacks + <braunr> those pages need to be physically contiguous if you want to avoid + the mapping + <braunr> allocating physically contiguous pages in mach is slow + <braunr> :) + <youpi> I didn't mean I wanted to avoid the mapping for stacks + <youpi> for anything more than a page, kmem mapping should be fine + <youpi> I'm concerned with code which allocates only page per page + <youpi> which thus really doesn't need any mapping + <braunr> i don't know the mach details but in derived implementations, + there is almost no overhead when allocating single pages + <braunr> except for the tlb programming + <youpi> well, there is: twice as much addressing space + <braunr> well + <braunr> netbsd doesn't directly map physical memory + <braunr> and for others, like freebsd + <braunr> the area is just one vm_map_entry + <braunr> and on modern mmus, 4 MiBs physical mappings are used in pmap + <youpi> again, I don't care about tlb & performance + <youpi> just about the addressing space + <braunr> hm + <braunr> you say "twice" + <youpi> which is short when you're trying to link crazy stuff like + iceweasel & co + <youpi> yes + <braunr> ok, the virtual space is doubled + <youpi> yes + <braunr> but the resources consume to describe them aren't + <braunr> even on mach + <youpi> since you have both the physical mapping and the kmem mapping + <youpi> I don't care much about the resources + <youpi> but about addressing space + <braunr> well there are a limited numbers of solutions + <youpi> the space it takes and has to be taken from something else, that + is, here physical memory available to Mach + <braunr> reduce the physical mapping + <braunr> increase the kmem mapping + <braunr> or reduce kernel memory consumption + <youpi> and instead of taking the space from physical mapping, we can as + well avoid doubling the space consumption when it's trivial lto + <youpi> yes, the hird + <youpi> +t + <youpi> that's what I'm asking from the beginning :) + <braunr> 18:21 < youpi> I don't care much about the resources + <braunr> actually, you care :) + <youpi> yes and no + <braunr> i understand what you mean + <youpi> not in the sense "it takes a page_t to allocate a page" + <braunr> you want more virtual space, and aren't that much concerned about + the number of objects used + <youpi> yes + <braunr> then it makes sense + <braunr> but in this case, it could be a good idea to generalize it + <braunr> have our own kmalloc/vmalloc interfaces + <braunr> maybe a gsoc project :) + <youpi> err, don't we have them already? + <youpi> I mean, what exactly do you want to generalize? + <braunr> mach only ever had vmalloc + <youpi> we already have a hell lot of allocators :) + <youpi> and it's a pain to distribute the available space to them + <braunr> yes + <braunr> but what you basically want is to introduce something similar to + kmalloc for single pages + <youpi> or just patch the few cases that need it into just grabbing a page + <youpi> there are probably not so many + <braunr> ok + <braunr> i've just read vm_page_grab() + <braunr> it only removes a page from the free list + <braunr> other functions such as vm_page_alloc insert them afterwards + <braunr> if a page is in no list, it can't be paged out + <braunr> so i think it's probably safe to assume it's naturally wired + <braunr> you don't even need a call to vm_page_wire or a flag of some sort + <youpi> ok + <braunr> although considering the low amount of work done by + vm_page_wire(), you could, for clarity + <youpi> braunr: I was also wondering about the VM_PAGE_FREE_RESERVED & such + constants + <youpi> they're like 50 pages + <youpi> is this still reasonable nowadays? + <braunr> that's a question i'm still asking myself quite often :) + <youpi> also, the BURST_{MAX,MIN} & such in vm_pageout.c are probably out + of date? + <braunr> i didn't study the pageout code much + <youpi> k + <braunr> but correct handling of low memory thresholds is a good point to + keep in mind + <braunr> youpi: i often wonder how linux can sometimes have so few free + pages left and still be able to work without any visible failure + <youpi> well, as long as you have enough pages to be able to make progress, + you're fine + <youpi> that' the point of the RESERVED pages in mach I guess + <braunr> youpi: yes but, obviously, hard values are *bad* + <braunr> linux must adjust it, depending on the number of processors, the + number of pdflush threads, probably other things i don't have in mind + <braunr> i don't know what should make us adjust that value in mach + <youpi> which value? + <braunr> the size of the reserved pool + <youpi> I don't think it's adjusted + <braunr> that's what i'm saying + <braunr> i guess there is an #ifndef line for arch specific definitions + <youpi> err, you just said linux must adjust it : + <youpi> )) + <youpi> there is none + <braunr> linux adjusts it dynamically + <braunr> well ok + <braunr> that's another way to say it + <braunr> we don't have code to get rid of this macro + <braunr> but i don't even know how we, as maintainers, are supposed to + guess it diff --git a/open_issues/gnumach_memory_management_physical_memory.mdwn b/open_issues/gnumach_memory_management_physical_memory.mdwn new file mode 100644 index 00000000..58fefe1f --- /dev/null +++ b/open_issues/gnumach_memory_management_physical_memory.mdwn @@ -0,0 +1,46 @@ +[[!meta copyright="Copyright © 2011 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, freenode, #hurd, 2011-10: + + <braunr> antrik: about our physical memory limitations, i told you some + time ago that part of it was due to the linux drivers + <braunr> and i mentioned the paper concerning the integration of the linux + drivers written at the time + <braunr> it does indeed tell that mach, which used the common 3G->4G area + for the kernel space had to be adapted + <braunr> because linux used segmentation so that kernel addresses matched + physical addresses + <braunr> and it looks like some (many) drivers require that + <braunr> our current gnumach actually does this (which i found surprising + when i first found it) + <braunr> and i believe the easy solution to exceed this limitation is to + use a strategy similar to what linux still does on i386 + <braunr> some highmem support + <braunr> we could alter the vm_resident module so that, by default, it + still looks for pages in the low 0-800 (or 0-1800 on debian patched + kernels) area + <braunr> but for everything else than the kernel, e.g. all user processes + <braunr> we could use a flag or a specialized function that would first + look in the highmem pool for available physical pages to map + <braunr> the only thing i'm not yet sure of is about user/kernel transfers + <braunr> if virtual addresses and copies are always cleanly done, then it's + ok + <braunr> and i really hope our linux drivers do so :) + <braunr> (i mean ,the glue code ofc) + +2011-10-23: + + <youpi> braunr: I believe, like Linus, that highmem support is a nightmare + <antrik> braunr: uhm... the drivers want virtual addressses to match + physical ones? I guess that means switching address spaces before any + driver code is executed?... diff --git a/open_issues/issue_tracking.mdwn b/open_issues/issue_tracking.mdwn index 55c7b87b..72bb3b77 100644 --- a/open_issues/issue_tracking.mdwn +++ b/open_issues/issue_tracking.mdwn @@ -102,6 +102,84 @@ IRC, freenode, #hurd, 2011-08-31: <mattl> RT is not the easiest thing to set up, but works pretty well once it's running. +IRC, freenode, #hurd, 2011-10-19: + + <antrik> tschwinge: BTW, what happened to the plan of killing help-hurd? + <antrik> (and possibly some other lists) + <tschwinge> antrik: That plan got stalled, obviously. ;-) + <tschwinge> antrik: Now, I had proposed to use hurd-dev for development, + and turn bug-hurd into a debbugs bug reportling list. That proposal has + not heard any supportive/unsupportive votes yet. + <tschwinge> hurd-devel. That's the name. + <tschwinge> And turn off hurd-devel-readers. And turn off help-hurd. + <tschwinge> And web-hurd. + <tschwinge> Keep l4-hurd. + <antrik> yeah, I haven't replied regarding bug-hurd vs. hurd-devel, as I'm + not quite sure myself + <antrik> on one hand, a dedicated bug list can be convenient; on the other + hand, this kind of splits always causes unnecessary overhead IMHO + <antrik> also, hurd-devel would obviously be *only* for development, so in + this scenario we actually would *need* to keep something like help-hurd + as well... + <antrik> I think I'd prefer the non-exclusive mode for debbugs... would + have to check again how it works exactly though :-) + <tschwinge> antrik: I quite liked that exclusive mode for it automatically + archives discussions grouped by threads for easy reference. + <tschwinge> antrik: And, the very most of bug-hurd emails are ``issues'' of + some sort: bug report, patch (that needs to be tracked until it is + applied, etc. + <antrik> tschwinge: exclusive mode would just mean that people would take + most of these discussion elsewhere, and the bug list would only be used + when someone explicitly wants something tracked as a bug... + <antrik> ideally, the bug tracker should only track things if explicitly + CCed. ideally, it should be possible to forward mails that have been + posted without CC, so they can be tracked retroactively... + <tschwinge> antrik: Why do you think that people would take discussions + elsewhere? + <antrik> because most people don't consider it useful to put every random + question or remark in an issue tracker + <antrik> IMHO it should be easy to turn messages into tickets/followups; + but it should not happen automatically + <tschwinge> What if people wouldn't even notice that their issues is kept + in a tracker, too? + <draculus> It might send a notification of some sort? + <antrik> I once posted to a list with RT in exclusive mode, and quite + frankly, I considered it rather strange to get a ticket created for my + message :-) + <antrik> tschwinge: that would only be useful if you always close tickets + for irrelevant or finished discussions, mark duplicates etc. -- and this + would have to happen silently, without noise for most other people + following the list... + <antrik> tschwinge: are you sure you want to do that?... :-) + <tschwinge> Yes. + <tschwinge> Because that way we don't lose so much stuff as we currently + do. + <antrik> well, the decision is up to you in that case... + <tschwinge> In fact, probably less than manually archiving the content, as + I'm doing now, partially. + <tschwinge> antrik: Well, I'm just out for getting some comments. + <antrik> it would further reduce our bus factor though :-( + <tschwinge> That already is low enough that it doesn't matter anymore... + <tschwinge> antrik: So, to sum up, you'd use non-exclusive mode, but are + not actively opposed to exclusive mode as long as it doesn't too much + disturbe any procedures you're currently using? + <antrik> well, if it happens mostly in the background, I don't see why + anyone should be opposed... + <antrik> just make sure people posting to the list don't get a "ticket + created" message in response :-) + <antrik> it would make it harder though for people to explicitly track + issue they are interested in I fear + <antrik> when using non-exclusive mode, and people explicitly CC things to + the tracker, which sends a notice about a ticket being created, everyone + sees that and can act accordingly. if everything happens in the + background, few people would even think about it... + <antrik> so non-exclusive mode probably needs more effort to keep in order; + but it would be more useful too... + <tschwinge> Well, but with exclusive mode, people don't lose anything + compared to the current state, do they? + <antrik> tschwinge: probably not compared to the current state... but + possibly compared to a well-used non-exclusive mode :-) + # Further Systems diff --git a/open_issues/libpthread_assertion_thread_prevp.mdwn b/open_issues/libpthread_assertion_thread_prevp.mdwn new file mode 100644 index 00000000..1418bea1 --- /dev/null +++ b/open_issues/libpthread_assertion_thread_prevp.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2011 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="libpthread: __pthread_enqueue: Assertion `thread->prevp == 0' +failed"]] + +[[!tag open_issue_libpthread]] + +IRC, OFTC, #debian-hurd, 2011-10-21: + + [Python testsuite] + <pinotree> [169/340/1] test_logging + <pinotree> python: + /home/pino/sources/hurd/hurd-20110519/./libpthread/pthread/pt-internal.h:109: + __pthread_enqueue: Assertion `thread->prevp == 0' failed. + <pinotree> sigh + +IRC, freenode, #hurd, 2011-10-21: + + <pinotree> am i missing anything, or in libpthread the __pthread_threads + list does not ever has elements removed from it? + <pinotree> ... thus potentially causing + "./libpthread/pthread/pt-internal.h:109: __pthread_enqueue: Assertion + `thread->prevp == 0' failed." because threads can be appended on + __pthread_dealloc() to the __pthread_free_threads list as well? + <pinotree> maybe reusing the same next+prevp pointers in the __pthread + struct for more than one list at the same time isn't a good idea... + +2011-10-23: + + <youpi> pinotree: I don't understand the relation between thread->prevp != + 0 and the __pthread_threads list + <youpi> the list never has elements removed indeed, since libpthread never + frees __pthread structures apparently + <pinotree> youpi: ye sorry, that relation is indeed nonsense + <youpi> in which condition did you get prevp != 0 + <pinotree> i wa trying to find some explaination for the "thread->prevp == + 0" assertion in the _queue function + <youpi> ? + <pinotree> *was + <youpi> it's not obvious to me how libpthread makes sure the various + cond/mutex/rwlock make sure that it's not queued several times + <pinotree> yeah + <pinotree> apparently prevp/next are used for lists of held + waitcond/mutex/rwlock and free threads diff --git a/open_issues/libpthread_pthread_key_create_reuse.mdwn b/open_issues/libpthread_pthread_key_create_reuse.mdwn index a5704d0f..ca2da2f5 100644 --- a/open_issues/libpthread_pthread_key_create_reuse.mdwn +++ b/open_issues/libpthread_pthread_key_create_reuse.mdwn @@ -10,10 +10,10 @@ License|/fdl]]."]]"""]] [[!meta title="libpthread: pthread_key_create, reuse"]] -IRC, FreeNode, #hurd, 2011-07-02 - [[!tag open_issue_libpthread]] +IRC, FreeNode, #hurd, 2011-07-02: + < pinotree> hm, maybe i found a libpthread bug * pinotree tries a testcase < pinotree> yesssss, found the bug :) @@ -47,3 +47,36 @@ IRC, FreeNode, #hurd, 2011-07-02 veeery quick glance Test program: [[pthread_key_create_reuse.c]] + + +2011-11-01: + + <pinotree> youpi: about the bug with pthread keys (reuse): would be an + acceptable solution having a mutex for the thread_specifics of each + thread? + <youpi> you mean one per thread, one global, or one per key, or ? + <youpi> what is it supposed to protect? + <pinotree> the thread_specifics of each thread + <youpi> pinotree: but against what? + <pinotree> the idea would be: when destroying a key, iterate over all the + exiting threads and remove the key data from the thread_specifics of each + thread + <youpi> one of the issue is getting to browse through the whole list of + threads + <youpi> the other is concurrency between that, and a thread dying + <pinotree> there's the __pthread_threads_lock rwlock + <youpi> it should be enough to keep it locked during the iteration + <pinotree> but that wouldn't be enough when one thread is destroying a key, + and another one is doing {get,set}specific() on that key + <youpi> that's not supposed to happen + <pinotree> mmm + <youpi> “The effect of calling pthread_getspecific() or + pthread_setspecific() with a key value not obtained from + pthread_key_create() or after key has been deleted with + pthread_key_delete() is undefined.” + <youpi> undefined -> you are allowed to just blow up + <pinotree> but it's not been deleted yet... :) + <youpi> it could be, just a matter of time + <youpi> you're not supposed to rely on time-luckyness :) + <pinotree> mmm + <pinotree> bah, you've convinced me ( :) ) diff --git a/open_issues/libpthread_set_stack_size.mdwn b/open_issues/libpthread_set_stack_size.mdwn new file mode 100644 index 00000000..68f81752 --- /dev/null +++ b/open_issues/libpthread_set_stack_size.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2011 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, freenode, #hurd, 2011-10-21: + + <pinotree> maybe i'm missing something... what's the reason for not + allowing setting a different stack size in libpthread? + +2011-10-23: + + <youpi> pinotree: the threadvars implementations + <youpi> which needs to find the variables according to sp value + <youpi> of course, since we now have TLS, threadvards can go away + <youpi> it's simply on the so-long TODO list + +[[glibc/t/tls-threadvar]]. diff --git a/open_issues/mission_statement.mdwn b/open_issues/mission_statement.mdwn new file mode 100644 index 00000000..212d65e7 --- /dev/null +++ b/open_issues/mission_statement.mdwn @@ -0,0 +1,39 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2011-10-12: + + <ArneBab> we have a mission statement: http://hurd.gnu.org + <Gorodish> yes + <Gorodish> but it's quite wishy washy + <Gorodish> considering all the elegant capability Hurd potentially has to + offer + <antrik> Gorodish: it's true that the mission statement is very + abstract... but then, it's hard to put anything more specific into 35 + words + <Gorodish> not with some practice + <Gorodish> I notice programers tend to speak and write in terms of what + something does + <Gorodish> not what it is + <Gorodish> the "What is Hurd" is a good example + <Gorodish> there's a lot of interesting information there + <Gorodish> but the way it's ordered is odd + <antrik> a mission statement is not primarily a PR instrument; but rather a + guide that allows separating things that benefit the common goal from + things that don't... + <antrik> I agree that some actual marketing material in addition would be + nice :-) + <Gorodish> yes + <Gorodish> the modesty of Developers that work on FOSS projects never + ceases to amaze me + <Gorodish> I agree that the informational, factual, results oriented + documentation is the primary objective of documenting diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn index 359d5fee..d0b8ea7f 100644 --- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn +++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn @@ -27,6 +27,10 @@ extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24. On the idle grubber, this one repeatedly takes a few minutes wall time to complete successfully, contrary to a few seconds on a GNU/Linux system. +> On order of slowness may in fact be due to a Xen-specific issue, see +> [[xen_lseek]]. (But there are probably still one or two orders left, even +> without Xen.) + While processing the object files, there is heavy interaction with the relevant [[hurd/translator/ext2fs]] process. Running [[hurd/debugging/rpctrace]] on the testee shows that (primarily) an ever-repeating series of `io_seek` and @@ -47,4 +51,6 @@ IRC, freenode, #hurd, 2011-09-01: <youpi> (fgetpos actually, but that's the same) <youpi> and it is indeed about 10 times slower under Xen for some reason +Also see testcase [[test-lseek.c]] and [[test-mach.c]] + [[!tag open_issue_xen]] diff --git a/open_issues/performance/io_system/test-lseek.c b/open_issues/performance/io_system/test-lseek.c new file mode 100644 index 00000000..667dce66 --- /dev/null +++ b/open_issues/performance/io_system/test-lseek.c @@ -0,0 +1,17 @@ +#include <stdio.h> +#include <math.h> +#include <fcntl.h> +#include <unistd.h> +#include <sys/time.h> +#define N 100000 +int main(void) { + int fd = open("test.c", O_RDONLY); + struct timeval tv1, tv2; + int i; + gettimeofday(&tv1, NULL); + for (i = 0; i < N; i++) + lseek(fd, 0, SEEK_CUR); + gettimeofday(&tv2, NULL); + printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N); + return 0; +} diff --git a/open_issues/performance/io_system/test-mach.c b/open_issues/performance/io_system/test-mach.c new file mode 100644 index 00000000..90337346 --- /dev/null +++ b/open_issues/performance/io_system/test-mach.c @@ -0,0 +1,19 @@ +#define _GNU_SOURCE +#include <stdio.h> +#include <fcntl.h> +#include <mach/mach.h> +#define N 1000000 +int main(void) { + struct timeval tv1, tv2; + int i; + task_t task; + task = mach_task_self(); + mach_port_urefs_t refs; + gettimeofday(&tv1, NULL); + for (i = 0; i < N; i++) { + mach_port_get_refs(task, task, MACH_PORT_RIGHT_RECEIVE, &refs); + } + gettimeofday(&tv2, NULL); + printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N); + return 0; +} diff --git a/open_issues/pfinet_vs_system_time_changes.mdwn b/open_issues/pfinet_vs_system_time_changes.mdwn index 714c8784..513cbc73 100644 --- a/open_issues/pfinet_vs_system_time_changes.mdwn +++ b/open_issues/pfinet_vs_system_time_changes.mdwn @@ -17,7 +17,7 @@ IRC, unknown channel, unknown date. This was very likely a misdiagnosis: -IRC, freenode, #hurd, 2011-03-25 +IRC, freenode, #hurd, 2011-03-25: <tschwinge> antrik: I suspect it'S some timing stuff in pfinet that perhaps uses absolute time, and somehow wildely gets confused? @@ -40,3 +40,21 @@ IRC, freenode, #hurd, 2011-03-25 <tschwinge> (The other way round, you might likely get some integer wrap-around, and thus the same result.) <tschwinge> Yes. + +IRC, freenode, #hurd, 2011-10-26: + + <antrik> anyways, when ntpdate adjusts to the past, the connections hang, + roughly for the amount of time being adjusted + <antrik> they do not die though + <antrik> (well, if it's long enough, they probably timeout on the other + side...) + +IRC, freenode, #hurd, 2011-10-27: + + <antrik> oh, another interesting thing I observed is that the the subhurd + pfinet did *not* drop the connection... only the main Hurd one. I thought + the clock is system-wide?... + <tschwinge> It is. + <antrik> it's really fascinating that only the pfinet on the Hurd instance + where I set the date is affected, and not the pfinet in the other + instance diff --git a/open_issues/screen_dead_session.mdwn b/open_issues/screen_dead_session.mdwn index cdd3f322..fe51523b 100644 --- a/open_issues/screen_dead_session.mdwn +++ b/open_issues/screen_dead_session.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 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 @@ -14,7 +14,10 @@ Comparing to GNU/Linux, on GNU/Hurd it happens much more often and easily for *screen* sessions to become *dead*. This is annoying, as it defeats one of *screen*'s main purposes. -One reproducible scenario goes like this: +[[!toc]] + + +# One reproducible scenario goes like this * `ssh [somewhere]`, @@ -28,7 +31,8 @@ One reproducible scenario goes like this: * at some point, *P* will terminate / hang (after having received some kind of signal?), and the *screen* session will be reported as *dead*. -Another one, not as often reproduced: + +# Another one, not as often reproduced * `ssh [somewhere]`, @@ -43,3 +47,23 @@ Another one, not as often reproduced: (after having received some kind of signal?), and the *screen* session will *immediatelly* be reported as *dead*. (Perhaps the other way round: upon re-attaching, the *screen* session goes bonkers and takes *P* with it?) + + +# IRC, freenode, #hurd, 2011-10-19 + + <antrik> tschwinge: hm... haven't seen screen dying in a long time + <tschwinge> antrik: It's easy, and goes like this: have a session on one + system, log in from another, do screen -x and wait some time. + <antrik> I do this regularily. haven't had a crash in ages. + <antrik> (BTW, I'm not sure I ever had a crash on srceen -x... at that + time, I wasn't using -x. I often had crashes with screen -r. my + impression back then was that it works better when doing -rd -- in fact, + I always do that now, so I can't say whether crashes still happen with + only -r...) + +2011-10-26: + + <antrik> so I was saying the other day that I haven't had a screen crash in + a long time... well, here it was :-( + <antrik> this time it didn't crash on reconnect though, but already + before. probably when I killed the hanging ssh connection diff --git a/open_issues/ti-rpc_then_nfs.mdwn b/open_issues/ti-rpc_then_nfs.mdwn new file mode 100644 index 00000000..aa36e020 --- /dev/null +++ b/open_issues/ti-rpc_then_nfs.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2011 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_porting]] + +TI-RPC replaces glibc's Sun RPC implementation, [[!message-id +"4D0632C5.1040107@RedHat.com"]]. + +It needs some work on our side, [[!message-id +"20101214213212.GU1095@kepler.schwinge.homeip.net"]]. + +Then, the Hurd's [[hurd/translator/nfs]] translator and [[hurd/nfsd]] can be +re-enabled, [[!message-id "87hb2j7ha7.fsf@gnu.org"]]. diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn index e0828b28..11793582 100644 --- a/open_issues/translator_stdout_stderr.mdwn +++ b/open_issues/translator_stdout_stderr.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -13,3 +13,9 @@ License|/fdl]]."]]"""]] Decide / implement / fix that (all?) running (passive?) translators' output should show up on the (Mach / Hurd) console / syslog. + +[[!taglink open_issue_documentation]]: [[!message-id +"87oepj1wql.fsf@becket.becket.net"]] + +[[!taglink open_issue_documentation]]: Neal once had written an email on this +topic. diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn index e929f2bf..70c3c6dc 100644 --- a/open_issues/user-space_device_drivers.mdwn +++ b/open_issues/user-space_device_drivers.mdwn @@ -97,7 +97,7 @@ IRC, freenode, #hurd, 2011-07-27 * Hurd on L4: deva, fabrica - * [[DDE]] + * [[/DDE]] * Minix 3 @@ -195,7 +195,7 @@ IRC, freenode, #hurd, 2011-07-27 # External Projects - * [[DDE]] + * [[/DDE]] * <http://ertos.nicta.com.au/research/drivers/uldd/> diff --git a/open_issues/xen_lseek.mdwn b/open_issues/xen_lseek.mdwn new file mode 100644 index 00000000..accc7c8f --- /dev/null +++ b/open_issues/xen_lseek.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2011 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_xen]] + +IRC, freenode, #hurd, 2011-11-02: + + <youpi> btw, we have a performance issue with xen + <youpi> an lseek() call costs a huge lot + <youpi> like 1ms + <youpi> while the same costs just a few dozens µs with kvm + <youpi> there's of course the cost of switching between ring3, ring0, + ring1, ring0, ring3, but still + <gianluca> oh, nice. + <youpi> lseek is supposed to perform only a back&forth + <youpi> and I don't observe disk activity, so it's not waiting for the disk + to complete whatever atime change & such :) + <youpi> it was mentioned that perhaps xen in hvm mode with pv drivers would + be faster + <youpi> thanks to the ring3/"1" switching being done by the processor + <youpi> (and assuming npt) + <gianluca> hm + <gianluca> i'll look into that, sounds fun. + <gianluca> :) + <tschwinge> Here is a testcase: + http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec.html + +[[performance/io_system/binutils_ld_64ksec]]. diff --git a/source_repositories/discussion.mdwn b/source_repositories/discussion.mdwn new file mode 100644 index 00000000..ae64298e --- /dev/null +++ b/source_repositories/discussion.mdwn @@ -0,0 +1,193 @@ +[[!meta copyright="Copyright © 2011 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]]."]]"""]] + +[[!toc]] + + +# Integrating Development Braches/External Sources + +[[!taglink open_issue_documentation]] + +IRC, freenode, #hurd, 2011-10-11: + + <tschwinge> braunr: About integrating salloc (I'll just use this name). + <tschwinge> braunr: Ideally, as this is an external import, there should be + an empty Git branch where the initial-import code (right out of your + tree, for example) is added. + <tschwinge> braunr: Then this is merged into a GNU Mach salloc branch and + moved into the destination directory. + <tschwinge> Then, any bug fix patches that do not concern salloc itself, + should stay separately. + <tschwinge> Also, any improvements that are not specific to salloc itself. + <tschwinge> All other salloc development commits (try this; no this; fix + other thing; etc.) can be combined into one commit on the salloc branch. + <tschwinge> Does that make sense? + <tschwinge> braunr: The idea of the separate external/braunr-salloc-import + branch is that any external updates are applied to this branch (where + they'll apply) cleanly, and then it is merged into GNU Mach salloc (or + later master, once salloc is merged) again. + <antrik> tschwinge: if you really want to use a branch for the external + code import, better actually import it with its history, not just as a + snapshot + <antrik> (disclaimer: haven't actually tried how well this works in + practice...) + <tschwinge> antrik: Yes, generally this is even better, but: + <tschwinge> antrik: But typically the external code we want to import is + just a subset of its external repository. And I don't think we want to + have all of the external development history. + <antrik> that's the only sane way to do proper followup merges... + <antrik> admittedly it makes git log a bit confusing... + <tschwinge> antrik: Why is it the only sane way? + <braunr> tschwinge: "an empty Git branch", out of the gnumach git + repository ? + <braunr> tschwinge: then imported "into a GNU Mach salloc branch" ? + <antrik> tschwinge: otherwise you don't have merge history. you get no idea + why anything changed in the external code; and it's hard to merge any + changes happening in the local repository vs. the imports + <tschwinge> antrik: Of course, importing all the history may make sense at + times, but if we use the [Linux]/include/gcc-atomic.h header, we're + surely not going to import all the Linux kernel history for that. + Instead we would update our import branch with every upstream Linux + release, for example. + <tschwinge> braunr: You want me to clarify these points? + <braunr> tschwinge: yes please + <tschwinge> braunr: Start with an empty Git repository: mkdir import && cd + import/ && git init + <tschwinge> braunr: Add the files to-be-imported in there, adn commit that + as ``import ... version/Git commit from ...''. + <pinotree> tschwinge: maybe + http://book.git-scm.com/5_creating_new_empty_branches.html ? + <tschwinge> pinotree: Oh nice. + <tschwinge> pinotree: Thanks. + <pinotree> np + <tschwinge> Yes, can also do that, or a new Git repository as I said. + <tschwinge> braunr: Prefereably add the files in a salloc directory right + away to avoid any merge conflicts later on. + <tschwinge> braunr: Then, in GNU Mach, branch off of master: git checkout + -b salloc origin/master + <tschwinge> This will be the salloc integration working branch. + <tschwinge> braunr: Actually not ``in a salloc directory'', but with the + name the thing has in your upstream repository. + <tschwinge> Then, make the external import branch known here: git fetch + ../import master:external/import-braunr-allocator + <tschwinge> Then you can merge the external branch into the salloc branch: + git merge external/import-braunr-allocator + <braunr> got most of it, except for the "salloc directory" + <tschwinge> Then, move everything in place, and either commit --amend it to + the merge, or a separate commit. + <braunr> ah, you really suggest a separate directory not to have any + conflict + <braunr> then a move + <tschwinge> Right. + <braunr> but there maybe conflict afterwards + <tschwinge> I take it that the alloc files live in [x15]/kern/allocator, so + you'd put them into kern/allocator in the new repository, and then (after + merging that branch) move them to kern/salloc (or similar). + <braunr> i'm not sure i get the point + <braunr> no they won't + <braunr> it will live in kern/salloc.c, and the additional required files + like list.h may be put there too + <tschwinge> Aha, OK. + <braunr> but these are clearly separate files, so it should give the same + results, right ? + <tschwinge> Well, you could in the import branch put them all into x15/, + then merge, then move the files to kern/salloc.c, misc/list.h, etc. + <braunr> hm let's call it salloc/ :) + <braunr> but ok + <tschwinge> It's just that the import branch should have the same structure + than upstream has. + <tschwinge> To faciliate further imports later on. + <braunr> well, that's why i don't see the point of the move + <tschwinge> And after the merge it should have the file system structure as + used by GNU Mach. + <braunr> and there will be no upstream; once it's in gnu mach, it has its + own life + <tschwinge> Ah, OK. + <tschwinge> Well, then it won't matter too much. + <braunr> wouldn't it be better to make "upstream" (maskym's branch) have + the same structure as gnu mach already has before even creating the + integration branch ? + <tschwinge> I though X15 is the upstream. + <braunr> maksym* + <braunr> the upstream was actually the userspace library, before x15 got + its own derived version + <tschwinge> OK, I see. + <tschwinge> Then we really don't care too much, and yes, you can put it all + in the right places right away. + <braunr> ok + <tschwinge> But is my approach understandable given there is an upstream + from which we may want to import later changes? + <tschwinge> given there *were* + <braunr> (fyi, the userspace code was merely a first step which purpose was + to eliminate as many bugs as possible and profile a little) + <braunr> i don't intend to maintain the userspace code, no + <braunr> and the x15 version already has some system specific changes that + don't apply to gnu mach + <tschwinge> OK, I understand. + <tschwinge> braunr: Then, what remains is essentially this: + <tschwinge> <tschwinge> Then, any bug fix patches that do not concern + salloc itself, should stay separately. + <tschwinge> <tschwinge> Also, any improvements that are not specific to + salloc itself. + <tschwinge> <tschwinge> All other salloc development commits (try this; no + this; fix other thing; etc.) can be combined into one commit on the + salloc branch. + <tschwinge> Right? + <braunr> ok + <braunr> hm, what about the history of maksym's branch ? + <tschwinge> braunr: We don't really need it, do we? + <tschwinge> If there are distinct commits that make sense to be kept + separate, then that is fine, but all the development commits can usually + be merged. + <tschwinge> ``squashed'' + <braunr> i don't think we do, no + <braunr> ok so, i'll use his branch as a starting point in a private git + repository, until it's good enough to be merged upstream, then we'll + create the salloc integration branch and later merge that into master + <braunr> tschwinge: did i get it right ? :) + <tschwinge> We can still either keep Maksym's development branch open, or + perhaps create a tag named salloc-before-merge. + <tschwinge> Well, I think if we don't need to do the upstream-import thing, + then you can create a salloc integration branch right away, and prepare + everything in there. + <braunr> ok + <braunr> i'm not very familiar with remote branches + <tschwinge> OK. This way you don't need any. + <tschwinge> Just branch off of master (either your local master branch or + origin/master): git checkout -b salloc origin/master + <antrik> braunr: BTW, I'm not sure it has been clear, so let me restate it: + what large projects using Git usually do when merging new features + upstream is, they entirely drop the development history of the feature, + instead creating a new branch (or reworking the old one) which is + master-centric -- it is a series of commits, which get from the original + master to a state with the new feature implemented in the most + straightforward way + <braunr> antrik: in one commit ? + <braunr> antrik: or a few ofc + <antrik> depends. the commits should be bisectable as usual... i.e. don't + put things that can be separate into one commit, but don't separate + things that depend on each other into separate commits either :-) + <antrik> the bulk of the new code often goes in single large commit; but + the various changes to existing code necessary to make it work can often + make a pretty long series. but it can differ quite a lot depending on the + specific case + <antrik> just imagine you are someone reading the history in the future, + and tries to understand what changed while zalloc was replaced by + salloc. what series of commits makes this most obvious? + <braunr> sure + <braunr> antrik: new code first in a single commit first, then the + replacements from zalloc to salloc, then if any, special adjustements in + a third commit + <braunr> (ok twice first, remove one at will :p) + <antrik> yeah, something along these lines + <antrik> sometimes we also need praparation commits in advance, changing + the code structure so that the new feature can be added in a + straightforward fashion + <antrik> or cleanups afterwards diff --git a/unsorted/FunnyHurd.mdwn b/unsorted/FunnyHurd.mdwn index 1653ec77..1a70fb8a 100644 --- a/unsorted/FunnyHurd.mdwn +++ b/unsorted/FunnyHurd.mdwn @@ -1,39 +1,23 @@ -## <a name="Fun_stuff_ripped_from_the_Intern"> Fun stuff ripped from the Internet </a> - -<table border="1" cellpadding="1" cellspacing="0"> - <tr> - <td> %ATTACHURL%/hurd-windows.gif <br /> Hurd Windows, availble from <a href="http://www.hurd.com" target="_top">http://www.hurd.com</a></td> - <td> %ATTACHURL%/HurdExchange.gif <br /> Exchange your Hurd at <a href="http://www.thunderinghurd.com" target="_top">http://www.thunderinghurd.com</a></td> - </tr> - <tr> - <td> %ATTACHURL%/HurdCarDeal.jpg <br /> ... and we can of course also offer you a great deal on this -91 Chevy! :-) </td> - <td> %ATTACHURL%/HurdLodge.jpg <br /> The many perks of being a Hurd user also includes our own ski lodge! <br /><font size="+2">Hurd House</font><br /> - <ul> - <li>Knotty pine kitchen</li> - <li>Spacious kitchen &amp; living room with loft</li> - <li>Leather couch and love seat with a TV &amp; VCR</li> - <li>Outdoor Jacuzzi</li> - <li>Spacious master bedroom/bath upstairs</li> - <li>Twin beds in one room / queen bed in another</li> - </ul> - </td> - </tr> - <tr> - <td> %ATTACHURL%/HurdMagician.jpg <br /> From <a href="http://www.magicposters.com/buy/h-k.html" target="_top">http://www.magicposters.com/buy/h-k.html</a></td> - <td> %ATTACHURL%/CrystalAwards.jpg <br /> "Wow dude, I saw the Debian Swirl logo on last nights <a href="http://www.wif.org/events/crystals.html" target="_top">Crystal Awards</a>!" </td> - </tr> -</table> - ----- - -These images and links are only here to serve as a comic relief to this site. It is **not** the intention to humiliate the people, corporations or organizations behind these factual sites. - -If your [company] name or organization is listed here and you do not approve you can remove yourself simply by clicking on the "Edit" button. In the login window that appears you enter _TWikiGuest_ as username and _guest_ as password. - ----- - -### <a name="Comments"> Comments </a> - -Created the page. - --- [[Main/JoachimNilsson]] - 09 Nov 2002 +Fun stuff ripped from the Internet. + + * [*Martine termine + GNU/Hurd*](https://plus.google.com/105752945023653836002/posts/VLDp1HfXLZ6). + <img + src="https://lh6.googleusercontent.com/-rzRt1aMSWrE/TrBJvkDboRI/AAAAAAAABx8/3KhzIvPTZ1w/h301/martine-termine-gnu-hurd.jpg"> + + * Hurd Windows, availble from <http://www.hurd.com>. [[hurd-windows.gif]] + + * Exchange your Hurd at <http://www.thunderinghurd.com>. + [[HurdExchange.gif]] + + * ... and we can of course also offer you a great deal on this -91 Chevy! + :-) [[HurdCarDeal.jpg]] + + * From <http://www.magicposters.com/buy/h-k.html>. [[HurdMagician.jpg]] + + +--- + +These images and links are only here to serve as a comic relief to this site. +It is **not** the intention to humiliate the people, corporations or +organizations behind these factual sites. diff --git a/unsorted/FunnyHurd/CrystalAwards.jpg b/unsorted/FunnyHurd/CrystalAwards.jpg Binary files differdeleted file mode 100644 index 2daac850..00000000 --- a/unsorted/FunnyHurd/CrystalAwards.jpg +++ /dev/null diff --git a/unsorted/FunnyHurd/HurdLodge.jpg b/unsorted/FunnyHurd/HurdLodge.jpg Binary files differdeleted file mode 100644 index d13562f5..00000000 --- a/unsorted/FunnyHurd/HurdLodge.jpg +++ /dev/null |
