diff options
915 files changed, 64180 insertions, 4115 deletions
@@ -1,2 +1,3 @@ *~ -.ikiwiki + +/.ikiwiki*/ diff --git a/.gitmodules b/.gitmodules new file mode 100644 index 00000000..47fbf711 --- /dev/null +++ b/.gitmodules @@ -0,0 +1,3 @@ +[submodule "toolchain/logs"] + path = toolchain/logs + url = . diff --git a/.library/IkiWiki/Plugin/field.pm b/.library/IkiWiki/Plugin/field.pm new file mode 100644 index 00000000..d77e7282 --- /dev/null +++ b/.library/IkiWiki/Plugin/field.pm @@ -0,0 +1,722 @@ +#!/usr/bin/perl +# Ikiwiki field plugin. +# See doc/plugin/contrib/field.mdwn for documentation. +package IkiWiki::Plugin::field; +use warnings; +use strict; +=head1 NAME + +IkiWiki::Plugin::field - front-end for per-page record fields. + +=head1 VERSION + +This describes version B<1.20101101> of IkiWiki::Plugin::field + +=cut + +our $VERSION = '1.20101115'; + +=head1 PREREQUISITES + + IkiWiki + +=head1 AUTHOR + + Kathryn Andersen (RUBYKAT) + http://github.com/rubykat + +=head1 COPYRIGHT + +Copyright (c) 2009-2010 Kathryn Andersen + +This program is free software; you can redistribute it and/or +modify it under the same terms as Perl itself. + +=cut + +use IkiWiki 3.00; + +my %Fields = ( + _first => { + id => '_first', + seq => 'BB', + }, + _last => { + id => '_last', + seq => 'YY', + }, + _middle => { + id => '_middle', + seq => 'MM', + }, +); +my @FieldsLookupOrder = (); + +my %Cache = (); + +sub field_get_value ($$); + +sub import { + hook(type => "getsetup", id => "field", call => \&getsetup); + hook(type => "checkconfig", id => "field", call => \&checkconfig); + hook(type => "scan", id => "field", call => \&scan, last=>1); + hook(type => "pagetemplate", id => "field", call => \&pagetemplate); +} + +# =============================================== +# Hooks +# --------------------------- +sub getsetup () { + return + plugin => { + safe => 1, + rebuild => undef, + }, + field_register => { + type => "hash", + example => "field_register => {meta => 'last'}", + description => "simple registration of fields by plugin", + safe => 0, + rebuild => undef, + }, + field_allow_config => { + type => "boolean", + example => "field_allow_config => 1", + description => "allow config settings to be queried", + safe => 0, + rebuild => undef, + }, + field_tags => { + type => "hash", + example => "field_tags => {BookAuthor => '/books/authors'}", + description => "fields flagged as tag-fields", + safe => 0, + rebuild => undef, + }, +} + +sub checkconfig () { + # use the simple by-plugin pagestatus method for + # those plugins registered with the field_register config option. + if (defined $config{field_register}) + { + if (ref $config{field_register} eq 'ARRAY') + { + foreach my $id (@{$config{field_register}}) + { + field_register(id=>$id); + } + } + elsif (ref $config{field_register} eq 'HASH') + { + foreach my $id (keys %{$config{field_register}}) + { + field_register(id=>$id, order=>$config{field_register}->{$id}); + } + } + else + { + field_register(id=>$config{field_register}); + } + } + if (!defined $config{field_allow_config}) + { + $config{field_allow_config} = 0; + } +} # checkconfig + +sub scan (@) { + my %params=@_; + my $page=$params{page}; + my $content=$params{content}; + + # scan for tag fields + if ($config{field_tags}) + { + foreach my $field (keys %{$config{field_tags}}) + { + my @values = field_get_value($field, $page); + if (@values) + { + foreach my $tag (@values) + { + if ($tag) + { + my $link = $config{field_tags}{$field} . '/' + . titlepage($tag); + add_link($page, $link, lc($field)); + } + } + } + } + } +} # scan + +sub pagetemplate (@) { + my %params=@_; + my $page=$params{page}; + my $template=$params{template}; + + field_set_template_values($template, $page); +} # pagetemplate + +# =============================================== +# Field interface +# --------------------------- + +sub field_register (%) { + my %param=@_; + if (!exists $param{id}) + { + error 'field_register requires id parameter'; + return 0; + } + if (exists $param{call} and !ref $param{call}) + { + error 'field_register call parameter must be function'; + return 0; + } + + my $id = $param{id}; + $Fields{$id} = \%param; + + # add this to the ordering hash + # first, last, order; by default, middle + my $when = ($param{first} + ? '_first' + : ($param{last} + ? '_last' + : ($param{order} + ? ($param{order} eq 'first' + ? '_first' + : ($param{order} eq 'last' + ? '_last' + : ($param{order} eq 'middle' + ? '_middle' + : $param{order} + ) + ) + ) + : '_middle' + ) + )); + add_lookup_order($id, $when); + return 1; +} # field_register + +sub field_get_value ($$) { + my $field_name = shift; + my $page = shift; + + # This will return the first value it finds + # where the value returned is not undefined. + # This will return an array of values if wantarray is true. + + # The reason why it checks every registered plugin rather than have + # plugins declare which fields they know about, is that it is quite + # possible that a plugin doesn't know, ahead of time, what fields + # will be available; for example, a YAML format plugin would return + # any field that happens to be defined in a YAML page file, which + # could be anything! + + # check the cache first + my $lc_field_name = lc($field_name); + if (wantarray) + { + if (exists $Cache{$page}{$lc_field_name}{array} + and defined $Cache{$page}{$lc_field_name}{array}) + { + return @{$Cache{$page}{$lc_field_name}{array}}; + } + } + else + { + if (exists $Cache{$page}{$lc_field_name}{scalar} + and defined $Cache{$page}{$lc_field_name}{scalar}) + { + return $Cache{$page}{$lc_field_name}{scalar}; + } + } + + if (!@FieldsLookupOrder) + { + build_fields_lookup_order(); + } + + # Get either the scalar or the array value depending + # on what is requested - don't get both because it wastes time. + if (wantarray) + { + my @array_value = undef; + foreach my $id (@FieldsLookupOrder) + { + # get the data from the pagestate hash if it's there + if (exists $pagestate{$page}{$id}{$field_name} + and defined $pagestate{$page}{$id}{$field_name}) + { + @array_value = (ref $pagestate{$page}{$id}{$field_name} + ? @{$pagestate{$page}{$id}{$field_name}} + : ($pagestate{$page}{$id}{$field_name})); + } + elsif (exists $pagestate{$page}{$id}{$lc_field_name} + and defined $pagestate{$page}{$id}{$lc_field_name}) + { + @array_value = (ref $pagestate{$page}{$id}{$lc_field_name} + ? @{$pagestate{$page}{$id}{$lc_field_name}} + : ($pagestate{$page}{$id}{$lc_field_name})); + } + elsif (exists $Fields{$id}{call}) + { + @array_value = $Fields{$id}{call}->($field_name, $page); + } + if (@array_value and $array_value[0]) + { + last; + } + } + if (!@array_value) + { + @array_value = field_calculated_values($field_name, $page); + } + # cache the value + $Cache{$page}{$lc_field_name}{array} = \@array_value; + return @array_value; + } + else # scalar + { + my $value = undef; + foreach my $id (@FieldsLookupOrder) + { + # get the data from the pagestate hash if it's there + # but only if it's already a scalar + if (exists $pagestate{$page}{$id}{$field_name} + and !ref $pagestate{$page}{$id}{$field_name}) + { + $value = $pagestate{$page}{$id}{$field_name}; + } + elsif (exists $pagestate{$page}{$id}{$lc_field_name} + and !ref $pagestate{$page}{$id}{$lc_field_name}) + { + $value = $pagestate{$page}{$id}{$lc_field_name}; + } + elsif (exists $Fields{$id}{call}) + { + $value = $Fields{$id}{call}->($field_name, $page); + } + if (defined $value) + { + last; + } + } + if (!defined $value) + { + $value = field_calculated_values($field_name, $page); + } + # cache the value + $Cache{$page}{$lc_field_name}{scalar} = $value; + return $value; + } + + return undef; +} # field_get_value + +# set the values for the given HTML::Template template +sub field_set_template_values ($$;@) { + my $template = shift; + my $page = shift; + my %params = @_; + + my $get_value_fn = (exists $params{value_fn} + ? $params{value_fn} + : \&field_get_value); + + # Find the parameter names in this template + # and see if you can find their values. + + # The reason we check the template for field names is because we + # don't know what fields the registered plugins provide; and this is + # reasonable because for some plugins (e.g. a YAML data plugin) they + # have no way of knowing, ahead of time, what fields they might be + # able to provide. + + my @parameter_names = $template->param(); + foreach my $field (@parameter_names) + { + # Don't redefine if the field already has a value set. + next if ($template->param($field)); + + my $type = $template->query(name => $field); + if ($type eq 'LOOP' and $field =~ /_LOOP$/oi) + { + # Loop fields want arrays. + # Figure out what field names to look for: + # * names are from the enclosed loop fields + my @loop_fields = $template->query(loop => $field); + + my @loop_vals = (); + my %loop_field_arrays = (); + foreach my $fn (@loop_fields) + { + if ($fn !~ /^__/o) # not a special loop variable + { + my @ival_array = $get_value_fn->($fn, $page); + if (@ival_array) + { + $loop_field_arrays{$fn} = \@ival_array; + } + } + } + foreach my $fn (sort keys %loop_field_arrays) + { + my $i = 0; + foreach my $v (@{$loop_field_arrays{$fn}}) + { + if (!defined $loop_vals[$i]) + { + $loop_vals[$i] = {}; + } + $loop_vals[$i]{$fn} = $v; + $i++; + } + } + $template->param($field => \@loop_vals); + } + else # not a loop field + { + my $value = $get_value_fn->($field, $page); + if (defined $value) + { + $template->param($field => $value); + } + } + } +} # field_set_template_values + +# =============================================== +# Private Functions +# --------------------------- + +# Calculate the lookup order +# <module, >module, AZ +# This is crabbed from the PmWiki Markup function +sub add_lookup_order { + my $id = shift; + my $when = shift; + + # may have given an explicit ordering + if ($when =~ /^[A-Z][A-Z]$/o) + { + $Fields{$id}{seq} = $when; + } + else + { + my $cmp = '='; + my $seq_field = $when; + if ($when =~ /^([<>])(.+)$/o) + { + $cmp = $1; + $seq_field = $2; + } + $Fields{$seq_field}{dep}{$id} = $cmp; + if (exists $Fields{$seq_field}{seq} + and defined $Fields{$seq_field}{seq}) + { + $Fields{$id}{seq} = $Fields{$seq_field}{seq} . $cmp; + } + } + if ($Fields{$id}{seq}) + { + foreach my $i (keys %{$Fields{$id}{dep}}) + { + my $m = $Fields{$id}{dep}{$i}; + add_lookup_order($i, "$m$id"); + } + delete $Fields{$id}{dep}; + } +} + +sub build_fields_lookup_order { + + # remove the _first, _last and _middle dummy fields + # because we don't need them anymore + delete $Fields{_first}; + delete $Fields{_last}; + delete $Fields{_middle}; + my %lookup_spec = (); + # Make a hash of the lookup sequences + foreach my $id (sort keys %Fields) + { + my $seq = ($Fields{$id}{seq} + ? $Fields{$id}{seq} + : 'MM'); + if (!exists $lookup_spec{$seq}) + { + $lookup_spec{$seq} = {}; + } + $lookup_spec{$seq}{$id} = 1; + } + + # get the field-lookup order by (a) sorting by lookup_spec + # and (b) sorting by field-name for the fields that registered + # the same field-lookup order + foreach my $ord (sort keys %lookup_spec) + { + push @FieldsLookupOrder, sort keys %{$lookup_spec{$ord}}; + } +} # build_fields_lookup_order + +# standard values deduced from other values +sub field_calculated_values { + my $field_name = shift; + my $page = shift; + + my $value = undef; + + # Exception for titles + # If the title hasn't been found, construct it + if ($field_name eq 'title') + { + $value = pagetitle(IkiWiki::basename($page)); + } + # and set "page" if desired + elsif ($field_name eq 'page') + { + $value = $page; + } + # the page above this page; aka the current directory + elsif ($field_name eq 'parent_page') + { + if ($page =~ m{^(.*)/[-\.\w]+$}o) + { + $value = $1; + } + } + elsif ($field_name eq 'basename') + { + $value = IkiWiki::basename($page); + } + elsif ($config{field_allow_config} + and $field_name =~ /^config-(.*)$/oi) + { + my $cfield = $1; + if (exists $config{$cfield}) + { + $value = $config{$cfield}; + } + } + elsif ($field_name =~ /^(.*)-tagpage$/o) + { + my @array_value = undef; + my $real_fn = $1; + if (exists $config{field_tags}{$real_fn} + and defined $config{field_tags}{$real_fn}) + { + my @values = field_get_value($real_fn, $page); + if (@values) + { + foreach my $tag (@values) + { + if ($tag) + { + my $link = $config{field_tags}{$real_fn} . '/' . $tag; + push @array_value, $link; + } + } + if (wantarray) + { + return @array_value; + } + else + { + $value = join(",", @array_value) if $array_value[0]; + } + } + } + } + return (wantarray ? ($value) : $value); +} # field_calculated_values + +# match field funcs +# page-to-check, wanted +sub match_a_field ($$) { + my $page=shift; + my $wanted=shift; + + # The field name is first; the rest is the match + my $field_name; + my $glob; + if ($wanted =~ /^(\w+)\s+(.*)$/o) + { + $field_name = $1; + $glob = $2; + } + else + { + return IkiWiki::FailReason->new("cannot match field"); + } + + # turn glob into a safe regexp + my $re=IkiWiki::glob2re($glob); + + my $val = IkiWiki::Plugin::field::field_get_value($field_name, $page); + + if (defined $val) { + if ($val=~/^$re$/i) { + return IkiWiki::SuccessReason->new("$re matches $field_name of $page", $page => $IkiWiki::DEPEND_CONTENT, "" => 1); + } + else { + return IkiWiki::FailReason->new("$re does not match $field_name of $page", "" => 1); + } + } + else { + return IkiWiki::FailReason->new("$page does not have a $field_name", "" => 1); + } +} # match_a_field + +# check against individual items of a field +# (treat the field as an array) +# page-to-check, wanted +sub match_a_field_item ($$) { + my $page=shift; + my $wanted=shift; + + # The field name is first; the rest is the match + my $field_name; + my $glob; + if ($wanted =~ /^(\w+)\s+(.*)$/o) + { + $field_name = $1; + $glob = $2; + } + else + { + return IkiWiki::FailReason->new("cannot match field"); + } + + # turn glob into a safe regexp + my $re=IkiWiki::glob2re($glob); + + my @val_array = IkiWiki::Plugin::field::field_get_value($field_name, $page); + + if (@val_array) + { + foreach my $val (@val_array) + { + if (defined $val) { + if ($val=~/^$re$/i) { + return IkiWiki::SuccessReason->new("$re matches $field_name of $page", $page => $IkiWiki::DEPEND_CONTENT, "" => 1); + } + } + } + # not found + return IkiWiki::FailReason->new("$re does not match $field_name of $page", "" => 1); + } + else { + return IkiWiki::FailReason->new("$page does not have a $field_name", "" => 1); + } +} # match_a_field_item + +# =============================================== +# PageSpec functions +# --------------------------- + +package IkiWiki::PageSpec; + +sub match_field ($$;@) { + my $page=shift; + my $wanted=shift; + return IkiWiki::Plugin::field::match_a_field($page, $wanted); +} # match_field + +sub match_destfield ($$;@) { + my $page=shift; + my $wanted=shift; + my %params=@_; + + return IkiWiki::FailReason->new("cannot match destpage") unless exists $params{destpage}; + + # Match the field on the destination page, not the source page + return IkiWiki::Plugin::field::match_a_field($params{destpage}, $wanted); +} # match_destfield + +sub match_field_item ($$;@) { + my $page=shift; + my $wanted=shift; + return IkiWiki::Plugin::field::match_a_field_item($page, $wanted); +} # match_field + +sub match_destfield_item ($$;@) { + my $page=shift; + my $wanted=shift; + my %params=@_; + + return IkiWiki::FailReason->new("cannot match destpage") unless exists $params{destpage}; + + # Match the field on the destination page, not the source page + return IkiWiki::Plugin::field::match_a_field_item($params{destpage}, $wanted); +} # match_destfield + +sub match_field_tagged ($$;@) { + my $page=shift; + my $wanted=shift; + my %params=@_; + + # The field name is first; the rest is the match + my $field_name; + my $glob; + if ($wanted =~ /^(\w+)\s+(.*)$/o) + { + $field_name = $1; + $glob = $2; + } + else + { + return IkiWiki::FailReason->new("cannot match field"); + } + return match_link($page, $glob, linktype => lc($field_name), @_); +} + +sub match_destfield_tagged ($$;@) { + my $page=shift; + my $wanted=shift; + my %params=@_; + + return IkiWiki::FailReason->new("cannot match destpage") unless exists $params{destpage}; + + # Match the field on the destination page, not the source page + return IkiWiki::Plugin::field::match_field_tagged($params{destpage}, $wanted); +} + +# =============================================== +# SortSpec functions +# --------------------------- +package IkiWiki::SortSpec; + +sub cmp_field { + my $field = shift; + error(gettext("sort=field requires a parameter")) unless defined $field; + + my $left = IkiWiki::Plugin::field::field_get_value($field, $a); + my $right = IkiWiki::Plugin::field::field_get_value($field, $b); + + $left = "" unless defined $left; + $right = "" unless defined $right; + return $left cmp $right; +} + +sub cmp_field_natural { + my $field = shift; + error(gettext("sort=field requires a parameter")) unless defined $field; + + eval q{use Sort::Naturally}; + error $@ if $@; + + my $left = IkiWiki::Plugin::field::field_get_value($field, $a); + my $right = IkiWiki::Plugin::field::field_get_value($field, $b); + + $left = "" unless defined $left; + $right = "" unless defined $right; + return Sort::Naturally::ncmp($left, $right); +} + +1; diff --git a/.library/IkiWiki/Plugin/getfield.pm b/.library/IkiWiki/Plugin/getfield.pm new file mode 100644 index 00000000..971e7ecb --- /dev/null +++ b/.library/IkiWiki/Plugin/getfield.pm @@ -0,0 +1,126 @@ +#!/usr/bin/perl +# Ikiwiki getfield plugin. +# Substitute field values in the content of the page. +# See plugin/contrib/getfield for documentation. +package IkiWiki::Plugin::getfield; +use strict; +=head1 NAME + +IkiWiki::Plugin::getfield - query the values of fields + +=head1 VERSION + +This describes version B<1.20101101> of IkiWiki::Plugin::getfield + +=cut + +our $VERSION = '1.20101101'; + +=head1 PREREQUISITES + + IkiWiki + IkiWiki::Plugin::field + +=head1 AUTHOR + + Kathryn Andersen (RUBYKAT) + http://github.com/rubykat + +=head1 COPYRIGHT + +Copyright (c) 2009 Kathryn Andersen + +This program is free software; you can redistribute it and/or +modify it under the same terms as Perl itself. + +=cut + +use IkiWiki 3.00; + +sub import { + hook(type => "getsetup", id => "getfield", call => \&getsetup); + hook(type => "filter", id => "getfield", call => \&do_filter, last=>1); + + IkiWiki::loadplugin("field"); +} + +#--------------------------------------------------------------- +# Hooks +# -------------------------------- + +sub getsetup () { + return + plugin => { + safe => 1, + rebuild => undef, + }, +} + +sub do_filter (@) { + my %params=@_; + my $page = $params{page}; + my $destpage = ($params{destpage} ? $params{destpage} : $params{page}); + + my $page_file=$pagesources{$page}; + my $page_type=pagetype($page_file); + if (defined $page_type) + { + while ($params{content} =~ /{{\$([-\w\/]+#)?[-\w]+}}/) + { + # substitute {{$var}} variables (source-page) + $params{content} =~ s/{{\$([-\w]+)}}/get_field_value($1,$page)/eg; + + # substitute {{$page#var}} variables (source-page) + $params{content} =~ s/{{\$([-\w\/]+)#([-\w]+)}}/get_other_page_field_value($2,$page,$1)/eg; + } + } + + $page_file=$pagesources{$destpage}; + $page_type=pagetype($page_file); + if (defined $page_type) + { + while ($params{content} =~ /{{\+\$([-\w\/]+#)?[-\w]+\+}}/) + { + # substitute {{+$var+}} variables (dest-page) + $params{content} =~ s/{{\+\$([-\w]+)\+}}/get_field_value($1,$destpage)/eg; + # substitute {{+$page#var+}} variables (source-page) + $params{content} =~ s/{{\+\$([-\w\/]+)#([-\w]+)\+}}/get_other_page_field_value($2,$destpage,$1)/eg; + } + } + + return $params{content}; +} # do_filter + +#--------------------------------------------------------------- +# Private functions +# -------------------------------- +sub get_other_page_field_value ($$$) { + my $field = shift; + my $page = shift; + my $other_page = shift; + + my $use_page = bestlink($page, $other_page); + # add a dependency for the page from which we get the value + add_depends($page, $use_page); + + my $val = get_field_value($field, $use_page); + if ($val eq $field) + { + return "${other_page}#$field"; + } + return $val; + +} # get_other_page_field_value + +sub get_field_value ($$) { + my $field = shift; + my $page = shift; + + my $value = IkiWiki::Plugin::field::field_get_value($field,$page); + return $value if defined $value; + + # if there is no value, return the field name. + return $field; +} # get_field_value + +1; diff --git a/.library/IkiWiki/Plugin/reset_mtimes.pm b/.library/IkiWiki/Plugin/reset_mtimes.pm new file mode 100644 index 00000000..a168652b --- /dev/null +++ b/.library/IkiWiki/Plugin/reset_mtimes.pm @@ -0,0 +1,84 @@ +# Copyright © 2010 Thomas Schwinge <thomas@schwinge.name> + +# This program 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. +# +# This program 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., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + +package IkiWiki::Plugin::reset_mtimes; + +use warnings; +use strict; +use IkiWiki 3.00; + +# This plugin resets pages' / files' mtimes according to the RCS information +# when using --refresh mode. +# +# Note that the files' mtimes are *always* set, even if the file has +# un-committed changes. +# +# <http://ikiwiki.info/bugs/pagemtime_in_refresh_mode/> + +sub import +{ + hook (type => "needsbuild", + id => "reset_mtimes", + call => \&needsbuild); +} + +sub needsbuild (@) +{ + # Only proceed if --gettime is in effect, as we're clearly not intersted in + # this functionality otherwise. + return unless $config{gettime}; + + my $files = shift; + foreach my $file (@$files) + { + # [TODO. Perhaps not necessary. Can this hook ever be called for + # removed pages -- that need to be ``rebuilt'' in the sense that + # they're to be removed?] Don't bother for pages that don't exist + # anymore. + next unless -e "$config{srcdir}/$file"; + + my $page = pagename ($file); + debug ("needsbuild: <$file> <$page>"); + + # Only ever update -- otherwise ikiwiki shall do its own thing. + if (defined $IkiWiki::pagemtime{$page}) + { + debug ("pagemtime: " . $IkiWiki::pagemtime{$page}); + + my $mtime = 0; + eval + { + $mtime = IkiWiki::rcs_getmtime ($file); + }; + if ($@) + { + print STDERR $@; + } + elsif ($mtime > 0) + { + $IkiWiki::pagemtime{$page} = $mtime; + + # We have to set the actual file's mtime too, as otherwise + # ikiwiki will update it again and again. + utime($mtime, $mtime, "$config{srcdir}/$file"); + } + + debug ("pagemtime: " . $IkiWiki::pagemtime{$page}); + } + } +} + +1 diff --git a/.library/IkiWiki/Plugin/ymlfront.pm b/.library/IkiWiki/Plugin/ymlfront.pm new file mode 100644 index 00000000..9c033833 --- /dev/null +++ b/.library/IkiWiki/Plugin/ymlfront.pm @@ -0,0 +1,434 @@ +#!/usr/bin/perl +# YAML format for structured data +# See plugins/contrib/ymlfront for documentation. +package IkiWiki::Plugin::ymlfront; +use warnings; +use strict; +=head1 NAME + +IkiWiki::Plugin::ymlfront - add YAML-format data to a page + +=head1 VERSION + +This describes version B<1.20100808> of IkiWiki::Plugin::ymlfront + +=cut + +our $VERSION = '1.20101116'; + +=head1 PREREQUISITES + + IkiWiki + IkiWiki::Plugin::field + YAML::Any + +=head1 AUTHOR + + Kathryn Andersen (RUBYKAT) + http://github.com/rubykat + +=head1 COPYRIGHT + +Copyright (c) 2009 Kathryn Andersen + +This program is free software; you can redistribute it and/or +modify it under the same terms as Perl itself. + +=cut +use IkiWiki 3.00; + +sub import { + hook(type => "getsetup", id => "ymlfront", call => \&getsetup); + hook(type => "checkconfig", id => "ymlfront", call => \&checkconfig); + hook(type => "filter", id => "ymlfront", call => \&filter, first=>1); + hook(type => "preprocess", id => "ymlfront", call => \&preprocess, scan=>1); + hook(type => "scan", id => "ymlfront", call => \&scan); + hook(type => "checkcontent", id => "ymlfront", call => \&checkcontent); + + IkiWiki::loadplugin('field'); + IkiWiki::Plugin::field::field_register(id=>'ymlfront', + call=>\&yml_get_value, + first=>1); +} + +# ------------------------------------------------------------ +# Package Vars +# -------------------------------- +my $ymlfront_regex = qr{ + (\\?) # 1: escape? + \[\[(!) # directive open; 2: prefix + (ymlfront) # 3: command + ( # 4: the parameters.. + \s+ # Must have space if parameters present + (?: + (?:[-\w]+=)? # named parameter key? + (?: + """.*?""" # triple-quoted value + | + "[^"]*?" # single-quoted value + | + [^"\s\]]+ # unquoted value + ) + \s* # whitespace or end + # of directive + ) + *)? # 0 or more parameters + \]\] # directive closed + }sx; + +# ------------------------------------------------------------ +# Hooks +# -------------------------------- +sub getsetup () { + return + plugin => { + safe => 1, + rebuild => 1, + }, + ymlfront_delim => { + type => "array", + example => "ymlfront_sep => [qw(--YAML-START-- --YAML-END--)]", + description => "delimiters of YAML data", + safe => 0, + rebuild => undef, + }, +} + +sub checkconfig () { + eval q{use YAML::Any}; + eval q{use YAML} if $@; + if ($@) + { + return error ("ymlfront: failed to use YAML::Any or YAML"); + } + + $YAML::UseBlock = 1; + $YAML::Syck::ImplicitUnicode = 1; + + if (!defined $config{ymlfront_delim}) + { + $config{ymlfront_delim} = [qw(--- ---)]; + } +} # checkconfig + +# scan gets called before filter +sub scan (@) { + my %params=@_; + my $page = $params{page}; + + my $page_file=$pagesources{$page} || return; + my $page_type=pagetype($page_file); + if (!defined $page_type) + { + return; + } + # clear the old data + if (exists $pagestate{$page}{ymlfront}) + { + delete $pagestate{$page}{ymlfront}; + } + my $parsed_yml = parse_yml(%params); + if (defined $parsed_yml + and defined $parsed_yml->{yml}) + { + # save the data to pagestate + foreach my $fn (keys %{$parsed_yml->{yml}}) + { + my $fval = $parsed_yml->{yml}->{$fn}; + $pagestate{$page}{ymlfront}{$fn} = $fval; + } + } + # update meta hash + if (exists $pagestate{$page}{ymlfront}{title} + and $pagestate{$page}{ymlfront}{title}) + { + $pagestate{$page}{meta}{title} = $pagestate{$page}{ymlfront}{title}; + } + if (exists $pagestate{$page}{ymlfront}{description} + and $pagestate{$page}{ymlfront}{description}) + { + $pagestate{$page}{meta}{description} = $pagestate{$page}{ymlfront}{description}; + } + if (exists $pagestate{$page}{ymlfront}{author} + and $pagestate{$page}{ymlfront}{author}) + { + $pagestate{$page}{meta}{author} = $pagestate{$page}{ymlfront}{author}; + } +} # scan + +# use this for data in a [[!ymlfront ...]] directive +sub preprocess (@) { + my %params=@_; + my $page = $params{page}; + + if (! exists $params{data} + or ! defined $params{data} + or !$params{data}) + { + error gettext("missing data parameter") + } + # All the work of this is done in scan mode; + # when in preprocessing mode, just return an empty string. + my $scan=! defined wantarray; + + if (!$scan) + { + return ''; + } + + # clear the old data + if (exists $pagestate{$page}{ymlfront}) + { + delete $pagestate{$page}{ymlfront}; + } + my $parsed_yml = parse_yml(%params); + if (defined $parsed_yml + and defined $parsed_yml->{yml}) + { + # save the data to pagestate + foreach my $fn (keys %{$parsed_yml->{yml}}) + { + my $fval = $parsed_yml->{yml}->{$fn}; + $pagestate{$page}{ymlfront}{$fn} = $fval; + } + } + # update meta hash + if (exists $pagestate{$page}{ymlfront}{title} + and $pagestate{$page}{ymlfront}{title}) + { + $pagestate{$page}{meta}{title} = $pagestate{$page}{ymlfront}{title}; + } + if (exists $pagestate{$page}{ymlfront}{description} + and $pagestate{$page}{ymlfront}{description}) + { + $pagestate{$page}{meta}{description} = $pagestate{$page}{ymlfront}{description}; + } + if (exists $pagestate{$page}{ymlfront}{author} + and $pagestate{$page}{ymlfront}{author}) + { + $pagestate{$page}{meta}{author} = $pagestate{$page}{ymlfront}{author}; + } + return ''; +} # preprocess + +sub filter (@) { + my %params=@_; + my $page = $params{page}; + + my $page_file=$pagesources{$page} || return $params{content}; + my $page_type=pagetype($page_file); + if (!defined $page_type) + { + return $params{content}; + } + my $parsed_yml = parse_yml(%params); + if (defined $parsed_yml + and defined $parsed_yml->{yml} + and defined $parsed_yml->{content}) + { + $params{content} = $parsed_yml->{content}; + # also check for a content value + if (exists $pagestate{$page}{ymlfront}{content} + and defined $pagestate{$page}{ymlfront}{content} + and $pagestate{$page}{ymlfront}{content}) + { + $params{content} .= $pagestate{$page}{ymlfront}{content}; + } + } + + return $params{content}; +} # filter + +# check the correctness of the YAML code before saving a page +sub checkcontent { + my %params=@_; + my $page = $params{page}; + + my $page_file=$pagesources{$page}; + if ($page_file) + { + my $page_type=pagetype($page_file); + if (!defined $page_type) + { + return undef; + } + } + my $parsed_yml = parse_yml(%params); + if (!defined $parsed_yml) + { + debug("ymlfront: Save of $page failed: $@"); + return gettext("YAML data incorrect: $@"); + } + return undef; +} # checkcontent + +# ------------------------------------------------------------ +# Field functions +# -------------------------------- +sub yml_get_value ($$) { + my $field_name = shift; + my $page = shift; + + my $value = undef; + if (exists $pagestate{$page}{ymlfront}{$field_name}) + { + $value = $pagestate{$page}{ymlfront}{$field_name}; + } + elsif (exists $pagestate{$page}{ymlfront}{lc($field_name)}) + { + $value = $pagestate{$page}{ymlfront}{lc($field_name)}; + } + if (defined $value) + { + if (ref $value) + { + my @value_array = @{$value}; + return (wantarray + ? @value_array + : join(",", @value_array)); + } + else + { + return (wantarray ? ($value) : $value); + } + } + return undef; +} # yml_get_value + +# ------------------------------------------------------------ +# Helper functions +# -------------------------------- + +# parse the YAML data from the given content +# Expects page, content +# Returns { yml=>%yml_data, content=>$content } or undef +sub parse_yml { + my %params=@_; + my $page = $params{page}; + my $content = $params{content}; + + my $page_file=$pagesources{$page}; + if ($page_file) + { + my $page_type=pagetype($page_file); + if (!defined $page_type) + { + return undef; + } + } + my $start_of_content = ''; + my $yml_str = ''; + my $rest_of_content = ''; + if ($params{data}) + { + $yml_str = $params{data}; + } + elsif ($content) + { + my $ystart = $config{ymlfront_delim}[0]; + my $yend = $config{ymlfront_delim}[1]; + if ($ystart eq '---' + and $yend eq '---' + and $content =~ /^---[\n\r](.*?[\n\r])---[\n\r](.*)$/s) + { + $yml_str = $1; + $rest_of_content = $2; + } + elsif ($content =~ /^(.*?)${ystart}[\n\r](.*?[\n\r])${yend}([\n\r].*)$/s) + { + $yml_str = $2; + $rest_of_content = $1 . $3; + } + elsif ($content =~ $ymlfront_regex) + { + my $escape=$1; + my $prefix=$2; + my $command=$3; + my $params=$4; + if ($escape) + { + $rest_of_content = $content; + } + else + { + my %phash = (); + while ($params =~ m{ + (?:([-\w]+)=)? # 1: named parameter key? + (?: + """(.*?)""" # 2: triple-quoted value + | + "([^"]*?)" # 3: single-quoted value + | + (\S+) # 4: unquoted value + ) + (?:\s+|$) # delimiter to next param + }sgx) { + my $key=$1; + my $val; + if (defined $2) { + $val=$2; + $val=~s/\r\n/\n/mg; + $val=~s/^\n+//g; + $val=~s/\n+$//g; + } + elsif (defined $3) { + $val=$3; + } + elsif (defined $4) { + $val=$4; + } + + if (defined $key) { + $phash{$key} = $val; + } + else { + $phash{''} = $val; + } + } + if (defined $phash{data}) + { + $yml_str = $phash{data}; + $content =~ /^(.*?)\[\[!ymlfront.*?\]\](.*?)$/s; + $start_of_content = $1; + $rest_of_content = $2; + # TODO: This breaks if the YAML string itself contains ]]. + # Workaround: all [[!ymlfront [...]]] directives shall be + # at the end of the files. + $rest_of_content = ''; + } + } + } + } + if ($yml_str) + { + # if {{$page}} is there, do an immediate substitution + $yml_str =~ s/\{\{\$page\}\}/$page/sg; + + my $ydata; + eval q{$ydata = Load($yml_str);}; + if ($@) + { + debug("ymlfront: Load of $page failed: $@"); + return undef; + } + if (!$ydata) + { + debug("ymlfront: no YAML for $page"); + return undef; + } + my %lc_data = (); + if ($ydata) + { + # make lower-cased versions of the data + foreach my $fn (keys %{$ydata}) + { + my $fval = $ydata->{$fn}; + $lc_data{lc($fn)} = $fval; + } + } + return { yml=>\%lc_data, + content=>$start_of_content . $rest_of_content}; + } + return { yml=>undef, content=>$content }; +} # parse_yml +1; diff --git a/.templates/autotag.tmpl b/.templates/autotag.tmpl new file mode 100644 index 00000000..5ff710d2 --- /dev/null +++ b/.templates/autotag.tmpl @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="<TMPL_VAR TAG>"]] + +[[!map +pages="tagged(<TMPL_VAR TAG>)" +show=title]] diff --git a/.templates/editpage.tmpl b/.templates/editpage.tmpl index 45060ffe..1ecbd0a9 100644 --- a/.templates/editpage.tmpl +++ b/.templates/editpage.tmpl @@ -1,6 +1,6 @@ -<br /> <TMPL_VAR JAVASCRIPT> <TMPL_VAR MESSAGE> +<br /> <TMPL_VAR FORM-START> <TMPL_VAR FIELD-DO> <TMPL_VAR FIELD-SID> @@ -8,17 +8,18 @@ <TMPL_VAR FIELD-RCSINFO> <TMPL_VAR FIELD-NEWFILE> <TMPL_IF NAME="PAGE_SELECT"> -Page location: <TMPL_VAR FIELD-PAGE> -Page type: <TMPL_VAR FIELD-TYPE> +<label for="page" class="inline">Page location:</label><TMPL_VAR FIELD-PAGE> +<label for="type" class="inline">Page type:</label><TMPL_VAR FIELD-TYPE> <TMPL_ELSE> -<br /> <TMPL_VAR FIELD-PAGE> <TMPL_VAR FIELD-TYPE> </TMPL_IF> +<div class="editcontentdiv"> <TMPL_VAR FIELD-EDITCONTENT><br /> +</div> <TMPL_IF NAME="CAN_COMMIT"> -Optional comment about this change:<br /> -<TMPL_VAR FIELD-COMMENTS><br /> +<label for="editmessage" class="block">Optional comment about this change:</label> +<TMPL_VAR FIELD-EDITMESSAGE><br /> </TMPL_IF> <div class="copyright_assignment_notice"> @@ -66,3 +67,12 @@ if there are questions.</p> <TMPL_VAR PAGE_PREVIEW> </div> </TMPL_IF> +<TMPL_IF NAME="PAGE_DIFF"> +<hr /> +<div class="header"> +<span>Diff:</span> +</div> +<div id="diff"> +<TMPL_VAR PAGE_DIFF> +</div> +</TMPL_IF> diff --git a/.templates/newsitem.tmpl b/.templates/newsitem.tmpl index 1c8f2ae8..e8a9c861 100644 --- a/.templates/newsitem.tmpl +++ b/.templates/newsitem.tmpl @@ -1,60 +1,64 @@ -<div class="newsitem"> +<TMPL_IF HTML5><article class="newsitem"><TMPL_ELSE><div class="newsitem"></TMPL_IF> -<div class="newsitemheader"> - -<TMPL_IF NAME="AUTHOR"> +<TMPL_IF HTML5><section class="newsitemheader"><TMPL_ELSE><div class="newsitemheader"></TMPL_IF> +<TMPL_IF AUTHOR> <span class="author"> -<TMPL_IF NAME="AUTHORURL"> +<TMPL_IF AUTHORURL> <a href="<TMPL_VAR AUTHORURL>"><TMPL_VAR AUTHOR></a> <TMPL_ELSE> <TMPL_VAR AUTHOR> </TMPL_IF> </span> </TMPL_IF> -<span class="header"> -<TMPL_IF NAME="PERMALINK"> +<TMPL_IF HTML5><header class="header"><TMPL_ELSE><span class="header"></TMPL_IF> +<TMPL_IF PERMALINK> <a href="<TMPL_VAR PERMALINK>"><TMPL_VAR TITLE></a> <TMPL_ELSE> <a href="<TMPL_VAR PAGEURL>"><TMPL_VAR TITLE></a> </TMPL_IF> -</span> -<TMPL_IF NAME="HAVE_ACTIONS"> -<div class="actions"> +<TMPL_IF HTML5></header><TMPL_ELSE></span></TMPL_IF> + +<TMPL_IF HAVE_ACTIONS> +<TMPL_IF HTML5><nav class="actions"><TMPL_ELSE><div class="actions"></TMPL_IF> <ul> -<TMPL_IF NAME="EDITURL"> +<TMPL_IF EDITURL> <li><a href="<TMPL_VAR EDITURL>" rel="nofollow">Edit</a></li> </TMPL_IF> -<TMPL_IF NAME="DISCUSSIONLINK"> +<TMPL_IF COMMENTSLINK> +<li><TMPL_VAR COMMENTSLINK></li> +<TMPL_ELSE> +<TMPL_IF DISCUSSIONLINK> <li><TMPL_VAR DISCUSSIONLINK></li> </TMPL_IF> +</TMPL_IF> </ul> -</div><!--.actions--> +<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF> </TMPL_IF> -</div><!--.newsitemheader--> +<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF> -<div class="newsitemcontent"> +<TMPL_IF HTML5><section class="newsitemcontent"><TMPL_ELSE><div class="newsitemcontent"></TMPL_IF> <TMPL_VAR CONTENT> -</div><!--.newsitemcontent--> +<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF> -<div class="newsitemfooter"> +<TMPL_IF HTML5><footer class="newsitemfooter"><TMPL_ELSE><div class="newsitemfooter"></TMPL_IF> <!-- The saved space is more important that the information this provides. - <span class="pagedate"> Posted <TMPL_VAR CTIME> </span> - --> -<TMPL_IF NAME="TAGS"> -<span class="tags"> +<!-- The saved space is more important that the information this provides. +<TMPL_IF TAGS> +<TMPL_IF HTML5><nav class="tags"><TMPL_ELSE><span class="tags"></TMPL_IF> Tags: -<TMPL_LOOP NAME="TAGS"> +<TMPL_LOOP TAGS> <TMPL_VAR LINK> </TMPL_LOOP> -</span> +<TMPL_IF HTML5></nav><TMPL_ELSE></span></TMPL_IF> </TMPL_IF> +--> <!-- For these tiny snippets we can abstain from displaying this again. It should match the inlining page's information nevertheless. @@ -73,6 +77,6 @@ License: <TMPL_VAR LICENSE> --> -</div><!--.newsitemfooter--> +<TMPL_IF HTML5></footer><TMPL_ELSE></div></TMPL_IF> -</div><!--.newsitem--> +<TMPL_IF HTML5></article><TMPL_ELSE></div></TMPL_IF> diff --git a/.templates/page.tmpl b/.templates/page.tmpl index d546a88f..5192138a 100644 --- a/.templates/page.tmpl +++ b/.templates/page.tmpl @@ -1,85 +1,131 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" +<TMPL_IF HTML5><!DOCTYPE html> +<html> +<TMPL_ELSE><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> +</TMPL_IF> <head> -<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> +<TMPL_IF DYNAMIC> +<TMPL_IF FORCEBASEURL><base href="<TMPL_VAR FORCEBASEURL>" /><TMPL_ELSE> +<TMPL_IF BASEURL><base href="<TMPL_VAR BASEURL>" /></TMPL_IF> +</TMPL_IF> +</TMPL_IF> +<TMPL_IF HTML5><meta charset="utf-8" /><TMPL_ELSE><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></TMPL_IF> <title><TMPL_VAR TITLE></title> -<TMPL_IF NAME="FAVICON"> +<TMPL_IF FAVICON> <link rel="icon" href="<TMPL_VAR BASEURL><TMPL_VAR FAVICON>" type="image/x-icon" /> </TMPL_IF> <link rel="stylesheet" href="<TMPL_VAR BASEURL>style.css" type="text/css" /> +<TMPL_IF LOCAL_CSS> +<link rel="stylesheet" href="<TMPL_VAR BASEURL><TMPL_VAR LOCAL_CSS>" type="text/css" /> +<TMPL_ELSE> <link rel="stylesheet" href="<TMPL_VAR BASEURL>local.css" type="text/css" /> -<TMPL_IF NAME="EDITURL"> +</TMPL_IF> +<TMPL_IF EDITURL> <link rel="alternate" type="application/x-wiki" title="Edit this page" href="<TMPL_VAR EDITURL>" /> </TMPL_IF> -<TMPL_IF NAME="FEEDLINKS"><TMPL_VAR FEEDLINKS></TMPL_IF> -<TMPL_IF NAME="RELVCS"><TMPL_VAR RELVCS></TMPL_IF> -<TMPL_IF NAME="META"><TMPL_VAR META></TMPL_IF> +<TMPL_IF FEEDLINKS><TMPL_VAR FEEDLINKS></TMPL_IF> +<TMPL_IF RELVCS><TMPL_VAR RELVCS></TMPL_IF> +<TMPL_IF META><TMPL_VAR META></TMPL_IF> </head> <body> -<div class="pageheader"> -<div class="header"> +<TMPL_IF HTML5><article class="page"><TMPL_ELSE><div class="page"></TMPL_IF> + +<TMPL_IF HTML5><section class="pageheader"><TMPL_ELSE><div class="pageheader"></TMPL_IF> +<TMPL_IF HTML5><header class="header"><TMPL_ELSE><div class="header"></TMPL_IF> <span> <span class="parentlinks"> -<TMPL_LOOP NAME="PARENTLINKS"> +<TMPL_LOOP PARENTLINKS> <a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>/ </TMPL_LOOP> </span> <span class="title"> <TMPL_VAR TITLE> +<TMPL_IF ISTRANSLATION> + (<TMPL_VAR PERCENTTRANSLATED>%) +</TMPL_IF> +</span> </span> -</span><!--.header--> -<TMPL_IF NAME="SEARCHFORM"> +<TMPL_IF SEARCHFORM> <TMPL_VAR SEARCHFORM> </TMPL_IF> -</div> +<TMPL_IF HTML5></header><TMPL_ELSE></div></TMPL_IF> -<TMPL_IF NAME="HAVE_ACTIONS"> -<div class="actions"> +<TMPL_IF HAVE_ACTIONS> +<TMPL_IF HTML5><nav class="actions"><TMPL_ELSE><div class="actions"></TMPL_IF> <span class="global"> <ul> -<TMPL_IF NAME="RECENTCHANGESURL"> +<TMPL_IF RECENTCHANGESURL> <li><a href="<TMPL_VAR RECENTCHANGESURL>">Recent Changes</a></li> </TMPL_IF> -<TMPL_IF NAME="PREFSURL"> +<TMPL_IF PREFSURL> <li><a href="<TMPL_VAR PREFSURL>">Preferences</a></li> </TMPL_IF> </ul> </span> <span class="per_page"> <ul> -<TMPL_IF NAME="EDITURL"> +<TMPL_IF EDITURL> <li><a href="<TMPL_VAR EDITURL>" rel="nofollow">Edit</a></li> </TMPL_IF> -<TMPL_IF NAME="HISTORYURL"> +<TMPL_IF HISTORYURL> <li><a href="<TMPL_VAR HISTORYURL>">History</a></li> </TMPL_IF> -<TMPL_IF NAME="COMMENTSLINK"> -<li><TMPL_VAR COMMENTSLINK><br /></li> +<TMPL_IF GETSOURCEURL> +<li><a href="<TMPL_VAR GETSOURCEURL>">Source</a></li> +</TMPL_IF> +<TMPL_IF ACTIONS> +<TMPL_LOOP ACTIONS> +<li><TMPL_VAR ACTION></li> +</TMPL_LOOP> +</TMPL_IF> +<TMPL_IF COMMENTSLINK> +<li><TMPL_VAR COMMENTSLINK></li> <TMPL_ELSE> -<TMPL_IF NAME="DISCUSSIONLINK"> -<li><TMPL_VAR DISCUSSIONLINK><br /></li> +<TMPL_IF DISCUSSIONLINK> +<li><TMPL_VAR DISCUSSIONLINK></li> </TMPL_IF> </TMPL_IF> </ul> </span> -</div> +<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF> </TMPL_IF> -</div> <!-- .pageheader --> + +<TMPL_IF OTHERLANGUAGES> +<TMPL_IF HTML5><nav id="otherlanguages"><TMPL_ELSE><div id="otherlanguages"></TMPL_IF> +<ul> +<TMPL_LOOP OTHERLANGUAGES> +<li> +<a href="<TMPL_VAR URL>"><TMPL_VAR LANGUAGE></a> +<TMPL_IF MASTER> +(master) +<TMPL_ELSE> + (<TMPL_VAR PERCENT>%) +</TMPL_IF> +</li> +</TMPL_LOOP> +</ul> +<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF> +</TMPL_IF> + +<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF> <TMPL_IF SIDEBAR> -<div id="sidebar"> +<TMPL_IF HTML5><aside class="sidebar"><TMPL_ELSE><div class="sidebar"></TMPL_IF> <TMPL_VAR SIDEBAR> -</div> +<TMPL_IF HTML5></aside><TMPL_ELSE></div></TMPL_IF> </TMPL_IF> -<div id="content"> +<div id="pagebody"> + +<TMPL_IF HTML5><section id="content"><TMPL_ELSE><div id="content"></TMPL_IF> <TMPL_VAR CONTENT> -</div> +<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF> +<TMPL_UNLESS DYNAMIC> <TMPL_IF COMMENTS> -<div id="comments"> +<TMPL_IF HTML5><section id="comments"><TMPL_ELSE><div id="comments"></TMPL_IF> <TMPL_VAR COMMENTS> <TMPL_IF ADDCOMMENTURL> <div class="addcomment"> @@ -88,37 +134,41 @@ <TMPL_ELSE> <div class="addcomment">Comments on this page are closed.</div> </TMPL_IF> -</div> +<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF> </TMPL_IF> +</TMPL_UNLESS> -<div id="footer" class="pagefooter"> -<div id="pageinfo"> +</div> -<TMPL_IF NAME="TAGS"> -<div class="tags"> +<TMPL_IF HTML5><footer id="footer" class="pagefooter"><TMPL_ELSE><div id="footer" class="pagefooter"></TMPL_IF> +<TMPL_UNLESS DYNAMIC> +<TMPL_IF HTML5><nav id="pageinfo"><TMPL_ELSE><div id="pageinfo"></TMPL_IF> + +<TMPL_IF TAGS> +<TMPL_IF HTML5><nav class="tags"><TMPL_ELSE><div class="tags"></TMPL_IF> Tags: -<TMPL_LOOP NAME="TAGS"> +<TMPL_LOOP TAGS> <TMPL_VAR LINK> </TMPL_LOOP> -</div> +<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF> </TMPL_IF> -<TMPL_IF NAME="BACKLINKS"> -<div id="backlinks"> +<TMPL_IF BACKLINKS> +<TMPL_IF HTML5><nav id="backlinks"><TMPL_ELSE><div id="backlinks"></TMPL_IF> Links: -<TMPL_LOOP NAME="BACKLINKS"> +<TMPL_LOOP BACKLINKS> <a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a> </TMPL_LOOP> -<TMPL_IF NAME="MORE_BACKLINKS"> +<TMPL_IF MORE_BACKLINKS> <span class="popup">... <span class="balloon"> -<TMPL_LOOP NAME="MORE_BACKLINKS"> +<TMPL_LOOP MORE_BACKLINKS> <a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a> </TMPL_LOOP> </span> </span> </TMPL_IF> -</div><!-- #backlinks --> +<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF> </TMPL_IF> <TMPL_IF COPYRIGHT> @@ -140,10 +190,13 @@ Last edited <TMPL_VAR MTIME> <!-- Created <TMPL_VAR CTIME> --> </div> -</div><!-- #pageinfo --> +<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF> <TMPL_IF EXTRAFOOTER><TMPL_VAR EXTRAFOOTER></TMPL_IF> +</TMPL_UNLESS> <!-- from <TMPL_VAR WIKINAME> --> -</div><!-- .pagefooter #footer --> +<TMPL_IF HTML5></footer><TMPL_ELSE></div></TMPL_IF> + +<TMPL_IF HTML5></article><TMPL_ELSE></div></TMPL_IF> </body> </html> diff --git a/advantages.mdwn b/advantages.mdwn new file mode 100644 index 00000000..a7d5b399 --- /dev/null +++ b/advantages.mdwn @@ -0,0 +1,77 @@ +[[!meta copyright="Copyright © 2001, 2002, 2008, 2010, 2011, 2012 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag stable_URL]] + +The GNU Hurd has a number of enticing features: + +It's free software, so anybody can use, modify, and redistribute it under the +terms of the [[GNU General Public License (GPL)|GPL]]. + +It's compatible as it provides a familiar programming and user environment. +For all intents and purposes, the Hurd provides the same facilities as a modern +[[Unix]]-like kernel. The Hurd uses the [[GNU C Library|glibc]], whose +development closely tracks [[standards such as ANSI/ISO, BSD, POSIX, Single +Unix, SVID, and X/Open|faq/posix_compatibility]]. + +Unlike other popular kernel software, the Hurd has an object-oriented structure +that allows it to evolve without compromising its design. This structure will +help the Hurd undergo major redesign and modifications without having to be +entirely rewritten. + +The Hurd is built in a very modular fashion. Other Unix-like kernels (Linux, +for example) are also modular in that they allow loading (and unloading) some +components as kernel modules, but the Hurd goes one step further in that most +of the components that constitute the whole kernel are running as separate +user-space processes and are thus using different address spaces that are +isolated from each other. This is a multi-server design based on a +[[microkernel]]. It is not possible that a faulty memory dereference inside +the [[TCP/IP stack|hurd/translator/pfinet]] can bring down the whole kernel, +and thus the whole system, which is a real problem in a monolothic Unix kernel +architecture. + +One advantage of the Hurd's separation of kernel-like functionality into +separate components ([[servers|hurd/translator]]) is that these can be +constructed using different programming languages -- a feature that is not +easily possible in a monolithic kernel. Essentially, only an interface from +the programming environment to the [[RPC]] mechanism is required. (We have a +[[project proposal|community/gsoc/project_ideas/language_bindings]] for this, +if you're interested.) + +<!-- This is a bit questionable... + +It's scalable. The Hurd implementation is aggressively multithreaded so that +it runs efficiently on both single processors and symmetric multiprocessors. +The Hurd interfaces are designed to allow transparent network clusters +(*collectives*), although this feature has not yet been implemented. + +See also [[unsorted/hurd-migr]] ([[!taglink open_issue_documentation]]). + +--> + +The Hurd is an attractive platform for learning how to become a kernel hacker +or for implementing new ideas in kernel technology. Every part of the system +is designed to be [[easily modified and extended|extensibility]]. + +It is possible to develop and test new Hurd kernel components without rebooting +the machine. Running your own kernel components doesn't interfere with other +users, and so no special system privileges are required. The mechanism for +kernel extensions is secure by design: it is impossible to impose your changes +upon other users unless they authorize them or you are the system +administrator. + +The Hurd is real software that works right now. It is not a research project +or a proposal. You don't have to wait at all before you can [[start +using|hurd/running]] and [[developing|contributing]] it. + +<!-- add stuff from hurd-talk.html --> + +*Technical advantages from a users viewpoint can be seen in the weblog entry [[Some technical advantages of the Hurd|community/weblogs/ArneBab/technical-advantages-of-the-hurd]].* diff --git a/binutils.mdwn b/binutils.mdwn index 3ce28bb1..d3e2b735 100644 --- a/binutils.mdwn +++ b/binutils.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,4 +9,15 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -The [GNU Binutils](http://www.gnu.org/software/binutils/). +[[!meta title="GNU Binutils"]] + + +# <http://www.gnu.org/software/binutils/> + + +# [[Maintenance|open_issues/binutils]] + + +# Open Issues + +[[!inline pages=tag/open_issue_binutils raw=yes feeds=no]] diff --git a/boehm_gc.mdwn b/boehm_gc.mdwn new file mode 100644 index 00000000..5745aaaf --- /dev/null +++ b/boehm_gc.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Boehm GC"]] + + +# <http://www.hpl.hp.com/personal/Hans_Boehm/gc/> + + +# [[Maintenance|open_issues/boehm_gc]] diff --git a/capability.mdwn b/capability.mdwn index 367ea163..7219cdce 100644 --- a/capability.mdwn +++ b/capability.mdwn @@ -1,16 +1,17 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] A capability is a protected reference. It is a reference in that it designates an object; it is protected in that in cannot be -forged. A capabilities both designates the object it refers to and +forged. A capability both designates the object it refers to and carries the authority to manipulate it. By binding [[designation]] and [[authorization]] together, capabilities @@ -24,10 +25,113 @@ to protect against A hijacking his authority. (This problem is refused to the [[confused_deputy]] problem.) Also, since A likely sent a string to identify the file to B, the identifier lacks a [[naming_context]] and therefore may resolve to a different object -than A intended. Be ensuring that [[designation]] and [[authorization]] are +than A intended. By ensuring that [[designation]] and [[authorization]] are always bound together, these problems are avoided. -[[Unix]] file descriptors can be viewed as capabilities. Unix file -descriptors do not survive reboot, that is, they are not -[[persistent|persistency]]. To work around this, [[ACL]]s are used to -recover authority. +Capability-based system architectures strive to meet the *principle of least +privilege* ({{$wikipedia_polp}}). + +[[!tag open_issue_documentation]] <!-- +Revoking capabilities: destroy Mach port, invalidates *all* send rights. See +shapiro_capintro_1999. To be more fine-grained, need separate instances, for +example, valet key vs. door key. Proxy objects (that can be destroyed +individually); attenuation design pattern, membranes +(wikipedia_object-capability_model)? +--> + +A capability mechanism is typically implemented in software by the operating +system kernel (typically a [[microkernel]]). The computing cost (as compared to +a hardware implementation) is neglectable. + + +[[!tag open_issue_documentation]] <!-- +References. shapiro_capintro_1999 has a bit. +--> + + +[[!tag open_issue_documentation]] <!-- +# Advantages + + * increased security; POLP + + * easy exchanging of functionality + + * support modular design and encapsulation + + * easy collaboration (in theory; need real example) + +--> + + +# UNIX + +[[UNIX file descriptors|unix/file_descriptor]] can be viewed as capabilities. +They do not survive reboot, that is, they are not [[persistent|persistency]]. +To work around this, [[ACL]]s are used to recover authority. + + +# GNU/Hurd + +In the GNU/Hurd system, a capability is represented by a [[Mach +port|microkernel/mach/port]]. As in UNIX (see above), they are not +[[persistent|persistency]]. + + +# Further Reading + + * [[Mach port|microkernel/mach/port]] + +[[!toggleable id=shapiro_capintro_1999 text="""[[!template id=note +text="*[[shapiro\_capintro\_1999|capability]]*: +{{$capability#shapiro_capintro_1999}}. +{{$capability#shapiro_capintro_1999_text}}."]]"""]] + + * [[!toggle id=shapiro_capintro_1999 text="[shapiro\_capintro\_1999]"]] + + * {{$wikipedia_capability-based_security}} + + * {{$wikipedia_object-capability_model}} + + * {{$wikipedia_polp}} + + +[[!tag open_issue_documentation]] <!-- +<http://www.eros-os.org/essays/wherefrom.html>, +<http://www.eros-os.org/essays/ACLSvCaps.html>, +<http://www.cap-lore.com/CapTheory/index.html>, +<http://www.cap-lore.com/CapTheory/tddCap.html> +<http://www.skyhunter.com/marcs/capabilityIntro/> +--> + + +[[!ymlfront data=""" + +shapiro_capintro_1999: + + "[What *is* a Capability, + Anyway?](http://www.eros-os.org/essays/capintro.html), Jonathan Shapiro, + 1999" + +shapiro_capintro_1999_text: + + "This is an easily readable introduction with good examples. In the author's + own words, the text *provides a layman's introduction to capabilities, + describing what they are, what they do, and why they result in better + security than today's computer systems*" + +wikipedia_capability-based_security: + + "[[!wikipedia Capability-based_security desc=\"Wikipedia, capability-based + security\"]]" + +wikipedia_object-capability_model: + + "[[!wikipedia Object-capability_model desc=\"Wikipedia, object-capability + model\"]]" + +wikipedia_polp: + + "[[!wikipedia Principle_of_least_privilege desc=\"Wikipedia, principle of + least privilege\"]]" + +"""]] diff --git a/challenges.mdwn b/challenges.mdwn new file mode 100644 index 00000000..a3a8a7e6 --- /dev/null +++ b/challenges.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The GNU Hurd has a lot of [[advantages]], but there are challenges, too. + +Some of these are explained in the [[hurd/critique]]. + +Even though they're quite popular in the simpler embedded space, there is no +successful true multi-server [[microkernel]] system for general-purpose desktop +use yet. This is still an ongoing research effort. (TODO: add references.) + +Likewise, resource scheduling in distributed operating system kernels is a +research topic. For example, read more about it on the relevant [[Open Issues +page|open_issues/multiprocessing]]. Also, the [[microkernel/Viengoos]] +research kernel project strives to explore these. + +TODO: more to come. [[!tag open_issue_documentation]] diff --git a/community.mdwn b/community.mdwn index 17377890..25f66244 100644 --- a/community.mdwn +++ b/community.mdwn @@ -1,16 +1,16 @@ -[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010, 2012 +Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -There is an expanding community of people developing and running test Debian -GNU/Hurd machines. +There is an expanding community of people developing and running GNU/Hurd +systems. [[Communication]] -- How communication and coordination works within the group. @@ -18,6 +18,8 @@ Further ways of getting in contact or getting information: [[Shared-Wiki-Weblog|Weblogs]] -- A shared weblog by Hurd developers and enthusiasts. +[[User Pages|/user]] + [[Meetings]] -- Meetings with Hurd developer attendance. [[GSoC]] -- Participation in the Google Summer of Code @@ -28,12 +30,18 @@ Further ways of getting in contact or getting information: [[LiveJournal]] +[identi.ca](http://identi.ca/group/hurd) + [[Orkut]] [[FaceBook]] [Advogato.org -- Hurd Project page](http://advogato.org/proj/HURD/) +[Google+](https://plus.google.com/114942488385711891227) + +[[Media_Appearances]] + --- # Hurd User Groups @@ -46,4 +54,8 @@ Further ways of getting in contact or getting information: * [Hurdfr.org](http://www.hurdfr.org/) * [HurdIt](http://hurd-it.sf.net/) * [HurdUk](http://uwhug.org.uk/) -* [HurdUs](http://hurd.gnufans.org/) + +# Other Community Pages + + * [GNU Hurd Sverige](http://hurd.mtb-tech.se/) -- A Swedish website + about the GNU Hurd diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index ce3b26fb..efd29841 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -1,53 +1,110 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Google Summer of Code"]] -# 2009 +We're in! The GNU Hurd project is again participating in the [Google Summer of +Code](http://www.google-melange.com/) under the [GNU +umbrella](http://www.gnu.org/software/soc-projects/). -The GNU Hurd project this year unfortunately is not in the list of accepted -mentoring organizations. +<!-- -However, don't despair! This doesn't mean that you'd not be allowed to work on -your favorite GNU Hurd project. For one, there's the possibility that a slot -for your project can be allocated under the [auspices of the GNU -project](http://www.gnu.org/software/soc-projects/). Second, we're of course -always open to introducing newcomers to the world of the GNU Hurd outside of -any Google Summer of whatever project. Just pick a task from the list pointed -to below on this page and get in touch with us! +This year's *student application period* is over. Thanks for sending in your +applications! We're now reviewing and discussing these, so please pay +attention to any questions posted on your proposal's page. The Google site's +notification system should be sending out emails, too. -<!-- The GSoC 2009 student application time has come to an end -- we -are now evaluating your applications. --> +As we only have finite resources (meaning that we won't be able to accept all +GNU Hurd applications even if we wanted to), we will eventually need to make a +choice about whom to select. For this, it is a very good idea to be in contact +with us, be it by answering the evaluators' questions on your proposal's page, +or by talking to us on the [[mailing_lists]] or on [[IRC]]. At this time, it +is important for us to get a good impression about the seriousness you're +showing with your application. -The applications have been evaluated and the following student has -been accepted: +It is a good idea to get familiar with the GNU Hurd, by reading some of our +[[documentation]], and by using a GNU/Hurd system. It is also a good idea to +send in some basic patches (this has already been mentioned in our +[[student_application_form]]), or discuss with us the principal steps you're +planning on doing in your intended work area. Of course, we don't expect you +to already start working seriously on your project, but any input you're giving +us will make it easier for us to justify selectiong your specific proposal. At +this time, it is not quantity that matters, and it also is not *the perfect +patch* we're waiting for, but it is rather that we see how you're generally +able to work with the code. - * [[Sergiu Ivanov|scolobb]] +If you have any questions, don't be shy: please ask! Nobody expects you to +know everything. Even for the long-term Hurd contributors it is common to +openly post messages to [[mailing_lists/bug-hurd]] saying: *Hey, I don't know +how to do `X`, can someone please help me?* And, as we're not working next to +each other in a conventional office or university setup, we'll need to +establish and get used to different communication channels. +[Timeline](http://www.google-melange.com/gsoc/events/google/gsoc2011). As +boring as it is, but the next step is waiting: we will have to wait for Google +to announce the number of slots that the whole GNU project gets, and we'll be +discussing with our GNU peers about how to split these up among all the GNU +subprojects. -# History +--> + + +Applications for 2012 are closed. + +# Accepted projects + +## Disk I/O Performance Tuning + +by Maksym Planeta + +See the project's +[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/mcsim/46002). -2006 and 2007 we participated in GSoC under the umbrella of the GNU project, -getting one slot each year. +## Virtualization Using Hurd Mechanisms -<!-- TODO. Extend. --> +by Pierre Thierry -In 2008 we successfully participated on our own, no longer within the GNU -project. Read about our five students' success on the [[2008]] page. +See the project's +[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/nowhereman/36001) +and [[complete proposal|gsoc/2012/virt/proposal]]. -# Joining in +# Possible projects -If these successes got you interested in contributing some larger part yourself - -in your free time or maybe in next years Google Summer of Code - -please have a look at our [[project_ideas]] and read up about [[contributing]]. +We have a list of [[project_ideas]], and students are likewise encouraged to +submit their own project proposals. Please follow our +[[student_application_form]]. + +Then, don't forget to visit <http://www.google-melange.com/>, and press the +button for submitting your proposal. + +Please read up about [[contributing]] in general, and please ask any questions +you might have, on the [[mailing_lists]], or on [[IRC]], for example at one of +our [[regular_IRC_meetings|IRC#regular_meetings]]. Generally it's a good idea +to [[get in contact with us|contact_us]] as soon as you're beginning to spend +time on a project. + + +## Outside of the GSoC Scope + +Working on one of these projects is generally a good opportunity to get started +with Hurd development, even outside of the GSoC context. Please don't hesitate +to contact us regarding mentoring even if it's not GSoC time at the moment, or +if you aren't a student anyway. + +# History -Also, feel free to ask your questions at one of our -[[regular_IRC_meetings|IRC#regular_meetings]]. +In 2006 and [[2007]], we participated in GSoC under the umbrella of the GNU +project, getting one slot each year. In the following year, we successfully +participated on our own, instead of as a suborganization of the GNU project. +Read about our five students' success on the [[2008]] page. The next two year, +we participated under the GNU umbrella with one slot in [[2009]], three in +[[2010]], and one again in [[2011]]. diff --git a/community/gsoc/2007.mdwn b/community/gsoc/2007.mdwn new file mode 100644 index 00000000..fa22f785 --- /dev/null +++ b/community/gsoc/2007.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Participated under the umbrella of the GNU project, getting one slot: + + * Carl Fredrik Hammar has been working on [[hurd/libchannel]]; [Google's + project + page](http://code.google.com/soc/2007/gnu/appinfo.html?csaid=44FB3FD69C665A08). diff --git a/community/gsoc/2008.mdwn b/community/gsoc/2008.mdwn index d7b467bb..d994f2b0 100644 --- a/community/gsoc/2008.mdwn +++ b/community/gsoc/2008.mdwn @@ -23,7 +23,8 @@ did a great job! vacation). The project however was hampered by various misunderstandings, wrong assumptions, and several major redesigns during the course of the work -- which is probably more our fault than the student's. In the end, though, he - completed nsmux (the main namespace proxy handling the magic filename + completed [[hurd/translator/nsmux]] (the main namespace proxy handling the + magic filename lookups, running dynamic translators on demand); he still works on finishing the translator stack filtering necessary to implement some of the desired functionality (accessing files while skipping existing translators). diff --git a/community/gsoc/2009.mdwn b/community/gsoc/2009.mdwn new file mode 100644 index 00000000..6efeb839 --- /dev/null +++ b/community/gsoc/2009.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!meta title="Google Summer of Code 2009"]] + +The GNU Hurd project unfortunately was not in the list of accepted +mentoring organizations. + +We did get one slot from the GNU project's. + +The applications have been evaluated and the following student has +been accepted: + + * [[Sergiu Ivanov|scolobb]] -- working on a *[[VFS-style union + mount|hurd/translator/unionmount]]* functionality; [Google's project + page](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/karlberry/t124022551214). diff --git a/community/gsoc/2010.mdwn b/community/gsoc/2010.mdwn new file mode 100644 index 00000000..d09e26b6 --- /dev/null +++ b/community/gsoc/2010.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Google Summer of Code 2010"]] + +In 2010 we have again been participating in the Google Summer of Code +under the GNU umbrella, with three slots: + + * *[[Jérémie Koenig|jkoenig]]*, mentored by *[[Samuel + Thibault|samuelthibault]]*, has been working on adapting the Debian Installer to + [produce working Debian GNU/Hurd installation + images](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/debian/t127230758239) + so we can easily offer up to date disc-sets. + ([Details](http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig).) + + * *[[Emilio Pozuelo Monfort|pochu]]*, mentored by *Carl Fredrik Hammar* (who + was a GSoC student in [[2007]]), has been working on a task that may be perceived as + less exciting from the outside, but yet is extremely valuable: [fixing + compatibility problems exposed by projects' + testsuites](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759396). + ([[Details|community/gsoc/project_ideas/testsuites]].) + + * *[[Karim Allah Ahmed|kam]]*, mentored by *Sergio López*, has been working on + [tuning the VM Subsystem in + GNU/Hurd](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759587) + to bring the virtual memory management in Hurd/Mach up to date. + ([[Details|community/gsoc/project_ideas/vm_tuning]].) diff --git a/community/gsoc/2011.mdwn b/community/gsoc/2011.mdwn new file mode 100644 index 00000000..ba10a031 --- /dev/null +++ b/community/gsoc/2011.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Google Summer of Code 2011"]] + +In 2011 we have again been participating in the Google Summer of Code +under the GNU umbrella, with one slot: + + * [[Jérémie Koenig|jkoenig]], mentored by [[Thomas Schwinge|tschwinge]] and + Richard Braun, has been working on the project [*Java on Hurd (and vice + versa)*](http://www.google-melange.com/gsoc/project/google/gsoc2011/jkoenig/27001). + ([[Details|user/jkoenig/java]].) diff --git a/community/gsoc/2012/virt/proposal.mdwn b/community/gsoc/2012/virt/proposal.mdwn new file mode 100644 index 00000000..d89f45d5 --- /dev/null +++ b/community/gsoc/2012/virt/proposal.mdwn @@ -0,0 +1,95 @@ +[[!meta title="Original proposal"]] + +*This is the proposal as it has been submitted to Google Summer of +Code.* + +# The name of the project + +Virtualization Using Hurd Mechanisms + +# Summary + +The goal is to create tools that let a user create a set of servers +that implement a Hurd environment and the necessary resources, with +the possibility of relying on existing servers in the parent Hurd for +some of them, instead of creating them. + +# Benefits + +This project will permit to create isolated systems but with far more +flexibility than traditional virtualization tools, because the degree +of isolation can be changed and possibly not only at creation time, +and communication and sharing of subsystems can be arranged between +isolated systems. + +# Deliverables + +D1 — User stories for the toolset, that will later serve as examples +for the documentation + +D2 — Exhaustive but concise documentation of the set of needed servers +making a working Hurd system (as much for me as for future users of +the tool, building and linking to existing Hurd documentation) + +D3 — Low-level tool to create a working Hurd environment (possibly +with strong limitations on the shape of the resources used by the +environment, most probably on the underlying filesystem) + +D4 — Fake or noop servers for the documented set of needed servers, to +be provided instead of working ones, where a feature is to be denied +to a Hurd environnement + +D5 — Proxy servers, where desirable, to provide access to servers +outside the environment (in ocaps terminology, caretakers) + +D6 — Extension of the low-level tool from D3 to remove its +unreasonable limitations + +D7 — High-level tools to easily create environments and run programs +in them (akin respectively to debootstrap and schroot) + +D8 — If possible, extensions to the D5 and D7 tools to enable dynamic +modifications of the features and authority granted to environments +and creation of multiple interconnected environments + +# Plan + +I intend to develop using the Scrum method, with sprints of two weeks, +which mean that each two weeks, I will present at least one new +working feature, working incrementally towards the full deliverable. I +will also push my code at least once a day to a public Git hosting, +including topic branches, so my progress can be followed easily. + +I intend to start from crosshurd and see how I can hook in its process +of creation to allow being provided alternatives. Depending on how +crosshurd is malleable to those changes, a modified crosshurd will +either be a learning-stage prototype or the base of the +implementation. + +To reuse Git terminology, once plumbing tools (i.e. tools that take +detailed invocation information for each server) are working fine, +I'll move on to porcelain tools, the final UI (i.e. tools that provide +sensible default options, aliases mechanisms, etc.). + +# Communication + +I'm usually easy to reach through both email and jabber, so those and +IRC will be my main way to inform my mentor and ask questions. I'll +setup an ikiwiki to have a summary of the exchanges and the temporary +documentation of the project (i.e. documentation that doesn't fit with +the code yet). + +# Qualification + +Thansk to or because of my participation to the Hurd mailing lists, +I've been utterly contaminated by the concept of POLA a few years +ago. Since then, I've been longing, almost in a painful way, for a +object-capability flavour of Debian. Having to deal in my previous day +jobs with virtualization tools like Xen and VMWare when I knew there +would be no need for paravirtualization or emulation to isolate +systems in an object-capability OS only made it worst. + +Now most of the code I produce naturally becomes capability oriented, +even if my underlying platform, programming language or OS, doesn't +provide true capabilities. And creating true POLA systems and making +it possible for others to benefit from POLA is now one of my dreams. diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn index 9fe3a420..8e672af1 100644 --- a/community/gsoc/organization_application.mdwn +++ b/community/gsoc/organization_application.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,166 +9,147 @@ 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]]."]]"""]] -* Link ID: - -hurd - -* Group Name: +* Organization Name: GNU Hurd -* Home Page URL: - -http://hurd.gnu.org - -* Public Email: - -bug-hurd@gnu.org - * Description: -The Hurd project is a loose community of people sharing a common interest in -developing the Hurd kernel, which is the official kernel of the [GNU operating -system](http://gnu.org). - -When the Hurd was originally started in 1990, it was the last missing major -component for a complete GNU system. Today Linux and other free kernels are -available to fill this gap, and the combination of GNU and Linux (often -[incorrectly](http://www.gnu.org/gnu/why-gnu-linux.html) called just "Linux") -is in wide use. However, the Hurd is still interesting due to its unique -design, better fitting the GNU philosophy than traditional monolithic kernels -like Linux. - -The GNU GPL guarantees that all users of software published under this license -get the legal permission to adapt the software they are using according to -their wishes, and also get the source code and other tools necessary to put -this permission to use. However, in traditional operating systems, the kernel -and related low-level system software are protected from normal users, and -cannot be easily modified; only the system administrator has power over these. - -The Hurd offers special mechanisms that allow any user to change almost all of -the system functionality he uses, without affecting the rest of the system, and -thus easily (at runtime) and without any special permissions. - -This ability to run subenvironments more or less independant from the rest of -the system, can be classified as a very sophisticated [lightweight -virtualization](http://tri-ceps.blogspot.com/2007/10/advanced-lightweight-virtualization.html) -approach. - -To offer these possibilities, the Hurd uses a true multiserver microkernel -architecture. That makes it quite unique: The Hurd is the only general-purpose -multiserver microkernel system in development today that is nearly ready for -everyday use, and offering almost perfect UNIX compatibility. (More than half -of the packages in the Debian repository are available for the Hurd.) All other -existing true microkernel systems are either research projects not nearly -complete enough for actual use, or limited to embedded systems and other -special purposes, or both. - -Marcus Brinkmann and Neal Walfield from the Hurd project are working at the -bleeding edge of microkernel operating system research. They have been in -contact with the most distinguished researchers in that field from the +The mission of the Hurd project is to create a general-purpose kernel suitable +for the [GNU operating system](http://gnu.org), which is viable for everyday +use, and gives users and programs as much control over their computing +environment as possible. + +In traditional operating systems, most system functionality is provided by the +kernel, and thus cannot be easily modified. The Hurd on the other hand -- +following the GNU spirit of giving users more control over the software they +use -- implements a unique design, which makes it feasible to change almost +everything, down to the core features of the system. + +While on other systems, such changes would require a lot of effort and special +privileges to rebuild the system core, with the Hurd this is not necessary: the +extensible architecture enables users (or applications) to simply modify their +local system environment at any time, while leaving the rest of the system in +place. + +The most obvious example is the completely decentralized VFS mechanism: it can +be extended in almost any imaginable way, simply by setting up suitable server +processes (translators). Not only does this empower users, but also it helps +application development: desktop environments such as GNOME for example, when +making use of these possibilities, wouldn't need to create their own VFS +mechanism -- they simply could extend the system VFS to suit their needs. + +One major element of the design which enables this extensibility, is the use of +a true multiserver microkernel architecture. The Hurd is quite unique in being +the only general-purpose multiserver microkernel system in development today, +that is nearly ready for everyday use, and offering almost perfect UNIX +compatibility. (About 65% of all packages in the Debian repository are +available for the Hurd.) The "general-purpose" and "everyday use" bits are +decisive here: all other existing true microkernel systems are either research +projects not nearly complete enough for actual use; or limited to embedded +systems and other special purposes; or both. + +Marcus Brinkmann and Neal Walfield, while working on improvements to the Hurd +design, pushed at the forefront of microkernel operating system research. They +worked with the most distinguished researchers in this field from the [L4](http://l4hq.org/) and [EROS](http://www.eros-os.org/eros.html)/[Coyotos](http://www.coyotos.org/) -microkernel operating system groups, and have written a couple of [research -papers](http://walfield.org/). - -* Why is your group applying to participate? What do you hope to gain by participating? - -The primary goal of course is to find and introduce new long-term contributors -to the project. - -Aside from that, it is a way to make progress with tasks that require an amount of -focused work, that is hard to do for volunteers working in their spare time -only. +microkernel operating system groups, and published a couple of [research +papers](http://walfield.org/) as well in this process. -Also it is a good possibility to get valuable input from new people, as well as -spreading technical and other knowledge about the Hurd among actual and -potential contributors. More generally, participation should help raising -awareness among people who might know about the existence of the Hurd, but -otherwise having very little idea what the project is all about, and how its -progress is. - -Last but not least, we hope the participation will have a positive effect on -our community -- new impulses, increased communication etc. +* Home Page: -* What is the main public mailing list for your group? +http://hurd.gnu.org -bug-hurd@gnu.org, see http://lists.gnu.org/mailman/listinfo/bug-hurd +* Main Organization License: -* Where is the main IRC channel for your group? +GNU General Public License (GPL) -\#hurd on freenode.net +* Why is your organization applying to participate in GSoC 2010? What do you hope to gain by participating? -* What criteria do you use to select the members of your group? Please be as specific as possible. +The primary goal of our participation is of course to find and introduce new long-term contributors +to the Hurd. We are trying to optimise for this in our student selection +process, our mentoring approach, and our choice of project ideas. -The most important criterium is that the person is involved in the project for -some time, knowing the ways; so he can actually instruct the student; and if -there are tough technical questions he can't answer himself, he knows whom to -ask. +The mentor-student setup, together with the period of focused work during the +summer session, also offer a unique opportunity for kick-starting innovative +new projects apart from mainline development, which are hard to fit in among +the normal day-to-day development work. This is particularily important for the +Hurd, as innovative uses are crucial to show the benefits of the unique +architecture. Several such projects came into being through the GSoC program +over the past years. -It's also important that the mentors are reliable and helpful, so the students -won't be left on their own with any problems they face. +Last but not least, GSoC participation always yields a lot of valuable input from new people, and helps +spreading technical and other knowledge about the Hurd among actual and +potential contributors. It has a very positive effect on +our community -- new impulses, increased communication, etc. -* Has your group participated previously? If so, please summarize your involvement and any past successes and failures. +* Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. In 2006 and 2007, we participated under the umbrella of the GNU project, getting one slot each year. -The 2006 participation was mostly a failure. After some intitial work -(available in CVS), the student disappeared -- moving to another country and -other personal issues from what we heard. +In 2008 we participated as an organisation on our own for the first time. This +turned out extremely beneficial: with the better visibility, we got a lot +more applications (more than 20), mostly of good or excellent quality. -The 2007 participation was a considerable success. The student was very bright -and dedicated. We got some code, as well as a lot of ideas, which we continued -discussing after the end of GSoC, and he intends to put into code as well in -the future. +In 2009, we were rejected as an organisation, so we participated under the GNU +umbrella again. -In 2008 we participated as an organisation on our own for the first time. This -turned out extremely beneficial: Not only did it give us much better -possibilities to find and select good students, as we hoped. We also get a lot -more applications, mostly of good or excellent quality. +While the 2006 student disappeared midway, in all the later years all of our +students were successful -- even including one who worked on his project in +spite of not getting an official slot. Half of them are regular Hurd contributors now. -We ended up with four slots. (We didn't request more, because we were not sure -whether we would be able to mentor them properly, and generally didn't want to -overdo it on our first "full" participation.) There was also a fifth student, -who worked on his project in spite of not getting a slot. +Selecting the most promising students, as well as suitable mentors, turned out +to be the most tricky part of GSoC participation -- but we learned our lesson +after the first failure: we didn't have any students that didn't meet our +expectations since then, and we also believe our mentoring is exceptionally +good now -- one project that was in serious trouble, turned out well after all, +due to effective mentor intervention. -All five students were pretty successful, most of them completing or almost -completing the original goals -- some even exceeding them. Even our weakest -student, after serious struggling in the beginning, did quite well in the end. +* If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006. -Two students are still regularily working on the Hurd -- not as much as we -hoped of course, but probably as much as can be realistically expected... +2008: 4/4 -All in all, the participation was a considerable amount of work, but it was -definitely worth it :-) +(+1 inofficial in 2008) +(under GNU umbrella: 2006: 0/1; 2007: 1/1; 2009: 1/1) -* If your group has not previously participated, have you applied in the past? If so, for what sort of participation? +* If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? -- -* What license does your organization use? +* What is the URL for your ideas page? -GNU General Public License (GPL) +http://www.gnu.org/software/hurd/community/gsoc/project_ideas.html -* What is the URL to the ideas list of your organization? +* What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2010. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. -http://www.gnu.org/software/hurd/community/gsoc/project_ideas.html +bug-hurd@gnu.org ( http://lists.gnu.org/mailman/listinfo/bug-hurd ) -* What is the main development mailing list for your group? +* What is the main IRC channel for your organization? -bug-hurd@gnu.org, see http://lists.gnu.org/mailman/listinfo/bug-hurd +\#hurd on freenode.net -* What is the application template you would like contributors to your organization to use. +* Does your organization have an application template you would like to see students use? If so, please provide it now. Please note that it is a very good idea to ask students to provide you with their contact information as part of your template. Their contact details will not be shared with you automatically via the GSoC 2010 site. [[student_application_form]] -* What is your plan for dealing with disappearing contributors? +* What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible: -The plan is mostly to avoid that happening in the first place. For that, we -will be particularily careful with the selection of the students: Making sure -that they have no other obligations during that time; that they are motivated +The most important criterium is that the person is involved in the project for +some time, knowing the ways; so he can actually instruct the student; and if +there are tough technical questions he can't answer himself, he knows whom to +ask. + +It's also important that the mentors are reliable and helpful, so the students +won't be left on their own with any problems they face. + +* What is your plan for dealing with disappearing students? + +The plan is mostly to avoid that happening in the first place. To this end, we +are particularily careful with selection of students: Making sure +that they have no other major obligations during that time; that they are motivated enough; that they actually have the necessary skills to complete the task; that they fit in our community. @@ -175,50 +157,55 @@ Also, we will make sure that we are constantly in contact with the students -- asking about progress, discussing technical issues, etc. -- so we can act in time if things go wrong. -If a student disappears in spite of that, there is little we can do. Of course +If a student disappears in spite of all this, there is little we can do. Of course we will try to contact him and find out what the problem is; whether the -project can perhaps be scaled down, or at least wrapped up to bring it in a -state where it is useful even if not finished. +project can perhaps be scaled down, or otherwise salvaged, so that the effort +already invested in the student and the project is not wasted. We also try to +make sure that all important design discussions are archieved, and that all +code produced is suitable for upstream inclusion from the beginning -- to allow +others to pick up the project if necessary, without having to start from zero. -We will also try to limit damage by insisting that students regularily check in -their work, so that we get partial results at least if someone disappears. - -* What is your plan for dealing with disappearing members? +* What is your plan for dealing with disappearing mentors? As our mentors all have been with the project for some time, the risk of them disappearing is not too big. If one of them disappears nevertheless, it's not a -problem for us: We have enough mentors, and someone else will take over. +problem for us: we have enough mentors, and someone else will take over. We will encourage the students to keep discussions public as much as possible, keeping private conversations with the mentors to a minimum, so the transition should go smoothly. -* What steps will you take to encourage contributors to interact with your community before, during, and after the program? +* What steps will you take to encourage students to interact with your project's community before, during and after the program? We try to make it very clear that we expect the students to get into regular -contact with us before the end of the student selection process, and won't +contact with us early during the student selection process already, and won't consider their applications otherwise. This way we know that the students are able and willing to communicate with us in the first place. -After the selection, the regular contact will be kept up: We require the -students to participate in weekly IRC meetings, where we ask the students -actively about the work they do, problems they face, decisions they take etc. -Furthermore, we will ask them to hang around on IRC most of the time while -working on their projects, so we keep in close contact. +After selection, the regular contact is kept up: we require the +students to participate in IRC meetings up to twice a week, where we ask the students +actively about the work they do, problems they face, decisions they take, etc. +Furthermore, we ask them to be available on IRC while working on their +projects, so we can communicate easily. We also require the students to join our main development mailing list, so any -design questions etc. can be discussed there. We will encourage them to take +design questions, etc. can be discussed there. We encourage them to take part in other conversations, not directly related to their projects, as well. -After the program we continue the regular meetings, still discussing the -projects: The application of the code created, future directions etc. +After the program we continue the regular meetings, discussing the further +development of their original projects; as well as new projects, after the +original ones are done. -* What will you do to ensure that your accepted contributors stick with the project after the program concludes? +* What will you do to ensure that your accepted students stick with the project after GSoC concludes? -We will try to invite all participating students to a conference afterwards, -where we will discuss the projects, as well as other Hurd-related topics. We -hope this will motivate them to follow up on the work they have done during the +In addition to keeping up the regular IRC meetings, +we try to invite all participating students to meet us at conferences afterwards, +where we discuss the projects, as well as other Hurd-related topics. This should +keep them motivated to follow up on the work they have done during the program, and generally help keeping them involved. -* Please select your backup group administrator. +* Is there anything else you would like to tell the Google Summer of Code program administration team? : + +* Backup Admin (Link ID): +tschwinge diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 32c8aed8..8ce10ffa 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] We offer a wide range of possible projects to choose from. If you have an idea not listed here, we'd love to hear about it! @@ -39,7 +40,7 @@ Try to find something to improve in the relevant code, by looking at known issues in the [Savannah bug tracker](http://savannah.gnu.org/bugs/?group=hurd); by running the code and testing stuff; and by looking through the code. If you don't find anything, try with some related code -- if you task involves -translator programming, make some improvement to an existing translor; if it +translator programming, make some improvement to an existing translator; if it involves glibc hacking, make an improvement to glibc; if it involves driver hacking, make an improvement to the driver framework; and so on... Makes sense, doesn't it? :-) @@ -73,16 +74,18 @@ After all, the purpose of GSoC is to introduce you to free software development before the end of the application process, with our help -- contact us, and we will assist you as well as we can. -See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/Hurd_Porting). +See also the list of [Hurd-related X.Org project +ideas](http://xorg.freedesktop.org/wiki/Hurd_Porting). + +<!-- Olaf, wouldn't it make sense to put the following tasks next to each +other: language_bindings, gnat, gccgo, perl_python. --> [[!inline pages="community/gsoc/project_ideas/language_bindings" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/virtualization" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/file_locking" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/driver_glue_code" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/server_overriding" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/tcp_ip_stack" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/nfs" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/libdiskfs_locking" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/pthreads" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/sound" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/disk_io_performance" show=0 feeds=no actions=yes]] @@ -91,17 +94,21 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/gnumach_cleanup" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/xmlfs" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/unionfs_boot" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/tmpfs" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/lexical_dot-dot" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/secure_chroot" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/package_manager" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/debian_installer" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/download_backends" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/libgtop" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/maxpath" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/gnat" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/gccgo" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/hardware_libs" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/cdparanoia" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/perl" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/perl_python" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/testing_framework" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/libcap" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/valgrind" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/driver_glue_code" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/dtrace" show=0 feeds=no actions=yes]] +[[!inline pages="community/gsoc/project_ideas/libdiskfs_locking" show=0 feeds=no actions=yes]] diff --git a/community/gsoc/project_ideas/debian_installer.mdwn b/community/gsoc/project_ideas/debian_installer.mdwn index ca10a61e..37dcc72d 100644 --- a/community/gsoc/project_ideas/debian_installer.mdwn +++ b/community/gsoc/project_ideas/debian_installer.mdwn @@ -10,6 +10,11 @@ is included in the section entitled [[!meta title="Port the Debian Installer to the Hurd"]] +[!] Jérémie Koenig has been working on this as a [[Google Summer of Code +2010|2010]] project. + +--- + The primary means of distributing the Hurd is through Debian GNU/Hurd. However, the installation CDs presently use an ancient, non-native installer. The situation could be much improved by making sure that the newer *Debian @@ -21,6 +26,21 @@ Some preliminary work has been done, see The goal is to have the Debian Installer fully working on the Hurd. It requires relatively little Hurd-specific knowledge. +A lot of the "non-Linux support" part of the project has already been done thanks to a previous GSoC, so at least no ground reason should bar the project. A lot of the required udebs are already in Debian or are pending upload, so that building an image and booting it does already work. A preliminary list of what remains is + + * Add initrd support to GNU Mach, unless youpi does it before :) This should not be very complicated by re-using the iopl driver code. + * hurdify genext2fs to handle 4096 block size by default (see bug #562999) and support translator entries. + * Port busybox. This needs to be synchronized with kfreebsd people, who have probably already done some work, but that seemingly still hasn't been merged. In the meanwhile, youpi has a version with most of it disabled so a d-i image can actually be built. + * Port keyboard-setup to configure the xkb driver of the Hurd console + +As a starting point to get a grasp at how the debian installer is built, students might wish to look at the current Debian installer source and build process on Linux: + + * svn co svn://svn.debian.org/d-i/trunk/installer/ + * cd installer/build + * make build_monolithic + +The same can be done on hurd-i386 but a few non-uploaded packages are needed, see http://people.debian.org/~sthibault/hurd-i386/README-d-i + Possible mentors: Samuel Thibault (youpi) -Exercise: Try to get one piece of the installer running on Hurd. +Exercise: Fix a couple of Hurd issues in busybox. diff --git a/community/gsoc/project_ideas/disk_io_performance.mdwn b/community/gsoc/project_ideas/disk_io_performance.mdwn index bb047308..ae634709 100644 --- a/community/gsoc/project_ideas/disk_io_performance.mdwn +++ b/community/gsoc/project_ideas/disk_io_performance.mdwn @@ -1,34 +1,48 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Disk I/O Performance Tuning"]] +[[!tag open_issue_hurd]] + The most obvious reason for the Hurd feeling slow compared to mainstream -systems like GNU/Linux, is very slow harddisk access. +systems like GNU/Linux, is a low I/O system performance, in particular very +slow hard disk access. The reason for this slowness is lack and/or bad implementation of common -optimisation techniques, like scheduling reads and writes to minimalize head +optimization techniques, like scheduling reads and writes to minimize head movement; effective block caching; effective reads/writes to partial blocks; -reading/writing multiple blocks at once; and read-ahead. The +[[reading/writing multiple blocks at once|open_issues/performance/io_system/clustered_page_faults]]; and +[[open_issues/performance/io_system/read-ahead]]. The [[ext2_filesystem_server|hurd/translator/ext2fs]] might also need some -optimisations at a higher logical level. +optimizations at a higher logical level. The goal of this project is to analyze the current situation, and implement/fix -various optimisations, to achieve significantly better disk performance. It +various optimizations, to achieve significantly better disk performance. It requires understanding the data flow through the various layers involved in -disk acces on the Hurd ([[filesystem|hurd/virtual_file_system]], +disk access on the Hurd ([[filesystem|hurd/virtual_file_system]], [[pager|hurd/libpager]], driver), and general experience with -optimising complex systems. That said, the killing feature we are definitely -missing is the read-ahead, and even a very simple implementation would bring +optimizing complex systems. That said, the killing feature we are definitely +missing is the [[open_issues/performance/io_system/read-ahead]], and even a very simple implementation would bring very big performance speedups. +Here are some real testcases: + + * [[open_issues/performance/io_system/binutils_ld_64ksec]]; + + * running the Git testsuite which is mostly I/O bound; + + * use [[TopGit]] on a non-toy repository. + + Possible mentors: Samuel Thibault (youpi) Exercise: Look through all the code involved in disk I/O, and try something diff --git a/community/gsoc/project_ideas/download_backends.mdwn b/community/gsoc/project_ideas/download_backends.mdwn index 749597a6..f794e814 100644 --- a/community/gsoc/project_ideas/download_backends.mdwn +++ b/community/gsoc/project_ideas/download_backends.mdwn @@ -19,7 +19,7 @@ Download protocols like FTP, HTTP, BitTorrent etc. are very good candidates for this kind of modularization: a program could simply use the download functionality by accessing FTP, HTTP etc. translators. -There is already an ftpfs traslator in the Hurd tree, as well as an [httpfs +There is already an ftpfs translator in the Hurd tree, as well as an [httpfs translator on hurdextras](http://www.nongnu.org/hurdextras/#httpfs); however, these are only suitable for very simple use cases: they just provide the actual file contents downloaded from the URL, but no additional status information @@ -35,7 +35,7 @@ The goal of this project is to design a suitable interface, implement it for at least one download protocol, and adapt apt-get (or some other program) to use this as a backend. -This task requires some design skills and some knowlegde of internet protocols, +This task requires some design skills and some knowledge of internet protocols, to create a suitable interface. Translator programming knowledge will have to be obtained while implementing it. diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn index 04efe202..8581c7cb 100644 --- a/community/gsoc/project_ideas/driver_glue_code.mdwn +++ b/community/gsoc/project_ideas/driver_glue_code.mdwn @@ -1,42 +1,73 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!meta title="New Driver Glue Code"]] +[[!meta title="New Driver Framework"]] -Although a driver framework in userspace would be desirable, presently the Hurd -uses kernel drivers in the microkernel, -[[GNU_Mach|microkernel/mach/gnumach]]. (And changing this would be far beyond a -GSoC project...) +[[!tag stable_URL]] -The problem is that the drivers in GNU Mach are presently old Linux drivers -(mostly from 2.0.x) accessed through a glue code layer. This is not an ideal -solution, but works quite OK, except that the drivers are very old. The goal of -this project is to redo the glue code, so we can use drivers from current Linux -versions, or from one of the free BSD variants. +The Hurd presently uses hardware drivers +implemented in the microkernel, [[GNU_Mach|microkernel/mach/gnumach]]. +These drivers are old Linux drivers (mostly from 2.0.x) +accessed through a glue code layer. +This is not an ideal solution, but works quite OK, +except that the drivers are extremely old by now. +Thus we need a new framework, +so we can use drivers from current Linux versions instead, +or perhaps from one of the free BSD variants. -While it would be certainly possible to create custom glue code again, a more -sustainable and probably also easier approch is to use -[ddekit](http://demo.tudos.org/dsweeper_tutorial.html) instead -- it already -does the hard work of providing an environment where the foreign drivers can -run, and has the additional advantage of being externally maintained. +This is [[!GNU_Savannah_task 5488]]. +[[open issues/user-space device drivers]]. +[[open issues/device drivers and io systems]]. -This is a doable, but pretty involved project. Previous experience with driver -programming probably is a must. (No Hurd-specific knowledge is required, -though.) +The most promising approach for getting newer drivers seems to be [[DDE]]: +it already does the hard work of providing an environment +where the foreign drivers can run, +and offers the additional benefit of being externally maintained. +DDE also offers the necessary facilities +for running all drivers in separate userspace processes, +which is more desirable than drivers running in the microkernel. -This is [[!GNU_Savannah_task 5488]]. +[[Zheng Da|zhengda]] has already done considerable work on this. +The basic framework for using DDE in the Hurd is present, +and network card drivers are already working very well. +However, this work isn't fully integrated in the Hurd yet. +The additional kernel interfaces that were created for this +are still prototypes, and will need to be reworked. +Also, there is no build system for automatically compiling +all Linux network card drivers in one go. + +Other types of drivers are missing so far. +Support for IDE drivers has been partially implemented, +but isn't fully working yet. +To fully replace the old in-kernel drivers, +further infrastructure will be necessary +to make userspace disk drivers usable for the root filesystem. + +Some other subsystems are missing or incomplete in DDE itself, +and will require additional work that is not specific to the Hurd implementation. + +The goal of this task is to fix at least one of the mentioned major shortcomings: +rework the kernel interfaces; +provide a streamlined build system for the drivers; +finish IDE support; +or implement support for some other subsystem. +<!-- should probably provide separate task descriptions for each... --> + +This is a doable, but pretty involved project. +Previous experience with driver programming probably is a must. +To be able to work on the framework, +the student will also have to get a good understanding of certain aspects of Hurd, +such as memory management for example. -Possible mentors: Samuel Thibault (youpi) +Possible mentors: Zheng Da, Samuel Thibault (youpi) -Exercise: Take a driver for some newer piece of hardware (e.g. Intel e1000 -ethernet) from a recent system, and try to port it to run in the existing -driver framework in GNU Mach. Completing the port might be too involved for the -exercise; but it's pretty likely that you will find something else to improve -in the glue code while working on this... +Exercise: Get one of the not yet integrated Linux network card drivers to work. +(Note: This should be straightforward, +once you have the framework properly built and set up...) diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn index 93c2a5f3..6261c03e 100644 --- a/community/gsoc/project_ideas/dtrace.mdwn +++ b/community/gsoc/project_ideas/dtrace.mdwn @@ -1,22 +1,25 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!meta title="dtrace Support"]] +[[!meta title="Kernel Instrumentation"]] + +[[!tag open_issue_gnumach]] One of the main problems of the current Hurd implementation is very poor -performance. While we have a bunch of ideas what could cause the performance +[[open_issues/performance]]. While we have a bunch of ideas what could cause the performance problems, these are mostly just guesses. Better understanding what really causes bad performance is necessary to improve the situation. For that, we need tools for performance measurements. While all kinds of more -or less specific profiling tools could be convieved, the most promising and +or less specific [[open_issues/profiling]] tools could be conceived, the most promising and generic approach seems to be a framework for logging certain events in the running system (both in the microkernel and in the Hurd servers). This would allow checking how much time is spent in certain modules, how often certain @@ -24,23 +27,36 @@ situations occur, how things interact, etc. It could also prove helpful in debugging some issues that are otherwise hard to find because of complex interactions. -The most popular framework for that is Sun's dtrace; but there might be others. -The student has to evaluate the existing options, deciding which makes most -sense for the Hurd; and implement that one. (Apple's implementation of dtrace -in their Mach-based kernel might be helpful here...) - -This project requires ability to evaluate possible solutions, and experience -with integrating existing components as well as low-level programming. +The most popular kernel instrumentation framework is Sun's dtrace, +originally written for Solaris, +but also adopted by some other systems. +However, the GPL-incompatible license means it can't be used in Linux, +and thus Linux developers created their own frameworks instead: +first [[SystemTap]], and now [[LTTng]]. + +In 2008, Andrei Barbu did initial work on kernel probes for the Hurd. +However, not all of his patches got merged, +because some turned out not to be fully functional. +Also, he didn't get around to work on userspace probes, +nor on a nice frontend for writing test scripts employing the probes. + +The goal of this project is to make the instrumentation framework +more usable and complete, +and to better integrate it in the Hurd. +For that, the student will have to work +on some real profiling and/or debugging tasks, +and fix any shortcomings he encounters in the framework. + +This is a pretty involved task. +Previous experience with low-level programming is a must; +and it also requires a good grasp on interactions in complex systems. + +To work on this project, +the student will have to get familiar with GNU Mach. +(The microkernel employed by the Hurd.) +Some understanding of other aspects of the Hurd will also be required, +depending on the exact nature of the profiling/debugging performed. Possible mentors: Samuel Thibault (youpi) -Exercise: In lack of a good exercise directly related to this taks, just pick -one of the kernel-related or generally low-level tasks from the bug/task -trackers on savannah, and make a go at it. You might not be able to finish the -task in a limited amount of time, but you should at least be able to make a -detailed analysis of the issue. - -*Status*: Andei Barbu was working on -[SystemTap](http://csclub.uwaterloo.ca/~abarbu/hurd/) for GSoC 2008, but it -turned out too Linux-specific. He implemented kernel probes, but there is no -nice frontend yet. +Exercise: Use the existing probes to perform some simple measurement. diff --git a/community/gsoc/project_ideas/file_locking.mdwn b/community/gsoc/project_ideas/file_locking.mdwn index b6b393f9..206d4d7d 100644 --- a/community/gsoc/project_ideas/file_locking.mdwn +++ b/community/gsoc/project_ideas/file_locking.mdwn @@ -1,27 +1,31 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!meta title="Fix File Locking"]] +[[!meta title="Fix and Complete File Locking Support"]] -Over the years, [[UNIX]] has aquired a host of different file locking mechanisms. +Over the years, [[UNIX]] has acquired a host of different file locking mechanisms. Some of them work on the Hurd, while others are buggy or only partially implemented. This breaks many applications. The goal is to make all file locking mechanisms work properly. This requires finding all existing shortcomings (through systematic testing and/or checking for known issues in the bug tracker and mailing list archives), and fixing -them. +them. The biggest missing feature is record locking, i.e. the lockf variant, +which needs a complete implementation. This task will require digging into parts of the code to understand how file locking works on the Hurd. Only general programming skills are required. +A preliminary patch is [[!GNU_Savannah_patch 332 desc="available"]]. + Possible mentors: Samuel Thibault (youpi) Exercise: Find one of the existing issues, either by looking at the task/bug diff --git a/community/gsoc/project_ideas/gccgo.mdwn b/community/gsoc/project_ideas/gccgo.mdwn new file mode 100644 index 00000000..54b20754 --- /dev/null +++ b/community/gsoc/project_ideas/gccgo.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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="Porting Google Go (GCC: gccgo)"]] + +The goal of this project is to make the [Google Go programming +language](http://golang.org/) available on GNU/Hurd in its [[GCC]] *gccgo* +implementation. + +Presumably less work will be needed on the language's frontend itself, but +rather on the supporting libraries. + +Apart from a solid knowledge of the [[POSIX]] API, working knowledge of the +Google Go programming language is a must. Some Hurd knowledge will have to be +acquired while working on the project. + +Designing and implementing [[language_bindings]] is a follow-up project. + +Possible mentors: Ian Lance Taylor: gccgo bits, [[Thomas Schwinge +(tschwinge)|tschwinge]]: Hurd bits. + +Exercise: Fix one of the problems preventing *gccgo* from working on the Hurd. + +--- + +[[Open Issue page|open_issues/gccgo]]. [Entry in the GCC +wiki](http://gcc.gnu.org/wiki/SummerOfCode#gccgo_hurd). diff --git a/community/gsoc/project_ideas/gnat.mdwn b/community/gsoc/project_ideas/gnat.mdwn deleted file mode 100644 index b7f2ea62..00000000 --- a/community/gsoc/project_ideas/gnat.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -[[!meta copyright="Copyright © 2009 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="Porting GNAT"]] - -The GNU Ada Translator (GNAT) isn't available for the Hurd so far. There are -also a number of other Debian packages depending on GNAT, and thus not -buildable on the Hurd. - -The goal of this project is getting GNAT fully working in Debian GNU/Hurd. It -requires implementing some explicitely system-specific stuff in GNAT, and maybe -fixing a few other problems. Good knowledge of Ada is a must; some Hurd -knowledge will have to be aquired while working on the project. - -Possible mentors: Samuel Thibault (youpi) - -Exercise: Fix one of the problems preventing GNAT from working on the Hurd. diff --git a/community/gsoc/project_ideas/gnumach_cleanup.mdwn b/community/gsoc/project_ideas/gnumach_cleanup.mdwn index e75c9d3e..4aef0d1b 100644 --- a/community/gsoc/project_ideas/gnumach_cleanup.mdwn +++ b/community/gsoc/project_ideas/gnumach_cleanup.mdwn @@ -11,7 +11,7 @@ is included in the section entitled [[!meta title="GNU Mach Code Cleanup"]] Although there are some attempts to move to a more modern microkernel -alltogether, the current Hurd implementation is based on +altogether, the current Hurd implementation is based on [[GNU_Mach|microkernel/mach/gnumach]], which is only a slightly modified variant of the original CMU [[microkernel/Mach]]. @@ -19,7 +19,7 @@ Unfortunately, Mach was created about two decades ago, and is in turn based on even older BSD code. Parts of the BSD kernel -- file systems, [[UNIX]] [[mechanism]]s like processes and signals, etc. -- were ripped out (to be implemented in [[userspace_servers|hurd/translator]] instead); while other mechanisms were -added to allow implementing stuff in userspace. +added to allow implementing stuff in user space. ([[Pager_interface|microkernel/mach/external_pager_mechanism]], [[microkernel/mach/IPC]], etc.) diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn index bf75c805..d9a426be 100644 --- a/community/gsoc/project_ideas/language_bindings.mdwn +++ b/community/gsoc/project_ideas/language_bindings.mdwn @@ -1,15 +1,19 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Bindings to Other Programming Languages"]] +<!-- See also open_issues/gccgo, open_issues/gnat, open_issues/perl, and +open_issues/python. --> + The main idea of the Hurd design is giving users the ability to easily modify/extend the system's functionality ([[extensible_system|extensibility]]). This is done by creating [[filesystem_translators|hurd/translator]] and other @@ -19,7 +23,7 @@ However, in practice this is not as easy as it should, because creating translators and other servers is quite involved -- the interfaces for doing that are not exactly simple, and available only for C programs. Being able to easily create simple translators in RAD languages is highly desirable, to -really be able to reap the advantages of the Hurd architecture. +really be able to reap the [[advantages]] of the Hurd architecture. Originally Lisp was meant to be the second system language besides C in the GNU system; but that doesn't mean we are bound to Lisp. Bindings for any popular @@ -30,20 +34,24 @@ Several approaches are possible when creating such bindings. One way is simply to provide wrappers to all the available C libraries ([[hurd/libtrivfs]], [[hurd/libnetfs]] etc.). While this is easy (it requires relatively little consideration), it may not be the optimal solution. It is preferable to hook in at a lower level, thus -being able te create interfaces that are specially adapted to make good use of +being able to create interfaces that are specially adapted to make good use of the features available in the respective language. -These more specialised bindings could hook in at some of the lower level +These more specialized bindings could hook in at some of the lower level library interfaces ([[hurd/libports]], [[hurd/glibc]], etc.); use the [[microkernel/mach/MIG]]-provided [[microkernel/mach/RPC]] stubs directly; or even create native stubs directly from the interface definitions. The -[[lisp_bindings_created_by_Flavio_Cruz|flaviocruz]] in last year's GSoC mostly -use the latter approach, and can serve as a good example. +[[lisp_bindings_created_by_Flavio_Cruz|flaviocruz]] as his [[2008 GSoC +project|2008]] mostly use the latter approach, and can serve as a good example. +In his [[2011 GSoC project|2011]], Jérémie Koenig designed and began +implementing an object-oriented interface; see his [[Java status +page|user/jkoenig/java]] for details. There is another possible reason for preferring lower-level bindings: Presently, the Hurd server libraries use the cthreads threading library, which -predates the pthread standard prevalent today. There is a pthread library for -the Hurd as well, but it's not possible to use both cthreads and pthreads in +predates the pthread standard prevalent today. There is a +[[pthread library for the Hurd|libpthread]] +as well, but it's not possible to use both cthreads and pthreads in the same executable. Thus, until [[porting_the_Hurd_libraries_to_pthreads|community/gsoc/project_ideas/pthreads]] is finished, implementing bindings for any language that uses pthreads (in the @@ -64,4 +72,4 @@ There was also some previous work on [Perl bindings](http://www.nongnu.org/hurdextras/#pith), which might serve as a reference if you want to work on Perl. -Possible mentors: Anatoly A. Kazantsev (jim-crow) for Python +Possible mentors: Anatoly A. Kazantsev (anatoly) for Python diff --git a/community/gsoc/project_ideas/lexical_dot-dot.mdwn b/community/gsoc/project_ideas/lexical_dot-dot.mdwn index f0b8db7c..e0dabc01 100644 --- a/community/gsoc/project_ideas/lexical_dot-dot.mdwn +++ b/community/gsoc/project_ideas/lexical_dot-dot.mdwn @@ -22,7 +22,7 @@ resolution. Some application already use lexical resolution internally for that reason. It is generally agreed that many problems could be avoided if the standard filesystem lookup calls used lexical resolution as well. The compatibility -problems probably would be negligable. +problems probably would be negligible. The goal of this project is to modify the filename lookup mechanism in the Hurd to use lexical resolution, and to check that the system is still fully @@ -31,7 +31,7 @@ mechanism. See also [[!GNU_Savannah_bug 17133]]. -Possible mentors: ? +Possible mentors: Carl Fredrik Hammar (cfhammar) Exercise: This project requires changes to the name lookup mechanism in the Hurd-related glibc parts, as well as the Hurd servers. Thus, the exercise task diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn index 10ca508e..18c49c48 100644 --- a/community/gsoc/project_ideas/libcap.mdwn +++ b/community/gsoc/project_ideas/libcap.mdwn @@ -1,12 +1,12 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Implementing libcap"]] @@ -14,7 +14,7 @@ libcap is a library providing the API to access POSIX capabilities. These allow giving various kinds of specific privileges to individual users, without giving them full root permissions. -Although the Hurd design should faciliate implementing such features in a quite +Although the Hurd design should facilitate implementing such features in a quite natural fashion, there is no support for POSIX capabilities yet. As a consequence, libcap is not available on the Hurd, and thus various packages using it can not be easily built in Debian GNU/Hurd. @@ -31,6 +31,10 @@ Some knowledge of POSIX capabilities will need to be obtained, and for the latter part also some knowledge about the Hurd architecture. This project is probably doable without previous experience with either, though. +David Hedberg applied for this project in 2010, +and though he didn't go through with it, +he fleshed out many [[details]]. + Possible mentors: Samuel Thibault (youpi) Exercise: Make libcap compile on Debian GNU/Hurd. It doesn't need to actually diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn new file mode 100644 index 00000000..85695978 --- /dev/null +++ b/community/gsoc/project_ideas/libcap/details.mdwn @@ -0,0 +1,766 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Details on implementing libcap"]] + + +This is the proposal submitted by David Hedberg for GSoC 2010 (who opted +to go with another mentoring organization), adapted from an initial +proposal and several amendments into a single document, but the idea +is to further adapt it to a more neutral design document over time. + + +# The proposal + +### Quick description of POSIX capabilities + +The original suggestion can be found [[here|libcap]]. +POSIX capabilities never actually entered the POSIX standard but was +left as a draft. Linux has nevertheless implemented this draft, and +there are reasons for doing the same in the Hurd - a more fine grained +control of rights leading to increased security being one of them. + +POSIX capabilities are give on a per-process basis, and basically allows +splitting up those rights usually granted to root into smaller and more +specific rights. Examples of capabilities are CAP_CHOWN and CAP_KILL, +overriding certain restrictions on chown and allowing the process to +kill processes with different UID's, respectively. + +Each process is given three sets with capabilities: the Permitted set +(P), the Effective set (E) and the Inheritable set (I). The effective +set contains the capabilities that are currently active. The permitted +set contains the capabilities that the process has the right to use. +The inheritable set contains the capabilities that can be inherited +by children to the process. A process can drop capabilities from its +permitted set, but not set them. The effective set and the inheritable +set can be changed freely as long as they stay subsets of the permitted +set. + +Capabilities can also be set on executables. When executed, the resulting +process is given the capabilities both as defined by the parent process +and by the capabilities set on the file (formula below), resulting in +what might be explained as a fine-grained setuid. Implementing this +requires support for *xattr* or similar. + +Some applications that are currently using capabilities are samba, ntp, +vsftp, pure-ftpd, proftpd, squid, asterisk and dovecot. + + +### A quick description of capabilities in Linux + +Each process has a three bit fields representing each of the three +sets (P, E and I). Each bit field is currently built up of two (32 +bit) integers to be able to hold the 33 currently defined capabilities +(see linux/capability.h). Each process further has a bounding set which +bounds the permitted set. Two [[system call]]s handles the setting and getting +of capabilities; *capset* and *capget*. Some related functionality +can also be controlled by calling *prctl*: the right to read/drop the +bounding capabilities (PR_CAPBSET_READ/PR_CAPBSET_DROP) and whether +or not the process should keep its capabilities when a change is made +to the threads UID's (PR_SET_KEEPCAPS/PR_GET_KEEPCAPS). User space +applications are expected(recommended?) to use libcap to take advantage +of the functionality provided. Some applications also use libcap-ng +which is "intended to make programming with POSIX capabilities much +easier than the traditional libcap library". Most applications seem +to be using the original libcap, however. + + +## Implementing libcap + +The exercise for this assignment was to get the libcap used in +Linux to compile under the Hurd. This was accomplished using the +latest git version of libcap from (..), corresponding to libcap +2.19. The changes were simple and amounted to simply removing the +dependency on some Linux-specific headers and creating stubs for +capset, capget and prctl described above. This suggests that porting +this library to the Hurd once the proper functionality is in place +could be relatively simple. The patch is available +[here](https://alioth.debian.org/tracker/index.php?func=detail&aid=312442&group_id=30628&atid=410472 "Alioth"). +One could also consider implementing the three missing functions in the +Hurd (or Hurd glibc) which would allow the usage of the Linux libcap +without modifications. As the Linux libcap maintainer might or might +not be interested in making libcap multi platform, this approach might +be preferable. + + +## Implementing POSIX capabilities in the Hurd + +As I am still reading up on how things fit together in the Hurd this is +very likely to contain some misunderstandings and be at least partly off +the mark. I intend to have grasped this by the time I start working on +it however, if I were to be given the chance. Below are two possible +approaches as I have understood them after some reading and discussions +on #hurd@freenode. + + +### The basics, Approach 1: Special UID's + +Let each capability be represented by a specific UID. One could imagine +reserving a range of the possible uid_t's for this purpose. The euids +vector in the authhandle struct could perhaps hold the effective set while +the auids vector could hold the permitted set as these seem to roughly +correspond to eachother in intent. This leaves the Inheritable set. +One solution could be to store the inheritable set in the agids vector, +but that does not seem to be a very natural nor nice solution. One could +extend the authhandle struct with an additional vector, but one would then +need to also extend the auth interface with RPC's to be able to modify +and access it. Another possibility is to store all the capabilities +in the same idvec and use separate defines for the the different sets +(CAP_P_CHMOD, CAP_E_CHMOD, CAP_I_CHMOD). This does not seem like a +good solution. + +Storing each capability in its own uid_t might also arguably be somewhat +wasteful, although this is probably of secondary concern (if at all). +One could also imagine that legacy applications might be confused, +although I am not sure I can see any obvious problems. What happens +when a process have only capability id's? + + +### The basics, Approach 2: Extend the auth interface + +This approach would expand the auth interface and extend +the auth server with another set of RPC's for capabilities +(*auth_getcaps*, *auth_makecaps*, *auth_user_authenticate* and +*auth_server_authenticate*), mirroring those currently declared for id's. +This would obviously require changes to more parts of the Hurd for +processes to be able to take advantage of capabilities, but as the logic +behind handling capabilities and that behind handling user id's might +not be completely comparable, this might make for a cleaner solution. +It would also remove the problem of having to sensibly map all the +three capability sets onto semantically differing sets of user/group +ids, something that might be even more important if we were to also +implement something like the bounding sets used in Linux or perhaps +other related functionality. We are also not limited to having to store +the capabilities as id vectors, although doing so would perhaps still +make sense. + + +### The individual capabilities + +Implementing the individual capabilities will probably have to be thought +of on a case-by-case basis. Taking chown (in *libdiskfs*) as an example, +the exact approach would differ slightly depending on how the approach +taken to implement capabilities. If the first approach were to be taken, +the UID's (and thus the capabilities) of the caller would already be +available to the function through the *iouser* struct contained in the +*protid* struct given as the first argument. Implementing capabilities +would then simply be a matter of checking for the special UID's. If the +second approach were to be taken, one would need to perhaps expand the +iouser struct to contain information about the capabilities. + +Just like Linux has defined many Linux-specific capabilities - some of +which could certainly be useful also applied to the Hurd - one could +also imagine extending the POSIX capability system also for Hurd specific +purposes. + + +## Some applications using capabilities + +#### Samba 3 + +Uses CAP_MKNOD and CAP_LEASE in smbd to only keep the necessary abilities. +Documentation mentions CAP_LINUX_IMMUTABLE as a way to protect files +from being deleted. Can also use a couple of IRIX specific capabilities +(CAP_NETWORK_MGT and CAP_DEVICE_MGT) as alternatives to the Linux-specific +ones if running on IRIX. + + +#### ntpd + +Checks if capabilities are supported, more precisely if CAP_SYS_TIME, +CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT and CAP_NET_BIND_SERVICE are +supported. If they are supported, it uses prctl with PR_SET_KEEPCAPS +to keep privileges across setuid() and then drops root. After done with +CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT it drops every capability except +CAP_SYS_TIME and, if needed, CAP_NET_BIND_SERVICE. + + +#### vsftpd + +Uses CAP_CHOWN, CAP_NET_BIND_SERVICE when using the "one process" +security model (typically disabled by default). + + +#### proftpd-basic + +Provides support for capabilities from mod_cap. Uses CAP_USE_CHOWN, +CAP_USE_DAC_OVERRIDE, CAP_USE_DAC_READ_SEARCH and CAP_USE_AUDIT_WRITE. +Distribution contains README.capabilities with some explanations. +Also ships with their own libcap for some reason, based on libcap 1.10. + + +#### dovecot + +Keeps CAP_CHOWN, CAP_SYS_CHROOT, CAP_SETUID, CAP_SETGID, +CAP_NET_BIND_SERVICE, CAP_DAC_OVERRIDE for proper operations, drops +the rest. + + +#### bind9 + +Reasons for each capability are clearly noted in comments in update.c +in linux_initialprivs() and linux_minprivs(). initialprivs drops all +capabilities and proceeds to set CAP_NET_BIND_SERVICE, CAP_SYS_CHROOT, +CAP_SETUID, CAP_SETGID, CAP_DAC_READ_SEARCH and CAP_CHOWN. minprivs only +sets CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE. + + +#### pulseaudio + +Mentions CAP_NICE (CAP_SYS_NICE), but does not appear to be using it +(anymore?). Seems to use libcap to drop caps, however. + + +#### pinentry + +Checks if CAP_IPC_LOCK is available and "uses it" to gain only the +ability to lock memory when needed. + + +#### zsh + +Comes with a module "caps" which contains "[b]uiltins for manipulating +POSIX.1e (POSIX.6) capability (privilege) sets." Most useful here is the +"cap" builtin, which makes it possible to change the shell's process +capability sets. This might be useful for testing. + + +#### inetutils (ping,traceroute) + +Does not use capabilities explicitly, but is nevertheless a useful +example of how file capabilities could be used. ping and traceroute +are currently installed suid root since they need to be able to open +raw sockets. With file capabilities, this could be accomplished by +instead setting the capability CAP_NET_RAW on the two executables, +thus giving the utilities almost only the specific rights they need. + + +## The capabilities + +The above might give some hint as to what capabilities should be +prioritized. One assumption I have made is that the goal of this project +is to implement, as far as possible, the same functionality as what is +present in Linux. No effort has (so far) been made to look into possible +applications specific to the Hurd. + +A few of the above mentioned applications also explicitly uses +PR_SET_KEEPCAPS (through prctl()) to specify that capabilities should +be passed on to children. This means that the implementation in the +Hurd should take this into account. + +I have below done a preliminary classification of the capabilities +as defined in Linux capability.h into four "classes": Network, File +management, "glibc -> mach" and Other. There are also some capabilities +that either depend on functionality not implemented or are too Linux +specific. I have not described each capability in detail as looking +at the comments in capability.h and reading in capabilities(7) are +better sources. + + +### The Networking Class + +These would mostly affect pfinet. The general picture seem to be that +pfinet currently uses a boolean (int) isroot in struct sock_user to keep +track of the credentials of the caller. This would need to be expanded +somehow to keep track of the separate capabilities. + +CAP_NET_BIND_SERVICE: Allow binding to TCP/UDP sockets below 1024 +CAP_NET_RAW: Allow use of RAW and PACKET sockets. +CAP_NET_BROADCAST: "Allow broadcasting, listen to multicast" +CAP_NET_ADMIN: This seem to be a bit of a "catch-all" for network-related +administration. + + +### The Files Management Class + +The description of CAP_CHOWN in the original proposal should apply to +(most of?) these. That is, modify the iouser struct. At least libdiskfs +should be modified, but the same or similar modifications might need to +be made to several servers (libnetfs..? The actual servers implementing +the filesystem?) + +CAP_CHOWN: "Make arbitrary changes to file UIDs and GIDs" +CAP_FOWNER: allow chmod, utime, .. for files not owned. +CAP_FSETID: Don't clear setuid/setgid when a file is modified. +CAP_DAC_OVERRIDE and +CAP_DAC_READ_SEARCH: Bypasses file/directory read/write/execute permission +checks. ( hurdexec.c, file-access.c, .. ? ) +CAP_MKNOD: allows usage of "the privileged aspects of mknod()". Does this +one make sense in the Hurd? + + +### The (glibc -> gnumach) Class + +These seem to be implemented in glibc by direct calls to gnumach. +If they should be implemented, maybe a proxy in the Hurd is needed? + +CAP_SYS_TIME: manipulate the system clock, set real-time clock. +CAP_IPC_LOCK: mlock, mlockall, mmap, shmctl +CAP_KILL: No permission checks for killing processes +CAP_SYS_NICE: setpriority/getpriority for arbitrary processes. + + +### The Rest Class + +CAP_SYS_CHROOT: Allows usage of chroot(). +It's either really simple (not needed in the case of the Hurd) or really +difficult. Needs some figuring out. One of the calls that should be +high-priority. +CAP_SYS_ADMIN: General administration rights. Seemingly sprinkled out +into just about everything. Quick grep through the Linux sources gives +440 hits in .c-files. +CAP_SYS_BOOT: Allow use of reboot(). +glibc calls init:startup_reboot.. +CAP_SETGID: Allows usage of setgid,setgroups and "forged gids on socket +credentials passing" +CAP_SETUID: Allows usage of set*uid and "forged pids on socket credentials +passing" +CAP_SYS_TTY_CONFIG: vhangup, some other places. vhangup() is a stub in +the Hurd, but maybe the console server is otherwise affected? +CAP_SYS_RESOURCE: Override various limits. (quota, reserved space etc. +on ext2, interrupt frequencies, consoles,...). According to "The Critique" +mach performs no resource accounting so some of these might be moot to +implement, while others still apply. +CAP_SYS_RAWIO Allow raw input/output. Sprinkled in many places, +device drivers among others. Many of these will probably be difficult +to implement. +CAP_SETPCAP: This one has (or had?) two different usages in Linux: +If file capabilities are not supported it gives the right to grant +or remove capabilities from the permitted set of arbitrary processes. +If file capabilities are supported, it allows for removing capabilities +from the bounding set of the current process. As the Hurd implementation +won't have file capabilities initially it might make sense to implement +this if possible. If bounding sets are implemented this should probably +be the way provided to modify them. + + +### Unimplementable + +*(At this point in time, as far as I can determine)* + +CAP_LINUX_IMMUTABLE: depends on chattr etc. working. +CAP_SETFCAP: depends on xattr's +CAP_SYS_PACCT: acct() missing in the Hurd. +CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_MAC_OVERRIDE, CAP_MAC_ADMIN, +CAP_AUDIT_WRITE, CAP_AUDIT_CONTROL, CAP_LEASE + + +## Priority when implementing + +The two most used capabilities as unscientifically judged from +the selection of applications above are CAP_NET_BIND_SERVICE and +CAP_CHOWN, suggesting that implementing the "network class" and the +"file management" class of capabilities as classified above might be a +good start. These also, to me, seem to be easier classes to implement. +CAP_NET_ADMIN might need some extra work. + +Second most common were CAP_SYS_CHROOT, CAP_SETGID and CAP_SETUID. I am +not completely clear on how these should be handled. + +Assuming those are out of the way, CAP_IPC_LOCK, CAP_SYS_TIME, CAP_KILL +and CAP_SYS_NICE might be a good choice to tackle if possible. This +might, if I have understood things correctly, involve writing a proxy +Hurd server for these calls in mach. + +CAP_SYS_ADMIN, CAP_SYS_RESOURCE and CAP_SYS_RAWIO. These contains a bit +of "everything" (ADMIN being the worse one), meaning that experience +and infrastructure gained from implementing the previous capabilities +might come in handy. CAP_SYS_RAWIO might be difficult; it can be found +inside many drivers in the Linux source. + + +## Additional general details + +[This article](http://www.ibm.com/developerworks/library/l-posixcap.html) +contains a good general description of how capabilities in Linux +works. As there will be no file capabilities in the Hurd initially, +an approach emulating the behavior Linux exhibits when SECURE_NOROOT +and SECURE_NO_SETUID_FIXUP are *not* set seems to be a good start. +This is called the "root-user-is-privileged" model in the article, +and somewhat simplified it means that processes started by root, or +setuid-root, is given all capabilities no matter what capabilities the +parent might or might not hold at the time of execution. Quoting verbatim +from the article: + +> * When SECURE_NOROOT is not set, then when a process executes a file, +> the new capability sets may be calculated as though the file had some +> file capability sets set fully populated. In particular: +> +> * The file inheritable and permitted sets will be full on if the +> process's real or effective uid is 0 (root) or the file is setuid +> root. +> +> * The file effective set will be full on if the process's effective +> uid is root or the file is setuid root. +> +> +> * When SECURE_NO_SETUID_FIXUP is not set, then when a process switches +> its real or effective uids to or from 0, capability sets are further +> shifted around: +> +> * If a process switches its effective uid from 0 to non-0, then its +> effective capability set is cleared. +> +> * If a process switches its real, effective, or saved uids from at +> least one being 0 to all being non-zero, then both the permitted +> and effective capabilities are cleared. +> +> * If a process sets its effective uid from non-zero to 0, then the +> effective capabilities are set equal to the permitted capabilities. + +The capabilities of the resulting process are determined by the following +formulas, again taken from the article, with p for Process and f for file: + +> pI' = pI +> pP' = fP | (fI & pI) +> pE' = pP' & fE + +The security under the above described model, being what at least some +of the applications I listed in my last comment employs, is basically +the following (also detailed somewhat in the same article): + +* Execute process as root (or setuid) to gain all capabilities. + +* Use the prctl [[system call]] to enable keepcaps for the process + (same(?) effect as enabling SECURE_NO_SETUID_FIXUP for the process). + keepcaps should be off by default. + +* setuid to a non-root user, and by doing so losing the possibility to + regain capabilities by simply starting a new process. + +* Drop all the capabilities except those few actually needed. + + +## Infrastructure details - Special UIDs approach + +The auth server must somehow keep track of three sets of capabilities. +I suggest keeping these three sets in three additional idvec's in the +authhandle struct, and will for the purpose of this description name +these pcaps (permitted), ecaps (effective) and icaps (inheritable). +This will simplify keeping track of the internal logic somewhat. +In addition to this, there is a need to keep track of the "keepcaps" flag +as described above. I suggest representing this with an int keepcaps +in the same struct. + +1. Expand authhandle struct with three additional idvecs and one integer. +Fix static functions handling the struct, such as destroy_authhandle. + +2. Implement the necessary logic in auth_makeauth to handle capabilities. + +Problems: +Assume that all capabilities are mapped onto uids, given names on the form +uid_<capability>, for example uid_cap_net_raw. Assume that the presence +of an uid in euids suggest that the capability is in the effective set +of the process, that the presence of this uid in auids suggests that it +is in the permitted set of the process, and that the presence of this +uid in aguids suggest that it is in the inheritable set of the process. +That they are internally stored in separate idvec's can be ignored as +an implementation detail. + +* The UID's have as it is different meanings depending on where in the + array they are positioned, and certain clients seem to rely on this. + The first UID in euids is the effective uid, and the first and second + UIDs in auids are the real and saved UIDS respectively. At least + some users of makeauth would need to made aware of capabilities, + for example setuid in glibc. + +* Setting/getting the keepcaps-flag is also a bit of a problem. To avoid + changing the auth interface yet another special UID could be used + for this purpose, although that seems to be really stretching it. + The cleaner solution would probably be to expand the interface with + something along the lines of auth_setkeepcaps/auth_getkeepcaps. + This interface would only be used by prctl. + +Another problem with this approach is that it seems a bit difficult +to oversee the affects that using other RPC's like fsys_getroot and +io_restrict_auth might have on capabilities. + + +## Infrastructure details - "extend-interfaces" approach + +This approach has started to seem like the better way to me, as the +usage of capabilities becomes more explicit through the entire "chain", +perhaps making it somewhat more easy to understand all the interactions. + +I suggest something like the following new interface methods: + +*** + + +### The auth interface + + routine auth_getauth_caps ( + handle: auth_t; + out euids: idarray_t; + out auids: idarray_t; + out egids: idarray_t; + out agids: idarray_t; + out ecaps: idarray_t; + out pcaps: idarray_t; + out icaps: idarray_t); + + routine auth_makeauth_caps ( + handle: auth_t; + other_handles: portarray_t; + euids: idarray_t; + auids: idarray_t; + egids: idarray_t; + agids: idarray_t; + ecaps: idarray_t; + pcaps: idarray_t; + icaps: idarray_t; + flags: int; /* keepcaps.. ? */ + out newhandle: mach_port_make_send_t); + + routine auth_server_authenticate_caps ( + handle: auth_t; + sreplyport reply: mach_port_poly_t; + rendezvous: mach_port_send_t; + newport: mach_port_poly_t; + out euids: idarray_t; + out auids: idarray_t; + out egids: idarray_t; + out agids: idarray_t; + out ecaps: idarray_t; + out pcaps: idarray_t; + out icaps: idarray_t); + + +### The io interface + + routine io_restrict_auth_caps ( + io_object: io_t; + RPT + out new_object: mach_port_send_t; + uids: idarray_t SCP; + gids: idarray_t SCP; + ecaps: idarray_t SCP); + + +### The fsys interface + + routine fsys_getroot_caps ( + fsys: fsys_t; + RPT + #ifdef FSYS_GETROOT_UREPLY + ureplyport ureply: mig_reply_port_t; + #endif + dotdot_node: mach_port_send_t; + gen_uids: idarray_t; + gen_gids: idarray_t; + out ecaps: idarray_t; + out pcaps: idarray_t; + out icaps: idarray_t; + flags: int; + out do_retry: retry_type; + out retry_name: string_t; + out file: mach_port_send_t); + +*** + +These are meant to be able to replace the old methods with +capability-aware methods, instead of merely complementing them. +The replacing work could then be made a more gradual process. Steps: + +* Extend authhandle with the same data members as in the UID-case. + +* Implement new _caps-functions according to described interface + extensions above, refactor code a bit to share common uid-handling + logic. Both makeauth's should drop all capabilities if switching from + uid 0 without having keepcaps. For example, keepcaps should be unset + by default. + +* Fix glibc. Extend hurd_id_data in hurd/id.h to store capabilities, + switch to capability aware functions where necessary. + +* io-reauthenticate. Fix implementations to use + auth_server_authenticate_caps instead. For this we also need somewhere + to save the caps, so it ties in with for example the extension of + iouser as mentioned in the details. + +* fsys_getroot. Implement fsys_getroot_caps in libdiskfs, trans, + libtreefs, libtrivs, libnetfs. Fix users of function in libdiskfs, + libfshelp, settrans, libtreefs, clookup. + +* io_restrict_auth. Implement io_restrict_auth_caps in libdiskfs, + libtreefs, libtrivfs, libnetfs, boot. Fix users in utils(symlink, + firmlink), libtrivs, term, clookup + +Among the problems might be that there are a lot of arguments that +needs to be passed around, and that it seems somewhat ugly to end up +with function names referencing caps in particular. + +Below some more about the specific capabilities. This should in large +be common to the two approaches above. + + +## Actually handing out the capabilities to process + +This seems like a good job for the file_exec route in the fs interface. +Quoting from the comments above the definition in fs.defs: "*Necessary +initialization, including authentication changes associated with set[ug]id +execution must be handled by the filesystem*". The capability-granting +functionality should to be added in at least the implementations in +libdiskfs and libnetfs as far as I can determine, and should be "easy +enough" once the infrastructure for implementing the file-related +capabilities (CAP_CHOWN etc.) are in place. This also seem to make +sense considering the future possibility for file capabilities. + + +## Some implementation details of individual capabilities. + +### Net-related capabilities. + +This turned out to be a bit less work than I had thought, as the +imported Linux code already seem to contain all the necessary checks. +What remains to do to implement all of these capabilities is mostly a +matter of putting some infrastructure in place. + +* In struct sock_user (pfinet.h), change isroot for idvec + caps. Alternatively, add idvec caps. + +* Change the function make_sock_user in socket.c to take an idvec caps + as a parameter and properly set the given caps to the corresponding + idvec in sock_user. + +* Fix users of make_sock_user: S_io_reauthenticate, S_io_restrict_auth, + S_socket_create, S_socket_accept. This should be doable with the + current infrastructure. For example, S_socket_create currently + sets isroot in the new sock_user from the corresponding member in + the trivfs_protid struct. This does not present a problem however, + as the latter struct also provides access to an iouser (iohelp.h) + from which the needed uids of the user should be available. + +* Fix up parts of source from Linux, modify task_struct add idvec, + modify prepare_current to take the caps idvec instead of isroot. + Re-implement the existing function capable(int cap) to actually check + for the capability passed as an argument instead of just return isroot. + +* Change a few isroot's at 3 other places in the code to check for + capabilities. Since these places all have access to isroot and thus by + implication the sock_user, they also have access to the new capability + information; no restructuring necessary. + + +### File-related capabilities + +While there are a lot of servers in the Hurd, I am not sure all of these +capabilities actually make sense to implement in all of them. + + +#### CAP_CHOWN + +Implementing this in libdiskfs should take care of it where it makes +sense. Servers using libdiskfs uses iouser from libiohelp to hold +user credentials. As noted above, this struct is already capable of +holding our capabilities as uid's or is otherwise extended to contain +the necessary idvecs if using the second general approach. Adding a +check along the lines of *idvec_contains(uid_cap_chown)* in function +diskfs_S_file_chown (file-chown.c) should be all that's needed. + +In libnetfs, netfs_attempt_chown is declared as a function that the +server using the library must implement. Any checks for chown rights +are however most likely performed on the server side, suggesting that +there is nothing we can do here to implement CAP_CHOWN. Even if we do +need to add something, an iouser containing the necessary information +to implement the checks in a manner analogous to that in libdiskfs seems +to be passed to each important function. + + +#### CAP_DAC_* + +These might actually make sense to implement in more servers, and the +logic seems somewhat involved. Need to add the necessary checks to +at least file_check_access, file_exec in libdiskfs. file_exec also in +libnetfs, probably. Possibly changes also in other places. + +The main difficulties overall seem to lie in getting the infrastructure +properly in place rather than implementing most of the individual +capabilities, and I have updated the schedule a bit in an attempt to +reflect this. + + +## Schedule updating + +The more I look into this the less time it seems likely to take to +do the work. Below is my best estimation at the moment, and I have +basically adjusted everything to what I think is more likely estimations. +If this is correct I would be more or less around midterm. I haven't +gone completely to the individual level as that doesn't seem to make +sense, but what is clustered together are either related capabilities +or a collection of capabilities classified roughly with regards to how +much I know about the area and how many different rights they control. +It's not my intention to "slack off" or anything, so if this estimation +were to be correct I could perhaps take a look at the xattrs-patch, +or spend the rest of my time fixing PATH_MAX-issues. Then again, maybe +there is some great difficulty hidden somewhere. + + +#### Some justifications: + +Dummy libcap, more or less done. +*1 day* (making sure it "fails gracefully" shouldn't really take longer than this) + +Application for testing, the beginnings of a fairly extensive "test suit" on Linux. +*2 days* + +Basic infrastructure. +*5 days*, depends on the chosen approach, but it is probably wise to +reserve at least a bunch of days for this. + +Implementations of prctl/capset/capget in libshouldbeinlibc, +or a port of libcap to the Hurd in any other way. +*5 days* + +CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_NET_BROADCAST, CAP_NET_ADMIN +*4 days*, as noted above this should be easy, but it might uncover bugs +in the newly implemented infrastructure for example. + +CAP_CHOWN,CAP_FOWNER,CAP_FSETID +*2 days*, I think these only needs to be done in libdiskfs + +CAP_DAC_OVERRIDE,CAP_DAC_READ_SEARCH +*4 days*, these might need changes to various servers + +CAP_SYS_TIME,CAP_IPC_LOCK,CAP_KILL +CAP_SYS_NICE,CAP_SYS_CHROOT,CAP_SYS_BOOT +*2 weeks*, these are varied and I'm not that sure exactly how each should +be tackled so some research is needed. + +CAP_SETGID,CAP_SETUID,CAP_SYS_TTY_CONFIG +*4 days* + +CAP_SYS_ADMIN,CAP_SYS_RESOURCE,CAP_SYS_RAWIO +*2 weeks*, these too are pretty varied and some might need some individual +researching + +CAP_SETPCAP +*1 day* + + +## Schedule + +24/5 Start coding +25/5 Dummy libcap ready for use. +27/5 The beginnings of a "test suite", written on Linux. + 1/6 Basic infrastructure in place + 6/6 Dummy libcap extended with real functionality to make use of + implemented capability and infrastructure, or the Hurd adapted for + compatibility with Linux libcap. +10/6 The "network class" of capabilities implemented. +12/6 CAP_CHOWN, CAP_FOWNER, CAP_FSETID +16/6 CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH +30/6 CAP_SYS_TIME, CAP_IPC_LOCK, CAP_KILL, CAP_SYS_NICE, + CAP_SYS_CHROOT, CAP_SYS_BOOT + 4/7 CAP_SETGID,CAP_SETUID,CAP_SYS_TTY_CONFIG +12/7 "Mentors and students can begin submitting mid-term evaluations" +16/7 GSoC Mid-term evaluations deadline. +18/7 CAP_SYS_ADMIN, CAP_SYS_RESOURCE, CAP_SYS_RAWIO +19/7 CAP_SETPCAP diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn index 2a08b387..faac8bd9 100644 --- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn +++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn @@ -1,15 +1,18 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Fix libdiskfs Locking Issues"]] +[[!tag open_issue_hurd]] + Nowadays the most often encountered cause of Hurd crashes seems to be lockups in the [[hurd/translator/ext2fs]] server. One of these could be traced recently, and turned out to be a lock inside [[hurd/libdiskfs]] that was taken @@ -18,17 +21,21 @@ faulty paths causing these lockups. The task is systematically checking the [[hurd/libdiskfs]] code for this kind of locking issues. To achieve this, some kind of test harness has to be implemented: For -exmple instrumenting the code to check locking correctness constantly at -runtime. Or implementing a unit testing framework that explicitely checks +example instrumenting the code to check locking correctness constantly at +runtime. Or implementing a [[open_issues/unit_testing]] framework that explicitly checks locking in various code paths. (The latter could serve as a template for -implementing unit checks in other parts of the Hurd codebase...) +implementing unit tests in other parts of the Hurd codebase...) -(A systematic code review would probably suffice to find the existing locking +(A [[systematic code review|open_issues/security]] would probably suffice to find the +existing locking issues; but it wouldn't document the work in terms of actual code produced, and thus it's not suitable for a GSoC project...) -This task requires experience with debugging locking issues in multithreaded -applications. +This task requires experience with debugging locking issues in +[[multithreaded|open_issues/multithreading]] applications. + +Tools have been written for automated [[open_issues/code_analysis]]; these can help to +locate and fix such errors. Possible mentors: Samuel Thibault (youpi) diff --git a/community/gsoc/project_ideas/libgtop.mdwn b/community/gsoc/project_ideas/libgtop.mdwn index ef1b2bcb..41897a1f 100644 --- a/community/gsoc/project_ideas/libgtop.mdwn +++ b/community/gsoc/project_ideas/libgtop.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2010, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,12 +11,16 @@ is included in the section entitled [[!meta title="Porting libgtop"]] +/!\ On 2012-05-05 Andjos reported (commit +web.git:8061106f2d1f15fa9a54947bc45d4cba68d89bba) that this task has already +been completed. + libgtop is a library used by many applications (especially GNOME applications) to abstract the system-specific methods for obtaining information about the current state of the system -- processes running, system load etc. -A [[Linux-compatible_procfs|madhusudancs]] implementation has been created -during GSoC 2008, and should cover a large part of the functionality of +A Linux-compatible [[hurd/translator/procfs]] is available +and should cover a large part of the functionality of libgtop. However, not all necessary information is exported via /proc (even on Linux); there are some bits still missing in the Hurd procfs implementation; and there are a couple of bugs that need to be fixed to make it fully usable. @@ -24,9 +29,9 @@ The goal of this project is a fully functional libgtop in Debian GNU/Hurd. Some application(s) using it also need to be ported, e.g. gnome-system-monitor. Some bits of this work are easy, others need some digging into Hurd internals. -This task doesn't require any specific previous knowlegde (besides of general +This task doesn't require any specific previous knowledge (besides of general C/UNIX programming skills of course); but during the course of the project, -some knowlegde about Hurd internals will have to be obtained, along with a bit +some knowledge about Hurd internals will have to be obtained, along with a bit of Debian stuff. Possible mentors: Samuel Thibault (youpi) diff --git a/community/gsoc/project_ideas/maxpath.mdwn b/community/gsoc/project_ideas/maxpath.mdwn index 5be8917f..4a1314c2 100644 --- a/community/gsoc/project_ideas/maxpath.mdwn +++ b/community/gsoc/project_ideas/maxpath.mdwn @@ -13,7 +13,7 @@ is included in the section entitled POSIX describes some constants (or rather macros) like PATH_MAX/MAXPATHLEN and similar, which may be defined by the system to indicate certain limits. Many people overlook the *may* though: Systems only should define them if they -actually have such fixed limits. The Hurd, following the GNU Coding Standards, +actually have such fixed limits (see [limits.h](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html)). The Hurd, following the GNU Coding Standards, tries to avoid this kind of arbitrary limits, and consequently doesn't define the macros. diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn index 045533e6..a60a8038 100644 --- a/community/gsoc/project_ideas/mtab.mdwn +++ b/community/gsoc/project_ideas/mtab.mdwn @@ -22,7 +22,7 @@ is no central place keeping track of mounts. As a consequence, there is currently no easy way to obtain a listing of all mounted file systems. This also means that commands like `df` can only work on -explicitely specified mountpoints, instead of displaying the usual listing. +explicitly specified mountpoints, instead of displaying the usual listing. One possible solution to this would be for the translator startup mechanism to update the `mtab` on any `mount`/`unmount`, like in traditional systems. @@ -31,7 +31,7 @@ with passive translators, i.e., translators that are not presently running, but set up to be started automatically whenever the node is accessed? Probably these should be counted among the mounted filesystems; but how to handle the `mtab` updates for a translator that is not started yet? Generally, being -centralized and event-based, this is a pretty unelegant, non-hurdish solution. +centralized and event-based, this is a pretty inelegant, non-hurdish solution. A more promising approach is to have `mtab` exported by a special translator, which gathers the necessary information on demand. This could work by @@ -64,10 +64,10 @@ other filtering rules might be desirable. After taking decisions on the outstanding design questions, the student will implement both the actual [[mtab_translator|hurd/translator/mtabfs]], and the -necessery interface(s) for gathering the data. It requires getting a good +necessary interface(s) for gathering the data. It requires getting a good understanding of the translator mechanism and Hurd interfaces in general. -Possible mentors: Olaf Buddenhagen (antrik) +Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar) Exercise: Make some improvement to any of the existing Hurd translators. Especially those in [hurdextras](http://www.nongnu.org/hurdextras/) are often diff --git a/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn b/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn index d40d73ac..f668b6f2 100644 --- a/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn +++ b/community/gsoc/project_ideas/namespace-based_translator_selection.mdwn @@ -1,14 +1,21 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!meta title="Namspace-based Translator Selection"]] +[[!meta title="Namespace-based Translator Selection"]] + +[!] [[Sergiu Ivanov|scolobb]] has been working *voluntarily* on this task an +inofficial GSoC 2008 participant. Not all the desired functionality is in +place yet, though. + +--- The main idea behind the Hurd is to make (almost) all system functionality user-modifiable ([[extensible_system|extensibility]]). This includes a @@ -26,7 +33,7 @@ file, and presents a virtual file with the uncompressed contents. Or the other way around. Or a translator that presents an [[XML_file_as_a_directory_tree|hurd/translator/xmlfs]]. Or an mbox as a set of individual files for each mail ([[hurd/translator/mboxfs]]); or ever further -breaking it down into headers, body, attachements... +breaking it down into headers, body, attachments... This gets even more powerful when translators are used as building blocks for larger applications: A mail reader for example doesn't need backends for @@ -40,7 +47,7 @@ There are a few problems with the way translators are set, though. For one, once a translator is set on a node, you always see the translated content. If you need the untranslated contents again, to do a backup for example, you first need to remove the translator again. Also, having to set a translator -explicitely before accessing the contents is pretty cumbersome, making this +explicitly before accessing the contents is pretty cumbersome, making this feature almost useless. A possible solution is implementing a mechanism for selecting translators @@ -61,7 +68,7 @@ place of the original ones. In the long run it's probably desirable to have the mechanism implemented in the standard name lookup mechanism, so it will be available globally, and avoid -the overhead of a proxy; but for the beginnig the proxy solution is much more +the overhead of a proxy; but for the beginning the proxy solution is much more flexible. The goal of this project is implementing a prototype proxy; perhaps also a @@ -75,8 +82,3 @@ Possible mentors: Olaf Buddenhagen (antrik) Exercise: Try to make some modification to the existing unionfs and/or firmlink translators. (More specific suggestions welcome... :-) ) - -*Status*: Sergiu Ivanov has been working *voluntarily* on -[[namespace-based_translator_selection|scolobb]], as an inofficial GSoC 2008 -participant! Not all the desired functionality is in place yet; work is -ongoing. diff --git a/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn b/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn new file mode 100644 index 00000000..befd680a --- /dev/null +++ b/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn @@ -0,0 +1,64 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-04-22 + + <youpi> btw, I was wondering, when working on namespace mangling, did they + think about automatitioning ? + <youpi> autopartitioning, I meant + <youpi> i.e. with a foo.img file, open foo.img,,part1 + <braunr> what are you referring to with namespace mangling + <youpi> and voila + <youpi> I don't remember the exact term they used + <braunr> you mean there is a hurd library that parses names and can direct + to different services depending on part of the name ? + <youpi> namespace-based_translator_selection + <youpi> yes + <braunr> i thought it only handled directories + <braunr> well, the classical path representation + * civodul finds it ugly + <youpi> civodul: because of potential conflict, and the not-too-nice ",," + part? + <youpi> actually I wonder whether using directory access would be nicer + <youpi> i.e. you have a foo.gz, just open foo.gz/gunzip to get the unzipped + content + <youpi> and for foo.img.gz, open foo.img.gz/gunzip/part/1 + <civodul> youpi: because of the interpretation of special chars in file + names + <civodul> users should be free to use any character they like in file names + <civodul> foo.gz/gunzip looks nicer to me + <youpi> ok, so we agree + <youpi> that said, the user could choose the separator + <youpi> the namespace can be not run by root for everybody, but just for + your shell, run by yourself + <antrik> civodul: the user can't use any character anyways... '/' and '\0' + are reserved :-P + <civodul> antrik: '/' isn't quite reserved on the Hurd :-) + <civodul> you could implement dir_lookup such that it does something + special about it + <civodul> (server-side) + <antrik> civodul: as for overloading '/', although I haven't thought it + through entirely, I guess that would work for nodes that present as files + normally. however, it would *not* work for directory nodes + <antrik> which would be quite a serious limitation IMHO + <antrik> I can think of various kinds of useful directory translators + <antrik> what's more, one of the main use cases I originally had in mind is + a policy filter + <antrik> you could pass a directory name with a appropriate filter applied + to tar for example, so it wouldn't try to follow any translators + <antrik> I don't see why taking an obscure prefix like ,, would be much of + a problem in practice anyways + <antrik> (also, it doesn't strictly prevent the user from having such file + names... you just need to escape it if accessing such files through the + namespace multiplexer. though admittedly that would need some special + handling in *some* programs to work properly) diff --git a/community/gsoc/project_ideas/nfs.mdwn b/community/gsoc/project_ideas/nfs.mdwn index 683287f7..d4980279 100644 --- a/community/gsoc/project_ideas/nfs.mdwn +++ b/community/gsoc/project_ideas/nfs.mdwn @@ -1,22 +1,23 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Improved NFS Implementation"]] The Hurd has both NFS server and client implementations, which work, but not -very well: File locking doesn't work properly (at least in conjuction with a +very well: File locking doesn't work properly (at least in conjunction with a GNU/Linux server), and performance is extremely poor. Part of the problems could be owed to the fact that only NFSv2 is supported so far. (Note though that locking on the Hurd is problematic in general, not only in -conjuction with NFS -- see the [[file_locking]] task.) +conjunction with NFS -- see the [[file_locking]] task.) This project encompasses implementing NFSv3 support, fixing bugs and performance problems -- the goal is to have good NFS support. The work done in @@ -31,6 +32,9 @@ has been done for a former GSoC application -- it might give you some pointers. But don't take any of the statements made there for granted -- check the facts yourself! +A bigger subtask is the [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] +issue. + This task, [[!GNU_Savannah_task 5497]], has no special prerequisites besides general programming skills, and an interest in file systems and network protocols. diff --git a/community/gsoc/project_ideas/package_manager.mdwn b/community/gsoc/project_ideas/package_manager.mdwn index 43e53f7c..23304f6b 100644 --- a/community/gsoc/project_ideas/package_manager.mdwn +++ b/community/gsoc/project_ideas/package_manager.mdwn @@ -37,7 +37,7 @@ came about. There are no global databases of any kind. (Some things might require caching for better performance, but this must happen transparently.) The core of this approach is formed by [[hurd/translator/stowfs]], which -creates a traditional unix directory structure from all the files in the +creates a traditional Unix directory structure from all the files in the individual package directories. But this only handles the lowest level of package management. Additional mechanisms are necessary to handle stuff like dependencies on other packages. diff --git a/community/gsoc/project_ideas/perl.mdwn b/community/gsoc/project_ideas/perl.mdwn deleted file mode 100644 index bfe1968e..00000000 --- a/community/gsoc/project_ideas/perl.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -[[!meta copyright="Copyright © 2009 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="Improving Perl Support"]] - -Perl is available on the Hurd, but there are quite a lot of test suite -failures. These could be caused by problems in the system-specific -implementation bits of Perl, and/or shortcomings in the actual system -functionality which Perl depends on. - -The goal of this project is to fix all of these problems if possible, or at -least some of them. Some issues might require digging quite deep into Hurd -internals, while others are probably easy to fix. - -Note that while some Perl knowledge is probably necessary to understand what -the test suite failures are about, the actual work necessary to fix these -issues is mostly C programming -- in the implementation of Perl and/or the -Hurd. - -Possible mentors: Samuel Thibault (youpi) - -Exercise: Make some improvement to Perl support on the Hurd, e.g. fixing one of -the known test suite failures. diff --git a/community/gsoc/project_ideas/perl_python.mdwn b/community/gsoc/project_ideas/perl_python.mdwn new file mode 100644 index 00000000..a51393f1 --- /dev/null +++ b/community/gsoc/project_ideas/perl_python.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 2009, 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 +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="Improving Perl or Python Support"]] + +<!-- See also open_issues/perl and open_issues/python. --> + +Perl and Python are available on the Hurd, but there are quite a lot of test suite +failures. These could be caused by problems in the system-specific +implementation bits of Perl/Python, and/or shortcomings in the actual system +functionality which Perl/Python depends on. + +The student applying for this project can pick either Perl or Python, +whichever he is more comfortable with. +(Perl is higher priority though; and there are more failures too.) + +The goal then is to fix all of the problems with the chosen language if possible, or at +least some of them. Some issues might require digging quite deep into Hurd +internals, while others are probably easy to fix. + +Note that while some Perl/Python knowledge is probably necessary to understand what +the test suite failures are about, the actual work necessary to fix these +issues is mostly C programming -- in the implementation of Perl/Python and/or the +Hurd. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Take a stab at one of the testsuite failures, +and write a minimal testcase exposing the underlying problem. +Actually fixing it would be a bonus of course -- +but as it's hard to predict which issues will be easy and which will be tricky, +we will already be satisfied if the student makes a good effort. +(We hope to see some discussion of the problems in this case though :-) ) diff --git a/community/gsoc/project_ideas/procfs.mdwn b/community/gsoc/project_ideas/procfs.mdwn index 85eec43c..ac5fa6d8 100644 --- a/community/gsoc/project_ideas/procfs.mdwn +++ b/community/gsoc/project_ideas/procfs.mdwn @@ -1,15 +1,25 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2011, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="procfs"]] +[!] Madhusudan.C.S has implemented a new, fully functional +[[procfs|madhusudancs]] as a [[GSoC 2008 project|2008]]. + +[!] This was not the end of the story: [[jkoenig's +`procfs`|hurd/translator/procfs]] is yet another re-written and +improved version. + +--- + Although there is no standard (POSIX or other) for the layout of the `/proc` pseudo-filesystem, it turned out a very useful facility in GNU/Linux and other systems, and many tools concerned with process management use it. (`ps`, `top`, @@ -33,13 +43,10 @@ interfaces.) This project requires learning [[hurd/translator]] programming, and understanding some of the internals of process management in the Hurd. It should not be too hard coding-wise; and the task is very nicely defined by the -exising Linux `/proc` interface -- no design considerations necessary. +existing Linux `/proc` interface -- no design considerations necessary. **Note**: We already have several applications for this task. Possible mentors: Olaf Buddenhagen (antrik) Exercise: Add or fix one piece in the existing procfs translator. - -*Status*: Madhusudan.C.S has implemented a new, fully functional [[procfs|madhusudancs]] for -GSoC 2008. He is still working on some outstanding issues. diff --git a/community/gsoc/project_ideas/pthreads.mdwn b/community/gsoc/project_ideas/pthreads.mdwn index 9c703d36..2270c774 100644 --- a/community/gsoc/project_ideas/pthreads.mdwn +++ b/community/gsoc/project_ideas/pthreads.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,15 +11,18 @@ is included in the section entitled [[!meta title="Convert Hurd Libraries and Servers to pthreads"]] +[[!tag open_issue_libpthread]] + The Hurd was originally created at a time when the [pthreads standard](http://www.opengroup.org/onlinepubs/009695399/basedefs/pthread.h.html) didn't exist yet. Thus all Hurd servers and libraries are using the old [[cthreads|hurd/libcthreads]] package that came with [[microkernel/Mach]], -which is not compatible with [[pthreads|hurd/libpthread]]. +which is not compatible with pthreads. Not only does that mean that people hacking on Hurd internals have to deal with a non-standard thread package, which nobody is familiar with. Although a -pthreads implementation for the Hurd was created in the meantime, it's not +[[pthreads implementation for the Hurd|libpthread]] +was created in the meantime, it's not possible to use both cthreads and pthreads in the same program. Consequently, pthreads can't presently be used in any Hurd servers -- including translators. diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn index a433e8d1..bfaf330b 100644 --- a/community/gsoc/project_ideas/secure_chroot.mdwn +++ b/community/gsoc/project_ideas/secure_chroot.mdwn @@ -1,26 +1,27 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Secure chroot Implementation"]] As the Hurd attempts to be (almost) fully [[UNIX]]-compatible, it also implements a -`chroot()` system call. However, the current implementation is not really +`chroot()` [[system call]]. However, the current implementation is not really good, as it allows easily escaping the `chroot`, for example by use of [[passive_translators|hurd/translator]]. Many solutions have been suggested for this problem -- ranging from simple -workaround changing the behaviour of passive translators in a `chroot`; -changing the context in which passive translators are exectuted; changing the +workaround changing the behavior of passive translators in a `chroot`; +changing the context in which passive translators are executed; changing the interpretation of filenames in a chroot; to reworking the whole passive -translator mechanism. Some involving a completely different approch to -`chroot` implementation, using a proxy instead of a special system call in the +translator mechanism. Some involving a completely different approach to +`chroot` implementation, using a proxy instead of a special [[system call]] in the filesystem servers. See <http://tri-ceps.blogspot.com/2007/07/theory-of-filesystem-relativity.html> @@ -38,7 +39,7 @@ new mechanisms. (Translators.) More important than the actual code is the documentation of what he did: he must be able to defend why he chose a certain approach, and explain why he believes this approach really secure. -Possible mentors: ? +Possible mentors: Carl Fredrik Hammar (cfhammar) Exercise: It's hard to come up with a relevant exercise, as there are so many possible solutions... Probably best to make an improvement to one of the diff --git a/community/gsoc/project_ideas/server_overriding.mdwn b/community/gsoc/project_ideas/server_overriding.mdwn index 42edf287..c35d88de 100644 --- a/community/gsoc/project_ideas/server_overriding.mdwn +++ b/community/gsoc/project_ideas/server_overriding.mdwn @@ -14,7 +14,7 @@ The main idea of the Hurd is that every user can influence almost all system functionality ([[extensible_system|extensibility]]), by running private Hurd servers that replace or proxy the global default implementations. -However, running such a cumstomized subenvironment presently is not easy, +However, running such a customized subenvironment presently is not easy, because there is no standard mechanism to easily replace an individual standard server, keeping everything else. (Presently there is only the [[hurd/subhurd]] method, which creates a completely new system instance with a completely @@ -40,7 +40,7 @@ mechanism would have to check an override table on each lookup, and apply the desired replacement whenever a match is found. Another approach would be server-side overrides. Again there are various -variants. The actual servers themself could provide a mechanism to redirect to +variants. The actual servers themselves could provide a mechanism to redirect to other servers on request. (3) Or we could use some more generic server-side namespace overrides: Either all filesystem servers could provide a mechanism to modify the namespace they export to certain clients (4), or proxies could be @@ -68,7 +68,7 @@ discussing this topic, from a previous year's GSoC application -- see <http://lists.gnu.org/archive/html/bug-hurd/2007-06/msg00082.html>, <http://lists.gnu.org/archive/html/bug-hurd/2008-03/msg00039.html>. -Possible mentors: Olaf Buddenhagen (antrik) +Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar) Exercise: Come up with a glibc patch that allows overriding one specific standard server using method (1). diff --git a/community/gsoc/project_ideas/sound.mdwn b/community/gsoc/project_ideas/sound.mdwn index b92f76da..8411831b 100644 --- a/community/gsoc/project_ideas/sound.mdwn +++ b/community/gsoc/project_ideas/sound.mdwn @@ -36,7 +36,7 @@ Possible mentors: Samuel Thibault (youpi) Exercise: This project requires kernel (driver framework) hacking as well as some Hurd server hacking; so the exercise should involve either of these, or even both. You could for example port some newer driver to run in the existing -framework (see the [[device_driver|driver_glue_code]] project descrption), or +framework (see the [[device_driver|driver_glue_code]] project description), or try to make some fix(es) to the [unfinished random device implementation](http://savannah.gnu.org/patch/?6088) created by Michael Casadevall. diff --git a/community/gsoc/project_ideas/tcp_ip_stack.mdwn b/community/gsoc/project_ideas/tcp_ip_stack.mdwn index b56bff51..331336ac 100644 --- a/community/gsoc/project_ideas/tcp_ip_stack.mdwn +++ b/community/gsoc/project_ideas/tcp_ip_stack.mdwn @@ -21,7 +21,7 @@ more flexibly. Rather than just having the standard socket interface, plus some lower-level hooks for special needs, there are explicit (perhaps filesystem-based) interfaces at all the individual levels; special application can just directly access the desired layer. All kinds of packet filtering, -routing, tunneling etc. can be easily achieved by stacking compononts in the +routing, tunneling etc. can be easily achieved by stacking components in the desired constellation. Implementing a complete modular network stack is not feasible as a GSoC @@ -34,7 +34,7 @@ make such a split later on feasible. This is [[!GNU_Savannah_task 5469]]. -Possible mentors: ? +Possible mentors: zhengda Exercise: You could try making some improvement to the existing pfinet implementation; or you could work towards running some existing userspace diff --git a/community/gsoc/project_ideas/testing_framework.mdwn b/community/gsoc/project_ideas/testing_framework.mdwn new file mode 100644 index 00000000..ff9899d9 --- /dev/null +++ b/community/gsoc/project_ideas/testing_framework.mdwn @@ -0,0 +1,55 @@ +[[!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="Automated Testing Framework"]] + +Hurd development would benefit greatly from automated tests. +Unit tests should be added for all the major components +(Mach; Hurd servers and libraries). +Also, functional tests can be performed on various levels: +Mach; individual servers; and interaction of several servers. + +(The highest level would actually be testing libc functionality, +which in turn uses the various Hurd mechanisms. +glibc already comes with a test suite -- +though it might be desirabe to add some extra tests +for exercising specific aspects of the Hurd...) + +Our page on [[automated testing|open_issues/unit_testing]] collects some relevant material. + +The Goal of this task is to provide testing frameworks +that allow automatically running tests +as part of the Hurd and Mach build processes. +The student will have to create the necessary infrastrucure, +and a couple of sample tests employing it. +Ideally, all the aspects mentioned above should be covered. +At least some have to be ready for use and upstream merging +before the end of the summer. + +(As a bonus, +in addition to these explicit tests, +it would be helpful to integrate some methods +for testing [[locking validity|libdiskfs_locking]], +performing static code analysis etc.) + +This task probably requires some previous experience +with unit testing of C programs, +as well as dealing with complex build systems. +No in-depth knowledge about any specific parts of the Hurd should be necessary, +but some general understanding of the Hurd architecture +will have to be aquired to complete this project. +This makes it a very good project +to get started on Hurd development :-) + +Possible mentors: ? + +Exercise: Create a program performing some simple test(s) on the Hurd or Mach code. +It doesn't need to be integrated in the build process yet -- +a standalone progrem with it's own Makefile is fine for now. diff --git a/community/gsoc/project_ideas/testing_framework/discussion.mdwn b/community/gsoc/project_ideas/testing_framework/discussion.mdwn new file mode 100644 index 00000000..b01d13c3 --- /dev/null +++ b/community/gsoc/project_ideas/testing_framework/discussion.mdwn @@ -0,0 +1,272 @@ +[[!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 +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]] + +freenode, #hurd channel, 2011-03-05: + + <nixness> what about testing though? + <nixness> like sort of "what's missing? lets write tests for it so that + when someone gets to implementing it, he knows what to do. Repeat" + project + <antrik> you mean creating an automated testing framework? + <antrik> this is actually a task I want to add for this year, if I get + around to it :-) + <nixness> yeah I'd very much want to apply for that one + <nixness> cuz I've never done Kernel hacking before, but I know that with + the right tasks like "test VM functionality", I would be able to write up + the automated tests and hopefully learn more about what breaks/makes the + kernel + <nixness> (and it would make implementing the feature much less hand-wavy + and more correct) + <nixness> antrik, I believe the framework(CUnit right?) exists, but we just + need to write the tests. + <antrik> do you have prior experience implementing automated tests? + <nixness> lots of tests! + <nixness> yes, in Java mostly, but I've played around with CUnit + <antrik> ah, great :-) + <nixness> here's what I know from experience: 1) write basic tests. 2) + write ones that test multiple features 3) stress test [option 4) + benchmark and record to DB] + <youpi> well, what we'd rather need is to fix the issues we already know + from the existing testsuites :) + +[[GSoC project propsal|community/gsoc/project_ideas/testsuites]]. + + <nixness> youpi, true, and I think I should check what's available in way + of tests, but if the tests are "all or nothing" then it becomes really + hard to fix your mistakes + <youpi> they're not all or nothing + <antrik> youpi: the existing testsuites don't test specific system features + <youpi> libc ones do + <youpi> we could also check posixtestsuite which does too + +[[open_issues/open_posix_test_suite]]. + + <antrik> AFAIK libc has very few failing tests + +[[open_issues/glibc]]. + + <youpi> err, like twenty? + <youpi> € grep -v '^#' expected-results-i486-gnu-libc | wc -l + <youpi> 67 + <youpi> nope, even more + <antrik> oh, sorry, I confused it with coreutils + <pinotree> plus the binutils ones, i guess + <youpi> yes + +[[open_issues/binutils#weak]]. + + <antrik> anyways, I don't think relying on external testsuites for + regression testing is a good plan + <antrik> also, that doesn't cover unit testing at all + <youpi> why ? + <youpi> sure there can be unit testing at the translator etc. level + <antrik> if we want to implement test-driven development, and/or do serious + refactoring without too much risk, we need a test harness where we can + add specific tests as needed + <youpi> but more than often, the issues are at the libc / etc. level + because of a combination o fthings at the translator level, which unit + testing won't find out + * nixness yewzzz! + <nixness> sure unit testing can find them out. if they're good "unit" tests + <youpi> the problem is that you don't necessarily know what "good" means + <youpi> e.g. for posix correctness + <youpi> since it's not posix + <nixness> but if they're composite clever tests, then you lose that + granularity + <nixness> youpi, is that a blackbox test intended to be run at the very end + to check if you're posix compliant? + <antrik> also, if we have our own test harness, we can run tests + automatically as part of the build process, which is a great plus IMHO + <youpi> nixness: "that" = ? + <nixness> oh nvm, I thought there was a test stuie called "posix + correctness" + <youpi> there's the posixtestsuite yes + <youpi> it's an external one however + <youpi> antrik: being external doesn't mean we can't invoke it + automatically as part of the build process when it's available + <nixness> youpi, but being internal means it can test the inner workings of + certain modules that you are unsure of, and not just the interface + <youpi> sure, that's why I said it'd be useful too + <youpi> but as I said too, most bugs I've seen were not easy to find out at + the unit level + <youpi> but rather at the libc level + <antrik> of course we can integrate external tests if they exist and are + suitable. but that that doesn't preclude adding our own ones too. in + either case, that integration work has to be done too + <youpi> again, I've never said I was against internal testsuite + <antrik> also, the major purpose of a test suite is checking known + behaviour. a low-level test won't directly point to a POSIX violation; + but it will catch any changes in behaviour that would lead to one + <youpi> what I said is that it will be hard to write them tight enough to + find bugs + <youpi> again, the problem is knowing what will lead to a POSIX violation + <youpi> it's long work + <youpi> while libc / posixtestsuite / etc. already do that + <antrik> *any* unexpected change in behaviour is likely to cause bugs + somewher + <youpi> but WHAT is "expected" ? + <youpi> THAT is the issue + <youpi> and libc/posixtessuite do know that + <youpi> at the translator level we don't really + <youpi> see the recent post about link() + +[link(dir,name) should fail with +EPERM](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00007.html) + + <youpi> in my memory jkoenig pointed it out for a lot of such calls + <youpi> and that issue is clearly not known at the translator level + <nixness> so you're saying that the tests have to be really really + low-level, and work our way up? + <youpi> I'm saying that the translator level tests will be difficult to + write + <antrik> why isn't it known at the translator level? if it's a translator + (not libc) bug, than obviously the translator must return something wrong + at some point, and that's something we can check + <youpi> because you'll have to know all the details of the combinations + used in libc, to know whether they'll lead to posix issues + <youpi> antrik: sure, but how did we detect that that was unexpected + behavior? + <youpi> because of a glib test + <youpi> at the translator level we didn't know it was an unexpected + behavior + <antrik> gnulib actually + <youpi> and if you had asked me, I wouldn't have known + <antrik> again, we do *not* write a test suite to find existing bugs + <youpi> right, took one for the other + <youpi> doesn't really matter actually + <youpi> antrik: ok, I don't care then + <antrik> we write a test suite to prevent future bugs, or track status of + known bugs + <youpi> (don't care *enough* for now, I mean) + <nixness> hmm, so write something up antrik for GSoC :) and I'll be sure to + apply + <antrik> now that we know some translators return a wrong error status in a + particular situation, we can write a test that checks exactly this error + status. that way we know when it is fixed, and also when it breaks again + <antrik> nixness: great :-) + <nixness> sweet. that kind of thing would also need a db backend + <antrik> nixness: BTW, if you have a good idea, you can send an application + for it even if it's not listed among the proposed tasks... + <antrik> so you don't strictly need a writeup from me to apply for this :-) + <nixness> antrik, I'll keep that in mind, but I'll also be checking your + draft page + <nixness> oh cool :) + <antrik> (and it's a well known fact that those projects which students + proposed themselfs tend to be the most successful ones :-) ) + * nixness draft initiated + <antrik> youpi: BTW, I'm surprised that you didn't mention libc testsuite + before... working up from there is probably a more effective plan than + starting with high-level test suites like Python etc... + <youpi> wasn't it already in the gsoc proposal? + <youpi> bummer + <antrik> nope + +freenode, #hurd channel, 2011-03-06: + + <nixness> how's the hurd coding workflow, typically? + +*nixness* -> *foocraft*. + + <foocraft> we're discussing how TDD can work with Hurd (or general kernel + development) on #osdev + <foocraft> so what I wanted to know, since I haven't dealt much with GNU + Hurd, is how do you guys go about coding, in this case + <tschwinge> Our current workflow scheme is... well... is... + <tschwinge> Someone wants to work on something, or spots a bug, then works + on it, submits a patch, and 0 to 10 years later it is applied. + <tschwinge> Roughly. + <foocraft> hmm so there's no indicator of whether things broke with that + patch + <foocraft> and how low do you think we can get with tests? A friend of mine + was telling me that with kernel dev, you really don't know whether, for + instance, the stack even exists, and a lot of things that I, as a + programmer, can assume while writing code break when it comes to writing + kernel code + <foocraft> Autotest seems promising + +See autotest link given above. + + <foocraft> but in any case, coming up with the testing framework that + doesn't break when the OS itself breaks is hard, it seems + <foocraft> not sure if autotest isolates the mistakes in the os from + finding their way in the validity of the tests themselves + <youpi> it could be interesting to have scripts that automatically start a + sub-hurd to do the tests + +[[hurd/subhurd#unit_testing]]. + + <tschwinge> foocraft: To answer one of your earlier questions: you can do + really low-level testing. Like testing Mach's message passing. A + million times. The questions is whether that makes sense. And / or if + it makes sense to do that as part of a unit testing framework. Or rather + do such things manually once you suspect an error somewhere. + <tschwinge> The reason for the latter may be that Mach IPC is already + heavily tested during normal system operation. + <tschwinge> And yet, there still may be (there are, surely) bugs. + <tschwinge> But I guess that you have to stop at some (arbitrary?) level. + <foocraft> so we'd assume it works, and test from there + <tschwinge> Otherwise you'd be implementing the exact counter-part of what + you're testing. + <tschwinge> Which may be what you want, or may be not. Or it may just not + be feasible. + <foocraft> maybe the testing framework should have dependencies + <foocraft> which we can automate using make, and phony targets that run + tests + <foocraft> so everyone writes a test suite and says that it depends on A + and B working correctly + <foocraft> then it'd go try to run the tests for A etc. + <tschwinge> Hmm, isn't that -- on a high level -- have you have by + different packages? For example, the perl testsuite depends (inherently) + on glibc working properly. A perl program's testsuite depends on perl + working properly. + <foocraft> yeah, but afaik, the ordering is done by hand + +freenode, #hurd channel, 2011-03-07: + + <antrik> actually, I think for most tests it would be better not to use a + subhurd... that leads precisely to the problem that if something is + broken, you might have a hard time running the tests at all :-) + <antrik> foocraft: most of the Hurd code isn't really low-level. you can + use normal debugging and testing methods + <antrik> gnumach of course *does* have some low-level stuff, so if you add + unit tests to gnumach too, you might run into issues :-) + <antrik> tschwinge: I think testing IPC is a good thing. as I already said, + automated testing is *not* to discover existing but unknown bugs, but to + prevent new ones creeping in, and tracking progress on known bugs + <antrik> tschwinge: I think you are confusing unit testing and regression + testing. http://www.bddebian.com/~hurd-web/open_issues/unit_testing/ + talks about unit testing, but a lot (most?) of it is actually about + regression tests... + <tschwinge> antrik: That may certainly be -- I'm not at all an expert in + this, and just generally though that some sort of automated testing is + needed, and thus started collecting ideas. + <tschwinge> antrik: You're of course invited to fix that. + +IRC, freenode, #hurd, 2011-03-08 + +(After discussing the [[open_issues/anatomy_of_a_hurd_system]].) + + <antrik> so that's what your question is actually about? + <foocraft> so what I would imagine is a set of only-this-server tests for + each server, and then we can have fun adding composite tests + <foocraft> thus making debugging the composite scenarios a bit less tricky + <antrik> indeed + <foocraft> and if you were trying to pass a composite test, it would also + help knowing that you still didn't break the server-only test + <antrik> there are so many different things that can be tested... the + summer will only suffice to dip into this really :-) + <foocraft> yeah, I'm designing my proposal to focus on 1) make/use a + testing framework that fits the Hurd case very well 2) write some tests + and docs on how to write good tests + <antrik> well, doesn't have to be *one* framework... unit testing and + regression testing are quite different things, which can be covered by + different frameworks diff --git a/community/gsoc/project_ideas/testsuites.mdwn b/community/gsoc/project_ideas/testsuites.mdwn new file mode 100644 index 00000000..9ca6fe3e --- /dev/null +++ b/community/gsoc/project_ideas/testsuites.mdwn @@ -0,0 +1,62 @@ +[[!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 +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="Fix Compatibility Problems Exposed by Testsuites"]] + +A number of software packages come with extensive testsuites. +Some notable ones are [[open_issues/glibc]], gnulib, Perl, +Python, GNU Coreutils, and glib. +While these testsuites were written mostly to track regressions in the respective packages, +some of the tests fail on the Hurd in general. + +There is also the [[Open POSIX Testsuite|open_issues/open_posix_test_suite]] +which is more of a whole system interface testing suite. + +Then, there is the [[open_issues/File_System_Exerciser]] which we can use to +test our file system servers for conformity. + +While in some cases these might point to wrong usage of system interfaces, +most of the time such failures are actually caused by shortcomings in Hurd's implementation of these interfaces. +These shortcomings are often not obvious in normal use, +but can be directly or indirectly responsible for all kinds of failures. +The testsuites help in isolating such problems, +so they can be tracked down and fixed. + +This task thus consists in running some of the mentioned testsuites +(and/or any other ones that come to mind), +and looking into the causes of failures. +The goal is to analyze all failures in one or more of the listed testsuites, +to find out what shortcomings in the Hurd implementation cause them (if any), +and to fix at least some of these shortcomings. + +Note that this task somewhat overlaps with the [[Perl/Python task|perl_python]] listed above. +Here the focus however is not on improving the support for any particular program, +but on fixing general problems in the Hurd. + +This is a very flexible task: +while less experienced students should be able to tackle at least a few of the easier problems, +other issues will be challenging even for experienced hackers. +No specific previous knowledge is required for this task; +only fairly decent C programming skills. +While tracking down the various issues, +the student will be digging into the inner workings of the Hurd, +and thus gradually gaining the knowledge required for Hurd development in general. + +A complementary task is adding a proper [[open_issues/unit_testing]] framework +to the GNU Hurd's code base, and related packages. + +Possible mentors: Samuel Thibault (youpi) + +Exercise: Take a stab at one of the testsuite failures, +and write a minimal testcase exposing the underlying problem. +Actually fixing it would be a bonus of course -- +but as it's hard to predict which issues will be easy and which will be tricky, +we will already be satisfied if the student makes a good effort. +(We hope to see some discussion of the problems in this case though :-) ) diff --git a/community/gsoc/project_ideas/tmpfs.mdwn b/community/gsoc/project_ideas/tmpfs.mdwn index 69adef0f..c38c6da8 100644 --- a/community/gsoc/project_ideas/tmpfs.mdwn +++ b/community/gsoc/project_ideas/tmpfs.mdwn @@ -1,21 +1,27 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Fix tmpfs"]] +[!] [[Maksym_Planeta]] has been making good progress here; status is tracked at +[[here|hurd/translator/tmpfs/discussion]]. + +--- + In some situations it is desirable to have a file system that is not backed by actual disk storage, but only by anonymous memory, i.e. lives in the RAM (and possibly swap space). A simplistic way to implement such a memory filesystem is literally creating a -ramdisk, i.e. simply allocating a big chunck of RAM (called a memory store in +ramdisk, i.e. simply allocating a big chunk of RAM (called a memory store in Hurd terminology), and create a normal filesystem like ext2 on that. However, this is not very efficient, and not very convenient either (the filesystem needs to be recreated each time the ramdisk is invoked). A nicer solution is @@ -37,7 +43,7 @@ implementation. It requires digging into some parts of the Hurd, including the [[pager_interface|hurd/libpager]] and [[hurd/translator]] programming. This task probably doesn't require any design work, only good debugging skills. -Possible mentors: ? +Possible mentors: Carl Fredrik Hammar (cfhammar) Exercise: Take a look at tmpfs and try to fix one of the existing issues. Some of them are probably not too tricky; or you might discover something else you diff --git a/community/gsoc/project_ideas/unionfs_boot.mdwn b/community/gsoc/project_ideas/unionfs_boot.mdwn index a801290f..d9f1a9e1 100644 --- a/community/gsoc/project_ideas/unionfs_boot.mdwn +++ b/community/gsoc/project_ideas/unionfs_boot.mdwn @@ -11,7 +11,7 @@ is included in the section entitled [[!meta title="Allow Using unionfs Early at Boot"]] In [[UNIX]] systems, traditionally most software is installed in a common directory -hierachy, where files from various packages live beside each other, grouped by +hierarchy, where files from various packages live beside each other, grouped by function: user-invokable executables in `/bin`, system-wide configuration files in `/etc`, architecture specific static files in `/lib`, variable data in `/var`, and so on. To allow clean installation, deinstallation, and upgrade of @@ -42,4 +42,4 @@ Completing this task will require gaining a very good understanding of the Hurd boot process and other parts of the design. It requires some design skills also to come up with a working mechanism. -Possible mentors: ? +Possible mentors: Carl Fredrik Hammar (cfhammar) diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn new file mode 100644 index 00000000..e9e94857 --- /dev/null +++ b/community/gsoc/project_ideas/valgrind.mdwn @@ -0,0 +1,83 @@ +[[!meta copyright="Copyright © 2009, 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 +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="Porting Valgrind to the Hurd"]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +[Valgrind](http://valgrind.org/) is an extremely useful debugging tool for memory errors. +(And some other kinds of hard-to-find errors too.) +Aside from being useful for program development in general, +a Hurd port will help finding out why certain programs segfault on the Hurd, +although they work on Linux. +Even more importantly, it will help finding bugs in the Hurd servers themselfs. + +To keep track of memory use, +Valgrind however needs to know how each [[system call]] affects the validity of memory regions. +This knowledge is highly kernel-specific, +and thus Valgrind needs to be explicitely ported for every system. + +Such a port involves two major steps: +making Valgrind understand how kernel traps work in general on the system in question; +and how all the individual kernel calls affect memory. +The latter step is where most of the work is, +as the behaviour of each single [[system call]] needs to be described. + +Compared to Linux, +[[microkernel/Mach]] (the microkernel used by the Hurd) has very few kernel traps. +Almost all [[system call]]s are implemented as [[RPC]]s instead -- +either handled by Mach itself, or by the various [[Hurd servers|hurd/translator]]. +All RPCs use a pair of `mach_msg()` invocations: +one to send a request message, and one to receive a reply. +However, while all RPCs use the same `mach_msg()` trap, +the actual effect of the call varies greatly depending on which RPC is invoked -- +similar to the `ioctl()` call on Linux. +Each request thus must be handled individually. + +Unlike `ioctl()`, +the RPC invocations have explicit type information for the parameters though, +which can be retrieved from the message header. +By analyzing the parameters of the RPC reply message, +Valgrind can know exactly which memory regions are affected by that call, +even without specific knowledge of the RPC in question. +Thus implementing a general parser for the reply messages +will already give Valgrind a fairly good approximation of memory validity -- +without having to specify the exact semantic of each RPC by hand. + +While this should make Valgrind quite usable on the Hurd already, it's not perfect: +some RPCs might return a buffer that is only partially filled with valid data; +or some reply parameters might be optional, +and only contain valid data under certain conditions. +Such specific semantics can't be deduced from the message headers alone. +Thus for a complete port, +it will still be necessary to go through the list of all known RPCs, +and implement special handling in Valgrind for those RPCs that need it. + +The goal of this task is at minimum to make Valgrind grok Mach traps, +and to implement the generic RPC handler. +Ideally, specific handling for RPCs needing it should also be implemented. + +Completing this project will require digging into Valgrind's handling of [[system call]]s, +and into Hurd RPCs. +It is not an easy task, but a fairly predictable one -- +there shouldn't be any unexpected difficulties, +and no major design work is necessary. +It doesn't require any specific previous knowledge: +only good programming skills in general. +On the other hand, +the student will obtain a good understanding of Hurd RPCs while working on this task, +and thus perfect qualifications for Hurd development in general :-) + +Possible mentors: Samuel Thibault (youpi) + +Exercise: As a starter, +students can try to teach valgrind a couple of Linux ioctls, +as this will make them learn how to use the read/write primitives of valgrind. diff --git a/community/gsoc/project_ideas/virtualization.mdwn b/community/gsoc/project_ideas/virtualization.mdwn index c7403f70..bd67718b 100644 --- a/community/gsoc/project_ideas/virtualization.mdwn +++ b/community/gsoc/project_ideas/virtualization.mdwn @@ -25,18 +25,18 @@ desired constellations. The goal is to create a set of powerful tools for managing at least one desirable virtualization scenario. One possible starting point could be the [[hurd/subhurd]]/[[hurd/neighborhurd]] mechanism, which allows a second almost totally -independant instance of the Hurd in parallel to the main one. +independent instance of the Hurd in parallel to the main one. While subhurd allow creating a complete second system instance, with an own set of Hurd servers and [[UNIX]] daemons and all, there are also situations where it is -desirable to have a smaller subenvironment, living withing the main system and +desirable to have a smaller subenvironment, living within the main system and using most of its facilities -- similar to a chroot environment. A simple way to create such a subenvironment with a single command would be very helpful. It might be possible to implement (perhaps as a prototype) a wrapper using existing tools (chroot and [[hurd/translator/unionfs]]); or it might require more specific tools, -like some kind of unionfs-like filesytem proxy that mirrors other parts of the -filesystem, but allows overriding individual locations, in conjuction with +like some kind of unionfs-like filesystem proxy that mirrors other parts of the +filesystem, but allows overriding individual locations, in conjunction with either chroot or some similar mechanism to create a subenvironment with a different root filesystem. @@ -73,4 +73,4 @@ Completing this project will require gaining a very good understanding of the Hurd architecture and spirit. Previous experience with other virtualization solutions would be very helpful. -Possible mentors: Olaf Buddenhagen (antrik) +Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar) diff --git a/community/gsoc/project_ideas/vm_tuning.mdwn b/community/gsoc/project_ideas/vm_tuning.mdwn index 9e802188..ecc5f9f4 100644 --- a/community/gsoc/project_ideas/vm_tuning.mdwn +++ b/community/gsoc/project_ideas/vm_tuning.mdwn @@ -14,7 +14,7 @@ Hurd/[[microkernel/Mach]] presently make very bad use of the available physical system. Some of the problems are inherent to the system design (the kernel can't distinguish between important application data and discardable disk buffers for example), and can't be fixed without fundamental changes. Other -problems however are an ordinary lack of optimisation, like extremely crude +problems however are an ordinary lack of optimization, like extremely crude heuristics when to start paging. (See <http://lists.gnu.org/archive/html/bug-hurd/2007-08/msg00034.html> for example.) Many parameters are based on assumptions from a time when typical machines had like 16 MiB of RAM, or simply have been set to @@ -23,7 +23,7 @@ arbitrary values and never tuned for actual use. The goal of this project is to bring the virtual memory management in Hurd/Mach closer to that of modern mainstream kernels (Linux, FreeBSD), by comparing the implementation to other systems, implementing any worthwhile improvements, and -general optimisation/tuning. It requires very good understanding of the Mach +general optimization/tuning. It requires very good understanding of the Mach VM, and virtual memory in general. This project is related to [[!GNU_Savannah_task 5489]]. diff --git a/community/gsoc/project_ideas/xattr.mdwn b/community/gsoc/project_ideas/xattr.mdwn index 55961547..8ec4c42e 100644 --- a/community/gsoc/project_ideas/xattr.mdwn +++ b/community/gsoc/project_ideas/xattr.mdwn @@ -21,7 +21,7 @@ fields in the inode to store Hurd-specific metadata: most notable passive translator settings. As these fields are Hurd-specific, they can't be accessed by the standard methods from Linux for example, so it's not possible to fully work with a Hurd filesystem on GNU/Linux (copy, backup etc.); and also, even -when on Hurd, only tools that explicitely support the Hurd-specific information +when on Hurd, only tools that explicitly support the Hurd-specific information can handle them. Using extended attributes instead of custom fields for the Hurd-specific @@ -38,8 +38,8 @@ Completing this project will require digging into some parts of the Hurd, but it should be quite doable without previous Hurd experience. Some experience with xattrs might help a bit, but shouldn't be really necessary either. -Some previous work on xattr support is available in [[!GNU_Savannah_patch -5126]], and might serve as a starting point. +Some previous work on xattr support is [[available|open_issues/xattr]], and +might serve as a starting point. Possible mentors: Samuel Thibault (youpi) diff --git a/community/gsoc/student_application_form.mdwn b/community/gsoc/student_application_form.mdwn index 84070cbf..ba339dc9 100644 --- a/community/gsoc/student_application_form.mdwn +++ b/community/gsoc/student_application_form.mdwn @@ -21,7 +21,8 @@ title yourself of course -- but surely this isn't hard, if you were able to come up with your own project idea :-) Submitting the application form is only part of the deal: we expect a few other -things on top of that. Lacking these, the application is not complete, and we +things on top of that, as explained below. This is important, so please take +it seriously -- without these things, the application is not complete, and we won't consider it. One of the things we expect is that you contact us directly as soon as possible @@ -30,41 +31,44 @@ One of the things we expect is that you contact us directly as soon as possible in particular allows for very informal conversations. (Note though that we are not all in the same time zone, and people generally -don't stare at the IRC screen all the time -- it can take quite a long time -until somebody replies: even several hours. Don't get discouraged by that: Just +don't stare at the IRC screen all the time: it can take quite a long time +until somebody replies -- even several hours. Don't get discouraged by that. Just be patient and hang on, or try again later.) Contacting us as soon as possible is crucial, as regular communication is the single most important factor for a successful GSoC project. We need to see that -you are able and willing to talk to us regularily. Also it allows us getting to -know you much better than the application form alone could. +you are able and willing to talk to us regularly. Also, we get to +know you much better this way than what the application form alone would allow us to. -You shouldn't be at a loss for reason to contact us. You ought to discuss your -project and application with us for exmple: You will gain a much better idea -about the project, our expectations etc. -- in short, you will be able to -submit a better application right from the beginnig, saving both yourself and -us some tedious roundtrips :-) +You shouldn't be at a loss for reasons to contact us. You ought to discuss your +project and application with us for example -- you will gain a much better idea +about the project, our expectations etc. In short, you will be able to +submit a better application right from the beginning, saving both yourself and +us some tedious round trips :-) Also, if you really want to get involved with the Hurd project, there are -surely many things you will want to know :-) All in all, you should have ample +surely many things you will want to know -- after all, it's a fascinating +project, with a fascinating architecture etc., right? :-) + +All in all, you should have ample causes to get in touch during the application period. Bonus points if you also participate in discussions not directly related to your project. The other thing necessary to complete your application is making a change to -some part of the Hurd code, and submitting a patch with the change. (If you are +some part of the Hurd code, and submitting a patch implementing that change. (If you are not sure what that means, ask us!) This is important, as it shows that you have everything set up to start hacking -on the project (source code, tool chain, testing environment etc.), and that -you have all kinds of qualifications necessary to successfully finish the -project: general programming abilities; working in the Hurd environment; +on the project (source code, tool chain, testing environment etc.); and that +you have all kinds of qualifications necessary to successfully finish your +project: general programming skills; working in the Hurd environment; submitting patches and reacting to feedback; finding and/or asking for any information you need; and so on. Don't get us wrong: We absolutely do *not* demand that you have and know all this up front. After all, the idea of GSoC is to *introduce* you to free software development in general, and to our project specifically :-) We are -willing to help you with anything you will need to create the patch -- you just +eager to help you with anything you will need to create the patch -- you just need to ask! We actively encourage you to contact us whenever you have any doubts. Don't be @@ -72,7 +76,7 @@ afraid that we will think worse of you when you ask too much. On the contrary: this is an occasion for you to show us that whenever there is something you don't know yet, you are able to learn quickly, and know how to ask for help :-) -As for the kind of change we want: Ideally, it would be some real improvement +As for the kind of change we want: ideally, it would be some real improvement (bug fix or new feature) in a part of the Hurd related to the specific project you want to work on. (This is not always possible though -- in that case, a useful change to some unrelated part of the Hurd would also do, or perhaps some @@ -101,9 +105,17 @@ you are unsure about something. And now that you are prepared to face the enemy, here we go :-) +* Please supply your contact information here: full name, email address, IRC +nick, Jabber ID, phone number, etc. -- anything we might need to recognize you +and to keep in touch. + +* Introduce yourself: who are you, where are you from, what do you do, how did +you get here... Don't write a long essay here -- just a bunch of basic facts +you think we should know, so we get some idea whom we are talking to :-) + * Please describe the task of the project you want to work on, in your own words. Be as specific as possible. It's not sufficient to rephrase the -description from the project ideas page; show us that you actually understand +description from the project ideas page -- show us that you actually understand what this task involves! Read the available documentation (and possibly code) if necessary. And don't hesitate to ask us if you have any doubts :-) @@ -116,7 +128,7 @@ ready to be merged to mainline. Experience shows that adding the "final touches" necessary for that, tends to take up quite a lot of time -- there are always some bugs here and there, some misunderstandings about how things are supposed to work, build system issues, missing documentation, forgotten bits, -and so on. Thus, the schedule should suppose that a larger part of the main +and so on. Thus, the schedule should assume that a larger part of the main implementation work will be done by midterm! Also note that by the beginning of the summer session, you need to be able to @@ -162,12 +174,12 @@ the application process. * Do you have a permanent internet connection, especially during the time of the summer session? Are you able and willing to hang out on the Hurd IRC -channel regularily? (As in: Running the IRC client more or less permanently and +channel regularly? (As in: Running the IRC client more or less permanently and checking for activity now and then.) If it turns out that your mentor lives in a different time zone, could you shift your day/night rhythm to better match that of your mentor and other Hurd developers? -Hint: Hanging out on the channel regularily during the application process +Hint: Hanging out on the channel regularly during the application process would be a good start :-) * When does your university term end, when are your exams, and when does the @@ -190,8 +202,8 @@ intend to make sure you will be able to dedicate sufficient time to your project nevertheless? Please be open about this, and also mention things you are not yet sure about. -We can be flexible about time arrangements; but we need to know about any -possible obstacles up front. +We can be flexible about time arrangements; but we absolutely need to know about any +possible obstacles up front. Surprises on that score are not acceptable. * How do you intend to make sure that your code will keep on being maintained and supported properly after the end of the GSoC program? diff --git a/community/gsoc/xorg_ideas.mdwn b/community/gsoc/xorg_ideas.mdwn index 406d370d..26177345 100644 --- a/community/gsoc/xorg_ideas.mdwn +++ b/community/gsoc/xorg_ideas.mdwn @@ -8,51 +8,11 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -## libpciaccess Support for GNU Hurd - -xserver 1.5 introduces libpciaccess as a new method for handling PCI devices. -The purpose was to get rid of the messy old PCI code in the server, instead -using a new implementation that is encapsulated in a library, and uses external -PCI access interfaces provided by the operating systems. - -As libpciaccess is written from scratch, support for various operating systems -needs to be reimplemented individually, writing specific backends for each. -This task is about creating such a backend for GNU Hurd. - -Writing a "proper" native backend for the Hurd is rather involved, as there is -no kernel PCI interface so far -- it has to be created first. It would also -have the disadvantage of being somewhat tied to the specific driver framework: -The present framework is pretty dated (using some ancient Linux drivers with a -layer of glue code); and when this is replaced, the PCI interface will have to -be updated as well. - -Alternatively, a libpciaccess backend simply doing old-style register poking -from user space could be implemented. (Either from scratch, or by reusing some -existing PCI code from the old server or some BSD kernel.) That approach is not -as elegant; it would be somewhat fragile and limited, like the old PCI code in -the server. On the other hand, it is much simpler to implement; and it would -also benefit other non-mainstream platforms that can't afford -creating/maintaining a native backend. - -The goal of this project is getting a recent xorg server, using libpciaccess, -to run on the Hurd. - -This task probably doesn't require any previous X programming knowledge, though -a bit of experience with PCI programming will probably help. Some Hurd-specific -knowledge will have to be obtained while working on it -- especially if -implementing a proper kernel PCI interface. The task is pretty involved in the -latter case, but shouldn't be too hard if taking the user space register poking -approach. - -Exercise: Implement a stub backend for libpciaccess, which doesn't really do -anything useful, but compiles fine on the Hurd. - - ## VT Switching for GNU Hurd While XFree86 was first ported to the Hurd more than a decade ago, and there -are updates now and then to make newer versions of Xorg run as well (see also -the libpciaccess task), the support is quite rudimentary: in particular, there +are updates now and then to make newer versions of Xorg run as well, +the support is quite rudimentary: in particular, there is no support for switching back to the text console while X is running. Implementing this requires creating an interface between the X server and the @@ -74,7 +34,7 @@ The Direct Rendering Manager (DRM) is a kernel driver component taking care of graphics hardware access. Originally, it only took care of the 3D acceleration unit, and was used mostly by the DRI (Direct Rendering Infrastructure) in Mesa. -About two years ago, the developers came to the conclusion that a more robust +A few years ago, the developers came to the conclusion that a more robust and functional graphics stack requires the kernel driver to take care of other graphics access as well: mode setting in particular. (Essentially what the old KGI project proposed, see <http://www.kgi-project.org>.) Also, with the new GEM @@ -90,7 +50,7 @@ microkernel idea -- we want to run the drivers as priviledged user space server processes, rather than actual kernel modules. This task is about doing the first steps for porting the DRM to the Hurd. This -can be done by taking one of the existing DRM modesetting drivers (Intel or +can be done by taking one of the existing DRM modesetting drivers (Intel, Nouveau (Nvidia), or Radeon), trying to get parts of it running as a Hurd server, and porting/implementing necessary pieces of the general DRM framework as needed along the way. diff --git a/community/meetings.mdwn b/community/meetings.mdwn index 9c88418e..19c5a533 100644 --- a/community/meetings.mdwn +++ b/community/meetings.mdwn @@ -1,22 +1,34 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Meetings with Hurd developer attendance"]] # Upcoming + +## In the Future + + * [[GNU Hackers Meeting, 2012, Düsseldorf|ghm2012]] * [[Self-organised]] + # Past + * [[FOSDEM_2012]] + * [[FrOSCon_2011]] + * [[GNU Hackers Meeting, 2011, Paris|ghm2011]] + * [[FOSDEM_2011]] + * [[DebConf10]] + * [[GNU Hackers Meeting, 2010, Den Haag|ghm2010]] + * [[FOSDEM_2010]] * [[EuroSys_2009]] * [[FOSDEM_2008]] * [[Weekend_at_stesie's|stesie_2007-10-12]] diff --git a/community/meetings/debconf10.mdwn b/community/meetings/debconf10.mdwn new file mode 100644 index 00000000..3b83a8cc --- /dev/null +++ b/community/meetings/debconf10.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="DebConf10"]] + +<http://debconf10.debconf.org/> + + * {{$banck_hurd}} + + +[[!ymlfront data=""" + +banck_hurd: + + "presentation (including video) by Michael Banck: [*Debian GNU/Hurd -- Past. + Present. And + Future?*](http://penta.debconf.org/dc10_schedule/events/595.en.html) + ([slides](http://people.debian.org/~mbanck/debian-hurd.pdf))" + +"""]] diff --git a/community/meetings/fosdem_2010.mdwn b/community/meetings/fosdem_2010.mdwn new file mode 100644 index 00000000..9def3c1c --- /dev/null +++ b/community/meetings/fosdem_2010.mdwn @@ -0,0 +1,86 @@ +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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="FOSDEM 2010"]] + +<http://fosdem.org/2010> + +FOSDEM will take place on February 6th/7th at the Université Libre de +Bruxelles. + + +# Who And When + +[[!table class="table_style_1" data=""" +"Name","Attending","Arrival","Return","Share room with us" +"Anatoly A. Kazantsev","no","","","" +"Andrei Barbu","no","","","" +"Arne Babenhauserheide","no","","","" +"[[Bas Wijnen|baswijnen]]","Yes","Friday evening","Sunday afternoon","no" +"Ben Asselstine","yes","?","?","yes (but no dates confirmed)" +"Carl Fredrik Hammar","no","","","" +"Colin Leitner","no","","","" +"Emilio Pozuelo Monfort","probably not","","","" +"Flavio Cruz","no","","","" +"[[Gianluca Guida|GianlucaGuida]]","yes","Fr.","Mo.","yes" +"Guillem Jover","no","","","" +"Madhusudan C.S.","?","","","" +"Marcus Brinkmann","yes","fr","mo","yes" +"[[Michael Banck|MichaelBanck]]","yes","Fr., early afternoon","Su., night","yes" +"Neal Walfield","yes","Fr","Mo","yes" +"Olaf Buddenhagen","yes","fr","mo","yes" +"Pino Toscano","no","","","" +"[[Samuel Thibault|SamuelThibault]]","no","","","" +"Sergiu Ivanov","no","","","" +"[[Soeren Schulze|SoerenSchulze]]","yes","Fr","Mo","yes" +"[[Stefan Siegl|stesie]]","no","","","" +"[[Thomas Schwinge|tschwinge]]","yes","Fr., 10:35","Mo., 18:25","yes" +"Vasily Sartakov","maybe","","","" +"Zheng Da","no","","","" +"""]] + + +# Where (Accommodation) + +This year, we'll stay in the [Hotel Astrid](http://www.astridhotel.be/), +together with the FSFE folks. The following data (without Ben's) has been +forwarded to them: + +[[!table class="table_style_1" data=""" + , Ben , Gianluca, Marcus, Michael, Neal, Olaf, Thomas, Total +Fri 5, **?**, 1 , 1 , 1 , 1 , 1 , 1 , 6 +Sat 6, **?**, 1 , 1 , 1 , 1 , 1 , 1 , 6 +Sun 7, **?**, 1 , 1 , , 1 , 1 , 1 , 5 +"""]] + + +# What + +On Saturday, Bas will be giving a [talk about *Iris*, his new +kernel](http://fosdem.org/2010/schedule/events/emb_iris) (Sat., 18:00, Embedded +Developer Room). + +On Sunday, one can join the other folks at the [Alt-OS Developer +Room](http://fosdem.org/2010/schedule/devrooms/altos) (also see the [Haiku +FOSDEM2010AltOSDevroomSchedule +page](http://dev.haiku-os.org/wiki/FOSDEM2010AltOSDevroomSchedule)) where at +least some of us will [spend their +time](http://lists.gnu.org/archive/html/bug-hurd/2009-12/msg00080.html). + +At this very place, Olaf will be giving two presentations: [*Why is Anyone +Still Working on the GNU +Hurd?*](http://fosdem.org/2010/schedule/events/altos_hurd) (Sun., 10:30, Alt-OS +Developer Room), and [*Porting KGI graphics drivers from Linux to GNU +Hurd*](http://fosdem.org/2010/schedule/events/altos_kgi_hurd) (Sun., 13:00, +Alt-OS Developer Room). + +There'll be further GNU folks around; [Mini GNU Hackers Meeting at FOSDEM +Brussels 2010](http://www.gnu.org/ghm/2010/fosdem/). diff --git a/community/meetings/fosdem_2011.mdwn b/community/meetings/fosdem_2011.mdwn new file mode 100644 index 00000000..8522e10f --- /dev/null +++ b/community/meetings/fosdem_2011.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 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 +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="FOSDEM 2011"]] + +<http://fosdem.org/2011> + +FOSDEM will take place on February 5th/6th at the Université Libre de +Bruxelles. + + +# Who and When + +[[!table class="table_style_1" data=""" +"Name","Attending","Arrival","Return","Share room with us" +"Emilio Pozuelo Monfort","yes"," "," "," " +"Marcus Brinkmann","yes"," "," "," " +"Michael Banck","yes"," "," "," " +"Neal Walfield","yes","Friday noon","Monday noon","yes" +"Richard Braun","no","n/a","n/a","n/a" +"[[Thomas Schwinge|tschwinge]]","no","n/a","n/a","n/a" +"Wouter van Heyst","yes"," "," "," " +"""]] + + +# What + +<http://lists.gnu.org/archive/html/bug-hurd/2010-12/msg00019.html> diff --git a/community/meetings/fosdem_2012.mdwn b/community/meetings/fosdem_2012.mdwn new file mode 100644 index 00000000..8143e236 --- /dev/null +++ b/community/meetings/fosdem_2012.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010, 2011, 2012 Free +Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="FOSDEM 2012"]] + +<http://fosdem.org/2012> + +FOSDEM will take place on February 4th/5th at the Université Libre de +Bruxelles. + + +# Who and When + +[[!table class="table_style_1" data=""" +"Name","Attending","Arrival","Return","Share room with us" +"[[Maksym Planeta]]","no" +"Olaf Buddenhagen","yes","","","yes" +"Richard Braun","no" +"Svante Signell","no" +"[[Thomas Schwinge|tschwinge]]","no" +"""]] + + +# Multiserver, Microkernel-Based Operating Systems Devroom + +[Announcement](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00137.html). diff --git a/community/meetings/froscon_2011.mdwn b/community/meetings/froscon_2011.mdwn new file mode 100644 index 00000000..b15140d6 --- /dev/null +++ b/community/meetings/froscon_2011.mdwn @@ -0,0 +1,15 @@ +[[!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="FrOSCon, 2011, Sankt Augustin, Germany"]] + +<http://www.froscon.de/> + + * [Arch Hurd booth](http://www.froscon.de/en/exhibitors/projekte.html#c1413) diff --git a/community/meetings/ghm2010.mdwn b/community/meetings/ghm2010.mdwn new file mode 100644 index 00000000..c8a9d8c3 --- /dev/null +++ b/community/meetings/ghm2010.mdwn @@ -0,0 +1,26 @@ +[[!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 +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="GNU Hackers Meeting, 2010, Den Haag"]] + +<http://www.gnu.org/ghm/2010/denhaag/> + + * {{$walfield_hurd}} + + +[[!ymlfront data=""" + +walfield_hurd: + + "video of the presentation by Neal Walfield: [*GNU/Hurd: It's About Freedom + (Or: Why you should + care)*](http://audio-video.gnu.org/video/ghm2010/GNU-Hurd_-_Its_About_Freedom,_Or_Why_you_should_care.ogv)" + +"""]] diff --git a/community/meetings/ghm2011.mdwn b/community/meetings/ghm2011.mdwn new file mode 100644 index 00000000..8e77d500 --- /dev/null +++ b/community/meetings/ghm2011.mdwn @@ -0,0 +1,27 @@ +[[!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="GNU Hackers Meeting, 2011, Paris"]] + +<http://www.gnu.org/ghm/2011/paris/> + + * {{$thibault_hurd}} + + +[[!ymlfront data=""" + +thibault_hurd: + + "presentation by Samuel Thibault: [*GNU/Hurd, aka. Extensibility from the + Ground*](http://www.gnu.org/ghm/2011/paris/#outline-container-2-5) + ([slides](http://www.gnu.org/ghm/2011/paris/slides/samuel-thibault-hurd.pdf), + [video](http://audio-video.gnu.org/video/ghm2011/Samuel_Thibault-GNU_Hurd.ogv))" + +"""]] diff --git a/community/meetings/ghm2012.mdwn b/community/meetings/ghm2012.mdwn new file mode 100644 index 00000000..0e3c8cd5 --- /dev/null +++ b/community/meetings/ghm2012.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="GNU Hackers Meeting, 2012, Düsseldorf"]] + +<http://www.gnu.org/ghm/2012/ddorf/> diff --git a/community/weblogs.mdwn b/community/weblogs.mdwn index 50791549..28f413eb 100644 --- a/community/weblogs.mdwn +++ b/community/weblogs.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,8 +11,14 @@ is included in the section entitled Weblogs from Hurd programmers and enthusiasts. +[[!map +pages="community/weblogs/* and !community/weblogs/*/*" +show=title]] + +--- + [[!inline -pages="community/weblogs/*/* and !*/discussion" +pages="community/weblogs/*/* and !community/weblogs/*/*/*" show=0 actions=no rootpage="community/weblogs" postformtext="Add a new user named:"]] diff --git a/community/weblogs/ArneBab.mdwn b/community/weblogs/ArneBab.mdwn index 4ef8a329..1e80e5a8 100644 --- a/community/weblogs/ArneBab.mdwn +++ b/community/weblogs/ArneBab.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 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 @@ -39,7 +39,7 @@ See you in the Hurd! ----- My Blog ----- [[!inline -pages="community/weblogs/ArneBab/* and !*/discussion" +pages="community/weblogs/ArneBab/* and !community/weblogs/ArneBab/*/*" show=0 actions=no rootpage="community/weblogs/ArneBab" postformtext="Add a new entry named:"]] diff --git a/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn new file mode 100644 index 00000000..b0e57bfb --- /dev/null +++ b/community/weblogs/ArneBab/2011-04-06-application-pyhurd.mdwn @@ -0,0 +1,148 @@ +Python Bindings for the Hurd (PyHurd) +========================== + +## Contact information + +- Name: Arne Babenhauserheide +- E-Mail Address: arne_bab@web.de +- IRC-nick: ArneBab @ freenode +- Jabber-ID: arne@jabber.fsfe.org +- Phone-number: XXXXXXXXX +- GnuPG key: http://draketo.de/inhalt/ich/pubkey.txt + +## Who I am + +I am a physics student from Heidelberg, Germany, a passionate free software user and roleplayer, and I started contributing to the Hurd in minor ways about 5 years ago. Now my coding skills are good enough (and I have enough time) that I feel ready to tackle a GSoC project - and I want to take the chance GSoC offers and do a focussed effort for contributing to free software before I am no longer a student. I married 4 years ago and now have a 5½ month old son whoose happy laughing can make you forget everything around you - or at least it does that to me, but what else could you expect to hear from his father about him ;) + +## Project + +For this years GSoC I want to turn the currently rudimentary Python Bindings of the Hurd into a complete Python-library for low-level Hurd and Mach hacking with high level functionality to allow for easy creation of complex applications. Particularly it should make it possible to utilize the whole Python standard library for translators. + +## Preliminary Schedule + + * *Community bonding period.* + Read up on the current C-interface to the Hurd and Cython. Especially grok the Hurd hacking guide. Add docstrings to all existing source files (where they are missing) explaining what they do. Add auto-generated API-docs. Deliverable: Easy to understand API-docs of the current PyHurd, a simple way to generate them from the sources automatically. + * *May 23.* + Coding starts. + * *May 30.* + Finished a basic Hello World translator, naively implementing the necessary Mach parts directly in the translator. + 1. A simple program which gets a Mach port and can receive messages on that port. It has to get and hold its port at startup and send a reply port, needs to use mach_msg to get the messages, should be able to deallocate the port and must have a kill condition (for example 10 received messages). + 2. stdout functionality, to print all Mach messages (for debugging and to make sure that they really get received entirely). + 3. a parser for the Mach read file message similar to trivfs\_S\_io\_read + * *June 6.* + Moved the functionality for reading into a simple API using decorators to define actions + and ported Hello World to use it: + + """Show Hello World.""" + from translator import repres + @repres.text.event + def on_text_read(size): + return "Hello, World!"[:size] + * *June 13.* + Implemented single file read-write in the API. Added a simple writethrough translator. The API code is nicely commented. + * *June 20.* + Access Control and file attributes. Added lock_file translator which just adjusts the effective file access codes and can be used to lock a file as long as the translator is used. Might be useful for quick testing. + * *June 27.* + Translator commandline arguments and testing. + * *July 4.* + Translator: Overlay with backend store: write changes to a different file. Makes any file writeable, but keeps the changes only visible for the user who set up the translator. Effectively single-file unionmount. + * *July 11.* + Mid-term: trivfs in python works: It is possible to write translators in Python with relative ease. + * *July 18.* + More complex, specialized and helper translator libraries, along with example translators. This should recreate some of the Hurd libraries for Python and add convenience options. + * *July 25.* + Full featured setttrans in Python. + * *August 1.* + Redesigned and realized an updated controlling API with the existing direct Cython bindings. + * *August 8.* + More translators and integrating into the build system. + * *August 15.* + Suggested Pencils down. The translator API is easy to use, there are many example translators and there is a full featured settrans command in Python using the easier controlling API which shows how to control the Hurd directly from Python. The code is pushed to <https://github.com/ArneBab/PyHurd> and a git repo at <http://git.savannah.gnu.org/cgit/hurd> and integrated into the build system with a switch to enable building PyHurd. + * *August 22.* + Firm pencils down. + + +## Initial Fix + +Initial Fix: Making PyHurd build again under Cython 0.14.1. Sent as patch series to bug-hurd@gnu.org + +## Detailed answers + +### What I have to learn, and what I already know + +I need to dive into the detailed interfaces of the Hurd to get a better understanding of the exact requirements for a well usable Python interface, especially for higher level functionality, and read up more on working with Cython. + +I already know Python and I did design my share of interfaces for my own hobby projects ([TextRPG][], [Fungus][], [evolve-keyboard-layout][] and others). + +[TextRPG]: https://bitbucket.org/ArneBab/textrpg/ +[Fungus]: https://bitbucket.org/ArneBab/fungus +[evolve-keyboard-layout]: https://bitbucket.org/ArneBab/evolve-keyboard-layout + +Also I know the functionality and design of the Hurd from a user perspective and can code in C and C++. + +### Why did you choose this project idea? What do you consider most appealing about it? + +FIrstoff: It is about making it possible for me to hack on the Hurd using my favorite programming language. + +Also I can learn more about accessing low-level interfaces directly (as opposed to just using higher level abstractions) and grok the ins and outs of creating Python extensions - into which I wanted to dive for a long time now. + +And I helped getting the project running and am intrigued by how far it can be pushed. + +### Have you been involved in any free software ("Open Source") projects yet? Which projects, how long, and in what way have you been involved? Have you been active in the Hurd project/Hurd community before? + +I worked on documentation and news for the Hurd, wrote two plugins and the usage guide for Mercurial and created a bunch of personal Python projects. Also I generally try to nudge other Hurd developers into the direction of actually getting the system useful for people (and communicating its strengths) - and do the same for the freenet project. + +In my opinion, my major contribution to the Hurd is the Month of the Hurd, a try at fixing the Hurds reputation for never being finished. To achieve that goal, the Month of the Hurd only lists actually testable successes for which I can easily describe how they get the Hurd closer to its vision, ideally those which are already committed. + +### Please briefly describe the Hurd, including the goals, architecture etc. Also, what makes you interested in the Hurd? Why do you want to work on it? What is your vision of it's future development? + +The Hurd offers much greater freedom for users compared to Linux, because every user can change his/her environment to a much greater extent. + +Also it allows for easier low-level tinkering, making it possible for hobby-hackers to work on stuff which in linux requires dabbling with kernel-sources. Also it makes it much easier to test these low-level work, so a community can spawn which informally shares low-level hacks, giving a much bigger momentum for low-level work. + +And it allows for containment of potentially dangerous applications using subhurds. As a very simple example, I can open a webbrowser without giving it access to the internet and just add that capability later, when I really want to go online (as opposed to just showing local files). + +But mainly: + + settrans -a ftp\: /hurd/hostmux /hurd/ftpfs / + dpkg -i ftp://ftp.gnu.org/…/*.deb + +And that’s only the beginning. + +### Are you subscribed to the bug-hurd@gnu.org mailing list? (See http://lists.gnu.org/mailman/listinfo/bug-hurd ) + +Yes :) + +### Do you have a permanent internet connection, especially during the time of the summer session? Are you able and willing to hang out on the Hurd IRC channel regularly? (As in: Running the IRC client more or less permanently and checking for activity now and then.) If it turns out that your mentor lives in a different time zone, could you shift your day/night rhythm to better match that of your mentor and other Hurd developers? + +Yes, a permanent internet connection as well as a permanently running computer. Since I’m used to also work later in the evening (on hobby projects), the time zone should not be a major issue. + +### When does your university term end, when are your exams, and when does the next term begin? + +I have a clean timetable for the summer: No exams anymore. + +### How much time do you intend to spend on your GSoC project per day/week during the summer months? + +I plan to spend at least 40 hours per week on the PyHurd. + +### What other major activities will you engage in during the summer? (Moving apartments, longer vacations, other obligations, etc.) If any, how do you intend to make sure you will be able to dedicate sufficient time to your project nevertheless? + +Finding a job for after the GSoC. This should not take too much time, all in all, but rather mean short out-times now and then. + +### How do you intend to make sure that your code will keep on being maintained and supported properly after the end of the GSoC program? + +My main plan to keep it maintained is to comment it cleanly, and naturally to keep using the Hurd and PyHurd itself, so any breakage will bother me personally. + +Also i want to get it merged into the main git repositories, so it is directly accessible for later developers. + +### Anything else you want to add to your application? + +I’d love to work on PyHurd, because it grips me more and more. For example a high level API might get as simple as + + from translator.source.text import * + from translator.repres.tree import * + def source_text_changed(text): … (adapt tree object) + def repres_tree_changed(tree): … (adapt text object) + → 2-way connectingk,5 + writeonly is then done by simply leaving out the definition for the source_<whatever>_changed. + source is the node below and repres is the translated node diff --git a/community/weblogs/ArneBab/2011-04-06-application-python-test.mdwn b/community/weblogs/ArneBab/2011-04-06-application-python-test.mdwn new file mode 100644 index 00000000..4c20afa1 --- /dev/null +++ b/community/weblogs/ArneBab/2011-04-06-application-python-test.mdwn @@ -0,0 +1 @@ +Cancelled. See [[community/weblogs/ArneBab/2011-04-06-application-pyhurd]] instead. diff --git a/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn b/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn new file mode 100644 index 00000000..00d09094 --- /dev/null +++ b/community/weblogs/ArneBab/Hurd-showcase-qemu-image.mdwn @@ -0,0 +1,111 @@ +I’m currently preparing a qemu image for the Hurd which allows testing the capabilities of the Hurd with as little effort as possible. + +**Work in progress. These are my in-development notes.** + +For that I want to use: + +* An up to date debian image (no longer online, but I have a copy here). +* My [Hurd Intro](http://bitbucket.org/ArneBab/hurd_intro), +* Translators from [hurd-extras](http://www.nongnu.org/hurdextras/) and the [incubator](http://git.savannah.gnu.org/cgit/hurd/incubator.git/), and naturally +* a lot of apt-get update; apt-get upgrade and apt-get dist-upgrade :) (all worked flawlessly). + +## Working + +### Generally + + # ssh with public key + apt-get install random-egd + ssh-keygen + + # build tools + apt-get install build-essential + +### StoreIO + + # mount an iso image + mount foo.iso bar -t iso9660fs + # see myfile as device + settrans foo /hurd/storeio myfile + # so that means I can pack a complete chroot (300MB) into a file with storeio and ext2fs — giselher + + # nfs mount anywhere (TODO: check this with antrik) + mount server:/home /home -t nfs + settrans /home /hurd/nfs server:/home + +## In Progress + +### Hurdextras + + hg clone <hurdextras repo> + +### httpfs + + # pkg-config is needed to avoid “PKG_CHECK_MODULES syntax error near unexpected token `HTTPFS,'” + # pkg-config must be installed before you run autoreconf. + apt-get install autoconf autoconf-archive libxml2-dev pkg-config + autoreconf -i -f + ./configure + make + make install + + settrans -ac gnu /usr/local/httpfs www.gnu.org/ + # (breaks, because libxml2 needs pthreads → work to do.) + # (what we need: pthreads in translators. → see the [work of Barry](https://savannah.gnu.org/task/?func=detailitem&item_id=5487)) + # check: for i in `objdump -x /usr/local/bin/httpfs |grep NEEDED| sed s/.*NEEDED//`; do echo $i; objdump -x /usr/lib/$i | grep pthread; objdump -x /lib/$i | grep pthread; done + +### Tarfs + + apt-get install zip libz-dev libbz2-dev + git clone git://git.sv.gnu.org/hurd/incubator.git tarfs + cd tarfs/ + git checkout tarfs/master + cd tarfs + make + make install + # works, though with warnings. + + settrans -ca new /hurd/tarfs -cz test/intro.tar.gz + cp repos/intro/README new/ + settrans -g new + tar -tf test/intro.tar.gz + # works + + tar -cf test/intro.tar repos/intro + settrans -ac t /hurd/tarfs test/intro.tar + # (settrans: /hurd/tarfs: Translator died :( ⇒ more work to do ) + +### nsmux + + git clone git://git.sv.gnu.org/hurd/incubator.git nsmux + cd nsmux/ + git checkout -b nsmux origin/nsmux + + apt-get install autoconf autoconf-archive + autoreconf -i -f + ./configure + make + make install + + cd ../.. + mkdir test + touch test/hello + settrans -ca test2 /usr/local/bin/nsmux test + # tar -cvf test/intro.tar repos/hurd_intro + cat test2/hello + cat test2/hello,,hello + # Hello, World! + +### clisp + + git clone git://git.sv.gnu.org/hurd/incubator.git clisp + cd clisp/ + git checkout -b clisp origin/clisp + + apt-get install texi2html + make + make install + + +### debugging Translators + + rpctrace diff --git a/community/weblogs/ArneBab/What_a_Hurd_release_should_be_able_to_do_for_me.mdwn b/community/weblogs/ArneBab/What_a_Hurd_release_should_be_able_to_do_for_me.mdwn new file mode 100644 index 00000000..51ef2a85 --- /dev/null +++ b/community/weblogs/ArneBab/What_a_Hurd_release_should_be_able_to_do_for_me.mdwn @@ -0,0 +1,40 @@ +I thought a bit about what I’d need from Hurd to use it for some of my real life tasks. + +My desktop has to be able to do everything it does now, and that under high load, so it currently is no useful target for the Hurd. + +But then I have an OLPC XO sitting here, and I use it mostly for work and for clearly defined tasks. As such it seems natural to me to check, what the Hurd would have to be able to do to support my workflow on the OLPC. + +### What I need + +* Writing text and programming Python with emacs. - *works*. +* Use Mercurial for my versiontracked stuff. - *works*. +* Reading websites with emacs and w3m or with lynx. - *works*. +* Use SSH to go on my desktop and on the university machine. - *should work*. +* Run X11 with dwm and emacs. - *should work*. +* Boot Hurd on the OLPC from a USB stick. - *not yet*? +* Support networking over wlan and wpa_supplicant. - *not yet*? Might DDE kit help? +* Listen to music with Quod Libet in X11. - *not yet*. Needs audio support. + +### What would be nice + +* Run a Gentoo system. - not *really* needed, but nice to update my system with the same tools. +* Watch videos with mplayer. - unlikely. Even with Linux as kernel watching videos pushes my XO to the limit. But this is not essential. + + +So, as soon as Debian GNU/Hurd (or Arch Hurd) supports the things I need, I’ll put it on a USB-stick and use it for coding and writing. + +To be frank: I’d likely even use it without audio-support. I have an mp3 player and can feed it via USB. So the essential features for me are: + +### Essential features + +* Writing text and programming Python with emacs. - works. +* Use Mercurial for my versiontracked stuff. - works. +* Use SSH to go on my desktop and on the university machine. - should work. +* Boot Hurd on the OLPC from a USB stick. - not yet? +* Support networking over wlan and wpa_supplicant. - not yet? Might DDE kit help? + +### Conclusion + +The Hurd doesn’t yet do everything I need for my OLPC, but it isn’t that far away either. Grub already gets [ported to OLPC](http://grub.enbug.org/OLPC), so what’s missing to make the Hurd a work system for me are just *booting on OLPC from USB stick* and *wlan-support on OLPC*. + +All the rest I need for work is already in place. diff --git a/community/weblogs/ArneBab/how-i-write-a-qoth.mdwn b/community/weblogs/ArneBab/how-i-write-a-qoth.mdwn new file mode 100644 index 00000000..87b1f07d --- /dev/null +++ b/community/weblogs/ArneBab/how-i-write-a-qoth.mdwn @@ -0,0 +1,44 @@ +I just read on the hurd IRC channel (chat: #hurd at irc.freenode.net), that people consider my work valuable (I knew that, and I think that myself, but it is still nice to hear), so I want to dispell any possible myth about it :) + +What I do is not hard - at least not anymore, since I created a simple structure for it (But it still takes time). + +First I open up the relevant mailing lists for the quarter. I get them from [[contributing/web_pages/news/writing_the_qoth]]. Normally I just use the following: + +* <http://lists.gnu.org/archive/html/bug-hurd/YYYY-MM/threads.html> +* <http://lists.debian.org/debian-hurd/YYYY/MM/> + +Then I copy them 3 times and use M-x replace-string (in emacs) to adjust them to the correct months. + +Additionally I open the Arch Hurd news: + +* <http://www.archhurd.org/news.php> +* <http://planet.archhurd.org/> + +Having all those news at hand, I read every thread-starter and every news-item. For each of them I first check if I understand them (no use trying to explain something I don’t get myself) and if they provide a way for people to test what they improved (however complex that might be), then I + +* note the name of the main contributor(-s), +* write a line of text what it does (often partly copied from the news-item), +* add a link to the news-item, a code-repo or a patch and +* a note how that new development helps achieve the goals_of_the_Hurd (see [[contributing/web_pages/news/writing_the_qoth]] for details). + +With that list of short news I go into [[contributing/web_pages/news/qoth_next]]. + +Now I identify 2 to 4 main news items by some kind of “helps the Hurd most when more people know it”, “biggest change” and similar fudgery :) + +Finally I sort all the news items by intuition, crude logic I develop on-the-fly writing and the goal of making the qoth read somewhat like nice prose. + +On the way to that I commit every little to medium step. I never know when I have to abort due to an interruption (I’m sure tschwinge loves my super-non-atomic horrible-to-review commits :-) - but better that than losing work == time, and I try to prefix the commit-messages with “news:” so he knows that it’s useless to review them as in-flight-patches…). + +Having finished the text (usually after 3 to 6 hours of overall work), I send it by mail to bug-hurd: <http://lists.gnu.org/archive/html/bug-hurd/> + +After about a week I incorporate the comments from there and publish the qoth as described in [[contributing/web_pages/news/writing_the_qoth]]. + +Then tschwinge reviews it, does some last-minute changes and pushes it from the staging wiki to the website. + +And that’s it. + +I hope this small insight was interesting to you. Happy hacking and have fun with the Hurd! + +-- Arne Babenhauserheide + +PS: Writing this blog entry took about 20 minutes. The raw text is longer than a qoth, but it is much faster to write, because it avoids the main time-eater: Gathering the info with the necessary references to make sure that people can test what’s in here. diff --git a/community/weblogs/ArneBab/metadata-and-program-communication-akonadi-nepomuk-dbus.mdwn b/community/weblogs/ArneBab/metadata-and-program-communication-akonadi-nepomuk-dbus.mdwn new file mode 100644 index 00000000..41c82c83 --- /dev/null +++ b/community/weblogs/ArneBab/metadata-and-program-communication-akonadi-nepomuk-dbus.mdwn @@ -0,0 +1,20 @@ +Just ideas for more elegant implementations of dbus and akonadi/nepomuk using Hurd interfaces + +tagging: + + settrans ~/ /hurd/nsmux + ls ~/file,,metadata + +store in ~/.metadata + +network store: search for .metadata + +All metadata: + + settrans meta /hurd/metadata --show-store + +dbus: + + settrans -a /dbus /hurd/dbus + +Programs just add an active translator in /dbus: /dbus/org.… → receives dbus calls in-process. diff --git a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn index ff169b0a..5febe7b6 100644 --- a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn +++ b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn @@ -94,16 +94,16 @@ sounds like an interesting option.*" *"While I believe this can be applied to any kind of applications, I'm personally most interested in more efficient and powerful desktop environments -- these considerations are in fact what got me seriously -interested in the Hurd. +interested in the Hurd.* -Even more specifically, I've done most considerations (though by far not +*Even more specifically, I've done most considerations (though by far not all) on modular web browsing environments. Those interested can read up -some of my thoughts on this: +some of my thoughts on this:* http://sourceforge.net/mailarchive/message.php?msg_name=20080909073154.GB821%40alien.local -(Just skip the text mode browsing stuff -- the relevant part is the long +*(Just skip the text mode browsing stuff -- the relevant part is the long monologue at the end... I really should put these ideas into my blog.)"* @@ -127,7 +127,17 @@ or even: * cp ftp://foo/bar/ogg play -that's KDEs fabled network transparency on the filesystem / shell level. +that's KDEs fabled network transparency on the filesystem / shell level (where it belongs to be desktop agnostic). + +* add temporary filesystems anywhere via `settrans -a NODE /hurd/ext2fs` + +* On-demand mounted filesystems via a passive translator which unmounts the filesystem when it isn’t used for some time. + +* make everything temporarily writeable without really changing it via [[hurd/translator/unionfs]]. Store the changes on an external device. + +* Read tar archives and mbox files via `ls foo.tar.gz,,tarfs` and `ls foo.mbox,,mboxfs`, respectively → [[hurd/translator/nsmux]]. + +* Use stuff like the new akonady (personal information) framework in KDE more efficiently from the shell. Reality check @@ -149,7 +159,7 @@ aren't possible. * elegantly mount iso images and similar as unprivileged user. - Other useful stuff: - * Install deb-packages from an ftp server via 'dpkg -iO ftp://foo/bar/*.deb' + * Install deb-packages from an ftp server via 'dpkg -iO ftp://foo/bar/package.deb' * remount a filesystem readonly as regular user: fsysopts /foo -r * give a process additional group and user permissions at runtime: $ groups @@ -187,10 +197,6 @@ aren't possible. # once the subhurd closes. $ subdo --no-lasting-changes ./virus -- Running parts of the Hurd on different computers, maybe even with shared servers on -dedicated hardware (Cloud Computing when the servers can be made to migrate from -between computers). Maybe this should be placed in "need a lot of coding". - - subhurds for quickly adapting the whole system without bothering others. - Define your personal environment via translators, so you can easily take it with @@ -222,8 +228,6 @@ traditional systems in this reagard, but in fact surpass them. - The possibility to create more efficient and powerful desktop environments. -- Multicore systems (need to fixup Mach for SMP) - - Currently to offer CPU time to some project (like the World Community Grid), it is necessary to install a program from them, and they can then do only what that proram allows them to - which leads to reinventing a processing environment instead of just @@ -240,6 +244,12 @@ level. Programs only have to display the given files and quickly update the state of their own files, so the programs stay very easy. The translator could notify the program when something changes. +- Multicore systems (need to fixup Mach for SMP) + +- Running parts of the Hurd on different computers, maybe even with shared servers on +dedicated hardware (Cloud Computing when the servers can be made to migrate from +between computers). Maybe this should be placed in "need a lot of coding". + ### Unfeasible ideas @@ -320,13 +330,32 @@ Each participant: ("must", because in a community people can do what they perceive as important, and telling someone to stop what he's doing is no option (in my opinion)) +**Result: We talk about the niches we can already fulfill :)** + Things to do ------------ todo-item -> niches for which it is useful. +*This might be useful for the next GSoC.* + ### Easy -- Port debian packages to the Hurd -> mainly tinkerers, but also any other niche. +- Port debian packages to the Hurd -> currently mainly tinkerers, but also any other niche. In the long run this is necessary for every user. Easy start for devs. +- Document easier access to low-level functions via translators, one function at a time. -> tinkerers. +- get nsmux ready for regular users by setting it up in the LiveCDs by default. -> show tinkerers what it can do. +### Complex + +- A filesystem-based package manager: Unionmounting packages. With filterfs from nsmux packages any user should be able to selectively disable any package without affecting the system of others. Simple active translators can add packages. -> clean design and more freedom for tinkerers to setup test environments: “Does this also work with XY disabled?” +- Enable subhurds for regular users via a subdo command: A framework for confining individual applications. -> tinkerers for testing their work. +- Define your personal environment via translators, so you can easily take it with +you ⇒ system on a USB stick. Would work great with a filesystem based package manager. -> ? + +### Huge + +- Get Hurd/GNU Mach ready for efficient multicore usage. -> multicore +- Running parts of the Hurd on different computers, maybe even with shared servers on +dedicated hardware (Cloud Computing when the servers can be made to migrate from +between computers). -> multicore on steroids :) diff --git a/community/weblogs/ArneBab/porting-simple-packages.mdwn b/community/weblogs/ArneBab/porting-simple-packages.mdwn new file mode 100644 index 00000000..becea251 --- /dev/null +++ b/community/weblogs/ArneBab/porting-simple-packages.mdwn @@ -0,0 +1,72 @@ +# Quick porting guide for simple packages + +*If you want to help port a package with simple issues to the Hurd, please read on.* + +*just imagine joe C-doodler stumbling over some GNU philosophy and thinking “hey, I’ve got 2 free hours, why not help the Hurd?”* +*for him I’d like to have a guide (and for me, the faulty-memory-does-too-many-things :) )* + +*a short guide “how to do simple ports” broken down to command line level: how to get the list of simple packages (youpi told me that here), how to get the source, how to test the fix, how to submit the fix.* + +## Setup an instant Hurd development environment + +See [[Instant Development Environment|contributing#index5h2]] - just follow the command to get a Hurd running in Qemu. + +## Getting the list of failed packages + + wget http://people.debian.org/~sthibault/failed_packages.txt.gz + gunzip failed_packages.txt.gz + +## Finding a simple task + + grep PATH_MAX failed_packages.txt -B 2 + +Each of these packages is likely to be simple to fix. The output looks like this: + + … + -- + tex/lilypond_2.12.3-7 by buildd_hurd-i386-mozart [optional:uncompiled:bp{-100}:calprio{-63}:days{258}] + Reasons for failing: + > file-name.cc:88: error: 'PATH_MAX' was not declared in this scope + -- + … + +in this case, lilypond is the package. + +Other simple tasks can be found on [[hurd/porting/guidelines]]. + +## Downloading the package source and installing dependencies + + apt-get source PACKAGE + apt-get build-dep PACKAGE + +For example + + apt-get source lilypond + apt-get build-dep lilypond + +## Fix the package + +See [[hurd/porting/guidelines]] for help on fixing the package. + +Notes: + +* char path[4096] is evil. Use dynamic allocation (if you can). +* use stuff like if (x < sysconf(_SC_PATH_MAX)) {} +* if need be, make it conditional + +\#ifdef PATH_MAX +old, POSIX-violating code +\#else +GNU, better code +\#endif + +## Test the fix (compile, run tests) + + cd PACKAGE + dpkg-buildpackage -B + +Also check the packages README for instructions. + +## Submit the fix + +See [[hurd/running/debian/patch_submission]]. diff --git a/community/weblogs/ArneBab/tasks-for-the-hurd.mdwn b/community/weblogs/ArneBab/tasks-for-the-hurd.mdwn new file mode 100644 index 00000000..bf6224b2 --- /dev/null +++ b/community/weblogs/ArneBab/tasks-for-the-hurd.mdwn @@ -0,0 +1,63 @@ +Tasks for the Hurd +================== + +*These tasks are compiled from the + [[community/weblogs/ArneBab/niches_of_the_hurd]] and + [[community/weblogs/ArneBab/what_we_need]]. The first asked “where + can the Hurd find niches where it is the biggest fish in the pond, + and how?” while the second asked “what do we still need to make the + Hurd usable for most of its developers as system for their day-to-day + tasks?”.* + +*This might be useful for the next GSoC. Please feel free to edit + and/or migrate it mercilessly :)* + +### Easy + +- Port debian packages to the Hurd -> currently mainly tinkerers, but + also any other niche. In the long run this is necessary for every + user. Easy start for devs. +- Document easier access to low-level functions via translators, one + function at a time. -> tinkerers. +- get nsmux ready for regular users by setting it up in the LiveCDs by + default. -> show tinkerers what it can do. +- Test on modern machines. If it doesn’t work, file a bug: + [info](http://www.mail-archive.com/bug-hurd@gnu.org/msg19105.html). + + +### Complex + +- A filesystem-based package manager: Unionmounting packages. With + filterfs from nsmux packages any user should be able to selectively + disable any package without affecting the system of others. Simple + active translators can add packages. -> clean design and more + freedom for tinkerers to quickly setup test environments: “Does this + also work with XY disabled?” ⇒ rapid testing for different base + systems. +- Enable subhurds for regular users via a subdo command: A framework + for confining individual applications. -> tinkerers for testing + their work. +- Define your personal environment via translators, so you can easily + take it with you ⇒ system on a USB stick. Would work great with a + filesystem based package manager -> use the capabilities of a system + and all its installed packages without having to give up your own + custom environment. + +- Implement USB support, maybe using DDE or DDEkit -> prerequisite to system on USB. +- Add Wireless support, maybe via DDE. +- Add sound support via a sound translator. +- Add SATA support. +- Stabilize Xorg, so it can run fast for days. +- Add PPPoE capablilities. +- Debug NFS for climm, w3m and git. +- Port a full-featured browser (i.e. Firefox). +- (Graphical Desktop and switching between console and X) or full + featured high-resultion console which doesn’t need X (and emacs :) + ). + +### Huge + +- Get Hurd/GNU Mach ready for efficient multicore usage. -> multicore +- Running parts of the Hurd on different computers, maybe even with + shared servers on dedicated hardware (Cloud Computing when the servers + can migrate between computers). -> multicore on steroids :) diff --git a/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn b/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn new file mode 100644 index 00000000..35e55518 --- /dev/null +++ b/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn @@ -0,0 +1,56 @@ +Some technical advantages of the Hurd +===================================== + +*→ An answer to [just accept it, truth hurds](http://blog.flameeyes.eu/2011/05/15/just-accept-it-truth-hurds), where Flameeyes told his reasons for not liking the Hurd and asked for technical advantages (and claimed, that the Hurd does not offer a concept which got incorporated into other free software, contributing to other projects). Note: These are the points I see. Very likely there are more technical advantages which I don’t see well enough to explain them. Please feel free to [point them out](http://draketo.de/comment/reply/447#comment-form).* + +*__Information for potential testers:__ The Hurd is already usable, but it is not yet in production state. It progressed a lot during the recent years, though. Have a look at the [[status_report|hurd/status]] if you want to see if it’s already interesting for you.* + +Thanks for explaining your reasons. As answer: + +Firstoff: [FUSE](http://fuse.sourceforge.net/) is essentially an implementation of parts of the [[translator_system|hurd/documentation/translators]] (which is the main building block of the [Hurd](http://hurd.gnu.org)) to Linux, and NetBSD recently got a [port of the translators system of the Hurd](http://netbsd-soc.sourceforge.net/projects/hurdt/). That’s the main contribution to other projects that I see. + +On the bare technical side, the **translator-based filesystem** stands out: The filesystem allows for making arbitrary programs responsible for displaying a given node (which can also be a directory tree) and to start these programs on demand. To make them persistent over reboots, you only need to add them to the filesystem node (for which you need the right to change that node). Also you can start translators on any node without having to change the node itself, but then they are not persistent and only affect your view of the filesystem without affecting other users. These translators are called active, and you don’t need write permissions on a node to add them. +<!--break--> +The filesystem implements stuff like Gnome VFS (gvfs) and KDE **network transparency on the filesystem level**, so those are available for all programs. And you can add a new filesystem as simple user, just as if you’d just write into a file “instead of this node, show the filesystem you get by interpreting file X with filesystem Y” (this is what you actually do when setting a translator but not yet starting it (passive translator)). + +One practical advantage of this is that the following works: + + settrans -a ftp\: /hurd/hostmux /hurd/ftpfs / + dpkg -i ftp://ftp.gnu.org/path/to/*.deb + +This installs all deb-packages in the folder `path/to` on the FTP server. The shell sees normal directories (beginning with the directory “ftp:”), so shell expressions just work. + +You could even define a Gentoo mirror translator (`settrans mirror\: /hurd/gentoo-mirror`), so every program could just access mirror://gentoo/portage-2.2.0_alpha31.tar.bz2 and get the data from a mirror automatically: `wget mirror://gentoo/portage-2.2.0_alpha31.tar.bz2` + +Or you could add a unionmount translator to root which makes writes happen at another place. **Every user is able to make a readonly system readwrite** by just specifying where the writes should go. But the writes **only affect his view of the filesystem**. + +Starting a network process is done by a translator, too: The first time something accesses the network card, the network translator starts up and actually provides the device. This replaces most **initscripts in the Hurd: Just add a translator to a node**, and the service will persist over restarts. + +It’s a surprisingly **simple concept, which reduces the complexity of many basic tasks needed for desktop systems**. + +And at its most basic level, *Hurd is a set of protocols for messages which allow using the filesystem to coordinate and connect processes* (along with helper libraries to make that easy). + +Also it adds **POSIX compatibility to Mach** (while still providing access to the capabilities-based access rights underneath, if you need them). You can **give a process permissions at runtime** and take them away at will. For example you can start all programs without permission to use the network (or write to any file) and add the permissions when you need them. + + groups # → root + addauth -p $(ps -L) -g mail + groups # → root mail + +And then there are subhurds (essentially **lightweight virtualization** which allows cutting off processes from other processes without the overhead of creating a virtual machine for each process). But that’s an entire post of its own… + +And the fact that a translator is just a simple standalone program means that these can be shared and tested much more easily, opening up completely new options for lowlevel hacking, because it massively lowers the barrier of entry. + +And then there is the possibility of *subdividing memory management* and using different microkernels (by porting the Hurd layer, as partly done in the NetBSD port), but that is purely *academic* right now (search for *Viengoos* to see what its about). + + +So in short: *The translator system in the Hurd is a simple concept which makes many tasks easy, which are complex with Linux (like init, network transparency, new filesystems, …). Additionally there are capabilities, subhurds and (academic) memory management.* + +Best wishes, +Arne + +*PS: I decided to read flameeyes’ post as “please give me technical reasons to dispell my emotional impression”.* + +*PPS: If you liked this post, it would be cool if you’d flattr it: <a href="http://flattr.com/thing/273582/Some-technical-advantages-of-the-Hurd" target="_blank"> +<img src="http://api.flattr.com/button/flattr-badge-large.png" alt="Flattr this" title="Flattr this" border="0" /></a>* + +*PPPS: Additional information can be found in [Gaël Le Mignot’s talk notes](http://kilobug.free.fr/hurd/pres-en/abstract/html/), in [niches for the Hurd](http://www.gnu.org/software/hurd/community/weblogs/ArneBab/niches_for_the_hurd.html) and the [[GNU_Hurd_documentation_pages|hurd/documentation]].* diff --git a/community/weblogs/ArneBab/technical-advantages-of-the-hurd/discussion.mdwn b/community/weblogs/ArneBab/technical-advantages-of-the-hurd/discussion.mdwn new file mode 100644 index 00000000..49b64509 --- /dev/null +++ b/community/weblogs/ArneBab/technical-advantages-of-the-hurd/discussion.mdwn @@ -0,0 +1,248 @@ +## Followup discussion in IRC + +IRC, freenode, #hurd, 2011-05-15 + +<dl> +<dt><LibreMan></dt><dd> ArneBab: hi, I read the hurd rant by flameeyes and your response ... I'm following Hurd for some time and would like to ask some questions about it, would you mind? :)</dd> +<dt><ArneBab></dt><dd> please ask :)</dd> +<dt><ArneBab></dt><dd> I don’t mind (as long as I have the time - which I have right now)</dd> +<dt><LibreMan></dt><dd> ok, so essentially I'm trying to figure out, as flameeyes probably is, whether reasons behind developing Hurd are more philosophical/value based or are there real-world technical advantages to it as well</dd> +<dt><ArneBab></dt><dd> antrik: I think his original remark was meant as part-jokingly remark to an aquaintance - which seems fitting, when you keep in mind that flameeyes works very hard and very much on Gentoo, hardly the most popular distro (but the one I like most).</dd> +<dt><ArneBab></dt><dd> LibreMan: the reasons for working on the Hurd are a little bit different for every contributor.</dd> +<dt><ArneBab></dt><dd> (or rather: vastly different :) )</dd> +<dt><LibreMan></dt><dd> as I'm reading about it and your reposne as well, I'm not sure the techical advantages you list would have any real world effect on usability of the OS, do you think they would?</dd> +<dt><ArneBab></dt><dd> I think they would</dd> +<dt><LibreMan></dt><dd> ArneBab: yeah, sure ... my reasons for supporting Hurd are philosophical/value based ... I'll say that outright</dd> +<dt><ArneBab></dt><dd> for example you enter an FTP address in your filebrowser. No problem. Then you want to grep the file contents.</dd> +<dt><ArneBab></dt><dd> you go into the shell and first need to get the files (completely inconvenient)</dd> +<dt><-- npnth (~npnth@pdpc/supporter/active/npnth) hat das Netzwerk verlassen (Disconnected by services) +<dt><ArneBab></dt><dd> or you use gnome and kde programs, and both access the same URL, but cache 2 times.</dd> +<dt><LibreMan></dt><dd> ArneBab: isn't that solved by mounting it?</dd> +<dt><ArneBab></dt><dd> or you want to implement your own desktop and need to do that network transarency stuff yourself.</dd> +<dt><ArneBab></dt><dd> You can’t really mount everything - especially not without root rights.</dd> +<dt><ArneBab></dt><dd> and that’s just one aspect.</dd> +<dt><ArneBab></dt><dd> But that’s only the technical side (he only wanted to hear that)</dd> +<dt><LibreMan></dt><dd> the thing is all these advantages seem too trivial to support a wholly new OS to be developed ... but maybe I'm mistaken, that's why I'm asking, I would love to be good techical reasons for Hurd ... but are not aware of any so far</dd> +<dt><ArneBab></dt><dd> What interests me the most as that I as user can change my environment without affecting others.</dd> +<dt><ArneBab></dt><dd> s/as/is/</dd> +<dt><ArneBab></dt><dd> the main community part is (and I think I missed that), that any server is just a userspace program.</dd> +<dt><ArneBab></dt><dd> it can be exchanged just like any other program</dd> +<dt><antrik></dt><dd> ArneBab: yeah, I found the original remark after following the other links... though it's rather painful to trace the conversations :-)</dd> +<dt><LibreMan></dt><dd> ArneBab: yeah, I understand that ... but what practical advantage would that give me I do not see ... as a server administrator for example</dd> +<dt><ArneBab></dt><dd> I can write an improved filesystem and pass it to you for testing, and you test it only for a backup snapshot of your disk without rebooting.</dd> +<dt><ArneBab></dt><dd> As server admin, you don’t need to install all drivers users could need.</dd> +<dt><ArneBab></dt><dd> the users can just install what they need themselves.</dd> +<dt><antrik></dt><dd> it certainly didn't sound half-joking though... and if it was meant privately, identi.ca is clearly NOT the right place</dd> +<dt><ArneBab></dt><dd> LibreMan: You simply provide a base which reduces the number of things people need to install.</dd> +<dt><LibreMan></dt><dd> ArneBab: but do not I have to give them access to raw HW too then?</dd> +<dt><ArneBab></dt><dd> antrik: I prefer to always assume good faith :)</dd> +<dt><ArneBab></dt><dd> brb</dd> +<dt><ArneBab></dt><dd> child</dd> +<dt><ArneBab></dt><dd> re</dd> +<dt><LibreMan></dt><dd> well, I do not see that people not able to install their own drivers on a server would be any problem currently</dd> +<dt><LibreMan></dt><dd> that's my point ... is seems to solve "problems" that are not really actual real world problems ...</dd> +<dt><ArneBab></dt><dd> LibreMan: no, you just give them a safe device, where a server makes sure they don’t do illegal things.</dd> +<dt><antrik></dt><dd> LibreMan: most of the advantages are not directly visible, unless you do very specific things, where traditional systems impose limits</dd> +<dt><ArneBab></dt><dd> For me network transparency is a realworld problem</dd> +<dt><ArneBab></dt><dd> as is that I can’t give a program network access later</dd> +<dt><antrik></dt><dd> but it makes many things easier, which in the end will translate into advantages for everyone I believe</dd> +<dt><ArneBab></dt><dd> “log out and in again to play games”</dd> +<dt><ArneBab></dt><dd> (after adding yourself to the games group)</dd> +<dt><ArneBab></dt><dd> or better still: Always start with minimal rights and only add what is really needed.</dd> +<dt><ArneBab></dt><dd> There’s no reason why a program should have access to my audio hardware without me granting it.</dd> +<dt><ArneBab></dt><dd> That way I could even run malicious software without having to fear compromising my system.</dd> +<dt><antrik></dt><dd> LibreMan: I could come up with situations where it could help you as an administrator; but this is not really helpful. you won't really understand the advantages until you get into a specific situation that is hard to do on Linux for example, and much easier on the Hurd</dd> +<dt><LibreMan></dt><dd> ArneBab: well, then it becomes a tradeoff between security and user friendliness ... I do not think that problem is unsolvable currently, I think it is a design decision not to "solve it" as wast majority of users do not actually need or want it</dd> +<dt><ArneBab></dt><dd> LibreMan: Time and again I find myself sitting in front of my linux box and thinking “damn, this woul be so easy in the Hurd”</dd> +<dt><ArneBab></dt><dd> (I do most of my work on a Linux box)</dd> +<dt><ArneBab></dt><dd> Gentoo GNU/Linux with KDE and Emacs</dd> +<dt><LibreMan></dt><dd> antrik: yeah, could you give me an example of something that is hard on linux but easy under hurd? with real world implications for real use cases :)</dd> +<dt><ArneBab></dt><dd> LibreMan: Get a hg/git log of a repo on an ftp server</dd> +<dt><antrik></dt><dd> LibreMan: no, it's *not* a tradeoff. the whole point is that the Hurd architecture allows users to customize their environment *without* compromising the security of the system</dd> +<dt><ArneBab></dt><dd> antrik LibreMan: I think there we have one point: When you use Linux you are used to thinking of the Linux limits as the absolute limits.</dd> +<dt><LibreMan></dt><dd> antrik: the point is, wast majority of users do not need that ... AFAIK</dd> +<dt>-*- youpi is fed up with using sudo just to mount an iso image +<youpi></dt><dd> really</dd> +<dt><Tekk_></dt><dd> youpi: dbus</dd> +<dt><ArneBab></dt><dd> LibreMan: just wait for the first strong linux worm which spreads in a game and requires sudo for install… </dd> +<dt><youpi></dt><dd> (and it's just one of the strongest examples)</dd> +<dt><youpi></dt><dd> Tekk_: ??</dd> +<dt><antrik></dt><dd> LibreMan: ArneBab already gave you various exmples. including at least one that works out of the box</dd> +<dt><Tekk_></dt><dd> youpi: with dbus you don't need root permissions</dd> +<dt><youpi></dt><dd> Tekk_: and you can mount any iso?</dd> +<dt><antrik></dt><dd> (others would require some additional coding)</dd> +<dt><ArneBab></dt><dd> Tekk_: but something needs them.</dd> +<dt><Tekk_></dt><dd> youpi: oh, iso...</dd> +<dt><LibreMan></dt><dd> ArneBab: why would a game need sudo to install? :)</dd> +<dt><youpi></dt><dd> Tekk_: yes, iso</dd> +<dt><youpi></dt><dd> or $WHATEVER_FS</dd> +<dt><Tekk_></dt><dd> youpi: sec</dd> +<dt><ArneBab></dt><dd> LibreMan: yes, I would ask that, too. But the general Ubuntu user?</dd> +<dt><youpi></dt><dd> or sshfs, or ftpfs, etc.</dd> +<dt>-*- ArneBab had hoped you’d catch that :) +<LibreMan></dt><dd> the area where I can imagine hurd being better is virtualization</dd> +<dt><antrik></dt><dd> LibreMan: again, the "general Ubuntu user" won't directly see the benefits. but he will see them when developers use them to implement nice features that would be much harder to implement elsewhere</dd> +<dt><LibreMan></dt><dd> making everything cloudy is a big trend nowadays and hurd could provide additional flexibility there ... or no? I'm really just guessing based on what I read</dd> +<dt><antrik></dt><dd> it's a bad trend</dd> +<dt><ArneBab></dt><dd> LibreMan: it could give me more options when I have to work on another ones computer. After all it was conceived in the time of dumb terminals - which now comes back.</dd> +<dt><LibreMan></dt><dd> ArneBab: oh well, if we are talking about user stupidity then no OS is going to help ;)</dd> +<dt><antrik></dt><dd> I'm not sure whether the Hurd help with "making things cloudy", but it's not something I'd consider an advantage anyways :-)</dd> +<dt><ArneBab></dt><dd> LibreMan: The OS can reduce the impact of user stupidity (called DAU in german: „Dümmster anzunehmender User“ → “dumbest conceivable user”)</dd> +<dt><antrik></dt><dd> as for virtualization, indeed there is a *very* close relation between that and microkernel systems, which most people fail to see...</dd> +<dt><LibreMan></dt><dd> antrik: the "cloud" is coming if we like it or not ... it better run on FOSS if it comes ;)</dd> +<dt><Tekk_></dt><dd> you know, you gues have a huge advantage</dd> +<dt><Tekk_></dt><dd> guys*</dd> +<dt><Tekk_></dt><dd> people have waited forever and written you off</dd> +<dt><ArneBab></dt><dd> LibreMan: just think about the difference between a GNU/Linux distro and Windows XP where you were admin at all times.</dd> +<dt><Tekk_></dt><dd> and as duke nukem forever shows, that's a good thing ;P</dd> +<dt><antrik></dt><dd> in fact, the only fundamental difference is that a VM makes the subenvironment look more or less like a real machine, while in traditional microkernel systems different interfaces are used</dd> +<dt><ArneBab></dt><dd> LibreMan: A Hurd system would go one step further.</dd> +<dt><ArneBab></dt><dd> You’d even need a password more seldomly, reducing the incentive to just work as admin.</dd> +<dt><ArneBab></dt><dd> Reason: There are less things which can really badly impact the system.</dd> +<dt><antrik></dt><dd> LibreMan: when talking about "the cloud", people usually mean things that are fundamentally incompatible with the idea of free software</dd> +<dt><antrik></dt><dd> (you don't have control over the software running web services)</dd> +<dt><ArneBab></dt><dd> antrik: but the cloud just means “I’m on a different computer”. AGPLv3 is cool there :)</dd> +<dt><LibreMan></dt><dd> antrik: yeah, that's the common bussines practice but it doesn't have to be ... AGPL ;)</dd> +<dt><antrik></dt><dd> ArneBab: well, actually "the cloud" means something different to everyone ;-)</dd> +<dt><LibreMan></dt><dd> I do not have any problem with a cloud running AGPL software</dd> +<dt><ArneBab></dt><dd> antrik: well, yes :)</dd> +<dt><antrik></dt><dd> ArneBab: but generally it relies on using programs on foreign machines, controlled by someone else. AGPL doesn't change that</dd> +<dt><LibreMan></dt><dd> freedombox is going to be a "cloud" too</dd> +<dt><antrik></dt><dd> LibreMan: that's not what most people mean by "cloud"</dd> +<dt><LibreMan></dt><dd> at least I hope so</dd> +<dt><ArneBab></dt><dd> I don’t have control over my webserver. I can’t run a real Python there. Hurd could change that (though that will take a lot of coding: the conceptual options are there)</dd> +<dt><ArneBab></dt><dd> LibreMan: what could interest you: http://www.gnu.org/software/hurd/community/weblogs/ArneBab/niches_for_the_hurd.html</dd> +<dt><ArneBab></dt><dd> “Niches of the Hurd”</dd> +<dt><LibreMan></dt><dd> what I mean by "the cloud" is what Eben Moglen explaied it as ... the technology which make it possible to forget about the "iron" and move servers around seamlessly</dd> +<dt><LibreMan></dt><dd> ArneBab: thank.. going to look at it</dd> +<dt><antrik></dt><dd> LibreMan: that's actually more or less what used to be called "grid computing" before the cloud hype</dd> +<dt><LibreMan></dt><dd> antrik: well ... yes, essentially</dd> +<dt><antrik></dt><dd> LibreMan: but most people mean many other things too when talking about "clouds"</dd> +<dt><antrik></dt><dd> and anyways, you can't really forget about the iron. there is a middle layer which you don't have control of</dd> +<dt><LibreMan></dt><dd> antrik: sure, I would say that most people do not know what they mean :)</dd> +<dt><Tekk_></dt><dd> hmm</dd> +<dt><Tekk_></dt><dd> ArneBab: I can see a big place for virtualization in browsers</dd> +<dt><Tekk_></dt><dd> I mean, with everyone so worried about the code getting executed there, we just have GNUBrowse run in it's own little environment all closed off</dd> +<dt><ArneBab></dt><dd> Tekk_: me too: safe subenvironments.</dd> +<dt><LibreMan></dt><dd> the reason I follow Hurd is because i would LOVE to have viable GPLv3 OS as opposed to GPLv2 Linux</dd> +<dt><antrik></dt><dd> that's not a good reason</dd> +<dt><LibreMan></dt><dd> there are people hard at work subverting Linux</dd> +<dt><antrik></dt><dd> first of all, we'd have to get rid of all Linux code</dd> +<dt><LibreMan></dt><dd> locking it down ... and Linus doesn't seem to care</dd> +<dt><antrik></dt><dd> also, if that's all you care about, it would be less work to implement a simple monolithic kernel from scratch</dd> +<dt><LibreMan></dt><dd> antrik: so why is hurd a good idea if it's so much harder to develop?</dd> +<dt><-- azeem (~mbanck@p5DF41DDE.dip0.t-ipconnect.de) hat das Netzwerk verlassen (Ping timeout: 240 seconds) +<LibreMan></dt><dd> antrik: I thought that was the reason all along ... to develop GNU mopatible kernel</dd> +<dt><Tekk_></dt><dd> LibreMan: what do you mean GNU compatible?</dd> +<dt><LibreMan></dt><dd> Tekk_: the philosophy of GNU</dd> +<dt><Tekk_></dt><dd> ah, yes they've always needed a gnu kernel</dd> +<dt><LibreMan></dt><dd> the reason why it was created in a first place</dd> +<dt><ArneBab></dt><dd> LibreMan: I just added a missing part in the article: </dd> +<dt><ArneBab></dt><dd> “And the fact that a translator is just a simple standalone program means that these can be shared and tested much more easily, opening up completely new options for lowlevel hacking, because it massively lowers the barrier of entry.</dd> +<dt><ArneBab></dt><dd> ”</dd> +<dt><LibreMan></dt><dd> ok, next question :) why is it so hard to make Hurd work?</dd> +<dt><ArneBab></dt><dd> because we are so few people… </dd> +<dt><LibreMan></dt><dd> I mean, it's in developement for 20 years or so, no?</dd> +<dt><Tekk_></dt><dd> LibreMan: it's never been done before too</dd> +<dt><LibreMan></dt><dd> ArneBab: well, one person developed Linux</dd> +<dt><ArneBab></dt><dd> One person make Linux basically work</dd> +<dt><Tekk_></dt><dd> LibreMan: there has *never* been a full microkernel outside of research, which is what hurd plans to be</dd> +<dt><Tekk_></dt><dd> LibreMan: yeah, one person made linux kinda work in a year, then basically handed it off to everyone to help</dd> +<dt><LibreMan></dt><dd> but if it's so much complicated to develop, is it worth it?</dd> +<dt><Tekk_></dt><dd> LibreMan: and that was with a well trodden path that everyone knwos</dd> +<dt><ArneBab></dt><dd> But for the Hurd to basically work means it already provides far more options than waat Linux did.</dd> +<dt><ArneBab></dt><dd> That’s why the foundation is harder: It makes everything else easier.</dd> +<dt><ArneBab></dt><dd> But at the moment it works.</dd> +<dt><ArneBab></dt><dd> And I think I’ll just repeat that: The Hurd works. It is not feature complete, but all the really hard parts work.</dd> +<dt><ArneBab></dt><dd> Missing are many of the hard (but not really hard) parts, like adding drivers.</dd> +<dt><ArneBab></dt><dd> (and then there are ultra hard features which are possible but currently layed off, but now I get into beat-em-up speech :) )</dd> +<dt><LibreMan></dt><dd> I would define "works" as I can install it right now and run stable system ... I do not think it worls in those terms</dd> +<dt><ArneBab></dt><dd> LibreMan: that I’d define as production system</dd> +<dt><youpi></dt><dd> LibreMan: define "stable"</dd> +<dt><Tekk_></dt><dd> LibreMan: I'm pretty sure linux didn't "work" by your definition when linus passed it off</dd> +<dt><ArneBab></dt><dd> But I can start a Hurd right now and code in it.</dd> +<dt><LibreMan></dt><dd> ArneBab: yeah, that's waht "works" means for me :)</dd> +<dt><ArneBab></dt><dd> I can start emacs</dd> +<dt><youpi></dt><dd> LibreMan: I wouldn't even call my linux "stable"</dd> +<dt><youpi></dt><dd> as I just need to unplug my external USB hdd to make it crash...</dd> +<dt><youpi></dt><dd> while in a hurd system, it'd just crash the corresponding ext2fs daemon only</dd> +<dt><LibreMan></dt><dd> youpi: well yes :) but you can function on it pretty successfully ...</dd> +<dt><ArneBab></dt><dd> LibreMan: Frankly all I’m missing for a production environment are USB support and Audio.</dd> +<dt><youpi></dt><dd> you can on a hurd system too</dd> +<dt><ArneBab></dt><dd> (and it should work on an OLPC)</dd> +<dt><LibreMan></dt><dd> youpi: without USB and sound? :P</dd> +<dt><ArneBab></dt><dd> Both are driver issues. No problem in the kernel.</dd> +<dt><youpi></dt><dd> I seldomly use USB and sound actually</dd> +<dt><youpi></dt><dd> and never for my actual work</dd> +<dt><-- Tekk_ (~user@2002:474d:d1e9:0:21d:72ff:fe24:4c37) hat das Netzwerk verlassen (Remote host closed the connection) +--></dt><dd> Tekk_ (~user@2002:474d:d1e9:0:21f:3aff:fe54:7cc3) hat #hurd betreten</dd> +<dt><LibreMan></dt><dd> youpi: yeah, but how many users can ay that?</dd> +<dt><youpi></dt><dd> so what?</dd> +<dt><youpi></dt><dd> how many users can install linux?</dd> +<dt><youpi></dt><dd> does that make it unsuccessful?</dd> +<dt><LibreMan></dt><dd> many people actually</dd> +<dt><youpi></dt><dd> well, many people don't care about USB and sound either</dd> +<dt><youpi></dt><dd> depends what you mean by "many"</dd> +<dt><LibreMan></dt><dd> compared to how many do not mind having USB and sound ...</dd> +<dt><youpi></dt><dd> just like depends what you mean by "stable"</dd> +<dt><youpi></dt><dd> so _basically_ it works</dd> +<dt><youpi></dt><dd> not for all users on earth of course</dd> +<dt><youpi></dt><dd> not for all linux users of course</dd> +<dt><youpi></dt><dd> but for a lot of them already</dd> +<dt><ArneBab></dt><dd> LibreMan: USB and Sound are just driver issues.</dd> +<dt><ArneBab></dt><dd> They are not part of the core functionality.</dd> +<dt><Tekk_></dt><dd> LibreMan: usb keyboards and mice work though</dd> +<dt><LibreMan></dt><dd> ArneBab: sure, but that doesn't matter ... user doen't care about the technicalities ...</dd> +<dt><Tekk_></dt><dd> I think</dd> +<dt><ArneBab></dt><dd> LibreMan: But for the Hurd it means that it’s no general unsolved problem, but just an issue of too little coders to do the work.</dd> +<dt><LibreMan></dt><dd> if it's driver, kernel, microkernel whatever ... does it work or not, that's what it comes down to</dd> +<dt><ArneBab></dt><dd> s/too little/too few/</dd> +<dt><LibreMan></dt><dd> so it's a matter of attracting more people to work on it</dd> +<dt><ArneBab></dt><dd> LibreMan: yes</dd> +<dt><ArneBab></dt><dd> The Arch people helped a lot with that, because 2 distributions is not just 2× one distribution (in it’s outside effect)</dd> +<dt><ArneBab></dt><dd> But we need more people who do the easy work.</dd> +<dt><ArneBab></dt><dd> relatively easy… </dd> +<dt><ArneBab></dt><dd> porting the 10-15% packages which just have PATH_MAX issues.</dd> +<dt><LibreMan></dt><dd> so there would need to be sufficient motivations for them to join developement ... so far I do not see any different than Free Software ideals</dd> +<dt><ArneBab></dt><dd> for example</dd> +<dt><ArneBab></dt><dd> jupp</dd> +<dt><ArneBab></dt><dd> plus some cool options.</dd> +<dt><ArneBab></dt><dd> and experimenting in low-level</dd> +<dt><ArneBab></dt><dd> “ever wanted to write your own filesystem from scratch - and test it without wrecking your box?”</dd> +<dt><LibreMan></dt><dd> I do not understand why FSF does not do something similar to GSoC</dd> +<dt><ArneBab></dt><dd> LibreMan: I assume “too little money”…</dd> +<dt><Tekk_></dt><dd> LibreMan: hurd is in the gsoc</dd> +<dt><LibreMan></dt><dd> yeah, that would be the obvious answer :) and the right onw I guess</dd> +<dt><ArneBab></dt><dd> Besides: antrik, do you know how jkkenig fares?</dd> +<dt><Tekk_></dt><dd> LibreMan: gsoc is a per project thing, and most of them don't need the help</dd> +<dt><ArneBab></dt><dd> jkoenig</dd> +<dt><LibreMan></dt><dd> Tekk_: I know ... I just do not like that a company like Google needs to sponsor it and "we" are not selfsufficient</dd> +<dt><ArneBab></dt><dd> LibreMan: well, too few people are used to pay for what they like instead of for what requires payment.</dd> +<dt><ArneBab></dt><dd> But that is changing.</dd> +<dt><LibreMan></dt><dd> ArneBab: exactly ...</dd> +<dt><LibreMan></dt><dd> things like Flattr are trying to change that mentalty</dd> +<dt><ArneBab></dt><dd> Besides (stable): Hurd runs the Hurd wiki.</dd> +<dt><ArneBab></dt><dd> http://www.bddebian.com/~hurd-web/</dd> +<dt><LibreMan></dt><dd> I'm quite surprised I did not know about this http://www.fossfactory.org</dd> +<dt><LibreMan></dt><dd> I was planning to make such a website myself ...</dd> +<dt><LibreMan></dt><dd> I do not understand why it doesn't get more publicity ... the way Kickstarted does</dd> +<dt>-*- ArneBab goes lurker, sons here +<jkoenig></dt><dd> ArneBab, I have exams till friday, I should be more present after that</dd> +<dt><Tekk_></dt><dd> what does the hello world translator do? XD</dd> +<dt><ArneBab></dt><dd> Tekk_: content = hello</dd> +<dt><antrik></dt><dd> ArneBab: I have no idea about the status of GSoC</dd> +<dt><antrik></dt><dd> I haven't even read my mails for a couple of weeks; so you probably know more than me</dd> +<dt><antrik></dt><dd> Tekk_: provide a pseudo-file with "hello world" as contents</dd> +<dt><Tekk_></dt><dd> ah</dd> +<dt><antrik></dt><dd> BTW, gvfs is actually my favourite example of why the Hurd architecture makes sense</dd> +<dt><antrik></dt><dd> they implemented an extra GNOME-specific VFS layer, that is mostly redundant with the kernel one, adding complexity, overhead, and not integrated with the rest of the system -- and the only reason they need it is because the kernel VFS of traditional systems is too limited</dd> +<dt><antrik></dt><dd> with the Hurd's decentralized VFS, they could have implemented everything they need trivially right in the system VFS layer</dd> +<dt><antrik></dt><dd> the question is not really what features are possible with the Hurd architecture: given enough effort, any feature can be implemented with any architecture. it's the amount of effort that differs, making some things *feasible* that are not on other systems</dd> +<dt><Tekk_></dt><dd> see: windows ME</dd> +<dt><antrik></dt><dd> there is no reason for example why things like isolated subenvironments couldn't be implemented on Linux. (and it fact it's clearly moving in that direction, with the virtualisation hype) -- but it requires a shitload of kernel changes. while on Hurd all it needs is a little userspace programming</dd> +<dt><antrik></dt><dd> and every new feature added to Linux container solutions require further kernel hacking</dd> +<dt><antrik></dt><dd> or every new feature added to FUSE</dd> +<dt><antrik></dt><dd> and so on</dd> +</dl> + +[[!tag open_issue_documentation]] diff --git a/community/weblogs/ArneBab/what_we_need.mdwn b/community/weblogs/ArneBab/what_we_need.mdwn new file mode 100644 index 00000000..4511eb64 --- /dev/null +++ b/community/weblogs/ArneBab/what_we_need.mdwn @@ -0,0 +1,39 @@ +We created a list of the things we still need for using the Hurd for in our day-to-day activities (work or hobby). + +As soon as these issues are taken care of, the Hurd offers everything we need for fullfilling most of our computing needs on at least one of our devices: + +- USB (5): Arne, ms, Michael, Emilio, antrik²³ +- Wireless (5): Arne, ms, Carl Fredrik, Michael (netbook), antrik (notebook) +- Sound (4): ms, Carl Fredrik, Michael, antrik² + +- SATA (2): Michael, (Emilio) +- Tested for modern machines°¹ (2): Emilio, antrik (notebook) +- Stable Xorg° (2): Emilio, antrik +- PPPoE (2): Carl Fredrik, antrik² + +- Graphical Desktop (1): Emilio +- Full featured high-resultion console which doesn’t need X (1): antrik +- Switching between console and X° (1): antrik +- full-featured browser (i.e. Firefox)°⁵ (1): antrik +- NFS working for climm, w3m and git (1): antrik⁴ +- mplayer with win32codecs (1): antrik³ +- gnash or alternatives (1): antrik³ + +°: Very likely needed by more people, but not named as most pressing issue. +¹: It’s unclear on which processors the Hurd would have problems. Please report it if you have one! +→ [info](http://www.mail-archive.com/bug-hurd@gnu.org/msg19105.html) +²: Would be OK to use a router box instead. +³: Not critical but would be convenient. +⁴: Only while *not* using Hurd as the only machine. +⁵: [We’re close to that](http://www.mail-archive.com/bug-hurd@gnu.org/msg19177.html). + +So, if one of these issues seems to be interesting for you, or you think “I can do that easily”, +why not become a Hurd hacker and add your touch? :) + +You can reach us in the [[mailing_lists]] and in [[irc]]. + +The sourcecode is in our [[source_repositories]] (git). When you want to check sources relevant for you, [DDE](http://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=dde) might be a good place to start for wireless and sound. USB on the other hand might need work in [gnumach](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/) ([[hacking_info|microkernel/mach/gnumach]]). + +Besides: “The great next stuff” is in the [incubator git repo](http://git.savannah.gnu.org/cgit/hurd/incubator.git/), including (among others) [clisp](http://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=clisp) (translators in lisp) and [nsmux](http://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/?h=nsmux) (dynamically setting translators on files for one command by accessing `file,,translator`). + +Happy hacking! diff --git a/community/weblogs/antrik.mdwn b/community/weblogs/antrik.mdwn new file mode 100644 index 00000000..6db88dd9 --- /dev/null +++ b/community/weblogs/antrik.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!inline +pages="community/weblogs/antrik/* and !community/weblogs/antrik/*/*" +show=0 +actions=no +rootpage="community/weblogs/antrik" postformtext="Add a new entry named:"]] diff --git a/community/weblogs/antrik/plan9-and-the-hurd-major-differences.mdwn b/community/weblogs/antrik/plan9-and-the-hurd-major-differences.mdwn new file mode 100644 index 00000000..9e6143bf --- /dev/null +++ b/community/weblogs/antrik/plan9-and-the-hurd-major-differences.mdwn @@ -0,0 +1,50 @@ +[[!meta copyright="Copyright © 2009 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="Major differences between Plan9 and the Hurd"]] + +There are some similarities between the Hurd and Plan 9 regarding the file +system handling -- but there are also very fundamental differences which go +far beyond monolithic vs. microkernel design: + +- The Hurd is UNIX (POSIX) compatible + +- While (almost) all services are attached to the file system tree, not + all services actually export a file system interface! + + Personally, I advocate using FS-based interfaces as much as possible. + Yet, there are some cases where they get very awkward and/or + inefficient, and domain-specific interfaces simply make a lot more + sense. + + Also, some Hurd services are indeed used to implement the file systems + in the first place -- they work below the FS level, and obviously + can't use an FS interface! + +- File systems are completely decentralized -- clients always talk to + the FS servers directly, without any central VFS layer. (I don't think + that's the case in Plan 9?) + + This offers much more flexibility -- the way the FS interfaces + themselves work can be modified. Many things can be implemented as + normal translators, that would require special VFS support on other + systems. (Extended attributes, VFS-based union mounts, local + namespaces, firmlink, magic file name suffixes etc.) + +- The system design allows users and applications to change almost all + aspects of the system functionality in the local environment easily + and without affecting other parts of the system. + + (This is possible with Plan 9 to some extent; but the Hurd allows it + at a much lower level -- including stuff like the filesystem + interfaces, access control mechanisms, program execution and process + management, and so on.) + +I hope I didn't forget any major differences... diff --git a/community/weblogs/hook.mdwn b/community/weblogs/hook.mdwn new file mode 100644 index 00000000..e9e083dc --- /dev/null +++ b/community/weblogs/hook.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Well as [[weblogs/ArneBab]] asked me to, I made a blog here in the Hurd's community section. + +So I suppose it's time for me to introduce myself. I'm a lawyer student just short of my masters' (called "diploma" here in Slovenia) and a hacker by heart. I've been using GNU/Linux for over a decade now, started on Slackware and continued on Gentoo. I try to give back to the community by being an active member (posting bugs and whatnot), coordinating the local FSFE Fellowship group and lately also lending a hand to the Gentoo Licenses team. I keep a [website and blog](http://matija.suklje.name) of my own and occasionally even write some short sad piece of sloppy code. + +Small disclaimer about my coding abilities: + + 10 IANAC IAAL + +For those who wonder about what IANAC IAAL means — it's the oposite of IANAL IAAC and means "I Am Not A Coder, I Am A Lawyer" ;) + +[[!inline +pages="community/weblogs/hook/* and !community/weblogs/hook/*/*" +show=0 +actions=no +rootpage="community/weblogs/hook" postformtext="Add a new entry named:"]] diff --git a/community/weblogs/hook/Post.mdwn b/community/weblogs/hook/Post.mdwn new file mode 100644 index 00000000..904ff372 --- /dev/null +++ b/community/weblogs/hook/Post.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +You might wonder why this post is not titled "First Post" or anything similar showing off my arrival in the Hurd community. + +Well, that's both easy and hard to explain — easy, because it doesn't take much words and hard because of their impact. + +The thing is it may well be my first and last post here. + +I am not making this decision lightly, because I care a lot for FOSS and although I'm new and not much of a coder (`GOTO 10`), I can see how important GNU Hurd is and needs more advocates and contributors. + +Sadly, as I stated [on my normal blog](http://matija.suklje.name/?q=node/205), to be more help to the FOSS community, I actually have to help less. I have to make the painful choice to select from many FOSS-related things I care about deeply only a few I'm really good at and discard the rest. And since law is my forte, that's where I'll help and leave coding to those who are better at it. + +That too is freedom and probably the biggest burden of it. + +I'm pretty sure most people here haven't had the time to get to know me yet, but I'll still miss you. And thank you guys for your outstanding work in making the system that gives the user the most freedom possible! **Please, keep up the work!** + + *hook out → just out (hopefully not forever)* + +P.S. `10 IANAC IAAL` diff --git a/community/weblogs/tschwinge.mdwn b/community/weblogs/tschwinge.mdwn new file mode 100644 index 00000000..fc0d2ace --- /dev/null +++ b/community/weblogs/tschwinge.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!inline +pages="community/weblogs/tschwinge/* and !community/weblogs/tschwinge/*/*" +show=0 +actions=no +rootpage="community/weblogs/tschwinge" postformtext="Add a new entry named:"]] diff --git a/community/weblogs/tschwinge/2009-06-23_split_patch_and_git_rebase_--interactive.mdwn b/community/weblogs/tschwinge/2009-06-23_split_patch_and_git_rebase_--interactive.mdwn new file mode 100644 index 00000000..bd08060e --- /dev/null +++ b/community/weblogs/tschwinge/2009-06-23_split_patch_and_git_rebase_--interactive.mdwn @@ -0,0 +1,545 @@ +[[!meta copyright="Copyright © 2009 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="splitting a patch into three, and then some git rebase +--interactive"]] + +I was revisiting the issue of getting the Hurd's code base compiled with recent +versions of GCC. Specifically, there were a lot of duplicate symbols shown at +linking time, and all these were related to `inline` functions. Originally, in +2007, we had solved this problem already (or rather, shifted it) by using GCC's +`-fgnu89-inline` option, but as we [[!GNU_Savannah_patch 6840 desc="saw now"]], +that one obviously doesn't help anymore if third-party code is using the Hurd's +unfixed header files. + +So I was revisiting this issue. I was already prepared that this would take +some hours, with lots of editing, compiling cycles, plus some analyzing of the +binaries. So I made up a fresh repository for this work. + + $ mkdir hurd-ei + $ cd hurd-ei/ + $ git init + [...] + $ git remote add savannah git://git.savannah.gnu.org/hurd/hurd.git + $ git fetch + [...] + +Switch to a new topic-branch. + + $ git checkout -b master-ei savannah/master + Branch master-ei set up to track remote branch master from savannah. + Switched to a new branch 'master-ei' + +(*`ei`* is short for `extern inline`.) + +The first thing to do was to disable that `-fgnu89-inline` option, so I edited +`Makeconf` where it was added to `CFLAGS`. + +I started editing, compiling, editing, compiling, and so on. + +Finally, the tree was in a shape where everything was building fine and the +resulting libraries contained the symbols they should, etc. + +I committed the whole junk as one *big blob* commit, to store it in a safe +place (you never know with these Hurd machines...), and to continue working on +it the next day. + + $ git commit -a + +For the commit message, I already mostly assembled a `ChangeLog`-style log. +Then: + + $ git format-patch savannah/master.. + 0001-Bla.patch + +... and here is [[0001-Bla.patch.bz2]] (compressed). + + +The next day, a.k.a. today, in a different Git repository. + + $ git checkout -b master-fix_inline savannah/master + Branch master-fix_inline set up to track remote branch master from savannah. + Switched to a new branch 'master-fix_inline' + $ bunzip2 < ../some/where/0001-Bla.patch.bz2 | git am + Applying: Bla. + +The *big blob* is now on top of savannah/master (which was +`2772f5c6a6a51cf946fd95bf6ffe254273157a21`, by the way -- in case that you want +to reproduce this tutorial later, simply substitute `savannah/master` with +`2772...`). + +By then, I had come to the conclusion that the commit essentially was fine, but +should be split into two, and the `configure` hunk shouldn't be in there. So +be it. + +So, the `HEAD` of the active branch is our *big blob* commit that we want to +work on. Check with `git show HEAD`: + + $ git show HEAD + commit 93e97f3351337c349e2926f4041e61bc487ef9e6 + Author: Thomas Schwinge <tschwinge@gnu.org> + Date: Tue Jun 23 00:27:28 2009 +0200 + + Bla. + + * console-client/timer.h (fetch_jiffies): Use static inline instead of extern + inline. + * ext2fs/ext2fs.h (test_bit, set_bit, clear_bit, dino, global_block_modified) + (record_global_poke, sync_global_ptr, record_indir_poke, sync_global) + (alloc_sync): Likewise. + * libftpconn/priv.h (unexpected_reply): Likewise. + * term/term.h (qsize, qavail, clear_queue, dequeue_quote, dequeue) + (enqueue_internal, enqueue, enqueue_quote, unquote_char, char_quoted_p) + (queue_erase): Likewise. + * ufs/ufs.h (dino, indir_block, cg_locate, sync_disk_blocks, sync_dinode) + (swab_short, swab_long, swab_long_long): Likewise. + * term/munge.c (poutput): Use static inline instead of inline. + + * libdiskfs/diskfs.h: Apply inline optimization only ifdef + [__USE_EXTERN_INLINES]. Use __extern_inline instead of extern inline. + * libftpconn/ftpconn.h: Likewise. + * libpipe/pipe.h: Likewise. + * libpipe/pq.h: Likewise. + * libshouldbeinlibc/idvec.h: Likewise. + * libshouldbeinlibc/maptime.h: Likewise. + * libshouldbeinlibc/ugids.h: Likewise. + * libstore/store.h: Likewise. + * libthreads/rwlock.h: Likewise. + * libdiskfs/extern-inline.c: Adapt to these changes. + * libftpconn/xinl.c: Likewise. And don't #include "priv.h". + * libpipe/pipe-funcs.c: Likewise. + * libpipe/pq-funcs.c: Likewise. + * libshouldbeinlibc/maptime-funcs.c: Likewise. And remove superfluous + includes. + * libstore/xinl.c: Likewise. + * libthreads/rwlock.c: Likewise. + + * Makeconf (CFLAGS): Don't append $(gnu89-inline-CFLAGS). + * pfinet/Makefile (CFLAGS): Append $(gnu89-inline-CFLAGS). + + diff --git a/Makeconf b/Makeconf + index e9b2045..236f1ec 100644 + --- a/Makeconf + +++ b/Makeconf + @@ -65,7 +65,7 @@ INCLUDES += -I$(..)include -I$(top_srcdir)/include + CPPFLAGS += $(INCLUDES) \ + -D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64 \ + $($*-CPPFLAGS) + -CFLAGS += -std=gnu99 $(gnu89-inline-CFLAGS) -Wall -g -O3 \ + +CFLAGS += -std=gnu99 -Wall -g -O3 \ + [...] + +We want to undo this one commit, but preserve its changes in the working +directory. + + $ git reset HEAD^ + Makeconf: locally modified + configure: locally modified + console-client/timer.h: locally modified + ext2fs/ext2fs.h: locally modified + libdiskfs/diskfs.h: locally modified + libdiskfs/extern-inline.c: locally modified + libftpconn/ftpconn.h: locally modified + libftpconn/priv.h: locally modified + libftpconn/xinl.c: locally modified + libpipe/pipe-funcs.c: locally modified + libpipe/pipe.h: locally modified + libpipe/pq-funcs.c: locally modified + libpipe/pq.h: locally modified + libshouldbeinlibc/idvec.h: locally modified + libshouldbeinlibc/maptime-funcs.c: locally modified + libshouldbeinlibc/maptime.h: locally modified + libshouldbeinlibc/ugids.h: locally modified + libstore/store.h: locally modified + libstore/xinl.c: locally modified + libthreads/rwlock.c: locally modified + libthreads/rwlock.h: locally modified + pfinet/Makefile: locally modified + term/munge.c: locally modified + term/term.h: locally modified + ufs/ufs.h: locally modified + +Now, `HEAD` points to the commit before the previous `HEAD`, i.e. `HEAD^`. +Again, check with `git show HEAD`: + + $ git show HEAD + commit 2772f5c6a6a51cf946fd95bf6ffe254273157a21 + Author: Samuel Thibault <samuel.thibault@ens-lyon.org> + Date: Thu Apr 2 23:06:37 2009 +0000 + + 2009-04-03 Samuel Thibault <samuel.thibault@ens-lyon.org> + + * exec.c (prepare): Call PREPARE_STREAM earlier to permit calling + finish_mapping on E even after errors, as is already done in do_exec. + + diff --git a/exec/ChangeLog b/exec/ChangeLog + index 5a0ad1d..a9300bf 100644 + --- a/exec/ChangeLog + +++ b/exec/ChangeLog + @@ -1,3 +1,8 @@ + +2009-04-03 Samuel Thibault <samuel.thibault@ens-lyon.org> + + + + * exec.c (prepare): Call PREPARE_STREAM earlier to permit calling + + finish_mapping on E even after errors, as is already done in do_exec. + + + 2008-06-10 Samuel Thibault <samuel.thibault@ens-lyon.org> + + * elfcore.c (TIME_VALUE_TO_TIMESPEC): Completely implement instead of + diff --git a/exec/exec.c b/exec/exec.c + index 05dc883..cb3d741 100644 + --- a/exec/exec.c + +++ b/exec/exec.c + @@ -726,6 +726,9 @@ prepare (file_t file, struct execdata *e) + + e->interp.section = NULL; + + + /* Initialize E's stdio stream. */ + + prepare_stream (e); + [...] + +Luckily, Git saves the previous (i.e. before the `git reset`) `HEAD` reference +as `ORIG_HEAD`. Have a look at it with `git show ORIG_HEAD` -- it contains the +*big blob* commit, including the preliminary commit message -- just what HEAD +was before: + + $ git show ORIG_HEAD + commit 93e97f3351337c349e2926f4041e61bc487ef9e6 + Author: Thomas Schwinge <tschwinge@gnu.org> + Date: Tue Jun 23 00:27:28 2009 +0200 + + Bla. + + * console-client/timer.h (fetch_jiffies): Use static inline instead of extern + inline. + [...] + + diff --git a/Makeconf b/Makeconf + index e9b2045..236f1ec 100644 + --- a/Makeconf + +++ b/Makeconf + @@ -65,7 +65,7 @@ INCLUDES += -I$(..)include -I$(top_srcdir)/include + CPPFLAGS += $(INCLUDES) \ + -D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64 \ + $($*-CPPFLAGS) + -CFLAGS += -std=gnu99 $(gnu89-inline-CFLAGS) -Wall -g -O3 \ + +CFLAGS += -std=gnu99 -Wall -g -O3 \ + [...] + +OK, now let's pick the files that we want to have in the first of the +envisioned two commits: these are the *static inline instead of extern inline* +and *apply inline optimization only...* sections. + + $ git add console-client/timer.h ext2fs/ext2fs.h [...] libthreads/rwlock.c + +Oh, we forgot something: now that we're preparing this stuff to go into the +*master* repository, update the copyright years. Edit, edit, edit, and then, +again: + + $ git add console-client/timer.h ext2fs/ext2fs.h [...] libthreads/rwlock.c + +Now Git's staging area contains the changes that we want to commit (and the +working directory contains the rest of the *big blob*). Commit these `add`ed +files, and use *big blob*'s commit message as a template for the new one, as it +already contains most of what we want (don't forget to chop off the unneeded +parts). + + $ git commit -c ORIG_HEAD + Waiting for Emacs... + [master-fix_inline 51c15bc] Use static inline where appropriate. + 6 files changed, 50 insertions(+), 51 deletions(-) + $ git show HEAD + commit c6c9d7a69dea26e04bba7010582e7bcd612e710c + Author: Thomas Schwinge <tschwinge@gnu.org> + Date: Tue Jun 23 00:27:28 2009 +0200 + + Use static inline where appropriate and use glibc's __extern_inline machinery. + + * console-client/timer.h (fetch_jiffies): Use static inline instead of extern + inline. + * ext2fs/ext2fs.h (test_bit, set_bit, clear_bit, dino, global_block_modified) + (record_global_poke, sync_global_ptr, record_indir_poke, sync_global) + (alloc_sync): Likewise. + * libftpconn/priv.h (unexpected_reply): Likewise. + * term/term.h (qsize, qavail, clear_queue, dequeue_quote, dequeue) + (enqueue_internal, enqueue, enqueue_quote, unquote_char, char_quoted_p) + (queue_erase): Likewise. + * ufs/ufs.h (dino, indir_block, cg_locate, sync_disk_blocks, sync_dinode) + (swab_short, swab_long, swab_long_long): Likewise. + * term/munge.c (poutput): Use static inline instead of inline. + + * libdiskfs/diskfs.h: Apply inline optimization only ifdef + [__USE_EXTERN_INLINES]. Use __extern_inline instead of extern inline. + * libftpconn/ftpconn.h: Likewise. + * libpipe/pipe.h: Likewise. + * libpipe/pq.h: Likewise. + * libshouldbeinlibc/idvec.h: Likewise. + * libshouldbeinlibc/maptime.h: Likewise. + * libshouldbeinlibc/ugids.h: Likewise. + * libstore/store.h: Likewise. + * libthreads/rwlock.h: Likewise. + * libdiskfs/extern-inline.c: Adapt to these changes. + * libftpconn/xinl.c: Likewise. And don't #include "priv.h". + * libpipe/pipe-funcs.c: Likewise. + * libpipe/pq-funcs.c: Likewise. + * libshouldbeinlibc/maptime-funcs.c: Likewise. And remove superfluous + includes. + * libstore/xinl.c: Likewise. + * libthreads/rwlock.c: Likewise. + + diff --git a/console-client/timer.h b/console-client/timer.h + index 4204192..5e64e97 100644 + --- a/console-client/timer.h + +++ b/console-client/timer.h + @@ -1,5 +1,7 @@ + /* timer.h - Interface to a timer module for Mach. + - Copyright (C) 1995,96,2000,02 Free Software Foundation, Inc. + + + + Copyright (C) 1995, 1996, 2000, 2002, 2009 Free Software Foundation, Inc. + + + Written by Michael I. Bushnell, p/BSG and Marcus Brinkmann. + + This file is part of the GNU Hurd. + @@ -54,7 +56,7 @@ int timer_remove (struct timer_list *timer); + /* Change the expiration time of the timer TIMER to EXPIRES. */ + void timer_change (struct timer_list *timer, long long expires); + + -extern inline long long + +static inline long long + [...] + +As you can see, `HEAD` now points to the new commit on top of the current +branch. (`ORIG_HEAD` doesn't change.) + +On to the next, and last one, only two changes should be left: the `Makeconf` +and `pfinet/Makefile` ones. + + $ git status + # On branch master-fix_inline + # Your branch is ahead of 'savannah/master' by 1 commit. + # + # Changed but not updated: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: Makeconf + # modified: configure + # modified: pfinet/Makefile + # + # Untracked files: + # (use "git add <file>..." to include in what will be committed) + # + # 0001-Bla.patch + # autom4te.cache/ + # hurd_extern_inline_fix.patch?file_id=18191 + no changes added to commit (use "git add" and/or "git commit -a") + +Alright, there is as well still the `configure` hunk that we want to get rid +of. But first for the real second commit, after editing for again adding the +copyright year update: + + $ git add Makeconf pfinet/Makefile + $ git commit -c ORIG_HEAD + Waiting for Emacs... + [master-fix_inline 6a967d1] We're now C99 inline safe -- apart from the Linux code in pfinet. + 2 files changed, 6 insertions(+), 3 deletions(-) + +Check that we're in a clean state now: + + $ git status + # On branch master-fix_inline + # Your branch is ahead of 'savannah/master' by 2 commits. + # + # Changed but not updated: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: configure + # + # Untracked files: + # (use "git add <file>..." to include in what will be committed) + # + # 0001-Bla.patch + # autom4te.cache/ + # hurd_extern_inline_fix.patch?file_id=18191 + no changes added to commit (use "git add" and/or "git commit -a") + +Oops, we forgot something... + + $ git checkout -- configure + +Now, our tree is clean again. (Check with `git status`.) + +By now, we came to the conclusion that the first of the two commits should have +been further split into two separate ones. Of course, essentially we would do +the same splitting again that we've done just now -- but how to easily modify +the first commit, now that we have another one on top of it? + +Alright, `git rebase --interactive` to the rescue -- let's interactively +*`rebase`* the last two commits, to modify them as wanted. + + $ git rebase --interactive HEAD~2 + Waiting for Emacs... + +Emacs wants us to tell which commits we want to keep as they are (`pick`), +which should be merged into others (`squash`), and which we want to `edit`. In +our scenario, we want to `edit` the first one and `pick` the second one. +Change the file thusly and close it. + + Stopped at 5becbb5... Use static inline where appropriate and use... + You can amend the commit now, with + + git commit --amend + + Once you are satisfied with your changes, run + + git rebase --continue + +We want to undo this first commit to split it into two. Again, use `git reset` +for that, while preserving the commit's changes in the working directory. + + $ git reset HEAD^ + console-client/timer.h: locally modified + [...] + +Pick the set of files that we want to have in the first of the envisioned two +commits: the *static inline instead of extern inline* section, and commit them, +again using the previous commit message as a template for the new one: + + $ git add console-client/timer.h ext2fs/ext2fs.h [...] term/munge.c + $ git commit -c ORIG_HEAD + Waiting for Emacs... + [detached HEAD 51c15bc] Use static inline where appropriate. + 6 files changed, 50 insertions(+), 51 deletions(-) + +Next part: *apply inline optimization only...*. Again, `git add` those files +that shall be part of the next commit, i.e. all remaining ones. As before, use +the previous commit message as a template. + + $ git add libdiskfs/diskfs.h [...] libthreads/rwlock.c + $ git commit -c ORIG_HEAD + Waiting for Emacs... + [detached HEAD 8ac30ea] [__USE_EXTERN_INLINES]: Use glibc's __extern_inline machinery. + 16 files changed, 508 insertions(+), 356 deletions(-) + +Now we're done with splitting that commit into two. (Check with `git status` +that we didn't forget anything.) What's missing is getting back the other +commit on top of the two now-split ones: + + $ git rebase --continue + Successfully rebased and updated refs/heads/master-fix_inline. + +Here we go. The other commit has been applied on top of the two new ones. + +Due to time-honored tradition, I always double-check what I have just +committed, before distributing it to the world: + + $ git log --reverse -p -C --cc savannah/master.. + +... and promptly, I recognize some changes that shouldn't be in there: when +using it on some files, Emacs' `copyright-fix-years`, aside from indeed fixing +the list of copyright years, and adding the current year, also changed *GPL +... version 2* into *version 3*, which would be nice, but which we can't do for +the moment. The error is present only in the first and second commit. If it +were in only in the third (the last) one, simply editing the files, and then +using `git commit --amend` would be the solution. But again there is the +problem about how to modify the first (`HEAD~2`) and second (`HEAD~1`, or +`HEAD^`) commit now that there is another one on top of it. By now, we know +the solution: + + $ git rebase --interactive HEAD~3 + Waiting for Emacs... + +This time, we need to `edit` the first and second commits, and `pick` the third +one. + + Stopped at ffd215b... Use static inline where appropriate. + You can amend the commit now, with + + git commit --amend + + Once you are satisfied with your changes, run + + git rebase --continue + +`git show` (which defaults to showing `HEAD`, by the way) can again be used to +have a look at the current `HEAD` (which is the first of the three commits), +and then we revert the unwanted changes in the editor, resulting with the +following changed files: + + $ git status + # Not currently on any branch. + # Changed but not updated: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: ext2fs/ext2fs.h + # modified: libftpconn/priv.h + # modified: term/munge.c + # modified: term/term.h + # modified: ufs/ufs.h + # + # Untracked files: + # (use "git add <file>..." to include in what will be committed) + # + # 0001-Bla.patch + # autom4te.cache/ + # hurd_extern_inline_fix.patch?file_id=18191 + no changes added to commit (use "git add" and/or "git commit -a") + +Then, we can -- as `git rebase` suggested above -- *amend* the existing `HEAD` +commit with these changes (`--amend` and `--all`), reusing `HEAD`'s commit +message without spawning an editor (`-C HEAD`): + + $ git commit --amend -C HEAD --all + [detached HEAD c6c9d7a] Use static inline where appropriate. + 6 files changed, 45 insertions(+), 46 deletions(-) + +Continue with the next commit: + + $ git rebase --continue + Stopped at 8ac30ea... [__USE_EXTERN_INLINES]: Use glibc's __extern_inline machinery. + You can amend the commit now, with + + git commit --amend + + Once you are satisfied with your changes, run + + git rebase --continue + +Again, have a look at the commit (`git show`), revert the unwanted changes, +*amend* `HEAD`, and continue to the next commit: + + $ git commit --amend -C HEAD --all + [detached HEAD 9990dc6] [__USE_EXTERN_INLINES]: Use glibc's __extern_inline machinery. + 16 files changed, 500 insertions(+), 348 deletions(-) + $ git rebase --continue + Stopped at 6a967d1... We're now C99 inline safe -- apart from the Linux code in pfinet. + You can amend the commit now, with + + git commit --amend + + Once you are satisfied with your changes, run + + git rebase --continue + +Two files are left to be edited (`git show`, etc., again), and finally: + + $ git commit --amend -C HEAD --all + [detached HEAD 241c605] We're now C99 inline safe -- apart from the Linux code in pfinet. + 2 files changed, 5 insertions(+), 2 deletions(-) + $ git rebase --continue + Successfully rebased and updated refs/heads/master-fix_inline. + +That's it. `git log --reverse -p -C --cc savannah/master..` now looks as nice +as can be. + + +Of course, this is only a small insight of what is possible to do with `git +rebase` and friends -- see the manual for further explanations. diff --git a/community/weblogs/tschwinge/2009-06-23_split_patch_and_git_rebase_--interactive/0001-Bla.patch.bz2 b/community/weblogs/tschwinge/2009-06-23_split_patch_and_git_rebase_--interactive/0001-Bla.patch.bz2 Binary files differnew file mode 100644 index 00000000..4a682c86 --- /dev/null +++ b/community/weblogs/tschwinge/2009-06-23_split_patch_and_git_rebase_--interactive/0001-Bla.patch.bz2 diff --git a/community/weblogs/tschwinge/2009-06-24_importing_from_gnu_arch_into_git.mdwn b/community/weblogs/tschwinge/2009-06-24_importing_from_gnu_arch_into_git.mdwn new file mode 100644 index 00000000..f397e75b --- /dev/null +++ b/community/weblogs/tschwinge/2009-06-24_importing_from_gnu_arch_into_git.mdwn @@ -0,0 +1,104 @@ +[[!meta copyright="Copyright © 2009 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="converting from GNU arch to Git -- without direct repository +access"]] + +I wanted to import an old GNU arch repository into Git, but only had HTTP +access via ArchZoom. I spent quite some time to try teaching `git archimport` +to use HTTP access to that repository, but this didn't work out. Too bad -- +but at least, using ArchZoom, I was able to get the individual revisions' +tarballs: + + $ ls -1 *.tar.gz + bpf--devel--0.0--base-0.tar.gz + bpf--devel--0.0--patch-1.tar.gz + bpf--devel--0.0--patch-10.tar.gz + bpf--devel--0.0--patch-11.tar.gz + bpf--devel--0.0--patch-12.tar.gz + bpf--devel--0.0--patch-2.tar.gz + bpf--devel--0.0--patch-3.tar.gz + [...] + bpf--devel--0.0--patch-9.tar.gz + bpf--release--0.1--base-0.tar.gz + bpf--release--0.1--patch-1.tar.gz + bpf--release--0.1--patch-2.tar.gz + [...] + bpf--release--0.1--patch-8.tar.gz + +I unpacked these: + + $ for f in *.tar.gz; do tar -xz < "$f" || echo >&2 "$f" failed; done + +The last revision's tree apparently contains all previous revisions' commit +information (author, date, message), so use that: + + $ cp -a ↩ + bpf--release--0.1--patch-8/{arch}/bpf/bpf--devel/bpf--devel--0.0/info@hurdfr.org--hurdfr/patch-log ↩ + d-patch-log + $ cp -a ↩ + bpf--release--0.1--patch-8/{arch}/bpf/bpf--release/bpf--release--0.1/info@hurdfr.org--hurdfr/patch-log ↩ + r-patch-log + +... and extract the information that we need: + + $ base=bpf--devel--0.0-- && ↩ + for f in d-patch-log/*; do ↩ + grep < "$f" ^Creator: | head -n 1 ↩ + | { read j c && ↩ + echo "$c" | sed s%' <.*'%% ↩ + > "$base""$(basename "$f")".author_name && ↩ + echo "$c" | sed -e 's%.*<%%' -e 's%>.*%%' ↩ + > "$base""$(basename "$f")".author_email; } && ↩ + grep < "$f" ^Standard-date: | head -n 1 | { read j d && echo "$d" ↩ + > "$base""$(basename "$f")".author_date; } && ↩ + { grep < "$f" ^Summary: | head -n 1 | { read j m && echo "$m"; } && ↩ + echo && sed < "$f" '1,/^$/d'; } ↩ + > "$base""$(basename "$f")".log ↩ + || echo >&2 "$f" failed; ↩ + done + $ base=bpf--release--0.1-- && ↩ + for f in r-patch-log/*; [...] + +(Of course, I could have used something more elaborate than shell scripting...) + +Remove the GNU arch stuff that we don't need anymore: + + $ find bpf--*/ -type d \( -name {arch} -o -name .arch-ids \) -print0 ↩ + | xargs -0 rm -r + +The `base-0` revisions are actually either empty (the `devel` one) or +equivalent to the previous revision (the `release` one), so remove these: + + $ rm -rf bpf--devel--0.0--base-0 bpf--release--0.1--base-0 + +Finally, import all the other ones: + + $ mkdir g && ( cd g/ && git init ) + $ for d in bpf--d*-? bpf--d*-?? bpf--r*; do ↩ + test -d "$d"/ || continue && ↩ + ( cd g/ && ↩ + rsync -a --delete --exclude=/.git ../"$d"/ ./ && ↩ + git add . && ↩ + GIT_AUTHOR_NAME="$(cat ../"$d".author_name)" ↩ + GIT_AUTHOR_EMAIL="$(cat ../"$d".author_email)" ↩ + GIT_AUTHOR_DATE="$(cat ../"$d".author_date)" ↩ + git commit -F ../"$d".log -a ); ↩ + done + +Voilà! + + +**Update 2009-06-25:** + +Half a day later, [[HurdFr]] published a `git archimport`-converted repository +-- which was *identical* to my hand-crafted one (apart from having +`git-archimport-id:` tags in the commit messages, and the first (empty) commit +not being stripped off). :-) diff --git a/config_edittemplate/open_issue_page.mdwn b/config_edittemplate/open_issue_page.mdwn index 9e11b0d7..172614eb 100644 --- a/config_edittemplate/open_issue_page.mdwn +++ b/config_edittemplate/open_issue_page.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -30,9 +30,4 @@ open_issue_mig]], etc.; remove the backslash, of course) to make sure that your report shows up on the relevant lists of open issues. Select *Preview* on this page to see all tags that are currently in active use. -[[!map pages="tag/* and !tag/*/* and !tag/open_issue_mach" -show=title]] - -Most of them should be self-explanatory. *fixed_in_debian* is used to tag -items that have been fixed in the Debian GNU/Hurd distribution, but not yet in -the upstream sources. +[[!inline pages=tag raw=yes feeds=no]] diff --git a/config_edittemplate/regular_page.mdwn b/config_edittemplate/regular_page.mdwn index 8650bdf7..3f95f9b5 100644 --- a/config_edittemplate/regular_page.mdwn +++ b/config_edittemplate/regular_page.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this diff --git a/contributing.mdwn b/contributing.mdwn index a5b3a34e..eaffe7b2 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -1,49 +1,47 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010, 2011, 2012 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -So, you are interested in contributing to the GNU Hurd project? +[[!tag stable_URL]] -Welcome! Every single contribution is very much encouraged! +So, you are interested in contributing to the GNU Hurd project? Welcome! +Every single contribution is very much encouraged. -There are various ways of contributing, read on about contributing to... +There are various ways to contribute; read up on contributing to... -[[!toc levels=3]] +[[!toc levels=4]] If someone of you is lurking around here and would like to contribute, but -feels she / he could do so better under formal mentoring: please speak up at -one of the [[regular_IRC_meetings|IRC#regular_meetings]]! +feels she / he could do so better under formal mentoring: please +[[contact_us]], or just speak up at one of the [[regular IRC +meetings|IRC#regular_meetings]]! +We also have a list of [[open_issues]] and one for more elaborate [[project +ideas|community/gsoc/project_ideas]] - the latter originally written for the +[[Google Summer of Code|community/gsoc]], but not exclusively. Even just +investigating open issues, without being able to fix them, can be useful, +because a issue that has been tracked down often becomes obvious to address for +people who know the stuff -- but these people typically don't have the time +that is needed to track down the issues. -# Documentation - -## These Web Pages - -Please read about [[how_to_contribute_to_these_web_pages|web_pages]]. - - -# The System Itself -There are essential two kinds of Hurd system designs. +<a name="hurd_on_mach"></a> +# Improve GNU Hurd Running on GNU Mach -<a name="hurd_on_mach"> </a> -## Hurd on Mach - -For one there's the implementation of the *[[Hurd]] running on the -[[GNU_Mach_microkernel|microkernel/mach/gnumach]]*. This is what is commonly -meant when people are talking about GNU/Hurd systems. +The *[[GNU Hurd|hurd]] running on the [[GNU Mach +microkernel|microkernel/mach/gnumach]]* is what is commonly meant when people +are talking about GNU/Hurd systems. This system has mostly been designed and implemented [[in the '90s|history]]. It works and is usable. -For example, these web pages are rendered on a [GNU/Hurd -system](http://www.bddebian.com/cgi-bin/uptime). +For example, these web pages have been rendered on a GNU/Hurd system. You can try it out for yourself: for getting access, installing [[Debian_GNU/Hurd|hurd/running/debian]] will probably be the easiest and most @@ -54,6 +52,8 @@ things you're going to work on (and on your internet connection), this may be an easy way of getting used to Hurd systems. Installing in a virtual machine is another possibility, see the page about [[running_a_Hurd_system|hurd/running]] for the full story. +In particular, running a Debian GNU/Hurd [[QEMU image|hurd/running/QEMU]] may +be a viable alternative. Then you can either play around and eventually strive to do something useful or -- if you want -- [[ask_us|contact_us]] to assign something to you, depending @@ -61,34 +61,103 @@ on the skills you have and the resources you intend to invest. Please spend some time with thinking about the items in this [[questionnaire]]. -Before you can significantly contribute, take some time to learn about the -system, e.g., [[microkernels_for_beginners|microkernel/for_beginners]]. Until -you can do the basic exercises listed there, you won't be able to significantly -contribute to the Hurd. +Before you can significantly contribute to the operating system itself, you'll +need to take some time to learn about the system, for example: +[[microkernels for beginners|microkernel/for_beginners]], [[Mach's +concepts|microkernel/mach/concepts]], [[Hurd's concepts|hurd/concepts]], the +*[[hurd/critique]]*. Until you can understand and do the basic exercises +listed there, you won't be able to significantly contribute to the Hurd. For more reading resources, please see these web pages, for example, [[Hurd_documentation|hurd/documentation]] and [[Mach_documentation|microkernel/mach/documentation]] for links to a bunch of documents. -### Porting Packages -Debian is currently the Hurd distribution of choice among Hurd users and -developers. +<a name="porting"></a> +## Porting Packages + +Please [[contact_us]] before spending a lot of time on the following porting +tasks: some work may already have been done that you can base your work upon. + +For guidelines, please have a look at the dedicated [[porting_page|hurd/porting]]. + + +### Debian GNU/Hurd -Here is a -[[list_of_Debian_packages_that_need_porting|hurd/running/debian/porting]]. +[[!template id=note text="""#### Goal: Debian Wheezy Release Canditate + +There is a goal of getting Debian GNU/Hurd into shape for a technology +preview/release candidate with Debian Wheezy (expected towards the end of 2012 +or beginning of 2013). + +The *to do* list is on <http://wiki.debian.org/Debian_GNU/Hurd>."""]] + +The following missing packages/missing functionality block a lot of other +packages, and are thus good candidates for porting, in order to increase +archive coverage: + +* umount functionality in busybox +* hyperestraier +* sane-backends-extras +* ruby1.9.1 + +Here is a [[list of packages that need porting|hurd/running/debian/porting]]. You can also just [[install_Debian_GNU/Hurd|hurd/running/debian]] and find what doesn't work or suit you and try to improve that. -### Open Issues +Or, you can pick one from the [list of failing +packages](http://people.debian.org/~sthibault/failed_packages.txt). + + +## Open Issues + +There is a list of [[open_issues]]. This list includes everything from bug +reports to open-ended research questions. + + +<a name="insta-dev-env"></a> +## Instant Development Environment -Here is a list of [[open_issues]]. +<!-- I don't like this being here. At least not in this form. This just +duplicates information that is available in other places. (Or should be +available in other places, in more elaborate form.) +The idea of a one-stop development environment is not bad (I like that), but +I'd do this differently. For example, we should add some Git submodules to the +master hurd.git repository (which is currently empty), to branches that are +known to build and interface correctly with current GNU/Hurd system +installations (thus including TLS, etc.), and also add in my cross-gnu scripts +and a simple build machinery so this is usable from GNU/Linux (and other +systems), and so on and so forth. -<a name="hurd_on_modern_microkernel"> </a> -## Hurd on a modern microkernel +I'll have to think about it some more. + +--[[tschwinge]]. --> + +*This is a very brief guide to get your development environment set up. Pester ArneBab @ irc.freenode.net on IRC if something does not work :)* +([[!taglink open_issue_documentation]]) + +* Install qemu-kvm via your distros packages. +* Download the [qemu image](http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz): `wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz` +* Unpack it: `tar xf debian-hurd.img.tar.gz` +* Run it: `qemu-kvm -m 512 -no-kvm-irqchip -drive cache=writeback,index=0,media=disk,file=debian-hurd.img` # …irq… is a currently necessary fix due to some changes in Linux. Optionally use `--curses` to keep your keyboard layout. If need be modprobe kvm_amd, kvm intel and kvm to get kvm support (which is much, much faster). See also: [kvm FAQ](http://www.linux-kvm.org/page/FAQ). +* login as root +* `apt-get update` +* `apt-get install -y git mercurial emacs vim` +* `apt-get build-dep -y hurd gnumach` +* `git clone git://git.sv.gnu.org/hurd/hurd.git` +* `git clone git://git.sv.gnu.org/hurd/gnumach.git` +* `git clone git://git.sv.gnu.org/hurd/incubator.git` +* Get more from the [repo list](http://git.savannah.gnu.org/cgit/hurd/). +* Read the docs on these pages. +* Start hacking. +* For shutting down, use `reboot`, then press `c` in grub and issue halt (to avoid filesystem corruption). Adding `--no-reboot` to the qemu line should help, too. + + +<a name="hurd_on_modern_microkernel"></a> +# Design / Research: GNU Hurd on a Modern Microkernel Developers [[have_identified|hurd/critique]] a number of problem with the *Hurd on Mach* system. Problems, that can not easily be fixed by bug-fixing the @@ -101,9 +170,49 @@ itself is more a research project than a *sit down and implement/code/hack* project. If you're interested in contributing in this area, knowing the *Hurd on Mach* -system nevertheless is a prerequisite. At least have a deep look at the -documentation pointers given in the previous section. Also read through the -[[HurdNG|hurd/ng]] section. +system (see [[above|contributing#hurd_on_mach]]) nevertheless is a +prerequisite. At least have a deep look at the documentation pointers. Also +read through the [[HurdNG|hurd/ng]] section. Please send email to the [[mailing lists/l4-hurd]] mailing list for discussing this post-Mach system design. + + +# Documentation + + +## Technical Writer + +Our hackers (programmers) typically do what their kind always does: they code. +What they don't like too much is documenting their wonderful achievements. On +the other hand, there are people (you?) who enjoy documenting technical +matters, so don't hesitate to [[contact_us]] if technical documentation shall +be your contribution to GNU Hurd development. + + +## Web Pages + +Please read about [[how_to_contribute_to_these_web_pages|web_pages]]. + + +# Final Words -- Difficulties + +Please note that doing substantial contributions to a project as big and as +encompassing as the GNU Hurd is not a trivial task. For working on the GNU +Hurd's inner guts and getting useful work done, you have to plan for a +many-months learning experience which will need sufficient self-motivation. +Working on an advanced operating system kernel isn't something you can do in a +few free minutes -- even less so without any previous [[kernel]] hacking +experience. + +Likewise, the Linux kernel maintainers are stating the exactly same +difficulties, which is well presented by Jonathan Corbet in his 2010 Linux +Kernel Summit report for the opening sessions about [*welcoming of +newcomers*](http://lwn.net/Articles/412639/). + +But of course, none of this is meant to be dismissive, or to scare you away -- +on the contrary: just [[start +using|hurd/running]] the GNU Hurd, and either notice yourself what's not +working as expected, or have a look at one of the [[Open Issues]], and we shall +see if you'll evolve to be the next core Hurd hacker! +You'll *just* have to get excited about it! diff --git a/contributing/copyright_assignment.mdwn b/contributing/copyright_assignment.mdwn new file mode 100644 index 00000000..b65594de --- /dev/null +++ b/contributing/copyright_assignment.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2006, 2007, 2008, 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 +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]]."]]"""]] + +If you have pieces of code or documentation to contribute, then, in order to +install them into our [[source_repositories]], you have to assign the copyright +of your changes to the [Free Software Foundation](http://www.fsf.org/). + +The assignment for [[GNU Mach|microkernel/mach/gnumach]] additionally covers +[[microkernel/mach/mig/GNU_MIG]] (which used to be a component of GNU Mach, and +logically still is). + +The assignment for [[GNU Hurd|hurd]] additionally covers the separate +[[source_repositories/incubator]], [[libpthread]], [[hurd/translator/procfs]], +[[hurd/translator/unionfs]], [[microkernel/viengoos]], +[[web|contributing/web_pages]] repositories, and possibly more. + +Amongst others, the assignments for [[binutils]], [[GCC]], [[GDB]], [[glibc]] +are separate ones. + +Please [[contact_us]] to request the needed forms. diff --git a/contributing/discussion.mdwn b/contributing/discussion.mdwn new file mode 100644 index 00000000..5a6bfd7c --- /dev/null +++ b/contributing/discussion.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_documentation]] + + +# One-stop Development Environment + +Invent something. + + +# Mailing Lists + +Add link to [[mailing_lists]] to page, and suggest following these. diff --git a/contributing/questionnaire.mdwn b/contributing/questionnaire.mdwn index bc548b64..28c69f74 100644 --- a/contributing/questionnaire.mdwn +++ b/contributing/questionnaire.mdwn @@ -26,6 +26,11 @@ items and spend some time thinking about those. projects are all within the *Hurd* topic, but are vastly different projects. +* How much time do you have? + + Do you plan to work on just a small project, or do you have time for + longer development? + * How is your expertise about system and kernel programming? Sadly we don't have the ressources to teach you from ground-up. We will -- diff --git a/contributing/web_pages.mdwn b/contributing/web_pages.mdwn index f1388bc2..b2e96121 100644 --- a/contributing/web_pages.mdwn +++ b/contributing/web_pages.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Contribute to the Web Pages"]] @@ -48,38 +48,50 @@ we do have some simple requests. Please try to match the *tone* of your topics and edits with the existing topics. If we all pull in the same direction these pages will be more useful for everyone, especially for our own use. +### Which Pages to Work on? + +If you don't know which pages to work on, please have a look at those tagged +with [[tag/open_issue_documentation]]. Typically, you'll have to look at the +pages' source code (Markdown) to see which parts the tag applies to. + +### News Items + +There are [[more detailed instructions about editing news items|news]]. + +<a name="staging_area"> ## Staging Area +</a> When you commit changes, either using the web interface or checking them in -into the repository, they'll not become visible on -<http://www.gnu.org/software/hurd/> immediatelly, but first of all only on +into the repository; they won't become visible on +<http://www.gnu.org/software/hurd/> immediately, but on <http://www.bddebian.com:8888/~hurd-web/> instead. The former set of pages, the official GNU Hurd web appearance, will be updated periodically (but -manually) from the latter one, where every edit is visible immediatelly. This +manually) from the latter one, where every edit is visible immediately. This is so that we have a chance to have the pages make fit for appearance on `www.gnu.org`, but you are nevertheless able to work on all pages unrestrictedly. -# Edit Via the Web Interface +# Editing via the Web Interface -When you found a page you want to work on, just follow the *Edit* link on the -top of the page. When doing this for the first time, this will first transfer -you to a page where you have to create an account. After logging in, you -can edit the pages. +When you have found a page you want to work on, just follow the *Edit* link at the +top of the page. When doing this for the first time, this will first redirect +you to a page where you will have to create an account. After logging in, you +can edit pages. # Working on a Checkout of the Git Repository -(!) What is being described here are only the basics. The checkouts are +(!) What is being described here is only the basics. The checkouts are completely valid Git repositories and can (and want to) be treated as such. Consult the Git documentation about how to shuffle around with branches, how to rename files, how to add arbitrary data files, and so on. (!) Before attempting any bigger editing work (to which you are sincerely -invited!) be sure to check the involved pages' *Discussion* subpages (linked +invited!) be sure to check the involved pages' *Discussion* sub-pages (linked from the pages' header line) and in there take down (short) notes about the -editing endeavors you're going to undertake. Doing so should help to (a) avoid +editing endeavours you're going to undertake. Doing so should help to (a) avoid double work and (b) avoid merge conflicts if you install your changes into the main repository. @@ -99,35 +111,41 @@ identity: ## Getting the Sources -For being able to do a checkout from which you can later directly push your +To be able to do a checkout from which you can later directly push your changes back into the master repository, you need a [[shell_account_on_*flubber*|public_hurd_boxen]] and need to be a member of -the *hurd-web* group. (It's also very much recommenable that you set up your local -ssh configuration as advised on that page.) If you have an account on there: +the *hurd-web* group. (It's also recommended that you set up your local +SSH configuration as advised on that page.) If you have an account on there: $ git clone flubber:~hurd-web/hurd-web [dest] If you don't have such an account or don't have your login data handy, you can -still get the pages the read-only way. +still get pages the read-only way. -Note that this -- currently -- is not the data from the master server, but from -a mirror of it, so it may be lacking behind a bit from time to time. - - $ git clone git://git.savannah.gnu.org/hurd/web.git [dest] + $ git clone git://flubber.bddebian.com/~hurd-web/hurd-web [dest] If that also doesn't work out, you have yet another chance: pull over the HTTP -protocol. Not very efficient (read: rather inefficient), but it works. This +protocol. Not very efficient (read: rather inefficient), but it works. This is also read-only. $ git clone http://www.bddebian.com:8888/git/hurd-web [dest] -For all cases: if you omit `[dest]` it will default to `hurd-web`. +Or, you can check out the Savannah repository: + + $ git clone git://git.savannah.gnu.org/hurd/web.git [dest] + +See <http://git.savannah.gnu.org/cgit/hurd/web.git>. If you're using the `ssh` +protocol, and you're a member of the Hurd's [[rules/Savannah_group]], you can +also push to this repository. The disadvantage of pushing to the Savannah +repository is that there is no [[ikiwiki]] installation where the pushed +changes are immediatelly rendered and viewable by everyone. -Later, you can just `cd` into the `hurd-web` directory and run a `git pull` to -get hold of the latest changes others have been installing in the mean time. -(In most cases, even better would be to do a `git fetch`, followed by a `git -rebase origin/master` to avoid useless *Merge branch ...* messages. See the -Git documentation for details.) +For all cases: if you omit `[dest]` it will default to `hurd-web` for the +`bddebian.com` repositories, or `web` for a Savannah clone. + +Later, you can just `cd` into the `hurd-web` or `web` directory, and, for +example, run `git pull` to get hold of the latest changes others have been +installing in the mean time. ## Editing the Content @@ -191,7 +209,7 @@ Or, to directly create a new page: $ w3m 'file:///$LIB/ikiwiki-w3m.cgi/hurd-web.cgi?page=open_issues/gnumach_has_a_bug&do=create' Note that the changes you do via `w3m` will not be committed to the VCS (see -[[render_locally]] for details). +[[render_locally]] for details.) ## Publish Your Changes @@ -225,3 +243,12 @@ running, the following is all you have to do: If you don't have an MTA running, you'll have to find another way: either post the `*.patch` files to <web-hurd@gnu.org> or upload them somewhere for us to download them from. + + +# New Year Procedure + +Files to update: + + * `/config_edittemplate/*.mdwn`, `/.templates/autotag.tmpl` + * `/contributing/web_pages/news/skeleton.mdwn` + * `/copyright.mdwn` diff --git a/contributing/web_pages/news.mdwn b/contributing/web_pages/news.mdwn new file mode 100644 index 00000000..920fdba8 --- /dev/null +++ b/contributing/web_pages/news.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2009, 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="""How to prepare and publish a "Quarter of the Hurd" for the last +quarter"""]] + +We prepare a *Quarter of the Hurd* in the file [[qoth_next]]. The idea is +to record to-be-published changes in that file at they time they arise, and +then publish them en bloc at the end of the quarter. There are instructions for +[[writing_the_qoth]]. + + * At the end of the quarter: prepare for publishing the QotH, then send the raw + Markdown text to the mailing list, asking for feedback. + + * ..., and publish. + + $ git mv contributing/web_pages/news/qoth_next.mdwn news/YYYY-MM.mdwn + + Edit the news entry's *meta date* value to the timestamp when the news + entry is published. We have to set that one manually, as otherwise the + timestamp of the news entry file's creation will be taken, which is (much) + earlier, and not what we want. We do not set the *meta updated* value, as + it's correct to update that one upon further modifications of the news + entries. + + $ git cp contributing/web_pages/news/skeleton.mdwn contributing/web_pages/news/qoth_next.mdwn + $ git commit -m 'QotH YYYY-MM.' + $ git push origin master diff --git a/contributing/web_pages/news/moth_next.mdwn b/contributing/web_pages/news/moth_next.mdwn new file mode 100644 index 00000000..e430f650 --- /dev/null +++ b/contributing/web_pages/news/moth_next.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta redir=qoth_next]] diff --git a/contributing/web_pages/news/qoth_next.mdwn b/contributing/web_pages/news/qoth_next.mdwn new file mode 100644 index 00000000..4b7a6f63 --- /dev/null +++ b/contributing/web_pages/news/qoth_next.mdwn @@ -0,0 +1,118 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +<!-- Date when the news item is (to be) pulished (important for RSS feeds). +Will be set by tschwinge when publishing. +[[!meta date="YYYY-MM-DD HH:MM UTC"]] +--> + +<!-- This is just a skeleton. Use it to create a new QotH. --> + +A quarter of the Hurd, Q1 of 2012: *TODO*, *TODO*, and *TODO*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +<!--basic structure of a QotH entry. Adapt, reduce and add points as needed. At the end, try to make the text flow as a unified whole.--> + +* Jeremie Koenig released the final report on his GSoC project Java on Hurd http://www.bddebian.com/~hurd-web/user/jkoenig/java/report along with a summary of his changes and the challenges he bested http://lists.gnu.org/archive/html/bug-hurd/2012-01/msg00062.html . + +* Richard Braun [libpcap](http://lists.gnu.org/archive/html/bug-hurd/2012-01/msg00059.html) bringing wireshark and [pcap_inject](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00000.html) for easier network testing. + +* Samuel Thibault prepared dde in incubator, making about half the Linux network drivers compile on the Hurd http://lists.gnu.org/archive/html/bug-hurd/2012-02/msg00037.html . Also he added the netdde debian package and testing notes http://lists.gnu.org/archive/html/bug-hurd/2012-02/msg00038.html . + +* Peter O'Gorman pushed the fix from Samuel Thibault to fix libtool on the Hurd. http://lists.gnu.org/archive/html/bug-hurd/2012-02/msg00023.html + +* Samuel Thibault merged the slab branch, finishing Maksym Planetas GSoC work on a better memory allocator http://lists.gnu.org/archive/html/bug-hurd/2012-02/msg00010.html . + +* Thomas Schwinge [moved](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00063.html) the translators [cvsfs](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=cvsfs/master), [libfuse](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=libfuse/master) and [smbfs](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=smbfs/master) into the incubator git repository, reducing the barrier of entry to improving them, so integrating cvs and samba in the filesystem and using FUSE translators can be stabilized more easily. + +* Svante Signell [added](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00060.html) the basics of ADA support by making gnat build. This gives us the option to use provable programs optimized for embedded systems with the Hurd. + +* Maksym Planeta published some [performance tests of tmpfs](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00040.html), showing a speedup from 22s with ramfs and ext2fs to 16s with tmpfs for apt-get calls. An obvious usecase for tmpfs are [faster Hurd LiveCDs](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00050.html). + +* Samuel Thibault [improved debugging in GNU Mach](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00032.html) by making the debugger aware of the difference between kernel space and user space. This should substantially reduce the development time for features in Mach by giving [nicer stack traces](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00047.html). + +* Ludovic Courtès added [a continuous testing framework](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00019.html) using a Nix-based GNU QEMU image. Since Hurd can now be built using „Nix“ (german for nothing), how about asking a colleague to revise his image of the Hurd as vaporware and showing him vapor chugging away on a compile of your favorite free program? If you don’t want to install it yourself, you can also check the [automatic tests on hydra](http://hydra.nixos.org/jobset/gnu/hurd-master) ([background](http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00104.html)). + +* Ludovic Courtes [fixed invalid port deallocation in `symlink'](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00013.html) and [made console-run resilient against missing /dev/console](http://lists.gnu.org/archive/html/bug-hurd/2012-03/msg00002.html), improving the overall reliability of the system. + +* Pino Toscano improved the POSIX compliance of the Hurd [for nanosleep](http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00130.html) [ptsname_r](http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00122.html), +[getlogin_r](http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00121.html), [getgroups](http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00120.html) and [sendto](http://lists.gnu.org/archive/html/bug-hurd/2012-06/msg00009.html), making it easier to port POSIX programs. + +* Richard brown improved memory mapping [with a red-black tree](http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00109.html), which should speed up memory access. + +* Thomas Schwinge [improved the Hurd build system](http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00087.html), making it easier to get in: „running autoreconf is all you need“. + +* Thomas DiModica [merged](http://lists.gnu.org/archive/html/bug-hurd/2012-06/msg00018.html) the cthreads to pthreads patch to Hurd master and [added a branch for it](http://lists.gnu.org/archive/html/bug-hurd/2012-07/msg00087.html) to make it easier to work on getting Hurd to use the more current pthreads. + +* Samuel Thibault [added TLS support](http://lists.gnu.org/archive/html/bug-hurd/2012-05/msg00046.html), further improving the standards conformance of the Hurd and paving the way for C++11x. + +* Roland McGrath [merged many libc changes](http://lists.gnu.org/archive/html/bug-hurd/2012-05/msg00033.html) for upstream inclusion, reducing the maintenance load for getting recent improvements of libc. + +* Samuel Thibault [made iconx build](http://lists.gnu.org/archive/html/bug-hurd/2012-06/msg00004.html), which fullfills a requirement for FTBFS. + +------ Q3 ------ + +* Richard Braun [added a VM page cache](http://lists.gnu.org/archive/html/bug-hurd/2012-07/msg00031.html) for better response times of the Hurd - along with fixes to bugs in several programs exposed by the increased freedom of the memory allocation of the kernel. + +* Pino Toscano improved the POSIX compliance of the Hurd for [fsync](http://lists.gnu.org/archive/html/bug-hurd/2012-08/msg00067.html) and +[ptrace](http://lists.gnu.org/archive/html/bug-hurd/2012-08/msg00068.html), making it easier to port POSIX programs. + +This quarter [hurd hacker] [item] + +Also … + +[our hackers] … + +Mainly thanks to … + +Additionally … + +And … + +Now, as a final note, we want to share a story about real-life debugging with the +Hurd; IRC, freenode, #hurd, 2012-03-02: + + <youpi> yay GNU/Hurd + <youpi> I have added i_translator check in e2fsck, it was missing + <youpi> I had a volume that was keeping making ext2fs crash + <youpi> with a reproductible scenario + <youpi> could easily work out it was i_translator, then add a + check to e2fsck, run it, which indeed fixed, them, and voilà, + ext2fs was working again + <youpi> all that on the same machine with *no* system reboot + <youpi> just ext2fs restart :) + + +So if you want to [reason for contibuting to the Hurd], +please [[get in contact|contact_us]] -- and maybe already grab the [[source +code|source_repositories]]. + +--- + +The **GNU Hurd** is the GNU project's replacement for the Unix kernel. It is a +collection of servers that run on the Mach microkernel to implement file +systems, network protocols, file access control, and other features that are +implemented by the Unix kernel or similar kernels (such as Linux). [[More +detailed|hurd/documentation]]. + +**GNU Mach** is the microkernel upon which a GNU Hurd system is based. It +provides an Inter Process Communication (IPC) mechanism that the Hurd uses to +define interfaces for implementing in a distributed multi-server fashion the +services a traditional operating system kernel provides. [[More +detailed|microkernel/mach/gnumach]]. + +<!--see [[contributing/web_pages/news/writing_the_qoth]] for additional information on writing the QotH.--> + +"""]] diff --git a/contributing/web_pages/news/skeleton.mdwn b/contributing/web_pages/news/skeleton.mdwn new file mode 100644 index 00000000..bb39cd6e --- /dev/null +++ b/contributing/web_pages/news/skeleton.mdwn @@ -0,0 +1,60 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +<!-- Date when the news item is (to be) pulished (important for RSS feeds). +Will be set by tschwinge when publishing. +[[!meta date="YYYY-MM-DD HH:MM UTC"]] +--> + +<!-- This is just a skeleton. Use it to create a new QotH. --> + +A quarter of the Hurd, QN of YYYY: *TODO*, *TODO*, and *TODO*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +<!--basic structure of a QotH entry. Adapt, reduce and add points as needed. At the end, try to make the text flow as a unified whole.--> + +This quarter [hurd hacker] [item] + +Also … + +[our hackers] … + +Mainly thanks to … + +Additionally … + +And … + +So if you want to [reason for contibuting to the Hurd], +please [[get in contact|contact_us]] -- and maybe already grab the [[source +code|source_repositories]]. + +--- + +The **GNU Hurd** is the GNU project's replacement for the Unix kernel. It is a +collection of servers that run on the Mach microkernel to implement file +systems, network protocols, file access control, and other features that are +implemented by the Unix kernel or similar kernels (such as Linux). [[More +detailed|hurd/documentation]]. + +**GNU Mach** is the microkernel upon which a GNU Hurd system is based. It +provides an Inter Process Communication (IPC) mechanism that the Hurd uses to +define interfaces for implementing in a distributed multi-server fashion the +services a traditional operating system kernel provides. [[More +detailed|microkernel/mach/gnumach]]. + +<!--see [[contributing/web_pages/news/writing_the_qoth]] for additional information on writing the QotH.--> + +"""]] diff --git a/contributing/web_pages/news/writing_the_qoth.mdwn b/contributing/web_pages/news/writing_the_qoth.mdwn new file mode 100644 index 00000000..88542255 --- /dev/null +++ b/contributing/web_pages/news/writing_the_qoth.mdwn @@ -0,0 +1,79 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]]."]]"""]] + +# Short Guide for Writing the QotH + +The not yet published next Quarter of Hurd the can found at [[contributing/web_pages/news/qoth_next]]. + +## Individual News Items + +The basic structure for a news item is as follows: *\[person with](link) did +\[task with}(link to testable code/patch) which brings us further towards +\[[goal]] by [short, easily understandable description of the contribution]*. + +Each news item should show a step towards the mission of the Hurd. From +[[community/weblogs/antrik/hurd-mission-statement]] you can +glean the following basic goals: + + * Better support for day-to-day desktop use (more packages, more stable, more + drivers, easier to setup, ...). + * More user freedom and possibilities for programs/translators. + * Technical advancement. + * More unique or at least interesting features. + * Attract more developers and/or users. + +The reason for this structure is to resolve the problem that many people think +that the Hurd won't ever be finished by concentrating on the improvements and +the steps towards completing our mission -- but only once they have actually +been done (to avoid showing anything which might become vaporware). + + +## Sources for News Items + +Watch these places for news: + + * GNU + + * <http://lists.gnu.org/archive/html/bug-hurd/YYYY-MM/threads.html> + + * <http://lists.gnu.org/archive/html/commit-hurd/YYYY-MM/threads.html> + + * <http://lists.gnu.org/archive/html/help-hurd/YYYY-MM/threads.html> + + * <http://lists.gnu.org/archive/html/web-hurd/YYYY-MM/threads.html> + + * <http://lists.gnu.org/archive/html/hurd-devel/YYYY-MM/threads.html> + + * <http://sourceware.org/ml/libc-alpha/YYYY-MM/> + + Also Git log. + + * (<http://sourceware.org/ml/libc-hacker/YYYY-MM/>) + + * (<http://sourceware.org/ml/glibc-cvs/YYYY-qQ/>) + + Better use the Git log. + + * <http://lists.gnu.org/archive/html/l4-hurd/YYYY-MM/threads.html> + + * Debian + + * <http://lists.debian.org/debian-hurd/YYYY/MM/> + + * <http://lists.debian.org/debian-glibc/YYYY/MM/> + + * Arch Hurd + + * <http://www.archhurd.org/news.php> + + * <http://planet.archhurd.org/> + + * (<http://lists.archhurd.org/devel/maillist.html>) diff --git a/copyright.mdwn b/copyright.mdwn index 8cd0aa21..31f24e32 100644 --- a/copyright.mdwn +++ b/copyright.mdwn @@ -1,2 +1,2 @@ -Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 The Contributing -Authors +Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 +The Contributing Authors diff --git a/dde.mdwn b/dde.mdwn new file mode 100644 index 00000000..7d341da5 --- /dev/null +++ b/dde.mdwn @@ -0,0 +1,42 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + * [[community/gsoc/project ideas/driver glue code]] + + * [[open issues/user-space device drivers]] + + * [[open issues/device drivers and io systems]] + +--- + +# Documentation + + * <http://demo.tudos.org/dsweeper_tutorial.html> + + Why device drivers in user space; different possibilities for getting + device drivers; DDE's origins and rationale. + + * <http://wiki.tudos.org/DDE/DDEKit>, + <http://os.inf.tu-dresden.de/pipermail/l4-hackers/2009/004291.html> + + Structural overview of the components. + + +# Discussion + +DDE essentially is a glue layer to embed Linux device drivers into another +environement. In the DDE case, this *other environment* is a user-space task +-- compared to the GNU Mach kernel having a *in-kernel* Linux 2.0 device +drivers glue code (cf. paper by Goel et al.). + + +# Source Code + + * <http://www.inf.tu-dresden.de/index.php?node_id=1584&ln=en> diff --git a/documentation.mdwn b/documentation.mdwn index 8559eff1..5ab08bfb 100644 --- a/documentation.mdwn +++ b/documentation.mdwn @@ -1,12 +1,63 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +You are interested in getting familiar with the GNU/Hurd system architecture, +or specific components of it? Here is a collection of texts to read. + +/!\ A lot of stuff is still missing ([[!taglink open_issue_documentation]]). + +[[!toc levels=3]] + + +# Basic Knowledge + +Before you can go details, you have to learn the basics about operating system +architecture. Yes, really. + + +## Operating Systems Basics + +Books. Etc. + + +## GNU/Hurd System Architecture + + +### Capabilities + +[[!toggleable id=shapiro_capintro_1999 text="""[[!template id=note +text="*[[shapiro\_capintro\_1999|capability]]*: +{{$capability#shapiro_capintro_1999}}. +{{$capability#shapiro_capintro_1999_text}}."]]"""]] + + * Our use of [[capabilities|capability]]. The + {{$capability#wikipedia_capability-based_security}} article. + Alternatively/additionally, [[!toggle id=shapiro_capintro_1999 + text="[shapiro\_capintro\_1999]"]]. + + In the GNU/Hurd system, a [[capability]] is represented by a [[Mach + port|microkernel/mach/port]]. + + * {{$capability#wikipedia_object-capability_model}}. Albeit not directly + tailored at the GNU/Hurd operating system architecture, this artice anyway + does a good job at describing general principles of a [[capability]]-based + system architecture. + + +# FAQ + +[[FAQ]] + + +# Specific Components Documentation for... @@ -16,9 +67,19 @@ Documentation for... * [[MIG|microkernel/mach/mig/documentation]] + * [[UNIX]] + + +# Presentations + +## 2004 + + * 2004-07-02 + + Ognyan Kulev, *presentation of the Hurd*, at the seminar *LIO and friends*, + <http://debian.fmi.uni-sofia.bg/~ogi/hurd/liofest-20040702-hurd.ppt>, in + Bulgarian. -# [[Unix]] Programming +# General - * *The C Programming Language* by Brian W. Kernighan and Dennis M. Ritchie, - [order from - Amazon](http://www.amazon.com/Programming-Language-Prentice-Hall-Software/dp/0131103628/ref=pd_bxgy_b_img_a) + * [[Media_Appearances]] diff --git a/donate.mdwn b/donate.mdwn index 22b218c1..6293633e 100644 --- a/donate.mdwn +++ b/donate.mdwn @@ -1,54 +1,106 @@ -[[!meta copyright="Copyright © 2003, 2006, 2007, 2008 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2006, 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] If you feel like donating goods or money for the work the developers are doing, then we're happy to confirm that this is indeed possible. Of course we'd -really like to have you working with us on the system, but if you're feeling -generous we won't stop you either. +really like to have you working with us on the system and become a +[[contributor|contributing]], but if you're feeling generous we won't stop you +either. -Note that you can't donate directly to the Hurd project, but only to either the -Free Software Foundation or individually to the developers. Donations to the -Free Software Foundation are tax deducible, see <http://fsf.org/donate>. +[[!toc levels=2]] -If you've got more money on hand than hacking time, you might consider buying -some [maintenance points](http://g10code.com/products.html#maintpoints) (EUR 10 a point) to -help the Hurd along. From the [g10 Code](http://www.g10code.com/products.html) -site: -> Hurd Maintenance Points are special: Some of our employees are well known -> Hurd hackers in their spare time; collected points for this program will be -> given to them in form of paid time. +# Free Software Foundation -See also this related -[mailing-list](http://mail.gnu.org/archive/html/help-hurd/2003-04/msg00044.html) -thread. +The Free Software Foundation is the GNU project's principal organizational +sponsor. [Donations to the FSF](http://donate.fsf.org/) are tax deducible. +However, they can't accept donations addressed directly to/specifically for the +GNU Hurd project. -And for further motivation, some words of wisdom from Marcus Brinkmann: -> By the way, if you are more on the speculating side, then it can't harm to -> just buy one or two maintenance points. That means that at some time I get -> an incentive to start the hacking, and there is a chance that when I start I -> don't stop for a while, and just continue on my private time (as I did for -> the last five years, if I might add that ;). +<a name="FOSS_Factory"></a> +# FOSS Factory -- a Bounty System for GNU Hurd Work + +[[!template id=note text=""" + +> Hey, I have more money than time or programming skills, and I'd like to help +> GNU Hurd development specifically -- how can we arrange for this, where can I +> donate money for GNU Hurd development? + +If you're dwelling on such thoughts, here is the answer; here you can donate +money for GNU Hurd development. + +"""]] + + +As its principal idea, [FOSS Factory](http://www.fossfactory.org/), means to +serve as a hub and organizational platform for connecting Free/Open Source +Software developers with monetary sponsors. From +<http://www.fossfactory.org/aboutus.php>: + +[[!img foss_factory/logo.png align=right link=no]] + +> FOSS Factory's mission is to accelerate the advancement of free/open source +> software by helping people collaborate on the design, funding, and +> development of innovative software ideas. All software solutions produced +> using our system are released under free/open source licenses. Our unique +> model brings the best of innovators from both the entrepreneurial and FOSS +> worlds together to solve real world problems using the mass resources of the +> FOSS community. + +In very general words, their modus operandi is that the community (including +the monetary sponsors) works together with the developers on splitting up tasks +into suitable and assessable sub-projects as necessary, and then act as the +reviewing instance, deciding on such sub-projects' success (and payment, +successively). For more details see their [System +Overview](http://www.fossfactory.org/overview.php). + +For now, we can assume that the amount of money to be made by working on a GNU +Hurd task in this framework is likely to be a symbolic amount only, rather than +being representative for the real effort that needs to be invested. Software +development is expensive, mostly due to the amount of time that is needed for +completing any non-trivial task. Instead, these bounties should be regarded as +an attraction/reward, perhaps also simply as a motivation for a developer to +focus on one specific problem, and bringing it to completion. + + +## Working on a Task and/or Suggesting/Donating for a New Task + +In principle, any Hurd-related development task is applicable (for example, +from the [[GSoC project ideas|community/gsoc/project_ideas]], or from the +[[open_issues]] list), but it is of course recommendable to match sponsors' +ideas with those of the developers and maintainers. For this, if you want to +sponsor a project, but don't know which one to choose, or if you want to work +on a bounty that is not yet listed on the site, we suggest that you talk to us +first, either publically on the [[bug-hurd mailing +list|mailing_lists/bug-hurd]] or privately on <hurd-maintainers@gnu.org>, if +you prefer. + +Both for supporting (donating) as well as claiming a bounty, you have to +register [at their site](http://www.fossfactory.org/), and proceed from there. +Please don't hesitate to ask [[Thomas Schwinge|tschwinge]] if you need help. + +Continue to explore the [[list of open bounties|tag/bounty]]. + + +# Hurd Developer Meetings Another possibility is to meet with the Hurd developers at a [[meeting|community/meetings]] and spend them a pizza or beer or both or similar. -# Developers - -<small>(alphabetically)</small> +# Individual Developers -<!-- TODO. Need some real ikiwiki way of adding such anchors. --> +Sorted alphabetically. <a name="Marcus_Brinkmann"></a> ## Marcus Brinkmann diff --git a/donate/foss_factory/logo.png b/donate/foss_factory/logo.png Binary files differnew file mode 100644 index 00000000..07a62b5e --- /dev/null +++ b/donate/foss_factory/logo.png diff --git a/hurd/ng/issues_with_mach.mdwn b/download.mdwn index 9fac498f..542a9e5b 100644 --- a/hurd/ng/issues_with_mach.mdwn +++ b/download.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,5 +8,6 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] - * [[open issues/Resource Management Problems]] - * [[Critique]] +[[!tag stable_URL]] + +[[!meta redir=source_repositories]] diff --git a/dsl.mdwn b/dsl.mdwn new file mode 100644 index 00000000..28f70d7d --- /dev/null +++ b/dsl.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="DSL"]] + +A *DSL* is a *domain-specific language* ([[!wikipedia Domain-specific_language +desc="Wikipedia article"]]). + +Compared to general-purpose programming languages, these are a candidate for +[[open_issues/formal_verification]]. + +DSLs are frequently used as [[IDL]]s for implementing [[RPC]] systems, but can +also used for other portions of the [[kernel]], such as [[capability]] systems. +This is exemplified for [[microkernel/Barrelfish]] in +{{$microkernel/barrelfish#fof_plos09}}, for example. diff --git a/emulation.mdwn b/emulation.mdwn index 9e6a5e55..3238209b 100644 --- a/emulation.mdwn +++ b/emulation.mdwn @@ -1,20 +1,11 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -# External - - * [*Emulation: Role-Playing for - Computers*](http://www.informit.com/articles/printerfriendly.aspx?p=659522), - an article by David Chisnall. - - -# See Also - - * [[Virtualization]]. +[[!meta redir=virtualization]] diff --git a/extensibility.mdwn b/extensibility.mdwn index 01b1f3b1..17cd5e51 100644 --- a/extensibility.mdwn +++ b/extensibility.mdwn @@ -1,17 +1,18 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] An extensible system is one that enables extensibility. Enabling extensibility means providing non-privileged mechanisms to extend existing objects and to introduce new objects. [[UNIX]] is generally not an extensible system as it does -not generally facilitate the hooking of system calls. For instance, there is +not generally facilitate the hooking of [[system call]]s. For instance, there is no way to hook into the virtual file system. This has motivated the introduction of separate, parallel interfaces by both the GNOME and KDE projects to provide users a more integrated view of their objects. diff --git a/faq.mdwn b/faq.mdwn new file mode 100644 index 00000000..9167ede6 --- /dev/null +++ b/faq.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="FAQ"]] + +Also see the... + + * [[microkernel FAQ|microkernel/faq]], + + * [[GNU Hurd FAQ|hurd/faq]], + + * [[running GNU Hurd FAQ|hurd/running/faq]], + + * [[Debian GNU/Hurd FAQ|hurd/running/debian/faq]]. + +[[!inline +pages="faq/* and !*/discussion" +show=0 +feeds=no +actions=yes +rootpage="faq" postformtext="Add a new item titled:"]] diff --git a/faq/binary_compatibility.mdwn b/faq/binary_compatibility.mdwn new file mode 100644 index 00000000..e9dfcdb8 --- /dev/null +++ b/faq/binary_compatibility.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2012-01-13: + + <veganman> sothere's absolutelyno way,evenslowly to run i386 linuxcode + under hurd/i386? Ihave a small app, commercial, which I have to get + running there + <veganman> no source + <braunr> no way + <braunr> you'd need to create a userspace linux server catching linux + system calls and calling hurd specific stuff to implement them + <braunr> it doesn't exist, it may be hard to implement + <braunr> some cases will definitely be hard to implement + <veganman> so, no magic linux lxemu on windows? + <veganman> or linuxemu on plan9 + <pinotree> nope + <veganman> I remember somethingsilly, sonmone hadcompiled linux asauser + applicationon plan9 and inserted his own binaries as + acodeobject,toberunon plan9, for useon ibm hpc hatrdware + <veganman> it was ron minich + <veganman> 5e.iwp9.org/slides/linuxemu.pdf + <veganman> I think that was it + <veganman> google for linux & cnk for additional clues diff --git a/faq/ghamp.mdwn b/faq/ghamp.mdwn new file mode 100644 index 00000000..16849aff --- /dev/null +++ b/faq/ghamp.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="GHAMP"]] + +*GHAMP* is the GNU/Hurd-based Apache, MySQL, PHP solution stack -- analoguous +to GLAMP, which is based on GNU/Linux. + +Pronounce it like the *G* in +[GNU](http://www.gnu.org/pronunciation/pronunciation.html), followed by a +mostly silent *H*, and *AMP* as in amplifier. diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn new file mode 100644 index 00000000..a96e0576 --- /dev/null +++ b/faq/how_many_developers.mdwn @@ -0,0 +1,63 @@ +[[!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 +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="How many developers are working on the GNU Hurd, and why so +few?"]] + + +# How Many Developers? + +One handful works on the core of the system in their free time, and another +handful helps with [[Debian GNU/Hurd|hurd/running/debian]] and +[[hurd/running/Arch_Hurd]] packaging. Also, an additional handful of former +developers are still available for answering technical questions, but are not +participating in the current development anymore. + +In the past (that is, a lot of years ago), the FSF did pay a few developers for +working full time on the GNU Hurd. But that was for a limited amount of time +only, and evidently, it was too little for getting the system into a +competitive state. Nowadays, it's only unpaid (apart from some +[[bounties|tag/bounty]]) and free-time volunteers' work. + +In contrast to the Linux kernel, there is no industry involvement in +development. For one, this is a good thing: independency; no conflicts of +interests. For another, it is also a bad thing: no dedicated full-time +manpower -- which matters a lot. + + +# Why So Few? + +We can only speculate. One major problem might be that the [[architectural +benefits|advantages]] are generally perceived as very abstract, with little +practical benefit. We currently don't have many tools that are actually making +use of all the possibilities. + +Another reason is that it's been taking too long. Today, most people don't +believe it will ever be ready for production use, and thus would consider +involvement a waste of time. This latter point is invalid, of course, as +learning can never be a waste of time. The same holds for the [[challenges]] +raised by the GNU Hurd -- we can only learn and improve upon working on them. + +For likely the same reasons there is no industry interest in the GNU Hurd: its +advantages are too abstract and incomplete for being of interest there. + +As for the scientific sector, the GNU Hurd projects was rather about *using* a +[[microkernel]] intead of doing research on them, for example. But, there have +been some projects and theses done, and some scientific papers published on GNU +Hurd topics, and we're generally very interested in further such projects. + + +# Attracting New Faces + +We're an open project: any interested party (*you*!) are very welcome to start +[[contributing]]. Mentoring is possible, too, to help you get started. + +Likewise, for reaching out to new developers, we're participating in [[Google's +Summer of Code program|community/gsoc]]. diff --git a/faq/how_many_developers/discussion.mdwn b/faq/how_many_developers/discussion.mdwn new file mode 100644 index 00000000..8e4c487a --- /dev/null +++ b/faq/how_many_developers/discussion.mdwn @@ -0,0 +1,65 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +# IRC, freenode, #hurd, 2011-05-22 + + <silver_hook> Since apparently Hurd's aim is a very stable and transparent + system ...why aren't there any companies backing it up? + <antrik> silver_hook: it's not in a state yet where it would be + commercially interesting + <antrik> silver_hook: and after some epic failures in the 90s, few + companies dare to invest in microkernel development... + <silver_hook> Isn't MacOS X running on top of Mach? + <antrik> yes, but it's not a true microkernel system + <antrik> for one, it's single-server, which is boring + <antrik> also it uses co-location, i.e. runs all the system code in the + kernel address space -- they are separated only formally + <antrik> even NT is more of a microkernel system I think + <silver_hook> Oh, OK, I'm not that knowledgeable about kernels to know + that. + <antrik> well, now you know :-) + <silver_hook> Yup, thanks :) + <antrik> most people don't know this, so don't worry + <silver_hook> I was just wondering that it might be potentially an ideal + server system, right? + <antrik> well, *potentially* it might be an ideal general-purpose system, + which includes server use... though personally I think the advantages of + the architecture are more visible in desktop use, as servers tend to be + rather streamlined, with little need for individualisation :-) + <antrik> however, it still remains to be proven that true (multi-server) + microkernel operating systems actually work for general-purpose + applications... + <silver_hook> antrik: I mean regarding hosting or virtual servers. + <antrik> so far, they are only successful in the much simpler embedded + space + <antrik> well, yes, the Hurd architecture in theory allows very much + flexibility regarding virtual environments... I once blogged about + that. not sure whether server applications really require that + flexibility though. I think most people are pretty happy with the various + virtualisation/container solutions available in Linux. again, the + flexibility is more relevant in the desktop space IMHO + <antrik> dosn't mean it wouldn't be useful for servers too... just not as + much of a selling point I fear :-) + + +# IRC, freenode, #hurd, 2011-07-09 + + <antrik> gnu_srs1: regarding your question why people aren't interested in + workin on Hurd: Eric Raymond explains it pretty well in his famous + "Cathedral and Bazaar" paper + <antrik> people are more likely to work on something that *almost* works + for them, and where they only have to fill in a few missing bits + <antrik> the Hurd doesn't almost work for anyone + <antrik> actually, you should probably reread the whole paper. it's + essentially an analysis why the Hurd failed compared to Linux + + +# [[open_issues/mission_statement]] diff --git a/faq/network_transparency.mdwn b/faq/network_transparency.mdwn new file mode 100644 index 00000000..aefaf500 --- /dev/null +++ b/faq/network_transparency.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2012-01-21: + + <chromaticwt> is it possible to transfer servers running on one microkernel + on one machine, to another microkernel running on a different machine? + <chromaticwt> two machines will be running the complete os + <antrik> well, if the code for network-transparent IPC still existed, it + might be possible to move a task to another machine, while keeping the + port associations with the original system... + <antrik> if you mean actually moving it to another system, that's pretty + much impossible in any system that has stateful interfaces diff --git a/faq/posix_compatibility.mdwn b/faq/posix_compatibility.mdwn new file mode 100644 index 00000000..4490b7cb --- /dev/null +++ b/faq/posix_compatibility.mdwn @@ -0,0 +1,32 @@ +[[!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 +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="POSIX compatibility"]] + +Is it favorable of rather a hindrance to be compatible to POSIX and similar +standards? + +A lot of things in POSIX et al. are designed for [[UNIX]]-like systems with +traditional monolithic [[kernel]]s. + +Thus, a [[microkernel]]-based system, as ours is, has to employ a bunch of +detours, for example to implement the [[`fork` system call|glibc/fork]]. + +On the other hand, (mostly) complying to these standards, made a really big +body of software *just work* without any (or just trivial) [[hurd/porting]]. +Especially so for command-line programs, and libraries. + +But: a large part of today's user programs are not written according to POSIX +et al. low-level interfaces, but against GNOME, GTK+2, and other high-level +frameworks and libraries. It may be a valid option to enrich these instead of +striving for total POSIX compliance -- and the high-level programs (that is, +their users) may not even notice this, but we would avoid a lot of overhead +that comes with wrapping the [[Hurd interfaces|hurd/interface]] to be POSIX +compliant. diff --git a/faq/posix_compatibility/discussion.mdwn b/faq/posix_compatibility/discussion.mdwn new file mode 100644 index 00000000..0d722c9e --- /dev/null +++ b/faq/posix_compatibility/discussion.mdwn @@ -0,0 +1,25 @@ +[[!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 +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]] + +\#hurd IRC channel on Freenode, 2010-12-21: + + <antrik> tschwinge: the writeup ignores the fact that POSIX compatibility + is not only for applications, but also for users familiar with the UNIX + environment + <antrik> also, I still don't buy the fact that most software is not written + for POSIX. even if assuming that GNOME programs don't use POSIX (which is + only half true), there is a lot of other software in a system that is + just as important, though less visible + <antrik> (server software, startup system, device management, automation, + ...) + <antrik> tschwinge: BTW, I meant to (and partially did) write a blog + article on this topic -- but I didn't get around to finish it... diff --git a/faq/sharing_the_user_space.mdwn b/faq/sharing_the_user_space.mdwn new file mode 100644 index 00000000..ec880827 --- /dev/null +++ b/faq/sharing_the_user_space.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +*Question:* Could it be possible to have a system installation where you can +dual-boot using either the [[Linux]] kernel, or the GNU Hurd, so that +everything but the kernel is shared? + +*Answer:* Given that both Linux and GNU Hurd are using the [[ELF]] binary +format, this could indeed be made possible, if all programs agreed to rely on +only one abstraction layer, for example the standard C library ([[glibc]]). +(Additionally, for example for [[system call]]s that are not covered by glibc +calls, you'd need to be able to reliably trap and emulate these.) However, +Linux' and the GNU Hurd's [[ABI]]'s have sufficiently diverged, so that this is +not easy to do. That's why you can't currently install a system in this way, +but you need a separate installation of the userspace suited for the Linux +kernel, or the GNU Hurd. diff --git a/faq/smp.mdwn b/faq/smp.mdwn new file mode 100644 index 00000000..e95edcd2 --- /dev/null +++ b/faq/smp.mdwn @@ -0,0 +1,28 @@ +[[!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 +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="Does GNU/Hurd support SMP/Multicore?"]] + +The Hurd servers themselves are multithreaded, so they should be able to take benefit of the parallelism brought by SMP/Multicore boxes. This has however never been tested yet because of the following. + +[[microkernel/Mach]] used to be running on SMP boxes like the [[!wikipedia +Intel_iPSC/860]], so principally has the required infrastructure. It has +however not yet been enhanced to support nowadays' SMP standards like ACPI, +etc. Also, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue +code likely isn't SMP-safe. As this glue code layer is not used in the +[[microkernel/mach/gnumach/ports/Xen]] port of GNU Mach, the plan is to try it +in this enviroment first. + +[[!tag open_issue_gnumach open_issue_xen]] + +That is why for now GNU/Hurd will only use one logical processor (i.e. one core or one thread, depending on the socket type). + +Once this issue is solved, there are follow-up issues about +[[open_issues/multiprocessing]] and [[open_issues/multithreading]]. diff --git a/faq/system_port.mdwn b/faq/system_port.mdwn new file mode 100644 index 00000000..c831c36f --- /dev/null +++ b/faq/system_port.mdwn @@ -0,0 +1,47 @@ +[[!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="Doing a GNU/Hurd System Port"]] + +How difficult is it to port the GNU/Hurd system to run on another architecture? + +The GNU/Hurd system consists of [[/Hurd]] servers running as user-space +processes on top of the [[GNU Mach|microkernel/mach/gnumach]] microkernel. The +system functionality is usually accessed through the +[[POSIX|posix_compatibility]] interface that is provided by [[/glibc]] and +[[/libpthread]]. + +A whole-system port involves touching all these components, with varying +degree, of course. + +For a CPU architecture port, the microkernel is the most involved part, +followed by glibc and the threading library. + +The original [[microkernel/Mach]] microkernel was portable to a number of +architectures which were a lot more popular at the beginning of the 1990s than +they are now. + +The GNU/Hurd system is currently available for the x86 architecture. This +includes emulators such as [[hurd/running/QEMU]] (or KVM), or +[[hurd/running/VirtualBox]]. Besides this, there is a port for the [[Xen +domU|microkernel/mach/gnumach/ports/xen]] *sub-architecture*. + +Further on, there are some [[unfinished porting +attempts|microkernel/mach/gnumach/ports]] for the Alpha, MIPS and PowerPC +architectures. These have not been completed due to little developer interest. + +Another option is to do the port at a different layer: port the Hurd servers to +not run on the GNU Mach microkernel, but instead on top of [[another +microkernel|which_microkernel]]. Or, even by providing a Mach emulation layer +on top of a monolithic kernel. For example, there could be a port for [[having +Mach run as a POSIX user-space process|open_issues/mach_on_top_of_posix]], or +by implementing the [[Mach IPC|microkernel/mach/ipc]] facility (as well as +several others) as Linux kernel modules. While there have been some +experiments, no such port has been completed yet. diff --git a/faq/which_microkernel.mdwn b/faq/which_microkernel.mdwn new file mode 100644 index 00000000..84b661e4 --- /dev/null +++ b/faq/which_microkernel.mdwn @@ -0,0 +1,55 @@ +[[!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 +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="What happened with the Hurd ports to the L4 / Coyotos / Viengoos +microkernels?"]] + +<!-- This page shares some text with history/port_to_another_microkernel. --> + +It is a frequently asked question, which microkernel the Hurd should be based +upon assuming that [[microkernel/Mach]] is no longer considered state of the +art, and it is well known that there has been a lot of discussion about this +topic, and also some code produced, but then, years later, the Hurd is still +based on [[GNU Mach|microkernel/mach/gnumach]]. + +Around the turn of the millenium, some of the Hurd developers began +experimenting with using other [[microkernel]]s for the Hurd, as they have been +encountering a number of fundamental design issues with the [[Mach +microkernel|microkernel/mach]], mostly with respect to +[[open_issues/resource_management_problems]]. + +At that time, L4 (Pistachio) was the prime candidate. A reimplementation of +the Hurd on this microkernel looked promising, and got pretty far (running some +simple POSIX programs, such as `banner`). However, over time some lingering +design issues turned out to be fundamental problems: the original L4 is not +suitable for building object-capability systems like the Hurd. Thus +development was aborted in 2005. + +During that process, Neal Walfield and Marcus Brinkmann started on a period of +research on other microkernels, getting in deeper contact with other +researchers. There was a lot of discussion, and a lot of good ideas produced, +but a straight-forward port of the Hurd to such a modern microkernel (Coyotos, +or the new L4 variants, for example) didn't seem feasible to them anymore: they +found microkernel design and system design to be interconnected in very +intricate ways, and this demanded design changes in the Hurd's core itself. + +Based on this experience, the next step was to write an own microkernel +instead, which Neal Walfield began doing with his experimental +[[microkernel/Viengoos]] project, for his research on resource management. +Currently he works in another research area though, and thus Viengoos is on +hold. + +Note that while none of the microkernel research work is active now, the +previous experiments already yielded a lot of experience, which will be very +useful in the further development / improvement of the mainline (Mach-based) +Hurd implementation. + +For more details about this topic, please see our history page about the +[[history/port_to_another_microkernel]]. diff --git a/faq/which_microkernel/discussion.mdwn b/faq/which_microkernel/discussion.mdwn new file mode 100644 index 00000000..ffdc6720 --- /dev/null +++ b/faq/which_microkernel/discussion.mdwn @@ -0,0 +1,120 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +[[!toc]] + + +# Olaf, 2011-04-10 + +This version mixes up three distinct phases: rewrite from scratch; redesign; +own microkernel. + +While Okuji initially might have intended a direct port of the existing Hurd +code, by the time I started following Hurd development (2004 IIRC), it has been +long clear that Hurd/L4 is a rewrite from scratch. + +The next phase was the desire of Neal and especially Macrus to completely +reinvent the design of the Hurd. This was mostly fueled by Shapiro's influence, +resulting in a security-above-everything rage. It was in this phase that not +only the original L4 has been abandonend, but also all thoughts about using +newer L4 variants (which might have been suitable) were forsaken in favor of +Shapiro's Coyotos. + +The whole idea of redesigning the Hurd -- especially for security concerns -- +is highly controversial: I always strongly objected to it; and Marcus later +admitted himself that he got carried away and lost sight of what really matters +for the Hurd. (But only after realising that Shapiro's notion of high security +is fundamentally incompatible with the GNU philosophy.) I opted for not +explicitely mentioning this aspect in the FAQ at all, as it's impossible to +explain properly in a compact form, and probably impossible at all to do it in +an objective fashion. + +The final phase -- following the realisation of incompatibility with +Shapiro/Coyotos -- was the attempt to create new microkernels specifically for +Hurd's needs. Marcus abandonned his pretty soon, and never made it public, so I +didn't mention it at all; but Viengoos is still relevant in certain ways. + +BTW, my original text also more explicitely answers the question what happened +to the Coyotos port -- which after all is what the title promises... + +All in all, I still think my text was better. If you have any conerns with it, +please discuss them... + + +# seL4 + +## IRC, freenode, #hurd, 2011-09-27 + + <cjuner> Does anyone remember/know if/why not seL4 was considered for + hurd-l4? Is anyone aware of any differences between seL4 and coyotos? + + +## IRC, freenode, #hurd, 2011-09-29 + + <antrik> cjuner: the seL4 project was only at the beginning when the + decision was made. so was Coyotos, but Shapiro promised back then that + building on EROS, it would be done very fast (a promise he couldn't keep + BTW); plus he convinced the people in question that it's safer to build + on his ideas... + <antrik> it doesn't really matter though, as by the time the ngHurd people + were through with Coyotos, they had already concluded that it doesn't + make sense to build upon *any* third-party microkernel + <cjuner> antrik, what was the problem with coyotos? what would be the + problem with sel4 today? + <cjuner> antrik, yes I did read the FAQ. It doesn't mention seL4 at all + (there isn't even much on the hurd-l4 mailing lists, I think that being + due to seL4 not having been released at that point?) and it does not + specify what problems they had with coyotos. + <antrik> cjuner: it doesn't? I thought it mentioned "newer L4 variants" or + something like that... but the text was rewritten a couple of times, so I + guess it got lost somewhere + <antrik> cjuner: unlike original L4, it's probably possible to implement a + system like the Hurd on top on seL4, just like on top of + Coyotos. however, foreign microkernels are always created with foreign + design ideas in mind; and building our own design around them is always + problematic. it's problematic with Mach, and it will be problematic with + any other third-party microkernel + <antrik> Coyotos specifically has different ideas about memory protection, + different ideas about task startup, different ideas about memory + handling, and different ideas about resource allocation + <cjuner> antrik, do any specific problems of the foreign designs, + specifically of seL4 or coyotos come to mind? + <antrik> cjuner: I mentioned several for Coyotos. I don't have enough + understanding of the matters to go into much more detail + <antrik> (and I suspect you don't have enough understanding of these + matters to take away anything useful from more detail ;-) ) + <antrik> I could try to explain the issues I mentioned for Coyotos (as far + as I understand them), but would that really help you? + + +# Xnu (Darwin) + + +## IRC, freenode, #hurd, 2012-03-30 + + <mel__> did people consider to port Hurd to Darwin? i.e. replace GNU Mach + with Darwin? + <braunr> no + <braunr> well, quickly only + <mel__> wouldn't it be a reasonable idea? + <mel__> after all, Darwin is production-ready and contains a Mach side. + <braunr> not more than fixing gnumach itself, or using linux instead + <mel__> well. + <braunr> those implementations have diverged with time + <mel__> i see + <mel__> the fsf should pay people for fixing gnu mach then. :) + <antrik> mel__: indeed someone consided Xnu (the actual kernel of Darwin) a + while back; but I think he shelved the idea again. not sure about the + exact reasons + <antrik> Xnu implements a few improvements that might be helpful; but it + doesn't address the really fundamental issues that matter for a true + multiserver system... @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -9,6 +9,15 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -The [GNU Compiler Collection](http://gcc.gnu.org/). +[[!meta title="GNU Compiler Collection"]] - * [[Open Issues|tag/open_issue_gcc]] + +# <http://gcc.gnu.org/> + + +# [[Maintenance|open_issues/gcc]] + + +# Open Issues + +[[!inline pages=tag/open_issue_gcc raw=yes feeds=no]] @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,10 +6,13 @@ id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -The [GNU debugger *GDB*](http://www.gnu.org/software/gdb/). +[[!meta title="GNU GDB"]] + + +# <http://www.gnu.org/software/gdb/> * [[Backtrace]]s @@ -18,4 +21,14 @@ The [GNU debugger *GDB*](http://www.gnu.org/software/gdb/). * [When disassemble doesn't work](http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00039.html) - * [[Open Issues|tag/open_issue_gdb]] + +# [[Maintenance|open_issues/binutils]] + + +# Open Issues + +[[!inline pages=tag/open_issue_gdb raw=yes feeds=no]] + + * *[Implementing a Mach Debugger for Multithreaded + Applications](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.5670)*, + Deborah Caswell and David Black, 1990. This talks about GDB. diff --git a/generate_interface_redir_pages b/generate_interface_redir_pages new file mode 100755 index 00000000..b6adc349 --- /dev/null +++ b/generate_interface_redir_pages @@ -0,0 +1,25 @@ +#!/bin/sh + +for s; do + s=$(basename "$s") && + for i in "$s"/??.mdwn; do + t=$(grep '^\[\[!meta title' | cut -d \" -f 2) \ + < "$i" && + i=$(expr "$i" : '\(.*\)\.mdwn') && + cat \ + > "$t".mdwn \ + <<EOF +[[!meta copyright="Copyright © 2009 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 redir=$i]] +EOF + done +done @@ -1,11 +1,93 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -The [GNU C Library](http://www.gnu.org/software/libc/). +[[!meta title="GNU C Library"]] + + +# <http://www.gnu.org/software/libc/> + + +## Sources + +For concenience, we maintain our own [[source +repository|source_repositories/glibc]]. + + +# Specifics + + +## Ports + +Porting glibc to a specific architecture is non-trivial. + +The main port is x86, which is somewhat complete and is maintained. There is +an incomplete and unmaintained port for PowerPC. There [[!message-id +desc="have" "20111129161104.25123.qmail@sourceware.org"]] [[!message-id +desc="been" "Pine.LNX.4.64.1111291611170.26895@digraph.polyomino.org.uk"]] +incomplete and largely unmaintained ports for Alpha and MIPS in glibc-ports. + + +## [[Hurd-specific Port|hurd/glibc]] + +An important part of the [[Hurd]] actually resides in glibc: here, the POSIX +interfaces are implemented on top of the [[Hurd IPC protocols|hurd/interface]]. +This is different to the Linux port, where most simple POSIX interfaces are in +fact simply forwarded to/implemented as [[system_call]]s. + + +## [[Maintenance|open_issues/glibc]] + + +# Implementation Details + + * [[hurd/glibc/Hurd-specific API]] + + * [[open_issues/secure_file_descriptor_handling]] + + * [[signal/signal_thread]] + + * [[startup]] + + +## Concepts + + * [[environment_variable]] + + * [[file_descriptor]] + + * [[process]] + + * [[signal]] + + * [[ioctl]] + + +## Individual functions + +Some of these are well-known as [[UNIX]] [[system call]]s. + + * [[fallocate]] + + * [[fork]] + + * [[mmap]] + + * [[poll]] + + +# Debugging + +Some hints for [[debugging]]. + + +# Open Issues + +[[!inline pages=tag/open_issue_glibc raw=yes feeds=no]] diff --git a/glibc/debugging.mdwn b/glibc/debugging.mdwn new file mode 100644 index 00000000..6b035c12 --- /dev/null +++ b/glibc/debugging.mdwn @@ -0,0 +1,11 @@ +[[!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]]."]]"""]] + + * [[ld_so_console]] diff --git a/glibc/debugging/ld_so_console.mdwn b/glibc/debugging/ld_so_console.mdwn new file mode 100644 index 00000000..b3d1762f --- /dev/null +++ b/glibc/debugging/ld_so_console.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]]."]]"""]] + +If you need to debug something in the early `ld.so` startup, and can't refrain +from good old `printf` debugging, there is a caveat: the available API in +`ld.so` is rather limited. See the few functions is `dl-sysdep.c`. For +example, there's a private `__libc_write`, which you should be able to use for +writing to FD stderr -- but, at early `ld.so` startup, this isn't usable as +`_hurd_init_dtable` is still all zeros, etc. To get you started, here is a +simple [[dl-sysdep.c.patch]] to get access to the Mach console. + +Can this be integrated with the other debugging printf functions from +`elf/dl-misc.c` (`_dl_debug_vdprintf`) ([[!taglink open_issue_glibc]])? diff --git a/glibc/debugging/ld_so_console/dl-sysdep.c.patch b/glibc/debugging/ld_so_console/dl-sysdep.c.patch new file mode 100644 index 00000000..eec8d7c6 --- /dev/null +++ b/glibc/debugging/ld_so_console/dl-sysdep.c.patch @@ -0,0 +1,63 @@ +diff --git a/sysdeps/mach/hurd/dl-sysdep.c b/sysdeps/mach/hurd/dl-sysdep.c +index ff37add..7e6d352 100644 +--- a/sysdeps/mach/hurd/dl-sysdep.c ++++ b/sysdeps/mach/hurd/dl-sysdep.c +@@ -44,6 +44,8 @@ + #include <dl-machine.h> + #include <dl-procinfo.h> + ++#include <device/device.h> ++ + extern void __mach_init (void); + + extern int _dl_argc; +@@ -116,6 +118,29 @@ static void fmh(void) { + /* XXX loser kludge for vm_map kernel bug */ + #endif + ++/* Return a port to the Mach console. */ ++static mach_port_t ++get_console (void) ++{ ++ mach_port_t device_master, console; ++ /* We cannot use __get_privileged_ports (from hurd/privports.c), as this ++ drags in too much other libc stuff. */ ++#if 0 ++ error_t err = __get_privileged_ports (0, &device_master); ++ ++ if (err) ++ return MACH_PORT_NULL; ++#else ++ error_t err = 0; ++ device_master = 2; ++#endif ++ ++ err = __device_open (device_master, D_WRITE | D_READ, "console", &console); ++ if (err) ++ return MACH_PORT_NULL; ++ ++ return console; ++} + + ElfW(Addr) + _dl_sysdep_start (void **start_argptr, +@@ -256,6 +279,20 @@ unfmh(); /* XXX */ + /* Set up so we can do RPCs. */ + __mach_init (); + ++ /* Open the Mach console so that any message can actually be seen. This is ++ particularly useful at boot time, when started by the bootstrap file ++ system. */ ++ mach_port_t console = get_console (); ++ if (console != MACH_PORT_NULL) ++ { ++ /* stdout = mach_open_devstream (console, "w"); */ ++ /* stderr = stdout; */ ++ /* if (stdout != NULL) */ ++ /* printf ("Hello, world!\n"); */ ++ int written; ++ __device_write_inband (console, 0, 0, "hello, world!\n", 14, &written); ++ } ++ + /* Initialize frequently used global variable. */ + GLRO(dl_pagesize) = __getpagesize ();
\ No newline at end of file diff --git a/glibc/discussion.mdwn b/glibc/discussion.mdwn new file mode 100644 index 00000000..fac300ea --- /dev/null +++ b/glibc/discussion.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]]."]]"""]] + + +# TLS + + +## IRC, freenode, #hurd, 2011-06-11 + +[[!tag open_issue_documentation open_issue_glibc]] + + <civodul> youpi: local-tls-support.diff removes libc-tsd.h; what's the + rationale? + <youpi> it's completely replaced by __thread variables + <civodul> ok, but apparently there are still libc headers that #include it + <civodul> like malloc-machine.h + <youpi> they'll include bits/libc-tsd.h instead + <civodul> oh, ok diff --git a/glibc/environment_variable.mdwn b/glibc/environment_variable.mdwn new file mode 100644 index 00000000..76c1371e --- /dev/null +++ b/glibc/environment_variable.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +# External + + * [*putenv() and setenv()*](http://www.greenend.org.uk/rjk/2008/putenv.html) + by Richard Kettlewell. diff --git a/glibc/fallocate.mdwn b/glibc/fallocate.mdwn new file mode 100644 index 00000000..3aecf16b --- /dev/null +++ b/glibc/fallocate.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Not yet implemented for the GNU Hurd in [[glibc]]. + + +# External + + * [*Punching holes in files*](http://lwn.net/Articles/415889/), Jonathan + Corbet, 2010-11-17. diff --git a/glibc/file_descriptor.mdwn b/glibc/file_descriptor.mdwn new file mode 100644 index 00000000..2c56d070 --- /dev/null +++ b/glibc/file_descriptor.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +A [[UNIX file descriptor|unix/file_descriptor]] is implemented in [[glibc]] by +using operations on objects referred to by [[Mach +ports|microkernel/mach/port]]). diff --git a/glibc/fork.mdwn b/glibc/fork.mdwn new file mode 100644 index 00000000..12ca2d19 --- /dev/null +++ b/glibc/fork.mdwn @@ -0,0 +1,69 @@ +[[!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 +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]]."]]"""]] + +On [[Unix]] systems, `fork` is a rather simple [[system call]]. + +Our implementation in [[glibc]] is and needs to be rather bulky. + +For example, it has to duplicate all port rights for the new [[Mach +task|microkernel/mach/task]]. The address space can simply be duplicated by +standard means of the [[microkernel/Mach]], but as [[unix/file_descriptor]]s +(for example) are a concept that is implemented inside [[glibc]] (based on +[[Mach port|microkernel/mach/port]]s), these have to be duplicated from +userspace, which requires a small number of [[RPC]]s for each of them, and in +the sum, [[this affects performance|open_issues/performance/fork]] when new +processes are continuously being spawned from the shell, for example. + +Often, a `fork` call will eventually be followed by an `exec`, which [[may in +turn close|open_issues/secure_file_descriptor_handling]] (most of) the +duplicated port rights. Unfortunately, this cannot be known at the time the +`fork` executing, so in order to optimize this, the code calling `fork` has to +be modified instead, and the `fork`, `exec` combo be replaced by a +`posix_spawn` call, for example, to avoid this work of duplicating each port +right, then closing each again. + +As far as we know, Cygwin has the same problem of `fork` being a nontrivial +operation. Perhaps we can learn from what they're been doing? Also, perhaps +they have patches for software packages, to avoid using `fork` followed by +`exec`, for example. + + +# TODO + + * [[fork: mach_port_mod_refs: + EKERN_UREFS_OWERFLOW|open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow]] + ([[!taglink open_issue_glibc]]). + + * Include de-duplicate information from elsewhere: [[hurd-paper]], + [[hurd-talk]], [[hurd/ng/trivialconfinementvsconstructorvsfork]], + [[open_issues/resource_management_problems/zalloc_panics]] ([[!taglink + open_issue_glibc open_issue_documentation]]). + + * We no longer support `MACH_IPC_COMPAT`, thus we can get rid of the `err = + __mach_port_allocate_name ([...]); if (err == KERN_NAME_EXISTS)` code + ([[!taglink open_issue_glibc]]). + + * Can we/why can't we use the concept of *inherited ports + array*s/`mach_ports_register` ([[!taglink open_issue_glibc]])? + + * GNUnet `vfork` signal race issue: [[!message-id + "87r50ww6m4.fsf@kepler.schwinge.homeip.net"]]. + + +## Related + + * [[open_issues/secure_file_descriptor_handling]]. + + +# External + + * {{$unix#djb_self-pipe}}. + + * {{$unix#rjk_fork}}. 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/mmap.mdwn b/glibc/mmap.mdwn new file mode 100644 index 00000000..09b0b65d --- /dev/null +++ b/glibc/mmap.mdwn @@ -0,0 +1,98 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +There are two implementations of `mmap` for GNU Hurd: +`sysdeps/mach/hurd/mmap.c` (main implementation) and +`sysdeps/mach/hurd/dl-sysdep.c` (*Minimal mmap implementation sufficient for +initial loading of shared libraries.*). + + * `MAP_COPY` + + What exactly is that? `elf/dl-load.c` has some explanation. + <http://lkml.indiana.edu/hypermail/linux/kernel/0110.1/1506.html> + + It is only handled in `dl-sysdep.c`, when `flags & (MAP_COPY|MAP_PRIVATE)` + is used for `vm_map`'s `copy` parameter, and `mmap.c` uses `! (flags & + MAP_SHARED)` instead, which seems inconsistent? + + +# `io_map` Failure + +This is the [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] issue. + +[[!tag open_issue_glibc]] + +Review of `mmap` usage in generic bits of glibc, based on +a1bcbd4035ac2483dc10da150d4db46f3e1744f8 (2012-03-11), listing these cases +where failure (due to `io_map` failing; that is, invocations where a `fd` is +passed) is not properly handled. + +`catgets/open_catalog.c`, `iconv/gconv_cache.c`, `intl/loadmsgcat.c`, +`locale/loadlocale.c` have fallback code for the `MAP_FAILED` case. + +[[tschwinge]]'s current plan is to make the following cases do the same (if +that is possible); probably by introducing a generic `mmap_or_read` function, +that first tries `mmap` (and that will succeed on Linux-based systems and also +on Hurd-based, if it's backed by [[hurd/libdiskfs]]), and if that fails tries +`mmap` on anonymous memory and then fills it by `read`ing the required data. +This is also what the [[hurd/exec]] server is doing (and is the reason that the +`./true` invocation on [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] +works, to my understanding): see `exec.c:prepare`, if `io_map` fails, +`e->filemap == MACH_PORT_NULL`; then `exec.c:map` (as invoked from +`exec.c:load_section`, `exec.c:check_elf`, `exec.c:do_exec`, or +`hashexec.c:check_hashbang`) will use `io_read` instead. + +Doing so potentially means reading in a lot of unused data -- but we probably +can't do any better? + +In parallel (or even alternatively?), it should be researched how Linux (or any +other kernel) implements `mmap` on NFS and similar file systems, and then +implement the same in [[hurd/libnetfs]] and/or [[hurd/translator/nfs]], etc. + +Here, also probably the whole mapping region [has to be +read](http://lists.gnu.org/archive/html/bug-hurd/2001-10/msg00306.html) at +`mmap` time. + +List of files without fallback code for the *`MAP_FAILED` due to `io_map` +failed* case: + + * `elf/cache.c` + + * `elf/dl-load.c` + + * `elf/dl-misc.c` + + * `elf/dl-profile.c` + + * `elf/readlib.c` + + * `elf/sprof.c` + + * `locale/loadarchive.c` + + * `locale/programs/locale.c` + + * `locale/programs/locarchive.c` + + * `nscd/connections.c` + + * `nscd/nscd_helper.c` + + * `nss/makedb.c` + + * `nss/nss_db/db-open.c` + + * Omitted: + + * `nptl/` + + * `sysdeps/unix/sparc/` + + * `sysdepts/unix/sysv/linux/` diff --git a/glibc/poll.mdwn b/glibc/poll.mdwn new file mode 100644 index 00000000..d96f27a5 --- /dev/null +++ b/glibc/poll.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +# External + + * [*poll() and EOF*](http://www.greenend.org.uk/rjk/2001/06/poll.html) by + Richard Kettlewell. diff --git a/glibc/process.mdwn b/glibc/process.mdwn new file mode 100644 index 00000000..9b2ec251 --- /dev/null +++ b/glibc/process.mdwn @@ -0,0 +1,26 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The GNU Hurd uses a similar concept to [[UNIX processes|unix/process]]. + +As a [[Mach task|microkernel/mach/task]] only implements a part of a UNIX +process, there is additional work to be done, for example for [[signal]]s, +[[environment_variable]]s, [[file_descriptor]]s. + + +# Controlling TTY + +Hurd controlling tty behavior is generally consistent with BSD's, including +`TIOCSCTTY`. Linux also has `TIOCSCTTY` and it is harmless to use it there. +But BSD and Hurd never do an implicit `TIOCSCTTY` (hence our `O_NOCTTY` is +zero). + +C.f. <http://lists.gnu.org/archive/html/bug-hurd/2009-10/msg00030.html> and the +following messages. diff --git a/glibc/signal.mdwn b/glibc/signal.mdwn new file mode 100644 index 00000000..727247ac --- /dev/null +++ b/glibc/signal.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2009, 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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The [[*UNIX signalling mechanism*|unix/signal]] is implemented for the GNU Hurd +by means of a separate *[[signal_thread]]* that is part of every user-space +[[process]]. This makes handling of signals a separate thread of control. +[[GNU Mach|microkernel/mach/gnumach]] itself has no idea what a signal is and +`kill` is not a [[system_call]] (as it typically is in a [[UNIX]] system): it's +implemented in [[glibc]]. + + * [[SA_SIGINFO, SA_SIGACTION|open_issues/sa_siginfo_sa_sigaction]] + + * Why does `kill` hang sometimes? + + <youpi> kill send the signal to the process + <youpi> if the process is hung, killing waits + <youpi> signals should be just asynchronous, but apparently for some + reason Roland & co wanted some synchronization + + [[!taglink open_issue_glibc]] + + +# Further Reading + + * {{$unix#djb_self-pipe}}. + + * {{$unix#rjk_fork}}. diff --git a/glibc/signal/signal_thread.mdwn b/glibc/signal/signal_thread.mdwn new file mode 100644 index 00000000..5341b1ab --- /dev/null +++ b/glibc/signal/signal_thread.mdwn @@ -0,0 +1,100 @@ +[[!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]]."]]"""]] + +For delivering a signal, Mach forwards an `msg_sig_post` message from the +invoker of `kill` to the target process. The target process' [[signal_thread]] +job is it to listen to such messages and to set up signal handler contexts in +other threads. + +--- + +[[!tag open_issue_documentation]] + + <braunr> bugs around signals are very tricky + <braunr> signals are actually the most hairy part of the hurd + <braunr> and the reason they're aynchronous is that they're handled by a + second thread + <braunr> (so yes, every process on the hurd has at least two threads) + <svante_> braunr: How to solve the asynch problem then if every process has + two threads? + <braunr> the easiest method would be to align ourselves on what most other + Unices do + <braunr> establish a "signal protocol" between kernel and userspace + <braunr> with a set of signal info in a table, most likely at the top of + the stack + <braunr> but this is explicitely what the original Mach developers didn't + want, and they were right IMO + <braunr> having two threads is very clean, but it creates incompatibilites + with what POSIX requires + <braunr> so there might be a radical choice to make here + <braunr> and i doubt we have the resources to make it happen + <svante_> What is the advantage of having two threads per process, a per + the original design? + <braunr> it's clean + <braunr> you don't have to define async-signal-safe functions + <braunr> it's like using sigwait() yourself in a separate thread, or + multiplexing them through signalfd() + <svante_> Regardless of the advantages, isn't two threads per process a + waste of resources? + <braunr> sure it is + <braunr> but does it really matter ? + <braunr> mach and the hurd were intended to be "hyperthreaded" + <braunr> so basically, a thread should consume only a few kernel resources + <braunr> in GNU Mach, it doesn't even consume a kernel stack because only + continuations are used + <braunr> and in userspace, it consumes 2 MiB of virtual memory, a few table + entries, and almost no CPU time + <svante_> What does "hyperthreaded" mean: Do you have a reference? + <braunr> in this context, it just means there are a lot of threads + <braunr> even back in the 90s, the expected number of threads could scale + up to the thousand + <braunr> today, it isn't much impressive any more + <braunr> but at the time, most systems didn't have LWPs yet + <braunr> and a process was very expensive + <svante_> Looks like I have some catching up to do: What is "continuations" + and LWP? Maybe I also need a reference to an overview on multi-threading. + <ArneBab> Lightweight process? + http://en.wikipedia.org/wiki/Light-weight_process + <braunr> svante_: that's a whole computer science domain of its own + <braunr> yes + <braunr> LWPs are another names for kernel threads usually + <braunr> continuations are a facility which allows a thread to store its + state, yield the processor to another thread, and when it's dispatched + again by the scheduler, it can resume with its saved state + <braunr> most current kernels support kernel preemption though + <braunr> which means their state is saved based on scheduler decisions + <braunr> unlike continuations where the thread voluntarily saves its state + <braunr> if you only have continuations, you can't have kernel preemption, + but you end up with one kernel stack per processor + <braunr> while the other model allows kernel preemption and requires one + kernel stack per thread + <svante_> I know resources are limited, but it looks like kernel preemption + would be nice to have. Is that too much for a GSoC student? + <braunr> it would require a lot of changes in obscure and sensitive parts + of the kernel + <braunr> and no, kernel preemption is something we don't actually need + <braunr> even current debian linux kernels are built without kernel + preemption + <braunr> and considering mach has hard limitations on its physical memory + management, increasing the amount of memory used for kernel stacks would + imply less available memory for the rest of the system + <svante_> Are these hard limits in mach difficult to change? + <braunr> yes + <braunr> consider mach difficult to change + <braunr> that's actually one of the goals of my stalled project + <braunr> which I hope to resume by the end of the year :/ + <svante_> Reading Wikipedia it looks like LWP are "kernel treads" and other + threads are "user threads" at least in IBM/AIX. LWP in Linux is a thread + sharing resources and in SunOS they are "user threads". Which is closest + for Hurd? + <braunr> i told you + <braunr> 14:09 < braunr> LWPs are another names for kernel threads usually + <svante_> Similar to to the IBM definition then? Sorry for not remembering + what I've been reading. 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"]] diff --git a/gnu.mdwn b/gnu.mdwn new file mode 100644 index 00000000..4efc0bad --- /dev/null +++ b/gnu.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]]."]]"""]] + +{{$gnustatus-2011-01}} + + +[[!ymlfront data=""" + +gnustatus-2011-01: + + "[GNU Status Reports: January + 2011](http://www.gnu.org/bulletins/gnustatus-2011-01.html)" + +"""]] @@ -1,4 +1,41 @@ -# [GRUB](http://www.gnu.org/software/grub/) +<http://www.gnu.org/software/grub/> + +This section complements the [[InstallNotes]] with complete information +regarding the GRUB 2 boot loader. The syntax is different from GRUB Legacy aka +GRUB 1 (see below). + + * `update-grub` is *Debian specific* and very useful. It will automatically + create a `/boot/grub/grub.cfg` file for the kernels in `/boot/` and for + OSes that it finds on various partitions, including GNU/Hurd. + + * Make sure that GRUB 2's version is at least 20091130 and GNU Mach's version + is at least 20091020. + + * Sample file: + + menuentry "GNU/Linux" { + insmod ext2 + set root=(hd0,12) + linux /boot/vmlinuz-2.6.32 root=/dev/hda12 ro + initrd /boot/initrd.img-2.6.32 + } + + menuentry "GNU" { + insmod ext2 + set root=(hd0,16) + multiboot /boot/gnumach.gz root=device:hd0s16 + module /hurd/ext2fs.static ext2fs --readonly \ + --multiboot-command-line='${kernel-command-line}' \ + --host-priv-port='${host-port}' \ + --device-master-port='${device-port}' \ + --exec-server-task='${exec-task}' -T typed '${root}' \ + '$(task-create)' '$(task-resume)' + module /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)' + } + +--- + +**The following information may be outdated and should be revised.** This section complements the [[InstallNotes]] with complete information regarding the GRUB boot loader. The syntax is different from Lilo's and so to scratch my own itch I'm creating this quick reference. The [Grub manual](http://www.gnu.org/software/grub/manual/grub.html) is another good reference. @@ -13,27 +50,27 @@ This section complements the [[InstallNotes]] with complete information regardin * boot * sample file - title GNU/Linux - root (hd0,11) - kernel /boot/vmlinuz-2.4.18 root=/dev/hda12 ro - initrd /boot/initrd.img-2.4.18 - savedefault - - title GNU - root (hd0,15) - kernel /boot/oskit-mach root=device:hd0s16 -- - module /hurd/ext2fs.static \ - --multiboot-command-line=${kernel-command-line} \ - --host-priv-port=${host-port} \ - --device-master-port=${device-port} \ - --exec-server-task=${exec-task} \ - -T typed ${root} $(task-create) $(task-resume) - module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) - savedefault - - title DOS - rootnoverify (hd0,0) - chainloader +1 + title GNU/Linux + root (hd0,11) + kernel /boot/vmlinuz-2.4.18 root=/dev/hda12 ro + initrd /boot/initrd.img-2.4.18 + savedefault + + title GNU + root (hd0,15) + kernel /boot/oskit-mach root=device:hd0s16 -- + module /hurd/ext2fs.static \ + --multiboot-command-line=${kernel-command-line} \ + --host-priv-port=${host-port} \ + --device-master-port=${device-port} \ + --exec-server-task=${exec-task} \ + -T typed ${root} $(task-create) $(task-resume) + module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) + savedefault + + title DOS + rootnoverify (hd0,0) + chainloader +1 -- [[Main/GrantBow]] - 01 Oct 2002 <br /> -- [[Main/GrantBow]] - 22 Dec 2002 diff --git a/history.mdwn b/history.mdwn index 8f155b54..0abcbd52 100644 --- a/history.mdwn +++ b/history.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 1998, 1999, 2001, 2002, 2007, 2008, 2009 Free -Software Foundation, Inc."]] +[[!meta copyright="Copyright © 1998, 1999, 2001, 2002, 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag stable_URL]] @@ -91,4 +91,4 @@ mailing lists. --- - * [[Port_to_L4]] + * [[Port_to_another_microkernel]] diff --git a/history/port_to_another_microkernel.mdwn b/history/port_to_another_microkernel.mdwn new file mode 100644 index 00000000..a8ec3fe7 --- /dev/null +++ b/history/port_to_another_microkernel.mdwn @@ -0,0 +1,178 @@ +[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, +2009, 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 +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="Porting the Hurd to another microkernel"]] + +<!-- This page shares some text with faq/which_microkernel. --> + +It is a frequently asked question, [[faq/which_microkernel]] the Hurd should be +based upon assuming that [[microkernel/Mach]] is no longer considered state of +the art, and it is well known that there has been a lot of discussion about +this topic, and also some code produced, but then, years later, the Hurd is +still based on [[GNU Mach|microkernel/mach/gnumach]]. + +At first, there was an effort to directly port the Hurd to the +[[L4_microkernel_family|microkernel/l4]]. Then the story continued... + +[[!toc levels=2]] + + +# L4 + +## Initial Idea + +Encountering a number of fundamental design issues with the [[Mach +microkernel|microkernel/mach]] (mostly regarding [[resource +management|open_issues/resource_management_problems]]), some of the Hurd +developers began experimenting with using other microkernels for the Hurd +around the turn of the millenium. + +The idea of using L4 as a [[microkernel]] for a Hurd system was initially +voiced in the [[community]] by Okuji Yoshinori, who, for discussing this +purpose, created the [[mailing_lists/l4-hurd]] mailing list in November 2000. + +Over the years, a lot of discussion have been held on this mailing list, which +today is still the right place for [[next-generation Hurd|hurd/ng]] +discussions. + + +## Why? + +Even though that said resource management issues constitute a broad research +topic, there was no hope that the original Mach project would work on these: +[[microkernel/Mach]] wasn't maintained by its original authors anymore. Mach +had served its purpose as a research vehicle, and has been retired by its +stakeholders. + +Thus, switching to a well-maintained current [[microkernel]] was expected to +yield a more solid foundation for a Hurd system than the [[decaying +Mach|microkernel/mach/history]] design and implementation was able to. + +At that time, the [[L4 microkernel family|microkernel/L4]] was one obvious +choice. Being a second-generation microkernel, it was deemed to provide for a +faster system kernel implementation, especially in the time-critical [[IPC]] +paths. Also, as L4 was already implemented for a bunch of different +architectures (x86, Alpha, MIPS; also including SMP support), and the Hurd +itself being rather archtecture-agnostic, it was expected to be able to easily +support more platforms than with the existing system. + + +## Steps and Goals + +At the same time, the idea was -- while mucking with the system's core anyway +-- to improve on some fundamental design issues, too -- like the resource +management problems, for example. + +One goal of porting the Hurd to L4 was to make the Hurd independent of +[[microkernel/Mach]] interfaces, to make it somewhat microkernel-agnostic. + +One idea was to first introduce a Mach-on-L4 emulation layer, to easily get a +usable (though slow) Hurd-using-Mach-interfaces-on-L4 system, and then +gradually move the Hurd servers to use L4 intefaces rather than Mach ones. + +A design upon the lean L4 kernel would finally have made it feasible to move +devices drivers out of the kernel's [[TCB]]. + + +# Implementation + +The project itself then was mostly lead by Marcus Brinkmann and Neal Walfield. +Neal started the original Hurd/L4 port while visiting Karlsruhe university in +2002. He explains: + +> My intention was to adapt the Hurd to exploit L4's concepts and intended +> [[design_pattern]]s; it was not to simply provide a Mach +> [[compatibility_layer]] on top of L4. When I left Karlsruhe, I no longer had +> access to [[microkernel/l4/Pistachio]] as I was unwilling to sign an NDA. +> Although the specification was available, the Karlsruhe group only [released +> their code in May +> 2003](https://lists.ira.uni-karlsruhe.de/pipermail/l4ka/2003-May/000345.html). +> Around this time, Marcus began hacking on Pistachio. He created a relatively +> complete run-time. I didn't really become involved again until the second +> half of 2004, after I complete by Bachelors degree. + +Development of Hurd/L4 was done in the [CVS module +`hurd-l4`](http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd-l4/). The `doc` +directory contains a design document that is worth reading for anyone who +wishes to learn more about Hurd/L4. + +Even though there was progress -- see, for example, the [[QEMU image for +L4|hurd/running/qemu/image_for_l4]] -- this port never reached a releasable +state. Simple POSIX programs, such as `banner` could run, but for more complex +system interfaces, a lot more work was needed. + +Eventually, a straight-forward port of the original Hurd's design wasn't deemed +feasible anymore by the developers, partly due to them not cosidering L4 +suitable for implementing a general-purpose operating system on top of it, and +because of deficiencies in the original Hurd's design, which they discovered +along their way. Neal goes on: + +> Before Marcus and I considered [[microkernel/Coyotos]], we had already +> rejected some parts of the Hurd's design. The +> [[open_issues/resource_management_problems]] were +> what prompted me to look at L4. Also, some of the problems with +> [[hurd/translator]]s were already well-known to us. (For a more detailed +> description of the problems we have identified, see our [[hurd/critique]] in the +> 2007 July's SIGOPS OSR. We have also written a forward-looking +> [[hurd/ng/position_paper]].) + +> We visited Jonathan Shapiro at Hopkins in January 2006. This resulted in a +> number of discussions, some quite influential, and not always in a way which +> aligned our position with that of Jonathan's. This was particularly true of +> a number of security issues. + +A lange number of discussion threads can be found in the archives of the +[[mailing_lists/l4-hurd]] mailing list. + +> Hurd-NG, as we originally called it, was an attempt to articulate the system +> that we had come to envision in terms of interfaces and description of the +> system's structure. The new name was selected, if I recall correctly, as it +> clearly wasn't the Hurd nor the Hurd based on L4. + + +## Termination + +As of 2005, development of Hurd/L4 has stopped. + + +# Coyotos + +Following that, an attempt was started to use the kernel of the +[[microkernel/Coyotos]] system. As Coyotos is an object-capability system +througout, the microkernel would obviously be more suitable for this purpose; +and it looked pretty promising in the beginning. However, further +investigations found that there are some very fundamental philosophical +differences between the Coyotos and Hurd designs; and thus this this attempt +was also abandonned, around 2006 / 2007. (This time before producing any +actual code.) + + +# Viengoos + +By now (that is, after 2006), there were some new [[microkernel/L4]] variants +available, which added protected [[IPC]] paths and other features necessary for +object-capability systems; so it might be possible to implement the Hurd on top +of these. However, by that time the developers concluded that microkernel +design and system design are interconnected in very intricate ways, and thus +trying to use a third-party microkernel will always result in trouble. So Neal +Walfield created the experimental [[microkernel/Viengoos]] kernel instead -- +based on the experience from the previous experiments with L4 and Coyotos -- +for his [[research on resource +management|open_issues/resource_management_problems]]. Currently he works in +another research area though, and thus Viengoos is on hold. + + +# Intermediate Results + +Note that while none of the microkernel work is active now, the previous +experiments already yielded a lot of experience, which will be very useful in +the further development / improvement of the mainline (Mach-based) Hurd +implementation. diff --git a/history/port_to_another_microkernel/discussion.mdwn b/history/port_to_another_microkernel/discussion.mdwn new file mode 100644 index 00000000..f2161195 --- /dev/null +++ b/history/port_to_another_microkernel/discussion.mdwn @@ -0,0 +1,69 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, #hurd, 2011-01-12. + +[[!taglink open_issue_documentation]] + + <Pete-J> Hello i am just curious of the development of Hurd - what's the + current mission on the microkernel i see projects like l4 and viengoos, + will one of these projects replace Mach? or will you stick with Mach + <Pete-J> as i understand is that Mach is a first generation microkernel + that's very old in design and causes alot of issues + <Pete-J> that's where l4 and viengoos comes in - they are trying to be the + next generation Mach - am i correct? + <neal> l4 is not a drop in replacement for Mach + <neal> it doesn't actually do much resource management + <neal> for instance, you still have to implement a memory manager + <neal> this is where several issues are with Mach + <neal> l4 doesn't address those issues; it punts to the operating system + <Pete-J> and what about viengoos? + <neal> it's unfinished + <neal> and it implemented some untested ideas + <neal> i.e., parts of viengoos were research + <neal> there has not been a sufficient evaluation of those ideas to + determine whether they are a good approach + <Pete-J> meaning that viengoos is a research kernel that could aid Mach? + <neal> I'm not sure I understand your question + <Pete-J> Well is viengoos trying to be a replacement for Mach, or will + viengoos be an experiment of new ideas that could be implemented in Mach? + <Pete-J> i am sorry for my limited english + <neal> viengoos was designed with a Hurd-like user-land in mind + <neal> in that sense it was a Mach replacement + <neal> (unlike L4) + <neal> viengoos consisted of a few experiments + <neal> one could implement them in mach + <neal> but it would require exposing new interfaces + <neal> in which case, I'm not sure you could call the result Mach + <Pete-J> Well as i understand you develop two microkernels side by side, + wouldnt it be more effective to investigate viengoos more and maybe move + the focus to viengoos? + <antrik> no + <antrik> having something working all the time is crucial + <antrik> it's very hard to motivate people to work on a project that might + be useful, in a couple of years, perhaps... + <Pete-J> Well Mach is meant to be replaced one day - i see no reason to + keep on developing it just because it works at this moment + <Pete-J> *if Mach is meant to be replaced + <antrik> it's not at all clear that it will be replaced by something + completely different. I for my part believe that modifying the existing + Mach is a more promising approach + <Pete-J> as i understand man power is something you need - and by spreading + out the developers just makes the progress more slow + <antrik> but even if it *were* to be replaced one day, it doesn't change + the fact that we need it *now* + <antrik> all software will be obsolete one day. doesn't mean it's not worth + working on + <antrik> the vast majority of work is not on the microkernel anyways, but + on the system running on top of it + <Pete-J> ahh i see + <antrik> manpower is not something that comes from nowhere. again, having + something working is crucial in a volunteer project like this + <antrik> there are no fixed plans diff --git a/history/port_to_l4.mdwn b/history/port_to_l4.mdwn index cdf048e6..3f951a64 100644 --- a/history/port_to_l4.mdwn +++ b/history/port_to_l4.mdwn @@ -1,102 +1,13 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2007, 2008, 2009 -Free Software Foundation, Inc."]] +[[!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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!meta title="Porting the Hurd to L4: Hurd/L4"]] +[[!tag stable_URL]] -There was an effort to port the Hurd from [[microkernel/Mach]] to the -[[L4_microkernel_family|microkernel/L4]]. - -The idea of using L4 as a [[microkernel]] for a [[Hurd_system|hurd]] was -initially voiced in the [[Hurd_community|community]] by Okuji Yoshinori, who, -for discussing this purpose, created the [[mailing lists/l4-hurd]] mailing list -in November 2000. - -The project itself then was mostly lead by Marcus Brinkmann and Neal Walfield. -Even though there was progress -- see, for example, the -[[QEMU image for L4|hurd/running/qemu/image for l4]] -- this port never reached a -releasable state. Eventually, a straight-forward port of the original Hurd's -design wasn't deemed feasible anymore by the developers, partly due to them not -cosidering L4 suitable for implementing a general-purpose operating system on -top of it, and because of deficiencies in the original Hurd's design, which -they discovered along their way. Read the [[hurd/critique]] and a -[[hurd/ng/position paper]]. - -By now, the development of Hurd/L4 has stopped. However, Neal Walfield moved -on to working on a newly designed kernel called [[microkernel/viengoos]]. - -Over the years, a lot of discussion have been held on the -[[mailing lists/l4-hurd]] mailing list, which today is still the right place -for [[next-generation Hurd|hurd/ng]] discussions. - -Development of Hurd/L4 was done in the `hurd-l4` module of the Hurd CVS -repository. The `doc` directory contains a design document that is worth -reading for anyone who wishes to learn more about Hurd/L4. - - -One goal of porting the Hurd to L4 was to make the Hurd independend of Mach -interfaces, to make it somewhat microkernel-agnostic. - -Mach wasn't maintained by its original authors anymore, so switching to a -well-maintained current [[microkernel]] was expected to yield a more solid -foundation for a Hurd system than the decaying Mach design and implementation -was able to. - -L4 being a second-generation [[microkernel]] was deemed to provide for a faster -system kernel implementation, especially in the time-critical [[IPC]] paths. -Also, as L4 was already implemented for a bunch of different architectures -(IA32, Alpha, MIPS; SMP), and the Hurd itself being rather archtecture-unaware, -it was expected to be able to easily support more platforms than with the -existing system. - -A design upon the lean L4 kernel would finally have moved devices drivers out -of the kernel's [[TCB]]. - - -One idea was to first introduce a Mach-on-L4 emulation layer, to easily get a -usable (though slow) Hurd-using-Mach-interfaces-on-L4 system, and then -gradually move the Hurd servers to use L4 intefaces rather than Mach ones. - - -Neal Walfield started the original Hurd/L4 port while at Karlsruhe in 2002. He -explains: - -> My intention was to adapt the Hurd to exploit L4's concepts and intended -> [[design_pattern]]s; it was not to simply provide a Mach -> [[compatibility_layer]] on top of L4. When I left Karlsruhe, I no longer had -> access to [[microkernel/l4/Pistachio]] as I was unwilling to sign an NDA. -> Although the specification was available, the Karlsruhe group only [released -> their code in May -> 2003](https://lists.ira.uni-karlsruhe.de/pipermail/l4ka/2003-May/000345.html). -> Around this time, Marcus began hacking on Pistachio. He created a relatively -> complete run-time. I didn't really become involved again until the second -> half of 2004, after I complete by Bachelors degree. - -> Before Marcus and I considered [[microkernel/Coyotos]], we had already -> rejected some parts of the Hurd's design. The -> [[open issues/resource management problems]] were -> what prompted me to look at L4. Also, some of the problems with -> [[hurd/translator]]s were already well-known to us. (For a more detailed -> description of the problems we have identified, see our [[hurd/critique]] in the -> 2007 July's SIGOPS OSR. We have also written a forward-looking -> [[hurd/ng/position paper]].) - -> We visited Jonathan Shapiro at Hopkins in January 2006. This resulted in a -> number of discussions, some quite influential, and not always in a way which -> aligned our position with that of Jonathan's. This was particularly true of -> a number of security issues. - -A lange number of discussion threads can be found in the archives of the -[[mailing lists/l4-hurd]] mailing list. - -> Hurd-NG, as we originally called it, was an attempt to articulate the system -> that we had come to envision in terms of interfaces and description of the -> system's structure. The new name was selected, if I recall correctly, as it -> clearly wasn't the Hurd nor the Hurd based on L4. +[[!meta redir=port_to_another_microkernel]] diff --git a/hurd-l4.mdwn b/hurd-l4.mdwn index 579c1190..afc8f8f3 100644 --- a/hurd-l4.mdwn +++ b/hurd-l4.mdwn @@ -1,13 +1,13 @@ -[[!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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag stable_URL]] -[[!meta redir=history/port_to_l4]] +[[!meta redir=history/port_to_another_microkernel]] @@ -1,16 +1,16 @@ [[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, -2009 Free Software Foundation, Inc."]] +2009, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] The GNU Hurd is under active development. Because of that, there is no -*stable* version. We distribute the Hurd sources only through CVS at present. +*stable* version. We distribute the Hurd sources only through [[Git|source_repositories]] at present. Although it is possible to bootstrap the GNU/Hurd system from the sources by cross-compiling and installing the system software and the basic applications, @@ -29,9 +29,9 @@ in the *unstable* branch of the Debian archive. # Introduction * [[What_Is_the_GNU_Hurd]] - A Brief Description -* [[Advantages]] +* [[Advantages]]. And [[challenges]]. * [[History]] - * [[history/Port_to_L4]] + * [[history/Port_to_another_microkernel]] * [[Logo]] * [[Status]] * [[KnownHurdLimits]] @@ -47,6 +47,7 @@ in the *unstable* branch of the Debian archive. * Introductory Material * [[Documentation]] * [Gaël Le Mignot](http://kilobug.free.fr/hurd/pres-en/slides/slides.html) + * [Neal Walfield](http://kerneltrap.org/node/5) * Architecture * [[Towards_a_New_Strategy_of_OS_Design|hurd-paper]] by Thomas Bushnell, BSG. * Marcus Brinkmann's [revisit](http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00651.html) @@ -61,10 +62,10 @@ in the *unstable* branch of the Debian archive. * [[running/Distrib]] -- Distributions * [[Public_Hurd_Boxen]] * [[Neighborhurd]]s and [[Subhurd]]s +* [[DDE]] -- Device Driver Environment ## Common Problems -* [[Console]] * [[Xfree86]] -- [[DebianX]] -- [[DebianXorg]] * [[GNUstep]] * [[XattrHurd]]: Setting translators under GNU/Linux @@ -74,25 +75,30 @@ in the *unstable* branch of the Debian archive. * [[Contributing]] -* [[Building]] - * [[building/Cross-Compiling]] - * [[Open Issues|tag/open_issue_hurd]] # Developer References * [[Rules]] * [[Trackers]] +* [[Building]] * [[Toolchain]] * [[glibc]] +* RPC [[Interface]]s * Libraries * [[libpager]] + * [[libports]] * [[libstore]] * [[libchannel]] - * [[libhello_example]] -- Hurd library example + * [[libtrivfs]] * [[libnetfs]] -- short introductory material + * [[libdiskfs]] + * [[libihash]] + * [[libthreads]] + * [[libpthread]] * [[IO_Path]] * [[Porting]] * [[Debugging]] * [Hurd Sourcecode Reference](http://www.htu.tugraz.at/~past/hurd/global/): Searchable and browsable index of the code. * [[Networking]] +* [[Console]] diff --git a/hurd/advantages.mdwn b/hurd/advantages.mdwn deleted file mode 100644 index a181a942..00000000 --- a/hurd/advantages.mdwn +++ /dev/null @@ -1,60 +0,0 @@ -[[!meta copyright="Copyright © 2001, 2002, 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]]."]]"""]] - -The Hurd is not the most advanced kernel known to the planet (yet), -but it does have a number of enticing features: - - * **it's free software** - - Anybody can use, modify, and redistribute it under the terms of the - [[GNU_General_Public_License_(GPL)|GPL]] - - * **it's compatible** - - The Hurd provides a familiar programming and user environment. For all - intents and purposes, the Hurd is a modern Unix-like kernel. The Hurd uses - the [[GNU_C_Library|glibc]], whose development closely tracks standards - such as ANSI/ISO, BSD, POSIX, Single Unix, SVID, and X/Open. - - * **it's built to survive** - - Unlike other popular kernel software, the Hurd has an object-oriented - structure that allows it to evolve without compromising its design. This - structure will help the Hurd undergo major redesign and modifications - without having to be entirely rewritten. - - * **it's scalable** - - The Hurd implementation is aggressively multithreaded so that it runs - efficiently on both single processors and symmetric multiprocessors. The - Hurd interfaces are designed to allow transparent network clusters - (*collectives*), although this feature has not yet been implemented. - - * **it's extensible** - - The Hurd is an attractive platform for learning how to become a kernel - hacker or for implementing new ideas in kernel technology. Every part of - the system is designed to be modified and extended. - - * **it's stable** - - It is possible to develop and test new Hurd kernel components without - rebooting the machine (not even accidentally). Running your own kernel - components doesn't interfere with other users, and so no special system - privileges are required. The mechanism for kernel extensions is secure by - design: it is impossible to impose your changes upon other users unless - they authorize them or you are the system administrator. - - * **it exists** - - The Hurd is real software that works Right Now. It is not a research - project or a proposal. You don't have to wait at all before you can start - using and developing it. diff --git a/hurd/binutils.mdwn b/hurd/binutils.mdwn index 76b0ae60..f9266448 100644 --- a/hurd/binutils.mdwn +++ b/hurd/binutils.mdwn @@ -1,14 +1,11 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[General_information|/binutils]] about the binutils. - -There shouldn't be any differences within the binutils between, for example, -the GNU/Hurd and GNU/Linux ports. +[[!meta redir=/binutils]] diff --git a/hurd/building.mdwn b/hurd/building.mdwn index 01586c84..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. @@ -13,12 +8,20 @@ do what you expect it to do is the highest if you try building from the Debian source packages. This is especially true if you want to use your compilation within a Debian system. -## Getting the Source Code +Note that for building code to run on GNU/Hurd systems, you need a toolchain +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 You can chose between getting the [sources from the developers's -RCS](http://savannah.gnu.org/cvs/?group=hurd): +git](http://savannah.gnu.org/git/?group=hurd): - $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co hurd + $ git clone git://git.sv.gnu.org/hurd/hurd.git ... or (if you are working on a Debian system) the ones that are used for the [current Debian hurd package](http://packages.debian.net/source/unstable/hurd): @@ -30,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 @@ -41,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. @@ -65,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: @@ -93,12 +96,8 @@ to `make`: This will automatically build all libraries that are required to build the requested server or library. -### Cross Compiling -Read about [[cross-compiling]]. - - -## RPC IDs +# RPC IDs [TODO: update / integrate somewhere.] @@ -114,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/cross-compiling.mdwn b/hurd/building/cross-compiling.mdwn index 51b3abfc..73c19b4d 100644 --- a/hurd/building/cross-compiling.mdwn +++ b/hurd/building/cross-compiling.mdwn @@ -1,264 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -# `cross-gnu` +[[!tag stable_URL]] -[[Thomas_Schwinge|tschwinge]] has written a shell script for building a -complete cross-build environment for GNU/Hurd systems. - -For now, find the shell scripts at -<http://nic-nac-project.de/~schwinge/tmp/cross-gnu> and -<http://nic-nac-project.de/~schwinge/tmp/cross-gnu-env>. - - -## Using - -Read through it. Understand it. Only then use it by following the next steps. - -/!\ Be made aware that -- while it is of course possible to build a working -cross-compiler -- this is not trivial to do. You'll have to patch source -packages. See the following list about needed patches, which have not yet been -installed in the upstream repositories. - - -### Supported Versions of Source Packages - -The following ones are known to work. Others may work as well, but no -guarantee is given. Always the preferred version is listed first. - - * `src/binutils`: [[GNU_Binutils|binutils]] - - * CVS `binutils-2_19-branch` - - $ mkdir binutils-2_19-branch - $ cd binutils-2_19-branch - $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/src ↩ - co -r binutils-2_19-branch binutils - - The sources are rooted in `binutils-2_19-branch/src/`. Also use these - commands for updating, instead of the usual `cvs update`. - - * The 2.19 release tarball from <ftp://ftp.gnu.org/gnu/binutils/> should - also be fine. - - * CVS `binutils-2_18-branch` - - $ mkdir binutils-2_18-branch - $ cd binutils-2_18-branch - $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/src ↩ - co -r binutils-2_18-branch binutils - - The sources are rooted in `binutils-2_18-branch/src/`. Also use these - commands for updating, instead of the usual `cvs update`. - - * The 2.18 release tarball from <ftp://ftp.gnu.org/gnu/binutils/> should - also be fine, as should be all other recent releases. - - * `src/gcc`: [[GNU_Compiler_Collection|gcc]] - - * SVN `gcc-4_1-branch` - - $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch - - Prepare: - - $ ( cd gcc-4_1-branch/ && contrib/gcc_update --touch ) - - * Releases of the 4.1 series from <ftp://ftp.gnu.org/gnu/gcc/> should - also be fine. - - * SVN `gcc-4_2-branch` - - $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch - - * Patches: - <http://lists.gnu.org/archive/html/bug-hurd/2007-11/msg00034.html> - - Prepare: - - $ ( cd gcc-4_2-branch/ && contrib/gcc_update --touch ) - - * Releases of the 4.2 series from <ftp://ftp.gnu.org/gnu/gcc/> should - also be fine, but need the same set of patches as the `gcc-4_2-branch` - needs. - - * SVN `gcc-4_3-branch` - - $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch - - * Patches: - <http://lists.gnu.org/archive/html/bug-hurd/2007-11/msg00034.html> - - Prepare: - - $ ( cd gcc-4_3-branch/ && contrib/gcc_update --touch ) - - * Releases of the 4.3 series from <ftp://ftp.gnu.org/gnu/gcc/> should - also be fine, but need the same set of patches as the `gcc-4_3-branch` - needs. - - * SVN `trunk` -- upcoming 4.4 series - - $ svn co svn://gcc.gnu.org/svn/gcc/trunk - - Prepare: - - $ ( cd trunk/ && contrib/gcc_update --touch ) - - * `src/gnumach`: [[GNU_Mach|microkernel/mach/gnumach]] - - * CVS `gnumach-1-branch` - - $ cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd ↩ - co -r gnumach-1-branch gnumach - $ mv gnumach gnumach-1-branch - - Prepare: - - $ ( cd gnumach-1-branch/ && autoreconf -vfi ) - - * `src/mig`: [[microkernel/mach/mig/GNU_MIG]] - - * CVS `HEAD` - - $ cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co mig - - Prepare: - - $ ( cd mig/ && autoreconf -vfi ) - - * `src/hurd`: [[GNU_Hurd|hurd]] - - * CVS `HEAD` - - $ cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co hurd - - * `src/glibc`: [[GNU_C_Library|glibc]] - - * CVS `glibc-2_7-branch` - - $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/glibc ↩ - co -r glibc-2_7-branch glibc - $ mv libc glibc-2_7-branch - - * Patches: - <http://lists.gnu.org/archive/html/bug-hurd/2007-11/msg00030.html> - - * Recent releases of the 2.7 series from <ftp://ftp.gnu.org/gnu/glibc/> - should also be fine, but need the same set of patches as the - `glibc-2_7-branch` needs. - -<!-- - - * CVS `HEAD` - - $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/glibc ↩ - co glibc - $ mv libc glibc-HEAD - - * TODO. - <http://lists.gnu.org/archive/html/bug-hurd/2007-11/msg00026.html> - ---> - -<!-- - - * `src/gdb`: [[GNU_Debugger|gdb]] - - This is optional and will only be compiled if present. - - * CVS `gdb_6_6-branch` - - $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/src ↩ - co -r gdb_6_6-branch gdb - $ mv src gdb_6_6-branch - - Also needs some patch because of MIG changes, if I remember correctly. - - * Recent tarballs from <ftp://ftp.gnu.org/gnu/gdb/> should also work. - ---> - - -### Preparation - -Unpack the tarballs if you downloaded any. - -Create a directory where the cross build shall be rooted in and a `src` -subdirectory in there. Then create symbolic links for every of the above -packages: from `src/PACKAGE` to where you stored or unpacked it. If you don't -intend to build several cross compilers or use the source trees otherwise, you -can also directly store the source trees in `src/`. The source trees can be -shared between multiple cross build trees since the packages' build systems are -supposed not to modify the files in the source trees. Not all packages adhere -to that, but they fail to do so only for pre-processed documentation, etc. - -Either make sure that `cross-gnu-env` and `cross-gnu` are found in `$PATH` -(`~/bin/`, for example) or alternatively remember to use their full paths in -the following. - -The system you're running the script on (the *build* system) needs to have a -basic compiling environment installed, i.e., a C compiler with the basic -libraries and `make`. You might also need `flex` and `bison`. For building -recent version of GCC (e.g., the upcoming 4.3, which is not yet supported) -you'll need to have development packages of GMP and MPFR installed. - - -### Setting Up the Environment - -Do this every time you intend to use the cross compiler: - - $ ROOT=to/the/cross/build/root - $ . cross-gnu-env - -This will set several environment variables, which are later used by (a) the -`cross-gnu` script and (b) by you, the user of the cross compiler. `$TARGET` -will be set by the script, `$PATH` will be adjusted, etc. See the -`cross-gnu-env` file for all environment variables that are set, as well as -their default values. `$ROOT` will be made an absolute path if it isn't -already. - -Later, you'll be able to do things like `../configure --host="$TARGET"` and the -cross compiler will be found automatically. - - -### Creating the Cross Build Environment - -After setting up the environemt, just run `cross-gnu` and watch the messages -flow by. In the end you should see a message: *[...]/cross-gnu: Everything -should be in place now.* - - -### Makefile - -A [[Makefile]] has been written to automate the above steps. You will require -an Internet connection and atleast 1.5 GiB of hard-disk space. Just run... - - make - -... to build the toolchain. To clean up, use... - - make clean - - -### Staying Up-To-Date - -You can re-run `cross-gnu` to rebuild the parts of the sources that have -changed since the last run. This will save a lot of time compared to starting -from scratch again. Also, it is especially useful if you aren't working with -unpacked tarballs, but on CVS's branches or want to quickly get a new tool -chain with patches you applied to the source trees. However: do *not* use this -technique when doing major changes to the source trees, like switching from GCC -4.0 to GCC 4.1. - - -# References - -* <http://lists.gnu.org/archive/html/bug-hurd/2004-09/msg00030.html> +[[!meta redir=/toolchain/cross-gnu]] diff --git a/hurd/building/cross-compiling/Makefile b/hurd/building/cross-compiling/Makefile deleted file mode 100644 index 7a6a9524..00000000 --- a/hurd/building/cross-compiling/Makefile +++ /dev/null @@ -1,168 +0,0 @@ -# "HurdToolchainMakefile" - a Makefile for setting up Hurd toolchain builds - -# Copyright (C) 2007 Free Software Foundation, Inc. - -# This program 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. -# -# This program 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., -# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. - -# Written by Shakthi Kannan <shakthi.kannan@qvantel.com>. - - -## Variables -TOPDIR=. -DOWNLOADS=${TOPDIR}/downloads -ROOT=${TOPDIR}/root -SRC=${ROOT}/src -GLIBC_DIR=${SRC}/glibc -PATCH0_DIR=patch0 -PATCH1_DIR=patch1 - -## Patches -PATCH1 = 0003-2007-09-13-H.J.-Lu-hongjiu.lu-intel.com.patch \ - 0005-Hurd-specific-kernel-features.h.patch \ - 0007-2007-10-05-version-of-stat.patch.patch \ - 0008-r2425-of-debian-patches-hurd-i386-local-atomic-no-mu.patch \ - 0010-r2425-of-debian-patches-hurd-i386-local-gscope.diff.patch \ - 0012-r2425-of-debian-patches-hurd-i386-local-no-strerror_.patch \ - 0013-r2626-of-debian-patches-hurd-i386-local-tls-support.patch \ - 0014-r2591-of-debian-patches-hurd-i386-local-tls.diff.patch \ - 0015-r2630-of-debian-patches-hurd-i386-submitted-libc_onc.patch \ - 0016-Include-stdint.h.patch \ - 0017-r2598-of-debian-patches-any-local-stdio-lock.diff.patch \ - 0018-r2650-of-debian-patches-hurd-i386-submitted-strtoul.patch \ - 0019-2007-11-12-Aurelien-Jarno-aurelien-aurel32.net-Tho.patch \ - 0020-r2656-of-debian-patches-any-submitted-sched_h.diff.patch \ - 0022-2007-11-18-Roland-McGrath-roland-frob.com.patch - -PATCH0 = 0009-2007-07-22-version-of-init-first.c_vs._GCC_4.1.patch.patch \ - 0011-2007-02-08-version-of-resolv_res_send.c.patch.patch - -all: create_dir get_sources apply_glibc_patches build_all - -## Create directories -create_dir: - cd ${TOPDIR} - mkdir ${DOWNLOADS} - mkdir -p ${SRC} - -get_sources: get_cross_gnu get_binutils get_gcc get_gnumach get_mig get_hurd get_glibc - -get_cross_gnu: - @ echo " ___ _ __ ___ ___ ___ __ _ _ __ _ _ " - @ echo " / __| '__/ _ \/ __/ __|_____ / _\` | '_ \| | | |" - @ echo "| (__| | | (_) \__ \__ \_____| (_| | | | | |_| |" - @ echo " \___|_| \___/|___/___/ \__, |_| |_|\__,_|" - @ echo " |___/ " - cd ${DOWNLOADS}; \ - wget http://nic-nac-project.de/~schwinge/tmp/cross-gnu - @ echo " ___ _ __ ___ ___ ___ __ _ _ __ _ _ ___ _ ____ __" - @ echo " / __| '__/ _ \/ __/ __|_____ / _\` | '_ \| | | |_____ / _ \ '_ \ \ / /" - @ echo "| (__| | | (_) \__ \__ \_____| (_| | | | | |_| |_____| __/ | | \ V / " - @ echo " \___|_| \___/|___/___/ \__, |_| |_|\__,_| \___|_| |_|\_/ " - @ echo " |___/ " - cd ${DOWNLOADS}; \ - wget http://nic-nac-project.de/~schwinge/tmp/cross-gnu-env; \ - chmod +x cross-gnu; \ - chmod +x cross-gnu-env - -get_binutils: - @ echo " _ _ _ _ _ " - @ echo "| |__ (_)_ __ _ _| |_(_) |___ " - @ echo "| '_ \| | '_ \| | | | __| | / __|" - @ echo "| |_) | | | | | |_| | |_| | \__ \\" - @ echo "|_.__/|_|_| |_|\__,_|\__|_|_|___/" - cd ${SRC}; \ - cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/src co -r binutils-2_18-branch binutils; \ - mv src binutils - -get_gcc: - @ echo " __ _ ___ ___ " - @ echo " / _\` |/ __/ __|" - @ echo "| (_| | (_| (__ " - @ echo " \__, |\___\___|" - @ echo " |___/ " - cd ${SRC}; \ - svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch; \ - mv gcc-4_1-branch gcc; \ - ( cd gcc/ && contrib/gcc_update --touch ) - -get_gnumach: - @ echo " _ " - @ echo " __ _ _ __ _ _ _ __ ___ __ _ ___| |__ " - @ echo " / _\` | '_ \| | | | '_ \` _ \ / _\` |/ __| '_ \ " - @ echo "| (_| | | | | |_| | | | | | | (_| | (__| | | |" - @ echo " \__, |_| |_|\__,_|_| |_| |_|\__,_|\___|_| |_|" - @ echo " |___/ " - cd ${SRC}; \ - cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co -r gnumach-1-branch gnumach; \ - ( cd gnumach/ && autoreconf -vfi ) - -get_mig: - @ echo " _ " - @ echo " _ __ ___ (_) __ _ " - @ echo "| '_ \` _ \| |/ _\` |" - @ echo "| | | | | | | (_| |" - @ echo "|_| |_| |_|_|\__, |" - @ echo " |___/ " - cd ${SRC}; \ - cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co mig; \ - ( cd mig/ && autoreconf -vfi ) - -get_hurd: - @ echo " _ _ " - @ echo "| |__ _ _ _ __ __| |" - @ echo "| '_ \| | | | '__/ _\` |" - @ echo "| | | | |_| | | | (_| |" - @ echo "|_| |_|\__,_|_| \__,_|" - cd ${SRC}; \ - cvs -d:pserver:anoncvs@cvs.gnu.org:/cvsroot/hurd co hurd - -get_glibc: - @ echo " _ _ _ " - @ echo " __ _| (_) |__ ___ " - @ echo " / _\` | | | '_ \ / __|" - @ echo "| (_| | | | |_) | (__ " - @ echo " \__, |_|_|_.__/ \___|" - @ echo " |___/ " - cd ${SRC}; \ - cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/glibc co -r glibc-2_7-branch glibc; \ - mv libc glibc - mkdir ${GLIBC_DIR}/${PATCH0_DIR} - mkdir ${GLIBC_DIR}/${PATCH1_DIR} - -get_patch0: $(PATCH0) - -get_patch1: $(PATCH1) - -$(PATCH1): - wget -r -np -nd -P ${GLIBC_DIR}/${PATCH1_DIR} http://www.schwinge.homeip.net/~thomas/tmp/glibc-patches/$@ - cd ${GLIBC_DIR}; \ - patch -p1 < ${PATCH1_DIR}/$@ - -$(PATCH0): - wget -r -np -nd -P ${GLIBC_DIR}/${PATCH0_DIR} http://www.schwinge.homeip.net/~thomas/tmp/glibc-patches/$@ - cd ${GLIBC_DIR}; \ - patch -p0 < ${PATCH0_DIR}/$@ - -apply_glibc_patches: get_patch0 get_patch1 - -build_all: - ROOT=${TOPDIR}/root ; \ - export PATH="$(PATH):$(DOWNLOADS)" ; \ - echo $$PATH ; \ - . ${DOWNLOADS}/cross-gnu-env ; \ - ${DOWNLOADS}/cross-gnu - -clean: - rm -rf downloads root *~ diff --git a/hurd/building/cross-compiling/discussion.mdwn b/hurd/building/cross-compiling/discussion.mdwn deleted file mode 100644 index dbe317ad..00000000 --- a/hurd/building/cross-compiling/discussion.mdwn +++ /dev/null @@ -1,26 +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]]."]]"""]] - -What happens if the external link goes down? Is there any way to store files -within the wiki itself? --[[vincentvikram]] - -> You can store files in the wiki if you have direct access to the Git -> repository. - -> I'm not sure I'd like arbitrary people to be able to store files in the wiki, -> as that might be abused easily and once a file is stored in the Git -> repository, there's no clean way to get rid of it anymore. Of course, there -> are valid cases for adding raw files, then you can always send me a link and -> ask me to add that file. - -> Now, as for the `cross-gnu` shell script, as I said: it will eventually be -> made part of the Hurd CVS repository. - -> --[[tschwinge]] diff --git a/hurd/building/example.mdwn b/hurd/building/example.mdwn deleted file mode 100644 index bf31bf7e..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: - - cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co hurd - -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/chroot.mdwn b/hurd/chroot.mdwn new file mode 100644 index 00000000..60bf47b7 --- /dev/null +++ b/hurd/chroot.mdwn @@ -0,0 +1,51 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +This documents the currently-needed tricks to successfully build a chroot in +GNU/Hurd. + +# Preparation + +For proper translator startup, the chroot storage needs to be handled by a +separate translator, for instance: + + # dd < /dev/zero > storage + # mke2fs storage + # settrans -c chroot /hurd/ext2fs $PWD/storage + +# Unpack + +Debootstrap should be able to build the content: + + # debootstrap sid chroot + +# Tricks + +One current issue to know about chroots is that since passive translators (e.g. +/servers/socket/pflocal) are started by the root translator, which is not aware +of the chrooting, these passive translators are started non-chrooted, leading to +a few issues. + +## Sockets + +Since the passive pflocal translator will not be chrooted, local socket creation +will actually happen in the root filesystem. To make things work correctly the +programs inside the chroot need to be able to access them: + + # settrans chroot/servers/socket/1 /hurd/firmlink /servers/socket/1 + # settrans chroot/tmp /hurd/firmlink /tmp + # settrans -c chroot/var/lib/dbus /hurd/firmlink /var/lib/dbus + +## Network + +Unless using a separate IP for the chroot, it is preferrable to share the pfinet translator: + + # settrans chroot/servers/socket/2 /hurd/firmlink /servers/socket/2 + # settrans chroot/servers/socket/26 /hurd/firmlink /servers/socket/26 diff --git a/hurd/console.mdwn b/hurd/console.mdwn index 3895531b..55581870 100644 --- a/hurd/console.mdwn +++ b/hurd/console.mdwn @@ -1,3 +1,93 @@ +[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2011, +2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + + +# Architecture: client and server + +The Hurd console's implementation is broken into two pieces each running on +it's own process, the console client and server. + +The console client is also split into modules (input driver, display driver, +speaker, ...) but they all run in the same process. + +The console server puts itself as a translator on top of `/dev/vcs` folder +presenting the following hierarchy: + + + /dev/vcs + \ + +- 1 + \ + +- console + +- input + +- display + +- .. + +- n + +where the numbered nodes represent virtual consoles and their contents are all +alike. + +As the following graph shows, the console, input and display nodes are the +interfaces used by the terminal server, input driver and display drivers +respectively. + + +------------------+ +-----------------+ + | Input driver | | Terminal Server | + | | | | + | pc-kbd | | | + +------------------+ +-----------------+ + | _cons_vcons_input | + | writes to reads | + | vcs/i/input vcs/i/console | + | +-----------------+ | + | | Console Server | | + | | /hurd/console | | + | input_enqueue | --------------- | input_dequeue | + +--------------->| Input Queue |>---------------+ + | --------------- | + +--------------->| Output Buffer |>---------------+ + | +-----------------+ | + | | + | writes reads | + | vcs/i/console vcs/i/display | + | | + +----------------+ +-----------------+ + | Teminal Server | | Display driver | + | | | | + | /hurd/term | | vga | + +----------------+ +-----------------+ + +The input driver takes scancodes from the in-kernel kbd queue, translates them +into characters and writes them to the input node. Then the terminal server +reads the console node taking the characters out of the console server. + +Each of theese actions is actually an RPC handled by the translator on +`/dev/vcs`. Writes to input nodes are handled by calling `input_enqueue` to +put the character into a queue. And reads from console nodes are handled by +calling `input_dequeue` which takes out charecters from the queue and gives +them to the reader. + +It's important to note here that both `input_enqueue` and `input_dequeue` are +blocking operations and a blocked `input_dequeue` necessarily needs an +`input_enqueue` call to continue. + +[[RPC]]s are handled by the console server with the help of [[hurd/libports]]' +`ports_manage_multithreaded` API. + + +# Old stuff + +[[!taglink open_issue_documentation]]: cleanup needed. + The below is a reworked version of Marcus Brinkmann's [letter to the debian-hurd list](http://lists.debian.org/debian-hurd/2002/debian-hurd-200209/msg00054.html). It describes how to setup the new console server for the Hurd. I am testing this right now, so this document is a work in progress. -- [[Main/JoachimNilsson]] - 21 Jan 2003 @@ -16,10 +106,6 @@ The latest Hurd package in Debian has all that is needed to run (dunno about hur Additional information about the console can be found in the [Hurd Console Tutorial](http://uwhug.org.uk/index.pl?Hurd_Console_Tutorial) -## <a name="Table_of_Contents"> Table of Contents </a> - -%TOC% - ## <a name="What_is_the_new_console_"> What is the new console? </a> **_The new Hurd console features:_** @@ -276,3 +362,101 @@ An [experimental plugin to load XKB keymaps](http://kilobug.free.fr/hurd/xkb-0.3 Added examples that use repeaters needed by X. -- [[Main/OgnyanKulev]] - 18 Sep 2004 + + +# IRC, freenode #hurd, 2012-04-23 + + <Tekk_> is there any way to get copy/paste in hurd? + <Tekk_> with the console server + <Tekk_> like you get with gpm + <youpi> Tekk_: by implementing it + <antrik> Tekk_: that's something for the console client, not the server + <antrik> (or perhaps both? not entirely sure) + <Tekk_> antrik: I'm not entirely sure how the client works + <Tekk_> does it start a new client with each tty? + <Tekk_> or one client handles all of them? + <youpi> the client only should be enough + <youpi> it handles all input already anyway + <youpi> the client handles all ttys + <youpi> it just hops over them according to alt-Fx shortcuts + <antrik> Tekk_: there is only one client for all, but a separate console + *server* for each tty + <Tekk_> antrik: ah, the ever confusing X scheme + <antrik> no + <antrik> the client handles multiplexing and actual terminal I/O + <antrik> the servers handle the state of the virtual terminals, and provide + the device nodes + <antrik> this doesn't fit with the X scheme in any way + <antrik> (where everything is basically in one big monolithic server + process) + <Tekk_> antrik: I mean that you're running multiple servers and there's one + big client running on the other end + <Tekk_> which always pretty well confuses everyone to start with + <antrik> I totally fail to see the connection + <antrik> there is usually one X server, with potentially many clients + <Tekk_> nevermind + <Tekk_> doesn't really matter to anything + <Tekk_> so yeah, copy/paste would be in the client? + <antrik> unless you mean a termial server, running actual client programs, + connected to various terminals, running X servers... which is where it + gets confusing in a way ;-) + <antrik> but there is really no relation at all here + <Tekk_> antrik: exactly ;) + <Tekk_> I meant in the traditional sense, where you're on a thin client + running an X server and the remote server is running X clients + <Tekk_> copy/paste probably isn't really too bad + <antrik> applications are also clients of the terminal server processes; + but having a completely different role (and using completely different + requests) than the console client + <Tekk_> you have a buffer, when something is highlighted you strncpy the + highlighted text into the buffer. when middle click happens you send the + text to the right virtual terminal + <antrik> right. what I was considering is whether the pasting (and possibly + also grabbing) the text might be done through some separate protocol + implemented in the console server, rather than the ordinary console + client interfaces... but probably no need for that + <Tekk_> nah, as long as you have a way of getting a highlighted area and + then the text contained in it + <Tekk_> and then of course a way to insert text where the cursor is, but + I'm pretty sure you can safely assume that one :P + <antrik> well, the client has a way to send keystrokes to the server, + obviously. the question here is whether pretending the pasting is + keystrokes is good enough, or whether it might be useful to have an + explicit way to push the pasted stuff to the server + <antrik> (the cursor position is relevant only for echo) + <Tekk_> antrik: I'll try to grab the console source some time this week and + take a look + <Tekk_> maybe I can try to get it working + <antrik> good luck :-) + <antrik> it's probably not too hard + <Tekk_> I'm sure I'll need it :) + <antrik> the whole console machinery is quite hard to grasp (and I still + find myself confused sometimes, although I gained a pretty good + understanding I think when writing my thesis) + <antrik> but for this specific task, not much knowlegde should be needed + about the various confusing aspects + <Tekk_> hmm. looks like copy/paste won + <Tekk_> 't be a quick thing, actually + <Tekk_> wait, no. there must be a way to get mouse events + <Tekk_> how else could you move the mouse.. + <Tekk_> (with by moving your mouse, not cons_mouse_move) + <Tekk_> by moving your mouse* + <Tekk_> started typing something different + + +# Graphics/Higher Resolution + +## IRC, freenode #hurd, 2012-04-24 + + <Tekk_> does the console support higher resolutions yet? + <youpi> no + <youpi> it's just textonly + <antrik> Tekk_: the main reason why I originally started on the KGI work + was to get a graphical console... but I never finished that part + <antrik> (since KGI is obsolete anyways) + <antrik> BTW, there is a KMS-based userspace console now for Linux... I + guess it should be easy to adapt to other systems having KMS support + <antrik> I don't think it actually makes much sense for Linux, as it's one + of the hardest and least profitable things to move out of a monolithic + kernel... + <antrik> well, not hardest I guess; but most problematic diff --git a/hurd/dde.mdwn b/hurd/dde.mdwn new file mode 100644 index 00000000..6327a1ef --- /dev/null +++ b/hurd/dde.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2009, 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 +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 stable_URL]] + + * [[community/gsoc/project ideas/driver glue code]] + + * [[open issues/user-space device drivers]] + + * [[open issues/device drivers and io systems]] + +--- + +There is an effort going on to make [[/DDE]] usable in GNU/Hurd +userspace. + +See Zheng Da's [[project page|zhengda]], as well as another [[guide]]. diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn new file mode 100644 index 00000000..132b36ae --- /dev/null +++ b/hurd/dde/guide.mdwn @@ -0,0 +1,231 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +This guide explains how to build and set up +a DDE-based network card driver +with Debian GNU/Hurd, +if your (wired) network card +is not supported by the old in-kernel drivers shipped with gnumach. + +NOTE: As of hurd package 20120520-1, all that is already done for you, do *not* +do anything mentioned below, and you just need to configure your TCP/IP stack by +using settrans on /servers/socket/2, or dhclient /dev/eth0. + +This guide assumes that you have +an installation of Debian GNU/Linux on the same machine, +which helps in fetching the required packages +in absence of working networking in the Hurd. +The whole process is much more cumbersome otherwise. +It also assumes that apart from networking, +your Hurd system is already installed and operational. + +Debian now already includes dde support in both gnumach (>= +2:1.3.99.dfsg.git20120219-1) and hurd (>= 20120219-1), so in the steps below, +building gnumach will not be needed. Also, be sure to use the dde-debian branch +instead of dde. + + +We start by booting into Debian GNU/Linux, +so we can download everything we will need for building DDE. If you have already a way to download things from the Hurd image, skip to "Get DDE code" below. + +Once there, first mount the Hurd partition (as root): + + $ mount /dev/hdd1 /mnt -t ext2 # assuming your Hurd partition is hdd1 -- replace with whatever matches your setup + +Prepare apt offline configuration so we can get necessary packages: + + $ cd /mnt/etc/apt + + $ echo "deb http://ftp.debian-ports.org/debian unreleased main" >> sources.list # if you don't have sources.list set up yet on the Hurd system + + $ echo "deb-src http://ftp.debian-ports.org/debian unreleased main" >> sources.list + + $ echo "deb http://ftp.uk.debian.org/debian unstable main" >> sources.list + + $ echo "deb-src http://ftp.uk.debian.org/debian unstable main" >> sources.list + + $ wget http://www.gnu.org/software/hurd/hurd/running/debian/DebianAptOffline/apt.conf.offline + +Download the packages for offline installation: + + $ cd /mnt + + $ apt-get -c etc/apt/apt.conf.offline update + + $ apt-get -c etc/apt/apt.conf.offline build-dep hurd gnumach + + $ apt-get -c etc/apt/apt.conf.offline install git-core build-essential libpciaccess-dev libpcap0.8-dev hurd-dev zlib1g-dev + +Get DDE code: + + $ cd /mnt/home/me # assuming your user name on the Hurd system is "me" + + $ mkdir dde && cd dde + +Note: here, use dde-debian instead of dde if you have gnumach >= +2:1.3.99.dfsg.git20120219-1 already installed and running. Otherwise you will +get "vm_allocate_contiguous: (ipc/mig) bad request message ID" error messages. + + $ git clone git://git.sv.gnu.org/hurd/incubator.git -b dde hurd + + $ git clone git://git.sv.gnu.org/hurd/gnumach.git -b master-user_level_drivers + +Now comes the tricky part: +you need to find out +whether there is already a driver for your card +in the DDE source tree, +and otherwise get the driver code +from the official Linux source tree. + +For this, you have to find out which Linux driver +is responsible for your network card. +In this guide we will use the forcedeth driver +(for Nvidia nForce chipsets) as example. +We check whether there is already a `dde_forcedeth` directory +in the newly cloned `hurd_dde` tree. +If there isn't, we have to find and download +the right source file from Linux: + +Point a (JavaScript-capable) web browser at + + http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tree;f=drivers/net;hb=refs/heads/linux-2.6.29.y + +(Note: you **have** to use some 2.6.29.y (whatever the y, prefer the latest), as +this is the version DDE is currently based on.) + +Find the right file to download +(forcedeth.c in this example); +then hit the "raw" link, +and save the resulting file (page) to /mnt/home/me/dde + +(If you happen to need one of the few drivers +that consist of more than one source file, +the process will be more complicated, +and can't be covered in this guide...) + + +Now everything should be in place, +so we can boot into Hurd to do the actual work. + +Once there, install the packages previously downloaded (again as root): + + $ apt-get build-dep hurd gnumach + + $ apt-get install git-core build-essential libpciaccess-dev libpcap0.8-dev hurd-dev zlib1g-dev + +Make sure we can build stuff as normal user: + + $ chown -R me ~me/dde + +Now you can log in with the normal user account to build stuff. + +Build a DDE-enabled Mach. Not needed if you have gnumach >= 2:1.3.99.dfsg.git20120219-1 already installed and running: + + $ cd ~me/dde/gnumach + + $ autoreconf -i && ./configure --enable-kdb --enable-device-drivers=none --enable-lpr --enable-floppy --enable-ide + + $ make + + +If not already present in DDE, +we need to prepare the driver for the network card (else, skip to "Having prepared the driver" below): + + $ cd ~me/dde/hurd + + $ cp -r dde_pcnet32 dde_forcedeth # using pcnet32 as template + + $ cd dde_forcedeth + + $ rm pcnet32.c # don't want the actual pcnet32 code here... + + $ cp ~me/dde/forcedeth.c . # ...but rather the forcedeth code + + $ sed -i 's/pcnet32/forcedeth/g' Makefile # adapt Makefile accordingly + + $ sed -i 's/pcnet32/forcedeth/g' .gitignore + + $ sed -i 's:-lhurd-slab:../libhurd-slab/libhurd-slab.a:' Makefile # fix up build system... XXX I guess this part is obsolete + + $ sed -i 's:-I/include:-I..:' Makefile # same + + $ nano forcedeth.c # Near the top of the file, there will be many #include lines. After the last one, add this: + + #include <ddekit/timer.h> + + $ cd .. + +Commit the new driver with git. +This will be helpful if we update the DDE code later; +as well as for creating a patch for later reuse +and/or upstream submission: + + $ git add dde_forcedeth + + $ git commit -a -m 'Add forcedeth driver' + + +Having prepared the driver, +we can now build the necessary Hurd and DDE bits: + + $ autoreconf -i && ./configure + + $ make libddekit libmachdev devnode pfinet # Hurd components. This is not needed if you have the Debian hurd-dev >= 20120219-1 package already installed. + + $ make -C libdde_linux26 # common DDE driver code -- uses a different Makefile system than the Hurd components! This is not needed if you have the Debian hurd-dev >= 20120219-2 package already installed. + +If you have the Debian hurd-dev >= 20120219-2 package already installed (and thus skipped the previous steps), run: + + $ make -C dde_forcedeth PKGDIR=/usr/share/libdde_linux26 # actual driver + +otherwise, after doing the previous steps, use: + + $ make -C dde_forcedeth # actual driver + +Install the various built components to their final destinations (as root). You only need to install dde_forcedeth if you are already running the Debian gnumach >= 2:1.3.99.dfsg.git20120219-1 and hurd-dev >= 20120219-1 packages: + + $ cd ~me/dde/ + + $ cp gnumach/gnumach /boot/gnumach_dde + + $ cp hurd/devnode/devnode hurd/pfinet/pfinet hurd/dde_forcedeth/dde_forcedeth /hurd + + +Now everything should be ready. +Before we can use the driver, +we have to boot with the newly built gnumach_dde +instead of the standard kernel. +(Adapt your grub configuration; +or manually edit the entry +in the boottime grub menu while testing.) + +Once there, set up the translators for the driver (as root): + + $ settrans -cap /dev/forcedeth /hurd/dde_forcedeth + +If that spews error "vm_allocate_contiguous: (ipc/mig) bad request message ID", +you are mixing things: either use the debian kernel and the dde-debian incubator +branch, or use your kernel built from the master-user_level_drivers branch and +the dde incubator branch, but don't make any mixture. + + $ settrans -cap /dev/eth0 /hurd/devnode -M /dev/forcedeth eth0 + +Finally, we can set up the actual network translator, +using something like: + + $ settrans -cap /servers/socket/2 /hurd/pfinet -i /dev/eth0 -a 192.168.1.194 -g 192.168.1.254 -m 255.255.255.0 + +For the exact syntax, +see the normal network setup documentation. +The only differences here +are the different location of the pfinet binary, +and the different syntax for the -i option. + +Check Arch/Hurd recipe on git://projects.archhurd.org/packages.git diff --git a/hurd/dde/guide/discussion.mdwn b/hurd/dde/guide/discussion.mdwn new file mode 100644 index 00000000..a1cccad4 --- /dev/null +++ b/hurd/dde/guide/discussion.mdwn @@ -0,0 +1,17 @@ +[[!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]]."]]"""]] + +ToDo: + +[[!tag open_issue_documentation]] + +* This guide is probably out of date in some points: the build system got reworked in the meantime I believe... +* The formatting here needs serious cleanup +* Might be nice to explain how to find out the right Linux driver, and in which source file it resides diff --git a/hurd/debugging.mdwn b/hurd/debugging.mdwn index 36ab769a..d6e9c8b5 100644 --- a/hurd/debugging.mdwn +++ b/hurd/debugging.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + # Strategies @@ -20,3 +22,4 @@ is included in the section entitled * [[glibc]] * [[translator]]s + * [[trap_in_the_kernel]] diff --git a/hurd/debugging/glibc.mdwn b/hurd/debugging/glibc.mdwn index 905dd0da..028d4fe4 100644 --- a/hurd/debugging/glibc.mdwn +++ b/hurd/debugging/glibc.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Here are some hints about how to approach testing after nontrivial changes to glibc have been done. @@ -15,7 +16,7 @@ glibc have been done. First step is having the build of glibc succeed. This is actually more difficult than one might expect as it involves (towards the end of the build -process -- unless you are [[building/cross-compiling]], of course -- that the +process -- unless you are cross-compiling, of course -- that the newly created libraries and loader actually work: they'll be used to run the `rpcgen` program. If that step doesn't succeed, it'll look similar to this: @@ -25,12 +26,10 @@ newly created libraries and loader actually work: they'll be used to run the --- -Unless [[building/cross-compiling]], the next thing you'll probably want to do +Unless cross-compiling, the next thing you'll probably want to do is running the test suite, or parts of it. -Here is a list of known failures: - -[TODO]. +There is a list of [[known failures|open_issues/glibc]]. --- diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index 63b72ee0..df6290f7 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] *rpctrace* is -- roughly -- an equivavlent to Linux's *strace* or Solaris' or BSD's *truss*. It is used to trace [[remote_procedure_call|rpc]]s a process is @@ -17,6 +18,8 @@ See `rpctrace --help` about how to use it. # Issues and Patches +[[!tag open_issue_hurd]] + * <http://savannah.gnu.org/patch/?2104> -- don't assert that local port names are valid * <http://savannah.gnu.org/bugs/?3939> -- `rpctrace`d program hangs when signal @@ -24,12 +27,147 @@ See `rpctrace --help` about how to use it. * <http://savannah.gnu.org/patch/?1633> -- terminated with `C-c` `rpctrace`d programs hang * <http://savannah.gnu.org/patch/?5580> -- more readable output -* <http://savannah.gnu.org/bugs/?20612> -- heisenbug + +* IRC, unknown channel, unknown date + + <youpi> how to rpctrace a translator ? + <youpi> ah, just settrans /usr/bin/rpctrace... + <youpi> hum, it hung, and killing it got a Mach panic (thread in unexpected + state) ... + +* IRC, unknown channel, unknown date + + <antrik> hm... for a funny effect, try running rpctrace on + /servers/socket/1, and then use dpkg... ;-) + +* IRC, unknown channel, unknown date. + + <youpi> the problem of rpctrace is that it's a man in the middle :) + <youpi> so in principle, by design authentication stuff shouldn't work + <antrik> I don't think the Hurd auth mechanism in any way prevents or tries to prevent man-in-the-middle... + <youpi> maybe, but just try, you'll see all kinds of issue as soon as you have authentication stuff + <youpi> and the basic reason is that being a man in the middle needs special care + <youpi> which rpctrace doesn't completely do + <antrik> it's a while since I have dived into rpctrace; but AIUI, it should work just fine if the proxying is done properly + <antrik> note that there is a number of known bugs in rpctrace, for which zhengda has sent patches... though I haven't reviewed all of them I think + <antrik> there are some nasty Mach operations that are really hard to proxy -- but I don't think the auth mechanism needs any of these... + +* IRC, freenode, #hurd, 2011-11-04 + + [[!taglink open_issue_documentation]] + + <mcsim> hello. Are there any documentation about understanding output + of rpctrace? + <braunr> no + <braunr> you should read the source code, best doc available + <braunr> if you have too many numbers and almost no symbolc names, + you're lacking rpc definition lists + <braunr> check that the gnumach-common package is installed, as it + provides the gnumach definitions + <braunr> (the glibc ones are almost always available) + <braunr> with those two, you should be fine for the beginning + <mcsim> gnumach-common is installed. And what is the name for glibc + package for gnumach definitions. + <mcsim> Also I'm using libraries specified by LD_LIBRARY_PATH. Does it + make influence on absence of symbolic names? + <braunr> no + <braunr> rpctrace --help + <braunr> see the --rpc-list=FILE option + <braunr> the default lists are in /usr/share/msgids/, with the .msgids + extension + <braunr> $ dpkg -S msgids + <braunr> gnumach-common: /usr/share/msgids/gnumach.msgids + <braunr> hurd: /usr/share/msgids/hurd.msgids + <braunr> ok, glibc has none, it's the hurd + <braunr> for more details about the output, read the source code + <braunr> it shouldn't be that hard to grasp + <mcsim> -I /usr/share/msgids helped + <mcsim> thank you + <braunr> it shouldn't have, it's the default path + <mcsim> but symbolic names appeared + <braunr> well, that's weird :) + <pinotree> braunr: the output of rpctrace --help should tell the + default dir for msgids + +* IRC, freenode, #hurd, 2012-06-30 + + <mcsim> hello. Has anyone faced with problem when translator works + fine, but when it is started via rpctrace it hangs? Probably you know + what can cause this? + <antrik> mcsim: rpctrace itself is quite buggy + <antrik> zhengda once did a number of improvements, but they never went + upstream... + <youpi> well, he never explained how his fixes worked :) + <youpi> GNU/Hurd is no different from other projects in that regard: if + you don't explain how your patches work, there's low chance that they + are applied + <youpi> unless the maintainer has time to dive himself, which we don't + <pinotree> "it compiles, ship it!" + <braunr> pinotree: i guess the hurd is different in that particular + regard :p + <youpi> not different from linux + <braunr> eh, they include staging drivers now :) + <youpi> we have a sort-of staging tree as well, with netdde + <youpi> we don't really care about stability there + <antrik> youpi: actually, I think by now (and not to a small part + because of this episode) that we are too strict about patch + submission + <youpi> well, review really is needed, otherwise source gets into a bad + shape + <antrik> while zhengda's variant might not have been ideal (nobody of + us understands the workings of rpctrace enough to tell), I have + little doubt that it would be an improvement... + <youpi> it happened quite a few times that a fix revealed to be + actually bogus + <youpi> in that particular case, I agree + <youpi> the problem is that usually what happens is that questions are + asked + <youpi> and the answers never happen + <youpi> and thus the patch gets lost + <antrik> after all, when he when he submitted that patch, he had a much + better understanding of rpctrace than any of us... + <youpi> sure + <antrik> Linus is actually quite pragmatic about that. from what I've + seen, if he can be convinced that something is *probably* an + improvement over the previous status, he will usually merge it, even + if he has some qualms + <youpi> when there is a maintainer, he usually requires his approval, + doesn't he? + <antrik> in particular, for code that is new or has been in a very bad + shape before, standards shouldn't be as high as for changes to known + good code. and quite frankly, large parts of the Hurd code base + aren't all that good to begin with... + <youpi> sure + <antrik> well, sure. in this case, we should have just appointed + zhengda to be the rpctrace maintainer :-) + <antrik> BTW, as his version is quite fundamentally different, perhaps + instead of merging the very large patch, perhaps we should just ship + both versions, and perhaps drop the old one at some point if the new + one turns out to work well... + <antrik> (and perhaps I overused the word perhaps in that sentence + perhaps ;-) ) + <youpi> about that particular patch, you had needed raised a few bits + <youpi> and there was no answers + <youpi> the patch is still in my mbox, far away + <youpi> so it was *not* technically lost + <youpi> it's just that as usual we lack manpower + <antrik> yeah, I know. but many of the things I raised were mostly + formalisms, which might be helpful for maintaining high-quality code, + but probably were just a waste of time and effort in this case... I'm + not surprised that zhengda lost motivation to pursue this further :-( + <braunr> it would help a lot to get the ton of patches in the debian + packages upstream :) + <youpi> braunr: there aren't many, and usually for a good reason + <youpi> some of them are in debian for testing, and can probably be + commited at some point + <pinotree> youpi: we could mark (with dep3 headers) the ones which are + meant to be debian-specific + <youpi> sure + <antrik> well, there are also a few patches that are not exactly + Debian-specific, but not ready for upstream either... + <youpi> antrik: yes -# TODO +# See Also - <youpi> how to rpctrace a translator ? - <youpi> ah, just settrans /usr/bin/rpctrace... - <youpi> hum, it hung, and killing it got a Mach panic (thread in unexpected - state) ... +See also [[open_issues/librpci]]. diff --git a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn index 1e8c4ef6..b7cfc3c9 100644 --- a/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn +++ b/hurd/debugging/translator/capturing_stdout_and_stderr.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -33,6 +34,4 @@ using the appropriate glibc magic (`setvbuf`). Otherwise you'll see text in the output files only if either glibc herself decides to flush (after some KiB of text) the after translator exits. -It is a [[!taglink open_issue_hurd]] to decide / implement / fix that -(all?) running (passive?) translators' output should show up on the -console / syslog. +There is also a [[related open issue|open_issues/translator_stdout_stderr]]. diff --git a/hurd/debugging/trap_in_the_kernel.mdwn b/hurd/debugging/trap_in_the_kernel.mdwn new file mode 100644 index 00000000..11f989e3 --- /dev/null +++ b/hurd/debugging/trap_in_the_kernel.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_documentation]] + +IRC, #hurd, September 2010 + + <diegonc> when an application executes an out instruction in user mode, how is + kernel mode entered? general protection trap? + <youpi> some sort of trap, yes + <youpi> I'd rather think about illegal instruction, but yes + <diegonc> hm.. so to debug what happens inside that instruction I'll have to + break at the trap handler. Can I instruct kdb to stop only when a given task + caused the trap? + <youpi> applications usually don't trap, so what I usually do is to uncomment + the test at the end of user_trap() before the call to kdb_trap() + <diegonc> "if (debug_all_traps_with_kdb && .. " <- that test? + <youpi> yes + <youpi> so comment the test to make kdb_trap() called all the time + <diegonc> oh, I understand now :) diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index 589246bd..48fd017c 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -1,5 +1,5 @@ [[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, -2009 Free Software Foundation, Inc."]] +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 @@ -24,6 +24,8 @@ is included in the section entitled * [[*The_Hurd*|/hurd-talk]], a presentation by Marcus Brinkmann. + * The *[[translator_primer]]*. + * A document about *[[translators]]* by Marcus Brinkmann. * [[*A_Critique_of_the_GNU_Hurd_Multi-server_Operating_System*|critique]], an @@ -63,3 +65,9 @@ is included in the section entitled [[Position_paper_*Improving_Usability_via_Access_Decomposition_and_Policy*|ng/position_paper]] Neal Walfield and Marcus Brinkmann give an overview about how a future, subsequent system may be architected. + + * [*Generalizing mobility for the Hurd*](http://users.student.lth.se/cs07fh9/2009-hammar-hurd-mobility.pdf), + a thesis written by Carl Fredrik Hammar, + investigates the mobility aspect of stores + and how it can be generalized and used for other applications. + The background chapter may be of interest to new developers. diff --git a/hurd/documentation/translator_primer.mdwn b/hurd/documentation/translator_primer.mdwn new file mode 100644 index 00000000..e5c8c160 --- /dev/null +++ b/hurd/documentation/translator_primer.mdwn @@ -0,0 +1,85 @@ +[[!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]]."]]"""]] + +# Small Examples on Using Translators + +The [[concept|concepts]] of user-space servers, [[translator]]s, is a very +powerful one. Here is an introductionary text. + + +## Intro + +The Hurd has some unique capabilities, and we created this simple image +to enable you to easily try three of them: + +* The simplest of translators: Hello World! +* Transparent FTP +* Mount a remote ISO file + +### Hello World + +To try out the simplest of translators, you can go the following simple steps: + + $ touch hello + $ cat hello + $ settrans hello /hurd/hello + $ cat hello + "Hello World!" + $ settrans -g hello + $ cat hello + +What you do with these steps is first verifying that the file "hello" is empty. + +Then you setup the translator /hurd/hello in the file/node hello. + +After that you check the contents of the file, and the translator returns "Hello World!". + +To finish it, +you remove the translator from the file "hello" +(and tell any active running instances to go away) +via "settrans -g hello". +Having done that, verify that now the file is empty again. + +### Transparent FTP + +We already setup a a transparent FTP translator for you at /ftp: + +With it you can easily access public FTP via the file system, for example the one from the GNU project: + + $ ls /ftp://ftp.gnu.org/ + +But you can also do this very easily yourself: + + $ # Setup the translator on the node ftp: + $ settrans -c ftp: /hurd/hostmux /hurd/ftpfs / + +and you can access FTP sites via the pseudo-directory ftp:, for example with + + $ ls ftp://ftp.gnu.org/ + +What you do here is setting up the translator /hurd/hostmux on ftp: and passing it the translator /hurd/ftpfs to use for resolving accesses as well as / as additional path component. + +### ISO file mount + +Now that we can access ftp.gnu.org transparently, let's mount a remote ISO file: + + $ settrans -c mnt /hurd/iso9660fs ftp://ftp.gnu.org/old-gnu/gnu-f2/hurd-F2-main.iso + $ ls mnt/ + +It is interesting to note that since the ISO9660 format is indexed, ftpfs does not have to download the whole ISO file, it merely fetches what iso9660fs requests. + + +These were only three basic usages of translators on the Hurd. We're sure you'll quickly see many other ways to use this. + +As a last comment: You can setup a translator on any node you have access to, so you can for example mount any filesystems as normal user. + +You might currently be logged in as root, but you could just as well do the same as normal user. + +Why don't you try it out? diff --git a/hurd/faq.mdwn b/hurd/faq.mdwn index be30e1b4..413aaf3f 100644 --- a/hurd/faq.mdwn +++ b/hurd/faq.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,6 +10,8 @@ is included in the section entitled [[!meta title="GNU Hurd FAQ"]] +See also other [[/FAQ]]. + [[!inline pages="hurd/faq/* and !*/discussion" show=0 diff --git a/hurd/faq/how_about_drivers.mdwn b/hurd/faq/how_about_drivers.mdwn new file mode 100644 index 00000000..0556fd28 --- /dev/null +++ b/hurd/faq/how_about_drivers.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2009 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="What drivers does GNU/Hurd have?"]] + +Currently, Mach integrates drivers from Linux 2.0 through some glue code. As +it's very old, that limits hardware support a lot, of course. We are however +working on using the DDE toolkit to run linux drivers in userland processes, +which provides both long-term support for new hardware and safety against driver +bugs. diff --git a/hurd/faq/how_to_switch_microkernels.mdwn b/hurd/faq/how_to_switch_microkernels.mdwn new file mode 100644 index 00000000..21f7a371 --- /dev/null +++ b/hurd/faq/how_to_switch_microkernels.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="How difficult would it be to switch to another microkernel?"]] + +One would have to reimplement the `mach/` and `sysdeps/mach/` parts of +[[glibc]] and [[libpthread]]. Quite a few other Hurd tools also assume a +[[microkernel/Mach]] kernel and would have to be adapted or rewritten. diff --git a/hurd/faq/off.mdwn b/hurd/faq/off.mdwn new file mode 100644 index 00000000..64009101 --- /dev/null +++ b/hurd/faq/off.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="How am I supposed to shut my Hurd system down?"]] + +The GNU/Hurd does not use SYSV runlevels, so commands like + + $ shutdown -h now + +will not work. Simply use the equivalent shortcut + + $ halt + +which is provided natively on GNU/Hurd, instead of from SYSV runlevels. + +Note that due to a bug, +we [[recommend you run syncfs|open_issues/sync_but_still_unclean_filesystem]] +prior to issuing the `halt` command. diff --git a/hurd/faq/old-stuff.mdwn b/hurd/faq/old-stuff.mdwn index 6968a894..df2058c0 100644 --- a/hurd/faq/old-stuff.mdwn +++ b/hurd/faq/old-stuff.mdwn @@ -6,7 +6,7 @@ If you still have problems, do not hesitate to make use of the [[mailing lists]] * Yes and no. GNU refers to the system as a whole, while GNU/Hurd is more specific, saying that it is the GNU system running on the Hurd -- to differentiate it from the GNU system running on Linux, GNU/Linux. Also see [[GNU/GnuNames]] * **_What editor can I use?_** - * `nano` is the default editor on a fresh install, not `ae`. + * `nano` is the default editor on a fresh install, not `ae`, but a lot of editors are available. * **_Why can't I get the answers I need from Hurd hackers?_** * This [document](http://www.catb.org/~esr/faqs/smart-questions.html) may help you understand some developers attitudes and social norms. @@ -28,16 +28,16 @@ If you still have problems, do not hesitate to make use of the [[mailing lists]] * These are different versions of the Mach microkernel that supports the Hurd that runs on top of it. For more info, see [[Mach]] * **_What software is available for GNU?_** - * Most packages from [Debian](http://www.debian.org/) [GNU/Linux](http://www.gnu.org/gnu/linux-and-gnu.html) which aren't linux-specific ([Packages That Won't Be Ported](http://www.debian.org/ports/hurd/hurd-devel-debian)) are expected to work on GNU/Hurd too. See the database in <http://packages.debian.org/>. Programs which need pthreads, including [GNOME](http://www.gnome.org), [KDE](http://www.kde.org), [Mozilla](http://www.mozilla.org), [OpenOffice](http://www.openoffice.org), [SDL](http://www.libsdl.org), etc. are being worked on currently using Neal Walfields libpthreads. See the [[porting/guidelines]] document for some common build problems and their solutions. + * Most (2/3) packages from [Debian](http://www.debian.org/) [GNU/Linux](http://www.gnu.org/gnu/linux-and-gnu.html) which aren't linux-specific ([Packages That Won't Be Ported](http://www.debian.org/ports/hurd/hurd-devel-debian)) are expected to work on GNU/Hurd too. See the database in <http://packages.debian.org/>. Notably, [GNOME](http://www.gnome.org), and [KDE](http://www.kde.org) work. See the [[porting/guidelines]] document for some common build problems and their solutions. * If you can't fetch a package with "apt-get install ", try building it from source: "apt-get source && cd <package\_dir> && debian/rules binary". - * As of January 2007, 50% of Debian packages have been ported on the Hurd. Of course, bug testing is welcome. + * As of April 2010, 65% of Debian packages have been ported on the Hurd. Of course, bug testing is welcome. * **_How do I initialize a serial console on the Hurd?_** * You can try out the Serial Howto at <http://www.nongnu.org/thug/serial-howto.txt> * For a real serial console at boot time you need to rebuild your GNUmach 1.x kernel. For more info see the Utah release notes at [http://www.cs.utah.edu/flux/mach4-i386/html/mach4-UK22.html#serial\_console](http://www.cs.utah.edu/flux/mach4-i386/html/mach4-UK22.html#serial_console) * **_Will GNU work in Vmware?_** - * It's highly recommended and easier to get a full image for Bochs. See [[Distrib]] + * It's highly recommended and easier to get a full image for qemu. See [[Distrib]] * It didn't use to, [Hurd bootstrap fails](http://lists.debian.org/debian-hurd/2002/debian-hurd-200207/msg00069.html). Vmware is not [free software](http://www.gnu.org/philosophy/free-sw.html) and it is [[Distrib/VmWare]]. We recommend to use [free](http://www.gnu.org/philosophy/free-sw.html) alternatives, like [[Distrib/BochsEmulator]]. * A faster, more widespread and [free](http://www.gnu.org/philosophy/free-sw.html) recent alternative is [QEMU][[running/QEMU]]. You can find more informations on [[running/QEMU]]. * If someone prefers using VMWare: diff --git a/hurd/faq/old_hurd_faq.txt b/hurd/faq/old_hurd_faq.txt index c7e0ffe8..e6c6cb5a 100644 --- a/hurd/faq/old_hurd_faq.txt +++ b/hurd/faq/old_hurd_faq.txt @@ -89,7 +89,7 @@ Q4. What's all this about Mach 3.0 (and Mach 4.0)? As mentioned above, Mach is a micro-kernel, written at Carnegie Mellon University. A more descriptive term might be a greatest-common-factor kernel, since it provides facilities common to all ``real'' operating -systems, such as memory management, interprocess communication, +systems, such as memory management, inter-process communication, processes, and a bunch of other stuff. Unfortunately, the system calls used to access these facilities are only vaguely related to the familiar and cherished Unix system calls. There are no "fork", diff --git a/hurd/faq/slash_usr_symlink/discussion.mdwn b/hurd/faq/slash_usr_symlink/discussion.mdwn new file mode 100644 index 00000000..219e14e4 --- /dev/null +++ b/hurd/faq/slash_usr_symlink/discussion.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + + +# IRC, freenode, #hurd, 2012-02-01 + + <marcusb> I remember the time when we had a /usr symlink. Now fedora 17 + will move / to /usr and have /foo symlinks. :) + <marcusb> braunr: + http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge + <marcusb> braunr: fedora and others are merging /bin, /sbin and some other + into /usr + <marcusb> braunr: back in 1998 we tried for two years or so to have /usr -> + .. in Debian GNU/Hurd, but eventually we gave up on it, because it broke + some stuff + <gnu_srs> marcusb: Hi, which one is better (in your opinion): / or /usr? + <marcusb> gnu_srs: fedora says that using /usr allows better separation of + distribution files and machine-local files + <braunr> marcusb: won't it break remote /usr ? + <marcusb> so you can atomically mount the OS files to /usr + <marcusb> gnu_srs: but in the end, it's a wash + <marcusb> personally, I think every package should get its own directory + <braunr> marcusb: what PATH then ? + <marcusb> braunr: well, I guess you'd want to assemble a union filesystem + for a POSIX shell + <braunr> marcusb: i don't see what you mean :/ + <braunr> ah this comes from Lennart Poettering + <marcusb> braunr: check out for example how http://nixos.org/ does it + <manuel> braunr: something like, union /package1/bin /package2/bin + /package3/bin for /bin, /package1/lib /package2/lib /package3/lib for + /lib, etc. I guess + <braunr> manuel: would that scale well ? + <marcusb> the idea that there is only one correct binary for each program + with the name foo is noble, but a complete illusion that hides the + complexity of the actual configuration management task + <braunr> marcusb: right diff --git a/hurd/faq/still_useful.mdwn b/hurd/faq/still_useful.mdwn new file mode 100644 index 00000000..bffeaebd --- /dev/null +++ b/hurd/faq/still_useful.mdwn @@ -0,0 +1,46 @@ +[[!meta copyright="Copyright © 2009 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]]."]]"""]] + +what are the advantages with the Hurd over Linux, in general of course, nothing +in depth + +> Flexibility for the user: +> +> transparent ftp +> +> $ cd /ftp://ftp.debian.org/debian +> $ ls +> +> personnal filesystem +> +> $ dd < /dev/zero > myspace.img bs=1M count=1024 +> $ mke2fs myspace.img +> $ settrans myspace /hurd/ext2fs myspace.img +> $ cd myspace + +>> Just curious, but I keep seeing these (and other similar) concepts being +>> brought up as the amazing selling points of the Hurd, but all of this is +>> entirely doable now in Linux with FUSE or things like it. + +>>> Nowadays, at LAST, yes, partly. + +>> I'm not sure if an ftp filesystem has been implemented for FUSE yet, but its +>> definately doable; and loopback filesystems like in your second example have +>> been supported for years. + +>>> As a normal user? And establish a tap interface connected through ppp over +>>> ssh or whatever you could want to imagine? + +>> What, then, are the major selling points or benefits? + +>>> These were just examples, Linux is trying to catch up in ugly ways indeed +>>> (yes, have a look at the details of fuse, it's deemed to be inefficient). +>>> In the Hurd, it's that way from the _ground_ and there is no limitation +>>> like having to be root or ask for root to add magic lines, etc. diff --git a/hurd/gcc.mdwn b/hurd/gcc.mdwn index 53b5e071..129aa8a9 100644 --- a/hurd/gcc.mdwn +++ b/hurd/gcc.mdwn @@ -1,15 +1,11 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[General_information|/gcc]] about the GCC. - -Apart from the target-specific configuration machinery, there shouldn't be any -major differences within GCC between, for example, the GNU/Hurd and GNU/Linux -ports. Especially all the compiler magic is all the same. +[[!meta redir=/gcc]] diff --git a/hurd/glibc.mdwn b/hurd/glibc.mdwn index e975a239..39bfed62 100644 --- a/hurd/glibc.mdwn +++ b/hurd/glibc.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[General_information|/glibc]] about the glibc. diff --git a/hurd/glibc/hurd-specific_api.mdwn b/hurd/glibc/hurd-specific_api.mdwn index aeb63d91..7ead63cd 100644 --- a/hurd/glibc/hurd-specific_api.mdwn +++ b/hurd/glibc/hurd-specific_api.mdwn @@ -1,17 +1,18 @@ -[[!meta copyright="Copyright © 2002, 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Hurd-specific glibc API"]] These functions have meaning only under Hurd. They are needed to get port -names that are used in native Hurd API (the RPC calls to servers). The `.defs` +names that are used in native Hurd API (the [[RPC]]s to servers). The `.defs` and `.h` files can be found in `/include/hurd` when all development files are installed (Debian package `hurd-dev`.) Note that `.defs` are not included in C programs -- they are used to produce `.h` files. @@ -81,7 +82,13 @@ programs -- they are used to produce `.h` files. <dt><tt><b>openport</b> (io_t port, int flags);</tt></dt> <p> </p> - <dd>Open a file descriptor on a port. FLAGS are as for <tt>open</tt>; flags affected by <tt>io_set_openmodes</tt> are not changed by this. If successful, this consumes a user reference for PORT (which will be deallocated on close.) See <tt>&lt;hurd/io.defs&gt;</tt> and <tt>&lt;hurd/io.h&gt;</tt>.</dd> + <dd>Open a [[unix/file_descriptor]] on a [[microkernel/mach/port]]. FLAGS + are as for <tt>open</tt>; flags affected by <tt>io_set_openmodes</tt> are + not changed by this. If successful, this consumes a user reference for + PORT (which will be deallocated on close.) See + <tt>&lt;hurd/io.defs&gt;</tt> and + <tt>&lt;hurd/io.h&gt;</tt>. + </dd> <p> </p> <dt><tt>task_t</tt></dt> @@ -157,7 +164,7 @@ programs -- they are used to produce `.h` files. </p> <dt><tt>thread_t</tt></dt> <dt><tt><b>hurd_thread_self</b> (void);</tt></dt> - <dd>Return the current thread's thread port. This is a cheap operation (no system call), but it relies on Hurd signal state being set up.</dd> + <dd>Return the current thread's thread port. This is a cheap operation (no [[system call]]), but it relies on Hurd signal state being set up.</dd> <p> </p> <dt><tt>error_t</tt></dt> diff --git a/hurd/interface.mdwn b/hurd/interface.mdwn new file mode 100644 index 00000000..53cd31f0 --- /dev/null +++ b/hurd/interface.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Interfaces"]] + +/!\ Incomplete. + +[[!map pages="hurd/interface/* and !hurd/interface/*_*" +show=title]] diff --git a/tag/open_issue_mach.mdwn b/hurd/interface/dir_link.mdwn index 3b31bea8..0f1db578 100644 --- a/tag/open_issue_mach.mdwn +++ b/hurd/interface/dir_link.mdwn @@ -8,6 +8,4 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title=open_issue_mach]] - -[[!meta redir=open_issue_gnumach]] +[[!meta redir=fs/23]] diff --git a/hurd/interface/dir_lookup.mdwn b/hurd/interface/dir_lookup.mdwn new file mode 100644 index 00000000..40e79538 --- /dev/null +++ b/hurd/interface/dir_lookup.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/18]] diff --git a/hurd/interface/dir_mkdir.mdwn b/hurd/interface/dir_mkdir.mdwn new file mode 100644 index 00000000..bf386818 --- /dev/null +++ b/hurd/interface/dir_mkdir.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/20]] diff --git a/hurd/interface/dir_mkfile.mdwn b/hurd/interface/dir_mkfile.mdwn new file mode 100644 index 00000000..01828a03 --- /dev/null +++ b/hurd/interface/dir_mkfile.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/25]] diff --git a/hurd/interface/dir_notice_changes.mdwn b/hurd/interface/dir_notice_changes.mdwn new file mode 100644 index 00000000..5763a0a3 --- /dev/null +++ b/hurd/interface/dir_notice_changes.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/26]] diff --git a/hurd/interface/dir_readdir.mdwn b/hurd/interface/dir_readdir.mdwn new file mode 100644 index 00000000..b41e8d49 --- /dev/null +++ b/hurd/interface/dir_readdir.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/19]] diff --git a/hurd/interface/dir_rename.mdwn b/hurd/interface/dir_rename.mdwn new file mode 100644 index 00000000..3839487f --- /dev/null +++ b/hurd/interface/dir_rename.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/24]] diff --git a/hurd/interface/dir_rmdir.mdwn b/hurd/interface/dir_rmdir.mdwn new file mode 100644 index 00000000..d69fdd30 --- /dev/null +++ b/hurd/interface/dir_rmdir.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/21]] diff --git a/hurd/interface/dir_unlink.mdwn b/hurd/interface/dir_unlink.mdwn new file mode 100644 index 00000000..a8861bac --- /dev/null +++ b/hurd/interface/dir_unlink.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/22]] diff --git a/hurd/interface/file_chauthor.mdwn b/hurd/interface/file_chauthor.mdwn new file mode 100644 index 00000000..6fcf97f1 --- /dev/null +++ b/hurd/interface/file_chauthor.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/02]] diff --git a/hurd/interface/file_check_access.mdwn b/hurd/interface/file_check_access.mdwn new file mode 100644 index 00000000..5ab4af57 --- /dev/null +++ b/hurd/interface/file_check_access.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/09]] diff --git a/hurd/interface/file_chflags.mdwn b/hurd/interface/file_chflags.mdwn new file mode 100644 index 00000000..6e55536b --- /dev/null +++ b/hurd/interface/file_chflags.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/04]] diff --git a/hurd/interface/file_chmod.mdwn b/hurd/interface/file_chmod.mdwn new file mode 100644 index 00000000..0bbb8d92 --- /dev/null +++ b/hurd/interface/file_chmod.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/03]] diff --git a/hurd/interface/file_chown.mdwn b/hurd/interface/file_chown.mdwn new file mode 100644 index 00000000..a99bcf85 --- /dev/null +++ b/hurd/interface/file_chown.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/01]] diff --git a/hurd/interface/file_exec.mdwn b/hurd/interface/file_exec.mdwn new file mode 100644 index 00000000..5f4b57f9 --- /dev/null +++ b/hurd/interface/file_exec.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/00]] diff --git a/hurd/interface/file_get_fs_options.mdwn b/hurd/interface/file_get_fs_options.mdwn new file mode 100644 index 00000000..b04c70a3 --- /dev/null +++ b/hurd/interface/file_get_fs_options.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/30]] diff --git a/hurd/interface/file_get_storage_info.mdwn b/hurd/interface/file_get_storage_info.mdwn new file mode 100644 index 00000000..87166c90 --- /dev/null +++ b/hurd/interface/file_get_storage_info.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/15]] diff --git a/hurd/interface/file_get_translator.mdwn b/hurd/interface/file_get_translator.mdwn new file mode 100644 index 00000000..6c8565f4 --- /dev/null +++ b/hurd/interface/file_get_translator.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/28]] diff --git a/hurd/interface/file_get_translator_cntl.mdwn b/hurd/interface/file_get_translator_cntl.mdwn new file mode 100644 index 00000000..befbf1a3 --- /dev/null +++ b/hurd/interface/file_get_translator_cntl.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/29]] diff --git a/hurd/interface/file_getcontrol.mdwn b/hurd/interface/file_getcontrol.mdwn new file mode 100644 index 00000000..94503b23 --- /dev/null +++ b/hurd/interface/file_getcontrol.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/11]] diff --git a/hurd/interface/file_getfh.mdwn b/hurd/interface/file_getfh.mdwn new file mode 100644 index 00000000..369afb17 --- /dev/null +++ b/hurd/interface/file_getfh.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/17]] diff --git a/hurd/interface/file_getlinknode.mdwn b/hurd/interface/file_getlinknode.mdwn new file mode 100644 index 00000000..64efb810 --- /dev/null +++ b/hurd/interface/file_getlinknode.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/16]] diff --git a/hurd/interface/file_lock.mdwn b/hurd/interface/file_lock.mdwn new file mode 100644 index 00000000..8860d24b --- /dev/null +++ b/hurd/interface/file_lock.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/07]] diff --git a/hurd/interface/file_lock_stat.mdwn b/hurd/interface/file_lock_stat.mdwn new file mode 100644 index 00000000..78abebb5 --- /dev/null +++ b/hurd/interface/file_lock_stat.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/08]] diff --git a/hurd/interface/file_notice_changes.mdwn b/hurd/interface/file_notice_changes.mdwn new file mode 100644 index 00000000..f6646410 --- /dev/null +++ b/hurd/interface/file_notice_changes.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/10]] diff --git a/hurd/interface/file_reparent.mdwn b/hurd/interface/file_reparent.mdwn new file mode 100644 index 00000000..80cd174e --- /dev/null +++ b/hurd/interface/file_reparent.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/31]] diff --git a/hurd/interface/file_set_size.mdwn b/hurd/interface/file_set_size.mdwn new file mode 100644 index 00000000..cf1e376c --- /dev/null +++ b/hurd/interface/file_set_size.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/06]] diff --git a/hurd/interface/file_set_translator.mdwn b/hurd/interface/file_set_translator.mdwn new file mode 100644 index 00000000..4a43bdad --- /dev/null +++ b/hurd/interface/file_set_translator.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/27]] diff --git a/hurd/interface/file_statfs.mdwn b/hurd/interface/file_statfs.mdwn new file mode 100644 index 00000000..f5086d34 --- /dev/null +++ b/hurd/interface/file_statfs.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/12]] diff --git a/hurd/interface/file_sync.mdwn b/hurd/interface/file_sync.mdwn new file mode 100644 index 00000000..160c86ca --- /dev/null +++ b/hurd/interface/file_sync.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/13]] diff --git a/hurd/interface/file_syncfs.mdwn b/hurd/interface/file_syncfs.mdwn new file mode 100644 index 00000000..a52e92b0 --- /dev/null +++ b/hurd/interface/file_syncfs.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/14]] diff --git a/hurd/interface/file_utimes.mdwn b/hurd/interface/file_utimes.mdwn new file mode 100644 index 00000000..ab09a58b --- /dev/null +++ b/hurd/interface/file_utimes.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fs/05]] diff --git a/hurd/interface/fs.mdwn b/hurd/interface/fs.mdwn new file mode 100644 index 00000000..4f217c5a --- /dev/null +++ b/hurd/interface/fs.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="fs: Filesystem"]] + +All these objects also implement the generic IO facilities. + +To get or set the translator currently running on a file, use +[[`file_set_translator`|file_set_translator]], +[[`file_get_translator`|file_get_translator]], or +[[`file_get_translator_cntl`|file_get_translator_cntl]] on a port gotten with +the `FS_LOOKUP_NOTRANS` flag to [[`dir_lookup`|dir_lookup]]. You can send +these [[RPC]]s to a port to a translated node (looked up without +`FS_LOOKUP_NOTRANS`) to stack a new translator on top of the existing one. + +[[!map pages="hurd/interface/fs/* and !hurd/interface/fs/*/*" +show=title]] diff --git a/hurd/interface/fs/00.mdwn b/hurd/interface/fs/00.mdwn new file mode 100644 index 00000000..29b93731 --- /dev/null +++ b/hurd/interface/fs/00.mdwn @@ -0,0 +1,30 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_exec"]] + + routine file_exec ( + exec_file: file_t; + RPT + exec_task: task_t; + flags: int; + argv: data_t SCP; + envp: data_t SCP; + fdarray: portarray_t SCP; + portarray: portarray_t SCP; + intarray: intarray_t SCP; + deallocnames: mach_port_name_array_t SCP; + destroynames: mach_port_name_array_t SCP); + +Overlay a task with a file. Necessary initialization, including authentication +changes associated with set[ug]id execution must be handled by the filesystem. +Filesystems normally implement this by using [[`exec_newtask`|exec_newtask]] or +[[`exec_loadtask`|exec_loadtask]] as appropriate. diff --git a/hurd/interface/fs/01.mdwn b/hurd/interface/fs/01.mdwn new file mode 100644 index 00000000..7b9c7a31 --- /dev/null +++ b/hurd/interface/fs/01.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_chown"]] + + routine file_chown ( + chown_file: file_t; + RPT + new_owner: uid_t; + new_group: gid_t); + +Change owner and/or group. diff --git a/hurd/interface/fs/02.mdwn b/hurd/interface/fs/02.mdwn new file mode 100644 index 00000000..3158d2c6 --- /dev/null +++ b/hurd/interface/fs/02.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_chauthor"]] + + routine file_chauthor ( + chauth_file: file_t; + RPT + new_author: uid_t); + + Whan that Aprill with hith thoureth thoote + The droghte of March hath perthed to the roote, + And bathed every veyne in thwith licour, + Of which vertu engendred is the flour; + Whan Zephiruth eek with hith thweete breeth + Inthpired hath in every holt and heeth + The tender croppeth, and the yonge thonne + Hath in the Ram his halve courth yronne, + And thmale foweleth maken melodye, + That thlepen all the nyght with open ye + (Tho Priketh hem Nature in hir corageth), + Thanne longen folk to goon on pligrimageth, + And palmereth for to theken thtraunge thtrondeth, + To ferne halweth, kowthe in thondry londeth: + And thpethially, from every thireth ende + Of Engelond to Cantebury they wende, + The hooly blithful martyr for to theke, + That hem hath holpen whan that they were theeke. diff --git a/hurd/interface/fs/03.mdwn b/hurd/interface/fs/03.mdwn new file mode 100644 index 00000000..d697ec90 --- /dev/null +++ b/hurd/interface/fs/03.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_chmod"]] + + routine file_chmod ( + chmod_file: file_t; + RPT + new_mode: mode_t); + +Change mode bits. diff --git a/hurd/interface/fs/04.mdwn b/hurd/interface/fs/04.mdwn new file mode 100644 index 00000000..d0386eab --- /dev/null +++ b/hurd/interface/fs/04.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_chflags"]] + + routine file_chflags ( + chflags_file: file_t; + RPT + new_flags: int); + +Change file flags. diff --git a/hurd/interface/fs/05.mdwn b/hurd/interface/fs/05.mdwn new file mode 100644 index 00000000..184e2ffd --- /dev/null +++ b/hurd/interface/fs/05.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_utimes"]] + + routine file_utimes ( + utimes_file: file_t; + RPT + new_atime: time_value_t; + new_mtime: time_value_t); + +Change access and modify times. + +If the microseconds value is -1 (all bits on) then the time should be set to +the current time and the remainder of the `time_value_t` ignored. diff --git a/hurd/interface/fs/06.mdwn b/hurd/interface/fs/06.mdwn new file mode 100644 index 00000000..393f1a9b --- /dev/null +++ b/hurd/interface/fs/06.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_set_size"]] + + routine file_set_size ( + trunc_file: file_t; + RPT + new_size: loff_t); + +Change the size of the file. If the size increases, new blocks are +zero-filled. After successful return, it is safe to reference mapped areas of +the file up to `new_size`. diff --git a/hurd/interface/fs/07.mdwn b/hurd/interface/fs/07.mdwn new file mode 100644 index 00000000..d6408763 --- /dev/null +++ b/hurd/interface/fs/07.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_lock"]] + + routine file_lock ( + lock_file: file_t; + RPT + flags: int); + +Apply/manipulate advisory lock. diff --git a/hurd/interface/fs/08.mdwn b/hurd/interface/fs/08.mdwn new file mode 100644 index 00000000..fbb3d53b --- /dev/null +++ b/hurd/interface/fs/08.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_lock_stat"]] + + routine file_lock_stat ( + lock_file: file_t; + RPT + out mystatus: int; + out otherstatus: int); + +Return current lock status. `mystatus` tells what kind of lock the caller has; +`otherstatus` tells what kind of lock anyone has (including the caller). diff --git a/hurd/interface/fs/09.mdwn b/hurd/interface/fs/09.mdwn new file mode 100644 index 00000000..02c778c2 --- /dev/null +++ b/hurd/interface/fs/09.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_check_access"]] + + routine file_check_access ( + file: file_t; + RPT + out allowed: int); + +Find out what kind of access this file permits the current user (regardless of +the current open modes for this port). `allowed` is a bitwise *or* of +`O_READ`, `O_WRITE`, and `O_EXEC`. This is not necessarily the same as what an +`open` or `exec` would allow; `O_EXEC` is set for *root* even if no executable +bits are on (in which case [[`file_exec`|file_exec]] should fail) and `O_WRITE` +is set a directory can be modified, even though it can't be written directly. diff --git a/hurd/interface/fs/10.mdwn b/hurd/interface/fs/10.mdwn new file mode 100644 index 00000000..56ce204f --- /dev/null +++ b/hurd/interface/fs/10.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_notice_changes"]] + + routine file_notice_changes ( + file: file_t; + RPT + port: mach_port_send_t); + +Notice changes to file `file`. Send notification messages (see +[[`fs_notify.defs`|fs_notify]]) to `port` as they occur. diff --git a/hurd/interface/fs/11.mdwn b/hurd/interface/fs/11.mdwn new file mode 100644 index 00000000..94aa4ee0 --- /dev/null +++ b/hurd/interface/fs/11.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_getcontrol"]] + + routine file_getcontrol ( + file: file_t; + RPT + out control: mach_port_send_t); + +Return control port for this filesystem. diff --git a/hurd/interface/fs/12.mdwn b/hurd/interface/fs/12.mdwn new file mode 100644 index 00000000..b69b591b --- /dev/null +++ b/hurd/interface/fs/12.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_statfs"]] + + routine file_statfs ( + file: file_t; + RPT + out info: fsys_statfsbuf_t); + +Return filesystem status. diff --git a/hurd/interface/fs/13.mdwn b/hurd/interface/fs/13.mdwn new file mode 100644 index 00000000..2e06e0c4 --- /dev/null +++ b/hurd/interface/fs/13.mdwn @@ -0,0 +1,60 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_sync"]] + + routine file_sync ( + file: file_t; + RPT + wait: int; + omit_metadata: int); + +Sync the individual file. If `omit_metadata` is set, then it is only necessary +for the server to updated the actual contents of the file, not any associated +metadata. + +# Implementation Examples + +Servers that either don't keep any unsynchronized state (or don't have a +backing store at all) can simply `return 0`. Examples: [[translator/nfs]]. + +## [[libtrivfs]] + +Pass the call through to the underlying node. + +### [[storeio]] / [[streamio]] + +Instead of to the underlying node, pass the call through to the backend +(device). + +## [[libnetfs]] + +Invoke `netfs_attempt_sync`. + +## [[libdiskfs]] + +Invoke `diskfs_file_update`. + +# Usage Examples + +## [[glibc]] + + * `fdatasync` + + `file_syncfs (FD, true, true)` -- invoke it on the passed file descriptor, + do wait for completion, do allow omitting to update the associated + metadata. + + * `fsync` + + `file_syncfs (FD, true, false)` -- invoke it on the passed file descriptor, + do wait for completion, don't allow omitting to update the associated + metadata. diff --git a/hurd/interface/fs/14.mdwn b/hurd/interface/fs/14.mdwn new file mode 100644 index 00000000..a13c0bd8 --- /dev/null +++ b/hurd/interface/fs/14.mdwn @@ -0,0 +1,67 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_syncfs"]] + + routine file_syncfs ( + file: file_t; + RPT + wait: int; + do_children: int); + +Synchronize the entire filesystem. + +This function has a companion in [[`fsys_syncfs`|fsys_syncfs]], which is +invoked on the server's control port instead of an arbitrary node. Both of +them are usually implemented in equivalent ways. + +# Implementation Examples + +Servers that either don't keep any unsynchronized state (or don't have a +backing store at all) can simply `return 0`. Examples: [[translator/nfs]]. + +The implementation typically doesn't care on which specific node (as exported +by the implementing server) [[`file_syncfs`|file_syncfs]] is being invoked on. + +## [[libtrivfs]] + +Invoke [[`file_sync`|file_sync]] on the underlying node. Rationale: the +underlying node represents this filesystem's backend, and once this node is +synchronized, the whole [[libtrivfs]]-based filesystem is to be considered +synchronized. + +### [[storeio]] / [[streamio]] + +Instead of the to underlying node, pass the call through to the backend +(device). + +## [[libnetfs]] + +Invoke `netfs_attempt_syncfs`. + +## [[libdiskfs]] + +Invoke [[`fsys_syncfs`|fsys_syncfs]] on all active children, and invoke +`diskfs_sync_everything` and `diskfs_set_hypermetadata`. + +# Usage Examples + +## [[glibc]] + + * `sync` + + `file_syncfs ("/", false, true)` -- invoke it on the process' root directory + (`INIT_PORT_CRDIR`), don't wait for completion, do synchronize child + filesystems. + +## [[Hurd]] + + * [[`syncfs`|syncfs]] diff --git a/hurd/interface/fs/15.mdwn b/hurd/interface/fs/15.mdwn new file mode 100644 index 00000000..50dcce1b --- /dev/null +++ b/hurd/interface/fs/15.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_get_storage_info"]] + + routine file_get_storage_info ( + file: file_t; + RPT + out ports: portarray_t, dealloc; + out ints: intarray_t, dealloc; + out offsets: off_array_t, dealloc; + out data: data_t, dealloc); + +Return information on the storage used to hold this file. See the comment for +`enum file_storage_class` in `<hurd/hurd_types.h>` the details. diff --git a/hurd/interface/fs/16.mdwn b/hurd/interface/fs/16.mdwn new file mode 100644 index 00000000..8ba776c1 --- /dev/null +++ b/hurd/interface/fs/16.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_getlinknode"]] + + routine file_getlinknode ( + file: file_t; + RPT + out linknode: mach_port_send_t); + +Return the node for hard links to this potentially translated file. This +returns a potentially unauthenticated node. diff --git a/hurd/interface/fs/17.mdwn b/hurd/interface/fs/17.mdwn new file mode 100644 index 00000000..8895434a --- /dev/null +++ b/hurd/interface/fs/17.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_getfh"]] + + routine file_getfh ( + file: file_t; + RPT + out filehandle: data_t, dealloc); + +Return a file handle for this file. This can be used by NFS and such. It is +not guaranteed that this call will work; if it doesn't, then this filesystem +cannot be NFS mounted. + +Currently file handles are only used by `nfsd` with the purpose of +having some stable representation of nodes (TODO: Add references). +The only translator library that implements `file_getfh` and the +complementary [[`fsys_getfile`|fsys_getfile]] is `libdiskfs`, so if +you are linking against a different library you should expect that the +filesystem exported by your translator will not be supported by `nfsd` +by default. + +If you would like your non-`libdiskfs` translator to be supported by +`nfsd`, you should implement these two RPCs on your own. The idea is +that to each node exported by your translator you should put in +correspondence a unique file handle. A file handle is a 28-byte +value. The first 4 bytes are not used. Then comes a 4-byte number +which should identify your node somehow (`libdiskfs` uses the index +into the internally maintained node cache). After it there comes a +4-byte number which should bear a similar function to the `st_gen` +field of a `stat` structure. Following this specification, you should +be able to implement `file_getfh` and `fsys_getfile` in a proper way +to get `nfsd` support. diff --git a/hurd/interface/fs/18.mdwn b/hurd/interface/fs/18.mdwn new file mode 100644 index 00000000..dbe606f3 --- /dev/null +++ b/hurd/interface/fs/18.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="dir_lookup"]] + + routine dir_lookup ( + start_dir: file_t; + RPT + file_name: string_t; + flags: int; + mode: mode_t; + out do_retry: retry_type; + out retry_name: string_t; + out result: mach_port_send_t); + +Translate a file name, following all symlinks. Upon return, if `do_retry` is +`FS_RETRY_MAGICAL` then `retry_name` specifies what to do, the list of +possibilities is documented in `<hurd/hurd_types.h>`; if `FS_RETRY_REAUTH`, +then `result` should be reauthenticated before being used. If `retry_name` is +the empty string and the retry type is `FS_RETRY_NORMAL`, then no further +[[`dir_lookup`|dir_lookup]] calls are required; `result` is the port to use. +Otherwise the [[`dir_lookup`|dir_lookup]] call should be repeated, sent to +`result` (or the reauthenticated port) with `retry_name` passed for +`file_name`. This call is required to be supported by all files (even +non-directories) if the filename is null, and should function in that case as a +re-open of the file. diff --git a/hurd/interface/fs/19.mdwn b/hurd/interface/fs/19.mdwn new file mode 100644 index 00000000..86625d44 --- /dev/null +++ b/hurd/interface/fs/19.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="dir_readdir"]] + + routine dir_readdir ( + dir: file_t; + RPT + out data: data_t, dealloc[]; + entry: int; + nentries: int; + bufsiz: vm_size_t; + out amount: int); + +Read entries from the directory. Each entry is identified by an index number +starting at 0 and running through the file. This call fetches `nentries` (or +any convenient number if `nentries` is -1) entries starting at `entry`, +returning an array of struct directs in `data`. The number of entries +successfully read is returned in `amount`. If `entry` is bigger than the index +of the last entry, then 0 is returned in `amount`. If `bufsize` is nonzero, +never return more than `bufsize` bytes of data regardless. diff --git a/hurd/interface/fs/20.mdwn b/hurd/interface/fs/20.mdwn new file mode 100644 index 00000000..da57f0b5 --- /dev/null +++ b/hurd/interface/fs/20.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="dir_mkdir"]] + + routine dir_mkdir ( + directory: file_t; + RPT + name: string_t; + mode: mode_t); + +Create directory. diff --git a/hurd/interface/fs/21.mdwn b/hurd/interface/fs/21.mdwn new file mode 100644 index 00000000..c562333a --- /dev/null +++ b/hurd/interface/fs/21.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="dir_rmdir"]] + + routine dir_rmdir ( + directory: file_t; + RPT + name: string_t); + +Remove directory. diff --git a/hurd/interface/fs/22.mdwn b/hurd/interface/fs/22.mdwn new file mode 100644 index 00000000..24fcdd9e --- /dev/null +++ b/hurd/interface/fs/22.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="dir_unlink"]] + + routine dir_unlink ( + directory: file_t; + RPT + name: string_t); + +Remove non-directory. diff --git a/hurd/interface/fs/23.mdwn b/hurd/interface/fs/23.mdwn new file mode 100644 index 00000000..44621d37 --- /dev/null +++ b/hurd/interface/fs/23.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="dir_link"]] + + routine dir_link ( + dir: file_t; + RPT + file: file_t; + name: string_t; + excl: int); + +Create a hard link. + +If `dir` and `file` are not implemented by the same filesystem, `EXDEV` should +be returned. If the two filesystems, however can inter-operate and guarantee +the appropriate POSIX semantics, they can communicate by a private protocol and +allow hard links between them. If `excl` is set, then fail if `name` already +exists in `dir`. diff --git a/hurd/interface/fs/24.mdwn b/hurd/interface/fs/24.mdwn new file mode 100644 index 00000000..aac2df60 --- /dev/null +++ b/hurd/interface/fs/24.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="dir_rename"]] + + routine dir_rename ( + olddirectory: file_t; + RPT + oldname: string_t; + newdirectory: file_t; + newname: string_t; + excl: int); + +Rename file -- comments similar to those for [[`dir_link`|dir_link]] apply here +about `EXDEV`. If `excl` is set, then fail if `newname` already exists in +`newdirectory`. diff --git a/hurd/interface/fs/25.mdwn b/hurd/interface/fs/25.mdwn new file mode 100644 index 00000000..9b08d54f --- /dev/null +++ b/hurd/interface/fs/25.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="dir_mkfile"]] + + routine dir_mkfile ( + directory: file_t; + RPT + flags: int; + mode: mode_t; + out newnode: mach_port_send_t); + +Create a new file without linking it into the filesystem. You still must have +write permission on the specified directory, even though it will not actually +be written. Return in `newnode` a port to the file. `flags` are the same as +for [[`dir_lookup`|dir_lookup]], but `O_CREAT` and `O_TRUNC` are assumed even +if not specified. diff --git a/hurd/interface/fs/26.mdwn b/hurd/interface/fs/26.mdwn new file mode 100644 index 00000000..82a7bca1 --- /dev/null +++ b/hurd/interface/fs/26.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="dir_notice_changes"]] + + routine dir_notice_changes ( + directory: file_t; + RPT + port: mach_port_send_t); + +Notice changes to directory `dir`. Send directory change notifications (see +[[`fs_notify.defs`|fs_notify]]) to `port` as they occur. diff --git a/hurd/interface/fs/27.mdwn b/hurd/interface/fs/27.mdwn new file mode 100644 index 00000000..9a7bd13f --- /dev/null +++ b/hurd/interface/fs/27.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_set_translator"]] + + routine file_set_translator ( + file: file_t; + RPT + passive_flags: int; + active_flags: int; + oldtrans_flags: int; + passive: data_t SCP; + active: mach_port_send_t); + +Set a translator for future lookups to a file. + +`passive` is the passive translator; `active` is the active translator. + +The `flags` are `FS_TRANS_*`, defined in `<hurd/hurd_types.h>`. `oldflags` are +sent in an [[`fsys_goaway`|fsys_goaway]] to an existing active translator if +there is one and it is to be killed. diff --git a/hurd/interface/fs/28.mdwn b/hurd/interface/fs/28.mdwn new file mode 100644 index 00000000..13ac4b7a --- /dev/null +++ b/hurd/interface/fs/28.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_get_translator"]] + + routine file_get_translator ( + file: file_t; + RPT + out translator: data_t, dealloc); + +Return the stored permanent translator for this file. diff --git a/hurd/interface/fs/29.mdwn b/hurd/interface/fs/29.mdwn new file mode 100644 index 00000000..1cc3950a --- /dev/null +++ b/hurd/interface/fs/29.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_get_translator_cntl"]] + + routine file_get_translator_cntl ( + file: file_t; + RPT + out translator_cntl: mach_port_send_t); + +Return the translator control port to the active translator (if any) for this +file. diff --git a/hurd/interface/fs/30.mdwn b/hurd/interface/fs/30.mdwn new file mode 100644 index 00000000..653af42f --- /dev/null +++ b/hurd/interface/fs/30.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_get_fs_options"]] + + routine file_get_fs_options ( + file: file_t; + RPT + out options: data_t, dealloc); + +Return the options describing the way the receiving filesystem is running. +(Suitable as an arg for [[`fsys_set_options`|fsys_set_options]]). diff --git a/hurd/interface/fs/31.mdwn b/hurd/interface/fs/31.mdwn new file mode 100644 index 00000000..32e7efda --- /dev/null +++ b/hurd/interface/fs/31.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 1994, 1995, 1996, 1997, 1998, 1999, 2002, 2009 +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="file_reparent"]] + + routine file_reparent ( + file: file_t; + RPT + parent: mach_port_t; + out new_file: mach_port_send_t); + +Return a new file, `new_file`, with the same semantics as `file`, but with +lookups of `..` (if `file` is a directory) redirected to `parent`. diff --git a/hurd/interface/fsys.mdwn b/hurd/interface/fsys.mdwn new file mode 100644 index 00000000..cea10d30 --- /dev/null +++ b/hurd/interface/fsys.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 1992, 1993, 1994, 1995, 1996, 1997, 2002, 2009 +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="fsys: Filesystem Control"]] + +[[!map pages="hurd/interface/fsys/* and !hurd/interface/fsys/*/*" +show=title]] diff --git a/hurd/interface/fsys/00.mdwn b/hurd/interface/fsys/00.mdwn new file mode 100644 index 00000000..68e0479e --- /dev/null +++ b/hurd/interface/fsys/00.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 1992, 1993, 1994, 1995, 1996, 1997, 2002, 2009 +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="fsys_startup"]] + + routine fsys_startup ( + bootstrap: mach_port_t; + RPT + openflags: int; + control_port: mach_port_send_t; + out realnode: mach_port_send_t); + +Sent by filesystem on its bootstrap port upon startup. `realnode` is the node +this filesystem is the translator for, opened with flags `flags` (`O_NOTRANS` +is assumed even if not provided). diff --git a/hurd/interface/fsys/01.mdwn b/hurd/interface/fsys/01.mdwn new file mode 100644 index 00000000..9cb95de5 --- /dev/null +++ b/hurd/interface/fsys/01.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 1992, 1993, 1994, 1995, 1996, 1997, 2002, 2009 +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="fsys_goaway"]] + + routine fsys_goaway ( + fsys: fsys_t; + RPT + flags: int); + +Filesystem should go away. Bye. diff --git a/hurd/interface/fsys/02.mdwn b/hurd/interface/fsys/02.mdwn new file mode 100644 index 00000000..63b84c48 --- /dev/null +++ b/hurd/interface/fsys/02.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 1992, 1993, 1994, 1995, 1996, 1997, 2002, 2009 +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="fsys_getroot"]] + + routine fsys_getroot( + fsys: fsys_t; + RPT + #ifdef FSYS_GETROOT_UREPLY + ureplyport ureply: mig_reply_port_t; + #endif + dotdot_node: mach_port_send_t; + gen_uids: idarray_t; + gen_gids: idarray_t; + flags: int; + out do_retry: retry_type; + out retry_name: string_t; + out file: mach_port_send_t); + +Return a file to the root of the filesystem. `flags` are as for +[[`dir_lookup`|dir_lookup]] (but `O_CREAT` and `O_EXCL` are not meaningful). +`do_retry`, `retry_name`, and `result` are as for [[`dir_lookup`|dir_lookup]]. +The port should be authenticated with `gen_uids` and `gen_gids` (except, of +course, for `FS_RETRY_REAUTH` and `FS_RETRY_MAGICAL). `dotdot_node` is an +unauthenticated port for the directory in which this root is located. diff --git a/hurd/interface/fsys/03.mdwn b/hurd/interface/fsys/03.mdwn new file mode 100644 index 00000000..b0c033c2 --- /dev/null +++ b/hurd/interface/fsys/03.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 1992, 1993, 1994, 1995, 1996, 1997, 2002, 2009 +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="fsys_getfile"]] + + routine fsys_getfile ( + fsys: fsys_t; + RPT + gen_uids: idarray_t; + gen_gids: idarray_t; + filehandle: data_t; + out file: mach_port_send_t); + +Get a file given a file handle (see [[`file_getfh`|file_getfh]]). diff --git a/hurd/interface/fsys/04.mdwn b/hurd/interface/fsys/04.mdwn new file mode 100644 index 00000000..7b370d2b --- /dev/null +++ b/hurd/interface/fsys/04.mdwn @@ -0,0 +1,58 @@ +[[!meta copyright="Copyright © 2009 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="fsys_syncfs"]] + + routine fsys_syncfs ( + fsys: fsys_t; + RPT + wait: int; + do_children: int); + +Synchronize the entire filesystem. + +This function has a companion in [[`file_syncfs`|file_syncfs]], which is +invoked on an arbitrary node instead of the server's control port. Both of +them are usually implemented in equivalent ways. + +# Implementation Examples + +Servers that either don't keep any unsynchronized state (or don't have a +backing store at all) can simply `return 0`. Examples: [[translator/symlink]], +[[translator/nfs]]. + +## [[libtrivfs]] + +Invoke [[`file_sync`|file_sync]] on the underlying node. Rationale: the +underlying node represents this filesystem's backend, and once this node is +synchronized, the whole [[libtrivfs]]-based filesystem is to be considered +synchronized. + +### [[storeio]] / [[streamio]] + +Instead of to the underlying node, pass the call through to the backend +(device). + +## [[libnetfs]] + +Invoke `netfs_attempt_syncfs`. + +## [[libdiskfs]] + +Invoke [[`fsys_syncfs`|fsys_syncfs]] on all active children, and invoke +`diskfs_sync_everything` and `diskfs_set_hypermetadata`. + +# Usage Examples + +## [[libdiskfs]] + +In the implementations of both [[`file_syncfs`|file_syncfs]] and +[[`fsys_syncfs`|fsys_syncfs]], [[`fsys_syncfs`|fsys_syncfs]] is invoked on all +active children. diff --git a/hurd/interface/fsys/05.mdwn b/hurd/interface/fsys/05.mdwn new file mode 100644 index 00000000..5caf6b17 --- /dev/null +++ b/hurd/interface/fsys/05.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2009 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="fsys_set_options"]] + + routine fsys_set_options ( + fsys: fsys_t; + RPT + options: data_t; + do_children: int); + +Pass a server-specific options string. This usually includes flags similar to +command line options, e.g., `--readonly`, or `--sync=30`. diff --git a/hurd/interface/fsys/06.mdwn b/hurd/interface/fsys/06.mdwn new file mode 100644 index 00000000..c8ccbed8 --- /dev/null +++ b/hurd/interface/fsys/06.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2009 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="fsys_getpriv"]] + + routine fsys_getpriv ( + fsys: fsys_t; + RPT + out host_priv: mach_port_send_t; + out device_master: mach_port_send_t; + out fstask: mach_port_send_t); + +This is only implemented by bootstrap filesystems. diff --git a/hurd/interface/fsys/07.mdwn b/hurd/interface/fsys/07.mdwn new file mode 100644 index 00000000..4700416d --- /dev/null +++ b/hurd/interface/fsys/07.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2009 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="fsys_init"]] + + routine fsys_init ( + fsys: fsys_t; + sreplyport reply_port: sreply_port_t; + proc_server: mach_port_send_t; + auth_handle: auth_t); + +This is only implemented by bootstrap filesystems. diff --git a/hurd/interface/fsys/08.mdwn b/hurd/interface/fsys/08.mdwn new file mode 100644 index 00000000..42ac277d --- /dev/null +++ b/hurd/interface/fsys/08.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2009 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="fsys_forward"]] + + routine fsys_forward ( + server: mach_port_t; + RPT + requestor: mach_port_send_t; + argv: data_t); + +Ask `server` to provide [[`fsys`|fsys]] translation service for us. +`requestor` is the bootstrap port supplied to the original translator, and +`argv` are the command line arguments. If the recipient accepts the request, +he (or some delegate) should send [[`fsys_startup`|fsys_startup]] to +`requestor` to start the filesystem up. diff --git a/hurd/interface/fsys/09.mdwn b/hurd/interface/fsys/09.mdwn new file mode 100644 index 00000000..fa5c4117 --- /dev/null +++ b/hurd/interface/fsys/09.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2009 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="fsys_get_options"]] + + routine fsys_get_options ( + server: fsys_t; + RPT + out options: data_t, dealloc); + +Return the options describing the operation of the receiving filesystem +(sutiable for [[`fsys_set_options`|fsys_set_options]]). diff --git a/hurd/interface/fsys_forward.mdwn b/hurd/interface/fsys_forward.mdwn new file mode 100644 index 00000000..1ab16003 --- /dev/null +++ b/hurd/interface/fsys_forward.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fsys/08]] diff --git a/hurd/interface/fsys_get_options.mdwn b/hurd/interface/fsys_get_options.mdwn new file mode 100644 index 00000000..5a48d24d --- /dev/null +++ b/hurd/interface/fsys_get_options.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fsys/09]] diff --git a/hurd/interface/fsys_getfile.mdwn b/hurd/interface/fsys_getfile.mdwn new file mode 100644 index 00000000..d292f265 --- /dev/null +++ b/hurd/interface/fsys_getfile.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fsys/03]] diff --git a/hurd/interface/fsys_getpriv.mdwn b/hurd/interface/fsys_getpriv.mdwn new file mode 100644 index 00000000..6c4332ba --- /dev/null +++ b/hurd/interface/fsys_getpriv.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fsys/06]] diff --git a/hurd/interface/fsys_getroot.mdwn b/hurd/interface/fsys_getroot.mdwn new file mode 100644 index 00000000..ff03c482 --- /dev/null +++ b/hurd/interface/fsys_getroot.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fsys/02]] diff --git a/hurd/interface/fsys_goaway.mdwn b/hurd/interface/fsys_goaway.mdwn new file mode 100644 index 00000000..bf431a08 --- /dev/null +++ b/hurd/interface/fsys_goaway.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fsys/01]] diff --git a/hurd/interface/fsys_init.mdwn b/hurd/interface/fsys_init.mdwn new file mode 100644 index 00000000..2be8dfb9 --- /dev/null +++ b/hurd/interface/fsys_init.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fsys/07]] diff --git a/hurd/interface/fsys_set_options.mdwn b/hurd/interface/fsys_set_options.mdwn new file mode 100644 index 00000000..7f977c20 --- /dev/null +++ b/hurd/interface/fsys_set_options.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fsys/05]] diff --git a/hurd/interface/fsys_startup.mdwn b/hurd/interface/fsys_startup.mdwn new file mode 100644 index 00000000..21cbdee3 --- /dev/null +++ b/hurd/interface/fsys_startup.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fsys/00]] diff --git a/hurd/interface/fsys_syncfs.mdwn b/hurd/interface/fsys_syncfs.mdwn new file mode 100644 index 00000000..88955524 --- /dev/null +++ b/hurd/interface/fsys_syncfs.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2009 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 redir=fsys/04]] diff --git a/hurd/io_path.mdwn b/hurd/io_path.mdwn index 78e13efd..c47b5dca 100644 --- a/hurd/io_path.mdwn +++ b/hurd/io_path.mdwn @@ -1,27 +1,87 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -# read +[[!meta title="I/O Path"]] - * [[glibc]]'s `read` is in `glibc/sysdeps/mach/hurd/read.c:__libc_read`. +[[!tag open_issue_documentation]] <!-- Someone still needs to make a pass over +this text. --> - * That calls `glibc/hurd/fd-read.c:_hurd_fd_read()`. +[[!toc]] - * That calls `__io_read`, which is an [[RPC]], i.e., that actually results - into the [[translator/ext2fs]] server calling - `hurd/libdiskfs/io-read.c:diskfs_S_io_read`. - * That calls `_diskfs_rdwr_internal`, which calls - `hurd/libpager/pager-memcpy.c:pager_memcpy`, which usually basically just - tell the kernel to virtually project the memory object corresponding to the - file in the caller process's memory. No read is actually done. +# `read`, [[libtrivfs]] + +[[glibc]]'s `read` is in `glibc/sysdeps/mach/hurd/read.c:__libc_read`. + +A buffer (and its size) to store the to-be-read data in is supplied by the +caller of `read`. + +> `__libc_read` calls `glibc/hurd/fd-read.c:_hurd_fd_read`. + +>> `_hurd_fd_read` calls `__io_read`, which is an [[RPC]]: +>> `hurd/hurd/io.defs:io_read`. + +>>> Enter user-side RPC stub `glibc.obj/hurd/RPC_io_read.c:__io_read`. Process +>>> stuff, switch to kernel, etc. + +(For example) [[translator/hello]] server, [[libtrivfs]]-based. Enter +server-side RPC stub `hurd.obj/libtrivfs/ioServer.c:_Xio_read`. Process stuff, +call `hurd/trans/hello.c:trivfs_S_io_read`. + +A 2048 byte buffer is provided. + +> `trivfs_S_io_read`. Depending on the internal state, either a new memory +> region is set-up (and returned as out-of-line data), or the desired amount of +> data is returned in-line. + +Back in `_Xio_read`. + +If the 2048 byte buffer is not decided to be used (out-of-line case or bigger +than 2048 bytes case; server decides to instead provide a new memory region), +the [[`dealloc`|microkernel/mach/mig/documentation/dealloc]] flag is being set, +which causes Mach to unmap that memory region from the server's address space, +i.e., doing a memory *move* from the server to the client. + +Leave server-side RPC stub `_Xio_read`. + +>>> Return from kernel, continue client-side RPC stub `io_read`. Have to copy +>>> data. Three cases: out-of-line data (pass pointer to memory area); +>>> returned more data than fits into the originally supplied buffer (allocate +>>> new buffer, copy all data into it, pass pointer of new buffer); otherwise +>>> copy as much data as is available into the originally supplied buffer. +>>> I.e., in all cases *all* data which was provided by the server is made +>>> available to the caller. + +>> Back in `_hurd_fd_read`. If a new buffer has been allocated previously, or +>> the out-of-line mechanism has been used, the returned data now has to be +>> copied into the originally supplied buffer. If the server returned more +>> data than requested, this is a [[protocol_violation|EGRATUITOUS]]. + +> Back in `__libc_read`. + + +# `read`, [[hurd/translator/ext2fs]]/[[hurd/libdiskfs]] + +(For example) [[translator/ext2fs]] server, enter server-side RPC stub +`hurd.obj/libdiskfs/ioServer.c:_Xio_read`. Process stuff, call +`hurd/libdiskfs/io-read.c:diskfs_S_io_read`. + +A 2048 byte buffer is provided. + +> `diskfs_S_io_read` calls `_diskfs_rdwr_internal`. + +>> That calls `hurd/libpager/pager-memcpy.c:pager_memcpy`, which usually +>> basically just tells the kernel to virtually project the memory object +>> corresponding to the file in the caller process's memory. No read is +>> actually done. * Then, when the process actually reads the data, the kernel gets the user page fault (`gnumach/i386/i386/trap.c:user_trap`), which calls `vm_fault`, @@ -38,3 +98,12 @@ is included in the section entitled * ext2fs eventually finishes the data_request() function, the kernel installs the page into the process that got a fault. + + +# Documentation + + * In [*Linux kernel design patterns - part + 3*](http://lwn.net/Articles/336262/) (2009-06-22), Neil Brown gives a + nice overview of the related layering inside the Linux kernel, + including the VFS layer, page cache and directory entry cache + (dcache). diff --git a/hurd/libchannel.mdwn b/hurd/libchannel.mdwn index 91c7810f..3e19fb18 100644 --- a/hurd/libchannel.mdwn +++ b/hurd/libchannel.mdwn @@ -1,12 +1,12 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] # libchannel @@ -60,3 +60,9 @@ library to implement specialized channel libraries, e.g. *libaudio* and *libnetwork* or similar. So work on *libchannel* will continue, in one form or another. + + +# Related + + * [*Van Jacobson's network channels*](http://lwn.net/Articles/169961/) + (2006-01-31) by Jonathan Corbet. 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/libfshelp.mdwn b/hurd/libfshelp.mdwn new file mode 100644 index 00000000..4eda91b6 --- /dev/null +++ b/hurd/libfshelp.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +TODO. + + +# Open Issues + +[[!tag open_issue_hurd]] + + * IRC, unknown channel, unknown date + + <flavioc> antrik, i had some problems with CLISP. it goes into an infinite loop when there's no stdin or stdout (fshelp closes them when a translator starts). At first I tried to patch it but CLISP has very intricate dependencies on them, so I just created a wraper program (run-lisp-trans) that opens /dev/null as stdin and stdout and then exec's clisp + <marcus> flavioc, antrik: I would suggest to modify libfshelp to start translators with stdin/stdout mapped to /dev/null. + <marcus> or is there a good reason not to? + <flavioc> marcus, the problem is in clisp :-), it should not expect that stdin/stdout are always open + <marcus> flavioc: I agree, but there is really no point in making it hard. many programs will fail if stdin, stdout or stderr are not occupied. historically, they expect them to be there, so IMO libfshelp should be changed + <marcus> flavioc: it's a simple solution, works everywhere and shouldn't do any harm :) + <flavioc> marcus, I see. should I propose that on the mailing list? :-) + <marcus> flavioc: it might be simpler to just crack the svn server and sneak it in :) + <marcus> if you submit a patch I will look at it and check it in if it is ok + <marcus> and see if Roland is still watching ... :D diff --git a/hurd/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/libihash.mdwn b/hurd/libihash.mdwn new file mode 100644 index 00000000..d6b8e8b6 --- /dev/null +++ b/hurd/libihash.mdwn @@ -0,0 +1,59 @@ +[[!meta copyright="Copyright © 2009, 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + + * Hurd libihash + + * old + + * new + + * hurd-l4 libhurd-ihash + + * [[viengoos libhurd-ihash|microkernel/viengoos/projects/new_hash_function]] + + IRC, unknown channel, unknown date + + <neal> so, we need a new ihash implementation + <neal> marcusb: When 80% full, the collision rate is very high. + <neal> marcusb: I tested using 512mb / 4096 entries + <neal> marcusb: Changing the load factor to 30% resulted in my program running more than an order of magnitude faster. + <marcusb> yeah, it shouldn't get so full + <marcusb> don't we do an exponential back-off in the array size? + <marcusb> of course it's clear we can do much better + <marcusb> the ihash algo is very simple + <marcusb> I'm not even sure it makes much sense to have a generic library + + +# Alternatives? + + * glibc + + * include/inline-hashtab.h + + * locale/programs/simple-hash.h + + * misc/hsearch_r.c + + * NNS; cf. f46f0abfee5a2b34451708f2462a1c3b1701facd + + * libstdc++: `unordered_map`, `tr1/unordered_map`, `ext/hash_map` + + * libiberty: `hashtab.c` + + * <http://cmph.sourceforge.net/> + + * <http://libhashish.sourceforge.net/> + + * <http://www.azillionmonkeys.com/qed/hash.html> + + * CCAN's htable, idtree diff --git a/hurd/libnetfs.mdwn b/hurd/libnetfs.mdwn index a2bf47ee..8625f8bc 100644 --- a/hurd/libnetfs.mdwn +++ b/hurd/libnetfs.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -33,7 +34,7 @@ which is, generally speaking, seriously different from *libnetfs*. All in all, *libnetfs* is the library you would choose when you want to write a translator which will show a file (or a directory) in a modified way (for example, if you'd like to show only *.sh* files or -make an archive look unpacked). As different from *libtrivfs*, using +make an archive look unpacked). As different from *[[libtrivfs]]*, using *libnetfs*, you can show to your clients not just a single file, but a whole directory tree. @@ -229,7 +230,7 @@ performance or to solve specific problems. ##Synchronization is Crucial A *libnetfs* programmer shall always keep in mind that, as different -from *libtrivfs*-based translators, *libnetfs*-based translators are +from *[[libtrivfs]]*-based translators, *libnetfs*-based translators are always multithreaded. To guard data against damage each node incorporates a lock. Moreover, each light node usually contains a lock, too. This happens because *libnetfs* nodes and light nodes are diff --git a/hurd/libpager.mdwn b/hurd/libpager.mdwn index c9a1c0b6..d844743d 100644 --- a/hurd/libpager.mdwn +++ b/hurd/libpager.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Mach's [[microkernel/mach/external_pager_mechanism]]. @@ -14,3 +15,17 @@ Mach [[microkernel/mach/IPC]]'s [[microkernel/mach/ipc/sequence_numbering]]. [GNU Hurd Reference Manual: 4.2 Pager Library](http://www.gnu.org/software/hurd/doc/hurd_5.html#SEC32). + + +# Writeback: Writing Out Dirty Pages + + +## Related + + * LWN, Jonathan Corbet, [*No-I/O dirty + throttling*](http://lwn.net/Articles/456904/), 2011-08-31. + + +# Open Issues + + * [[open_issues/linux_vmsig]] diff --git a/hurd/libports.mdwn b/hurd/libports.mdwn new file mode 100644 index 00000000..6f2cd46d --- /dev/null +++ b/hurd/libports.mdwn @@ -0,0 +1,37 @@ +[[!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 +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]]."]]"""]] + +*libports* is a convenience library for easier handling of [[Mach +ports|microkernel/mach/port]]. It is documented in the [[Reference_Manual]]. + +*libports* is not (at least, not for now) a generalization / abstraction of +Mach ports to the functionality the Hurd needs, that is, it is not meant to +provide an interface independently of the underlying [[microkernel]]. + +*libports* does not itself depend on *[[libthreads]]*, but the appropriate +threading hooks are used if present, that is if *[[libthreads]]* is used by +another component. + + +# Message Processing + +## `ports_manage_multithreaded` + +When a message is recieved, the thread acting as receiver checks if any other +thread is also waiting for requests. If there is none, a new thread is +spawned. Thus, the current thread continues processing the message while the +newly created thread starts listening for new ones. ([[!taglink +open_issue_hurd]]: [[open_issues/multithreading]].) + +Also, there are configurable timeouts for [[translator]]s who want to go away +when they are not used. ([[!taglink open_issue_hurd]]: there used to be bugs +in this area, [[!message-id "87hev152we.fsf@becket.becket.net"]], but it may be +fixed as of [[!message-id "20111030210045.GA4983@myhost"]], +[[!GNU_Savannah_Git_hurd_hurd 9b5429e834cde56f73b8ff605e36afc7d9bb6e1b]].) 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/libstore/part.mdwn b/hurd/libstore/part.mdwn new file mode 100644 index 00000000..5260d05d --- /dev/null +++ b/hurd/libstore/part.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="part store"]] + +`part.c` + +Written by Neal in 2001, 2002. + +Useful if the microkernel / [[DDE]] / [[microkernel/mach/gnumach/ports/Xen]] +doesn't export *partition devices*, but only *raw* devices. + +Neal: + +> The motivation was to be able to evict the partitioning logic from Mach. + + +# Booting + +A similar problem is described in +[[community/gsoc/project_ideas/unionfs_boot]], and needs to be implemented. + + +# TODO + +How to use, etc. diff --git a/hurd/libthreads.mdwn b/hurd/libthreads.mdwn new file mode 100644 index 00000000..8b1a97e6 --- /dev/null +++ b/hurd/libthreads.mdwn @@ -0,0 +1,28 @@ +[[!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]]."]]"""]] + +`libthreads` a.k.a. C threads. + + +# Internals + + +## Threads' Death + +C threads death doesn't actually free the thread's stack (and maybe not the +associated Mach ports either). That's because there's no way to free the stack +after the thread dies (because the thread of control is gone); the stack needs +to be freed by something else, and there's nothing convenient to do it. There +are many ways to make it work. + +However, it isn't really a leak, because the unfreed resources do get used for +the next thread. So the issue is that the shrinkage of resource consumption +never happens, but it doesn't grow without bounds; it just stays at the maximum +even if the current number of threads is lower. diff --git a/hurd/libtrivfs.mdwn b/hurd/libtrivfs.mdwn new file mode 100644 index 00000000..b15aeabe --- /dev/null +++ b/hurd/libtrivfs.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 1994, 1996, 1998, 1999, 2000, 2001, 2002, 2003, +2004, 2005, 2007, 2008, 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Certain [[translator]]s do not need to be very complex, because they represent +a single file rather than an entire directory hierarchy. The *trivfs library*, +which is declared in `<hurd/trivfs.h>`, does most of the work of implementing +this kind of translator. This library requires the [[iohelp|libiohelp]] and +[[ports|libports]] libraries. + +Using `libtrivfs` is not the only way to implement such a single-file +translator, but is a convenient abstraction: the library hides a lot of +low-level stuff and you just have to provide a number of call-back functions +and symbols in order to get a functioning (for file I/O, etc.) node in the file +system. + + +# Further Reading + + * In the *[[The_GNU_Hurd_Reference_Manual|reference_manual]]*: + <http://www.gnu.org/software/hurd/doc/hurd_6.html#SEC48>. + + * In the *[[Hurd_Hacking_Guide]]*: + <http://www.gnu.org/software/hurd/hacking-guide/hhg.html#An-Example-using-trivfs>. diff --git a/hurd/logo.mdwn b/hurd/logo.mdwn index aae80561..467e6ba8 100644 --- a/hurd/logo.mdwn +++ b/hurd/logo.mdwn @@ -1,25 +1,11 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -The famous *Hurd Boxes* logo is available at -<http://www.gnu.org/graphics/hurd_mf.html>. - - -On some lonely Wednesday, Colin Leitner and [[Thomas_Schwinge|tschwinge]] -converted these four boxes from the [original METAFONT -sources](http://www.gnu.org/graphics/hurd.mf) to -[[hand-written_SVG_code|boxes-redrawn.svg]]. - -[[!img boxes-redrawn.png]] - - -This symbol is also being used as a favicon for this web site. - -[[!img /favicon.ico]] +[[!meta redir=/logo]] diff --git a/hurd/networking.mdwn b/hurd/networking.mdwn index ff16eb25..bdf9def2 100644 --- a/hurd/networking.mdwn +++ b/hurd/networking.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2000, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2000, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] For each supported `PF_*` protocol family, there is a file `/servers/socket/N` where `N` is the numberic value fo the `PF_*` symbol. Right now @@ -17,10 +18,10 @@ where `N` is the numberic value fo the `PF_*` symbol. Right now User programs open those files, and use the `socket_create` [[RPC]] to make a new socket. With that socket, they can use the other `socket_*` RPCs and also the `io_*` RPCs. The `socket_*` RPCs are essentially clones of the [[Unix]] -syscalls in question. +[[system call]]s in question. The only exception is `sockaddrs`, which are implemented as [[ports|libports]] -instead of the opaque data arrays they are in the syscalls. You manipulate +instead of the opaque data arrays they are in the system calls. You manipulate `sockaddr` ports with the `socket_create_address`, `socket_fabricate_address`, and `socket_whatis_address` calls. The `sockaddr` port is then used in socket calls like `socket_connect` and `socket_accept`. diff --git a/hurd/ng.mdwn b/hurd/ng.mdwn index fb4d742f..fbebb137 100644 --- a/hurd/ng.mdwn +++ b/hurd/ng.mdwn @@ -10,72 +10,71 @@ These pages try to summarize the major discussions and ideas. This section explains the motivations behind the new design: - * [[Issues_with_Mach]] * [[Issues_with_L4_Pistachio]] * [[Limitations_of_the_original_Hurd_design]] - * History of the [[history/port_to_L4]] + * History of the [[history/port_to_another_microkernel]] # Work already done +A [[critique]] of the original Hurd is available. + A [[position_paper]] by Marcus Brinkmann and Neal H. Walfield can be found. A draft specification of the Hurd-NG interfaces has been, but is no longer, available. -A [[critique]] of the original Hurd is available. # Subjects ## Design processus -* [[DesignGoals]] -* [[RequirementsForUser]] -* [[DesignPrinciples]] +* [[Design Goals|DesignGoals]] +* [[Requirements For User|RequirementsForUser]] +* [[Design Principles|DesignPrinciples]] * [[Philosophy]] ## Concepts -* [[security]] -* [[CapabilityBasedMicrokernel]] -* [[FirstClassReceiveBuffer]] +* [[Security]] +* [[Capability Based Microkernel|CapabilityBasedMicrokernel]] +* [[First-class Receive Buffer|FirstClassReceiveBuffer]] * [[PowerBox]] -* [[WhatIsACapability]] -* [[WhatIsAConstructor]] -* [[WhatIsASpacebank]] -* [[TrivialConfinementVsConstructorVsFork]] -* [[CopyVsRevocableCopyVsMap]] -* [[SetuidVsConstructor]] -* [[HurdishApplicationsForPersistence]] -* [[WhatsInAGroup]] -* [[ThePolycastInterface]] -* [[PermissionBits]] -* [[CancellationForwarding]] +* [[What is a Capability|WhatIsACapability]] +* [[What is a Constructor|WhatIsAConstructor]] +* [[What is a Spacebank|WhatIsASpacebank]] +* [[Trivial Confinement vs. Constructor vs. Fork|TrivialConfinementVsConstructorVsFork]] +* [[Copy vs. Revocable Copy vs. Map|CopyVsRevocableCopyVsMap]] +* [[Setuid vs. Constructor|SetuidVsConstructor]] +* [[Hurdish Applications for Persistence|HurdishApplicationsForPersistence]] +* [[What's in a Group|WhatsInAGroup]] +* [[The Polycast Interface|ThePolycastInterface]] +* [[Permission Bits|PermissionBits]] +* [[Cancellation Forwarding|CancellationForwarding]] ## Problems to solve -* [[HowMuchConfinementDoWeWant]] -* [[SharedLibraries]] -* [[PathMax]] +* [[How Much Confinement Do We Want|HowMuchConfinementDoWeWant]] +* [[Shared Libraries|SharedLibraries]] +* [[Path Max|PathMax]] ## Implementation -* [[ChoiceOfMicrokernel]] -* [[HurdInterafaces]] -* [[PosixLayer]] -* [[SystemStructure]] +* [[Hurd Interafaces|HurdInterafaces]] +* [[Posix Layer|PosixLayer]] +* [[System Structure|SystemStructure]] ## Use Cases _please move me somewhere better! [[SamMason]]_ -* [[UseCaseUserFileSystem]] -* [[UseCasePrivateKeys]] +* [[Use Case User Filesystem|UseCaseUserFileSystem]] +* [[Use Case Private Keys|UseCasePrivateKeys]] ## Organization diff --git a/hurd/ng/choiceofmicrokernel.mdwn b/hurd/ng/choiceofmicrokernel.mdwn deleted file mode 100644 index 20ee6f05..00000000 --- a/hurd/ng/choiceofmicrokernel.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -TBD - -* [[MicrokernelL4]] -* [[MicrokernelCoyotos]] diff --git a/hurd/ng/discussion.mdwn b/hurd/ng/discussion.mdwn new file mode 100644 index 00000000..d4632bd5 --- /dev/null +++ b/hurd/ng/discussion.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2009 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]]."]]"""]] + +To go beyond research project Hurd have to support thousands of various programs running on GNU/Linux nowadays. +It looks like ExoKernel approach http://pdos.csail.mit.edu/exo.html might be useful here. +Does somebody tried to look into something like Hurd exokernel + liblinux? diff --git a/hurd/ng/microkernelcoyotos.mdwn b/hurd/ng/microkernelcoyotos.mdwn deleted file mode 100644 index cdf4e1bf..00000000 --- a/hurd/ng/microkernelcoyotos.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -# <a name="The_Coyotos_microkernel"> The Coyotos microkernel </a> - -[Coyotos](http://www.coyotos.org/index.html) is a microkernel and OS and the successor of EROS, that itself is the successor of KeyKOS. A more complete history can be found [here](http://www.coyotos.org/history.html). Its main objectives are to correcte some shortcomings of EROS, demonstrate that an atomic kernel design scales well, and (eventually) to completely formally verify both the kernel and critical system components by writing them in a new language called [bitc](http://www.bitc-lang.org/). [See [l4.verified](http://nicta.com.au/research/projects/l4.verified) for work on formally verifying an L4 microkernel.] - -Coyotos is an orthogonally persistent pure capability system. It uses continuation based unbuffered asynchronous IPC (actually it's synchronous IPC with asynchronous syscalls). - -TODO: explain these terms and (more important) their consequences on system design. - -The coyotos microkernel specification can be found [here](http://www.coyotos.org/docs/ukernel/spec.html) diff --git a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn index 4eeef6ee..949895e7 100644 --- a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn +++ b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn @@ -6,10 +6,11 @@ This comparison is about a simple situation: there is a parent process P, which # <a name="Trivial_Confinement"> Trivial Confinement </a> -For trivial confinement, there is a system call to create a process from some memory pages. P performs the following steps: +For trivial confinement, there is a [[system call]] to create a process from +some memory pages. P performs the following steps: * Allocate some memory and put the code image of the child into that memory. This can be done by P, or for example by the file system which then gives the resulting memory (space bank) to P. -* Perform the system call on that memory. The result is a capability to C. +* Perform the [[system call]] on that memory. The result is a capability to C. * Send A to C using the returned capability. Note that it is up to the implementation of the system what happens with P's access to the memory which holds the child. For example, it is probably a good idea if it is at least unmapped, so it cannot accidentily write things in it. It could even be revoked, so that it can't write things in it, even if it wants to. @@ -32,7 +33,16 @@ This mechanism is targeted at a specific use pattern, namely that a process is c # <a name="POSIX_Fork"> </a> POSIX Fork -POSIX fork, or rather fork+exec, is how things are done on many current systems. It may be insightful to see it included in the comparison, especially for people who are new to the subject. There are two system calls, fork and exec. Fork will create a clone of the current process, including all the capabilities (that is, file descriptors) of the parent (except the ones which have explicitly been excluded). Exec is a system call which really goes to the filesystem, not the kernel (although on systems which use it, the filesystem usually resides in the kernel), and asks it to spawn a new process from the contents of a certain path in place of the caller. This passes all capabilities to the new process. The procedure is: +POSIX fork, or rather fork+exec, is how things are done on many current +systems. It may be insightful to see it included in the comparison, especially +for people who are new to the subject. There are two [[system call]]s, fork +and exec. Fork will create a clone of the current process, including all the +capabilities (that is, [[unix/file_descriptor]]s) of the parent (except the +ones which have explicitly been excluded). Exec is a [[system call]] which +really goes to the filesystem, not the kernel (although on systems which use +it, the filesystem usually resides in the kernel), and asks it to spawn a new +process from the contents of a certain path in place of the caller. This +passes all capabilities to the new process. The procedure is: * P calls fork(), creating P'. * P' drops B. @@ -52,7 +62,11 @@ In contrast, the other two options don't pass anything by default. If there is a The problem of fork+exec can be solved. It is if the default would be to not pass capabilities to the new process, but specify a list of capabilities that it should keep, or (like in the other cases) pass them over a new channel which is implicitly created during the fork. However, in that case the only difference with trivial confinement is that P' dies in the process (and thus must be created to prevent P from dying). Almost any use of exec is in practice preceded by a fork for this purpose. It would be easier to make trivial confinement the default operation and let P die directly after it in the rare case that it should. -The only reason for continuing to use fork+exec would be that it is what existing programs do. However, they break anyway if they need to specify which file descriptors to pass. So they need to be adapted. Therefore, it's better to make the usual spawning method the primitive one, and emulate the other. +The only reason for continuing to use fork+exec would be that it is what +existing programs do. However, they break anyway if they need to specify which +[[unix/file_descriptor]]s to pass. So they need to be adapted. Therefore, it's +better to make the usual spawning method the primitive one, and emulate the +other. # <a name="Trivial_Confinement_vs_Construct"> Trivial Confinement vs Constructor </a> @@ -67,7 +81,7 @@ Except for the control, there is really only one other difference, and that's ad What it doesn't do is protect the code image against bugs in P. In the constructor the trusted and well-tested constructor code is handling the image, for trivial confinement the (very possibly) buggy program P. In particular, when starting a program from a file system, with trivial confinement the operation is: * Ask the file system for the code, receive a capability to a space bank with a copy (on write) of it. -* Make the system call to turn it into a program. +* Make the [[system call]] to turn it into a program. Now this isn't much more complicated than the constructor which does: diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index 5fd66292..2618cd90 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010, 2011, +2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -22,6 +22,66 @@ There is a separate page about [[System_API_Limitations]]. You may ask on the [[mailing lists/bug-hurd]] mailing list for details or questions about fixing bugs. +## <a name="GNU build system"> GNU build system </a> + +For a good overview of the components in the GNU build system, see +<http://en.wikipedia.org/wiki/GNU_build_system> and +<http://www.gnu.org/s/hello/manual/autoconf/index.html>. + +The GNU build system distinguishes between 'build', 'host' and 'target' machines. +The 'build' machine is where compilers are run, the 'host' machine where the package +being built will run, and for cross compiling the 'target' machine, on which the compiler +built will generate code for. + +When using GNU autotools to configure a package config.guess and config.sub from autotools-dev +are used to find out the build machine identity: CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM. +For GNU/Hurd config.guess gives 'i686-unknown-gnu0.3'. Sometimes a quadruple is used +adding KERNEL, e.g. for Linux on an amd64: 'x86_64-unknown-linux-gnu'. This +is however actually a triple, it just happens that the operating system part +unfortunately contains a '-'. config.sub is used to +canonicalize on these triplets, e.g. config.sub i686-gnu gives 'i686-pc-gnu'. + +On Debian systems the build Makefile is debian/rules and some Debian packages will set $host to +'i486-pc-gnu'. This is accomplished with the 'dpkg-architecture -qDEB_HOST_GNU_TYPE' construct +forwarded to configure in debian/rules, e.g. configure --host=$DEB_HOST_GNU_TYPE. +Another way to set $build, $host etc is via the Debian dh_auto_configure script from the debhelper +package which uses the Perl code autoconf.pm to find out these variables. + +## <a name="autoconf"> Fixing configure.{ac,in} </a> + +The GNU/Hurd (and GNU/kFreeBSD) toolchain is extremely close to the GNU/Linux toolchain. +configure.ac thus very often just needs to be fixed by using the same cases as Linux, that is, turn + + switch "$host_os" in + case linux*) + +into + + switch "$host_os" in + case linux*|k*bsd-gnu*|gnu*) + +for a host_os case statement, or + + switch "$host" in + case *-linux*) + +into + + switch "$host" in + case *-linux*|*-k*bsd-gnu*|*-gnu*) + +If separate case is needed, make sure to put *-gnu* *after* *-linux*: + + switch "$host" in + case *-linux*|*-k*bsd-gnu*) + something;; + + case *-gnu*) + something else;; + +because else *-gnu* would catch i386-pc-linux-gnu for instance... + +Note: some of such statements are not from the source package itself, but from aclocal.m4 which is actually from libtool. In such case, the package simply needs to be re-libtoolize-d. ## <a name="Undefined_bits_confname_h_tt_mac"> Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) </a> @@ -50,10 +110,21 @@ An example with `fpathconf`: If you get Bad File Descriptor error when trying to read from a file (or accessing it at all), check the `open()` invocation. The second argument is the access method. If it is a hard coded number instead of a symbol defined in the standard header files, the code is screwed and should be fixed to either use `O_RDONLY`, `O_WRONLY` or `O_RDWR`. This bug was observed in the `fortunes` and `mtools` packages for example. -## <a name="PATH_MAX_tt_MAX_PATH_tt_MAXPATHL"> `PATH_MAX` / `MAX_PATH` / `MAXPATHLEN` </a> +## <a name="PATH_MAX_tt_MAX_PATH_tt_MAXPATHL">`PATH_MAX`, `MAX_PATH`, `MAXPATHLEN`, `_POSIX_PATH_MAX`</a> + +<http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html> Every unconditionalized use of `PATH_MAX`, `MAX_PATH` or `MAXPATHLEN` is a POSIX incompatibility. If there is no upper limit on the length of a path (as its the case for GNU), this symbol is not defined in any header file. Instead, you need to either use a different implementation that does not rely on the length of a string or use `sysconf()` to query the length at runtime. If `sysconf()` returns -1, you have to use `realloc()` to allocate the needed memory dynamically. Usually it is thus simpler to just use dynamic allocation. Sometimes the amount is actually known. Else, a geometrically growing loop can be used: for instance, see [Alioth patch](http://alioth.debian.org/tracker/download.php/30628/410472/303735/1575/cpulimit-path-max-fix.patch) or [Pulseaudio patch](http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=patch-pulse;att=1;bug=522100). Note that in some cases there are GNU extensions that just work fine: when the `__GLIBC__` macro is defined, `getcwd()` calls can be just replaced by `get_current_dir_name()` calls. +Note: constants such as `_POSIX_PATH_MAX` are only the minimum required value +for a potential corresponding `PATH_MAX` macro. They are not a replacement for +`PATH_MAX`, just the minimum value that one can assume. + +Note 2: Yes, some POSIX functions such as `realpath()` actually assume that +`PATH_MAX` is defined. This is a bug of the POSIX standard, which got fixed in +the latest revisions, in which one can simply pass `NULL` to get a dynamically +allocated buffer. + ## <a name="ARG_MAX"> `ARG_MAX` </a> Same rationale as `PATH_MAX`. There is no limit on the number of arguments. @@ -64,7 +135,7 @@ Same rationale as `PATH_MAX`. There is no limit on the number of iovec items. ## <a name="MAXHOSTNAMELEN_tt_"> `MAXHOSTNAMELEN` </a> -Same as `PATH_MAX`. When you find a `gethostname()` function, which acts on a static buffer, you can replace it with Neal's [xgethostname function](http://ftp.walfield.org/pub/people/neal/xgethostname/) which returns the hostname as a dynamic buffer. For example: +Same as `PATH_MAX`. When you find a `gethostname()` function, which acts on a static buffer, you can replace it with Neal's [xgethostname function](http://walfield.org/pub/people/neal/xgethostname/) which returns the hostname as a dynamic buffer. For example: Buggy code: @@ -149,10 +220,6 @@ by error_t err = error_t(EINTR); -## <a name="Filenames_ending_in_a_slash_"> Filenames ending in a slash \`/' </a> - -Those are evil if they don't exist and you want to name a directory this way. For example, `mkdir foobar/` will not work on GNU. This is POSIX compatible. POSIX says that the path of a directory may have slashes appended to it. But the directory does not exist yet, so the path does not refer to a directory, and hence trailing slashes are not guaranteed to work. Just drop the slashes, and you're fine. - ## <a name="Missing_termio_h_tt_"> Missing `termio.h` </a> Change it to use `termios.h` (check for it properly with autoconf `HAVE_TERMIOS_H` or the `__GLIBC__` macro) @@ -187,7 +254,11 @@ then be found. ## <a name="SA_SIGINFO"> `SA_SIGINFO` </a> -Not implemented, packages may be fixed for working around this: use void sighandler(int num) prototype and sa_handler field. +Implemented by Jérémie Koenig, pending upload in Debian eglibc 2.13-19. + +## <a name="SA_NOCLDWAIT"> `SA_NOCLDWAIT` </a> + +Not implemented yet. ## <a name="SOL_IP"> `SOL_IP` </a> @@ -223,7 +294,7 @@ These are not POSIX, `sys/types.h` and `stdint.h` should be used instead. ## <a name="iopl"> `iopl` </a> -Not supported. Try to replace with `ioperm(0, 65536, 1)` (conditionned with `__GNU__` as that will not work in Linux). +Not supported and actually very dangerous (permits userland to completely disable interruptions...). Replace with `ioperm(0, 65536, 1)`. ## <a name="iopl"> `semget`, `sem_open` </a> @@ -233,6 +304,63 @@ Not implemented, will always fail. Use `sem_init()` instead if possible. Not implemented, not POSIX. Try to disable the feature in the package. -## <a name="broken_libc6_dependency"> broken libc6 dependency </a> +## <a name="parport"> <linux/parport.h> <linux/ppdev.h> </a> + +There is no programming interface for the parallel port on GNU/Hurd yet. + +## <a name="cdrom"> <linux/cdrom.h> </a> + +Use <sys/cdrom.h> instead. + +## <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. + +For example (C/C++): + + /* check whether it does not exist */ + if (errno == 2) + ... + +or Python: + + # check whether it does not exist + try: + ... + except OSError, err: + err.errno == 2: + ... + +This is wrong, as [the actual values of the `E*` are unspecified (per POSIX)](http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html#tag_02_03). You must always use the predefined constants for the possible errors. + +For example (C/C++): + + /* check whether it does not exist */ + if (errno == ENOENT) + ... + +With Python, you can use the [`errno` module](http://docs.python.org/library/errno.html) for the various constants: + + # check whether it does not exist + try: + ... + except OSError, err: + import errno + err.errno == errno.ENOENT: + ... + +## <a name="libdl"> undefined reference to `dlopen`, `dlsym`, `dlclose` </a> + +Configure script often hardcode the library that contains dlopen & such (`-ldl'), and only for Linux. Simply add the other GNU OS cases: replace `linux*' with `linux*|gnu*|k*bsd*-gnu` + +## <a name="linux_headers"> Missing `linux/types.h`, `asm/types.h`, `linux/limits.h`, `asm/byteorder.h`, `sys/endian.h`, `asm/ioctl.h`, `asm/ioctls.h`, `linux/soundcard.h` </a> + +These are often used (from lame rgrep results) instead of their standard equivalents: `sys/types.h` (or `stdint.h` for fixed-size types), `limits.h`, `endian.h`, `sys/ioctl.h`, `sys/soundcard.h` + +## <a name="linux_features"> Missing `sys/*.h`, `linux/*.h`</a> -Some packages use an erroneous dependency on `libc6-dev`. This is incorrect because `libc6` is specific to GNU/Linux. The corresponding package for GNU is `libc0.3-dev` but other OSes will have different ones. You can locate the problem in the `debian/control` file of the source tree. Typical solutions include detecting the OS using `dpkg-architecture` and hardcoding the soname, or better, use a logical OR. eg: `libc6-dev | libc0.3-dev | libc-dev`. The `libc-dev` is a virtual package that works for any soname but you have to put it only as the last option. +These are linuxish things, they may not have Hurd equivalents yet, better disable the code. diff --git a/hurd/porting/system_api_limitations.mdwn b/hurd/porting/system_api_limitations.mdwn index 06a6b382..1615ccc0 100644 --- a/hurd/porting/system_api_limitations.mdwn +++ b/hurd/porting/system_api_limitations.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2003, 2004, 2005, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2003, 2004, 2005, 2009, 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 @@ -22,9 +22,7 @@ These are the known system API limits that have porting implications. **_[\#47998](http://bugs.debian.org/47998): `msgget` IPC not implemented_** -**_[\#184565](http://bugs.debian.org/184565): libc0.3: missing shm\* functions (from `<sys/shm.h>`)_**<br />**breaks:** cdrtools<br />**error:** warning: shm\* is not implemented and will always fail - -**_[\#190581](http://bugs.debian.org/190581): nice() doesn't work_**<br />**breaks:** coreutils<br />**error:** `nice()` doesn't take effect on some situations +**_[[nice() doesn't work|open_issues/nice_vs_mach_thread_priorities]]_**. **_[\#187391](http://bugs.debian.org/187391): libc0.3-dev: `sockaddr_un.sun_path` can't be assigned a `const char *` when compiling with g++_**<br />**breaks:** fam, gail<br />**status:** maybe this should be in [[PortingIssues]] (see _long_ bug log) diff --git a/hurd/running.mdwn b/hurd/running.mdwn index 470b5f0b..a14106e1 100644 --- a/hurd/running.mdwn +++ b/hurd/running.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag stable_URL]] There are several different ways to run a GNU/Hurd system: @@ -14,7 +17,11 @@ There are several different ways to run a GNU/Hurd system: * [[microkernel/mach/gnumach/ports/Xen]] - In Xen * [[Live_CD]] * [[QEMU]] - In QEMU +* [[VirtualBox]] - In VirtualBox * [[vmware]] (**non-free!**) -* [[FlashHurd]] - From a flash stick + +* [[FAQ]] * [[Public_hurd_boxen]] + +[[chroots|chroot]] need a couple of tricks to work properly. diff --git a/hurd/running/arch_hurd.mdwn b/hurd/running/arch_hurd.mdwn new file mode 100644 index 00000000..0e6075bb --- /dev/null +++ b/hurd/running/arch_hurd.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Arch Hurd"]] + +Arch Hurd is a port of Arch Linux to the GNU Hurd, founded on 2010-01-04 by Michael Walker (Barrucadu) and, with input from a variety of people including Allan McRae (allan), Matthias Lanzinger (melpo), and Alexander Preisinger (giselher), the project has made excellent process. There is a livecd available on the Arch Hurd website, with which you can try or install Arch Hurd. + +### Links + +* Official Website: <http://www.archhurd.org> +* Installation Guide: <http://wiki.archhurd.org/wiki/Installation_Guide> +* Mailing Lists: <http://lists.archhurd.org> +* Forum: <http://bbs.archhurd.org> +* IRC: #archhurd on irc.freenode.net diff --git a/hurd/running/debian.mdwn b/hurd/running/debian.mdwn index 97d35bd7..fcd4d49b 100644 --- a/hurd/running/debian.mdwn +++ b/hurd/running/debian.mdwn @@ -1,28 +1,24 @@ [[!meta title="Debian GNU/Hurd"]] -### Debian Resources - +# Debian Resources - Official page about the Debian GNU/Hurd port: [Debian GNU/Hurd](http://www.debian.org/ports/hurd/) +- Debian [[FAQ]] — Frequently Asked Questions -- Debian [[FAQ]] -- Frequently Asked Questions - -### Installing +## QEMU Image +[[!inline pages=hurd/running/debian/qemu_image raw=yes feeds=no]] +# Installing - [Installation Instructions](http://www.debian.org/ports/hurd/hurd-install) - - [Upgrading K11 or K14 based systems to - unstable](http://lists.debian.org/debian-hurd/2007/09/msg00007.html) -- [[After_install]] -- Do this to get networking, new console and X - -### Contributing + - [Upgrading K11 or K14 based systems to unstable](http://lists.debian.org/debian-hurd/2007/09/msg00007.html) +- [[After_install]] — Do this to get networking, new console and X -- [[Porting]] -- Helping with porting packages - * [[Patch_submission]] -- How to submit patches for build failures +# Contributing +- [[Porting]] — Helping with porting packages + * [[Patch_submission]] — How to submit patches for build failures - [[Creating_image_tarball]] -### Additional Information - +# Additional Information - [Presentation](http://people.debian.org/~mbanck/talks/hurd_lt2004/html/) - *Debian GNU/Hurd* by [[MichaelBanck]], LinuxTag 2004 Karlsruhe + *Debian GNU/Hurd*, [[MichaelBanck]], LinuxTag 2004 Karlsruhe - [[Status]] - [Archive Qualification](http://wiki.debian.org/ArchiveQualification/hurd-i386) - diff --git a/hurd/running/debian/MediaPressKitDiscuss.mdwn b/hurd/running/debian/MediaPressKitDiscuss.mdwn index e8b1cfff..2bd97290 100644 --- a/hurd/running/debian/MediaPressKitDiscuss.mdwn +++ b/hurd/running/debian/MediaPressKitDiscuss.mdwn @@ -1,5 +1,3 @@ -%TOC% - # <a name="Media_Press_Kit"> Media / Press Kit </a> ## <a name="Problem"> Problem </a> diff --git a/hurd/running/debian/after_install.mdwn b/hurd/running/debian/after_install.mdwn index 15ca9c83..419940a7 100644 --- a/hurd/running/debian/after_install.mdwn +++ b/hurd/running/debian/after_install.mdwn @@ -1,35 +1,6 @@ First steps after installation. -So you have managed to get past the first `native-install` runs in single-user -mode? - -Time to get to work. - -[[!toc]] - - -### Get Networking Running - -[[Network]]. - -Check if your NIC was detected by GNU Mach: - - # devprobe eth0 - -`devprobe` (run as user *root*) will print `eth0` on successful detection. If -it doesn't, your NIC was not detected correctly. You can then try to do the -following (also as user *root*) for getting details: - - # cat /dev/klog > ~/klog - [Wait a second, then press `Ctrl-C'.] - -Now examine the `~/klog` file. - -If the NIC was detected: - - # settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a 192.168.1.3 -g 192.168.1.1 -m 255.255.255.0 - -In order to use DHCP, you need to install the `dhcp-client` package and run `dhclient eth0` etc. +See http://www.debian.org/ports/hurd/hurd-install for configuration bits and tips and tricks. # Setup GRUB @@ -40,72 +11,5 @@ you. See [[GRUB]]'s page for this. # Setup `apt-get` -Sometimes getting `apt-get` to work is not straightforward. Good mirrors to -put in `/etc/apt/sources.list` are (as of Jan 2007): - - deb http://mirrors.kernel.org/debian unstable main contrib - deb-src http://mirrors.kernel.org/debian unstable main contrib - deb http://ftp.debian-ports.org/debian unreleased main - deb-src http://ftp.debian-ports.org/debian unreleased main - -`apt-get` update a couple of times if some file fails to download. - -If when doing your first `apt-get`, `dpkg` complains of missing programs, get root in a login shell (`su -`). - Installing packages without having a network connection is described [[Distrib/DebianAptOffline]]. - -# [[translator/Random]] - -You often need `scp` and `ssh`. There is now a `random-egd` package available which uses -a random translator by Ryan Hunter and the entropy gathering daemon as entropy source. - -See [[Translator/random]] for more information. - -# [[Console]] - -The latest Hurd package in Debian, plus the `native-install` script, creates -all necessary device nodes and other magic. You just need to edit -`/etc/default/hurd-console` to tune the parameters and tell it to start at -bootup. - -You can also call the Hurd console manually with the proper arguments: - - console -d vga -d pc_kbd --repeat=kbd -d pc_mouse --repeat=mouse \ - -d generic_speaker -c /dev/vcs - - cd /dev - ln -s cons/kbd . - ln -s cons/mouse . - - -# [[Hurd/DebianXorg]] - -You first must have setup the virtual console. See above. - -Assuming you've installed WindowMaker and have tried running `startx` already: - - [/etc/xorg.conf] - - Section "Module" - # Load "dri" - # Load "speedo" - . - . - . - EndSection - - Section "InputDevice" - Identifier "Configured Mouse" - Driver "mouse" - Option "CorePointer" - Option "Device" "/dev/mouse" - Option "Protocol" "osmouse" - EndSection - -Make sure not to have the `Emulate3Buttons` and `ZAxisMapping` settings set, as -they lead to problems with e.g. dragging windows around. - -# What about package XYZ? - -See if you can find a useful tip in [[package_troubleshooting]]. diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn new file mode 100644 index 00000000..8d351aae --- /dev/null +++ b/hurd/running/debian/dhcp.mdwn @@ -0,0 +1,31 @@ +[[!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_porting]] + +In order to use DHCP, you need to install the `ifup` and `isc-dhcp-client` +packages, and manually create the following two symbolic links: + + # ln -s ../rcS.d/S06ifupdown-clean ../rcS.d/S11networking /etc/rc.boot/ + +During execution at boot time, the `S11networking` script will emit some error +messages while trying to configure the loopback interface. These are not +fatal. + +Debian GNU/Hurd doesn't currently execute's Debian standard `/etc/rcS.d/*` boot +scripts, but has its own `/libexec/rc` script -- which integrates scripts from +`/etc/rc.boot/` instead. + + +# Open Issues + + * [[!debbug 616290]] + + * [[Proper Hurdy DHCP support|hurd/translator/pfinet/dhcp]] diff --git a/hurd/running/debian/faq.mdwn b/hurd/running/debian/faq.mdwn index 4966456a..8aaadf9c 100644 --- a/hurd/running/debian/faq.mdwn +++ b/hurd/running/debian/faq.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2007 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,7 +11,7 @@ is included in the section entitled [[!meta title="Debian GNU/Hurd FAQ"]] -See also the [[Hurd_FAQ|hurd/FAQ]] and [[after_install]]. +See also [[after_install]] instructions, and other [[/FAQ]]. [[!inline pages="hurd/running/debian/faq/* and !*/discussion" diff --git a/hurd/running/debian/faq/512_mib_ram_limit.mdwn b/hurd/running/debian/faq/512_mib_ram_limit.mdwn index 90c16a69..f89a5c01 100644 --- a/hurd/running/debian/faq/512_mib_ram_limit.mdwn +++ b/hurd/running/debian/faq/512_mib_ram_limit.mdwn @@ -10,9 +10,12 @@ is included in the section entitled [[!meta title="512 MiB RAM Limit"]] -GNU Mach does not cope well with lots of memory. Newer versions of the Debian -`gnumach` package will limit themselves to around 1 GiB of memory. If you have -an older version, or still experience problems with `vmstat` (see above) -reported much less memory than you have, the best is to limit the memory it can -see via GRUB's `upppermem` feature. Add `uppermem 786432` to GRUB's Hurd entry -in `menu.lst`. +Just like any 32bit OS without bad tricks, GNU Mach does not cope well with lots +of memory. Newer versions of the Debian `gnumach` package will limit themselves +to around 1 GiB of memory. If you want more, you can twiddle the VM_MAX_ADDRESS +limit between kernelland and userland in i386/include/mach/i386/vm_param.h. + +If you have an older version, or still experience problems with `vmstat` (see +above) reported much less memory than you have, the best is to limit the memory +it can see via GRUB's `upppermem` feature. Add `uppermem 786432` to GRUB's Hurd +entry in `menu.lst`. diff --git a/hurd/running/debian/faq/apt_umount.mdwn b/hurd/running/debian/faq/apt_umount.mdwn index f2889f3e..db0dbfd1 100644 --- a/hurd/running/debian/faq/apt_umount.mdwn +++ b/hurd/running/debian/faq/apt_umount.mdwn @@ -22,4 +22,4 @@ Give executable permission to the script. # chmod +x /usr/bin/umount In `/etc/fstab` add a trailing `/` after cdrom like `/cdrom/` since apt uses a -traing `/`. +trailing `/`. diff --git a/hurd/running/debian/faq/debugging_translators.mdwn b/hurd/running/debian/faq/debugging_translators.mdwn index d3aadec8..b55484e1 100644 --- a/hurd/running/debian/faq/debugging_translators.mdwn +++ b/hurd/running/debian/faq/debugging_translators.mdwn @@ -9,9 +9,7 @@ is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] In order to [[debug|debugging]] translators and being able to step into glibc -during it, you need the `hurd-dbg` and `libc0.3-dbg` packages installed. Then +during it, you need the `hurd-dbg` and `libc0.3-dbg` packages installed. If you need to debug the initialization of the translator, start the translator like `settrans -P /foo /usr/bin/env LD\_LIBRARY\_PATH=/usr/lib/debug /hurd/foofs`. The `-P` option will make it pause and you will be able to attach [[debugging/GDB]] to the process. - -Is starting the translator like this really needed? diff --git a/hurd/running/debian/faq/df.mdwn b/hurd/running/debian/faq/df.mdwn index 4de232da..bbd3a7b9 100644 --- a/hurd/running/debian/faq/df.mdwn +++ b/hurd/running/debian/faq/df.mdwn @@ -8,6 +8,12 @@ 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]]."]]"""]] -There is no `/etc/mtab`, so just running `df` will yield an error. Pass `df` a -path like `df /` or `df ./` to see the disk usage of that particular file -system. +There is no `/etc/mtab` (due to dynamic translator startup, its content is hard +to define actually, see +[[the mtab GSoC project idea|community/gsoc/project_ideas/mtab]]), +so just running `df` will yield the following error. + + df: cannot read table of mounted file systems + +Pass `df` a path like `df /` or `df ./` to see the disk usage of that particular +file system. diff --git a/hurd/translator/procfs/top.mdwn b/hurd/running/debian/faq/eata.mdwn index 2cba78ad..fa7dbdec 100644 --- a/hurd/translator/procfs/top.mdwn +++ b/hurd/running/debian/faq/eata.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,11 +8,6 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] - open("/proc/stat", O_RDONLY) = 3 - open("/proc/sys/kernel/pid_max", O_RDONLY) = 3 - open("/proc", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 - open("/proc/1/stat", O_RDONLY) = 4 - open("/proc/1/statm", O_RDONLY) = 4 - open("/proc/2/stat", O_RDONLY) = 4 - open("/proc/2/statm", O_RDONLY) = 4 - [...] +In some virtual machines (e.g. VirtualBox), "probing eata on XXX" may be +quite long. This is apparently due to poor efficiency of the virtualizer, not +Mach. There is no such issue on real hardware or using qemu/kvm. diff --git a/hurd/running/debian/faq/ps_hangs.mdwn b/hurd/running/debian/faq/ps_hangs.mdwn index b5e35420..febfeb59 100644 --- a/hurd/running/debian/faq/ps_hangs.mdwn +++ b/hurd/running/debian/faq/ps_hangs.mdwn @@ -8,4 +8,5 @@ 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]]."]]"""]] -If `ps` hangs, try `ps -M` which might still work. +If `ps` hangs, try `ps -M` which might still work by not getting detailed +information from processes. diff --git a/hurd/running/debian/faq/sshd_only_works_for_root_logins.mdwn b/hurd/running/debian/faq/sshd_only_works_for_root_logins.mdwn index 517d59dc..1a3c46e1 100644 --- a/hurd/running/debian/faq/sshd_only_works_for_root_logins.mdwn +++ b/hurd/running/debian/faq/sshd_only_works_for_root_logins.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,6 +9,11 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] +This isssue has been fixed in the Debian hurd / libc0.3 packages as of 2010-11. +Retire this item sometime after 2011. + +--- + Privilege seperation does not work with Hurd currently. You need to explicitely set `PrivilegeSeparation` to `no` in `/etc/ssh/sshd_options`, just commenting out the entry will not work as it is on by default. Also make sure you have diff --git a/hurd/running/debian/faq/xserver-common.mdwn b/hurd/running/debian/faq/xserver-common.mdwn index 09fbc902..d1b17f31 100644 --- a/hurd/running/debian/faq/xserver-common.mdwn +++ b/hurd/running/debian/faq/xserver-common.mdwn @@ -8,5 +8,5 @@ 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]]."]]"""]] -You need to run `dpkg-reconfigure xserver-common` and select `Anybody` for +You need to run `dpkg-reconfigure x11-common` and select `Anybody` for starting X as there is no way to detect console users currently. diff --git a/hurd/running/debian/package_troubleshooting.mdwn b/hurd/running/debian/package_troubleshooting.mdwn index 829af8e3..c6236c2f 100644 --- a/hurd/running/debian/package_troubleshooting.mdwn +++ b/hurd/running/debian/package_troubleshooting.mdwn @@ -1,9 +1,5 @@ This page reports known Hurd-specific bugs, quirks and corresponding solutions and workarounds with Debian GNU/Hurd package installation and working. -## <a name="Table_of_Contents"> Table of Contents </a> - -%TOC% - ## <a name="Dpkg_wants_external_programs_"> Dpkg wants external programs? </a> It may be that dpkg wants external GNU/Linux-specific programs that it can't found or that just don't exist on the Hurd. You can trick dpkg by copying and running this script as root: @@ -21,7 +17,8 @@ You must set up the [[translator/random]] device first. ## <a name="An_X_package_hangs_at_startup_wi"> An X package hangs at startup without error messages </a> -Observed with GTK programs like xchat, synaptic, inkscape. It is an issue with libpthread that (as of 04 Feb 2007) is still unresolved. Sorry. +Observed with GTK programs like xchat, synaptic, inkscape. It is an issue with +[[libpthread]] that (as of 04 Feb 2007) is still unresolved. Sorry. ## <a name="Borked_fonts_on_GTK_app"> </a> Borked fonts on GTK app diff --git a/hurd/running/debian/patch_submission.mdwn b/hurd/running/debian/patch_submission.mdwn index 66348dd9..1dd8a4db 100644 --- a/hurd/running/debian/patch_submission.mdwn +++ b/hurd/running/debian/patch_submission.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] If you fixed a Debian package which *FTBFS* (fails to build from source), you should submit the patch so that all users can profit from your work. @@ -27,14 +28,24 @@ either use the reportbug tool, or just simple mail. In any case, you should follow these guidelines: * The submission address is <submit@bugs.debian.org>. + * The mail's subject (which will become the bug's title) should be `SOURCE-PACKAGE: FTBFS on hurd-i386: REASON`. + * The first lines of the mail's body (the so-called *pseudo-header*): - * `Severity: important` -- not *serious*. - * `Version: VERSION` -- the version of the source package in unstable. - * `Tags: patch` -- as/if you include a ready-to-be-applied patch. - * `User: debian-hurd@lists.debian.org` - * `Usertags: hurd` + + Package: PACKAGE + Severity: important -- not *serious* + Version: VERSION -- the version of the source package in unstable. + Tags: patch -- if you include a ready-to-be-applied patch. + User: debian-hurd@lists.debian.org + Usertags: hurd + X-Debbugs-CC: debian-hurd@lists.debian.org + +The last three lines are used to to change the current *User* to the specified +value (the default is the email sender/from address), specify *Usertags* to add +the specified tags for the current user, and *X-Debbugs-CC* so that the +[[mailing list|mailing_lists/debian-hurd]] knows about your report. In the bug description, mention that the package fails to build on hurd-i386 and (if possible) quote the failure. If possible, point to the failing build diff --git a/hurd/running/debian/porting.mdwn b/hurd/running/debian/porting.mdwn index aa044570..b57b295e 100644 --- a/hurd/running/debian/porting.mdwn +++ b/hurd/running/debian/porting.mdwn @@ -1,23 +1,31 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Debian packages that need porting"]] -Approximately half of the Debian archive has been compiled successfully on the +[[!tag stable_URL]] + +More than half of the Debian archive has been compiled successfully on the Hurd, however, many programs fail to build for various reasons. A [list of build failures including error messages](http://unstable.buildd.net/buildd/hurd-i386_Failed.html) can be found, as well as a [preliminary -analysis](http://lists.debian.org/debian-hurd/2007/07/msg00000.html) of them and [solutions](http://lists.debian.org/debian-hurd/2007/07/msg00001.html), and some more details in [[hurd/porting/guidelines]]. +analysis](http://lists.debian.org/debian-hurd/2007/07/msg00000.html) of them and [solutions](http://lists.debian.org/debian-hurd/2007/07/msg00001.html), and some more details in [[hurd/porting/guidelines]]. [Graphs and statistics](http://people.debian.org/~sthibault/) about the consequence in terms of build dependencies are available. + +There is a mailing list, +[debian-hurd-build-logs](http://lists.alioth.debian.org/mailman/listinfo/debian-hurd-build-logs), +where *builds logs from the Debian GNU/Hurd autobuilders* are posted. It is a +high-traffic and high-volume list, and for that reason *not* archived, so you +have to subscribe to see the messages. It might be a good idea to record your intention to port something either in the list below or in the [Alioth task @@ -36,13 +44,12 @@ guidelines. There is also further information available about [[hurd/porting]]. -[[!map pages="tagged(open_issue_porting) and !tagged(fixed_in_debian) and -!open_issues and !*/discussion" +[[!map +pages="tagged(open_issue_porting) and !tagged(fixed_in_debian) and !*/discussion" show=title]] [[!inline -pages="tagged(open_issue_porting) and !tagged(fixed_in_debian) and -!*/discussion" +pages="tagged(open_issue_porting) and !tagged(fixed_in_debian) and !*/discussion" show=0 feeds=no actions=yes diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn new file mode 100644 index 00000000..de1027b7 --- /dev/null +++ b/hurd/running/debian/qemu_image.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]]."]]"""]] + +There is a QEMU image with [[Debian GNU/Hurd|debian]] pre-installed available +as <http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz>. + +Usage: + + $ wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz + $ tar -xz < debian-hurd.img.tar.gz + $ qemu -m 512 -net nic,model=rtl8139 -net user -drive cache=writeback,index=0,media=disk,file=$(echo debian-hurd-*.img) + +See the discussion about [[hurd/running/qemu/writeback_caching]]. + +Just in case you were wondering: the *root* password is *root*. + +[[!if test="destpage(hurd/running/qemu)" then="" else="For more detailed +instructions, please see the [[hurd/running/QEMU]] page."]] diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index 229e2d8f..befb015d 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -4,6 +4,8 @@ Working distributions of GNU/Hurd: GNU/Hurd distributions in early stages of development: +* [[Arch|arch_hurd]] (features a LiveCD) +* [[Nix]] * [[Gentoo]] * [[GNU]] @@ -14,7 +16,7 @@ GNU/Hurd distributions in early stages of development: # Issues <dt>[[SoftwareLicensing]]</dt> -<dd> The copyright and license information for software that is distributed with the Hurd software is important. Debian has it's DFSG guidelines. Other distributions will need to address these same issues. </dd> +<dd> The copyright and license information for software that is distributed with the Hurd software is important. Debian has its DFSG guidelines. Other distributions will need to address these same issues. </dd> [[GnuDebianRelationship]] @@ -71,7 +73,7 @@ about getting applications to work (if possible). <dl> <dt>[[SavannahProjects]]</dt> - <dd> Savannah is a CVS &amp; Bug system evolved from a free version of the code that powers <a href="http://sf.net" target="_top">sourceforge.net</a>. It has forked and been slightly modified for use by FSF, GNU and non-GNU projects. Actual Development takes place here. There is also a <a href="http://savannah.gnu.org/people/?group=hurd" target="_top">help wanted</a> list. </dd> + <dd> Savannah is a CVS & Bug system evolved from a free version of the code that powers <a href="http://sf.net" target="_top">sourceforge.net</a>. It has forked and been slightly modified for use by FSF, GNU and non-GNU projects. Actual Development takes place here. There is also a <a href="http://savannah.gnu.org/people/?group=hurd" target="_top">help wanted</a> list. </dd> </dl> <dl> @@ -85,8 +87,8 @@ about getting applications to work (if possible). </dl> <dl> - <dt> Debain Infrastructure</dt> - <dd> Testing is critical in helping the development effort. Bugs (defect reports) can be filed against the Debian software package in which they are found. [[debian/patch_submission]] tells how to file a Debian bug report. [[DebianPackages]] has some information about how Debian splits the software into packages and some references. There is a buildd autobuilder compiling the Debian Sid archive software for the GNU/Hurd port. [[BuilddStatus]] includes information on the buildd &amp; turtle efforts. </dd> + <dt> Debian Infrastructure</dt> + <dd> Testing is critical in helping the development effort. Bugs (defect reports) can be filed against the Debian software package in which they are found. [[debian/patch_submission]] tells how to file a Debian bug report. [[DebianPackages]] has some information about how Debian splits the software into packages and some references. There is a buildd autobuilder compiling the Debian Sid archive software for the GNU/Hurd port. [[BuilddStatus]] includes information on the buildd & turtle efforts. </dd> </dl> <dl> diff --git a/hurd/running/faq.mdwn b/hurd/running/faq.mdwn new file mode 100644 index 00000000..2746a20a --- /dev/null +++ b/hurd/running/faq.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="General FAQ About Running GNU/Hurd"]] + +See also other [[/FAQ]]. + +[[!inline +pages="hurd/running/faq/* and !*/discussion" +show=0 +feeds=no +actions=yes +rootpage="hurd/running/faq" postformtext="Add a new item titled:"]] diff --git a/hurd/running/faq/native-install_doesnt_finish.mdwn b/hurd/running/faq/native-install_doesnt_finish.mdwn new file mode 100644 index 00000000..a852e1dd --- /dev/null +++ b/hurd/running/faq/native-install_doesnt_finish.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2009 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]]."]]"""]] + +Copying baseGNU to the virtual disk works. Even booting got through but when I +try to run native-install it never gets to the very end. First time it froze on +*sed* package, the other time on *sysv-rc*. + +> How much memory did you configure for the [[QEMU]] system? It may simply be +> -- I've seen this myself -- that the system runs out of memory, as at the +> native-install stage (I think at least) swap is not yet configured and +> enabled. What I've been doing is: boot (with -s), MAKEDEV hdWHATEVER in +> /dev/ for the swap device, run /hurd/mach-defpager, followed by swapon +> /dev/hdWHATEVER. Does this help? + +>> Thank You very much, more memory solved the freezing. + +[[!tag open_issue_hurd]] diff --git a/hurd/running/gentoo.mdwn b/hurd/running/gentoo.mdwn index 2a979f41..ef72bfad 100644 --- a/hurd/running/gentoo.mdwn +++ b/hurd/running/gentoo.mdwn @@ -2,7 +2,7 @@ Unofficial port to Gentoo and the portage system. It was [announced](http://forums.gentoo.org/viewtopic.php?t=41939&postdays=0&postorder=asc&start=0) -March 17, 2003 in the Gentoo forums. There's a #gentoo-irc channel similar to +March 17, 2003 in the Gentoo forums. There's a #gentoo and a #gentoo-hurd IRC channel similar to [[IRC]]. ### State of the GGH, 2009-05 diff --git a/hurd/running/gnu.mdwn b/hurd/running/gnu.mdwn index 26d93279..94012ef5 100644 --- a/hurd/running/gnu.mdwn +++ b/hurd/running/gnu.mdwn @@ -15,32 +15,32 @@ It is our wish and goal to establish a new direction for the GNU system distribu This is not intended to detract from Debian GNU/Hurd and we should help them where we can. -I really want this to be more of a community driven effort in the spirit of say Ubuntu. We all have different motivations and skill levels but we need a common goal to get this system going. +I really want this to be more of a community driven effort in the spirit of say, Ubuntu. We all have different motivations and skill levels but we need a common goal to get this system going. -These are just some quick notes I am making late at night. Lets clean this up. +These are just some quick notes I am making late at night. Let's clean this up. ## <a name="Motivations"> Motivations </a> 1. There is a possibility that Debian drops support for GNU/Hurd. 2. Other GNU/Linux distributions do not support the Hurd infrastructure well. -3. Benefitting from the Hurd design and using a microkernel. +3. Benefiting from the Hurd design and using a microkernel. 4. Freedom. ## <a name="Community"> Community </a> -1. Lets establish some ground rules. +1. Let's establish some ground rules. 2. We need infrastructure * Wiki for community documentation * Mailing lists like gnu-system-discuss exists for mostly technical items * IRC channels like #hug and ##hurd * Perhaps less formal and less intimidating channels and mailing lists would involve broader parts of the community 3. We need a community vision and direction. - * Lets work together for a common goal - * Lets establish goals and priorities and get resources on them. (More later) + * Let's work together for a common goal + * Let's establish goals and priorities and get resources on them. (More later) * Major goal to create a system making full use of Hurd features? * We should never hesitate to throw away existing stuff whenever it hinders us to make good use of Hurd features * However, we should try to reuse existing stuff (from Debian for example) as long as it doesn't limit our possibilities or impose considerable overhead - * Lets have fun. It's GNU and it's important but let's enjoy ourselves. + * Let's have fun. It's GNU and it's important but let's enjoy ourselves. ## Download diff --git a/hurd/running/gnu/create_an_image.mdwn b/hurd/running/gnu/create_an_image.mdwn index 2cdb8e27..98af99eb 100644 --- a/hurd/running/gnu/create_an_image.mdwn +++ b/hurd/running/gnu/create_an_image.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Creating a bootable qemu image from a root filesystem and bootloader @@ -17,7 +18,7 @@ Creating a bootable qemu image from a root filesystem and bootloader 2. Use a live CD (better to have a lighter OS like system rescue CD to make the process faster) and the image created to boot. - qemu -cdrom /dev/cdrom -hda <imagename.img> -boot d + qemu -m 512 -cdrom /dev/cdrom -drive cache=writeback,index=0,media=disk,file=<imagename.img> -boot d 3. Once system is booted use a partition editing tool (like fdisk, cfdisk, parted, gparted, qtparted ...) to partition the image. @@ -27,7 +28,7 @@ Creating a bootable qemu image from a root filesystem and bootloader create the necessary partitions (root and swap partitions boot, home ... if required) -4. Create a file syatem for the root partiotion +4. Create a file system for the root partition mke2fs /dev/hda1 @@ -39,7 +40,7 @@ Creating a bootable qemu image from a root filesystem and bootloader 6. Copy the file system from the host machine to the mounted directory (use a compressed file system to make the copying faster) - Grab the GNU spapshot from ams' site + Grab the GNU snapshot from ams' site <http://www.update.uu.se/~ams/home/slask/GNU/> scp <user>@<host>:<path to the compressed file system> disk @@ -58,13 +59,13 @@ Creating a bootable qemu image from a root filesystem and bootloader poweroff -10. To make the file syatem bootable download a grub floppy image +10. To make the file system bootable download a grub floppy image <http://hurd.in/pub/Hurd/HurdOnVMware/grub.img> 11. Run qemu to boot into your brand new system - qemu -hda <hard disk image.img> -fda grub.img -boot a + qemu -m 512 -drive cache=writeback,index=0,media=disk,file=<hard disk image.img> -fda grub.img -boot a Happy Hacking !! diff --git a/hurd/running/gnu/discussion.mdwn b/hurd/running/gnu/discussion.mdwn deleted file mode 100644 index 7a96803b..00000000 --- a/hurd/running/gnu/discussion.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -## <a name="GNU_Web_Meta_Discussion"> </a> GNU Web Meta Discussion - -Where did you get that logo? Maybe it's the color but it looks very elegant compared to <http://www.gnu.org> - --- [[Main/GrantBow]] - 23 Oct 2002 - -I did it myself. Somewhat inspired by another GNU artwork, but completely hand made in the Gimp. - -I'm working on a cool Mach logo as well. Inspiration is the old Atari arcade game M.A.C.H. 3. :-) - --- [[Main/JoachimNilsson]] - 29 Oct 2002 - -What do you feel about the new copyright notice at the bottom of this web? - -I'm afraid that I will have to add another page to the edit process to actually enforce this stuff. Perhaps I can combine the old Preview with this copyright assignment, what do you think? - -Oh, btw. It seems RMS is right. At least according to Swedish law (as far as I've checked) transfer/assignment of copyright can be made the way he describes. The user has to select a checkbox or press a button to accept the copyright assignment each time. But as long as that is done we don't have to have any other form of "legal contract" between the users and the FSF. - --- [[Main/JoachimNilsson]] - 29 Oct 2002 diff --git a/hurd/running/gnu/setup.mdwn b/hurd/running/gnu/setup.mdwn index 57a19054..2fb30c7b 100644 --- a/hurd/running/gnu/setup.mdwn +++ b/hurd/running/gnu/setup.mdwn @@ -8,7 +8,7 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -Setup is very easy (You need a GNU/Linux system to install GNU, we are developing an installer for GNU and if you want to help us join us on [[http://lists.gnu.org/mailman/listinfo/gnu-system-discuss][gnu-system-discuss]]), just follow these steps ... +Setup is very easy (You need a GNU/Linux system to install GNU, we are developing an installer for GNU and if you want to help us join us on [gnu-system-discuss](http://lists.gnu.org/mailman/listinfo/gnu-system-discuss)), just follow these steps ... ## Step 1: Find a home for GNU diff --git a/hurd/running/gnu/universal_package_manager.mdwn b/hurd/running/gnu/universal_package_manager.mdwn index ecac8e21..bf1b92e0 100644 --- a/hurd/running/gnu/universal_package_manager.mdwn +++ b/hurd/running/gnu/universal_package_manager.mdwn @@ -20,10 +20,10 @@ Basically all package management schemes follow similar approach, it will have a There can be both aproaches - * Re-implement rpm, dpkg... to recognise stow as backend instead of its own data store. In that case we will have to re implement, apt-rpm, yum ... - * Implement a translator which reads stow and show it as an rpm data store for yum, deb data store for apt-get ... + * Re-implement rpm, dpkg... to recognise stow as backend instead of its own data store. In that case we will have to re-implement, apt-rpm, yum ... + * Implement a translator which reads stow and show it as an rpm data store for yum, deb data store for apt-get ... -One goal is obviously choice of packaging and hence availability of more packages. Also this gives maintainers a chioce to continue builing packages for GNU in the format they are already familiar with. The second goal is to demonstrate the flexibility GNU offers in implementing functionality in filesystems (open/read/write interface). +One goal is obviously choice of packaging and hence availability of more packages. Also this gives maintainers a choice to continue building packages for GNU in the format they are already familiar with. The second goal is to demonstrate the flexibility GNU offers in implementing functionality in filesystems (open/read/write interface). ## Why? @@ -40,7 +40,7 @@ With the increased flexibility in implementing filesystems as per the requiremen ## How? - * Installtion of a package is just drag the pacakage (be it a tgz, rpm, deb or an exe) and drop it to the package manager. + * Installation of a package is just drag the package (be it a tgz, rpm, deb or an exe) and drop it to the package manager. * apt-cache search vim --> ls -al /packages/meta/ |grep vim * apt-get install vim --> install vim @@ -77,12 +77,12 @@ just writing the new translator. ## Initial idea -A bit complex than the earlier scheme but it is more exciting and we can look at this schem seriously once we have the simple scheme working. +A bit more complex than the earlier scheme but it is more exciting and we can look at this scheme seriously once we have the simple scheme working. All packages are installed at `/packages/binary/<packagename>/<packageversion>`. -For eaxmple vim 6.4 version can be installed from source like +For example vim 6.4 version can be installed from source like # cd vim64 # ./configure --prefix=/packages/binary/vim/6.4 @@ -99,7 +99,7 @@ Now if you have another vim version, say 7.0 then just follow the steps # make # make install -You have 2 versions of vim and how can you sepcify which one is the current version? You can symlink the current version to select the version you would like to see as default +You have 2 versions of vim and how can you specify which one is the current version? You can symlink the current version to select the version you would like to see as default # ln -s /packages/binary/vim/7.0 /packages/vim/current @@ -141,7 +141,7 @@ v. Add your name below and give a shout in the list. Add your comments here -## Interesting? +## Interested? To join the project just list your name below. @@ -153,3 +153,6 @@ To join the project just list your name below. 6. Ajish.B 7. Ambili.B 8. Abhradip Mukherjee + 9. Ermenegildo Fiorito + 10. Oltion Doda + 11. Russell James diff --git a/hurd/running/live_cd.mdwn b/hurd/running/live_cd.mdwn index 568b6535..1eb9b8e0 100644 --- a/hurd/running/live_cd.mdwn +++ b/hurd/running/live_cd.mdwn @@ -1,4 +1,6 @@ -You can download a gzipped iso of a Hurd Live CD at +[[Arch Hurd|hurd/running/arch_hurd/]] offers Hurd LiveCDs at <http://www.archhurd.org/gethurd.php>. + +Also you can download a gzipped iso of a Hurd Live CD at <http://www.superunprivileged.org/hurd/live-cd/>. The Superunpriveleged crew also offers a tiny Hurd Live CD that is under 10 @@ -6,13 +8,20 @@ MiB: <http://www.superunprivileged.org/hurd/tiny-cd/> Use it like this: - $ qemu -cdrom hurd-tiny-cd-20060722.iso + $ qemu -m 512 -cdrom hurd-tiny-cd-20060722.iso + +A more recent Live CD can be found at <http://teythoon.cryptobitch.de/hurd/livecd/hurd-live-install-1273300101.iso.xz>. + +It can be run with qemu via + + $ wget http://teythoon.cryptobitch.de/hurd/livecd/hurd-live-install-1273300101.iso.xz + $ xz -d hurd-live-install-1273300101.iso.xz + $ qemu -m 512 -cdrom hurd-live-install-1273300101.iso These [[!wikipedia LiveCD]]s should be useful for those who want to try out the Hurd before they commit to installing it on their hard disks. In addition to that, the bootable Hurd CDs should enable us to have a native installer instead of relying on Linux. - * [[RequirementsForLiveCD]] * [[BuildingHurdLiveCD]] diff --git a/hurd/running/nix.mdwn b/hurd/running/nix.mdwn new file mode 100644 index 00000000..663589f6 --- /dev/null +++ b/hurd/running/nix.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Nix-based GNU/Hurd System"]] + +<http://www.nixos.org/> + + * <http://hydra.nixos.org/jobset/gnu/hurd-master> + + * <http://hydra.nixos.org/job/gnu/hurd-master/qemu_image/latest/download> + + * <http://hydra.nixos.org/job/gnu/hurd-master/qemu_test> + +--- + +This QEMU image is not (yet) comparable to NixOS, because the latter provides +extra features, such as whole-system configuration (including services, etc.), +and whole-system transactional update and rollback. It is is cross-built using +Nix, and because of that, it uses per-package installation directories under +`/nix/store`. diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 48d87b35..512ea602 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -1,54 +1,207 @@ +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 +Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + This page discusses things for [[Unix]] systems, there is a separate page for [[Microsoft_Windows]] systems. +See the discussion about [[hurd/running/qemu/writeback_caching]]. # Readily Available Images -To try out the Hurd you can use the image of the Debian GNU/Hurd: +You can use the following images to give the GNU/Hurd a try. -* [Official Debian GNU/Hurd QEMU image](http://ftp.debian-ports.org/debian-cd/K16/debian-hurd-k16-qemu.img.tar.gz) +## Debian GNU/Hurd -(!) Note that the following are unofficial images: they have been prepared by -volunteers and may not have been tested extensively. +[[!inline pages=hurd/running/debian/qemu_image raw=yes feeds=no]] + +## [[Nix]] + +## Unofficial Images -<!--* [Disk image](http://www.numenor.art.pl/balrog/hurd/) with an installation of - [[Debian_GNU/Hurd|running/debian]].--> +Note that the following images are unofficial ones: they have been prepared by +volunteers and may not have been tested extensively. * [Disk image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) - with a short intro on translators. Just start it with 'qemu *disk_image.img*'. + with a short intro on translators. Just start it with `qemu -m 512 + -drive cache=writeback,index=0,media=disk,file=disk_image.img`. It should work without any of the configuration below. If you want to know what you can do with it, please have a look at [[its_wikipage|hurd/running/qemu/babhurd_image]]. And when you use it, please [tell me your experience with it](http://draketo.de/contact)! - [[community/weblogs/ArneBab]] -<!--* [Announcement](http://lists.debian.org/debian-hurd/2007/09/msg00000.html) of another image. - The link in the email doesn't work anymore, too old. //--> +# Arch Hurd Live CD + +Also you can use QEMU to easily try one of the +[[Hurd_LiveCDs|hurd/running/live_cd/]]. # What is Needed to create a QEMU image +## Debian Installer + +Instructions for creating a qemu image from the install CDs from debian installer can be found in the README alongside the d-i Hurd images: <http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/> + +## Old method + 1. First thing is to install [[/QEMU]]. 2. A [[grub]] boot disk for the floppy disk image needed for booting. The [0\.97 version](ftp://alpha.gnu.org/gnu/grub/grub-0.97-i386-pc.ext2fs) works fine. I downloaded it and renamed to `floppy.img`. Alternatively, the Debian grub-disk package (up till version 0.97-28) is fine as well. 3. You will need a [Debian/Hurd installation CD](http://www.debian.org/ports/hurd/hurd-cd). K16 works fine. +# KVM acceleration + +Check if your CPU supports kvm: + + $ egrep '^flags.*(vmx|svm)' /proc/cpuinfo + +#### If you don't have hardware support (slow): + $ apt-get install qemu + +Do not enable kernel-kqemu, as that assumes some particular behavior from the guest kernel, which we are reluctant to artificially add to gnumach. + +If QEMU with KVM is not available, [[Virtualbox]] reportedly has better +performance. + +#### If you have hardware support (recommended): + $ apt-get install qemu-kvm + $ modprobe kvm + +Intel VTx/VTd: Enable Intel kvm in the BIOS + +On a HP xw4600 Workstation: F10, Security->System Security; Enable VTx and VTd + +Check that the kvm module is loaded: + + $ lsmod|grep kvm + kvm_intel 38050 0 + kvm 213800 1 kvm_intel + + $ ls -l /dev/kvm + crw-rw----+ 1 root kvm 10, 232 Mar 14 15:02 /dev/kvm + +Add yourself to the kvm group: + + $ adduser your_user kvm; logout; login + +AMD SVM (AMD-V): Enable AMD-V in the BIOS if not enabled. + +Check that the kvm module is loaded: + + $ lsmod|grep kvm + kvm_amd 31862 0 + kvm 214088 1 kvm_amd + +More info on kvm at: http://www.linux-kvm.org/page/FAQ + +If your machine supports hardware acceleration, you should really use the kvm variant of qemu, as it speeds things quite a lot. Note however that kvm tends to make assumptions when accelerating things in the linux kernel, you may need some -no-kvm-something option. At the moment in Debian you need to pass + + -no-kvm-irqchip + +to the command line, see below, if you are running Linux kernels 2.6.37 or 2.6.38 else IRQs may hang sooner or later. The kvm irq problems will be solved in kernel 2.6.39. + +/!\ Note that there are known performance issues with KVM on Linux 2.6.39 +kernels, compared to 2.6.32: [[!debbug 634149]]. We're preparing on a change +on our side to work around this. + + +# HAP/EPT/NPT acceleration + +Performance will be yet better if HAP (EPT or NPT) is available: + + $ grep ept /proc/cpuinfo + $ grep npt /proc/cpuinfo + +# Installing Debian/Hurd with QEMU using the Debian installer + +Note: If you have hardware support, replace the qemu commands below with kvm, e.g. qemu-ing -> kvm-img. -# Installing Debian/Hurd with QEMU +First off you will need to create a disk image using `qemu-img`. I have set mine to 4 GiB, although you should be able to get away with less. -First off you will need to create a disk image using `qemu-img`. I have set mine to 2 gigabytes, although you should be able to get away with less(Currently, the maximum disk image size one can create with QEMU is 4.5G). + $ qemu-img create hd0.img 4G - $ qemu-img create hd0.img 2G +Next you will want to start up QEMU and begin the installation process. -Next you will want to start up QEMU and begin the installation process. The first time you run it you will want to use the `-boot d` option to boot off the cdrom. + $ qemu -m 512 -drive cache=writeback,index=0,media=disk,file=hd0.img -cdrom mini.iso -net nic,model=rtl8139 -net user - $ qemu -hda hd0.img -cdrom debian-K16-hurd-i386-CD1.iso -fda floppy.img -boot d +Now at his point do the regular install using `hd0` as your harddrive. Partition it and install the base system. -Now at his point do the regular install using `hd0` as your harddrive. Partition it and install the base system. Once you have finished installing the base system select the reboot option as this will ensure the disk is properly un-mounted. When the Debian CD menu comes up again simply close QEMU. +In the installer make your choice of install option: Default install (or your choice) -Now run your image with floppy booting (`-boot a`) and finish the install (`./native-install` .. etc). + Language: English + Country, territory or area: your_choice + Locale: your_choice -**Important:** Older versions on gnumach needed that the `-M isapc` was passed to qemu. This is not needed anymore. +Note that even if you can set the country and locale, your local keyboard is not yet supported. + +In case of problems with timezone or locale settings do the following after the installation is completed + + To get the correct timezone: + $ dpkg-reconfigure tzdata + To get your locale setting: + $ nano /etc/locale.gen + $ locale-gen + +Network: Now configured automatically with dhcp + + IP address: 10.0.2.15 + Netmask: 255.255.0.0 + Gateway: 10.0.2.2 + Nameserver: 10.0.2.3 + + Qemu network setup: + QEMU VLAN <------> Firewall/DHCP server <-----> Internet + | (10.0.2.2) + | + ----> DNS server (10.0.2.3) + | + ----> SMB server (10.0.2.4) + +Partitioning method: Guided (or your choice) + +Partitioning `/dev/hd0`: All files in one partition. + +**Important**: Since partman does not yet mount other partitions than / automatically at reboot, it is crucial that you choose this option for now. + +Once you have finished installing the base system (might take some time) the system is rebooted and next boot will be from the hard disk. Now you are able to log in to your newly installed GNU/Hurd system. Also see another text about how to [[gnu/create_an_image]] for the [[GNU_system|gnu]]. +## Running the installed system + +Starting qemu/qemu-kvm: + + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,index=0,media=disk,file=hd0.img -vga vmware + vmsvga_value_write: guest runs Linux. + +Note: See below on port forwarding in the networking section. + +Note: Using the vmware vga driver is useful for setting up X windows, see [Debian GNU/Hurd](http://www.debian.org/ports/hurd/hurd-install) + +If you have problems with grub hanging during boot with the vmware vga driver: Disable the graphic boot + + $ nano /etc/default/grub + uncomment GRUB_TERMINAL=console + $ /usr/sbin/update-grub + +### A few words about the qemu console + +During the graphical emulation, you can use the following keys: + + <Ctrl><Alt>-f Toggle full screen + <Ctrl><Alt>-u Restore the screen's un-scaled dimensions + <Ctrl><Alt>-n Switch to virtual console 'n'. Standard console mappings are: + 1 Target system display + 2 Monitor + 3 Serial port + <Ctrl><Alt> Toggle mouse and keyboard grab. + # Transferring Files @@ -65,13 +218,13 @@ You may wish to mount your disk image on your host system to transfer files. To hd0.img1 * 63 3515903 1757920+ 83 Linux hd0.img2 3515904 4193279 338688 82 Linux swap / Solaris -Now take the number of sectors for the beginning of the partition and multiply it by the sector size. My partition starts at sector 63 and I have a sector size of 512 therefor my offset is 32256. +Now take the number of sectors for the beginning of the partition and multiply it by the sector size. My partition starts at sector 63 and I have a sector size of 512 therefore my offset is 32256. For a start at 2048 the ofsset is 1048576. # mount -o loop,offset=32256 hd0.img /mnt/diskimage ## Having QEMU create *virtual FAT disk images* -[Manual](http://www.nongnu.org/qemu/qemu-doc.html#SEC25). +[Link to the manual](http://www.nongnu.org/qemu/qemu-doc.html#SEC25). QEMU has a facility to create FAT file systems on-the-fly: @@ -97,12 +250,55 @@ If you just want to access the internet from within QEMU, you can setup pfinet f # settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0 # echo "nameserver 10.0.2.3" > /etc/resolv.conf +If you are on [[Debian GNU/Hurd|debian]], you can even use [[debian/DHCP]]. + +To get ssh working: + + # apt-get install random-egd openssh-server (Similarly for telnet if preferred) + (See also <http://www.nongnu.org/qemu/qemu-doc.html#SEC32>.) Outgoing internet connections should just work then. +Testing it can be difficult with a minimal installation, +but `apt-get update` should work after you have filled out +`/etc/apt/sources.list`. +After that you should be able to install other network packages, +but note that `ping` doesn't work with QEMU's user-networking stack. + +If you want to connect from the host system to the Hurd system running in QEMU, you can use port forwarding in QEMU or to setup something more advanced, like bridged networking. + +## Port Forwarding in QEMU +(In the following we assume we use kvm!) + +#### Logging in to Hurd from a terminal in your host system +This is the recommended way to work with a Command Line Interface (CLI) since all your keyboard and locale settings are preserved. + +a) with ssh (assuming you have installed openssh-server) + + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,index=0,media=disk,file=hd0.img & + +Logging in to the running Hurd: -If you want to connect from the host system to the Hurd system running in QEMU, you need to setup something more advanced, like bridged networking. + $ ssh -p5555 localhost +Copying files: + + 1) On your host + To Hurd: scp -p -P5555 file localhost: + From Hurd: scp -p -P5555 localhost:file . + 2) On Hurd + To host: scp -p file {10.0.2.2,your_host_ip}: . + From host: scp -p {10.0.2.2,your_host_ip}:file . + +b) with telnet (assuming you have installed a telnet server, like telnetd) + + $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -drive cache=writeback,index=0,media=disk,file=hurd-install.qemu & + +Logging in to the running Hurd: + + $ telnet localhost 5556 + +c) With the tap interface, see below. ## Bridged Networking @@ -137,7 +333,7 @@ Now it is time to start-up your QEMU Hurd system and get networking going in the **Important:** Remember you may need to use the `-M isapc` or `-isa` flag if using an older version of the gnumach package. - $ qemu -hda hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap + $ qemu -m 512 -drive cache=writeback,index=0,media=disk,file=hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap Once you have logged in as `root` run the `pfinet` translator with values that apply to your network. Think of your QEMU client as another computer in your network. @@ -156,31 +352,3 @@ system after installation. [[Image_for_L4]] -- a QEMU image for the Hurd/L4 project. <http://eyeside.net/hurd/Hurd-on-QEMU.html> - - -# TODO - -[[IRC]], #hurd, 2007-07-04. - - <azeem-uni> so, is there a way to use a Debian GNU/Hurd partition (/dev/hda6) with qemu directly? - <tschwinge> Don't dare to do that, please. - <tschwinge> It will lead to inconsistencies. - <tschwinge> Because the Linux kernel thinks that it has complete control over the disk, or something. - <tschwinge> In theory you could run something like ``-hda /dev/hda'', having GRUB installed on there to offer you to boot your Hurd system from hda6 and that will even work, but then don't get the idea to stop qemu, mount that partition on your Linux system and restart qemu. That's where I got lots of inconsistencies then, afterwards. - <azeem-uni> it's probably the same problem as having that partition mounted, suspending to disk, booting into it in the Hurd, and resume Linux - <neal> right - <tschwinge> That's a different problem. - <tschwinge> Then the partitoon is still mounted. - <neal> no, I think it is basically the same problem - <tschwinge> The file system stuff is cached in the kernel. - <neal> you have data that has not been written to disk yet - <tschwinge> Right. - <neal> and neither is prepared for the resource to be shared - <tschwinge> In the azeem-uni scenarion the data is on the file system layer and in my scenarion it's some disk block caching inside the Linux kernel, I guess. - <azeem-uni> anyway, do you guys think if I use -hda /dev/hda and tell Grub to boot off /dev/hda6, that the rest of hda should be fine, right? - <azeem-uni> maybe adding -snapshot makes it totally safe - <neal> azeem: Should be fine. - <tschwinge> Yes. - -The problem is actually that the linux block cache doesn't make any consistency between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6 directly to qemu and it will be fine. - diff --git a/hurd/running/qemu/babhurd_image.mdwn b/hurd/running/qemu/babhurd_image.mdwn index c0952fcf..6a3bb30e 100644 --- a/hurd/running/qemu/babhurd_image.mdwn +++ b/hurd/running/qemu/babhurd_image.mdwn @@ -5,8 +5,9 @@ What this little Hurd image can do This is the README file accompanying a [disk\_image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) for -[[running_the_GNU/Hurd_via_qemu|hurd/running/qemu]]. To run the disk image, just use *'qemu -disk_image.img'*. +[[running the GNU/Hurd via qemu|hurd/running/qemu]]. To run the disk image, +just use `qemu -m 512 -drive +cache=writeback,index=0,media=disk,file=disk_image.img`. You can find the custom *.bashrc* used to tell the user about it as well as this text itself in the Mercurial repository [hurd_intro](http://bitbucket.org/ArneBab/hurd_intro). diff --git a/hurd/running/qemu/discussion.mdwn b/hurd/running/qemu/discussion.mdwn new file mode 100644 index 00000000..facb8a31 --- /dev/null +++ b/hurd/running/qemu/discussion.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 +Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +# Using Partitions + +[[IRC]], #hurd, 2007-07-04. + + <azeem-uni> so, is there a way to use a Debian GNU/Hurd partition + (/dev/hda6) with qemu directly? + <tschwinge> Don't dare to do that, please. + <tschwinge> It will lead to inconsistencies. + <tschwinge> Because the Linux kernel thinks that it has complete control + over the disk, or something. + <tschwinge> In theory you could run something like ``-hda /dev/hda'', + having GRUB installed on there to offer you to boot your Hurd system from + hda6 and that will even work, but then don't get the idea to stop qemu, + mount that partition on your Linux system and restart qemu. That's where + I got lots of inconsistencies then, afterwards. + <azeem-uni> it's probably the same problem as having that partition + mounted, suspending to disk, booting into it in the Hurd, and resume + Linux + <neal> right + <tschwinge> That's a different problem. + <tschwinge> Then the partitoon is still mounted. + <neal> no, I think it is basically the same problem + <tschwinge> The file system stuff is cached in the kernel. + <neal> you have data that has not been written to disk yet + <tschwinge> Right. + <neal> and neither is prepared for the resource to be shared + <tschwinge> In the azeem-uni scenarion the data is on the file system layer + and in my scenarion it's some disk block caching inside the Linux kernel, + I guess. + <azeem-uni> anyway, do you guys think if I use -hda /dev/hda and tell Grub + to boot off /dev/hda6, that the rest of hda should be fine, right? + <azeem-uni> maybe adding -snapshot makes it totally safe + <neal> azeem: Should be fine. + <tschwinge> Yes. + +The problem is actually that the linux block cache doesn't make any consistency +between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings +won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6 +directly to qemu and it will be fine. diff --git a/hurd/running/qemu/microsoft_windows.mdwn b/hurd/running/qemu/microsoft_windows.mdwn index 832b4bef..e2c8636c 100644 --- a/hurd/running/qemu/microsoft_windows.mdwn +++ b/hurd/running/qemu/microsoft_windows.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2012 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Welcome, This document is for getting you started in a few minutes. @@ -46,7 +47,5 @@ Welcome, This document is for getting you started in a few minutes. ## QEmu Image Hangs on Boot The Debian GNU/Hurd K16 QEmu image hangs during the boot process. You may have better luck by converting the image to qcow format - ..\qemu-0.9.0-x86\qemu-img.exe convert debian-hurd-k16-qemu.img -O - qcow debian-hurd-k16-qemu.qcow - ..\qemu-0.9.0-x86\qemu.exe -L ..\qemu-0.9.0-x86 -m 512 -hda - debian-hurd-k16-qemu.qcow -localtime -M pc + ..\qemu-0.9.0-x86\qemu-img.exe convert debian-hurd-k16-qemu.img -O qcow debian-hurd-k16-qemu.qcow + ..\qemu-0.9.0-x86\qemu.exe -L ..\qemu-0.9.0-x86 -m 512 -drive cache=writeback,index=0,media=disk,file=debian-hurd-k16-qemu.qcow -localtime -M pc diff --git a/hurd/running/qemu/networking.mdwn b/hurd/running/qemu/networking.mdwn index 71daa576..2bc9b16d 100644 --- a/hurd/running/qemu/networking.mdwn +++ b/hurd/running/qemu/networking.mdwn @@ -20,7 +20,7 @@ Netmask is 255.255.255.0 You can setup the pfinet translator with the command - $ settrans -fgap /servers/socket/2 /hurd/pfinet -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0 + $ settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0 Configure nameserver in /etc/resolve.conf diff --git a/hurd/running/qemu/writeback_caching.mdwn b/hurd/running/qemu/writeback_caching.mdwn new file mode 100644 index 00000000..c9c53e3e --- /dev/null +++ b/hurd/running/qemu/writeback_caching.mdwn @@ -0,0 +1,90 @@ +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 +Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Host-side Writeback Caching"]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2011-06-07 + + <braunr> hm, i guess i should have used cache=writeback with kvm before + starting the debian installer :/ + <braunr> ah yes, much better + <braunr> this shows how poor the state of our I/O drivers and subsystem is + :/ + <antrik> indeed... still no clustered pageout :-( + <braunr> and no I/O scheduler either + <braunr> although an I/O scheduler has limited value without clustered + pageouts + <braunr> since one of its goals is to pack related I/O requests together eh + <braunr> i wonder if the wiki mentions using cache=writeback to speed up + qemu performances + <braunr> it would help those unable to use kvm a lot + <braunr> and even those running kvm too + <braunr> kvm -m $RAM \ -monitor stdio \ -drive + cache=writeback,index=0,media=disk,file=hd0.img \ + <braunr> etc.. + <braunr> the idea is that qemu doesn't open its disk file synchronously + <braunr> changes are queued in the host page cache before being flushed to + the disk image + <braunr> but if you brutally close your qemu instance, you're likely to + loose file system consistency + <braunr> ext2fs will think it has committed its metadata to the disk, but + the disk image won't be updated synchronously + <braunr> on my machine (which is quite fast), my kvm has installed debian + like 10 times faster than without the option + <antrik> braunr: I don't think killing qemu should hurt in this + case... probably only matters when the host machine dies + <braunr> antrik: ah yes, right + <braunr> it really makes everything faster, even downloading, since I/O + requests aren't interleaved between networking RPCs + <antrik> regarding I/O sheduler... this discussion came up before, but I + don't remember the outcome -- doesn't the glued Linux driver actually + come with one? + <braunr> i don't remember either + <antrik> braunr: err... I don't think interleaving has anything to do with + it... I guess it's simply the fact that downloading writes the result to + disk, which suffers from lacking clustered pageout like everything else + <antrik> (my internet connection is too slow though to notice :-) ) + <braunr> well, if there is no I/O during downloading, downloading is faster + :) + +IRC, freenode, #hurd, 2011-06-08 + + <braunr> youpi: does xen provide disk caching options ? + <youpi> through a blktap, probably + <braunr> ok + +([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.) + + <braunr> we should find the pages mentioning qemu on the wiki and add the + options to enable disk image caching + <braunr> it really makes the hurd run a lot faster + <braunr> as a workaround for emulators until I/O is reworked, ofc + +IRC, freenode, #hurd, 2011-06-09 + + <gnu_srs> braunr recommends to use writeback caching with kvm. Is this + really recommended with the frequent crashes I experience? + <youpi> provided that you terminate your kvm normaly (i.e. quitting it, not + killing it), there should be no difference + <jkoenig> I think the host's stability is what matters + <jkoenig> the data presumably sits in linux's cache even if qemu dies + violently + <gnu_srs> But the freezes I see force me to kill kvm :-( + <youpi> maybe kvm doesn't even do caching indeed, I don't know + <youpi> gnu_srs: you can quit even when frozen + <youpi> use the console + <youpi> (the kvm console) + <jkoenig> gnu_srs, "Writeback caching will report data writes as completed + as soon as the data is present in the host page cache. This is safe as + long as you trust your host. If your host crashes or loses power, then + the guest may experience data corruption." (from the qemu manpage) diff --git a/hurd/running/virtualbox.mdwn b/hurd/running/virtualbox.mdwn new file mode 100644 index 00000000..f57fcbc3 --- /dev/null +++ b/hurd/running/virtualbox.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]]."]]"""]] + +[[!meta title="VirtualBox"]] + +<http://www.virtualbox.org/> + + +# Installation + +The disk controller has to be configured as IDE. Neither SATA nor SCSI are +supported. + +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/settrans/discussion.mdwn b/hurd/settrans/discussion.mdwn new file mode 100644 index 00000000..c9ec4d34 --- /dev/null +++ b/hurd/settrans/discussion.mdwn @@ -0,0 +1,18 @@ +[[!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 open_issue_hurd]] + + +# IRC, freenode, #hurd, 2011-06-01 + + <antrik> ugh... I just realized why settrans -a without -f doesn't + generally work on filesystem translators + <antrik> obviously, it needs -R too! diff --git a/hurd/status.mdwn b/hurd/status.mdwn index 9b43ef35..e6545b27 100644 --- a/hurd/status.mdwn +++ b/hurd/status.mdwn @@ -1,53 +1,63 @@ -[[!meta copyright="Copyright © 2001, 2002, 2007, 2008, 2009 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2007, 2008, 2009, 2010, 2011, 2012 +Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag stable_URL]] The Hurd, together with the GNU Mach microkernel, the GNU C Library and the other GNU and non-GNU programs in the GNU system, provide a rather complete and usable operating system today. It may not be ready -for production use, as there are still many bugs and missing features. +for production use, as there are still some bugs and missing features. However, it should be a good base for further development and non-critical application usage. -The GNU system (also called GNU/Hurd) is completely self-contained +[[!img hurd-fvwm-screenshot-2009-11-12.png size=300x +alt="FVWM and Gnumeric running on GNU/Hurd" +title="FVWM and Gnumeric running on GNU/Hurd" +align="right" +]] The GNU system (also called GNU/Hurd) is completely self-contained (you can compile all parts of it using GNU itself). You can run several instances of the Hurd in parallel, and debug even critical servers in one Hurd instance with gdb running on another Hurd -instance. You can run the X window system, applications that use it, -and advanced server applications like the Apache webserver. +instance. You can run the X window system, applications that use it such as +gnumeric, iceweasel, and advanced server applications like the Apache webserver. On the negative side, the support for character devices (like sound -cards) and other hardware is mostly missing. Although the POSIX -interface is provided, some additional interfaces like POSIX shared +cards) and other hardware is mostly missing. Although the [[POSIX +interface|faq/posix_compatibility]] is provided, some additional interfaces +like POSIX shared memory or semaphores are still under development. All this applies to the current development version, and not to the last release (0.2). We encourage everybody who is interested to try -out the latest development version, and send feedback to the Hurd +out the current development version, and send feedback to the Hurd developers. +The Hurd team doesn't create Hurd-only releases, but instead relies on +the distributions done by folks from *Debian*, *Arch* (since 2010), and *Nix* +(since 2012). -The Hurd team doesn't create Hurd-only releases, but instead relies -on a distribution done by folks from *Debian*. - -That Debian version closely tracks the progress of the Hurd -(and often includes many new features), -so little would be gained by creating an official pure Hurd release. - -The Debian GNU/Hurd [[distribution|running/debian]] offers *LiveCDs and QEMU images* -to test-drive the Hurd in a real life system with access to about -50% of the Debian software archive. +[[!img hurd-iceweasel-screenshot-2012-03-21.png size=300x +alt="Iceweasel running on GNU/Hurd" +title="Iceweasel running on GNU/Hurd" +align="right" +]] +[[Debian GNU/Hurd|running/debian]] closely tracks the progress of the Hurd (and +often includes new features). They offer *LiveCDs and QEMU images* to +test-drive the Hurd, and about 75% of the Debian software archive are +available. The most recent version of the Debian GNU/Hurd port at the time of +writing was published on 2012 February 21st. -The most recent version of the Debian port at the time of writing -is *Debian GNU/Hurd K16*. +[[hurd/running/Arch_Hurd]] offers *LiveCDs* for testing and installation. +[[hurd/running/Nix]] provides QEMU images. That said, the last official release of the Hurd without the Debian parts was 0.2 done in 1997. diff --git a/hurd/status/hurd-fvwm-screenshot-2009-11-12.png b/hurd/status/hurd-fvwm-screenshot-2009-11-12.png Binary files differnew file mode 100644 index 00000000..445abf32 --- /dev/null +++ b/hurd/status/hurd-fvwm-screenshot-2009-11-12.png diff --git a/hurd/status/hurd-iceweasel-screenshot-2012-03-21.png b/hurd/status/hurd-iceweasel-screenshot-2012-03-21.png Binary files differnew file mode 100644 index 00000000..7dcc6d59 --- /dev/null +++ b/hurd/status/hurd-iceweasel-screenshot-2012-03-21.png diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index 5b132604..f2117ead 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] A sub-Hurd is like a [[neighbor_Hurd|neighborhurd]], however, makes use of some resources provided by another Hurd. For instance, backing store and the @@ -17,7 +18,10 @@ attach to them with gdb from the parent ([[debugging_via_subhurds|debugging/subhurd]]). This avoids deadlock, e.g., when the instance of gdb stops the server but requires its use. (Note: it is possible to use [[debugging/gdb/noninvasive_debugging]], but this is less -flexible.) +flexible.) Vice versa, it is also possible to use a subhurd to debug the +*main* Hurd system, for example, the latter's root file system. + +[[!toc levels=2]] # Howto @@ -27,7 +31,7 @@ flexible.) To run a subhurd, you need an additional partition with an installed Hurd system. In principle, you can also use your main partition in read-only mode; but this obviously will create severe limitations. Usually, you will want a -complete independant system. +complete independent system. The system for the subhurd is a normal Hurd installation, which could just as well run standalone. You can use any of the various possible installation @@ -105,9 +109,9 @@ inside the subhurd, or to `ssh` directly into the subhurd. If you want to access the subhurd processes from the outside, e.g. for [[debugging_purposes|debugging/subhurd]] (or to get rid of a subhurd that -didn't exit cleanly...), you need to find out how main Hurd PIDs correspond to +didn't exit cleanly...), you need to find out how main Hurd [[PID]]s correspond to subhurd processes: the subhurd processes appear in the main Hurd (e.g. if doing -`ps -e`) as unknown processes, and vice versa, but the PIDs are different! To +`ps -e`) as unknown processes, and vice versa, but the [[PID]]s are different! To find out which process is which, you can simply compare the order -- while the numbers are different, the order should usually match. Often it also helps to look at the number of threads (e.g. using `ps -l`), as many servers have very @@ -119,3 +123,65 @@ characteristic thread counts. Read about using a subhurd for [[debugging_purposes|debugging/subhurd]]. Roland's tutorial about [[running_a_subhurd]]. + + +# Use Cases + +<a name="debugging_main_hurd_system"></a> +## Debugging the *Main* Hurd System + +A subhurd can be used for debugging the *main* Hurd system. This works as long +as the subhurd doesn't use any services provided by the main Hurd. For +example, if you already have a subhurd running at the time it happens, you can +use that one to debug a deadlocked [[translator/ext2fs]] root file system in +the *main* Hurd. + +For this, you need to get a handle to the main Hurd's [[ext2fs +translator|translator/ext2fs]]'s [[PID]], but this is no problem, as currently +[[PID]]s are visible across subhurd boundaries. (It is a [[!taglink +open_issue_hurd]] whether this is the right thing to do in +[[open_issues/virtualization]] contexts, but that's how it currently is.) + + +<a name="unit_testing"></a> +## Unit Testing + +freenode, #hurd channel, 2011-03-06: + +From [[open_issues/unit_testing]]. + + <youpi> it could be interesting to have scripts that automatically start a + sub-hurd to do the tests + <youpi> though that'd catch sub-hurd issues :) + <foocraft> so a sub-hurd is a hurd that I can run on something that I know + works(like linux)? + <foocraft> Virtual machine I would think + <foocraft> and over a network connection it would submit results back to + the host :p + * foocraft brain damage + <youpi> sub-hurd is a bit like chroot + <youpi> except that it's more complete + <foocraft> oh okay + <youpi> i.e. almost everything gets replaced with what you want, except the + micro-kernel + <youpi> that way you can even test the exec server for instance, without + risks of damaging the host OS + <foocraft> and we know the micro-kernel works correctly, right youpi? + <youpi> well, at least it's small enough that most bugs are not there + <foocraft> 1) all tests run in subhurd 2) output results in a place in the + subhurd 3) tester in the host checks the result and pretty-prints it 4) + rinse & repeat + <youpi> the output can actually be redirected iirc + <youpi> since you give the sub-hurd a "console" + <foocraft> youpi, yup yeah, so now it's more like chroot if that's the case + <youpi> it really looks like chroot, yes + <foocraft> but again, there's this subset of tests that we need to have + that ensures that even the tester running on the subhurd is valid, and it + didn't break because of a bug in the subhurd + <tschwinge> As long as you do in-system testing, you'll always (have to) + rely on some functionality provided by the host system. + <foocraft> the worst thing that could happen with unit testing is false + results that lead someone to try to fix something that isn't broken :p + <tschwinge> Yes. + <youpi> usually one tries to repeat the test by hand in a normal + environment diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn new file mode 100644 index 00000000..3449edcd --- /dev/null +++ b/hurd/subhurd/discussion.mdwn @@ -0,0 +1,69 @@ +[[!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-08-10 + + < braunr> youpi: aren't sub-hurds actually called "neighbor hurds" ? + < youpi> no idea + < braunr> i also don't understand the recursive property + < youpi> a user can run a subhurd + < neal> braunr: What don't you understand? + < youpi> a user in a subhurd can run a subhurd + < youpi> etc + < braunr> i'm not sure it's really recursive + < neal> youpi: At some point it was observed that you don't strictly + require any resources from the "parent" Hurd. + < neal> youpi: i.e., you could have two Hurds running "directly" on Mach + < youpi> sure + < neal> youpi: Hence neighbor rather than sub + < youpi> but you need to be root for that + < youpi> or else your subhurd can't do much + < neal> you need to have been authorized to use the required resouces + < youpi> which is about the same :) + < neal> depends how they are delegated + < youpi> that's still asking root for something + < neal> if you say so + < youpi> which is most probably not the default + < braunr> well, either you depend on the parent to do things on your + behalf, or you directly have some privileged ports + < braunr> i'd agree with youpi that it's pretty much having root access at + some point + < youpi> and usually you don't have privileged ports by default :) + < braunr> but we don't need to restrict the presentation to user only sub + hurds + < braunr> people don't mind switching to root on their desktops + < braunr> which is one of the reasons they ask "what does the hurd really + bring me today ?" + < braunr> but being able to run truely separate hurds or recursive hurds is + something nice most OSes can't do easily + < youpi> switching to root becomes a *pain* when you have to do it 1 every + two commands + < braunr> yes sure, but some people might just say you're clumsy :x + < neal> The question is: can I start a sub-hurd from within another hurd + that survives the parent's hurd exiting? The answer is yes. The reason + is that the sub-hurd can be constructed in such a way that it does not + rely on the parent. In this case, the parent does not necessarily + subjugate the sub-hurd. Hence the name. + < braunr> but that's out of the scope of the discussion + < antrik> using the traditional, root only mechanism, neighbour-hurd is + indeed a more appropriate term. apart from the initial terminal being + proxied to the parent system by the boot program, they are really equal + < antrik> with zhengda's work on non-root subhurds, you rely on various + proxies in the parent system to access privileged resources; so subhurd + is indeed a more appropriate term in this case + < antrik> (not only non-root subhurds in fact... when using any of the + proxies, such as the network multiplexer -- even if still running as + root...) + < youpi> antrik: you could still give a com0 port as terminal + < antrik> I don't think that's actually supported in the boot + program... but it doesn't really matter, as you don't really need the + terminal anyways -- you can always log in through the network diff --git a/hurd/syncfs.mdwn b/hurd/syncfs.mdwn new file mode 100644 index 00000000..9f329b4b --- /dev/null +++ b/hurd/syncfs.mdwn @@ -0,0 +1,17 @@ +[[!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 +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]]."]]"""]] + +`syncfs` is a tiny wrapper around the [[`file_syncfs` +RPC|interface/file_syncfs]]. + +Its functionality should me merged into GNU coreutils' `sync` program, see +[[!GNU_Savannah_task 6614]][[!tag open_issue_hurd open_issue_porting]]. + +There is a [[!FF_project 270]][[!tag bounty]] on this task. diff --git a/hurd/toolchain.mdwn b/hurd/toolchain.mdwn index 8b852089..91d49b2c 100644 --- a/hurd/toolchain.mdwn +++ b/hurd/toolchain.mdwn @@ -1,18 +1,11 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -* [[binutils]] -* [[GCC]] -* [[glibc]] - -Before beginning to work on the inner parts of the GNU/Hurd toolchain, it's -always profitable to also know how things are done on other systems. Compare, -for example, how things are done differently for GNU/Hurd than they are done -for GNU/Linux. +[[!meta redir=/toolchain]] diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index 5c14cfa9..d504b41f 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -1,13 +1,20 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag stable_URL]] + +[[!toc]] + + +# General Information A translator is simply a normal program acting as an object server and participating in the Hurd's @@ -18,6 +25,12 @@ and [[pfinet]]) and thus translates object invocations into calls appropriate for the backing store (e.g., ext2 file system, nfs server, etc.). +Another way of putting it is that it translates from one representation of a +data structure into another representation, for example from the on-disk +[[ext2|ext2fs]] data layout to a traditional file system hierarchy, or from a +XML file to a virtual hierarchical manifestation. This translation can be a +bidirectional process, but it need not be. + A translator is usually registered with a specific file system node by using the [[`settrans`|settrans]] command. @@ -33,6 +46,17 @@ kernel and thus have absolute access to the machine. As the protocols do not require any special privilege to implement, this is not an issue on the Hurd. +In Mach parlance, a *translator* is what they name a *server*: a process that +participates in [[RPC]] interactions. In the Hurd, a translator is a server +that is additionally attached to a filesystem node. Thus, it is quite common, +even in the Hurd context, to speak about *server*s if you're stressing the RPC +part, and on the other hand about *translator*s if you're stressing the +filesystem part: a translator implements the [[interface/fs]] and +[[interface/io]] interfaces. For example: *the [[pfinet]] server implements +the socket API calls (which are mapped by [[glibc]] to equivalent RPC calls)*, +compared to *a [[libdiskfs]]-based translator implements a filesystem, based on +a backing store*. + To learn how to write a translator, read the code! It is well documented, in particular, the header files. The [[Hurd_Hacking_Guide]] also has a tutorial. @@ -41,15 +65,25 @@ Also there is an [[writing/example]] about how to write a simple translator. See some [[examples]] about how to use translators. +There is a [[documentation/translator_primer]]. + Marcus Brinkmann has written a document about [[documentation/translators]]. Here are some [[hints_about_debugging_translators|debugging/translator]] available. +Read about translator [[short-circuiting]]. + +The [[concept|concepts]] of translators creates its own problems, too: +[[open_issues/translators_set_up_by_untrusted_users]], and +[[open_issues/trust_the_behavior_of_translators]]. + # Existing Translators +* [[hello]] * [[auth]] +* [[exec]] * [[pfinet]] * [[pflocal]] * [[hostmux]] @@ -57,9 +91,8 @@ available. * [[ext2fs]] * [[fatfs]] * [[magic]] -* [[mboxfs]] * [[unionfs]] -* [[xmlfs]] +* [[nfs]] * ... @@ -70,11 +103,63 @@ available. * [[cvsfs]] * [[tmpfs]] * [[procfs]] -* [[unionmount]] +* [[nsmux]] +* [[netio]] +* [[tarfs]] +* [[gopherfs]] * ... +# Translators (only) in Hurdextras + +*These Translators are available in the [hurdextras repository](http://savannah.nongnu.org/cvs/?group=hurdextras) but not yet described on this website. They are in varying stages of Development.* + +* [jfs](http://www.nongnu.org/hurdextras/#jfs) +* [httpfs](http://www.nongnu.org/hurdextras/#httpfs) +* [gopherfs](http://www.nongnu.org/hurdextras/#cvsfs) +* [memfs](http://www.nongnu.org/hurdextras/#gopherfs) +* [notice](http://www.nongnu.org/hurdextras/#notice) +* [pith](http://www.nongnu.org/hurdextras/#pith) +* [pptop](http://www.nongnu.org/hurdextras/#pptop) +* [run](http://www.nongnu.org/hurdextras/#run) +* [smbfs](http://www.nongnu.org/hurdextras/#smbfs) +* [xmlfs](http://www.nongnu.org/hurdextras/#xmlfs) +* [mboxfs](http://www.nongnu.org/hurdextras/#mboxfs) + # Translator Wishlists * [[wishlist_1]] * [[wishlist_2]] + * [[open_issues/network_file_system_by_just_forwarding_RPCs]] + * [[libguestfs]] + + +# Internally + +## `*_demuxer` Functions + + * IRC, unknown channel, unknown date + + <jim-crow> what is a main idea of _demuxer functions in translators? + <neal> jim-crow: Think of a web server. + <neal> jim-crow: A typical web server must process many different requests. + <neal> jim-crow: There are different types of requests. + <neal> jim-crow: For instance, static pages and dynamically gnereated content. + <neal> the static pages are processed by one function + <neal> and the dynamic pages by another + <neal> the thing that makes the decision which of these functions to pass the request to is the demuxer. + <jim-crow> neal: ok, I see + <jim-crow> but what is actually it doing in trivfs_demuxer? + <neal> it looks at the message id and calls the right server stub + <jim-crow> for example it calls trivfs_io_server function, but I can't find its implementation + <jim-crow> that's my main question :-) + <neal> look at the files mig generates + <jim-crow> neal: ok, thanks + <jim-crow> neal: is this functions where actually stubs are called? + <neal> I think so. + + +# Bounties + +There is a [[!FF_project 280]][[!tag bounty]] on some translator improvement +tasks. diff --git a/hurd/translator/devfs.mdwn b/hurd/translator/devfs.mdwn index 27df23aa..a9cc307f 100644 --- a/hurd/translator/devfs.mdwn +++ b/hurd/translator/devfs.mdwn @@ -1,20 +1,73 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] `devfs` is a translator sitting on `/dev` and providing what is to be provided in there in a dynamic fashion -- as compared to static passive translator settings as they're used now. -`devfs` has not yet been written. +`devfs` has not yet been written. [[!tag open_issue_hurd]] --- If applicable, it has to be taken care that all code concerning the page-in path is resident at all times. + +--- + +# IRC, freenode, #hurd, 2012-01-29 + +[[!tag open_issue_documentation]] + + <pinotree> what would be an hurdish way to achieve something like the + various system (udev, devfs, devd, etc) for populating devices files + automatically according to the found system devices? + <pinotree> (not that i plan anything about that, just curious) + <youpi> it's not really a stupid question at all :) + <youpi> I guess translators in /dev + <youpi> such as a blockfs on /dev/block + <antrik> pinotree: in an ideal world (userspace drivers and all), the + device nodes will be exported by the drivers themselfs; and the drivers + will be launched by the bus respective bus driver + <antrik> an interesting aspect is what to do if we want a traditional flat + /dev directory with unique device names... probably need some + unionfs-like translator that collects the individual driver nodes in an + intelligent manner + + +# IRC, freenode, #hurd, 2012-04-22 + + <antrik> braunr: I don't think it's a problem that translators are invoked + when listing /dev + <antrik> the problem is that they linger around although they are very + unlikely to be needed again any time soon + <youpi> for now it's not too much a problem because there aren't too many + <youpi> but that can become problematic + <pinotree> a devfs on /dev could also fill it with new devices + <youpi> but only with the ones that actually exist + <pinotree> yeah + <braunr> antrik: i mean, the hurd may lack a feature allowing the same + translator to be used for several nodes not hierarically related + <braunr> antrik: or rather, it's a special case that we should implement + differently + <braunr> (with e.g. a devfs that can route requests for different nodes to + a same translator + <braunr> ) + <antrik> I agree BTW that some intermediary for /dev would be helpful -- + but I don't think it should actually take over any RPC handling; rather, + only redirect the requests as appropriate (with the actual device nodes + in a hierarchical bus-centric layout) + <braunr> right + <antrik> braunr: actually, the Hurd *does* have a feature allowing the same + translator to be attached to several unrelated nodes + <braunr> i keep getting surprised :) + <antrik> though it's only used in very few places right now + <youpi> pfinet and ptys at least ? + <antrik> yeah, and console client IIRC + diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn new file mode 100644 index 00000000..e038ba84 --- /dev/null +++ b/hurd/translator/discussion.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_documentation open_issue_hurd]] + +IRC, freenode, #hurd, 2011-08-25: + + < frhodes> how can I replace an existing running server with a new one + without rebooting? + < antrik> frhodes: depends. if other critical things depend on it, you + can't. there is no mechanism to serialize and pass on the open sessions + < antrik> in some situations, you can orphan the old translator while + starting a new one, so the previous clients will stay with the old one + while new one will get the new one + < antrik> obviously that only works for things that aren't exclusive by + nature + < antrik> in some cases, you might even be able simply to remove the old + translator... but obviously only for non-critical stuff :-) diff --git a/hurd/translator/examples.mdwn b/hurd/translator/examples.mdwn index 6319df77..ee766fbf 100644 --- a/hurd/translator/examples.mdwn +++ b/hurd/translator/examples.mdwn @@ -36,9 +36,9 @@ or ftp$ cd ftp.fr.debian.org ftp/ftp.fr.debian.org $ ls -* tarfs translator +* tarfs translator (needs uatime fix, 2010-08-25 → [git repo](http://github.com/giselher/tarfs)) -You can use tarfs to mount (almost) any tar file: +You can use tarfs to mount (almost) any tar file (currently broken, 2010-08-25): $ settrans -ca a /hurd/tarfs -z myfile.tar.gz $ settrans -ca b /hurd/tarfs -y myfile.tar.bz2 @@ -50,7 +50,7 @@ You can even use it to create new tar files: $ cp -r all my files new/ $ syncfs new -This is not as fast as `tar czvf newfile.tar.gz all my files` but at least, it's more original. ;) +This is not as fast as `tar czvf newfile.tar.gz all my files`, but at least it's more original. ;) * cvsfs translator diff --git a/hurd/translator/exec.mdwn b/hurd/translator/exec.mdwn new file mode 100644 index 00000000..d5b6bfbc --- /dev/null +++ b/hurd/translator/exec.mdwn @@ -0,0 +1,12 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The *exec* server, listening on `/servers/exec`, is responsible for +preparing the execution of processes. diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index 441fb00f..8e15d1c7 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -1,18 +1,94 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +# Implementation + + * [[filetype]] option + + * [[Hurd-specific_extensions]] + + * [[Page_cache]] + + * [[metadata_caching]] + + +## Large Stores The `ext2fs` translator from the upstream Hurd code base can only handle file systems with sizes of less than roughly 2 GiB. -A patch exists to lift this limitation (and is being used in the +[[!tag open_issue_hurd]] + + +### Ognyan's Work + + * Ognyan Kulev, [[*Supporting Large ext2 File Systems in the + Hurd*|ogi-fosdem2005.mgp]], 2005, at FOSDEM + + * Ognyan Kulev, [[large_stores]] + + * <http://kerneltrap.org/node/4429> + +Ognyan's patch lifts this limitation (and is being used in the [[Debian_GNU/Hurd_distribution|running/debian]]), but it introduces another incompatibility: `ext2fs` then only supports block sizes of 4096 bytes. Smaller block sizes are commonly automatically selected by `mke2fs` when using small backend stores, like floppy devices. + + +#### IRC, freenode, #hurd, 2012-06-30 + + <braunr> at least having the same api in the debian package and the git + source would be great (in reference to the large store patch ofc) + <youpi> braunr: the api part could be merged perhaps + <youpi> it's very small apparently + <antrik> braunr: the large store patch is a sad story. when it was first + submitted, one of the maintainers raised some concerns. the other didn't + share these (don't remember who is who), but the concerned one never + followed up with details. so it has been in limbo ever since. tschwinge + once promised to take it up, but didn't get around to it so far. plus, + the original author himself mentioned once that he didn't consider it + finished... + <youpi> antrik: it's clearly not finished + <youpi> there are XXXs here and there + <braunr> it's called an RC1 and RC2 is mentioned in the release notes + <antrik> youpi: well, that doesn't stop most other projects from commiting + stuff... including most emphatically the original Hurd code :-) + <youpi> what do you refer to my "that" ? :) + <braunr> "XXX" + <youpi> right + <youpi> at the time it made sense to delay applying + <youpi> but I guess by nowadays standard we should just as well commit it + <youpi> it works enough for Debian, already + <youpi> there is just one bug I nkow about + <youpi> the apt database file keeps haveing the wrong size, fixed by e2fsck + <pinotree> youpi: remember that patch should be fixed in the offset + declaration in diskfs.h + <youpi> I don't remember about that + <youpi> did we fix it in the debian package? + <pinotree> nope + <youpi> you had issues when fixing it, didn't you? + <youpi> (I don't remember where I can find the details about this) + <pinotree> i changed it, recompiled hurd and installed it, started a perl + rebuild and when running one of the two lfs tests it hard locked the vm + after ext2fs was taking 100% cpu for a bit + <pinotree> i don't exclude i could have done something stupid on my side + though + <youpi> or there could just be actual issues, uncovered here + <youpi> which can be quite probable + + +# Documentation + + * <http://e2fsprogs.sourceforge.net/ext2.html> + + * <http://www.nongnu.org/ext2-doc/> diff --git a/hurd/translator/ext2fs/filetype.mdwn b/hurd/translator/ext2fs/filetype.mdwn new file mode 100644 index 00000000..5d85bac9 --- /dev/null +++ b/hurd/translator/ext2fs/filetype.mdwn @@ -0,0 +1,33 @@ +[[!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]]."]]"""]] + +The *ext2fs* translator doesn't support the ext2 format's *filetype* option. + +According to *mke2fs(8)*: + +> **filetype**: Store file type information in directory entries. + +By setting directory listings' informational `d_type` field (`readdir`, etc.), +this may avoid the need for subsequent `stat` calls. + +Not all file systems can support this option. + +In `[hurd]/ext2fs/dir.c` the `EXT2_FEATURE_INCOMPAT_FILETYPE` is generally +masked out (is not even considered) when adding a node to a directory in +`diskfs_direnter_hard` and when reading in `diskfs_get_directs`. The Hurd's +ext2fs unconditionally sets this field to 0 (`EXT2_FT_UNKNOWN`). + + +# `e2fsck` + +Running `e2fsck` on a file system with the *filetype* option, will correct the +*filetype* for a lot of files (all `EXT2_FT_UNKNOWN`?) to either 1 (regular +file, `EXT2_FT_REG_FILE`), or 2 (directory, `EXT2_FT_DIR`), and likely others. +The Hurd's ext2fs will again ignore these fields, of course. diff --git a/hurd/translator/ext2fs/hurd-specific_extensions.mdwn b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn new file mode 100644 index 00000000..774f1cf3 --- /dev/null +++ b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + + +# IRC, freenode, #hurd, 2012-04-20 + + <Tekk_> what are the extensions to ext2? + <Tekk_> that hurd uses + <braunr> tha ability to store passive translator command lines in the + inodes + <braunr> the* + <antrik> well, also a fourth set of permission bits, and an "author" field + <braunr> right + <antrik> both very obscure features that better never existed... diff --git a/hurd/translator/ext2fs/large_stores.txt b/hurd/translator/ext2fs/large_stores.txt new file mode 100644 index 00000000..6e7ffc6f --- /dev/null +++ b/hurd/translator/ext2fs/large_stores.txt @@ -0,0 +1,520 @@ +[[!meta copyright="Copyright © 2005, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +This is -*- mode: outline -*- + +* Introduction + +Here is a try to describe the ext2fs patch for the Hurd. This patch +allows using partitions/stores larger that approximately 1.5G by not +memory mapping the whole store to address space. + +As a guideline, the changelog of RC1 (Release Candidate 1) is +followed, so I hope nothing is missed. During writing of this text, +some questions arised and they are marked with XXX. An effort will be +made to fix all these for RC2. + + Ognyan Kulev <ogi@fmi.uni-sofia.bg> + +* The block layer and its purpose + +The basic unit of ext2 filesystem is "block". All filesystem +operation work on blocks which are read, and sometimes modified and +written back. Possible block sizes are 1K, 2K and 4K, but current +implementation works reliably only on 4K blocks (= page size of i386). + +So the two basic operations on blocks are "reading" block and +"writing" block. + +* Current implementation + +** Reading + +Currently, the whole store is memory mapped into address space of +ext2fs process. The is called "disk image", although "store image" +would be more accurate. The address of the start of the disk image is +stored in pager.c:disk_image. So "reading" block is easy: just +calculate byte offset of block and add it to disk_image. The resulting +address points to the start of the desired block. + +The macro ext2fs.h:bptr has exactly this purpose: given block number, +it returns pointer to block. Sometimes we have pointer somewhere in +the block, and we want the block number. This is calculated by +ext2fs.h:bptr_block. + +There is another set of macros that use byte offsets instead of block +numbers. These are boffs_ptr (store offset -> memory pointer) and +bptr_offs (memory pointer -> store offset). + +Converting between store offset and block number is easy with macros +boffs (block -> offset) and boffs_block (offset -> block). Other +useful macros are trunc_block and round_block. + +** Writing + +Modifying block and saving it is not that straight-forward as +reading. For writing, you need to use "pokel" ("poked elements"). +Pokel interface is in ext2fs.h. Implementation is in pokel.c. + +The problem is that generally multiple blocks are modified and we want +all these changes to hit disk at relatively same time. So we can't +just change block and leave decision when it's going to be written to +the microkernel. + +So there is a pokel for each set of changes and each change should be +reported to the pokel by calling pokel_add. When this set of changes +is completed, pokel_sync of pokel_flush is called. (The latter is +used to ignore changes.) + +In practice, there is one indir_pokel for each ext2fs.h:disknode, +which is used for indirect blocks of ext2fs. The only other pokel +used is ext2fs.h:global_pokel, where all other changes to metadata are +registered. + +* Proposed implementation + +First one must realize that the idea of mapping the whole store is to +be thrown away. So only parts of the store should be mapped. These +currently mapped parts of store are collectively called "cache". + +In the proposed implementation, the cache has fixed size of +ext2fs.h:DISK_CACHE_BLOCKS. In RC1, it's 100, but this is only to +easily catch bugs. In practice, it can be, for example, 512M, or +(512*1024/4) blocks of 4K. pager.c:disk_cache_size and +pager.c:disk_cache_blocks are additional variables about that +information. + +The cached blocks are mapped in ext2fs.h:disk_cache and span +disk_cache_size bytes (= disk_cache_blocks blocks). As in the +original implementation, this part of address space is handled by +custom pager. + +** Data structures + +Blocks in cache aren't consecutive, so we need data structure to hold +which part of address space represents what block. This is the +purpose of pager.c:disk_cache_info. Index in this array is "cached +block index". But this array doesn't help in finding if specific +block is mapped, and where. This is the purpose of the +pager.c:disk_cache_bptr ihash which finds cached block index from +given block number. Both data structures are guarded by +pager.c:disk_cache_lock. + +** Public interface + +"Public" interface to the cache are functions disk_cache_block_ref, +disk_cache_block_ref_ptr, disk_cache_block_deref, +disk_cache_block_is_ref. disk_cache_block_ref takes block number and +return pointer to block content. Reference count of this cached block +is incremented. After finishing work with block, +disk_cache_block_deref should be called. + +In converting original ext2fs code to use this functions, usually call +to bptr is turned into call to disk_cache_block_ref. In addition, +after pointer to block content is not used anymore, +disk_cache_block_deref is called. This simple scheme is only for +reading from block. For modifying block, see about pokels below. + +disk_cache_block_ref_ptr just increments reference count of specified +block. It's used when we give pointer to block content to somebody +else that will dereference it (e.g. pokel) and we want to continue to +use this content. + +disk_cache_block_is_ref checks if specified block has reference count +greater than zero. It's used in assert:s. + +*** bptr* and boffs* macros + +These macros continue to work as before, but they don't deal with +reference counting and this should be taken into consideration. In +addition, bptr_index returns cached block index from given pointer to +block content. (This function is used internally.) + +*** Pokels + +When pokel_add is called with pointer to block content, this +"consumes" reference of block. It's not consumed (decremented by 1) +immediately, but when pokel_sync or pokel_flush is called. (Reference +is consumed immediately if the block is already in the pokel. The +important thing is that you always lose one reference of the block.) + +So we have the following code when we read from block: + + char *bh = disk_cache_block_ref (block); + ... + disk_cache_block_deref (bh); + +And the following code when we modify block: + + char *bh = disk_cache_block_ref (block); + ... + pokel_add (pokel, bh, block_size); + +**** Indirect calls to pokel_add + +Some functions indirectly call pokel_add, so this should be taken into +consideration. These are: + + * record_global_poke + * record_indir_poke + +So these functions should be treated in the same scheme as pokel_add. +For example: + + char *bh = disk_cache_block_ref (block); + ... + record_indir_poke (node, bh); + +**** Modifying SBLOCK in diskfs_set_hypermetadata + +SBLOCK is global variable that points to superblock content. There is +one reference count for superblock, so before we call +record_global_poke (which consumes reference), +disk_cache_block_ref_ptr is called. + +**** Modifying GDP + +When group descriptor is wanted, usuall group_desc is called and +result is stored in local variable GDP. After modifying GDP, +record_global_poke is called. But because record_global_poke is used, +we need call to disk_cache_block_ref_ptr: + + gdp = group_desc (i); + ... + disk_cache_block_ref_ptr (gdp); + record_global_poke (gdp); + +*** More complex use of pointer to block content + +In ext2_new_block and ext2_alloc_inode functions, we have local +pointer variable BH that sometimes points to block content and +sometimes points to nothing. In order to reduce possible errors, when +BH points to nothing it's always 0. In some points (goto labels), +there is assertion if BH is what's expected (pointer to nothing or +pointer to something). + +*** dino + +dino function return pointer to struct ext2_inode for given ino_t. +This uses reference, so corresponding disk_cache_block_deref should be +called after finishing work with ext2_inode. For convenience, dino is +renamed to dino_ref, and dino_deref just calls disk_cache_block_deref. + + struct ext2_inode *di = dino_ref (np->cache_id); + ... + dino_deref (di); + +Or + + struct ext2_inode *di = dino_ref (np->cache_id); + ... + sync_global_ptr (di, 1); + dino_deref (di); + +Or + + struct ext2_inode *di = dino_ref (np->cache_id); + ... + record_global_poke (di); + +* Internals of the proposed implementation + +As said earlier, instead of mapping the whole store of filesystem to +address space, only part of it is mapped. This part is called "cache" +or "disk cache" (although "store cache" would be more appropriate). +Currently, the cache is contiguous area in address space that starts +at disk_cache. Its size is disk_cache_size which is disk_cache_blocks +number of blocks of size block_size. + +Mapped blocks in disk cache are not fixed -- each block in the cache +can be replaced at any time with another block. So we need to know +which blocks are cached currently and where. Information about each +cached block is stored in disk_cache_info[]. Index is from 0 to +disk_cache_blocks-1. In this information the block number is stored +(among some other things, discussed later). The reverse direction, +getting the index of cached block from block number, is achieved by +using disk_cache_bptr ihash. Both these data structures are guarded +by disk_cache_lock. + +** Requesting a block + +When ext2 code requests block, it calls disk_cache_block_ref. First, +this block is search with disk_cache_bptr. If its there, the +reference count is incremented and pointer to block content is +returned. In this case, there is a call to disk_cache_wait_remapping, +which is explained a bit later. + +It's more interesting when block is not found in disk_cache_bptr. In +this case, disk_cache_map is called. Again, disk_cache_bptr is +consulted, because in the meantime another could already have mapped +this block. If this is the case, the code is essentially the same as +those in disk_cache_block_ref. + +When it's assured that block is not in the cache, we have no choice +but throw away an already mapped/cached block and put our block in its +place. Such block has to meet the following conditions: + +- Its reference count being 0 +- Not in the core +- Not being remapped (explained later) +- Not being forbidden to be remapped ("fixed", explained later) + +The last three conditions are actually flags in disk_cache_info: +DC_INCORE, DC_REMAPPING and DC_FIXED. DC_DONT_REUSE collectively +gives the condition in which block is not suitable for +reusing/remapping. + +Searching suitable place in cache is linear. As an optimisation, this +search doesn't start from the beginning, but starts from where last +time it has ended. This last index is stored in disk_cache_hint. So +new candidate blocks for replacement are searched "circular". + +If suitable place is found, the old mapping is removed, and the new +mapping is initialized. But we are still not ready to return pointer +to block content, because this content is not available yet. We mark +the block as DC_REMAPPING, which makes disk_cache_block_ref for that +block in other threads to wait until page is completely remapped. + +In both cases, when we have found place and when suitable place is not +found, disk_cache_hint is updated so that next disk_cache_map +continues searching from where we ended. + +When not suitable place is found, we have to use force. First all +pages in disk cache are touched. This is workaround because of some +bug in GNU Mach. The patch relies on "precious page" features of +Mach. Marking a page as precious instructs Mach to always inform us +about evicting this page. If page is modified, it seems that we are +always informed. But if page is unmodified and page is evicted, +sometimes Mach forgets to tell us. It's true that with large disk +cache, e.g. 512M, this potentially will re-read the whole cache from +disk. But if we reach this point, the microkernel is telling us that +all is already read :-) + +This is preparation for following calls to pager_return_some. This +libpager function is called only on cached blocks that has reference +count of 0. These are the potential candidates for replacement -- +there is no sense in calling pager_return_some when reference count is +1 or more. One final case is when there is no cached block that has +reference count of 0. This is bad and we can't do anything about it. +In this case, we just wait one second hoping that some other thread +will drop reference count of block to 0. (XXX Currently (in RC1) +sleep(1) is always executed. It should be executed only when disk +cache is starving. There is some rationale behind calling sleep(1) even when +disk cache is not starving. Although pager_return_some(,,,1) +guarantees that upon return of this function the page is returned, I'm +not sure that it's guaranteed that pager_notify_pageout is called. +This is because pager_return_some and +libpager/data-return.c:_pager_do_write_request are executed in +different threads and pager_return_some is confirmed before calling +pager_notify_pageout. This issue is open.) + +So, after forcibly evicting all pages (blocks) that can potentially be +reused, disk_cache_map is called again. + +In the case when suitable place is found and all data structures +(disk_cache_info and disk_cache_bptr) are changed accordingly, +pager_return_some(,,,1) is called and we wait for pager_read_page to +clear DC_REMAPPING. The purpose of this flag (DC_REMAPPING) is solely +this: to forbid any use of this block until we are absolutely sure +that this page contains exactly the wanted block. If NDEBUG is not +defined (so we include debug code), flags of the blocks are checked if +DC_REMAPPING is really cleared. + +Is DC_REMAPPING really needed? Is there possibility that between last +"mutex_unlock (&disk_cache_lock)" and "return bptr" something could go +wrong? Actually, disk cache just follows protocol set by +pager_notify_pageout: that between pager_return_some and changing +internal structures for the remapping no thread may touch the page. +This is achieved by marking the page as DC_REMAPPING. For +convenience, function disk_cache_wait_remapping is defined which waits +for cached block while it's marked as DC_REMAPPING. + +XXX XXX: Actually, the sequence used in RC1 is: remap block and +pager_return_some. The latter seems redundant, as only blocks that +are evicted are candidates for remapping. I'll try to fix that for +RC2. + +** Modifying blocks and pokels + +After block is modified, it should be registered with pokel_add to +some pokel. Pokel contains list of ranges of cached blocks. All this +blocks should have reference count at least 1. In pokel_flush and +pokel_sync, this reference is consumed. + +So in pokel_add if added blocks are already in the pokel, their +references are consumed, because only 1 reference is consumed in +pokel_{sync,flush}. It's checked if pokel is for disk_cache, because +pokels are used in file access too, where disk cache layer is not +used. + +pokel_{flush,sync} both use _pokel_exec, so this is the place where +block references are consumed. (XXX: In RC1, they are consumed +always, but it's better to check if these pages are in disk_cache. +Although calling disk_cache_block_deref on non-disk_cache page does no +harm.) + +*** Indirect use of pokel_add + +record_global_poke and record_indir_poke use indirectly pokel_add. +These functions are slightly changed to use public interface of +disk_cache. Only new precondition is added for them: caller should +supply "reference" that will be consumed later by pokel_{flush,sync}. + +*** Modifying block without using pokels + +sync_global_ptr synchronizes given block immediately. No reference is +consumed. (XXX: This should be changed in RC2 to consuming reference. +This will make the function similar in use to +record_{global,indir}_poke and will make the code more nice-looking.) + +** Initialization + +*** The superblock + +To create disk cache, we need the block size of the filesystem. This +information is in superblock, so we need to read superblock without +using disk cache. For this purpose get_hypermetadata is changed to +read the superblock with store_read instead of old bptr. New function +map_hypermetadata is created that sets sblock global variable to point +to the already mapped superblock. So to get behavior of old +get_hypermetadata, first new get_hypermetadata should be called, and +then map_hypermetadata. + +In ext2fs.c:main, instead of calling get_hypermetadata, +map_hypermetadata is called. The call to get_hypermetadata is in +pager.c:create_disk_pager. + +In ext2fs.c:diskfs_reload_global_state, along with get_hypermetada, +map_hypermetadata is called. + +*** disk_cache + +Disk cache data structures are initialized in +pager.c:create_disk_pager called from ext2fs.c:main. Disk pager is +still initialized with diskfs_start_disk_pager, but due to block_size +variable we call get_hypermetadata. Basic parameters of disk cache +like disk_cache_blocks and disk_cache_size are initialized here. The +rest of the initialization process is delegated to disk_cache_init. + +disk_cache_init initializes the rest of disk cache data structures: +disk_cache_lock, disk_cache_remapping, disk_cache_bptr, +disk_cache_info and disk_cache_hint. After that superblock and group +descriptors are mapped into the cached and are marked as DC_FIXED. +This forbids reusing those blocks, because Hurd's ext2 code relies on +these blocks being mapped into fixed location in address space. + +** Pager callbacks + +disk_pager_read_page and disk_pager_write_page just use disk cache +data structures to get the right pointers to blocks. +disk_pager_read_page requests notification of page-out and updates +DC_INCORE and DC_REMAPPING too. DC_INCORE is set and DC_REMAPPING is +cleared (because reading the new block finishes its remapping). + +disk_pager_notify_pageout just clears DC_INCORE, making that page +available for remapping. + +* libpager changes + +Here memory_object_data_ prefix is shorten to m_o_d_. And when it's +talked about m_o_d_function Mach function, usually its libpager +handler is meant. + +** Notification on eviction + +The most important change that is wanted from libpager is supporting +notification when page is evicted. Mach already has partial support +for notification on eviction by argument "kcopy" of m_o_d_return. If +kcopy is 0, then Mach doesn't have copy of this page anymore, so the +page is "evicted". The problem is that m_o_d_return is usually called +only when page is modified, and if it's not modified, it's silently +dropped. + +The solutions is marking page as "precious". This has the exact +semantics we need: when page is evicted, m_o_d_return callback is +always called with kcopy=0. + +*** Implementation details + +New argument is added to user callback pager_read_page: +notify_on_pageout. If it's non-zero and the page is evicted, user +callback pager_notify_pageout(pager,page) is called. This change ABI +requires all libpager clients in the Hurd to be changed according to +the new API. + +m_o_d_request stores notify_on_pageout as flag PM_NOTIFY_PAGEOUT. + +m_o_d_return no longer just skips non-dirty pages. Local array +notified[] is build and at the end of the function, +pager_notify_pageout is called for all pages that are evicted +(kcopy=0). + +** Avoiding libpager optimization + +Unfortunately, there is one more problem, this time specific to +libpager, not Mach. There is an optimization in m_o_d_request when +page is being paged out. In the beginning of m_o_d_return, all pages +being return are marked as PM_PAGINGOUT. This mark is cleared after +m_o_d_supply (which supplies page content to Mach) is called. If +m_o_d_request is called on page that is marked as PM_PAGINGOUT, this +page is marked with PM_PAGEINWAIT, and m_o_d_supply inside +m_o_d_return is not called for this page. This is possible because +neither of these functions hold pager->interlock during the whole +execution of function. This lock is temporarily unlocked during call +to user callbacks pager_read_page and pager_write_page. + +So what is the implication of this optimization to our page eviction +notification? When page is paged out, we get notified and we can +decide to reuse it. After arranging disk_cache_info, etc, page is +touched, but if this happens fast enough, the optimization is +triggered and we get the old content! Reading the page is "optimized" +and pager_read_page is not called, but instead the content of old +block is used. + +This is solved by marking flushed and synced pages (via +pager_{flush,sync}{,_some} with PM_FORCEREAD. (These functions call +lock-object.c:_pager_lock_object which marks pages with PM_FORCEREAD +if they are already marked with PM_NOTIFY_PAGEOUT.) In handling +m_o_d_request, pages marked as PM_FORCEREAD are not optimized in this +way. XXX: Currently, this fine-grained logic is disabled (with #if), +as it needs more testing. Probably RC2 will use it. For now, all +pages are considered PM_FORCEREAD and this particular optimization +never happens. + +*** Technical details + +As said above, we need guarantee that after pager_{sync,flush}*, +pager_read_page callback is called. The most convenient place to mark +these pages as being forced to re-read is +lock-object.c:_pager_lock_object, because this function is used by all +pager_{sync,flush}* functions. So there we just mark page as +PM_FORCEREAD if it's already marked as PM_NOTIFY_PAGEOUT. + +First, this mark influences behaviour of m_o_d_request. If page is +marked with PM_FORCEREAD and PM_PAGINGOUT, then we set PM_PAGEINWAIT +and wait until related m_o_d_return finishes (unmarks PM_PAGEINWAIT). +Then we continue with pager_read_page, etc. If page is not marked +with PM_FORCEREAD and is marked with PM_PAGINGOUT, then old logic is +used and pager_read_page is not called (because m_o_d_return handler +will call m_o_d_supply instead of us). (XXX: Again, this logic is +inside #if 0. Currently, all pages are considered as marked with +PM_FORCEREAD.) + +The other place where PM_FORCEREAD is taken into consideration is +handler of m_o_d_return. The original code checks if page is marked +with PM_PAGEINWAIT, and if it is, m_o_d_supply is called for the just +written page. PM_PAGEINWAIT is used as "delegator" of the +m_o_d_supply call to Mach. + +In patched libpager, there is one more condition for when to call +m_o_d_supply. It's called when page is marked as PM_PAGEINWAIT and +not marked as PM_FORCEREAD. If it's marked as PM_FORCEREAD, then we +leave m_o_d_supply to m_o_d_request handler which gets notified by +condition pager->wakeup. diff --git a/hurd/translator/ext2fs/ogi-fosdem2005.mgp b/hurd/translator/ext2fs/ogi-fosdem2005.mgp new file mode 100644 index 00000000..27b5077c --- /dev/null +++ b/hurd/translator/ext2fs/ogi-fosdem2005.mgp @@ -0,0 +1,165 @@ +# "Supporting Larger ext2 File Systems in the Hurd" +# Written by Ognyan Kulev for presentation at FOSDEM 2005. +# Content of this file is in public domain. +%include "default.mgp" +%page +%nodefault +%center, font "thick", size 5 + + + + +Supporting Larger ext2 File Systems in the Hurd + + + +%font "standard", size 4 +Ognyan Kulev +%size 3 +<ogi@fmi.uni-sofia.bg> + + +%size 4 +FOSDEM 2005 + +%page + +Need for supporting larger file systems + + Active development during 1995-1997 + + Hurd 0.2 was released in 1997 and it was very buggy + + Many bugs are fixed since then + + The 2G limit for ext2 file systems becomes more and more annoying + +%page + +Timeline + + 2002: Time for graduating, fixing the 2G limit in Hurd's ext2fs and implementing ext3fs were chosen for MSc thesis + + 2003: First alfa quality patch + + 2004: Graduation, ext2fs patch in Debian, but ext3fs is unstable + +%page + +User pager in GNU Mach + + Address space + memory_object_data_supply + memory_object_data_return + Memory object (Mach concept) + pager_read_page + pager_write_page + User-supplied backstore (libpager concept) + +%page + +Current ext2fs + + Memory mapping of the whole store + + Applies only for metadata! + + bptr (block -> data pointer) + = image pointer + block * block_size + + Inode and group descriptor tables are used as if they are continous in memory + +%page + +Patched ext2fs, part one + + Address space region + mapping + Array of buffers + association + Store + + Association of buffers changes (reassocation) + + It's important reassociation to occur on buffers that are not in core + +%page + +Patched ext2fs, part two + + Always use buffer guarded by + disk_cache_block_ref (block -> buffer) + disk_cache_block_deref (release buffer) + + Buffer = data + reference count + flags (e.g. INCORE) + + Calling some functions implies releasing buffer: + pokel_add (pokels are list of dirty buffers) + record_global_poke (use pokel_add) + sync_global_ptr (sync immediately) + record_indir_poke (use pokel_add) + + Use ihash for mapping block to buffer + +%page + +When unassociated block is requested + + +%font "typewriter", size 4, cont +retry: + i = hint; + while (buffers[i] is referenced or in core) { + i = (i + 1) % nbuffers; + if (i == hint) { + return_unreferenced_buffers (); + goto retry; + } + } + hint = i + 1; + + deassociate (buffers[i]); + associate (buffers[i], block); + + return buffers[i]; + +%page + +Notification for evicted pages + + Notification is essential for optimal reassociation + + Precious pages in Mach + + Slight change to API and ABI of libpager is required + + Mach sometimes doesn't notify! + +%page + +Pager optimization + +1. Mach returns page to pager without leaving it in core + +2. Pager becomes unlocked because of calling callback pager_write_page + +3. User task touches the page + +4. Mach requests the same page from pager + +5. XXX Pager supplies the page that was returned by Mach, instead of calling callback pager_read_page + +%page + +Future directions + + Committing in the Hurd :-) + Block sizes of 1K and 2K + Run-time option for buffer array size (?) + Compile-time option for memory-mapping the whole store + Upgrade of UFS + Extended attributes (EAs) and Access control lists (ACLs) + +# Local Variables: +# mgp-options: "-g 640x480" +# End: diff --git a/hurd/translator/ext2fs/page_cache.mdwn b/hurd/translator/ext2fs/page_cache.mdwn new file mode 100644 index 00000000..e8a964ed --- /dev/null +++ b/hurd/translator/ext2fs/page_cache.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +This is not at all specific to ext2fs, so should be integrated elsewhere. + + +# IRC, freenode, #hurd, 2012-04-22 + + <Tekk_> is there any particular reason ext2fs takes so much memory? + <Tekk_> it beats everything on my system hands down at 100 MB + <youpi> ext2fs contains the page cache + <youpi> so it's no wonder it takes memory + <youpi> it's all the mapped files + <Tekk_> any way I can cut down on that? + <Tekk_> my system only has 512 meg :/ + <youpi> gnumach is supposed to automatically cut it down as needed + <youpi> what is the actual symptom that you see? + <Tekk_> youpi: 360 MB of memory usage when I'm doing nothing + <Tekk_> oh, is it just intelligent enough to cut down when I'm using more + memory? + <youpi> Tekk_: yes + <Tekk_> awesome. I was worried :) diff --git a/hurd/translator/gopherfs.mdwn b/hurd/translator/gopherfs.mdwn new file mode 100644 index 00000000..6c32430f --- /dev/null +++ b/hurd/translator/gopherfs.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +`gopherfs` is a virtual filesystem allowing you to access Gopher sites. + + +# Source + +incubator, gopherfs/master diff --git a/hurd/translator/hello.mdwn b/hurd/translator/hello.mdwn new file mode 100644 index 00000000..bd56cd76 --- /dev/null +++ b/hurd/translator/hello.mdwn @@ -0,0 +1,14 @@ +[[!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]]."]]"""]] + +The *hello* translator is an example of a simple [[libtrivfs]]-based one-node +[[translator]]. It is shipped as part of the [[Hurd source code +repository|source_repositories]], and exists in a single-threaded and a +multi-threaded variant. diff --git a/hurd/translator/libguestfs.mdwn b/hurd/translator/libguestfs.mdwn new file mode 100644 index 00000000..649b31f5 --- /dev/null +++ b/hurd/translator/libguestfs.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +[libguestfs](http://libguestfs.org/) is said to be able to access a lot +of different filesystem types -- can we use it to build GNU Hurd +[[translator]]s? (There is a [[FUSE]] module, too.) diff --git a/hurd/translator/magic.mdwn b/hurd/translator/magic.mdwn index 06ee798b..84bacdfb 100644 --- a/hurd/translator/magic.mdwn +++ b/hurd/translator/magic.mdwn @@ -1,20 +1,21 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] The magic translator provides `/dev/fd`. $ showtrans /dev/fd /hurd/magic --directory fd -The `/dev/fd` directory holds the open file descriptors for your current -process. You can't see them with `ls -l /dev/fd/` but you can see them +The `/dev/fd` directory holds the open [[unix/file_descriptor]]s for your +current process. You can't see them with `ls -l /dev/fd/` but you can see them individually like this: $ ls -l /dev/fd/0 diff --git a/hurd/translator/netio.mdwn b/hurd/translator/netio.mdwn new file mode 100644 index 00000000..aca9cd69 --- /dev/null +++ b/hurd/translator/netio.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +`netio` is a translator designed for creating socket ports through the +filesystem. + + +# Source + +incubator, netio/master diff --git a/hurd/translator/nfs.mdwn b/hurd/translator/nfs.mdwn new file mode 100644 index 00000000..bf24370a --- /dev/null +++ b/hurd/translator/nfs.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Translator acting as a NFS client. + + +# See Also + + * [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] issue + + * [[open_issues/libnfs]] diff --git a/hurd/translator/nsmux.mdwn b/hurd/translator/nsmux.mdwn new file mode 100644 index 00000000..d156772b --- /dev/null +++ b/hurd/translator/nsmux.mdwn @@ -0,0 +1,121 @@ +[[!meta copyright="Copyright © 2009 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]]."]]"""]] + +# nsmux + +`nsmux` implements the simplest use-case of namespace-based translator +selection (see below). + +To use `nsmux` do the following: + + $ settrans -a <node> nsmux <directory> + +After this operation `<node>` will be a mirror of `<directory>` with +namespace-based translator selection functionality enabled. + +Please note that due to some details `nsmux` may complain a lot when +run as a normal user. This matter is the most urgent on the TODO +list. + +## Source + +`nsmux` translator can be obtained with the following series of +commands: + + $ git clone git://git.sv.gnu.org/hurd/incubator.git nsmux + $ cd nsmux/ + $ git checkout -b nsmux origin/nsmux + +`filter` translator can be obtained with the following series of +commands: + + $ git clone git://git.sv.gnu.org/hurd/incubator.git filter + $ cd filter/ + $ git checkout -b filter origin/filter + +The filter is not yet working. + +## Namespace-based Translator Selection + +Namespace-based translator selection is the special technique of using +"magic" filenames for both accessing the file and setting translators +on it. + +A "magic" filename is a filename which contains an unescaped sequence +of two commas: ",,". This sequence can be escaped by adding another +comma: ",,,". In the magic filename the part up to the first double +commas is interpreted as the filename itself; the remaining segments +into which the string is split by occurrences of ",," are treated as +names of translators located under `/hurd/`. + +The simplest advantage before traditional way of setting +translators is shown in the following examples. Compare this + + $ settrans -a file translator1 + $ settrans -a file translator2 + $ cat file + +to this: + + $ cat file,,translator1,,translator2 + +One simple command versus three more lengthy ones is an obvious +improvement. However, this advantage is not the only one and, +probably, not even the most important. + +What is a good candidate for the most important advantage is that +translators requested via "magic" filenames are session-bound. In +other words, by running `cat file,,translator` we set a translator +visible *only* to `cat`, while the original file remains untranslated. +Such session-specific translators are called **dynamic** and there is +no (theoretical) way for a client to get a port to a dynamic +translator requested by another client. + +Obviously, dynamic translators can be stacked, similarly to static +translators. Also, dynamic translator stacks may reside on top of +static translator stacks. + +An important operation of namespace-based translator selection is +*filtering*. Filtering basically consists in looking up a translator +by name in the stack and ignoring translators located on top of it. +Note that filtering does not mean dropping some translators: in the +current implementation a filter is expected to be a normal dynamic +translator, included in the dynamic translator stack similarly to +other translators. + +An important detail is that filtering is not limited to dynamic +translator stacks: a filter should be able to descend into static +translator stacks as well. + +Although the concept of filtering may seem purely abstract in the +simplest use-case of setting dynamic translators on top of files, the +situation changes greatly when dynamic translator stacks on top of +directories are considered. In this case, the implementation of +namespace-based translator selection is expected to be able to +propagate the dynamic translators associated with the directory down +the directory structure. That is, all files located under a directory +opened with magic syntax, are expected to be translated by the same +set of translators. In this case having the possibility to +specifically discard some of the translators set up on top of certain +files is very useful. + +Note that the implementation of propagation of dynamic translators +down directories is not fully conceived at the moment. The +fundamental problem is distinguishing between situations when the +dynamic translators are to be set on the underlying files of the +directory or on the directory itself. + +## Currently Implemented + +Currently there a working (though not heavily tested) implementation +of the simplest use-case of namespace-based translator selection in +the form of translator `nsmux`. The filter is partially implemented +and this is the immediate goal. Propagating translators down +directories is the next objective. diff --git a/hurd/translator/pfinet.mdwn b/hurd/translator/pfinet.mdwn index cbe50b48..f6f69ea4 100644 --- a/hurd/translator/pfinet.mdwn +++ b/hurd/translator/pfinet.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008 Free Software +[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] To configure Internet connectivity, the `pfinet` (*Protocol Family Internet*) [[translator]] must be configured. This is done using the @@ -31,5 +31,8 @@ installation. --- + * [[DHCP]]. + * [[Implementation]]. + * [[IPv6]]. diff --git a/unsorted/DhcpClient.mdwn b/hurd/translator/pfinet/dhcp.mdwn index 442f4781..456d0c84 100644 --- a/unsorted/DhcpClient.mdwn +++ b/hurd/translator/pfinet/dhcp.mdwn @@ -1,4 +1,20 @@ -# <a name="DHCP_and_the_Hurd"> </a> DHCP and the Hurd +[[!meta copyright="Copyright © 2002, 2003, 2005, 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]] + +[[Debian GNU/Hurd|running/debian]] has some script hackery to get +[[running/debian/DHCP]] going. + +--- According to the following thread, no port should be needed since all the patches that have been applied, including the one concerning the thread. In fact, the thread finishes without concluding whether the patch has been applied or not. You can grab it in the thread, anyway. @@ -6,22 +22,12 @@ According to the following thread, no port should be needed since all the patche The thread starts at Jan 4th 2005 until Jan 6th and is only retaken at April 14th in [this thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html). --- [[Main/ThadeuCascardo]] - 29 Sep 2005 - -No DHCP client has been ported to the Hurd yet. - [This](http://mail.gnu.org/archive/html/help-hurd/2003-10/msg00016.html) thread on help-hurd has a little more info on what's still needed for DHCP. --- [[Main/GregBuchholz]] - 09 Oct 2003 - Found this [message](http://mail.gnu.org/archive/html/bug-hurd/2003-08/msg00045.html) about DHCP capabilities in the Hurd encouraging. --- [[Main/GregBuchholz]] - 03 Sep 2003 - * Tom Hart began a [discussion ](http://mail.gnu.org/pipermail/help-hurd/2002-October/006643.html) of 14 posts in Oct 2002. --- [[Main/GrantBow]] - 20 Oct 2002 - The beginnings of a DHCP translator is available in the Hurd sources on Savannah: [hurd/trans/pump.c](http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd/trans/pump.c?rev=1.3&content-type=text/vnd.viewcvs-markup) Unfortunately our current TCP/IP stack, the pfinet translator, lacks support for the AF\_PACKET interface as well as sending packets with an IP address of 0.0.0.0. @@ -38,5 +44,3 @@ Neal Walfield on bug-hurd replies: > Anyone else know the status of getting these compiled and functional? We need to be able to send to the DHCP server with ip address 0.0.0.0. - --- [[Main/JoachimNilsson]] - 12 Nov 2002 diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn index 996ffd6d..5afee0c6 100644 --- a/hurd/translator/pfinet/ipv6.mdwn +++ b/hurd/translator/pfinet/ipv6.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -51,10 +52,6 @@ Quite the same, but with static IPv6 address assignment: -A 2001:4b88:10e4:0:216:3eff:feff:4223/64 -G 2001:4b88:10e4::1 -# Binaries +# Missing Functionality -For your convenience -- this work is not yet available in the Debian packages --- binaries of a patched (multicast reception) GNU Mach kernel (including -default driver set and debugging support) and a stripped pfinet translator -(named `pfinet6` here) are being provided at -<http://brokenpipe.de/GnuHurd/pfinet6/> +Amongst other things, support for [[IOCTL]]s is missing. diff --git a/hurd/translator/procfs.mdwn b/hurd/translator/procfs.mdwn index 404a6764..cccce0b7 100644 --- a/hurd/translator/procfs.mdwn +++ b/hurd/translator/procfs.mdwn @@ -1,19 +1,45 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -<http://www.nongnu.org/hurdextras/#procfs> - - * [[`ps`|procps]] - * [[`top`|top]] - * [[`htop`|htop]] - * `gtop` - * [[`killall`|killall]] - * `pkill` - * ... +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Although there is no standard (POSIX or other) for the layout of the `/proc` +pseudo-filesystem, it turned out a very useful facility in GNU/Linux and other +systems, and many tools concerned with process management use it. (`ps`, `top`, +`htop`, `gtop`, `killall`, `pkill`, ...) + +Instead of porting all these tools to use [[libps]] (Hurd's official method for +accessing process information), they could be made to run out of the box, by +implementing a Linux-compatible `/proc` filesystem for the Hurd. + +The goal is to implement all `/proc` functionality needed for the various process +management tools to work. (On Linux, the `/proc` filesystem is used also for +debugging purposes; but this is highly system-specific anyways, so there is +probably no point in trying to duplicate this functionality as well...) + +Ther was an implementation in [[open_issues/HurdExtras]], +<http://www.nongnu.org/hurdextras/#procfs>. + +Madhusudan.C.S has implemented a new, fully functional [[procfs|madhusudancs]] for +[[GSoC 2008|community/gsoc/2008]]. + +In August 2010, Jérémie Koenig [published another, new +version](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00165.html). +This can be found in <http://git.savannah.gnu.org/cgit/hurd/procfs.git/>. + +Testing it is as simple as this: + + $ git clone git://git.savannah.gnu.org/hurd/procfs.git + $ cd procfs/ + $ git checkout master + $ make + $ settrans -ca proc procfs --compatible + $ ls -l proc/ + +[[Open issues|jkoenig/discussion]]. diff --git a/hurd/translator/procfs/htop.mdwn b/hurd/translator/procfs/htop.mdwn deleted file mode 100644 index ce38b92c..00000000 --- a/hurd/translator/procfs/htop.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -[[!meta copyright="Copyright © 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]]."]]"""]] - - open("/proc/stat", O_RDONLY) = 3 - open("/proc/meminfo", O_RDONLY) = 3 - open("/proc/stat", O_RDONLY) = 3 - open("/proc", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 - open("/proc/1/task", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 4 - open("/proc/1/status", O_RDONLY) = 4 - open("/proc/1/statm", O_RDONLY) = 4 - open("/proc/1/stat", O_RDONLY) = 4 - open("/proc/1/cmdline", O_RDONLY) = 4 - open("/proc/2/task", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 4 - open("/proc/2/status", O_RDONLY) = 4 - open("/proc/2/statm", O_RDONLY) = 4 - open("/proc/2/stat", O_RDONLY) = 4 - open("/proc/2/cmdline", O_RDONLY) = 4 - [...] diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn new file mode 100644 index 00000000..4f6492ed --- /dev/null +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -0,0 +1,315 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +[[!toc]] + + +# Miscellaneous + +IRC, #hurd, around September 2010 + + <youpi> jkoenig: is it not possible to provide a /proc/self which points at + the client's pid? + <pinotree> (also, shouldn't /proc/version say something else than "Linux"?) + <youpi> to make linux tools work, no :/ + <youpi> kfreebsd does that too + <pinotree> really? + <youpi> yes + <youpi> (kfreebsd, not freebsd) + <pinotree> does kbsd's one print just "Linux version x.y.z" too, or + something more eg in a second line? + <pinotree> (as curiosity) + <youpi> % cat /proc/version + <youpi> Linux version 2.6.16 (des@freebsd.org) (gcc version 4.3.5) #4 Sun + Dec 18 04:30:00 CET 1977 + <pinotree> k + <giselher> I had some problems with killall5 to read the pid from /proc, Is + this now more reliable? + <youpi> I haven't tested with jkoenig's implementation + [...] + <pinotree> looks like he did 'self' too, see rootdir_entries[] in rootdir.c + <youpi> but it doesn't point at self + <antrik> youpi: there is no way to provide /proc/self, because the server + doesn't know the identity of the client + <youpi> :/ + <antrik> youpi: using the existing mechanisms, we would need another magic + lookup type + <antrik> an alternative idea I discussed with cfhammer once would be for + the client to voluntarily provide it's identity to the server... but that + would be a rather fundamental change that requires careful consideration + <antrik> also, object migration could be used, so the implementation would + be provided by the server, but the execution would happen in the + client... but that's even more involved :-) + <youpi> but we've seen how much that'd help with a lot of other stuff + <antrik> I'm not sure whether we discussed this on the ML at some point, or + only on IRC + <youpi> it "just" needs to be commited :) + <antrik> in either case, it can't hurt to bring this up again :-) + + +# root group + +IRC, #hurd, around October 2010 + + <pinotree> the only glitch is that files/dirs have the right user as + owner, but always with root group + + +# `/proc/[PID]/stat` being 400 and not 444, and some more + +IRC, freenode, #hurd, 2011-03-27 + + <pochu> is there a reason for /proc/$pid/stat to be 400 and not 444 like on + Linux? + <pochu> there is an option to procfs to make it 444 like Linux + <pochu> jkoenig: ^ + <jkoenig> pochu, hi + <jkoenig> /proc/$pid/stat reveals information which is not usually + available on Hurd + <jkoenig> so I made it 400 by default to avoid leaking anything + <pochu> is there a security risk in providing that info? + <jkoenig> probably not so much, but it seemed like it's not really a + descision procfs should make + <jkoenig> I'm not sure which information we're speaking about, though, I + just remember the abstract reason. + <pochu> things like the pid, the memory, the priority, the state... + <pochu> sounds safe to expose + <jkoenig> also it's 0444 by default in "compatible" mode + <jkoenig> (which is necessary for the linux tools to work well) + <pochu> yeah I saw that :) + <pochu> my question is, should we change it to 0444 by default? if there + are no security risks and this improves compatibility, sounds like a good + thing to me + <pochu> we're already 'leaking' part of that info through e.g. ps + <jkoenig> I think /proc should be translated by /hurd/procfs --compatible + by default (I'm not sure whether it's already the case) + <jkoenig> also I'm not sure why hurd-ps is setuid root, rather than the + proc server being less paranoid, but maybe I'm missing something. + <pochu> jkoenig: it's not, at least not on Debian + <pochu> youpi: hi, what do you think about starting procfs with + --compatible by default? + <pochu> youpi: or changing /proc/$pid/stat to 0444 like on Linux + (--compatible does that among a few other things) + <youpi> I guess you need it for something? + <pochu> I'm porting libgtop :) + <youpi> k + <pochu> though I still think we should do this in procfs itself + <youpi> ymmv + <jkoenig> pochu, youpi, --compatible is also needed because mach's high + reported sysconf(_SC_CLK_TCK) makes some integers overflow (IIRC) + <youpi> agreed + <jkoenig> luckily, tools which use procfs usually try to detect the value + /proc uses rather than rely on CLK_TCK + <jkoenig> (so we can choose whatever reasonable value we want) + +IRC, freenode, #hurd, 2011-03-28 + + <antrik> jkoenig: does procfs expose any information that is not available + to everyone through the proc server?... + <antrik> also, why is --compatible not the default; or rather, why is there + even another mode? the whole point of procfs is compatibility... + <jkoenig> antrik, yes, through the <pid>/environ and (as mentionned above) + <pid>/stat files, but I've been careful to make these files readable only + to the process owner + <jkoenig> --compatible is not the default because it relaxes this paranoia + wrt. the stat file, and does not conform to the specification with regard + to clock tick counters + <antrik> what specification? + <jkoenig> the linux proc(5) manpage + <jkoenig> which says clock tick counters are in units of + 1/sysconf(_SC_CLK_TCK) + <antrik> so you are saying that there is some information that the Hurd + proc server doesn't expose to unprivileged processes, but linux /proc + does? + <jkoenig> yes + <antrik> that's odd. I wonder what the reasoning behind that could be + <antrik> but this information is available through Hurd ps? + <antrik> BTW, what exactly is _SC_CLK_TCK supposed to be? + <pinotree> jkoenig: hm, just tried with two random processes on linux + (2.6.32), and enrivon is 400 + <pinotree> (which makes sense, as you could have sensible informations eg + in http_proxy or other envvars) + <jkoenig> antrik, CLK_TCK is similar to HZ (maybe clock resolution instead + of time slices ?) + <jkoenig> sysconf(3) says "The number of clock ticks per second." + <jkoenig> antrik, I don't remember precisely what information this was, but + ps-hurd is setuid root. + <jkoenig> anyway, if you run procfs --compatible as a user and try to read + foo/1/stat, the result is an I/O error, which is the result of the proc + server denying access. + <antrik> but Linux /proc acutally uses HZ as the unit IIRC? or is + _SC_CLK_TCK=HZ on Linux?... + <jkoenig> I expect they're equal. + <jkoenig> in practice procps uses heuristics to guess what value /proc uses + (for compatibility purposes with older kernels) + <jkoenig> I don't think HZ is POSIX, while _SC_CLK_TCK is specifies as the + unit for (at least) the values returned by times() + <jkoenig> s/specifies/specified/ + <jkoenig> antrik, some the information is fetched directly from mach by + libps, and understandably, the proc server does not give the task port to + anyone who asks. + <antrik> well, as long as the information is exposed through ps, there is + no point in hiding it in procfs... + <antrik> and I'm aware of the crazy guessing in libproc... I was actually + mentoring the previous procfs implementation + <antrik> (though I never got around to look at his buggy code...) + <jkoenig> ok + +IRC, freenode, #hurd, 2011-07-22 + + <pinotree> hm, why /proc/$pid/stat is 600 instead of 644 of linux? + <jkoenig> pinotree, it reveals information which, while not that sensitive, + would not be available to users through the normal proc interface. + <jkoenig> (it's available through the ps command which is setuid root) + <jkoenig> we discussed at some point making it 644, IIRC. + <pinotree> hm, then why is it not a problem on eg linux? + <jkoenig> (btw you can change it with the -s option.) + <jkoenig> pinotree, it's not a problem because the information is not that + sensitive, but when rewriting procfs I preferred to play it self and + consider it's not procfs' job to decide what is sensitive or not. + <jkoenig> IIRC it's not sensitive but you need the task port to query it. + <jkoenig> like, thread times or something. + <pinotree> status is 644 though + <jkoenig> but status contains information which anyone can ask to the proc + server anyway, I think. + + +# `/proc/mounts`, `/proc/[PID]/mounts` + +IRC, freenode, #hurd, 2011-07-25 + + < pinotree> jkoenig: btw, what do you think about providing empty + /proc/mounts and /proc/$pid/mounts files? + < jkoenig> pinotree, I guess one would have to evaluate the consequences + wrt. existing use cases (in other words, "I have absolutely no clue + whatsoever about whether that would be desirable" :-) + < jkoenig> pinotree, the thing is, an error message like "/proc/mounts: No + such file or directory" is rather explicit, whereas errors which would be + caused by missing data in /proc/mounts would maybe be harder to track + < braunr> this seems reasonable though + < braunr> there already are many servers with e.g. grsecurity or chrooted + environments where mounts is empty + < pinotree> well, currently we also have an empty mtab + < braunr> pinotree: but what do you need that for ? + < braunr> pinotree: the init system ? + < pinotree> and the mnt C api already returns no entries (or it bails out, + i don't remember) + < pinotree> not a strict need + + +# `/proc/[PID]/auxv`, `/proc/[PID]/exe`, `/proc/[PID]/mem` + +Needed by glibc's `pldd` tool (commit +11988f8f9656042c3dfd9002ac85dff33173b9bd). + + +# `/proc/self/exe` + +[[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]] + + +# `/proc/[PID]/fd/` + +## IRC, freenode, #hurd, 2012-04-24 + + <antrik> braunr: /proc/*/fd can be implemented in several ways. none of + them would require undue centralisation + <antrik> braunr: the easiest would be adding one more type of magic lookup + to the existing magic lookup mechanism + <antrik> wait, I mean /proc/self... for /proc/*/fd it's even more + straighforward -- we might even have a magic lookup for that already + <pinotree> i guess the ideal thing would be implement that fd logic in + libps + <antrik> pinotree: nope. it doesn't need to ask proc (or any other server) + at all. it's local information. that's what we have the magic lookups for + <antrik> one option we were considering at some point would be using the + object migration mechanism, so the actual handling would still happen + client-side, but the server could supply the code doing it. this would + allow servers to add arbitrary magic lookup methods without any global + modifications... but has other downsides :-) + <gnu_srs> youpi: How much info for /proc/*/fd is possible to get from + libps? Re: d-h@ + <youpi> see my mail + <youpi> I don't think there is an interface for that + <youpi> processes handle fds themselves + <youpi> so libps would have to peek in there + <youpi> and I don't remember having seen any code like that + <gnu_srs> 10:17:17< antrik> wait, I mean /proc/self... for /proc/*/fd it's + even more straighforward -- we might even have a magic lookup for that + already + <gnu_srs> pinotree: For me that does not ring a bell on RPCs. Don't know + what magic means,, + <youpi> for /proc/self/fd we have a magic lookup + <youpi> for /proc/pid/fd, I don't think we have + <gnu_srs> magic lookup* + <gnu_srs> magic lookup == RPC? + <youpi> magic lookup is a kind of answer to the lookup RPC + <youpi> that basically says "it's somewhere else, see there" + <youpi> the magic FD lookup tells the process "it's your FD number x" + <youpi> which works for /proc/self/fd, but not /proc/pid/fd + <civodul> youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that + could be used + <civodul> `msgport' should have --get-fd, actually + <youpi> civodul: I assumed that the reason why msgport doesn't have it is + that it didn't exist + <youpi> so we can get a port on the fd + <youpi> but then how to know what it is? + <civodul> youpi: ah, you mean for the /proc/X/fd symlinks? + <civodul> good question + <civodul> it's not designed to be mapped back to names, indeed :-) + <antrik> youpi: yeah, I realized myself that only /proc/self/fd is trivial + <antrik> BTW, in Linux it's nor real symlinks. it's magic, with some very + strange (but useful in certain situations) semantics + <antrik> not real symlinks + <antrik> it's very weird for example for fd connected to files that have + been unlinked. it looks like a broken symlink, but when dereferencing + (e.g. with cp), you get the actual file contents... + + +# `/proc/[PID]/maps` + +## IRC, OFTC, #debian-hurd, 2012-06-20 + + <pinotree> bdefreese: the two elfutils tests fail because there are no + /proc/$pid/maps files + <pinotree> that code is quite relying on linux features, like locating the + linux kernel executables and their modules, etc + <pinotree> (see eg libdwfl/linux-kernel-modules.c) + <pinotree> refactor elfutils to have the linux parts executed only on linux + :D + <bdefreese> Oh yeah, the maintainer already seems really thrilled about + Hurd.. Did you see + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041 ? + <pinotree> kurt is generally helpful with us (= hurd) + <pinotree> most probably there he is complaining that we let elfutils build + with nocheck (ie skipping the test suite run) instead of investigate and + report why the test suite failed + + +# IRC, freenode, #hurd, 2011-06-19 + + <pinotree> jkoenig: procfs question: in process.c, process_lookup_pid, why + is the entries[2].hook line repeated twice? + <jkoenig> pinotree, let me check + <jkoenig> pinotree, it's probably just a mistake, there's no way the second + one has any effect + <pinotree> jkoenig: i see, it looked like you c&p'd that code accidentally + <jkoenig> pinotree, it's probably what happened, yes. + + +# `/proc/[PID]/cwd` + +## IRC, freenode, #hurd, 2012-06-30 + + * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying + on "internal" (but exported) glibc functions diff --git a/hurd/translator/procfs/killall.mdwn b/hurd/translator/procfs/killall.mdwn deleted file mode 100644 index 3d31b51a..00000000 --- a/hurd/translator/procfs/killall.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -[[!meta copyright="Copyright © 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]]."]]"""]] - - open("/proc/stat", O_RDONLY) = 3 - open("/proc/self/stat", O_RDONLY) = 3 - open("/proc/uptime", O_RDONLY) = 3 - open("/proc/sys/kernel/pid_max", O_RDONLY) = 4 - open("/proc/meminfo", O_RDONLY) = 4 - open("/proc", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 5 - open("/proc/1/stat", O_RDONLY) = 6 - open("/proc/1/status", O_RDONLY) = 6 - open("/proc/1/cmdline", O_RDONLY) = 6 - open("/proc/2/stat", O_RDONLY) = 6 - open("/proc/2/status", O_RDONLY) = 6 - open("/proc/2/cmdline", O_RDONLY) = 6 - [...] diff --git a/hurd/translator/procfs/procps.mdwn b/hurd/translator/procfs/procps.mdwn deleted file mode 100644 index 3d31b51a..00000000 --- a/hurd/translator/procfs/procps.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -[[!meta copyright="Copyright © 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]]."]]"""]] - - open("/proc/stat", O_RDONLY) = 3 - open("/proc/self/stat", O_RDONLY) = 3 - open("/proc/uptime", O_RDONLY) = 3 - open("/proc/sys/kernel/pid_max", O_RDONLY) = 4 - open("/proc/meminfo", O_RDONLY) = 4 - open("/proc", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 5 - open("/proc/1/stat", O_RDONLY) = 6 - open("/proc/1/status", O_RDONLY) = 6 - open("/proc/1/cmdline", O_RDONLY) = 6 - open("/proc/2/stat", O_RDONLY) = 6 - open("/proc/2/status", O_RDONLY) = 6 - open("/proc/2/cmdline", O_RDONLY) = 6 - [...] diff --git a/hurd/translator/short-circuiting.mdwn b/hurd/translator/short-circuiting.mdwn new file mode 100644 index 00000000..6f608fb2 --- /dev/null +++ b/hurd/translator/short-circuiting.mdwn @@ -0,0 +1,90 @@ +[[!meta copyright="Copyright © 2009, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +In traditional [[Unix]], file systems contain special files. These are: +symbolic links, character devices, block devices, named pipes, and +named sockets. Naturally the Hurd also support these. + +However, if you take a look at `hurd/io.defs` and `hurd/fs.defs`, you'll +find that there are no [[RPC]]s that deal specifically with these types. +Sure, you can get the type of the file through `io_stat` (among other +things), but there are none that e.g. lets you create a symbolic link. + +If you take a look at how [[glibc]] implements `symlink`, you'll notice +that all it does is create a new file and set its passive translator to +`/hurd/symlink DEST`. You can verify this yourself by creating a symlink +with `ln -s foo bar` and print its passive translator setting with `showtrans +bar`. + +This is how the other special files are implemented as well. The header +`hurd/paths.h` contains a list of paths that are used to implement +special files: + + * `/hurd/symlink` + * `/hurd/chrdev` + * `/hurd/blkdev` + * `/hurd/fifo` + * `/hurd/ifsock` + +So all special files are implemented through special-purpose translators, +right? Not quite, instead the translators of this list are often +implemented in their underlying filesystem through *translator +short-circuiting*. In fact, `chrdev` and `blkdev` aren't even implemented +as translators at all. + +Translator short-circuiting is when a file system server implements the +functionality of a passive translator itself, instead of actually starting +it. For instance, all the [[`symlink`|symlink]] translator does is return +a `FS_RETRY_*` reply to the caller. So instead of starting it, the file +system server can simply continue the file name look-up internally by +appending the target of the symbolic link to the path being looked-up. + +This way, we can skip starting the `symlink` translator, skip retrying +the look-up on the newly started translator, and we might also skip a +retry to the same file system server again, if the target of the symbolic +link is in it. + +In fact, the list's translators that actually are implemented (`symlink`, +`fifo`, `ifsock`) are only used as a default implementation if the underlying +file system's translator does not implement the functionality itself, i.e., if +it doesn't short-circuit it. + +To make sure that you use one of these translators, there by bypassing the +short-circuiting mechanism, you can either start it as +an active translator, or use a different path from the one in +`hurd/path.h`, e.g. `settrans bar /hurd/./symlink foo`. +There is also a `FS_TRANS_FORCE` flag defined for the `file_set_translator` +RPCs, but it currently isn't set from anywhere. + +The best example of how short-circuiting is implemented can be found +in [[`libdiskfs`|libdiskfs]]. Notice how it detects if a translator to store +is a special file in `diskfs_S_file_set_translator` and instead +of storing a real passive translator setting on the disk, stores it as a +symlink node (using `diskfs_create_symlink_hook` or a generic implementation). + +In later look-ups to the node, it checks the node's `stat` structure in +`diskfs_S_file_get_translator`, or +`diskfs_S_dir_lookup` and handles special file types appropriately. + +Doing this translator short-circuiting has disadvantages: code duplication, or +in general adding code complexity that isn't needed for implementing the same +functionality, but it also has advantages: using functionality that the file +system's data structures nevertheless already provide -- storing symbolic links +in `ext2fs`' inodes instead of storing passive translator settings -- and thus +staying compatible with other operating systems mounting that file system. + +Also, this short-circuiting does preserve system resources, as it's no longer +required to start a `symlink` translator for resolving each symbolic link, as +well as it does reduce the [[RPC]] overhead. + +It can also confuse users who expect the passive translator to start. +For instance, if a user notices that [[`symlink`|symlink]]'s code is +lacking some functionality, but that it unexpectedly works when the user +tries to run it. diff --git a/hurd/translator/storeio.mdwn b/hurd/translator/storeio.mdwn index e4482e65..8e26a959 100644 --- a/hurd/translator/storeio.mdwn +++ b/hurd/translator/storeio.mdwn @@ -27,4 +27,4 @@ You can even `ungzip` files on the fly (`bunzip2` is available as well): You can use the *typed store*, to create filter chains (of course this example is kind of useless since you could use the `gunzip` store directly): - settrans -ca node /hurd/storeio -T type gunzip:file:foo.gz + settrans -ca node /hurd/storeio -T typed gunzip:file:foo.gz diff --git a/hurd/translator/storeio/discussion.mdwn b/hurd/translator/storeio/discussion.mdwn new file mode 100644 index 00000000..0766e0af --- /dev/null +++ b/hurd/translator/storeio/discussion.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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-11-10: + + <pinotree> hm, is it normal that st_rdev for storeio translators of + /dev/hd* devices is 0? diff --git a/hurd/translator/tarfs.mdwn b/hurd/translator/tarfs.mdwn new file mode 100644 index 00000000..e25e3255 --- /dev/null +++ b/hurd/translator/tarfs.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +`tarfs` is a translator aimed at providing access to tar files through the +filesystem. This way you don't have to extract files from the archive to +access them. It supports compressed archives (bzip2 and gzip) through +[[libstore]]. + + +# Status + +Works fine on most cases, occasional corruptions when writing using bzip2/gzip +stores. + + +# Source + +incubator, tarfs/master diff --git a/hurd/translator/tmpfs.mdwn b/hurd/translator/tmpfs.mdwn index 0179ad6c..626fad86 100644 --- a/hurd/translator/tmpfs.mdwn +++ b/hurd/translator/tmpfs.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] `tmpfs` is a file system server for temporary data storage without using a real (permanent) [[backing_store]]. @@ -20,10 +20,5 @@ system|ext2fs]] on it, having a real `tmpfs` is better, as it need not deal with the additional block-level indirection layer that `ext2` (or any other disk-based file system) imposes. -However, `tmpfs` is not working correctly at the moment: - -[[!inline -pages="hurd/translator/tmpfs/*" -show=0 -feeds=no -actions=yes]] +However, `tmpfs` is not working correctly at the moment, see the [[discussion]] +sub-pages. There is a [[!FF_project 271]][[!tag bounty]] on this task. diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn new file mode 100644 index 00000000..bdee0f78 --- /dev/null +++ b/hurd/translator/tmpfs/discussion.mdwn @@ -0,0 +1,430 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + + * [[notes_bing]] + + * [[notes_various]] + + * [[tmpfs_vs_defpager]] + + * [[!GNU_Savannah_bug 26751]] + + * [[!GNU_Savannah_bug 32755]] + + +# [[Maksym_Planeta]] + +## IRC, freenode, #hurd, 2011-11-29 + + <mcsim> Hello. In seqno_memory_object_data_request I call + memory_object_data_supply and supply one zero filled page, but seems that + kernel ignores this call because this page stays filled in specified + memory object. In what cases kernel may ignore this call? It is written + in documentation that "kernel prohibits the overwriting of live data + pages". But when I called memory_object_lock_request on this page with + should flush and MEMORY_OBJECT_RETURN_ALL nothing change + <braunr> what are you trying to do ? + <mcsim> I think that memory object holds wrong data, so I'm trying to + replace them. This happens when file is truncated, so I should notify + memory object that there is no some data. But since gnumach works only + with sizes that are multiple of vm_page_size, I should manually correct + last page for case when file size isn't multiple of vm_page_size. This is + needed for case when file grows again and that tail of last page, which + wasn't part of file should be filled wit + <mcsim> I've put some printf's in kernel and it seems that page that holds + data which I want replace both absent and busy: + <mcsim> m = vm_page_lookup(object,offset); + <mcsim> ... + <mcsim> if (m->absent && m->busy) { <-- Condition is true + <mcsim> in vm/memory_object.c:169 + <slpz> mcsim: Receiving m_o_data_request means there's no page in the + memory object at that offset, so m_o_data_supply should work + <slpz> are you sure that page is not being installed into the memory + object? + <braunr> it seems normal it's both absent and busy + <braunr> absent because, as sergio said, the page is missing, and busy + because the kernel starts a transfer for its content + <braunr> i don't understand how you determine the kernel ignores your + data_supply + <braunr> "because this page stays filled in specified memory object" + <braunr> please explain this with more detail + <slpz> mcsim: anyway, when truncating a file to a non page-aligned length, + you can just zero fill the rest of the page by mapping the object and + writing to it with memset/bzero + <braunr> (avoid bzero, it's obsolete) + <mcsim> slpz: I'll try try it now. + <braunr> slpz: i think that's what he's trying to do + <mcsim> I don't vm_map it + <braunr> how do you zero it then ? + <braunr> "I call memory_object_data_supply and supply one zero filled page" + <mcsim> First I call mo_lock_request and ask to return this page, than I + memset tail and try to mo_data_supply + <mcsim> I use this function when I try to replace kr = + memory_object_data_supply(reply_to, offset, addr, vm_page_size, FALSE, + VM_PROT_NONE, FALSE, MACH_PORT_NULL); + <mcsim> where addr points to new data, offset points to old data in + object. and reply_to is memory_control which I get as parameter in + mo_data_request + <braunr> why would you want to vm_map it then ? + <mcsim> because mo_data_supply doesn't work. + <braunr> mcsim: i still don't see why you want to vm_map + <mcsim> I just want to try it. + <braunr> but what do you think will happen ? + <mcsim> But seems that it doesn't work too, because I can't vm_map + memory_object from memory_manager of this object. + + +## IRC, freenode, #hurd, 2012-01-05 + + <mcsim> Seems tmpfs works now. The code really needs cleaning, but the main + is that it works. So in nearest future it will be ready for merging to + master branch. BTW, anyone knows good tutorial about refactoring using + git (I have a lot of pointless commits and I want to gather and scatter + them to sensible ones). + <antrik> I wonder whether he actually got the "proper" tmpfs with the + defaul pager working? or only the hack with a private pager? + <mcsim> antrik: with default pager + <antrik> mcsim: wow, that's great :-) + <antrik> how did you fix it? + <mcsim> antrik: The main code I wrote before December, so I forgot some of + what exactly I were doing. So I have to look through my code :) + <mcsim> antrik: old defpager was using old functions like m_o_data_write + instead of m_o_data_return etc. I changed it, mostly because of my + misunderstanding. But I hope that this is not a problem. + + +## IRC, freenode, #hurd, 2012-01-18 + + <antrik> mcsim: did you publish your in-progress work? + <mcsim> there is a branch with working tmpfs in git repository: + http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=mplaneta/tmpfs/defpager + <jd823592> sorry for interrupting the meeting but i wonder what is a + lazyfs? + <mcsim> jd823592: lazyfs is tmpfs which uses own pager + <antrik> mcsim: ah, nice :-) + <antrik> BTW, what exactly did you need to fix to make it work? + <mcsim> most fixes wore in defpager in default_pager_object_set_size. Also, + as i said earlier, I switched to new functions (m_o_data_return instead + of m_o_data_write and so on). I said that this was mostly because of my + misunderstanding, but it turned out that new function provide work with + precious attribute of page. + <mcsim> Also there were some small errors like this: + <mcsim> pager->map = (dp_map_t) kalloc (PAGEMAP_SIZE (new_size)); + <mcsim> memcpy (pager->map, old_mapptr, PAGEMAP_SIZE (old_size)); + <mcsim> where in second line should be new_size too + <mcsim> I removed all warnings in compiling defpager (and this helped to + find an error). + <antrik> great work :-) + <jd823592> tmpfs is nice thing to have :), are there other recent + improvements that were not yet published in previous moth? + <mcsim> BTW, i measured tmpfs speed in it is up to 6 times faster than + ramdisk+ext2fs + <antrik> mcsim: whow, that's quite a difference... didn't expect that + + +## IRC, freenode, #hurd, 2012-01-24 + + <mcsim> braunr: I'm just wondering is there any messages before hurd + breaks. I have quite strange message: memory_object_data_request(0x0, + 0x0, 0xf000, 0x1000, 0x1) failed, 10000003 + <braunr> hm i don't think so + <braunr> usually it either freezes completely, or it panics because of an + exhausted resource + <mcsim> where first and second 0x0 are pager and pager_request for memory + object in vm_fault_page from gnumach/vm_fault.c + <braunr> if you're using the code you're currently working on (which i + assume), then look for a bug there first + <tschwinge> mcsim: Maybe you're running out of swap? + <mcsim> tschwinge: no + <braunr> also, translate the error code + <mcsim> AFAIR that's MACH_INVALID_DEST + <braunr> and what does it mean in this situation ? + <mcsim> I've run fsx as long as possible several times. It runs quite long + but it breaks in different ways. + <mcsim> MACH_SEND_INVALID_DEST + <mcsim> this means that kernel tries to call rpc with pager 0x0 + <mcsim> this is invalid destiantion + <braunr> null port + <braunr> ok + <braunr> did the pager die ? + <mcsim> When I get this message pager dies, but also computer can suddenly + reboot + <braunr> i guess the pager crashing makes mach print this error + <braunr> but then you may have a dead port instead of a null port, i don't + remember the details + <mcsim> braunr: thank you. + <mcsim> btw, for big file sizes fsx breaks on ext2fs + <braunr> could you identify the threshold ? + <braunr> and what's fsx exactly ? + <mcsim> fsx is a testing utility for filesystems + <mcsim> see http://codemonkey.org.uk/projects/fsx/ + <braunr> ah, written by tevanian + <mcsim> threshold seems to be 8Mb + <braunr> fyi, avadis tevanian is the main author of the mach 3 core + services and VM parts + <braunr> well, ext2fs is bugged, we already know that + <braunr> old code maintained as well as possible, but still + <mcsim> hmm, with 6mb it breaks too + <braunr> i guess that it may break on anything larger than a page actually + :p + <mcsim> When I tested with size of 256kb, fsx worked quite long and didn't + break + <braunr> mcsim: without knowing exactly what the test actually does, it's + hard to tell + <mcsim> I see, I just wanted to tell that there are bugs in ext2fs too. But + I didn't debugged it. + <mcsim> fsx performs different operations, like read, write, truncate file, + grow file in random order. + <braunr> in parellel too ? + <braunr> parellel + <braunr> parallel* + <mcsim> no + <mcsim> I run several fsx's parallel on tmpfs, but they break on file with + size 8mb. + <braunr> that must match something in mach + <braunr> s/must/could/ :) + <mcsim> braunr: I've pushed my commits to mplaneta/tmpfs/master branch in + hurd repository, so you could review it. + <braunr> you shouldn't do that just for me :p + <braunr> you should do that regularly, and ask for reviews after + (e.g. during the meetings) + <mcsim> everyone could do that :) + <braunr> i'm quite busy currently unfortunately + <braunr> i'll try when i have time, but the best would be to ask very + specific questions + <braunr> these are usually the faster to answer for people ho have the + necessary expertise to help you + <braunr> fastest* + <mcsim> ok. + <mcsim> braunr: probably, I was doing something wrong, because now parallel + works only for small sizes. Sorry, for disinformation. + + +### IRC, freenode, #hurd, 2012-01-25 + + <antrik> braunr: actually, the paging errors are *precisely* the way my + system tends to die... + <antrik> (it's after about a month of uptime usually though, not a week...) + <antrik> tschwinge: in my case at least, I have still plenty of swap when + this happens. swap usage is generally at about the amount of physical + memory -- I have no idea though whether there is an actual connection, or + it's just coincidence + <braunr> antrik: ok, your hurd dies because of memory issues, my virtual + machines die because of something else (though idk what) + <antrik> before I aquired the habit of running my box 24/7 and thus hitting + this issue, most of the hangs I experienced were also of a different + nature... but very rare in general, except when doing specific + problematic actions + <mcsim> antrik: yes. Do you get messages like that I posted? + <mcsim> here is it: memory_object_data_request(0x0, 0x0, 0xf000, 0x1000, + 0x1) failed, 10000003 + <antrik> mcsim: I can't tell for sure (never noted them down, silly me...) + <antrik> but I definitely get paging errors right before it hangs + <antrik> I guess that was unclear... what I'm trying to say is: I do get + memory_object_data_request() failed; but I'm not sure about the + parameters + <mcsim> antrik: ok. Thank you. + <mcsim> I'll try to find something in defpager, but there should be errors + in mach too. At least because sometimes computer suddenly reboots during + test. + <antrik> mcsim: I don't get sudden reboots + <antrik> might be a different error + <antrik> do you have debugging mode activated in Mach? otherwise it reboots + on kernel panics... + <mcsim> antrik: no. But usually on kernel panics mach waits for some time + showing the error message and only than reboots. + <antrik> OK + <mcsim> how can I know that tmpfs is stable enough? Correcting errors in + kernel to make fsx test work seems to be very complex. + <mcsim> *If errors are in kernel. + <antrik> well, it seems that you tested it already much more thoroughly + than any other code in the Hurd was ever tested :-) + <antrik> of course it would be great if you could pinpoint some of the + problems you see nevertheless :-) + <antrik> but that's not really necessary before declaring tmpfs good enough + I'd say + <mcsim> ok. I'll describe every error I meet on my userpage + <mcsim> but it will take some time, not before weekend. + <antrik> don't worry, it's not urgent + <antrik> the reason I'd really love to see those errors investigated is + that most likely they are the same ones that cause stability problems in + actual use... + <antrik> having an easy method for reproducing them is already a good start + <mcsim> no. they are not the same + <mcsim> every time i get different one + <mcsim> especially when i just start one process fsx and wait error + <antrik> mcsim: have you watched memory stats while running it? if it's + related to the problems I'm experiencing, you will probably see rising + memory use while the test is running + <mcsim> it could be reboot, message, I posted and also fsx could stop + telling that something wrong with data + <antrik> you get all of these also on ext2? + <mcsim> i've done it only once. Here is the log: + http://paste.debian.net/153511/ + <mcsim> I saved "free" output every 30 seconds + <mcsim> no. I'll do it now + <antrik> would be better to log with "vmstat 1" + <mcsim> ok. + <mcsim> as you can see, there is now any leek during work. But near end + free memory suddenly decreases + <antrik> yeah... it's a bit odd, as there is a single large drop, but seems + stable again afterwards... + <antrik> a more detailed log might shed some light + <mcsim> drop at the beginning was when I started translator. + <mcsim> what kind of log do you mean? + <antrik> vmstat 1 I mean + <mcsim> ah... + + +## IRC, freenode, #hurd, 2012-02-01 + + <mcsim> I run fsx with this command: fsx -N3000 foo/bar -S4 + -l$((1024*1024*8)). And after 70 commands it breaks. + <mcsim> The strangeness is at address 0xc000 there is text, which was + printed in fsx with vfprintf + <mcsim> I've lost log. Wait a bit, while I generate new + <jkoenig_> mcsim, what's fsx / where can I find it ? + <mcsim> fsx is filesystem exersiser + <mcsim> http://codemonkey.org.uk/projects/fsx/ + <jkoenig_> ok thanks + <mcsim> i use it to test tmpfs + <mcsim> here is fsx that compiles on linux: http://paste.debian.net/154390/ + and Makefile for it: http://paste.debian.net/154392/ + <jkoenig_> mcsim, hmm, I get a failure with ext2fs too, is it expected? + <mcsim> yes + <mcsim> i'll show you logs with tmpfs. They slightly differ + <mcsim> here: http://paste.debian.net/154399/ + <mcsim> pre last operation is truncate + <mcsim> and last is read + <mcsim> during pre-last (or last) starting from address 0xa000, every + 0x1000 bytes appears text + <mcsim> skipping zero size read + <mcsim> skipping zero size read + <mcsim> truncating to largest ever: 0x705f4b + <mcsim> signal 2 + <mcsim> testcalls = 38 + <mcsim> this text is printed by fsx, by function prt + <mcsim> I've mistaken: this text appears even from every beginning + <mcsim> I know that this text appears exactly at this moment, because I + added check of the whole file after every step. And this error appeared + only after last truncation. + <mcsim> I think that the problem is in defpager (I'm fixing it), but I + don't understand where defpager could get this text + <jkoenig_> wow I get java code and debconf templates + <mcsim> So, my question is: is it possible for defpager to get somehow this + text? + <jkoenig_> possibly recycled, non-zeroed pages? + <mcsim> hmmm... probably you're right + <jkoenig_> 0x1000 bytes is consistent with the page size + <mcsim> Should I clean these pages in tmpfs? + <mcsim> or in defpager? + <mcsim> What is proper way? + <jkoenig_> mcsim, I'd say defpager should do it, to avoid leaking + information, I'm not sure though. + <jkoenig_> maybe tmpfs should also not assume the pages have been blanked + out. + <mcsim> if i do it in both, it could have big influence on performance. + <mcsim> i'll do it only in defpager so far. + <mcsim> jkoenig_: Thank you a lot + <jkoenig_> mcsim, no problem. + + +## IRC, freenode, #hurd, 2012-02-08 + + <tschwinge> mcsim: You pushed another branch with cleaned-up patches? + <mcsim> yes. + <tschwinge> mcsim: Anyway, any data from your report that we could be + interested in? (Though it's not in English.) + <mcsim> It's completely in ukrainian an and mostly describes some aspects + of hurd's work. + <tschwinge> mcsim: OK. So you ran out of time to do the benchmarking, + etc.? + <tschwinge> Comparing tmpfs to ext2fs with RAM backend, etc., I mean. + <mcsim> tschwinge: I made benchmarking and it turned out that tmpfs up to 6 + times faster than ext2fs + <mcsim> tschwinge: is it possible to have a review of work, I've already + done, even if parallel writing doesn't work? + <tschwinge> mcsim: Do you need this for university or just a general review + for inclusion in the Git master branch? + <mcsim> general review + <tschwinge> Will need to find someone who feels competent to do that... + <mcsim> the branch that should be checked is tmpfs-final + <pinotree> cool, i guess you tested also special types of files like + sockets and pipes? (they are used in eg /run, /var/run or similar) + <mcsim> Oh. I accidentally created this branch. It is my private + branch. I'll delete it now and merge everything to mplaneta/tmpfs/master + <mcsim> pinotree: Completely forgot about them :( I'll do it by all means + <pinotree> mcsim: no worries :) + <mcsim> tschwinge: Ready. The right branch is mplaneta/tmpfs/master + + +## IRC, freenode, #hurd, 2012-03-07 + + <pinotree> did you test it with sockets and pipes? + <mcsim> pinotree: pipes work and sockets seems to work too (I've created + new pfinet device for them and pinged it). + <pinotree> try with simple C apps + <mcsim> Anyway all these are just translators, so there shouldn't be any + problems. + <mcsim> pinotree: works + + +## IRC, freenode, #hurd, 2012-03-22 + + <mcsim> Hello. Is it normal that when i try to run du at directory where + translator is mounted it says that directory is 'Not a directory'? Here + are some examples with different filesystems: paste.debian.net/160699 + First is ramdisk+ext2fs, second is tmpfs, third is ext2fs. + <civodul> i can't reproduce the problem with ext2fs + <civodul> perhaps you can try rpctracing it to see where ENOTDIR comes from + <mcsim> civodul: when I run du io_stat_request ipc is called. But reply is + ((os/kern) invalid address). Where is server code for this ipc? I only + found its definition in defs file and that's all. + <civodul> mcsim: server code is in libdiskfs + ext2fs, for instance + <mcsim> civodul: Does io_stat_request have changed name in server code? I + just can't find it. Here are my grep results fore io_stat_request (i was + grepping in root of hurd repository: paste.debian.net/160708 + <youpi> remove _request + <youpi> it's just io_stat + <mcsim> youpi: thank you + + +## IRC, freenode, #hurd, 2012-04-08 + + <mcsim> youpi: I've corrected everything you said, and pushed code to new + branch mplaneta/tmpfs/master-v2 + <youpi> mcsim: all applied, thanks ! + <youpi> I'll probably test it a bit and upload a new version of hurd + <youpi> mcsim: it seems to be working fine indeed! + <mcsim> youpi: thank you for all your reviews, suggestions you gave and + corrections you made :) + <youpi> and it seems translators indeed work there too + <youpi> hopefully it'll work to run the debian installer + <youpi> that'd permit to solve memory consumption + <pinotree> (so tmpfs works really fine now? great!) + <youpi> I could reboot with tmpfs on /tmp and build a package there, yes + <mcsim> youpi: yes, I've compiled several packages already, but it does not + give big advantage in performance. + <youpi> I wasn't really looking for performance, but for correctness :) + <youpi> are you using writeback for your /, actually ? + <youpi> argl, /run gets triggered before mach-defpager is started + <youpi> the X11 socket works there too + <youpi> gnu_srs: might your mouse issue with Xorg be related with vnc usage + too? + <youpi> it seems ENOSPC works fine too + <mcsim> youpi: as to writeback. I think yes, because default pager is asked + to write data only when this data is evicted. + <youpi> I'm talking about kvm + <mcsim> youpi: I use real computer. + <youpi> ok + <youpi> but that indeed means writeback of ext2fs works, which is a good + sign :) diff --git a/hurd/translator/tmpfs/notes_various.mdwn b/hurd/translator/tmpfs/notes_various.mdwn index 01dc87d2..d1c5cf62 100644 --- a/hurd/translator/tmpfs/notes_various.mdwn +++ b/hurd/translator/tmpfs/notes_various.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009 Free Software +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] @@ -212,3 +212,11 @@ is included in the section entitled <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/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn new file mode 100644 index 00000000..5228515f --- /dev/null +++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn @@ -0,0 +1,272 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + + +# IRC, freenode, #hurd, 2010 + + <slpz> humm... why does tmpfs try to use the default pager? that's a bad + idea, and probably will never work correctly... + * slpz is thinking about old issues + <slpz> tmpfs should create its own pagers, just like ext2fs, storeio... + <slpz> slopez@slp-hurd:~$ settrans -a tmp /hurd/tmpfs 10M + <slpz> slopez@slp-hurd:~$ echo "foo" > tmp/bar + <slpz> slopez@slp-hurd:~$ cat tmp/bar + <slpz> foo + <slpz> slopez@slp-hurd:~$ + <slpz> :-) + <pochu> slpz: woo you fixed it? + <slpz> pochu: well, it's WIP, but reading/writing works... + <slpz> I've replaced the use of default pager for the standard pager + creation mechanism + <antrik> slpz: err... how is it supposed to use swap space if not using the + default pager? + <antrik> slpz: or do you mean that it should act as a proxy, just + allocating anonymous memory (backed by the default pager) itself? + <youpi> antrik: the kernel uses the default pager if the application pager + isn't responsive enough + <slpz> antrik: it will just create memory objects and provide zerofilled + pages when requested by the kernel (after a page fault) + <antrik> youpi: that makes sense I guess... but how is that relevant to the + question at hand?... + <slpz> antrik: memory objects will contain the data by themselves + <slpz> antrik: as youpi said, when memory is scarce, GNU Mach will start + paging out data from memory objects to the default pager + <slpz> antrik: that's the way in which pages will get into swap space + <slpz> (if needed) + <youpi> the thing being that the tmpfs pager has a chance to select pages + he doesn't care any more about + <antrik> slpz: well, the point is that instead of writing the pages to a + backing store, tmpfs will just keep them in anonymous memory, and let the + default pager write them out when there is pressure, right? + <antrik> youpi: no idea what you are talking about. apparently I still + don't really understand this stuff :-( + <youpi> ah, but tmpfs doesn't have pages he doesn't care about, does it? + <slpz> antrik: yes, but the term "anonymous memory" could be a bit + confusing. + <slpz> antrik: in GNU Mach, anonymous memory is backed by a memory object + without a pager. In tmpfs, nodes will be allocated in memory objects, and + the pager for those memory objects will be tmpfs itself + <antrik> slpz: hm... I thought anynymous memory is backed by memory objects + created from the default pager? + <antrik> yes, I understand that tmpfs is supposed to be the pager for the + objects it provides. they are obviously not anonymoust -- they have + inodes in the tmpfs name space + <antrik> but my understanding so far was that when Mach returns pages to + the pager, they end up in anonymous memory allocated to the pager + process; and then this pager is responsible for writing them back to the + actual backing store + <antrik> am I totally off there?... + <antrik> (i.e. in my understanding the returned pages do not reside in the + actual memory object the pager provides, but in an anonymous memory + object) + <slpz> antrik: you're right. The trick here is, when does Mach return the + pages? + <slpz> antrik: if we set the attribute "can_persist" in a memory object, + Mach will keep it until object cache is full or memory is scarce + <slpz> or we change the attributes so it can no longer persist, of course + <slpz> without a backing store, if Mach starts sending us pages to be + written, we're in trouble + <slpz> so we must do something about it. One option, could be creating + another pager and copying the contents between objects. + <antrik> another pager? not sure what you mean + <antrik> BTW, you didn't really say why we can't use the default pager for + tmpfs objects :-) + <slpz> well, there're two problems when using the default pager as backing + store for translators + <slpz> 1) Mach relies on it to do swapping tasks, so meddling with it is + not a good idea + <slpz> 2) There're problems with seqnos when trying to work with the + default pager from tasks other the kernel itself + <slpz> (probably, the latter could be fixed) + <slpz> antrik: pager's terminology is a bit confusing. One can also say + creating another memory object (though the function in libpager is + "pager_create") + <antrik> not sure why "meddling" with it would be a problem... + <antrik> and yeah, I was vaguely aware that there is some seqno problem + with tmpfs... though so far I didn't really understand what it was about + :-) + <antrik> makes sense now + <antrik> anyways, AIUI now you are trying to come up with a mechanism where + the default pager is not used for tmpfs objects directly, but without + making it inefficient? + <antrik> slpz: still don't understand what you mean by creating another + memory object/pager... + <antrik> (and yeat, the terminology is pretty mixed up even in Mach itself) + <slpz> antrik: I meant creating another pager, in terms of calling again to + libpager's pager_create + <antrik> slpz: well, I understand what "create another pager" means... I + just don't understand what this other pager would be, when you would + create it, and what for... + <slpz> antrik: oh, ok, sorry + <slpz> antrik: creating another pager it's just a trick to avoid losing + information when Mach's objects cache is full, and it decides to purge + one of our objects + <slpz> anyway, IMHO object caching mechanism is obsolete and should be + replaced + <slpz> I'm writting a comment to bug #28730 which says something about this + <slpz> antrik: just one more thing :-) + <slpz> if you look at the code, for most time of their lives, anonymous + memory objects don't have a pager + <slpz> not even the default one + <slpz> only the pageout thread, when the system is running really low on + memory, gives them a reference to the default pager by calling + vm_object_pager_create + <slpz> this is not really important, but worth noting ;-) + + +# IRC, freenode, #hurd, 2011-09-28 + + <slpz> mcsim: "Fix tmpfs" task should be called "Fix default pager" :-) + <slpz> mcsim: I've been thinking about modifying tmpfs to actually have + it's own storeio based backend, even if a tmpfs with storage sounds a bit + stupid. + <slpz> mcsim: but I don't like the idea of having translators messing up + with the default pager... + <antrik> slpz: messing up?... + <slpz> antrik: in the sense of creating a number of arbitrarily sized + objects + <antrik> slpz: well, it doesn't really matter much whether a process + indirectly eats up arbitrary amounts of swap through tmpfs, or directly + through vm_allocate()... + <antrik> though admittedly it's harder to implement resource limits with + tmpfs + <slpz> antrik: but I've talked about having its own storeio device as + backend. This way Mach can pageout memory to tmpfs if it's needed. + <mcsim> Do I understand correctly that the goal of tmpfs task is to create + tmpfs in RAM? + <slpz> mcsim: It is. But it also needs some kind of backend, just in case + it's ordered to page out data to free some system's memory. + <slpz> mcsim: Nowadays, this backend is another translator that acts as + default pager for the whole system + <antrik> slpz: pageout memory to tmpfs? not sure what you mean + <slpz> antrik: I mean tmpfs acting as its own pager + <antrik> slpz: you mean tmpfs not using the swap partition, but some other + backing store? + <slpz> antrik: Yes. + +See also: [[open_issues/resource_management_problems/pagers]]. + + <antrik> slpz: I don't think an extra backing store for tmpfs is a good + idea. the whole point of tmpfs is not having a backing store... TBH, I'd + even like to see a single backing store for anonymous memory and named + files + <slpz> antrik: But you need a backing store, even if it's the default pager + :-) + <slpz> antrik: The question is, Should users share the same backing store + (swap space) or provide their own? + <antrik> slpz: not sure what you mean by "users" in this context :-) + <slpz> antrik: Real users with the ability of setting tmpfs translators + <antrik> essentially, I'd like to have a single partition that contains + both swap space and the main filesystem (at least /tmp, but probably also + all of /run, and possibly even /home...) + <antrik> but that's a bit off-topic :-) + <antrik> well, ideally all storage should be accounted to a user, + regardless whether it's swapped out anonymous storage, temporary named + files, or permanent files + <slpz> antrik: you could use a file as backend for tmpfs + <antrik> slpz: what's the point of using tmpfs then? :-) + <pinotree> (and then store the file in another tmpfs) + <slpz> antrik: mach-defpager could be modified to use storeio instead of + Mach's device_* operations, but by the way things work right now, that + could be dangerous, IMHO + <antrik> pinotree: hehe + <pinotree> .. recursive tmpfs'es ;) + <antrik> slpz: hm, sounds interesting + <slpz> antrik: tmpfs would try to keep data in memory always it's possible + (not calling m_o_lock_request would do the trick), but if memory is + scarce an Mach starts paging out, it would write it to that + file/device/whatever + <antrik> ideally, all storage used by system tasks for swapped out + anonymous memory as well as temporary named files would end up on the + /run partition; while all storage used by users would end up in /home/* + <antrik> if users share a partition, some explicit storage accounting would + be useful too... + <antrik> slpz: is that any different from what "normal" filesystems do?... + <antrik> (and *should* it be different?...) + <slpz> antrik: Yes, as most FS try to synchronize to disk at a reasonable + rate, to prevent data losses. + <slpz> antrik: tmpfs would be a FS that wouldn't synchronize until it's + forced to do that (which, by the way, it's what's currently happening + with everyone that uses the default pager). + <antrik> slpz: hm, good point... + <slpz> antrik: Also, metadata in never written to disk, only kept in memory + (which saves a lot of I/O, too). + <slpz> antrik: In fact, we would be doing the same as every other kernel + does, but doing it explicitly :-) + <antrik> I see the use in separating precious data (in permanent named + files) from temporary state (anonymous memory and temporary named files) + -- but I'm not sure whether having a completely separate FS for the + temporary data is the right approach for that... + <slpz> antrik: And giving the user the option to specify its own storage, + so we don't limit him to the size established for swap by the super-user. + <antrik> either way, that would be a rather radical change... still would + be good to fix tmpfs as it is first if possible + <antrik> as for limited swap, that's precisely why I'd prefer not to have + an extra swap partition at all... + <slpz> antrik: It's not much o fa change, it's how it works right now, with + the exception of replacing the default pager with its own. + <slpz> antrik: I think it's just a matter of 10-20 hours, as + much. Including testing. + <slpz> antrik: It could be forked with another name, though :-) + <antrik> slpz: I don't mean radical change in the implementation... but a + radical change in the way it would be used + <slpz> antrik: I suggest "almosttmpfs" as the name for the forked one :-P + <antrik> hehe + <antrik> how about lazyfs? + <slpz> antrik: That sound good to me, but probably we should use a more + descriptive name :-) + + +## 2011-09-29 + + <tschwinge> slpz, antrik: There is a defpager in the Hurd code. It is not + currently being used, and likely incomplete. It is backed by libstore. + I have never looked at it. + +[[open_issues/mach-defpager_vs_defpager]]. + + +# IRC, freenode, #hurd, 2011-11-08 + + <mcsim> who else uses defpager besides tmpfs and kernel? + <braunr> normally, nothing directly + <mcsim> than why tmpfs should use defpager? + <braunr> it's its backend + <braunr> backign store rather + <braunr> the backing store of most file systems are partitions + <braunr> tmpfs has none, it uses the swap space + <mcsim> if we allocate memory for tmpfs using vm_allocate, will it be able + to use swap partition? + <braunr> it should + <braunr> vm_allocate just maps anonymous memory + <braunr> anonymous memory uses swap space as its backing store too + <braunr> but be aware that this part of the vm system is known to have + deficiencies + <braunr> which is why all mach based implementations have rewritten their + default pager + <mcsim> what kind of deficiencies? + <braunr> bugs + <braunr> and design issues, making anonymous memory fragmentation horrible + <antrik> mcsim: vm_allocate doesn't return a memory object; so it can't be + passed to clients for mmap() + <mcsim> antrik: I use vm_allocate in pager_read_page + <antrik> mcsim: well, that means that you have to actually implement a + pager yourself + <antrik> also, when the kernel asks the pager to write back some pages, it + expects the memory to become free. if you are "paging" to ordinary + anonymous memory, this doesn't happen; so I expect it to have a very bad + effect on system performance + <antrik> both can be avoided by just passing a real anonymous memory + object, i.e. one provided by the defpager + <antrik> only problem is that the current defpager implementation can't + really handle that... + <antrik> at least that's my understanding of the situation diff --git a/hurd/translator/unionfs.mdwn b/hurd/translator/unionfs.mdwn index 6f845102..2b692cf9 100644 --- a/hurd/translator/unionfs.mdwn +++ b/hurd/translator/unionfs.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,18 +9,152 @@ 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]]."]]"""]] -<http://www.nongnu.org/hurdextras/#unionfs> +# `unionfs` +*Unionfs allows you to simply union one directory or translator into another one, so you see the files of both of them side by side.* -<a name="stowfs"></a> -# `stowfs` +Source repository: <http://git.savannah.gnu.org/cgit/hurd/unionfs.git/> + +Right now there are some problems with syncing, so please be aware +that it might not work as expected. + +<a name="unionmount"></a> +# `unionmount` ... is a special mode of `unionfs`. -# See Also +## Project Idea + +When setting a translator on Hurd -- similar to mounting a file system on UNIX +-- the new node(s) exported by the translator are obscuring the original node +where the translator is set, and any nodes below it in the directory tree. The +translator itself can access the underlying node (which is a very nice feature, +as it allows translators presenting the contents of the node in a different +format); but it's no longer accessible from the "outside". + +Plan9 has a feature where a file system can be mounted in union mode: the new +file system doesn't obscure the mount point in this case, but instead the +contents are combined. (This feature has also been under discussion in Linux +for a couple of years now, under the label "VFS-based union mounts".) + +This kind of union mounts is generally useful, as it's sometimes more +convenient than unioning existing filesystem locations with unionfs -- it's not +necessary to mount a file system that is to be unioned at some external +location first: just union-mount it directly at the target location. + +But union mounts also allow creating passive translator hierarchies: If there +is a passive translator on a parent node, and further passive translators on +child nodes, the union mount allows the child nodes with the further translator +settings still to be visible after the parent translator has started. + +This could be useful for device nodes for example: let's say we have an +ethernet multiplexer at /dev/veth. Now the virtual subnodes could all be +directly under /dev, i.e. /dev/veth0, /dev/veth1 etc., and explicitely refer to +the main /dev/veth node in the translator command line. It would be more +elegant however to store the virtual nodes direcly below the main multiplexer +node -- /dev/veth/0, /dev/veth/1 etc. + +There are two possible approaches how union mounts could be implemented in the +Hurd. The first one is to let the various translators handle union mounts +internally, i.e. let them present the underlying nodes to the clients in +addition to the actual nodes they export themselfs. This probably can be +implemented as some kind of extension to the existing netfs and diskfs +libraries. + +The other possible apporach is less efficient and probably more tricky, but +probably also more generic: create a special unionmount translator, which +serves as a kind of proxy: setting the union-mounted translator on some +internal node; and at the actual mount location, presenting a union of the +nodes exported by this translator, and the nodes from the underlying file +system. + +The goal of this project is implementing union mounts using either of the +approaches described above. (Though it might be useful initially to prototype +both for comparision.) The ethernet multiplexer shall serve as an example use +case -- any changes necessary to allow using it with the union mount +functionality are also to be considered part of the task. + +[[Sergiu Ivanov|scolobb]] has been working on this as a [[Google Summer of Code +2009 project|community/gsoc/2009]]. + +## Implementation + +### Source + +Union mounts are currently implemented as two additional command line +options of the `unionfs` translator. This implementation resides in +the master-unionmount branch of the unionfs git repository. To +checkout the code, do the following: + + $ git clone git://git.sv.gnu.org/hurd/unionfs.git + $ cd unionfs + $ git checkout -b master-unionmount + $ git pull origin master-unionmount + +You can skip the checkout step if you don't mind that the +`master-unionmount` branch gets merged into the `master` branch. + +### Short Documentation + +The `unionmount` project adds options "--mount" and "--no-mount" to +`unionfs` (short versions: "-t" and "-n" correspondingly). Both +options are used to implement union-mounting, but the first option +will create a *transparent* union mount, while the second option will +create a *nontransparent* union mount. - * [[unionmount]] +One can create a transparent union mount with the following command: + + $ settrans -a <node> unionfs --underlying --mount=<translator> + +When running + + $ fsysopts <node> + +one will see the information about the `<translator>`, not the +`unionfs` translator. Although this might seem the only natural way +to do union mounts, one must keep in mind that such transparency +deprives one of the possibility to modify the unioned virtual +filesystem exported by `unionfs` at run-time (via `fsysopts`). + +One can create a nontransparent union mount with the following command: + + $ settrans -a <node> unionfs --underlying --no-mount=<translator> + +When running + + $ fsysopts <node> + +one will see the information about the `unionfs` translator. Although +this way allows modifying the contents of the unioned filesystem +exported by `unionfs` at runtime, the access to `<translator>` is +blocked. + +The filesystem exported by the *mountee* (`<translator>`) is actually +treated like a normal filesystem within `unionfs`, which means that +one can assign priorities to the *mountee* to achieve the desired +order of layering of the unioned directories. The following will make +`unionfs` query the underlying filesystem first and then the +*mountee*: + + $ settrans -a <node> unionfs --priority=2 --underlying --priority=1 --mount=<translator> + +Note that the same functionality can also be achieved by assigning +priority 1 to the underlying filesystem and keeping the priority of +the *mountee* at 0. + +<a name="stowfs"></a> +# `stowfs` + +... is a special mode of `unionfs`. # External Links * [*Unioning file systems for Linux*](http://valerieaurora.org/union/) + + * [FUSE page about + `unionfs`](http://sourceforge.net/apps/mediawiki/fuse/index.php?title=UnionFileSystems) + + * [Linux' overlay file system proposal, + 2010-09-20](http://thread.gmane.org/gmane.linux.kernel/1038413) + + How is this different? diff --git a/hurd/translator/unionmount.mdwn b/hurd/translator/unionmount.mdwn index 47a3d85d..7384afc7 100644 --- a/hurd/translator/unionmount.mdwn +++ b/hurd/translator/unionmount.mdwn @@ -8,53 +8,4 @@ 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="Union Mounts"]] - -When setting a translator on Hurd -- similar to mounting a file system on UNIX --- the new node(s) exported by the translator are obscuring the original node -where the translator is set, and any nodes below it in the directory tree. The -translator itself can access the underlying node (which is a very nice feature, -as it allows translators presenting the contents of the node in a different -format); but it's no longer accessible from the "outside". - -Plan9 has a feature where a file system can be mounted in union mode: the new -file system doesn't obscure the mount point in this case, but instead the -contents are combined. (This feature has also been under discussion in Linux -for a couple of years now, under the label "VFS-based union mounts".) - -This kind of union mounts is generally useful, as it's sometimes more -convenient than unioning existing filesystem locations with unionfs -- it's not -necessary to mount a file system that is to be unioned at some external -location first: just union-mount it directly at the target location. - -But union mounts also allow creating passive translator hierarchies: If there -is a passive translator on a parent node, and further passive translators on -child nodes, the union mount allows the child nodes with the further translator -settings still to be visible after the parent translator has started. - -This could be useful for device nodes for example: let's say we have an -ethernet multiplexer at /dev/veth. Now the virtual subnodes could all be -directly under /dev, i.e. /dev/veth0, /dev/veth1 etc., and explicitely refer to -the main /dev/veth node in the translator command line. It would be more -elegant however to store the virtual nodes direcly below the main multiplexer -node -- /dev/veth/0, /dev/veth/1 etc. - -There are two possible approaches how union mounts could be implemented in the -Hurd. The first one is to let the various translators handle union mounts -internally, i.e. let them present the underlying nodes to the clients in -addition to the actual nodes they export themselfs. This probably can be -implemented as some kind of extension to the existing netfs and diskfs -libraries. - -The other possible apporach is less efficient and probably more tricky, but -probably also more generic: create a special unionmount translator, which -serves as a kind of proxy: setting the union-mounted translator on some -internal node; and at the actual mount location, presenting a union of the -nodes exported by this translator, and the nodes from the underlying file -system. - -The goal of this project is implementing union mounts using either of the -approaches described above. (Though it might be useful initially to prototype -both for comparision.) The ethernet multiplexer shall serve as an example use -case -- any changes necessary to allow using it with the union mount -functionality are also to be considered part of the task. +[[!meta redir=unionfs#unionmount]] diff --git a/hurd/translator/wishlist_2.mdwn b/hurd/translator/wishlist_2.mdwn index a927db55..77f39644 100644 --- a/hurd/translator/wishlist_2.mdwn +++ b/hurd/translator/wishlist_2.mdwn @@ -70,7 +70,17 @@ Here's an [idea](http://www.circlemud.org/~jelson/software/fusd/docs/node13.html * "One particularly interesting application of FUSD that we've found very useful is as a way to let regular user-space libraries export device file APIs. For example, imagine you had a library which factored large composite numbers. Typically, it might have a C interface--say, a function called `int *factorize(int bignum)`. With FUSD, it's possible to create a device file interface--say, a device called `/dev/factorize` to which clients can `write(2)` a big number, then `read(2)` back its factors. -* This may sound strange, but device file APIs have at least three advantages over a typical library API. First, it becomes much more language independent--any language that can make system calls can access the factorization library. Second, the factorization code is running in a different address space; if it crashes, it won't crash or corrupt the caller. Third, and most interestingly, it is possible to use `select(2)` to wait for the factorization to complete. `select(2)` would make it easy for a client to factor a large number while remaining responsive to other events that might happen in the meantime. In other words, FUSD allows normal user-space libraries to integrate seamlessly with UNIX's existing, POSIX-standard event notification interface: `select(2)`." +* This may sound strange, but device file APIs have at least three advantages + over a typical library API. First, it becomes much more language + independent--any language that can make [[system call]]s can access the + factorization library. Second, the factorization code is running in a + different address space; if it crashes, it won't crash or corrupt the + caller. Third, and most interestingly, it is possible to use `select(2)` to + wait for the factorization to complete. `select(2)` would make it easy for a + client to factor a large number while remaining responsive to other events + that might happen in the meantime. In other words, FUSD allows normal + user-space libraries to integrate seamlessly with UNIX's existing, + POSIX-standard event notification interface: `select(2)`." ## <a name="Mail"> Mail </a> diff --git a/hurd/virtual_file_system.mdwn b/hurd/virtual_file_system.mdwn index 1e2f68fb..b62a5e4c 100644 --- a/hurd/virtual_file_system.mdwn +++ b/hurd/virtual_file_system.mdwn @@ -13,7 +13,7 @@ No single entity is responsible for the resolution of path names. A file system server (a [[translator]]) attaches to translators (`fs.defs:file_set_translator`). -When a process resolves an aboslute path, it queries +When a process resolves an absolute path, it queries its root file system server by invoking the `fs.defs:dir_lookup` method in the capability in its root directory slot. The file system server resolves as much as it knows about locally diff --git a/hurd/virtual_file_system/discussion.mdwn b/hurd/virtual_file_system/discussion.mdwn new file mode 100644 index 00000000..9e12d01e --- /dev/null +++ b/hurd/virtual_file_system/discussion.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-11-12: + + <sea4ever> So hurd implements a 'transparent translator' somewhere which + just passes all IO calls to the posix IO I'm used to? (i.e. read, write, + open, close, etc.?) + <youpi> it's the normal way of operation + <youpi> glibc's read() doesn't do a system call, it always does an RPC to + the underlying translator + <youpi> be it ext2fs for /, or your foobarfs for your node + <sea4ever> Ok that makes sense. How does one program know which translator + it should refer to though? + <sea4ever> the read() call magically knows which process to invoke? + <youpi> the / translator is always known + <youpi> and then you ask /'s translator about /home, then /home/you, then + /home/you/foobar + <youpi> it tells you which other translator tyou have to contact + <youpi> that's on open + <sea4ever> It's a tree! Ok. + <youpi> the notion of fd is then simply knowing the translator + <sea4ever> Right. 'file descriptor' is now 'translator address descriptor' + maybe. + <youpi> it's glibc which knows about FDs, nothing else knows + <youpi> yes + <youpi> actually an RPC port, simply + <sea4ever> I want to try out the new RPC mechanism that mach implements + <youpi> err, which "new" RPC ? + <youpi> mach's RPCs are very old actually :) diff --git a/hurd/virtualization.mdwn b/hurd/virtualization.mdwn index 42f83f77..49e911c2 100644 --- a/hurd/virtualization.mdwn +++ b/hurd/virtualization.mdwn @@ -1,13 +1,17 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Olaf Buddenhagen has written a text about how [[/virtualization]] is applicable within Hurd systems: <http://tri-ceps.blogspot.com/2007/10/advanced-lightweight-virtualization.html> + +We also have [[a lot of Open Issues about virtualization +topics|open_issues/virtualization]]. diff --git a/hurd/what_is_the_gnu_hurd.mdwn b/hurd/what_is_the_gnu_hurd.mdwn index 0b8f7ef6..7a7f3d43 100644 --- a/hurd/what_is_the_gnu_hurd.mdwn +++ b/hurd/what_is_the_gnu_hurd.mdwn @@ -1,17 +1,18 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2007, 2008 Free -Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, +2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="What Is the GNU Hurd?"]] -The Hurd is the GNU project's replacement for the [[Unix]] kernel. +The Hurd is the GNU project's replacement for [[UNIX]], a popular operating +system [[kernel]]. The Hurd is firstly a collection of protocols formalizing how different components may interact. The protocols are designed to reduce the mutual @@ -22,11 +23,19 @@ process to implement a file system. The only requirement is that it have access to its backing store and that the [[principal]] that started it own the file system node to which it connects. -The Hurd is also a set of servers that implement these protocols. -They include file systems, network protocols and authentication. +The Hurd is also a set of [[servers|translator]] that implement these +protocols. They include file systems, network protocols and authentication. The servers run on top of the [[microkernel/Mach]] [[microkernel]] and use Mach's [[microkernel/mach/IPC]] mechanism to transfer information. +The Hurd provides a compatibility layer such that compiling higher level +programs is essentially transparent; that is, by means of the [[glibc]], it +provides the same standard interfaces known from other [[UNIX]]-like systems. +Thus, for a typical user, the Hurd is intended to silently work in the +background providing the services and infrastructure which the [[microkernel]] +itself has no business implementing, but that are required for higher level +programs and libraries to operate. + The Hurd supplies the last major software component needed for a complete [[GNU_operating_system|running/gnu]] as originally conceived by Richard M. Stallman (RMS) in 1983. The GNU vision directly drove the creation and has @@ -1,15 +1,24 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 2010 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -An IDL is an interface definition language. The most well-known is -CORBA. An IDL compiler takes a specification and generates stubs -that hide the transport details. In the case of [[microkernel/mach/MIG]], this -hides the marshalling and unmarshalling of parameters according -to [[microkernel/Mach]]'s semantics. +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="IDL"]] + +An *IDL* is an *interface definition language* ([[!wikipedia +Interface_description_language desc="Wikipedia article"]]). A well-known one +is CORBA. These are [[DSL]]s. + +An IDL compiler takes a specification and generates stub code that hides the +transport details, and by this implements a [[RPC]] system. + +In the case of [[Mach's MIG|microkernel/mach/mig]], this hides the marshalling +and unmarshalling of procedures' parameters to and from +[[microkernel/mach/message]] format, according to [[microkernel/Mach]]'s +semantics, and invoking the respective [[microkernel/mach/port]] operations. diff --git a/ikiwiki.setup b/ikiwiki.setup index aee01480..9ae1f669 100644 --- a/ikiwiki.setup +++ b/ikiwiki.setup @@ -1,9 +1,10 @@ #!/usr/bin/perl -# Setup file for ikiwiki. # +# Setup file for ikiwiki. +# # Passing this to ikiwiki --setup will make ikiwiki generate # wrappers and build the wiki. -# +# # Remember to re-run ikiwiki --setup any time you edit this file. require IkiWiki::Setup::Standard; @@ -38,7 +39,11 @@ IkiWiki::Setup::Standard->import({ # users who are wiki admins adminuser => [qw{tschwinge}], # users who are banned from the wiki - banned_users => [], + banned_users => [qw{AlbertF bernhart ColetCris flamberian Jack_Dark + jasclaine NateNash + http://calvinyoung.myopenid.com/ + http://heaton.myopenid.com/ + http://hilarybunton.myopenid.com/}], # where the source of the wiki is located srcdir => $srcdir, # where to build the wiki @@ -54,10 +59,14 @@ IkiWiki::Setup::Standard->import({ # rcs backend to use rcs => 'git', # plugins to add to the default configuration - add_plugins => [qw{goodstuff cutpaste editdiff edittemplate favicon html sidebar table txt copyright license texinfo}], + add_plugins => [qw{goodstuff + cutpaste editdiff edittemplate favicon getsource + html rename repolist search sidebar table txt + field getfield ymlfront + copyright license texinfo}], # plugins to disable disable_plugins => [], - # location of template files + # additional directory to search for template files templatedir => $srcdir.'/.templates', # base wiki source location #underlaydir => '/usr/share/ikiwiki/basewiki', @@ -73,6 +82,10 @@ IkiWiki::Setup::Standard->import({ indexpages => 0, # enable Discussion pages? discussion => 1, + # name of Discussion pages + discussionpage => 'Discussion', + # generate HTML5? (experimental) + html5 => 0, # only send cookies over SSL connections? sslcookie => 0, # extension to use for new pages @@ -97,16 +110,25 @@ IkiWiki::Setup::Standard->import({ libdir => $srcdir.'/.library', # environment variables ENV => {}, - # regexp of source files to ignore - #exclude => '\\.wav$', + # regexp of normally excluded files to include + #include => '^\\.htaccess$', + # regexp of files that should be skipped + #exclude => '^(*\\.private|Makefile)$', # specifies the characters that are allowed in source filenames wiki_file_chars => '-[:alnum:]+/.:_', # allow symlinks in the path leading to the srcdir (potentially insecure) #allow_symlinks_before_srcdir => 0, + ###################################################################### + # core plugins + # (editpage, git, htmlscrubber, inline, link, meta, parentlinks) + ###################################################################### + # git plugin # git hook to generate git_wrapper => $git_wrapper, + # shell command for git_wrapper to run, in the background + #git_wrapper_background_command => 'git push github', # mode for git_wrapper (can safely be made suid) git_wrappermode => '0700', # git pre-receive hook to generate @@ -114,30 +136,40 @@ IkiWiki::Setup::Standard->import({ # unix users whose commits should be checked by the pre-receive hook #untrusted_committers => [], # gitweb url to show file history ([[file]] substituted) - historyurl => 'http://www.bddebian.com:8888/gitweb/?p=hurd-web;a=history;f=[[file]]', + historyurl => 'http://www.bddebian.com:8888/gitweb/?p=hurd-web;a=history;f=[[file]];hb=HEAD', # gitweb url to show a diff ([[file]], [[sha1_to]], [[sha1_from]], [[sha1_commit]], and [[sha1_parent]] substituted) - diffurl => 'http://www.bddebian.com:8888/gitweb/?p=hurd-web;a=blobdiff;h=[[sha1_to]];hp=[[sha1_from]];hb=[[sha1_parent]];f=[[file]]', + diffurl => 'http://www.bddebian.com:8888/gitweb/?p=hurd-web;a=blobdiff;f=[[file]];h=[[sha1_to]];hp=[[sha1_from]];hb=[[sha1_commit]];hpb=[[sha1_parent]]', # where to pull and push changes (set to empty string to disable) gitorigin_branch => $gitorigin_branch, # branch that the wiki is stored in gitmaster_branch => 'master', - # aggregate plugin - # enable aggregation to internal pages? - #aggregateinternal => 1, - # allow aggregation to be triggered via the web? - #aggregate_webtrigger => 0, + # htmlscrubber plugin + # PageSpec specifying pages not to scrub + #htmlscrubber_skip => '!*/Discussion', + + # inline plugin + # enable rss feeds by default? + rss => 1, + # enable atom feeds by default? + atom => 1, + # allow rss feeds to be used? + #allowrss => 0, + # allow atom feeds to be used? + #allowatom => 0, + # urls to ping (using XML-RPC) on feed update + pingurl => [], + + ###################################################################### + # auth plugins + # (anonok, blogspam, httpauth, lockedit, moderatedcomments, + # opendiscussion, openid, passwordauth, signinedit) + ###################################################################### # anonok plugin # PageSpec to limit which pages anonymous users can edit #anonok_pagespec => '*/discussion', - # attachment plugin - # enhanced PageSpec specifying what attachments are allowed - #allowed_attachments => 'virusfree() and mimetype(image/*) and maxsize(50kb)', - # virus checker program (reads STDIN, returns nonzero if virus found) - #virus_checker => 'clamdscan -', - # blogspam plugin # PageSpec of pages to check for spam #blogspam_pagespec => 'postcomment(*)', @@ -146,23 +178,66 @@ IkiWiki::Setup::Standard->import({ # blogspam server XML-RPC url #blogspam_server => '', - # bzr plugin - # bzr post-commit hook to generate - #bzr_wrapper => '', - # mode for bzr_wrapper (can safely be made suid) - #bzr_wrappermode => '06755', - # url to show file history, using loggerhead ([[file]] substituted) - #historyurl => '', - # url to view a diff, using loggerhead ([[file]] and [[r2]] substituted) - #diffurl => 'http://example.com/revision?start_revid=[[r2]]#[[file]]-s', + # httpauth plugin + # url to redirect to when authentication is needed + #cgiauthurl => 'http://example.com/wiki/auth/ikiwiki.cgi', + # PageSpec of pages where only httpauth will be used for authentication + #httpauth_pagespec => '!*/Discussion', - # calendar plugin - # base of the archives hierarchy - #archivebase => 'archives', + # lockedit plugin + # PageSpec controlling which pages are locked + #locked_pages => '!*/Discussion', - # camelcase plugin - # list of words to not turn into links - #camelcase_ignore => [], + # moderatedcomments plugin + # PageSpec matching users or comment locations to moderate + #moderate_pagespec => '*', + + # openid plugin + # url pattern of openid realm (default is cgiurl) + #openid_realm => '', + # url to ikiwiki cgi to use for openid authentication (default is cgiurl) + #openid_cgiurl => '', + + # passwordauth plugin + # a password that must be entered when signing up for an account + #account_creation_password => 's3cr1t', + # cost of generating a password using Authen::Passphrase::BlowfishCrypt + #password_cost => 8, + + ###################################################################### + # format plugins + # (creole, highlight, hnb, html, mdwn, otl, rawhtml, textile, txt) + ###################################################################### + + # highlight plugin + # types of source files to syntax highlight + #tohighlight => '.c .h .cpp .pl .py Makefile:make', + # location of highlight's filetypes.conf + #filetypes_conf => '/etc/highlight/filetypes.conf', + # location of highlight's langDefs directory + #langdefdir => '/usr/share/highlight/langDefs', + + # mdwn plugin + # enable multimarkdown features? + #multimarkdown => 0, + + ###################################################################### + # misc plugins + # (filecheck) + ###################################################################### + + ###################################################################### + # web plugins + # (404, attachment, comments, editdiff, edittemplate, getsource, + # google, goto, mirrorlist, remove, rename, repolist, search, + # theme, websetup, wmd) + ###################################################################### + + # attachment plugin + # enhanced PageSpec specifying what attachments are allowed + #allowed_attachments => 'virusfree() and mimetype(image/*) and maxsize(50kb)', + # virus checker program (reads STDIN, returns nonzero if virus found) + #virus_checker => 'clamdscan -', # comments plugin # PageSpec of pages where comments are allowed @@ -178,67 +253,101 @@ IkiWiki::Setup::Standard->import({ # commit comments to the VCS #comments_commit => 1, - # darcs plugin - # wrapper to generate (set as master repo apply hook) - #darcs_wrapper => '/darcs/repo/_darcs/ikiwiki-wrapper', - # mode for darcs_wrapper (can safely be made suid) - #darcs_wrappermode => '06755', - # darcsweb url to show file history ([[file]] substituted) - #historyurl => 'http://darcs.example.com/darcsweb.cgi?r=wiki;a=filehistory;f=[[file]]', - # darcsweb url to show a diff ([[hash]] and [[file]] substituted) - #diffurl => 'http://darcs.example.com/darcsweb.cgi?r=wiki;a=filediff;h=[[hash]];f=[[file]]', + # getsource plugin + # Mime type for returned source. + #getsource_mimetype => 'text/plain; charset=utf-8', - # htmlscrubber plugin - # PageSpec specifying pages not to scrub - #htmlscrubber_skip => '!*/Discussion', + # mirrorlist plugin + # list of mirrors + #mirrorlist => {}, - # inline plugin - # enable rss feeds by default? - rss => 1, - # enable atom feeds by default? - atom => 1, - # allow rss feeds to be used? - #allowrss => 0, - # allow atom feeds to be used? - #allowatom => 0, - # urls to ping (using XML-RPC) on feed update - pingurl => [], + # repolist plugin + # URIs of repositories containing the wiki's source + repositories => [qw{git://git.savannah.gnu.org/hurd/web.git + http://git.savannah.gnu.org/r/hurd/web.git + git://flubber.bddebian.com/~hurd-web/hurd-web + http://www.bddebian.com:8888/git/hurd-web}], + + # search plugin + # path to the omega cgi program + #omega_cgi => '/usr/lib/cgi-bin/omega/omega', + + # theme plugin + # name of theme to enable + #theme => 'actiontabs', + + # websetup plugin + # list of plugins that cannot be enabled/disabled via the web interface + #websetup_force_plugins => [], + # list of additional setup field keys to treat as unsafe + #websetup_unsafe => [], + # show unsafe settings, read-only, in web interface? + #websetup_show_unsafe => 1, + + ###################################################################### + # widget plugins + # (calendar, color, conditional, cutpaste, date, format, fortune, + # graphviz, haiku, img, linkmap, listdirectives, map, more, + # orphans, pagecount, pagestats, poll, polygen, postsparkline, + # progress, shortcut, sparkline, table, template, teximg, toc, + # toggle, version) + ###################################################################### + + # calendar plugin + # base of the archives hierarchy + #archivebase => 'archives', + # PageSpec of pages to include in the archives; used by ikiwiki-calendar command + #archive_pagespec => 'page(posts/*) and !*/Discussion', # listdirectives plugin # directory in srcdir that contains directive descriptions #directive_description_dir => 'ikiwiki/directive', - # lockedit plugin - # PageSpec controlling which pages are locked - #locked_pages => '!*/Discussion', + # teximg plugin + # Should teximg use dvipng to render, or dvips and convert? + #teximg_dvipng => '', + # LaTeX prefix for teximg plugin + #teximg_prefix => '\\documentclass{article} + #\\usepackage{amsmath} + #\\usepackage{amsfonts} + #\\usepackage{amssymb} + #\\pagestyle{empty} + #\\begin{document} + #', + # LaTeX postfix for teximg plugin + #teximg_postfix => '\\end{document}', - # mdwn plugin - # enable multimarkdown features? - #multimarkdown => 0, + ###################################################################### + # other plugins + # (aggregate, autoindex, brokenlinks, camelcase, ddate, embed, + # favicon, field, flattr, getfield, goodstuff, htmlbalance, + # localstyle, pagetemplate, pingee, pinger, prettydate, + # recentchanges, recentchangesdiff, relativedate, rsync, + # sidebar, smiley, sortnaturally, tag, testpagespec, underlay, + # ymlfront) + ###################################################################### - # mercurial plugin - # mercurial post-commit hook to generate - #mercurial_wrapper => '', - # mode for mercurial_wrapper (can safely be made suid) - #mercurial_wrappermode => '06755', - # url to hg serve'd repository, to show file history ([[file]] substituted) - #historyurl => 'http://example.com:8000/log/tip/[[file]]', - # url to hg serve'd repository, to show diff ([[file]] and [[r2]] substituted) - #diffurl => 'http://localhost:8000/?fd=[[r2]];file=[[file]]', + # aggregate plugin + # enable aggregation to internal pages? + #aggregateinternal => 1, + # allow aggregation to be triggered via the web? + #aggregate_webtrigger => 0, - # mirrorlist plugin - # list of mirrors - #mirrorlist => {}, + # camelcase plugin + # list of words to not turn into links + #camelcase_ignore => [], - # openid plugin - # an url where users can signup for an OpenID - #openidsignup => 'http://myopenid.com/', + # field plugin + # simple registration of fields by plugin + #field_register => {meta => 'last'}, + # allow config settings to be queried + #field_allow_config => 0, + # fields flagged as tag-fields + #field_tags => {BookAuthor => '/books/authors'}, - # passwordauth plugin - # a password that must be entered when signing up for an account - #account_creation_password => 's3cr1t', - # cost of generating a password using Authen::Passphrase::BlowfishCrypt - #password_cost => 8, + # flattr plugin + # userid or user name to use by default for Flattr buttons + #flattr_userid => 'joeyh', # pinger plugin # how many seconds to try pinging before timing out @@ -254,63 +363,25 @@ IkiWiki::Setup::Standard->import({ # number of changes to track recentchangesnum => 100, - # repolist plugin - # URIs of repositories containing the wiki's source - #repositories => [qw{svn://svn.example.org/wiki/trunk}], - - # search plugin - # path to the omega cgi program - #omega_cgi => '/usr/lib/cgi-bin/omega/omega', + # rsync plugin + # command to run to sync updated pages + #rsync_command => 'rsync -qa --delete . user@host:/path/to/docroot/', - # svn plugin - # subversion repository location - #svnrepo => '/svn/wiki', - # path inside repository where the wiki is located - #svnpath => 'trunk', - # svn post-commit hook to generate - #svn_wrapper => '/svn/wikirepo/hooks/post-commit', - # mode for svn_wrapper (can safely be made suid) - #svn_wrappermode => '04755', - # viewvc url to show file history ([[file]] substituted) - #historyurl => 'http://svn.example.org/trunk/[[file]]', - # viewvc url to show a diff ([[file]], [[r1]], and [[r2]] substituted) - #diffurl => 'http://svn.example.org/trunk/[[file]]?root=wiki&r1=[[r1]]&r2=[[r2]]', + # sidebar plugin + # show sidebar page on all pages? + #global_sidebars => 1, # tag plugin # parent page tags are located under tagbase => 'tag', - - # teximg plugin - # Should teximg use dvipng to render, or dvips and convert? - #teximg_dvipng => '', - # LaTeX prefix for teximg plugin - #teximg_prefix => '\\documentclass{article} - #\\usepackage{amsmath} - #\\usepackage{amsfonts} - #\\usepackage{amssymb} - #\\pagestyle{empty} - #\\begin{document} - #', - # LaTeX postfix for teximg plugin - #teximg_postfix => '\\end{document}', - - # tla plugin - # tla post-commit hook to generate - #tla_wrapper => '', - # mode for tla_wrapper (can safely be made suid) - #tla_wrappermode => '06755', - # url to show file history ([[file]] substituted) - #historyurl => '', - # url to show a diff ([[file]] and [[rev]] substituted) - #diffurl => '', + # autocreate new tag pages? + #tag_autocreate => 1, # underlay plugin # extra underlay directories to add #add_underlays => '', - # websetup plugin - # list of plugins that cannot be enabled/disabled via the web interface - #websetup_force_plugins => [], - # show unsafe settings, read-only, in web interface? - #websetup_show_unsafe => 1, + # ymlfront plugin + # delimiters of YAML data + ymlfront_delim => [qw{--YAML-START-- --YAML-END--}], }) @@ -1,13 +1,13 @@ [[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, -2009 Free Software Foundation, Inc."]] +2009, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] <div id="statements"> <div id="what-is"> @@ -17,7 +17,7 @@ It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux). -<em>[[More_detailed|hurd/what_is_the_gnu_hurd]].</em></p> +<em>[[More_detailed|hurd/documentation]].</em></p> </div> <div id="mission"> <p class="statement-title">What is the mission of the GNU Hurd project?</p> @@ -25,52 +25,50 @@ kernels (such as Linux). for the GNU operating system, which is viable for everyday use, and gives users and programs as much control over their computing environment as possible. -<em>[[Our mission explained|community/weblogs/antrik/hurd-mission-statement]].</em></p> +<em>[[Our_mission_explained|community/weblogs/antrik/hurd-mission-statement]].</em></p> </div> </div> --- -[[!toc]] +[[!toc levels=2]] -## News +# News [[!inline pages="news/* and !*/discussion" feedonly=yes -feedshow=10 -sort=title -reverse=yes]] +feedshow=10]] [[!inline pages="news/* and !*/discussion" show=5 feeds=no -sort=title -reverse=yes template=newsitem actions=yes]] -Read [[older_news_entries|news]]. +Older news entries can be found in the [[news archive|news]]. For Hurd +developers' musings have a look at the [[shared weblog|community/weblogs]]. +The [[recent changes]] page lists the latest changes of this website. -## Contributing +# Contributing -To help the Hurd you can for example (from high level stuff to the inner core) +So, you are interested in contributing to the GNU Hurd project? Welcome! +Every single contribution is very much encouraged. Please read our [[detailed +recommendations about how to contribute|contributing]]. -* [[Contribute_to_these_web_pages|contributing/web_pages]], -* [[Run_a_GNU/Hurd_system|index#run]], and help others get their systems running, -* [[Port_applications|hurd/running/debian/porting]] to work in Hurd, -* Write [[translators|hurd/translator]] to extend the Hurd, -* Work on the [[Hurd_on_Mach|contributing#hurd_on_mach]], or -* Help to port the Hurd [[to_a_modern_microkernel|contributing#hurd_on_modern_microkernel]]. +See our [[source_repositories]] for the source code. -Read about ways to contribute [[in_more_detail|contributing]]. +## Access to a GNU/Hurd System +We provide accounts on our [[public_Hurd_boxen]], and there are also +[[hurd/running/QEMU]] images available. -## Getting Help -There are a couple of different [[Hurd_FAQs|hurd/FAQ]]. +# Getting Help + +There are a couple of different [[FAQ lists|FAQ]]. There are a number of [[IRC_channels|IRC]] and several different [[mailing lists]] with searchable archives. @@ -79,8 +77,9 @@ answer your own question using a search engine and reading the introductory information. If you have done this and you cannot find the answer to your question, feel free to ask on a mailing list or on IRC. + <a name="run"> </a> -## Running the Hurd +# Running the Hurd The most functional distribution of the Hurd is the one provided by Debian. Find more information about it at the @@ -97,7 +96,7 @@ And these web pages are a living proof of the usability of the Hurd, as they are rendered on a [[Debian_GNU/Hurd|hurd/running/debian]] system. -## Current Status +# Current Status There has not yet been an official 1.0 release. The Hurd is developed by a few volunteers in their spare time. The project welcomes any assistance you can provide. @@ -112,19 +111,22 @@ Community resources for related projects focus around these pages, If you want to see the current discussions in the Hurd project, please have a look at the [bug-hurd mailinglist archives](http://lists.gnu.org/pipermail/bug-hurd/). +If you want to have a look at the current coding work, you can just head over to our +[[source_repositories]]. For more details, please read our writeup on the [[current_state_of_the_GNU_Hurd|hurd/status]]. -## How is this site arranged? +## Advantages and Challenges -The menu on the upper right corner provides a rough structuring about the -available content. Just follow those topics and explore these pages. +The GNU Hurd operating system design provides [[advantages]], but uncovers new +[[challenges]], too. -Further information about this site and how it was created can be found in the -[[colophon]]. ---- These pages are powered by [ikiwiki](http://ikiwiki.info/). + +Further information about this site and how it was created can be found in the +[[colophon]]. diff --git a/install.mdwn b/install.mdwn new file mode 100644 index 00000000..1a7416de --- /dev/null +++ b/install.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!tag stable_URL]] + +[[!meta redir=hurd/running]] @@ -1,16 +1,17 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -IPC stands for interprocess communication. +*IPC* stands for *inter-process communication*. -On [[Unix]], interprocess communication can be achieved using pipes. +On [[Unix]], inter-process communication can be achieved using pipes. This is inefficient for large amounts of data as the data must be copied. This is generally not a problem as most services are provided by the Unix kernel and Unix is not designed to be @@ -22,13 +23,35 @@ of many components. As components are separated by their respective examine and modify the caller's state. The advantage is that if the protocol is carefully designed, the callee cannot cause the caller any [[destructive_interference]] thereby removing the need for the -caller to [[trust]] the callee thus reducing the former's [[tcb]]. +caller to [[trust]] the callee thus reducing the former's [[TCB]]. When done systematically, this can increase the system's [[robustness]]. To this end, microkernels provide richer IPC semantics that include the ability to transfer [[capabilities|capability]] and to use [[virtual_memory]] [[mechanism]]s to copy data. +Continue reading about [[Mach's IPC system|microkernel/mach/IPC]]. + + +<a name="performance"></a> +# Performance + + * {{$performance_irrelevance}} + # See Also -* [[RPC]] + * [[RPC]] + + +[[!ymlfront data=""" + +performance_irrelevance: + + "Brian N. Bershad, 1992: [The Increasing Irrelevance of IPC Performance for + Microkernel-Based Operating + Systems](http://www.cs.cmu.edu/afs/cs/project/mach/public/www/doc/abstracts/IPCperf.html) + ([doc](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/published/IPCperf.doc), + [ps](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/published/IPCperf.ps), + [CiteSeerX](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.16))" + +"""]] @@ -1,82 +1,67 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2006, 2007, 2008, 2009 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2006, 2007, 2008, 2009, +2010, 2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="IRC"]] -While all official development takes place on the mailing lists and the Savannah trackers, -a lot of discussions are had on IRC as well. Everybody is welcome to join and follow these channels, but please -respect the below guidelines if you want to participate. - -# Asking Questions - -[[!inline pages=asking_questions raw=yes feeds=no]] - -# Staying On-Topic +There are some IRC channels where Hurd topics are discussed. -Please try to stay on topic. +Everybody is welcome to join and participate in the discussions, but please +respect the below guidelines if you want to participate. -* emacs vs. vi **is not** on topic -* If it is appropriate for a **slashdot comment**, it's **not appropriate** - here -* why GNU sucks is **off-topic** -* when the next release of the Hurd will be **is inappropriate** -* you should not advocate your favorite **GNU/Linux** ditribution +Please try to stay on topic. We're not interested in Emacs vs. vi discussions, +we don't want to hear why you think that the GNU project sucks, or what your +favorite GNU/Linux distribution is. -# Pasting Logs +[[!inline pages=asking_questions raw=yes feeds=no]] Sometimes providing a log or some other excerpt of text can -help solve a problem or answer a question. **Do not** paste -the log in the channel itself. Instead use a +help solve a problem or answer a question. Do not paste +the log in the channel itself if it's more than a few lines. Instead use a [paste bin](http://paste.debian.net). -# Rich Text - -Don't use it. Don't use colors. Don't use bold. Don't use emphasis. - -# Greeting - -If you never contribute to the discussion, there is no need -to always greet the channel when you enter and before leave. - <a name="regular_meetings"></a> # Regular Meetings Starting in early 2008, there have been regular IRC meetings held between the -(now former) [[community/GSoC]] students and their mentors. These continue to -take place even that the [[Google_Summer_of_Code_2008|community/gsoc/2008]] is -over, and still take place, currently **every Tuesday and Friday at 12:00 UTC in the `#hurd` -channel**. Of course, the meetings are not only for (former) GSoC students and -mentors, but open to any interested party. So, everyone, take your chance to -chat with GNU Hurd developers! +(now former) [[Google Summer of Code|community/gsoc]] students and their +mentors. These meetings turned out to considerably help student-mentor +interactions, and other developers regularely took part, too. +For this reason, we decided to continue having these meetings, even if it's not +currently Google Summer of Code time. +Currently, the meetings take place in the **`#hurd` channel every +Thursday at 19:00 UTC** and are open to any interested party. So, +everyone, take your chance to chat with GNU Hurd developers! # Channels -All Hurd IRC channels are hosted on [Freenode.net](http://freenode.net/). +## Freenode + +`irc.freenode.net`, <http://freenode.net/> + + * `#hurd`, the official GNU Hurd IRC channel. Some of the Hurd developers + and users hang out there. [Logs](http://richtlijn.be/~larstiq/hurd/). + + * `#hurdfr`, the French chapter. -* #hurd - The official Hurd IRC channel. Some of the Hurd developers and users hang out there, and discussions about GNU Hurd, GNU/Hurd and -Debian GNU/Hurd are had there. + * `#archhurd`, [[hurd/running/Arch_Hurd]]. + [Logs](http://files.archhurd.org/irclogs). -Local user channels include: -* #hurd-it - Italian -* #hurd-es - Spanish -* #hurdfr - French -* #hurd-de - German -* #hurd.in - Indian regional languages(but primarily English) +## OFTC -# Channel logs +`irc.oftc.net`, <http://www.oftc.net/> -* [#hurd logs](http://richtlijn.be/~larstiq/hurd/) + * `#debian-hurd`, [[Debian GNU/Hurd|hurd/running/debian]]. # Related diff --git a/kernel.mdwn b/kernel.mdwn new file mode 100644 index 00000000..8190660e --- /dev/null +++ b/kernel.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 2010 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The kernel of an operating system is a fundamental program which provides +essential resources from the hardware of the computer to other programs. + +A kernel typically runs all the time and remains resident in main memory. + +The amount of functionality and resources which it provides vary tremendously. + + * [[microkernel]] + + * [[UNIX]] diff --git a/libpthread.mdwn b/libpthread.mdwn new file mode 100644 index 00000000..b31876b3 --- /dev/null +++ b/libpthread.mdwn @@ -0,0 +1,30 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="POSIX Threading Library"]] + + +# Sources + +<http://git.savannah.gnu.org/cgit/hurd/libpthread.git/> + + +# Specifics + +Porting libpthread to a specific architecture is non-trivial. + +Our libpthread is currently used by / ported to the [[Hurd]] on [[GNU +Mach|microkernel/mach/gnumach]], some [[microkernel/L4]] variants, and +[[microkernel/Viengoos]]. + + +# Open Issues + +[[!inline pages=tag/open_issue_libpthread raw=yes feeds=no]] @@ -1,6 +1,6 @@ /* ikiwiki local style sheet - Copyright © 2007, 2008 Free Software Foundation, Inc. + Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, Inc. 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 @@ -51,7 +51,6 @@ pre margin-left: 3em; font-weight: bold; padding: 0.5em; - overflow: auto; } a @@ -138,7 +137,7 @@ a:hover padding: 0.5em; } -#sidebar +.sidebar { background-color: #f0f0f0; } @@ -159,25 +158,23 @@ a:hover } -/* Variable width. */ -#sidebar +/* Placement. */ +.sidebar { - width: auto; - /* ikiwiki's default for `width'. */ - min-width: 20ex; + margin-left: 20px; } /* Less indentation for list items. */ -#sidebar ul +.sidebar ul { padding-left: 2ex; } -#sidebar ul ul +.sidebar ul ul { padding-left: 2.5ex; } /* Make the logo appear centered */ -#sidebar img { +.sidebar img { display: block; margin-left: auto; margin-right: auto; diff --git a/hurd/running/vmware/discussion.mdwn b/logo.mdwn index 2db08654..aae80561 100644 --- a/hurd/running/vmware/discussion.mdwn +++ b/logo.mdwn @@ -8,11 +8,18 @@ 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 find that this is all quite quick to try and that I can run through the -./native-install and reboot cycle twice OK. However, at that point the -installed Hurd boots up but fails to display a login prompt. This is the case -for both K10 and K14 using VMware Workstation 5.0.0 under Windows XP. Maybe -I'm doing something wrong but it is hard to see what. I'd be interested to -know more precisely what other people find does work. - ---IanMiller - 01 Apr 2007 +The famous *Hurd Boxes* logo is available at +<http://www.gnu.org/graphics/hurd_mf.html>. + + +On some lonely Wednesday, Colin Leitner and [[Thomas_Schwinge|tschwinge]] +converted these four boxes from the [original METAFONT +sources](http://www.gnu.org/graphics/hurd.mf) to +[[hand-written_SVG_code|boxes-redrawn.svg]]. + +[[!img boxes-redrawn.png]] + + +This symbol is also being used as a favicon for this web site. + +[[!img /favicon.ico]] diff --git a/hurd/logo/boxes-redrawn.png b/logo/boxes-redrawn.png Binary files differindex fd26a87e..fd26a87e 100644 --- a/hurd/logo/boxes-redrawn.png +++ b/logo/boxes-redrawn.png diff --git a/hurd/logo/boxes-redrawn.svg b/logo/boxes-redrawn.svg index c0a7e460..c0a7e460 100644 --- a/hurd/logo/boxes-redrawn.svg +++ b/logo/boxes-redrawn.svg diff --git a/lttng.mdwn b/lttng.mdwn new file mode 100644 index 00000000..840312c4 --- /dev/null +++ b/lttng.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]]."]]"""]] + +[[!meta title="Linux Trace Toolkit Next Generation (LTTng)"]] + +[[!tag open_issue_hurd open_issue_gnumach]] + +# Overview + + * {{$toupin_lttng_2011}} + + +# Related + + * [[community/gsoc/project_ideas/dtrace]] + + * [[SystemTap]] + + +[[!ymlfront data=""" + +toupin_lttng_2011: + + Dominique Toupin's article [*Using Tracing to Diagnose or Monitor + Systems*](http://www.computer.org/cms/Computer.org/ComputingNow/homepage/2011/0111/rW_SW_UsingTracing.pdf) + (IEEE Software, January / February 2011) + +"""]] diff --git a/mailing_lists.mdwn b/mailing_lists.mdwn index d64582b8..33f131d5 100644 --- a/mailing_lists.mdwn +++ b/mailing_lists.mdwn @@ -1,13 +1,14 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, +2011, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + # On Posting @@ -23,28 +24,34 @@ do so. If in doubt, don't; just choose the single most appropriate list. When replying to others, please don't top-post and trim the existing text to quote only the sections you're actually replying to. See [[!wikipedia Posting_style]] for further reading, especially [[!wikipedia -Posting_style#Inline_replying]]. +Posting_style#Interleaved_style]]. Also see these general notes about [[community/communication]]. # Main Lists -The lists are [[unmoderated]] and most of them are hosted on -<http://lists.gnu.org/>. Try to post to the appropriate mailing list. +Most of these lists are [[unmoderated]], and most of them are hosted on +<http://lists.gnu.org/>. Some of the Hurd user groups listed on [[community]] also host additional mailing lists. -<!-- TODO. Need some real ikiwiki way of adding such anchors. --> - <a name="bug-hurd"></a> ## bug-hurd <bug-hurd@gnu.org> <http://lists.gnu.org/mailman/listinfo/bug-hurd> -Technical discussion and bug reports; main development list. +Technical discussion and bug reports; main development list. If you want to +[[*contribute*|contributing]], please meet us here. + +<a name="commit-hurd"></a> +## commit-hurd + +<http://lists.gnu.org/mailman/listinfo/commit-hurd> + +Commit notices for the GNU Hurd, and other automated status updates. <a name="hurd-devel"></a> ## hurd-devel @@ -59,8 +66,8 @@ Subscribe to [[hurd-devel-readers]] instead. <http://lists.gnu.org/mailman/listinfo/hurd-devel-readers> -This list is a read-only mirror of [[hurd-devel]]. In contrast to subscribing -to the latter, everyone is free to subscribe to this read-only list. +This list is a read-only mirror of [[hurd-devel]]. In contrast to the former, +everyone is free to subscribe to this read-only list. <a name="help-hurd"></a> ## help-hurd @@ -68,7 +75,8 @@ to the latter, everyone is free to subscribe to this read-only list. <help-hurd@gnu.org> <http://lists.gnu.org/mailman/listinfo/help-hurd> -Hurd-specific questions; for users of the Hurd. +Hurd-specific questions, for users of the Hurd. If you need help with [[*using +the Hurd*|hurd/running]], please ask on this list. <a name="web-hurd"></a> ## web-hurd @@ -103,6 +111,16 @@ Discussion around and questions regarding the Discussion about the [[GNU_system|hurd/running/gnu]]. +<a name="libc-alpha"></a> +## libc-alpha + +<libc-alpha@sourceware.org> +<http://sourceware.org/ml/libc-alpha/> + +Discussion about [[glibc]], where the Hurd's POSIX et al. interfaces are +implemented, amongst a lot of other bits and pieces. This list is *moderated*, +but on-topic development topics will generally be accepted. + # Spam diff --git a/mailing_lists/commit-hurd.mdwn b/mailing_lists/commit-hurd.mdwn new file mode 100644 index 00000000..08fcaff4 --- /dev/null +++ b/mailing_lists/commit-hurd.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta redir=mailing_lists#commit-hurd]] diff --git a/mailing_lists/libc-alpha.mdwn b/mailing_lists/libc-alpha.mdwn new file mode 100644 index 00000000..2f997922 --- /dev/null +++ b/mailing_lists/libc-alpha.mdwn @@ -0,0 +1,11 @@ +[[!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 redir=mailing_lists#libc-alpha]] diff --git a/mailing_lists/unmoderated.mdwn b/mailing_lists/unmoderated.mdwn index 4bef130e..385f2615 100644 --- a/mailing_lists/unmoderated.mdwn +++ b/mailing_lists/unmoderated.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] In fact the lists *are* moderated for users that post from not-subscribed email addresses. However, this moderation should be transparent to the poster, you @@ -14,6 +15,8 @@ only might notice some additional delay until your message shows up on the list, as it has to be handled manually. Note that this is a one-time delay, as the address will be added to a white-list, so that further messages from the same sending address will get through immediatelly. +The same holds for people who are sending their first message after subscribing +to a list. These two measures greatly help to keep the lists' spam level low. So, to initiate a discussion you do not need to subscribe to the mailing list in question. And people are very much encouraged to maintain the CC diff --git a/media_appearances.mdwn b/media_appearances.mdwn new file mode 100644 index 00000000..3495a88e --- /dev/null +++ b/media_appearances.mdwn @@ -0,0 +1,119 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +This is a collection of some Hurd-related media appearances. + +A lot of stuff is missing here. + +[[!toc levels=2]] + + +# 2012 + + +## April + + * *[People behind Debian: Samuel Thibault, working on accessibility and the + Hurd](http://raphaelhertzog.com/2012/04/19/people-behind-debian-samuel-thibault-working-on-accessibility-and-the-hurd/)*, + Raphaël Hertzog, 2012-04-19 + + +# 2011 + + +## August + + * GNU Hackers Meeting in Paris: {{$community/meetings/ghm2011#thibault_hurd}} + + +## July + + +### After Publishing [[news/2011-q2]] + + * {{$news/2011-q2#lwn}} + + * {{$news/2011-q2#phoronix-1}} + + * {{$news/2011-q2#phoronix-2}} + + * {{$news/2011-q2#phoronix-3}} + + * {{$news/2011-q2#golem}} + + * {{$news/2011-q2#h-online}} + + * {{$news/2011-q2#innocenthacker}} + + * {{$news/2011-q2#netzwelt}} + + * {{$news/2011-q2#operation-tunnelbau}} + + * {{$news/2011-q2#osnews}} + + * {{$news/2011-q2#pro-linux}} + + * {{$news/2011-q2#reddit-1}} + + * {{$news/2011-q2#reddit-2}} + + * {{$news/2011-q2#slashdot}} + + * {{$news/2011-q2#schmehl}} + + * ... + + +## January + + * {{$gnu#gnustatus-2011-01}} + + +# 2010 + + +## August + + * DebConf10: {{$community/meetings/debconf10#banck_hurd}} + + +## July + + * GNU Hackers Meeting in the Hague: {{$community/meetings/ghm2010#walfield_hurd}} + + * Koen Vervloesem: [*The Hurd: GNU's quest for the perfect + kernel*](http://lwn.net/Articles/395150/) + + Follow-up discussion: + + * <http://www.osnews.com/comments/23827> + + * Richard Hillesley: [*GNU HURD: Altered visions and lost + promise*](http://www.h-online.com/open/features/GNU-HURD-Altered-visions-and-lost-promise-1030942.html) + ([German + translation](http://www.heise.de/open/artikel/GNU-HURD-Veraenderte-Visionen-und-verworfene-Versprechen-1046753.html)) + + Follow-up discussion, some of it valid and constructive criticism, some of + it less so: + + * <http://lwn.net/Articles/394295/> + * <http://www.reddit.com/r/linux/comments/ckjt2/gnu_hurd_altered_visions_and_lost_promise/> + * <http://www.reddit.com/r/programming/comments/ckjud/the_hurd_altered_visions_and_lost_promise/> + * <http://www.osnews.com/comments/23511> + * <http://news.ycombinator.com/item?id=1474941> + + +# 2004 + + * Marcus Brinkmann, *The GNU Hurd - Lessons and Perspective*, from the + [OpenWeekend](http://openweekend.cz/) 2004 conference organized by the + Silicon Hill club. + <http://video.google.com/videoplay?docid=-7449462856350014702> diff --git a/microkernel.mdwn b/microkernel.mdwn index e2d70c01..edefddb7 100644 --- a/microkernel.mdwn +++ b/microkernel.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +A *microkernel* is one kind of a [[kernel]] implementation. [[Liedtke]] explains in [On Microkernel Construction](http://l4ka.org/publications/paper.php?docid=642) that a microkernel attempts to minimize the mandatory part of the operating @@ -19,12 +22,10 @@ The idea of a microkernel as explained above was first explored by Per Brinch-Hansen in 1970 in [The Nucleus of a Multiprogramming System](http://brinch-hansen.net/papers/1970a.pdf). -Other notable microkernels include [[Hydra]], [[KeyKOS]], [[Eros]] and [[L4]]. - An [introduction](http://www.cs.cornell.edu/Info/People/ulfar/ukernel/ukernel.html) by Úlfar Erlingsson and Athanasios Kyparlis (from 1996) to microkernel concepts. -[[Research]]. [[Viengoos]]. +[[Research]]. [[Microkernels_for_beginners|for_beginners]]. @@ -32,4 +33,23 @@ A 2002 article about [[microkernel_FUD|FUD]] (Fear, Uncertainty, Doubt). [[FAQ]]. -[[Mach]]. + +# Implementations + + * [[Hydra]] + + * [[KeyKOS]] + + * [[Mach]] -- used by the GNU/Hurd + + * [[EROS]] + + * [[CapROS]] + + * [[Coyotos]] + + * [[L4]] + + * [[Barrelfish]] + + * [[Viengoos]] diff --git a/microkernel/barrelfish.mdwn b/microkernel/barrelfish.mdwn new file mode 100644 index 00000000..8cf5591b --- /dev/null +++ b/microkernel/barrelfish.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +<http://barrelfish.org/> + + * {{$fof_plos09}} + + +[[!ymlfront data=""" + +fof_plos09: + + "Pierre-Evariste Dagand, Andrew Baumann, Timothy Roscoe. Filet-o-Fish: + practical and dependable domain-specific languages for OS development. PLOS + '09, October 11, 2009, Big Sky, Montana, USA." + +"""]] diff --git a/microkernel/coyotos.mdwn b/microkernel/coyotos.mdwn new file mode 100644 index 00000000..fec023ba --- /dev/null +++ b/microkernel/coyotos.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 2006, 2007, 2008, 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 +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="Coyotos"]] + +[*Coyotos*](http://www.coyotos.org/) is a microkernel and OS and the successor +of [[EROS]], that itself is the successor of [[KeyKOS]]. A more complete +history can be found [here](http://www.coyotos.org/history.html). Its main +objectives are to correcte some shortcomings of [[EROS]], demonstrate that an +atomic kernel design scales well, and (eventually) to completely formally +verify both the kernel and critical system components by writing them in a new +language called [bitc](http://www.bitc-lang.org/). + +Coyotos is an orthogonally [[persistent|persistency]] pure [[capability]] +system. It uses [[continuation]]-based unbuffered asynchronous [[IPC]] +(actually it's synchronous [[IPC]] with asynchronous [[system calls]]). + +TODO: explain these terms and (more important) their consequences on system +design. + +The coyotos microkernel specification can be found +[here](http://www.coyotos.org/docs/ukernel/spec.html). + +There once was the idea of a GNU/Hurd [[port using the Coyotos +microkernel|history/port_to_another_microkernel]], but this didn't come live. diff --git a/microkernel/discussion.mdwn b/microkernel/discussion.mdwn new file mode 100644 index 00000000..a5a73e18 --- /dev/null +++ b/microkernel/discussion.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_documentation]] + +IRC, freenode, #hurd, 2011-07-26: + + < antrik> Tekk_`: regarding microkernels: the basic idea, and really the + *only* fundamental difference, is that they isolate things in separate + address spaces. everything else goes back to this. + < antrik> benefits from the isolation generally fall into two groups: more + robustness (main focus of Minix3), and more flexibility (main focus of + Hurd) + < antrik> while it might also encourage some other good design choices, + these are secondary effects: such choices can also be implemented in a + monolithic architecture -- and not necessarily harder. just less obvious + in some cases... diff --git a/microkernel/eros.mdwn b/microkernel/eros.mdwn new file mode 100644 index 00000000..be1ca90a --- /dev/null +++ b/microkernel/eros.mdwn @@ -0,0 +1,15 @@ +[[!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]] + +<http://www.eros-os.org/> + +TODO. <http://www.eros-os.org/essays/reliability/paper.html> diff --git a/microkernel/faq.mdwn b/microkernel/faq.mdwn index a6c4f1f8..fe259f05 100644 --- a/microkernel/faq.mdwn +++ b/microkernel/faq.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,9 +11,11 @@ is included in the section entitled [[!meta title="Microkernel FAQ"]] +See also other [[/FAQ]]. + [[!inline pages="microkernel/faq/* and !*/discussion" show=0 feeds=no actions=yes -rootpage=microkernel/faq" postformtext="Add a new item titled:"]] +rootpage="microkernel/faq" postformtext="Add a new item titled:"]] diff --git a/microkernel/fud.mdwn b/microkernel/fud.mdwn index eef829e0..3f9229aa 100644 --- a/microkernel/fud.mdwn +++ b/microkernel/fud.mdwn @@ -11,12 +11,24 @@ This article is a response to an [earlier article](http://www.linuxjournal.com/n Miles Nordin claimed that microkernels are dead already. But this is not completely true. The first generation of microkernels, which were in fact no real microkernels, are dead. But there is a new generation, which uses a radically different strategy than the original (so-called) microkernels. Thus, microkernels are still a research topic, and today they look more promising than ever before. By now, this is just something we claim, but read on, and you'll find out why we do so. -Out of our own experience, we can confirm that the first generation microkernel Mach is quite slow, but being microkernel independent is one of the goals of the Hurd and people are already working on porting the Hurd from Mach to the second generation microkernel L4. Those new second generation kernels aren't as slow as Mach and we think that one should not talk about the performance of microkernel based systems without having read at least some of the papers on L4. The L4 people did some interesting benchmarks, which indicate that one can get a lot of performance by making a microkernel really small. How is this supposed to work? Well, the microkernel provides very primitive, highly optimized operations, and applications use them to implement whichever way of interprocess communication is apropriate for them in an efficient way. By deciding this on a per-case basis, you get optimal performance for all applications. +Out of our own experience, we can confirm that the first generation microkernel +Mach is quite slow, but being microkernel independent is one of the goals of +the Hurd and people are already working on porting the Hurd from Mach to the +second generation microkernel L4. Those new second generation kernels aren't +as slow as Mach and we think that one should not talk about the performance of +microkernel based systems without having read at least some of the papers on +L4. The L4 people did some interesting benchmarks, which indicate that one can +get a lot of performance by making a microkernel really small. How is this +supposed to work? Well, the microkernel provides very primitive, highly +optimized operations, and applications use them to implement whichever way of +inter-process communication is apropriate for them in an efficient way. By +deciding this on a per-case basis, you get optimal performance for all +applications. But L4 takes this even further. For example, you can have schedulers in userspace. Therefore you can use a scheduler which is optimized for the specific tasks your system performs. With the Linux kernel, different schedulers are only possible by using a different source tree, thus you cannot switch at run-time and/or have different schedulers for different groups of processes. Of course, microkernels still have some problems, mainly because we are bound to today's technology, and current processors have not been designed with microkernels in mind. On a processor that is not optimized for systems with monolithic kernels, where the currently still problematic overhead of context switches would vanish, microkernels would get another performance boost. This sounds like an excuse, but it is intended as a reminder about the fact that the problem is not the general concept of microkernels. However, the L4 people have done a lot of good hacks to work around all this and have reached reasonable performance already. -All this could be discussed in arbitrary detail, but we won't do that now, as we have more urgent things to do than reacting on FUD about microkernels. So we will conclude by saying that it is too easy to claim that one design is fast and the other one is slow, but everything depends on how exactly a system is designed and implemented. Maybe microkernels will eventually turn out to be slower in almost any case; we doubt that, but who knows? But even then, a microkernel based system will offer enough other advantages so that people will prefer to use it in some cases. But on the other hand, history has shown that new concepts seldom replace old ones completely, but rather establish themselfes in addition to the old ones, therefore we will have the opportunity to argue about which concept is best at least for another couple of years.. or decades? +All this could be discussed in arbitrary detail, but we won't do that now, as we have more urgent things to do than reacting on FUD about microkernels. So we will conclude by saying that it is too easy to claim that one design is fast and the other one is slow, but everything depends on how exactly a system is designed and implemented. Maybe microkernels will eventually turn out to be slower in almost any case; we doubt that, but who knows? But even then, a microkernel based system will offer enough other advantages so that people will prefer to use it in some cases. But on the other hand, history has shown that new concepts seldom replace old ones completely, but rather establish themselves in addition to the old ones, therefore we will have the opportunity to argue about which concept is best at least for another couple of years.. or decades? If you are interested in research about the performance of microkernel based systems, visit <http://www.l4ka.org> and <http://os.inf.tu-dresden.de/L4/> diff --git a/microkernel/l4.mdwn b/microkernel/l4.mdwn new file mode 100644 index 00000000..7af5e6fc --- /dev/null +++ b/microkernel/l4.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The [*L4* microkernel](http://l4ka.org/) is an attempt to create a very small +high performace core which provides basic memory management, task and context +switching, and little else. + +[L4Ka Pistachio Home](http://l4ka.org/projects/pistachio/). + +See [l4.verified](http://nicta.com.au/research/projects/l4.verified) for work +on formally verifying an L4 microkernel. + + * {{$sel4}} + +There was a GNU/Hurd [[port to L4|history/port_to_another_microkernel]], which +is now stalled. + + +[[!ymlfront data=""" + +sel4: + + "G. Klein, K. Elphinstone, G. Heiser, J. Andronick, D. Cock, P. Derrin, + D. Elkaduwe, K. Engelhardt, R. Kolanski, M. Norrish, T. Sewell, H. Tuch, and + S. Winwood. seL4: Formal verification of an OS kernel. In Proceedings of + the ACM Symposium on OS Principles, Big Sky, MT, USA, October 2009." + +"""]] diff --git a/microkernel/mach.mdwn b/microkernel/mach.mdwn index 39d0f4d2..02627766 100644 --- a/microkernel/mach.mdwn +++ b/microkernel/mach.mdwn @@ -1,16 +1,96 @@ +[[!meta copyright="Copyright © 2007, 2008, 2010, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + Mach is a so-called first generation [[microkernel]]. It is the microkernel currently used by the [[Hurd]]. -* [[Documentation]] -* [[Concepts]] -* [[History]] ([Torvalds, Tanenbaum Debate](http://www.dina.dk/~abraham/Linus_vs_Tanenbaum.html)) + * [[Concepts]] + + * [[Deficiencies]] + + * [[Documentation]] + + * [[History]] + + * [Torvalds, Tanenbaum + Debate](http://www.dina.dk/~abraham/Linus_vs_Tanenbaum.html) + # Implementations -* [[GNU_Mach|gnumach]] -* [[Mach/OskitMach]] - A Once Successor of Mach based on OSKit -* [Apple's Darwin](http://developer.apple.com/darwin/) ([API](http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/index.html)) (**non-free**) + * [[GNU_Mach|gnumach]] + + * [Apple's Darwin](http://developer.apple.com/darwin/) + ([API](http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/index.html)) + (**non-free**) + + * [[open_issues/OSF_Mach]] + # Related -* [[Mach_Interface_Generator_(MIG)|mig]] + * [[Mach_Interface_Generator_(MIG)|mig]] + + +[[!ymlfront data=""" + +kernel_foundation_unix: + + "M. Accetta, R. Baron, W. Bolosky, D. Golub, R. Rashid, A. Tevanian, and + M. Young, Mach: A New Kernel Foundation for UNIX Development, USENIX + Conference Proceedings, July 1986. Paper + [\[pdf\]](http://www.cs.toronto.edu/~demke/469F.06/Handouts/mach_usenix86.pdf)." + +kernel_interface: + + "Mach 3 Kernel Interfaces. Open Software Foundation and Carnegie Mellon + University. Keith Loepere, Editor. NORMA-MK12: July 15, 1992. Book [\[ps + (HTTP)\]](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_interface.ps), + [\[ps + (FTP)\]](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_interface.ps)." + +kernel_principles: + + "Mach 3 Kernel Principles. Open Software Foundation and Carnegie Mellon + University. Keith Loepere. NORMA-MK12: July 15, 1992. Book [\[ps + (HTTP)\]](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_principles.ps), + [\[ps + (FTP)\]](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_principles.ps)." + +server_interface: + + "Mach 3 Server Writer’s Interfaces. Open Software Foundation and Carnegie + Mellon University. Keith Loepere, Editor. NORMA-MK12, user15: July 15, + 1992. Book [\[ps + (HTTP)\]](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_interface.ps), + [\[ps + (FTP)\]](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_interface.ps)." + +server_writer: + + "Mach 3 Server Writer’s Guide. Open Software Foundation and Carnegie Mellon + University. Keith Loepere, Editor. NORMA-MK12, user15: July 15, 1992. Book + [\[ps + (HTTP)\]](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_writer.ps), + [\[ps + (FTP)\]](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_writer.ps)." + +vm: + + "R. Rashid, A. Tevanian, M. Young, D. Golub, and R. Baron, + Machine-Independent Virtual Memory Management for Paged Uniprocessor and + Multiprocessor Architectures, 2nd ACM Symposium on Architectural Support for + Programming Languages and Operating Systems (ASPLOS), October 1987. Paper + [\[pdf\]](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.111.7918&rep=rep1&type=pdf), + presentation + [\[ppt\]](http://www2.cs.uh.edu/~paris/6360/PowerPoint/Mach.ppt)." + +"""]] diff --git a/microkernel/mach/concepts.mdwn b/microkernel/mach/concepts.mdwn index 04dbb1c6..0f7cbf00 100644 --- a/microkernel/mach/concepts.mdwn +++ b/microkernel/mach/concepts.mdwn @@ -1,6 +1,33 @@ -[[Mach]] is a first-generation [[microkernel]]. Mach's basic abstractions -include [[address_space]]s in the form of [[task]]s, execution contexts in the -form of [[thread]]s, [[IPC]], [[capabilities|capability]] in the form of [[port]]s, and -[[memory_object]]s, which enable Mach's [[external_pager_mechanism]]. +[[!meta copyright="Copyright © 2002, 2003, 2007, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[Mach]] is a first-generation [[microkernel]]. + +Mach's basic abstractions include [[virtual_address_space]]s in the form of +[[task]]s, execution contexts in the form of [[thread]]s, [[IPC]], +[[capabilities|capability]] in the form of [[port]]s, and [[memory_object]]s, +which enable Mach's [[external_pager_mechanism]]. + +Controlling [[task]]s, their [[virtual_address_space]], [[thread]]s, and other +system objects in Mach is implemented by using [[port]]s, as opposed to other +[[kernel]]s' [[system_call]] interface: almost all of the Mach API is +implemented by sending [[message]]s to [[port]]s. Device drivers that reside +in kernel space are controlled by ports, too. Mach's [[API]] is well-[[documented|documentation]]. + +[[!toggleable id=mach_kernel_principles text="""[[!template id=note +text="*[[mach\_kernel\_principles|documentation]]*: +{{$mach#kernel_principles}}"]]"""]] + +In particular the [[!toggle id=mach_kernel_principles +text="[mach\_kernel\_principles]"]] book further elaborates on Mach's concepts +and principles. diff --git a/microkernel/mach/continuation.mdwn b/microkernel/mach/continuation.mdwn new file mode 100644 index 00000000..7a3267f3 --- /dev/null +++ b/microkernel/mach/continuation.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[Mach]] internally uses *continuation*s for kernel [[thread]] management. + +The advantage is that not a full kernel thread stack has to be preserved in +case that a thread is about to enter a blocking state. This saves space. It +is not clear this is still worthwhile given today's RAM offerings. (How many +kernel threads are there, typically?) + +And, this would no longer be possible in case Mach were be made a +[[preemptive|preemtion]] kernel. In the latter case, the kernel itself, that +is, kernel threads can be preempted, and then their full state needs to be +preserved. + +[[!tag open_issue_documentation]] <!-- Not linked to from any Mach page. Move +to GNU Mach pages, as this is only an implementation detail? --> diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn new file mode 100644 index 00000000..f2f49975 --- /dev/null +++ b/microkernel/mach/deficiencies.mdwn @@ -0,0 +1,260 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-06-29 + + <henrikcozza> I do not understand what are the deficiencies of Mach, the + content I find on this is vague... + <antrik> the major problems are that the IPC architecture offers poor + performance; and that resource usage can not be properly accounted to the + right parties + <braunr> antrik: the more i study it, the more i think ipc isn't the + problem when it comes to performance, not directly + <braunr> i mean, the implementation is a bit heavy, yes, but it's fine + <braunr> the problems are resource accounting/scheduling and still too much + stuff inside kernel space + <braunr> and with a very good implementation, the performance problem would + come from crossing address spaces + <braunr> (and even more on SMP, i've been thinking about it lately, since + it would require syncing mmu state on each processor currently using an + address space being modified) + <antrik> braunr: the problem with Mach IPC is that it requires too many + indirections to ever be performant AIUI + <braunr> antrik: can you mention them ? + <antrik> the semantics are generally quite complex, compared to Coyotos for + example, or even Viengoos + <braunr> antrik: the semantics are related to the message format, which can + be simplified + <braunr> i think everybody agrees on that + <braunr> i'm more interested in the indirections + <antrik> but then it's not Mach IPC anymore :-) + <braunr> right + <braunr> 22:03 < braunr> i mean, the implementation is a bit heavy, yes, + but it's fine + <antrik> that's not an implementation issue + <braunr> that's what i meant by heavy :) + <braunr> well, yes and no + <braunr> Mach IPC have changed over time + <braunr> it would be newer Mach IPC ... :) + <antrik> the fact that data types are (supposed to be) transparent to the + kernel is a major part of the concept, not just an implementation detail + <antrik> but it's not just the message format + <braunr> transparent ? + <braunr> but they're not :/ + <antrik> the option to buffer in the kernel also adds a lot of complexity + <braunr> buffer in the kernel ? + <braunr> ah you mean message queues + <braunr> yes + <antrik> braunr: eh? the kernel parses all the type headers during transfer + <braunr> yes, so it's not transparent at all + <antrik> maybe you have a different understanding of "transparent" ;-) + <braunr> i guess + <antrik> I think most of the other complex semantics are kinda related to + the in-kernel buffering... + <braunr> i fail to see why :/ + <antrik> well, it allows ports rights to be destroyed while a message is in + transfer. a lot of semantics revolve around what happens in that case + <braunr> yes but it doesn't affect performance a lot + <antrik> sure it does. it requires a lot of extra code and indirections + <braunr> not a lot of it + <antrik> "a lot" is quite a relative term :-) + <antrik> compared to L4 for example, it *is* a lot + <braunr> and those indirections (i think you refer to more branching here) + are taken only when appropriate, and can be isolated, improved through + locality, etc.. + <braunr> the features they add are also huge + <braunr> L4 is clearly insufficient + <braunr> all current L4 forks have added capabilities .. + <braunr> (that, with the formal verification, make se4L one of the + "hottest" recent system projects) + <braunr> seL4* + <antrik> yes, but with very few extra indirection I think... similar to + EROS (which claims to have IPC almost as efficient as the original L4) + <braunr> possibly + <antrik> I still fail to see much real benefit in formal verification :-) + <braunr> but compared to other problems, this added code is negligible + <braunr> antrik: for a microkernel, me too :/ + <braunr> the kernel is already so small you can simply audit it :) + <antrik> no, it's not neglible, if you go from say two cache lines touched + per IPC (original L4) to dozens (Mach) + <antrik> every additional variable that needs to be touched to resolve some + indirection, check some condition adds significant overhead + <braunr> if you compare the dozens to the huge amount of inter processor + interrupt you get each time you change the kernel map, it's next to + nothing .. + <antrik> change the kernel map? not sure what you mean + <braunr> syncing address spaces on hundreds of processors each time you + send a message is a real scalability issue here (as an example), where + Mach to L4 IPC seem like microoptimization + <youpi> braunr: modify, you mean? + <braunr> yes + <youpi> (not switchp + <youpi> ) + <braunr> but that's only one example + <braunr> yes, modify, not switch + <braunr> also, we could easily get rid of the ihash library + <braunr> making the message provide the address of the object associated to + a receive right + <braunr> so the only real indirection is the capability, like in other + systems, and yes, buffering adds a bit of complexity + <braunr> there are other optimizations that could be made in mach, like + merging structures to improve locality + <pinotree> "locality"? + <braunr> having rights close to their target port when there are only a few + <braunr> pinotree: locality of reference + <youpi> for cache efficiency + <antrik> hundreds of processors? let's stay realistic here :-) + <braunr> i am .. + <braunr> a microkernel based system is also a very good environment for RCU + <braunr> (i yet have to understand how liburcu actually works on linux) + <antrik> I'm not interested in systems for supercomputers. and I doubt + desktop machines will get that many independant cores any time soon. we + still lack software that could even romotely exploit that + <braunr> hum, the glibc build system ? :> + <braunr> lol + <youpi> we have done a survey over the nix linux distribution + <youpi> quite few packages actually benefit from a lot of cores + <youpi> and we already know them :) + <braunr> what i'm trying to say is that, whenever i think or even measure + system performance, both of the hurd and others, i never actually see the + IPC as being the real performance problem + <braunr> there are many other sources of overhead to overcome before + getting to IPC + <youpi> I completely agree + <braunr> and with the advent of SMP, it's even more important to focus on + contention + <antrik> (also, 8 cores aren't exactly a lot...) + <youpi> antrik: s/8/7/ , or even 6 ;) + <antrik> braunr: it depends a lot on the use case. most of the problems we + see in the Hurd are probably not directly related to IPC performance; but + I pretty sure some are + <antrik> (such as X being hardly usable with UNIX domain sockets) + <braunr> antrik: these have more to do with the way mach blocks than IPC + itself + <braunr> similar to the ext2 "sleep storm" + <antrik> a lot of overhead comes from managing ports (for for example), + which also mostly comes down to IPC performance + <braunr> antrik: yes, that's the main indirection + <braunr> antrik: but you need such management, and the related semantics in + the kernel interface + <braunr> (although i wonder if those should be moved away from the message + passing call) + <antrik> you mean a different interface for kernel calls than for IPC to + other processes? that would break transparency in a major way. not sure + we really want that... + <braunr> antrik: no + <braunr> antrik: i mean calls specific to right management + <antrik> admittedly, transparency for port management is only useful in + special cases such as rpctrace, and that probably could be served better + with dedicated debugging interfaces... + <braunr> antrik: i.e. not passing rights inside messages + <antrik> passing rights inside messages is quite essential for a capability + system. the problem with Mach IPC in regard to that is that the message + format allows way more flexibility than necessary in that regard... + <braunr> antrik: right + <braunr> antrik: i don't understand why passing rights inside messages is + important though + <braunr> antrik: essential even + <youpi> braunr: I guess he means you need at least one way to pass rights + <antrik> braunr: well, for one, you need to pass a reply port with each RPC + request... + <braunr> youpi: well, as he put, the message passing call is overpowered, + and this leads to many branches in the code + <braunr> antrik: the reply port is obvious, and can be optimized + <braunr> antrik: but the case i worry about is passing references to + objects between tasks + <braunr> antrik: rights and identities with the auth server for example + <braunr> antrik: well ok forget it, i just recall how it actually works :) + <braunr> antrik: don't forget we lack thread migration + <braunr> antrik: you may not think it's important, but to me, it's a major + improvement for RPC performance + <antrik> braunr: how can seL4 be the most interesting microkernel + then?... ;-) + <braunr> antrik: hm i don't know the details, but if it lacks thread + migration, something is wrong :p + <braunr> antrik: they should work on viengoos :) + <antrik> (BTW, AIUI thread migration is quite related to passive objects -- + something Hurd folks never dared seriously consider...) + <braunr> i still don't know what passive objects are, or i have forgotten + it :/ + <antrik> no own control threads + <braunr> hm, i'm still missing something + <braunr> what do you refer to by control thread ? + <braunr> with* + <antrik> i.e. no main loop etc.; only activated by incoming calls + <braunr> ok + <braunr> well, if i'm right, thomas bushnel himself wrote (recently) that + the ext2 "sleep" performance issue was expected to be solved with thread + migration + <braunr> so i guess they definitely considered having it + <antrik> braunr: don't know what the "sleep peformance issue" is... + <braunr> http://lists.gnu.org/archive/html/bug-hurd/2011-12/msg00032.html + <braunr> antrik: also, the last message in the thread, + http://lists.gnu.org/archive/html/bug-hurd/2011-12/msg00050.html + <braunr> antrik: do you consider having a reply port being an avoidable + overhead ? + <antrik> braunr: not sure. I don't remember hearing of any capability + system doing this kind of optimisation though; so I guess there are + reasons for that... + <braunr> antrik: yes me too, even more since neal talked about it on + viengoos + <antrik> I wonder whether thread management is also such a large overhead + with fully sync IPC, on L4 or EROS for example... + <braunr> antrik: it's still a very handy optimization for thread scheduling + <braunr> antrik: it makes solving priority inversions a lot easier + <antrik> actually, is thread scheduling a problem at all with a thread + activation approach like in Viengoos? + <braunr> antrik: thread activation is part of thread migration + <braunr> antrik: actually, i'd say they both refer to the same thing + <antrik> err... scheduler activation was the term I wanted to use + <braunr> same + <braunr> well + <braunr> scheduler activation is too vague to assert that + <braunr> antrik: do you refer to scheduler activations as described in + http://en.wikipedia.org/wiki/Scheduler_activations ? + <antrik> my understanding was that Viengoos still has traditional threads; + they just can get scheduled directly on incoming IPC + <antrik> braunr: that Wikipedia article is strange. it seems to use + "scheduler activations" as a synonym for N:M multithreading, which is not + at all how I understood it + <youpi> antrik: I used to try to keep a look at those pages, to fix such + wrong things, but left it + <braunr> antrik: that's why i ask + <antrik> IIRC Viengoos has a thread associated with each receive + buffer. after copying the message, the kernel would activate the + processes activation handler, which in turn could decide to directly + schedule the thead associated with the buffer + <antrik> or something along these lines + <braunr> antrik: that's similar to mach handoff + <youpi> antrik: generally enough, all the thread-related pages on wikipedia + are quite bogus + <antrik> nah, handoff just schedules the process; which is not useful, if + the right thread isn't activated in turn... + <braunr> antrik: but i think it's more than that, even in viengoos + <youpi> for instance, the french "thread" page was basically saying that + they were invented for GUIs to overlap computation with user interaction + <braunr> .. :) + <antrik> youpi: good to know... + <braunr> antrik: the "misunderstanding" comes from the fact that scheduler + activations is the way N:M threading was implemented on netbsd + <antrik> youpi: that's a refreshing take on the matter... ;-) + <braunr> antrik: i'll read the critique and viengoos doc/source again to be + sure about what we're talking :) + <braunr> antrik: as threading is a major issue in mach, and one of the + things i completely changed (and intend to change) in x15, whenever i get + to work on that again ..... :) + <braunr> antrik: interestingly, the paper about scheduler activations was + written (among others) by brian bershad, in 92, when he was actively + working on research around mach + <antrik> braunr: BTW, I have little doubt that making RPC first-class would + solve a number of problems... I just wonder how many others it would open diff --git a/microkernel/mach/discussion.mdwn b/microkernel/mach/discussion.mdwn deleted file mode 100644 index 589e302d..00000000 --- a/microkernel/mach/discussion.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -## <a name="Maintenance_of_the_Mach_web"> Maintenance of the Mach web </a> - -**_Old discussions:_** [[WIKIHOMEURLMachTOPICrev13]] - -Interesting, for consistency sake I'll think about making your changes you made on the right hand side to the other web WebHome pages. I guess it's not critical that they are identical, but I was trying to keep them identical if possible. I also wanted it to be "light" enough feature wise that it doesn't overpower the page. You've added back a few of the features, so we obviously differ in how important you and I think these features are. That's OK, I'll think about it some more and we'll see what happens. - -Oh, I see you added back [[WebTopicList]] and [[WebPreferences]]. I purposely removed [[WebPreferences]] from the lists on the right because it has nothing to do with navigation. I also didn't think that people actually use topic names to navigate. If they do they could search for them. Keeping the number to four items instead of six and keeping the descriptions concise makes a big difference when I view the page. - -(goes off to think more...) - -and eat... ;-) - --- [[Main/GrantBow]] - 29 Dec 2002 - -**_Reasons for my change:_** - -1. [[WebTopicList]] is a lot quicker than the [[WebIndex]] - brings down the load times and the load of the server -2. [[WebPreferences]] - users might be curious to see what can be modified. Changes should of course only be made in their home topics, like in %WIKIUSERNAME%. However, the [[WebPreferences]] can serve as an inspiration. Therefore we should perhaps make sure only the [[Main/TWikiAdminGroup]] members can alter the \*Preferences topics. -3. If you look closely I've also reordered the links. Shorter names first and long ones last, I tried to keep the descriptions brief and in proportional length as well. - -I don't know about you, but keeping the number of items to four rather than six doesn't really matter to me. The text is quite small and if it's the space we're after the [[WebStatistics]] does take up more than the navigation links. - --- [[Main/JoachimNilsson]] - 29 Dec 2002 diff --git a/microkernel/mach/documentation.mdwn b/microkernel/mach/documentation.mdwn index 3b12bfac..cc880ab6 100644 --- a/microkernel/mach/documentation.mdwn +++ b/microkernel/mach/documentation.mdwn @@ -1,24 +1,33 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, +2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] - - [Meet Mach](http://www.stepwise.com/Articles/Technical/MeetMach.html), a - summary of Mach's history and main concepts. + * Mach's [[concepts]]. + + * [*Meet Mach* by James + Scott](http://beefchunk.com/documentation/macosx-programming/Meet_Mach.pdf), + a summary of Mach's history and main concepts. * *[[The_GNU_Mach_Reference_Manual|gnumach/reference_manual]]*. - - OSF's [Kernel Interface (ps)](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_interface.ps) - [Kernel Interface (pdf)](http://shakthimaan.com/downloads/hurd/kernel_interface.pdf) + * {{$mach#kernel_foundation_unix}} + + * {{$mach#vm}} + + * {{$mach#kernel_principles}} + + * {{$mach#kernel_interface}} + + * {{$mach#server_writer}} - - OSF's [Kernel Principles (ps)](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_principles.ps) - [Kernel Principles (pdf)](http://shakthimaan.com/downloads/hurd/kernel_principles.pdf) + * {{$mach#server_interface}} * [*The Unofficial GNU Mach IPC beginner's guide*](http://hurdextras.nongnu.org/ipc_guide/), an easy introduction to diff --git a/microkernel/mach/external_pager_mechanism.mdwn b/microkernel/mach/external_pager_mechanism.mdwn index b175d1cc..05a6cc56 100644 --- a/microkernel/mach/external_pager_mechanism.mdwn +++ b/microkernel/mach/external_pager_mechanism.mdwn @@ -1,92 +1,93 @@ -[[!meta copyright="Copyright © 2002, 2007, 2008 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2002, 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -Mach provides a so-called external pager [[mechanism]]. This +Mach provides a so-called *external pager [[mechanism]]*. This mechanism serves to separate *managing memory* from *managing -content*. Mach does the former while user space tasks do the +content*. Mach does the former while user-space processes do the latter. +[[!tag open_issue_documentation]] <!-- Should probably refer to {{$mach#vm}}. +--> + # Introduction -In Mach, a task's [[Mach/AddressSpace]] consists of references -to [[Mach/MemoryObjects]]. A memory object is designated using -a [[port]] (a port is just a [[capability]]) and -implemented by a normal process. +In Mach, a [[task]]'s [[virtual_address_space]] consists of references to +[[memory_object]]s. To associate a memory object with a portion of a task's -address space, vm\_map is invoked a capability designating +address space, `vm_map` is invoked on a capability designating the task and passing a reference to the memory object and the offset at which to install it. (The first time a task maps an object, Mach sends an initialization message to the server including a control capability, which it uses to supply pages to the kernel.) This is essentially -the same as mapping a file into an address space on [[Unix]] -using mmap. +the same as mapping a file into an address space on [[UNIX]] +using `mmap`. -When a task faults, Mach checks to see if there is a memory +When a task [[faults|page_fault]], Mach checks to see if there is a memory object associated with the fault address. If not, the task -is sent an exception, which is normally further propagated +is sent an [[exception]], which is normally further propagated as a segmentation fault. If there is an associated memory -object, Mach checks whether the corresponding page is in core. -If it is, it installs the page and resumes the task. Mach -then invokes the memory object with the memory\_object\_request +object, Mach checks whether the corresponding [[page]] is in core. +If it is, it installs the page and resumes the task. Mach +then invokes the memory object with the `memory_object_request` method and the page to read. The memory manager then fetches or creates the content as appropriate and supplies it to -Mach using the memory\_object\_supply method. +Mach using the `memory_object_supply` method. # Creating and Mapping a Memory Object The following illustrates the basic idea: -> ________ -> / \ -> | Mach | -> \________/ -> /| / |\ \ -> (C) vm_map / / m_o_ready (E)\ \ (D) memory_object_init -> / |/ (F) return \ \| -> ________ ________ -> / \ -----> / \ -> | Client | (A) open | Server | -> \________/ <----- \________/ -> (B) memory_object - -(A) The client sends an "open" rpc to the server. + ________ + / \ + | Mach | + \________/ + /| / |\ \ + (C) vm_map / / m_o_ready (E)\ \ (D) memory_object_init + / |/ (F) return \ \| + ________ ________ + / \ -----> / \ + | Client | (A) open | Server | + \________/ <----- \________/ + (B) memory_object + +(A) The client sends an `open` [[RPC]] to the server. (B) The server creates a memory object (i.e., a port receive right), adds it to the port set that it is listening on and returns a capability (a port send right) to the client. (C) The client attempts to map the object into its address space using -the vm\_map rpc. It passes a reference to the port that the server gave +the `vm_map` RPC. It passes a reference to the port that the server gave it to the vm server (typically Mach). (D) Since Mach has never seen the object before, it queues a -memory\_object\_init on the given port along with a send right (the +`memory_object_init` on the given port along with a send right (the memory control port) for the manager to use to send messages to the kernel and also as an authentication mechanism for future interactions: the port is supplied so that the manager will be able to -identify from which kernel a given memory\_object\_* IPC is from. +identify from which kernel a given `memory_object_*` IPC is from. (E) The server dequeues the message, initializes internal data structures to manage the mapping and then invokes the -memory\_object\_ready method on the control object. +`memory_object_ready` method on the control object. (F) The kernel sees that the manager is ready, sets up the appropriate -mappings in the client and then replies to the vm\_map rpc indicating +mappings in the client's address space and then replies to the `vm_map` RPC indicating success. -There is nothing stopping others from playing "the kernel." This is +There is nothing stopping others from playing *the kernel*. This is not a security problem: clients must [[trust]] the server from whom they obtain memory objects and also the servers with whom they share the object. Multiple memory managers are a reality that should be @@ -96,37 +97,37 @@ mappings etc. # Resolving Page Faults -> (G) Client ________ -> resumed / \ -> | Mach | -> (A) Fault +----|------+ | \ (B) m_o_request (C) store_read -> ____|___ \_____|__/ |\ \| ________ _________ -> / +---\-------+ \ / \ / \ -> | Client | (F) | Server |<===>| storeio | -> \________/ m_o_supply \________/ \_________/ -> (E) return data | ^ -> | | (D) device_read -> v | -> ________ -> / Device \ -> | Driver | -> \________/ -> | ^ -> | | -> v -> ____________ -> / Hardware \ - -(A) The client does a memory access and faults. The kernel catches + (G) Client ________ + resumed / \ + | Mach | + (A) Fault +----|------+ | \ (B) m_o_request (C) store_read + ____|___ \_____|__/ |\ \| ________ _________ + / +---\-------+ \ / \ / \ + | Client | (F) | Server |<===>| storeio | + \________/ m_o_supply \________/ \_________/ + (E) return data | ^ + | | (D) device_read + v | + ________ + / Device \ + | Driver | + \________/ + | ^ + | | + v + ____________ + / Hardware \ + +(A) The client does a memory access and [[faults|page_fault]]. The kernel catches the fault and maps the address to the appropriate memory object. It -then invokes the memory\_object\_request method on the associated +then invokes the `memory_object_request` method on the associated capability. (In addition to the page to supply, it also supplies the control port so that the server can determine which kernel sent the message.) -(B) The manager dequeues the message. On the Hurd, this is translated -into a store\_read: a function in the libstore library which is used to -transparently manage block devices. The storeio server starts off as +(B) The manager dequeues the message. On the [[Hurd]], this is translated +into a `store_read`: a function in the [[hurd/libstore]] library which is used to +transparently manage block devices. The [[hurd/storeio]] server starts off as a separate process, however, if the server has the appropriate permission, the backing object can be contacted directly by the server. This layer of indirection is desirable when, for instance, a @@ -134,37 +135,37 @@ storeio running as root may want to only permit read only access to a resource, yet it cannot safely transfer its handle to the client. In this case, it would proxy the requests. -(C) The storeio server contacts, for instance, a device driver to do +(C) The storeio server contacts, for instance, a [[device_driver]] to do the read. This could also be a network block device (the NBD server in GNU/Linux), a file, a memory object, etc. -(D) The device driver allocates an anonymous page from the default -pager and reads the data into it. Once all of the operations are +(D) The device driver allocates an [[anonymous_page]] from the +[[default_pager]] and reads the data into it. Once all of the operations are complete, the device returns the data to the client unmapping it from its own address space at the same time. -(E) The storeio transfers the page to the server. The page is still +(E) The storeio server transfers the page to the server. The page is still anonymous. -(F) The manager does a memory\_object\_supply transferring the page to +(F) The manager does a `memory_object_supply` transferring the page to the kernel. Only now is the page not considered to be anonymous but managed. (G) The kernel caches the page, installs it in the client's virtual -address space and finally, resumes the client. +[[address_space]] and finally, resumes the client. # Paging Data Out -> Change manager Pager m_o_return store_write -> \ _________ (B) __(A)__ (C) ________ (D) _______ -> S | / Default \ / \ / \ / \ -> W |<=>| Pager |<=>| Mach |==>| server |<=>| storeio |<=> -> A | \_________/ \________/ \________/ \_______/ -> P | -> / + Change manager Pager m_o_return store_write + \ _________ (B) __(A)__ (C) ________ (D) _______ + S | / Default \ / \ / \ / \ + W |<=>| Pager |<=>| Mach |==>| server |<=>| storeio |<=> + A | \_________/ \________/ \________/ \_______/ + P | + / -(A) The paging [[policy]] is implemented by Mach: servers just implement +(A) The [[paging]] [[policy]] is implemented by Mach: servers just implement the [[mechanism]]. (B) Once the kernel has selected a page that it would like to evict, it @@ -173,10 +174,22 @@ if the server does not deallocate the page quickly enough, it cannot cause a denial of service: the kernel will just later double page it to swap (the default pager is part of the [[tcb]]). -(C) Mach then invokes memory\_object\_return method on the control -object. The server is expected to save the page free it in a timely +(C) Mach then invokes `memory_object_return` <!-- doesn't exist --> method on the control +object. The server is expected to save the page free <!-- ? --> it in a timely fashion. The server is not required to send a response to the kernel. -(D) The manager then transfers the data to the storeio which +(D) The manager then transfers the data to the storeio server which eventually sends it to disk. The device driver consumes the memory -doing the equivalent of a vm\_deallocate. +doing the equivalent of a `vm_deallocate`. + + +# Issues + + * [[open_issues/performance/io_system/read-ahead]] + + * [[open_issues/performance/io_system/clustered_page_faults]] + + +# GNU Hurd Usage + +Read about the [[Hurd's I/O path|hurd/io_path]]. diff --git a/microkernel/mach/gnumach.mdwn b/microkernel/mach/gnumach.mdwn index f3d6d5f9..edd0cfdb 100644 --- a/microkernel/mach/gnumach.mdwn +++ b/microkernel/mach/gnumach.mdwn @@ -1,15 +1,18 @@ -[[!meta copyright="Copyright © 2001, 2002, 2007, 2008 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -GNU Mach is the microkernel that the [[GNU_Hurd|hurd]] system is based on. +GNU Mach is the microkernel upon which a GNU Hurd system is based. It provides +an Inter Process Communication (IPC) mechanism that the Hurd uses to define +interfaces for implementing in a distributed multi-server fashion the services +a traditional operating system kernel provides. It is maintained by the Hurd developers for the GNU project and remains compatible with [[Mach]] 3.0. @@ -75,6 +78,7 @@ GNU/Hurd. * [[Building]] * [[Debugging]] * [[Boot_Trace]] + * [[Memory_Management]] * [[Projects]] * [[Rules]] * [[Open Issues|tag/open_issue_gnumach]] diff --git a/microkernel/mach/gnumach/boot_trace.mdwn b/microkernel/mach/gnumach/boot_trace.mdwn index d33ef25a..1badf712 100644 --- a/microkernel/mach/gnumach/boot_trace.mdwn +++ b/microkernel/mach/gnumach/boot_trace.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] `if NCPUS > 1` stuff is not being considered so far. @@ -215,6 +216,12 @@ is included in the section entitled >> kern/bootstrap.c: bootstrap\_create +>>> The [[grub/multiboot]] modules have been put somewhere into memory by +>>> [[GRUB]]. The boot scripts are parsed. The modules' ELF image's `PT_LOAD` +>>> sections are \`\`read'' (that is, `vm_allocate` and `copyout`) and turned +>>> into real [[task]]s. The multiboot modules' memory regions can be +>>> deallocated then. + >> [...] >> vm\_pageout diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 9c075600..427fb083 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -1,5 +1,13 @@ -Additional to the following text, a further [[example]] has be posted. +[[!meta copyright="Copyright © 2006, 2007, 2008, 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]]."]]"""]] # Building [[GNU_Mach|gnumach]] from Source @@ -11,55 +19,32 @@ enabled) is around 50 MiB. ## Getting the Source Code -### Developers's RCS +You can either use the git repository (see <http://git.savannah.gnu.org/cgit/hurd/>), -See <http://savannah.gnu.org/cvs/?group=hurd>. + $ git clone http://git.savannah.gnu.org/cgit/hurd/gnumach.git/ - $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co -r gnumach-1-branch gnumach - -(Most probably you want to get hold of the *GNU Mach 1 branch* and not the -trunk, which is also what we've done above.) - -You then have to create the automatically generatable files: - - $ ( cd gnumach && autoreconf --install ) - -### What Debian is currently using - -See [here](http://packages.debian.net/source/unstable/gnumach). +... or get the Debian sources, if you're using Debian. (See +[here](http://packages.debian.net/source/unstable/gnumach).) $ apt-get source gnumach Please see the Debian [[running/debian/FAQ]] before using `apt-get source`. -## Preparing for the Build +## On Debian Systems: -### ... on Debian systems +### Preparing for the Build -Building GNU Mach requires the *build-essential* and *fakeroot* packages, their -dependencies and additional packages that are specified by the source gnumach -package: +Building GNU Mach requires the *build-essential* and *fakeroot* packages, +and some additional dependencies specified by the gnumach source package: # apt-get install build-essential fakeroot # apt-get build-dep gnumach -### ... on non-Debian systems - -Apart from the case that you only want to install GNU Mach's header files (see -below), building GNU Mach requires you to have the Mach Interface Generator -installed. See [[building_MIG|mig/gnu_mig/building]] about how to do that, then come -back here. +### Building and Installing ... Debian `.deb` files -Additionally, building GNU Mach requires a C compiler, a standard C library and -your favourite flavor of awk (gawk) and GNU make. +Change into the directory with the downloaded / unpacked GNU Mach sources, -## Building and Installing - -### ... Debian `.deb` files - -Change into the directory with the downloaded / unpacked GNU Mach sources, e.g. - - $ cd gnumach-20050801 + $ cd gnumach-XXXXXXXX Start the build process with @@ -67,48 +52,68 @@ Start the build process with [[GNU_Mach|gnumach]] is now building. To use the new kernel, you must install the resulting `.deb` package which is located one directory above the build -directory and has a similar name as the build directory, e.g. +directory and has a similar name as the build directory: - # dpkg -i ../gnumach_20050801-4_hurd-i386.deb + # dpkg -i ../gnumach_XXXXXXXX-X_hurd-i386.deb You can now reboot your computer and enjoy the new kernel. -### [TODO] +## On non-Debian Systems: -GNU Mach should be built in a separate directory: +### Preparing for the Build - $ mkdir gnumach-build - $ cd gnumach-build +Building GNU Mach requires a C compiler, a _static_ 32 bit standard C library, +your favourite flavor of awk (gawk) and GNU make. -Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure -it: +First, create the configuartion files: - $ [...]/gnumach-1-branch/configure [TODO] + $ cd gnumach + $ autoreconf --install -Build the kernel image: +GNU Mach (and the associated headers) need be built in a separate build directory: - $ make gnumach.gz + $ mkdir build + $ cd build -Optionally run the (tiny) test suite: +Run configure: - $ make check + $ ../configure --prefix= -You can then install and use `gnumach.gz`. +If building on a 64 bit host system, +you need a number of additional settings to force a 32 bit build: -[TODO.] + $ CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ../configure --prefix= --host=i686-unknown-linux-gnu -### Installing only the Header Files +### Installing the Header Files First -GNU Mach should be built in a separate directory: +In order to build GNU Mach, you will need a working MIG. +Building MIG in turn requires the GNU Mach header files to be already present. +So for bootstrapping MIG, you have to install the Mach headers first, +for example into `~/gnu/include/`: - $ mkdir gnumach-build - $ cd gnumach-build + $ make DESTDIR=~/gnu install-data -Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure -it: +Now you can [[build_MIG|mig/gnu_mig/building]]. +Once you are done with that, come back here to finish the Mach build. - $ [...]/gnumach-1-branch/configure --prefix= +### Building and Installing -Install the header files into e.g. `~/gnu/include/`: +With MIG present, now build the kernel image: + + $ make gnumach.gz + +Optionally run the (tiny) test suite: + + $ make check + +It's a good idea to make a backup of the previously installed kernel, in case +you can't boot using the new one. That way, you can restore it after booting +from a rescue media (or mounting the disk image used by your vm). + + # cp /boot/gnumach.gz /boot/gnumach.gz.bak + +GNU Mach can now be moved into place, typically `/boot/gnumach.gz`, so that you +can boot your system with the new kernel. + + # cp gnumach.gz /boot - $ make DESTDIR=~/gnu install-data diff --git a/microkernel/mach/gnumach/building/example.mdwn b/microkernel/mach/gnumach/building/example.mdwn deleted file mode 100644 index 7db98547..00000000 --- a/microkernel/mach/gnumach/building/example.mdwn +++ /dev/null @@ -1,54 +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]]."]]"""]] - -## Compiling GNU Mach microkernel - -Host development system is IBM T41 running Debian Sarge 3.1r0a GNU/Linux. - -* gcc version: 3.3.5 -* GNU sed version: 4.1.2 -* GNU make version: 3.8 -* mig version: 1.3-4 - -Obtained gnumach-1-branch sources from cvs: - - export CVS_RSH="ssh" - cvs -z3 -d:ext:anoncvs@ savannah.gnu.org:/cvsroot/hurd co -r gnumach-1-branch gnumach - -Obtained mig_1.3-4_i386.deb from -http://www.hadrons.org/~guillem/debian/pool/main/mig/. Installed it using dpkg: - - dpkg -i mig_1.3-4_i386.deb - -Entered into the gnumach sources and did the following for compilation: - - mkdir build - cd build - ../configure --host=i386-unknown-gnu0.2 --build=i586-pc-linux-gnu \ - --enable-kdb --enable-ide - make - -The kernel file is created in the build directory. Move it to /boot on the -testing x86 system Hurd partition. Rename it as gnumach1 and compress it: - - mv kernel gnumach1 - gzip gnumach1 - -Add a new entry on the testing machine /boot/grub/menu.lst to boot the new -kernel. - - title GNU Hurd K10 Compiled gnumach - kernel (hd0,3)/boot/gnumach1.gz root=device:hd2s4 -s - module (hd0,3)/hurd/ext2fs.static--multiboot-command-line=${kernel-command-line} \\ - --host-priv-port=${host-port} --device-master-port=${device-port} \\ - --exec-server-task=${exec-task} -T typed ${root} $(task-create)$(task-resume) - module (hd0,3)/lib/ld.so.1 /hurd/exec $(exec-task=task-create) - -Reboot into the new compiled mygnumach1.gz kernel! diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn index 3a93c6ad..71e92459 100644 --- a/microkernel/mach/gnumach/debugging.mdwn +++ b/microkernel/mach/gnumach/debugging.mdwn @@ -1,23 +1,82 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Here are some hints to debug with GNU Mach. + +[[!toc levels=2]] + + +# Kernel Debugger Mach has a built-in kernel debugger. [Manual](http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html). +First, make sure to enable it. Either by using a pre-packaged gnumach-image-something-dbg, or by passing --enable-kdb to the ./configure invocation. + +Then, reproduce the issue again. If something like a kernel trap happens, you will end up in the GNU Mach debugger. Otherwise, type control-alt-d to make Mach enter it by hand. + +If you are running in kvm or qemu, it is convenient to use the curses frontend to be able to copy/paste. + +To get the register values, type + + show registers + +To get a backtrace, type + + trace + +, which will print both function return addresses and function parameters, such as + + 0x107cf1(8088488,5e,40000008,2aa008,0) + 0x1071bc(0,0,0,0,0) + 0x106831(24fe00,2000,b,800,0) + +Run the addr2line tool on the return addresses: + + $ addr2line -i -f -e /boot/gnumach 0x107cf1 0x1071bc 0x106831 + +This will print the source code lines of the backtrace. + +To examine the backtrace of some given thread, use + + show all thread/u + +to get the whole listing of all tasks and threads. You can then use trace/t to trace a specific thread. + +Unfortunately, userland and kernelland use the same range of addresses, so one can not get userland traces easily. The Xen port uses different ranges, and in that case one can use trace/u to also get the userland trace. + +To examine a variable, use nm /boot/gnumach to get the address of the variable (e.g. 0x123400), and use + + x 0x123400 + +to read it. One can also write to it by using + + w 0x123400 + +Another interesting feature is watching a variable, by using + + watch 0x123400 + +and then type continue, to let Mach continue execution. The debugger will be entered again on any change in that variable. The watch is implemented in hardware, so it does not disturb or slow down execution at all. + + +# GDB in QEMU When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly [use GDB on the running kernel](http://www.nongnu.org/qemu/qemu-doc.html#SEC48). +# Code Inside the Kernel + Alternatively you can use an approach like this one: add the following code snippet to `device/ds_routines.c`'s `ds_device_open` function, right at the top of the function, and modify the code as needed. @@ -56,6 +115,8 @@ This is especially useful if you need to manually trigger some stuff inside the running kernel, as with the *D1* example. +## Writing to the Screen Buffer + If you're doing real low level debugging, you might want to put variations of the following snipped into the code, this code will write a `#` character at line `[LINE]`, column `[COLUMN]` on the screen: @@ -67,3 +128,22 @@ The call of `halt_cpu` will -- as the name suggests -- halt the system afterwards. This might be what you want or it might not, but it is needed at some place when running the kernel inside QEMU, as QEMU somehow decides not to update its display buffer anymore under certain conditions. + + +# Halting the CPU and Examining Registers + +IRC, freenode, #hurd, 2011-07-14: + + <braunr> one ugly trick i use when printf isn't available is to halt the + cpu + <braunr> then use info registers to know where the cpu is halted + <braunr> and you'll know if you reached that code or not + <braunr> (info registers is a qemu command) + + +# Serial Console + +IRC, freenode, #hurd, 2011-11-13: + + <youpi> use console=com0 + <youpi> to activate the console on the first serial port diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn index 2152c079..874f5f07 100644 --- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn +++ b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] # CPU Architecture @@ -29,7 +29,7 @@ Read about further [[ports]]. # Memory -GNU Mach will use a maximum of 1 GiB of RAM. If your system has more, +GNU Mach will use a maximum of 1.7 GiB of RAM. If your system has more, the surplus will silently be ignored. (In past times, this would hinder GNU Mach from booting at all, but this has been fixed, so you no longer need to apply GRUB's `uppermem` directive.) @@ -68,10 +68,11 @@ All common IDE drives should work. Some drive geometries do not work, e.g. drives with hundreds of GiB of storage space, see [[!GNU_Savannah_bug 26425]]. -[[!toggle id="SATA" text="SATA drives may work in compatibility mode."]] -<!-- Sure? --[[tschwinge]] --> -[[!toggleable id="SATA" text=""" +## SATA + +SATA drives may work in compatibility mode. + This is how booting a [[GNU/Hurd_system|hurd]] will typically fail if GNU Mach couldn't connect to the hard disk, e.g., in a SATA system without IDE compatibility mode: @@ -81,7 +82,7 @@ compatibility mode: There *may* be an option in the system's BIOS setup to configure enabling such a compatibility mode. -"""]] + # Device Drivers diff --git a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn index 69ca3190..2b65956a 100644 --- a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn +++ b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn @@ -1,4 +1,33 @@ +[[!meta copyright="Copyright © 2007, 2008, 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]] + Further information may still be found on <http://www.nongnu.org/thug/gnumach_hardware.html> and could perhaps be incorporated into that page. --[[tschwinge]] + + +# SATA + +IRC, freenode, +hurd, 2011-07-24 + + <braunr> youpi: concerning the ide compatibility problem, it seems some + bioses provide several modes + <braunr> youpi: "legacy ide" and "native ide" + <braunr> i don't know what native ide really means, but when debugging ide + probing in gnumach, it just looks like there is nothing to detect + <braunr> and even in this mode, linux uses the ahci driver + <youpi> apparently native means it still uses the IDE protocol, but + possibly with other IRQs + <youpi> i.e. you need a PCI driver to handle that + <braunr> ok diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn new file mode 100644 index 00000000..c630af05 --- /dev/null +++ b/microkernel/mach/gnumach/memory_management.mdwn @@ -0,0 +1,121 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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 open_issue_gnumach]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-02-15 + + <braunr> etenil: originally, mach had its own virtual space (the kernel + space) + <braunr> etenil: in order to use linux 2.0 drivers, it now directly maps + physical memory, as linux does + <braunr> etenil: but there is nothing similar to kmap() or vmalloc() in + mach, so the kernel is limited to its 1 GiB + <braunr> (3 GiB userspace / 1 GiB kernelspace) + <braunr> that's the short version, there is a vmalloc() in mach, but this + trick made it behave almost like a kmalloc() + <antrik> braunr: the direct mapping is *only* for the benefit of Linux + drivers?... + <braunr> also, the configuration of segments limits the kernel space + <braunr> antrik: i'm not sure, as i said, this is the short version + <braunr> antrik: but there is a paper which describes the integration of + those drivers in mach + <etenil> you mean the linux 2.0 drivers? + <antrik> braunr: I read it once, but I don't remember anything about the + physical mapping in there... + <antrik> etenil: well, originally it was 1.3, but essentially that's the + same... + <braunr> i don't see any other reason why there would be a direct mapping + <braunr> except for performance (because you can use larger - even very + lage - pages without resetting the mmu often thanks to global pages, but + that didn't exist at the time) + + +# IRC, freenode, #hurd, 2011-02-15 + + <antrik> however, the kernel won't work in 64 bit mode without some changes + to physical memory management + <braunr> and mmu management + <braunr> (but maybe that's what you meant by physical memory) + +## IRC, freenode, #hurd, 2011-02-16 + + <braunr> antrik: youpi added it for xen, yes + <braunr> antrik: but you're right, since mach uses a direct mapped kernel + space, the true problem is the lack of linux-like highmem support + <braunr> which isn't required if the kernel space is really virtual + + +# IRC, freenode, #hurd, 2011-06-09 + + <braunr> btw, how can gnumach use 1 GiB of RAM ? did you lower the + user/kernel boundary address ? + <youpi> I did + <braunr> 2G ? + <youpi> yes + <braunr> ok + <youpi> it doesn't make so much sense to let processes have 3G addressing + space when there can't be more that 1G physical memory + <braunr> that's sad for an operating system which does most things by + mapping memory eh + <youpi> well, if a process wants to map crazy things, 3G may be tight + already + <youpi> e.g. ext2fs + <braunr> yes + <youpi> so there's little point in supporting them + <braunr> we need hurd/amd64 + <youpi> and there's quite some benefit in shrinking them to 2G + <youpi> yes + <youpi> actually even 2G may become a bit tight + <youpi> webkit linking needs about 1.5-2GiB + <youpi> things become really crazy + <braunr> wow + <braunr> i remember the linux support for 4G/4G split when there was enough + RAM to fill the kernel space with struct page entries + + +# IRC, freenode, #hurd, 2011-11-12 + + <youpi> well, the Hurd doesn't "artificially" limits itself to 1.5GiB + memory + <youpi> i386 has only 4GiB addressing space + <youpi> we currently chose 2GiB for the kernel and 2GiB for the userspace + <youpi> since kernel needs some mappings, that leaves only 1.5GiB usable + physical memory + <sea4ever`> Hm? 2GiB for kernel, 2GiB for userspace, 500MiB are used for + what? + <youpi> for mappings + <youpi> such as device iomap + <youpi> contiguous buffer allocation + <youpi> and such things + <sea4ever`> Ah, ok. You map things in kernel space into user space then. + <youpi> linux does the same without the "bigmem" support + <youpi> no, just in kernel space + <youpi> kernel space is what determines how much physical memory you can + address + <youpi> unless using the linux-said-awful "bigmem" support + + +# IRC, freenode, #hurd, 2012-07-05 + + <braunr> hm i got an address space exhaustion while building eglibc :/ + <braunr> we really need the 3/1 split back with a 64-bits kernel + <pinotree> 3/1? + <braunr> 3 GiB userspace, 1 GiB kernel + <pinotree> ah + <braunr> the debian gnumach package is patched to use a 2/2 split + <braunr> and 2 GiB is really small for some needs + <braunr> on the bright side, the machine didn't crash + <braunr> there is issue with watch ./slabinfo which turned in a infinite + loop, but it didn't affect the stability of the system + <braunr> actually with a 64-bits kernel, we could use a 4/x split diff --git a/microkernel/mach/gnumach/ports.mdwn b/microkernel/mach/gnumach/ports.mdwn index a29b8651..f114460c 100644 --- a/microkernel/mach/gnumach/ports.mdwn +++ b/microkernel/mach/gnumach/ports.mdwn @@ -1,15 +1,24 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] * x86. This is the main port. + + * [[Xen]] + * [PowerPC](http://www.pjbruin.dds.nl/hurd/). Is not in a usable state. - * Alpha. Was once started, but isn't in a usable state either. - * [[Xen]] + * Alpha: [project I](http://savannah.nongnu.org/projects/hurd-alpha), and + [project II](http://savannah.nongnu.org/projects/gnumach-alpha). Was once + started, but isn't in a usable state either. + + * MIPS. Status completely unknown. + + * [[open_issues/Mach_on_Top_of_POSIX]]. Status unknown. diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index c544fd57..c6023786 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,12 +6,13 @@ id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!toc]] -## Xen dom0, hypervisor + +# Xen dom0, hypervisor /!\ Now that GNU Mach handles PAE you can use a PAE-enabled hypervisor. @@ -20,7 +21,7 @@ You can either get binaries at <http://youpibouh.thefreecat.org/hurd-xen/> or bu - Copy `gnumach-xen-pae` and `hurd-modules` to your dom0 /boot. If you still have a non-PAE hypervisor, use `gnumach-xen-nonpae` instead. - Copy `hurd` into `/etc/xen`, edit it for fixing access to your hurd / and swap -## GNU/Hurd system +# GNU/Hurd system /!\ You need an already installed [[GNU/Hurd_system|hurd/running]]. @@ -30,7 +31,8 @@ If you have a free partition, you can fdisk to type 0x83, create a filesystem us Replace /dev/sda4 with your partition. Install and use crosshurd to setup a GNU/Hurd system on this partition. -## /etc/xen/hurd configuration + +# /etc/xen/hurd configuration Here is a sample /etc/xen/hurd configuration @@ -49,7 +51,8 @@ Suggestions about [[networking_configuration]] are available. If you need stable MAC addresses, use a syntax like `vif = [ 'mac=00:16:3e:XX:XX:XX, bridge=br0' ]`. -## Running Hurd with Xen + +# Running Hurd with Xen To run Hurd with Xen, use: @@ -63,7 +66,8 @@ and gnumach should get started. Proceed with native-install. - If `xm` complains about networking (`vif could not be connected`), it's Xen scripts' fault, see Xen documentation for how to configure the network. The simplest way is network-bridge with fixed IPs (note that you need the bridge-utils package for this). You can also just disable networking by commenting the vif line in the config. - If `xm` complains `Error: (2, 'Invalid kernel', 'xc_dom_compat_check: guest type xen-3.0-x86_32 not supported by xen kernel, sorry\n')`, you most probably have a PAE-enabled hypervisor and a non-PAE gnumach. Either install and boot non-PAE hypervisor and kernel, or rebuilt gnumach in PAE mode. -## Building from sources + +# Building from sources If you want to generate these images, first get the `gnumach-1-branch-Xen-branch` branch from gnumach CVS. Then look for "Ugly" in `kern/bootstrap.c`, how to generate `hurd-modules` is explained there, and you'll have to fix `EXT2FS_SIZE` and `LD_SO_SIZE` by hand. @@ -75,8 +79,49 @@ Then use The current `hurd-modules` was built from the debian packages `hurd 20070606-2` and `libc0.3 2.6.1-1`. /!\ This means that when using this image, your GNU/Hurd system also needs to be a glibc version 2.6 or later-based one! ---- +# `pv-grub` + +From Xen 4.0 on you can run the GNU Hurd directly using `pv-grub`, +without the need to [prepare a special bootstrap +image](http://youpibouh.thefreecat.org/hurd-xen/build_hurd-modules) (like an +initrd). + +Download http://youpibouh.thefreecat.org/hurd-xen/pv-grub.gz into /boot, and use the following for instance: + + kernel = "/boot/pv-grub.gz" + memory = 256 + disk = ['phy:sda4,hda,w'] + extra = "(hd0,1)/boot/grub/menu.lst" + vif = [ '' ] + +extra is now the path to the grub config file. + +# Partitions + +You will need the following notation for the gnumach root= parameter: + +root=part:2:device:hd0 + +to access the second partition of hd0, for instance. + +You will also need to use the parted storeio module for the /dev entries, for instance: + +settrans -fgap /dev/hd0s1 /hurd/storeio -T typed part:1:device:hd0 + +# Miscellaneous [[Internals]]. [[!GNU_Savannah_task 5468]], [[!GNU_Savannah_task 6584]]. + + +# Host-side Writeback Caching + +Optimization possible as it is with +[[QEMU|hurd/running/qemu/writeback_caching]]? + +IRC, freenode, #hurd, 2011-06-08 + + <braunr> youpi: does xen provide disk caching options ? + <youpi> through a blktap, probably + <braunr> ok diff --git a/microkernel/mach/gnumach/ports/xen/discussion.mdwn b/microkernel/mach/gnumach/ports/xen/discussion.mdwn new file mode 100644 index 00000000..2980e3b2 --- /dev/null +++ b/microkernel/mach/gnumach/ports/xen/discussion.mdwn @@ -0,0 +1,14 @@ +[[!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]] + +Stuff from <http://youpibouh.thefreecat.org/hurd-xen> should be merged into +these pages here. diff --git a/microkernel/mach/gnumach/projects.mdwn b/microkernel/mach/gnumach/projects.mdwn index 47a2756c..f4ef192a 100644 --- a/microkernel/mach/gnumach/projects.mdwn +++ b/microkernel/mach/gnumach/projects.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2005, 2006, 2007, 2008 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] This page is a place to keep track of ideas about things that may be improved in GNU Mach, so that it'll evolve to a reliable microkernel for The Hurd, both @@ -58,7 +58,8 @@ so that no duplicate efforts end up. * Improve the external pagers interface - * Implement read-ahead (huge I/O improvements expected). + * Implement [[open_issues/performance/io_system/read-ahead]] (huge I/O + improvements expected). * Making this interface synchronous should improve I/O performance significantly, without (almost) any drawbacks (we also get some diff --git a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn b/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn index e865e61a..2a9b4b60 100644 --- a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn +++ b/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2005, 2006, 2007, 2008 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2010 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -9,6 +9,8 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] +[[!tag open_issue_gnumach]] + # Restructure the tree in a sane way Merge `linux/src` and `linux/dev`. But only if using a sane RCS, so leave it diff --git a/microkernel/mach/gnumach/projects/gdb_stubs.mdwn b/microkernel/mach/gnumach/projects/gdb_stubs.mdwn index ef1b4909..064da7bf 100644 --- a/microkernel/mach/gnumach/projects/gdb_stubs.mdwn +++ b/microkernel/mach/gnumach/projects/gdb_stubs.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,6 +8,12 @@ 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_gdb]] + * <http://lists.gnu.org/archive/html/bug-hurd/2008-04/msg00103.html> * [ChangeLog.gdb](http://cvs.savannah.gnu.org/viewvc/gnumach/ChangeLog.gdb?root=hurd&view=markup&pathrev=gnumach-1-branch-gdb-branch) + +This may be another follow-up project: [*Linux Kernel GDB tracepoint +module*](http://thread.gmane.org/gmane.comp.gdb.devel/29369), Hui Zhu, +2010-10-09. diff --git a/microkernel/mach/history.mdwn b/microkernel/mach/history.mdwn index a8951737..5a3608cd 100644 --- a/microkernel/mach/history.mdwn +++ b/microkernel/mach/history.mdwn @@ -1,7 +1,3 @@ -# <a name="Table_of_Contents"> Table of Contents </a> - -%TOC% - # <a name="Early_beginnings"> Early beginnings </a> Mach has quite a history. Everything actually started at the University of Rochester in 1975. It was invented to demonstrate how operating systems could be built using a modular design where processes communicated using message passing, even across networks. The system was called the Rochester Intelligent Gateway and ran on a 16 bit mini computer called Eclipse from Data General. diff --git a/microkernel/mach/ipc.mdwn b/microkernel/mach/ipc.mdwn index aaf3ba23..1bb44b59 100644 --- a/microkernel/mach/ipc.mdwn +++ b/microkernel/mach/ipc.mdwn @@ -1,22 +1,21 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[General_information|/ipc]] about IPC. +Read about the [[general concept of *inter-process communication* (IPC)|/ipc]]. -An IPC is sent by invoking a [[port]]. <!-- Isn't this wording a bit strange? -``IPC is sent'' --tschwinge --> +On Mach, an IPC is done by invoking a [[port]]. + +The two fundamental operations, to *send* and *receive* [[message]]s, are used +to implement a [[RPC]] system. [[Sequence_numbering]]. [The Unofficial GNU Mach IPC beginner's guide](http://www.nongnu.org/hurdextras/ipc_guide/ipc_guide.html) - -# See Also - -* [[RPC]] diff --git a/microkernel/mach/memory_object.mdwn b/microkernel/mach/memory_object.mdwn new file mode 100644 index 00000000..f32fe778 --- /dev/null +++ b/microkernel/mach/memory_object.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 2002, 2003, 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 +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]]."]]"""]] + +Mach's [[virtual_memory]] subsystem uses *memory objects* for supplying the +content of regions of virtual memory in an [[virtual_address_space]]. + +All of these objects are managed by *memory manager*s, that are also called +*pager*s. These can be implemented as user-space processes. + +Both the memory objects, and their managers are kernel objects, and are +accessed by [[port]]s. + +A system's physical memory is conceived as a *memory cache* that contains +*memory cache objects*. So when a [[thread]] accesses a page in its task's +address space, the memory object that includes this page is *cached* in the +memory cache. Memory objects are [[paged out and paged +in|external_pager_mechanism]] by the aforementioned memory managers. The +decision when they should be paged in or paged out is left to [[Mach]]. Each +memory object has an ordered list of memory managers that provide paging. The +last one tried is the *default memory manager* that resides in the microkernel, +in contrast to most of the others. The default memory manager is needed +because the microkernel can't wait infinitely for someone else to free the +memory cache: it just calls the next memory manager hoping it to succeed. + +Read about [[GNU Mach's memory management|gnumach/memory_management]]. diff --git a/microkernel/mach/memory_object/discussion.mdwn b/microkernel/mach/memory_object/discussion.mdwn new file mode 100644 index 00000000..907f859a --- /dev/null +++ b/microkernel/mach/memory_object/discussion.mdwn @@ -0,0 +1,74 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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 open_issue_gnumach]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-08-05 + + < neal> braunr: For instance, memory objects are great as they allow you to + specify the mapping policy in user space. + < neal> braunr: But, the policy for determining the eviction order is + realized by Mach + < neal> braunr: And user-space has no control + < braunr> are you referring to the page cache lru approximation and stuff + like resource containers ? + < neal> I'm not sure what you mean by page cache lru appoximateion + < braunr> the kernel eviction policy :) + < neal> that's an implementation detail + + +# IRC, freenode, #hurd, 2011-09-05 + + <braunr> mach isn't a true modern microkernel, it handles a lot of + resources, such as high level virtual memory and cpu time + <braunr> for example, the page replacement mechanism can't be implemented + outside the kernel + <braunr> yet, it provides nothing to userspace server to easily allocate + resources on behalf of clients + <braunr> so, when a thread calls an RPC, the cpu time used to run that RPC + is accounted on the server task + <braunr> the hurd uses lots of external memory managers + +[[external_pager_mechanism]]. + + <braunr> but they can't decide how to interact with the page cache + <braunr> the kernel handles the page cache, and initiates the requests to + the pagers + <cjuner> braunr, why can't they decide that? + <braunr> because it's implemented in the kernel + <braunr> and there is nothing provided by mach to do that some other way + <slpz_> braunr: you probably already know this, but the problem with client + requests being accounted on behalf the server, is fixed in Mach with + Migrating Threads + +[[open_issues/mach_migrating_threads]]. + + <braunr> slpz_: migrating threads only fix the issue for the resources + managed by mach, not the external servers + <braunr> slpz_: but it's a (imo necessary) step to completely solve the + issue + <braunr> in addition to being a great feature for performance (lighter + context switchers, less state to track) + <braunr> it also helps priority inversion problems + <slpz_> braunr: I was referring just to cpu-time, but I agree with you an + interface change is needed for external pagers + <braunr> slpz_: servers in general, not necessarily pagers + <slpz_> as a way to mitigate the effect of Mach paging out to external + pagers, the folks at OSF implemented an "advisory pageout", so servers + are "warned" that they should start paging out, and can decide which + pages are going to be flushed by themselves + +[[open_issues/resource_management_problems]]. + + +# [[open_issues/memory_object_model_vs_block-level_cache]] diff --git a/microkernel/mach/message.mdwn b/microkernel/mach/message.mdwn new file mode 100644 index 00000000..ba47671e --- /dev/null +++ b/microkernel/mach/message.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +*Messages* are collections of typed data, with a defined layout. + +They are used for [[IPC]], and are sent to and received from [[port]]s. + +These messages are not only opaque data. They can also contain [[port +rights|port]] to be passed to another [[task]]. Port rights are either +*copied* or *moved*. Notice that port receive right must be moved but not +copied because there can't be more than one task that holds the receive right +to a port. The receiving task creates new local port name to the port rights +it received. + +Some data in the message can be *out-of-line data*. In the message, these are +*references* to memory regions ([[memory_object]]s) that are *virtually +copied*. When the message is received in a task, these virtual copies become +part of the task by mapping them into the receiver's [[virtual_address_space]]. +Another key concept that is applied is using *copy-on-write*, which means that +data is not copied immediately, but only when it is changed. This is primarily +used to send large blocks of data efficiently, as it is too expensive to store +them in the kernel address space: extra copied need only be made at the moment +that the memory regions begin to diverge, by threads modifying them. diff --git a/microkernel/mach/mig.mdwn b/microkernel/mach/mig.mdwn index 4275a4b4..331b3bf4 100644 --- a/microkernel/mach/mig.mdwn +++ b/microkernel/mach/mig.mdwn @@ -1,21 +1,34 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2006, 2007, 2008 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2003, 2006, 2007, 2008, 2010 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -The Mach Interface Generator (MIG) is an [[IDL]] compiler. Based on an -interface definition, it creates stubs to [[invoke]] object methods -and to demultiplex incoming messages. These stubs conveniently hide -the details of Mach's [[IPC]] machinery and make it easy to implement -and use Mach [[interface]]s as [[remote_procedure_calls_(RPC)|rpc]]. +The *Mach Interface Generator* (*MIG*) is an [[IDL]] compiler. Based on an +interface definition, it creates stub code to [[invoke]] object methods and to +demultiplex incoming messages. These stub functions conveniently hide the +details of Mach's [[IPC]] and [[port]] machinery and make it easy to implement +and use Mach [[interface]]s as [[remote procedure calls (RPC)|rpc]]: by using +the stub functions, the client programs can call remote procedures more or less +like any other C function. + +These functions encode arguments into [[message]]s' format (*marshalling*), +wait for a result on a newly created [[reply port|port]], decode return +arguments from the reply message (*demarshalling*, or *unmarshalling*) and pass +them to the client program. Similar actions are provided in the skeletons that +are linked to server programs. + +MIG allows very precise semantics to be specified about what the arguments are +and how to be passed. + + + * [[Documentation]] -* [[Documentation]] # Implementations diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn index 82d51a72..7d4f1eca 100644 --- a/microkernel/mach/mig/documentation.mdwn +++ b/microkernel/mach/mig/documentation.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] This is a small collection of links to external documents describing the *Mach Interface Generator* used by GNU Mach. @@ -17,23 +17,23 @@ Interface Generator* used by GNU Mach. A tutorial which demonstrates the use of the C Threads library primitives in writing a multithreaded program and the use of the Mach Interface Generator -(MIG) to generate remote procedure calls for interprocess communication. Like +(MIG) to generate remote procedure calls for inter-process communication. Like its companion tutorial, it is based on the Mach 2.5 system. However, the concepts are applicable to Mach 3.0 user level programming. Linda R. Walmer and Mary R. Thompson. *A Programmer's Guide to the Mach User Environment*. [PostScript -](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/machuse.ps), -[Doc](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/machuse.doc). +](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/machuse.ps), +[Doc](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/machuse.doc). February 1988. School of Computer Science, Carnegie Mellon University. An ftp directory containing the [mig programming -examples](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig_example) +examples](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig_example) for this tutorial. Slides to Rich Drave's talk on MIG, on November 21, 1991: -[PostScript](ftp://ftp.cs.cmu.edu//afs/cs/project/mach/public/doc/unpublished/internals_slides/Mig/root.ps), -[TeX](ftp://ftp.cs.cmu.edu//afs/cs/project/mach/public/doc/unpublished/internals_slides/Mig/slides.tex). +[PostScript](http://www.cs.cmu.edu//afs/cs/project/mach/public/doc/unpublished/internals_slides/Mig/root.ps), +[TeX](http://www.cs.cmu.edu//afs/cs/project/mach/public/doc/unpublished/internals_slides/Mig/slides.tex). # Roots @@ -41,15 +41,15 @@ Slides to Rich Drave's talk on MIG, on November 21, 1991: Mig is an implementation of a subset of the Matchmaker **language**. "Matchmaker is a language for specifying and automating the generation of -multilingual interprocess communication interfaces. MIG is an interim +multilingual inter-process communication interfaces. MIG is an interim implementation of a subset of the Matchmaker language that generates C and C++ -remote procedure call interfaces for interprocess communication between Mach +remote procedure call interfaces for inter-process communication between Mach tasks." Richard P. Draves, Michael B. Jones, Mary R. Thompson, *MIG - THE MACH INTERFACE GENERATOR*. -[ps](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps), -[doc](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.doc). +[ps](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps), +[doc](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.doc). November 1989. Department of Computer Science, Carnegie-Mellon University. @@ -70,6 +70,12 @@ pp. 67--77." [Chapter 4, Inter Process Communication](http://www.gnu.org/software/hurd/gnumach-doc/Inter-Process-Communication.html). + * OSF's [Server Writer's Guide (ps)](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_writer.ps) + [Server Writer's Guide (pdf)](http://shakthimaan.com/downloads/hurd/server_writer.pdf) + + * OSF's [Server Writer's Interfaces (ps)](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_interface.ps) + [Server Writer's Interfaces (pdf)](http://shakthimaan.com/downloads/hurd/server_interface.pdf) + * Flags: * [[dealloc_and_dealloc[]|dealloc]] diff --git a/microkernel/mach/mig/gnu_mig.mdwn b/microkernel/mach/mig/gnu_mig.mdwn index 1bcbd545..0de1bd67 100644 --- a/microkernel/mach/mig/gnu_mig.mdwn +++ b/microkernel/mach/mig/gnu_mig.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2001, 2006, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2001, 2006, 2008, 2009, 2010 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] GNU MIG is the GNU distribution of the [[Mach_3.0_interface_generator_*MIG*|mig]], as maintained by the GNU Hurd @@ -20,5 +20,9 @@ software in the GNU system that uses Mach-based GNU MIG is fully compatible with [[OSF_MIG|mig]]. +Like its predecessor, it can only generate C code, that has to be compiled and +linked to client and server programs respectively ([[!taglink +open_issue_mig]]). + * [[Building]] - building (and obtaining) GNU MIG * [[Open Issues|tag/open_issue_mig]] diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index f92f7dbe..e7d3c150 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -1,15 +1,28 @@ +[[!meta copyright="Copyright © 2006, 2007, 2008, 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]]."]]"""]] + # <a name="Building_the_Mach_Interface_Gene"> Building the Mach Interface Generator from Source </a> -If you want to build the Mach Interface Generator yourself instead of just using a pre-built package, follow these instructions. +If you want to build the Mach Interface Generator yourself instead of just +using a pre-built package, follow these instructions. ## <a name="Getting_the_Source_Code"> Getting the Source Code </a> You can chose between getting the [sources from the developers' -RCS](http://savannah.gnu.org/cvs/?group=hurd): +RCS](http://git.savannah.gnu.org/cgit/hurd/): - $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co mig + $ git clone http://git.savannah.gnu.org/cgit/hurd/mig.git/ -... or (if you are working on a Debian system) the ones that are used for the [current Debian mig package](http://packages.debian.net/source/unstable/mig): +... or (if you are working on a Debian system) get the sources that are used for the +[current Debian mig package](http://packages.debian.net/source/unstable/mig): $ apt-get source mig @@ -17,53 +30,70 @@ Please see the Debian [[hurd/running/debian/FAQ]] before using _apt-get source_. The unpacked source tree is around 1 MiB, and the build tree also is around 1 MiB. -## <a name="Preparing_for_the_Build"> Preparing for the Build </a> +## <a name="_on_Debian_systems"> On Debian Systems: </a> -### <a name="_on_Debian_systems"> ... on Debian systems </a> +### <a name="Preparing_for_the_Build"> Preparing for the Build </a> -Building the Mach Interface Generator requires the _build-essential_ and _fakeroot_ packages, their dependencies and additional packages that are specified by the source mig package: +Building MIG requires the *build-essential* and *fakeroot* packages, +and some additional dependencies specified by the mig source package: # apt-get install build-essential fakeroot # apt-get build-dep mig -### <a name="_on_non_Debian_systems"> ... on non-Debian systems </a> +### <a name="Building_and_Installing"> Building and Installing </a> <a name="_a_deb_file"> ... a _.deb_ file </a> -Building the Mach Interface Generator requires a C compiler, a standard C library (with corresponding header files) and your favourite flavor of awk (gawk), yacc (bison), lex (flex) and make. +Change into the directory with the downloaded / unpacked MIG sources: -Additionally, you need to have GNU Mach's header files installed. See -[[mach/gnumach/building]] about how to do that, then come back here. + $ cd mig-X.X.X.XX -## <a name="Building_and_Installing"> Building and Installing </a> +Start the build process: -### <a name="_a_deb_file"> ... a _.deb_ file </a> + $ dpkg-buildpackage -us -uc -b -rfakeroot -Change into the directory with the downloaded / unpacked MIG sources (_mig-1.3.1.99_): +This will create a _.deb_ package in the parent directory, +which you can then install on your system. - $ cd mig-1.3.1.99 +## <a name="_on_non_Debian_systems"> On non-Debian Systems: </a> -Start the build process: +### <a name="Preparing_for_the_Build"> Preparing for the Build </a> - $ dpkg-buildpackage -us -uc -b -rfakeroot +Building the Mach Interface Generator requires a C compiler, a standard 32 bit +C library (with corresponding header files), your favourite flavor of awk +(gawk), yacc (bison), lex (flex) and make. -You can then install / distribute the _.deb_ file which will drop out one directory above the current one. +Additionally, you need to have GNU Mach's header files installed. See +[[building GNU Mach|mach/gnumach/building]] about how to do that, then come back here. + +### <a name="Building_and_Installing"> Building and Installing </a> + +First, generate the configuration files: -### <a name="_TODO_"> [TODO] </a> + $ cd mig + $ autoreconf --install -The Mach Interface Generator has to be built in a separate directory: +The Mach Interface Generator has to be built in a separate build directory: - $ mkdir mig-build - $ cd mig-build + $ mkdir build + $ cd build + +Find the base directory where you installed GNU Mach's header files and where +you now intend to install the Mach Interface Generator (e.g. _~/gnu_), and run +configure: + + $ GNU=~/gnu + $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" -Find the root directory where you installed GNU Mach's header files and where you now intend to install the Mach Interface Generator (_~/gnu_) and the path to your Mach Interface Generator sources (\_[...]/mig) and configure it: +If you are building on a 64 bit machine, you need to add a --host option: $ GNU=~/gnu - $ TARGET_CPPFLAGS=-I"$GNU"/include [...]/mig/configure --prefix="$GNU" + $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" --host=i686-unknown-linux-gnu -Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: +Build and install the Mach Interface Generator into _$GNU_ (i.e. _~/gnu/_ in our example): $ make all install -To make your _mig_ binary easily available, you should append something like the following to e.g. your _~/.bash\_profile_: +To make your _mig_ binary easily available, you should append something like +the following to e.g. your _~/.bash\_profile_: PATH=~/gnu/bin:$PATH export PATH diff --git a/microkernel/mach/mig/gnu_mig/building/discussion.mdwn b/microkernel/mach/mig/gnu_mig/building/discussion.mdwn new file mode 100644 index 00000000..d7636158 --- /dev/null +++ b/microkernel/mach/mig/gnu_mig/building/discussion.mdwn @@ -0,0 +1,16 @@ +[[!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]]."]]"""]] + +# Non-cross-compiling + +[[!tag open_issue_mig]] + +[[samuelthibault]] mentioned that I should make clear what compiler options, etc. are only needed if compiling on a 64 bit computer. However, I don't know if the --host=i686... option is needed, here and when making gnumach, in case there may be some other default on 32 bit computers? --[[sudoman]] + diff --git a/microkernel/mach/pmap.mdwn b/microkernel/mach/pmap.mdwn new file mode 100644 index 00000000..6910bfd3 --- /dev/null +++ b/microkernel/mach/pmap.mdwn @@ -0,0 +1,74 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-02-01 + + <sekon> on Hurd what is the difference between kernel memory object and + pmap module ?? + <sekon> pmap is heap/libraries table for each thread while kernel memory + object refers to arbitary blobs of data ?? + <braunr> sekon: pmap is the low level memory mapping module + <braunr> i.e. it programs the mmu + <braunr> and these aren't hurd-specific, they are mach modules + <sekon> braunr: so kernel memonry objects consists of a bunch of pmaps ?? + <braunr> sekon: memory objects can be various things, be specific please + <braunr> (they're certainly not a bunch of pmaps though, no) + <braunr> there is one pmap per vm_map, and there is one vm_map per task + <braunr> and there is no need for double question marks, is ther ?? + <sekon> lol then is kernel memory object , please excuse the metaphor + something like a base class for pmap + <braunr> i don't know what a "kernel memory object" is, be specific please, + again + <sekon> braunr: + http://courses.cs.vt.edu/~cs5204/fall05-gback/presentations/MachOS_Rajesh.ppt + <sekon> goto page titled External Memory Management (EMM) on page 15 + <sekon> Kernel memory object shows up + <braunr> you know there are other formats for this document + <sekon> nope .. i did not know that + <sekon> in page 17 pmamp shows up + <braunr> "the problems of external memory management" ? + <sekon> braunr: the paper i am also reading is called x15mach_thesis + <braunr> ah, that's mine + * sekon bows + <sekon> :) + <braunr> ok i see page 17 + <sekon> so please good sir explain the relationship between kernel memory + object and pmap + <sekon> (if any) + <sekon> braunr: there is no mention of kernel memory object + <braunr> again, i don't see any reference or definition of "kernel memory + object" + <sekon> but your paper says + <sekon> that when page faults occur + <sekon> the kernel contact the manager for a kernel reference object + <sekon> *memory + <braunr> where ? + <sekon> in section 2.1.3 (unless i read it wrong) + <sekon> no just a sec + <sekon> 2.1.5 + <braunr> i never used the expression "kernel memory object" there :p + <braunr> anyway, you're referring simple to memory objects as seen by + userspace pagers + <braunr> a memory object is a data container + <braunr> usually, it's a file + <braunr> but it can be anything + <braunr> the pager is the task that provides its content and implements the + object methods + <braunr> as for the relation between them and the pmap module, it's a + distant one + <braunr> i'll explain it with an example + <braunr> page fault -> request content of memory object at a given offset + with given length from pager -> ask pmap to establish the mapping in the + mmu + <sekon> braunr: thank you ver much + <sekon> *very diff --git a/microkernel/mach/port.mdwn b/microkernel/mach/port.mdwn index af4a0c8d..26b55456 100644 --- a/microkernel/mach/port.mdwn +++ b/microkernel/mach/port.mdwn @@ -1,41 +1,89 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 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 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]]."]]"""]] - -Mach ports are [[capabilities|capability]]. - -A Mach port is a kernel queue. Each port has associated with -it a receive right and one or more send and send-once rights. -A queue can hold a number of messages. Once the queue is full, -the send blocks until their is space to enqueue the message -(this is interruptible via a timeout mechanism). - -A receive right designates a queue and authorizes the holder to -dequeue messages from the queue, and to create send and send-once -rights. - -Send and send-once rights designate a queue and authorize the -hold to enqueue messages (in the case of a send-once right, -a single message). Enqueuing a message is equivalent to -[[invoke|invoking]] a capability. - -Send and receive rights are named using local names. Each -task has associated with it a port [[address_space]]. A ports -are addressed via this table. Each task thus has its own -private [[naming_context]] for ports. - -Ports can be [[delegate]]d in an [[IPC]] message. When the -receiver dequeues the message, the right is made available -to it. - -A [[thread]] can only block receiving on a single port. To work -around this, the concept of a port set was introduced. A receive -right can be added to (at most) one port set. When a thread -receives from a port set, it dequeues from any of the ports that -has a message available. +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[Mach]] *port*s are [[capabilities|capability]], and are also essentially +similar to [[UNIX]] pipes. They are unforgeable communication channels, +implemented by kernel queues. + +Each port has associated with it one *receive right* and one or more *send +right*s and *send-once right*s. That is, there is one receiver and one or more +senders -- a unidirectional communication channel. Only with the corresponding +port right, access to a port is possible; this is enforced by Mach. + +The kernel queue can hold a number of [[message]]s. Once the queue is full, +the send blocks until there is space to enqueue the message (this is +interruptible via a timeout mechanism). + +A receive right [[designates|designation]] a queue and authorizes the holder to +dequeue messages from the queue, and to create send and send-once rights. + +Send and send-once rights designate a queue and authorize the hold to enqueue +messages (in the case of a send-once right, a single message). Enqueuing a +message is equivalent to [[invoke|invoking]] a capability. + +Ports are automatically destroyed when there is no associated port right to +them. + +Mach knows what port rights belong to each task, but [[thread]]s that running +in the context of a task refer to ports by means of send and receive rights +that are named using local *port names*. These port names are plain integers, +like [[UNIX file descriptors|unix/file_descriptor]]. Only these local names +can be used by [[thread]]s for invoking operations on ports, threads do not +deal with port rights directly. + +For that, each task has associated with it a *port address space*, or *port +name space*. All ports are addressed via this table. Each task thus has its +own private [[naming_context]] for port rights. + +So, the picture is that after obtaining a port send right, the client uses a +port name to send [[message]]s to the port, or exactly one message if it's a +send-once right. These messages are (probably) queued and when the server task +tries to receive messages by having a [[thread]] use its port receive right, it +gets the message(s). This is called [[IPC]]. + +Port rights themselves can be [[delegate]]d in a [[message]], too. When the +receiver dequeues the message, the right is made available to it. + +The delivery of [[message]]s is reliable and strictly ordered. When a +[[thread]] sends messages *1* and *2*, it is guaranteed that the receiving +[[task]] will catch them in the same order. Of course, there can be +intermediate messages that are sent by other threads. + +Ports are objects that are implemented by the [[kernel]], and they are +kernel-protected resources: they are unforgeable, and there is no way for a +[[task]] to do anything with a port unless it have corresponding port right. + +Due to this, ports are globally unique. This makes them ideal for constituting +system-wide *object references*. (Fruther reading: +{{$capability#wikipedia_object-capability_model}}.) For example, the [[RPC]] +system as used by the GNU Hurd works by invoking *methods* on such object +references. The available methods are defined in [[hurd/interface]] files, and +are processes by the [[MIG]] tool. + +Invoking an operation on a port does not transfer the current execution control +to the receiver, but instead is an asynchronous operation. For this, and +especially in a [[RPC]] system, the sender may include a *reply port* using a +send-once right, and synchronize (block) on that one. + + +# Port Set + +A [[thread]] can only block receiving on a single port. To work around this, +the concept of a *port set* was introduced. A receive right can be added to +(at most) one port set. These port sets look like port receive rights, but +cannot be passed to other tasks, and there are additional operations for adding +and removing port receive rights. + +When a server process' thread receives from a port set, it dequeues exactly one +message from any of the ports that has a message available in its queue. + +This concept of port sets is also the facility that makes convenient +implementation of [[UNIX]]'s `select` [[system_call]] possible. diff --git a/microkernel/mach/rpc.mdwn b/microkernel/mach/rpc.mdwn index 72acfaa0..422e0441 100644 --- a/microkernel/mach/rpc.mdwn +++ b/microkernel/mach/rpc.mdwn @@ -1,15 +1,28 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[General_information|/rpc]] about RPC. +Read about the [[general concept of a *remote procedure call* (RPC)|/rpc]]. Uses Mach's [[IPC]] [[mechanism]]. -Stub code generated by [[MIG]]. +The [[port]] abstraction allows RPCs to be executed on another computer +transparently. This can be implemented with user [[task]]s, but there is an +implementation in the kernel possible, too, which is called *NORMA*, but is not +avilable in [[GNU Mach|gnumach]]. + +The RPC stub code generated by [[MIG]]. + + +# Tracing + + * [[hurd/debugging/rpctrace]] + + * [[open_issues/librpci]] diff --git a/microkernel/mach/rpc/discussion.mdwn b/microkernel/mach/rpc/discussion.mdwn new file mode 100644 index 00000000..00e4a012 --- /dev/null +++ b/microkernel/mach/rpc/discussion.mdwn @@ -0,0 +1,117 @@ +[[!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-06-11 + + <antrik> I don't think we have a precendence case of Mach initiating RPCs + to userspace tasks + <braunr> well mach regularly sends RPCs to external pagers + <antrik> hm, right + <antrik> anyways, the ds_ in device.defs is for use *inside* Mach, not for + the userspace interface + <braunr> what makes you think so ? + <antrik> several things + <antrik> not least the fact that without zhengda's modifications, the + device handling never calls out to userspace for all I know + <braunr> hm, it does + <braunr> for async I/O + <braunr> when the kernel has finished its I/O, it calls + ds_device_read_reply/ds_device_write_reply + <antrik> I see + <antrik> I never quite understood the _reply stuff + <braunr> although i wonder how mig is supposed to forge those names + <antrik> braunr: it isn't + <antrik> braunr: there is a separate device_reply.defs + <antrik> braunr: and it sets a *userprefix* of ds_ + <antrik> rather than a serverprefix + <braunr> i saw, yes + <braunr> ah right + <antrik> so ds still refers to the in-Mach device server, not anything + userspace + <braunr> so this is where the patch is supposed to introduce the + device_intr_notify RPC + <antrik> or at least that's my understanding... + <braunr> no, it doesn't refer to in-mach servers + <braunr> it really forges the right rpcs to be called by mach + <antrik> the definition of "RPC" is rather unclear here + <braunr> why ? + <braunr> mach has its own mach_msg() call for kernel-to-user messaging + <antrik> yes, but this is used only to send the reply message for the RPC + earlier initiated by userspace AIUI + <antrik> it doesn't look like there is any special RPC for async I/O + <braunr> yes, because this is the only use case they had + <braunr> hence the name "reply" + <braunr> intr_notify isn't a reply, but it uses the same mechanism + <braunr> these are declared as simpleroutine + <antrik> sure. but the fact that it isn't a reply message, but rather + initiates a new RPC, changes things from MiG point of view I believe + <antrik> right, as there is no reply to the reply :-) + <braunr> :) + <braunr> a simpleroutine is how to turn an rpc into a simple ipc + <antrik> I know + <antrik> so in _reply, we pretend that the reply is actually a new RPC, + with server and client roles reversed, and no reply + <antrik> (this is actually rather kludgy... apparently MIG has no real + notion of async replies) + <braunr> i don't understand what you mean + <braunr> simpleroutine is the explicit solution for async replies + <braunr> as stated in + http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps + <braunr> it's not a new rpc with roles reversed + <braunr> it's not a reply either + <antrik> it might be an explicit solution for that, but it still seems + kludgy :-) + <braunr> i don't see why :/ + <braunr> would you have expected something like an option to create both + sync and async versions ? + <antrik> because it requires an extra .defs file + <antrik> yes + <braunr> ok + <braunr> well this seems cumbersome to me :) + <braunr> i prefer the simpleroutine approach + <braunr> but i agree this seems odd since mach has a high level ipc api + <antrik> anyways, my point is that the ds_ in device_reply.defs still + refers to the Mach side of things + <braunr> npnth: which package fails to build ? + <antrik> though a userspace process that actually handles the replies in an + async fashion will of course need some kind of device server too, just + like the DDE stuff... + <antrik> though naming it ds_ is confusing IMHO, because of the name clash + with the device server in Mach + <braunr> hm again, i fail to see why + <braunr> ds_ just means device_server + <braunr> and as most things in mach, it can be in kernel or not + <braunr> i mean, this is an interface prefix, i don't refer to an actual + single instance of a "device server" out there + <antrik> oh, right... DDE implements the Mach device protocol, so it *does* + do the ds_ part... but that makes the interrupt notification stuff even + more confusing + <braunr> hm + <braunr> because it provides a ds_device_intr_notify() which will never be + used, just to completely implement the interface ? + <antrik> yeah, that's what I suspect... + <braunr> sounds likely + <antrik> the device interface actually has two parts: one for "generic" + RPCs on the master device port, and one for device-specific RPCs. DDE + implements the latter, and uses the former... + <antrik> they live in separate places though I think: the individual device + RPCs are implemented in libmachdev, while the intr_ stuff is used in + libddekit probably + <braunr> it would be hairy to build otherwise + <antrik> so we *really* need to know what component npnth gets the error + with + <antrik> braunr: nah, not really. that's why we always have a separate + prefix for the server routines in Hurd RPCs + <braunr> right, i really need to read about mig again + <antrik> it's pretty normal for a translator to both implement and use an + interface diff --git a/microkernel/mach/task.mdwn b/microkernel/mach/task.mdwn new file mode 100644 index 00000000..c03c6a14 --- /dev/null +++ b/microkernel/mach/task.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +A Mach *task* is a collection of resources, a [[virtual_address_space]], and a +[[port name space|port]]. They depend on [[thread]]s for executing program +code: a task alone has no means to do so. + +Switching from one task to another one involves doing a *context switch*, which +is usually not a cheap operation, as it involves switching the hardware's idea +of the memory layout ([[virtual_address_space]]), amongst others. + +Mach tasks are distinct from [[UNIX processes|unix/process]] in that they +provide less facilities. In processes, there are [[unix/signal]]s, process / +group / session IDs, [[unix/file_descriptor]]s and many other things. Tasks +are used for resource allocation and sharing; they are *resource container*s. diff --git a/microkernel/mach/thread.mdwn b/microkernel/mach/thread.mdwn new file mode 100644 index 00000000..e27bb117 --- /dev/null +++ b/microkernel/mach/thread.mdwn @@ -0,0 +1,37 @@ +[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +A Mach *thread* belongs to exactly one [[task]], and is the means of execution. +The task supplies the resources. + +Mach threads are implemented inside the [[kernel]], as opposed to other +systems' user-level thread packages. + +A thread (theoretically) runs concurrently with all the other threads of a +system. If the system provides several processors, they can be used for +simultaneously running either several threads of the same task, or several +threads of different tasks. <!-- This is called SMP; the processors use +*shared memory*. --> [[!tag open_issue_documentation]] <!-- This needs a new +page, also covering Mach's `processor_set`s, and non-SMP, but still +multiprocessor systems. --> (But this is currently not support in [[GNU +Mach|gnumach]].) + +It is easy for the kernel to switch execution from one thread to another one +inside the same task: essentially, it only involves exchanging a few processor +registers' state. + +Threads have scheduling parameters and maintain various statistics about +themselves. + +On GNU/Hurd, APIs for Mach threads and thereabouts are provided by the +[[hurd/libthreads]] (cthreads), and [[libpthread]] (POSIX Threads) packages. + +A task backing a thread is the basis for a [[UNIX process|unix/process]]. diff --git a/microkernel/mach/virtual_address_space.mdwn b/microkernel/mach/virtual_address_space.mdwn new file mode 100644 index 00000000..97bc5f6b --- /dev/null +++ b/microkernel/mach/virtual_address_space.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +*Virtual address space*s in Mach define the valid virtual addresses that can be +used by [[thread]]s under execution in the [[task]] that owns that address +space. Each task has only one address space and each address space belongs to +only one task. So when we want to name an address space (for example, in the +Mach API) we name it by the task it belongs to. + +These address spaces are divided into *pages*. Each page has individual +properties like *access rights* (*read* / *write* / *execute*), *inheritance +attributes* (*no inheritance* / *copy* / *share*) and some other system +properties. Page manipulation is optimized to help moving large blocks of data +from one address space to another, for example when one thread provides data to +another thread -- *client / server* technology. + +Memory ranges of pages that can be controlled as a whole are called +*[[memory_object]]*s. + +*Wired pages* are those that cannot be [[paged out|external_pager_mechanism]]. +For example, Mach itself is a task with its own address space and threads, and +all of its pages are wired. + +*Precious pages* are those that must not be discarded silently when they are +clean and memory is needed. For example, a memory manager that shares memory +across a network could not restore a page if it is silently discarded because +it is unmodified. This is not valid for the well-known [[pager +managers|external_pager_mechanism]] that use disks as backing store. diff --git a/microkernel/viengoos.mdwn b/microkernel/viengoos.mdwn index d4edc929..66c6ff36 100644 --- a/microkernel/viengoos.mdwn +++ b/microkernel/viengoos.mdwn @@ -1,15 +1,26 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -*viengoos* is a new kernel currently being designed and written by Neal -Walfield. +*Viengoos* is a research kernel, designed and written by Neal Walfield. + +As of late 2009, the project is on hold, due to time constraints. + +Viengoos is not really meant to be a successor to [[Mach]]. It is highly +experimental; some of the techniques it employs, in particular, those related +to [[memory_management]] and [[IPC]], are unproven. These were motivated by +[[shortcomings_in_Mach|hurd/critique]] as well as current operating systems. A +research system is unlikely the best base for a product. A better approach is +to view Viengoos as an experimental platform whose goal is to explore solutions +to some of the [[issues_uncovered_by_the_Hurd|challenges]]. Knowledge gained +can then be integrated into something like [[Mach]]. The source can be downloaded from the *viengoos.git* repository, cf. <http://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git>. You can @@ -24,6 +35,8 @@ Then update to viengoos-on-bare-metal viengoos-on-bare-metal is the current development focus. +Discussion should be held on the [[mailing lists/l4-hurd]] mailing list. + * [[Building]] * Running * [[QEMU]] diff --git a/microkernel/viengoos/documentation.mdwn b/microkernel/viengoos/documentation.mdwn index 52ff7a48..edcc79a7 100644 --- a/microkernel/viengoos/documentation.mdwn +++ b/microkernel/viengoos/documentation.mdwn @@ -1,12 +1,12 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2012 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] The most up-to-date documentation is in the source code itself, see in particular the header files in the hurd directory. @@ -17,7 +17,8 @@ version of that is available [[here|reference-guide.pdf]]. It is not, however, automatically regenerated, and thus may not be up to date. -Academic Papers: + +# Academic Papers * [Viengoos: A Framework for Stakeholder-Directed Resource Allocation](http://walfield.org/papers/2009-walfield-viengoos-a-framework-for-stakeholder-directed-resource-allocation.pdf). @@ -54,3 +55,8 @@ Academic Papers: argue that only a small static number of scheduling policies are needed in practice and advocate hierarchical policy specification and central realization. + + +# Miscellaneous + + * [[IRC_2012-02-23]] diff --git a/microkernel/viengoos/documentation/irc_2012-02-23.mdwn b/microkernel/viengoos/documentation/irc_2012-02-23.mdwn new file mode 100644 index 00000000..a3229be9 --- /dev/null +++ b/microkernel/viengoos/documentation/irc_2012-02-23.mdwn @@ -0,0 +1,159 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="IRC, freenode, #hurd, 2012-02-23"]] + +[[!tag open_issue_documentation open_issue_viengoos]] + + <braunr> neal: i've read a bit about current modern microkernel based + systems, and i'm wondering + <braunr> neal: can a capability be used for both request and replies, or + does messaging need something similar to reply ports ? + <neal> braunr: you want a reply port + <neal> think about a file server: + <neal> the file server publishes a capability to access something + <neal> and multiple entities use it + <neal> if you wanted just bidirectional caps + <braunr> that's the idea i had in mind, i just wondered if it was actually + still the case in practice + <neal> you'd need to create a new capability every time you delegated the + cap + <braunr> yes + <braunr> thanks + <braunr> what about send once rights ? + <neal> also, if you send on a cap and then start waiting on it you could + get your own reply :) + <neal> you can get around send-once rights by using a counter + <braunr> no i mean, is their behaviour still needed/useful ? + <neal> the counter is kernel implemented + <neal> yes + <neal> as an optimization + <braunr> so they're just a special case of capability + <neal> yes + <braunr> not a special capability type of their own + <neal> but they eliminate the constant create/destroy sequence + <braunr> (even if it was already the case at the implementation level in + mach, they were named separately which could confuse people) + <braunr> hm + <braunr> actually, send once rights were used for important notifications + such as dead port notifications + <braunr> is this still handled at the kernel level in modern ukernels ? + <neal> in viengoos, this is called the version field + <neal> see chapter 2 + <neal> + http://www.gnu.org/software/hurd/microkernel/viengoos/documentation/reference-guide.pdf + <braunr> neal: btw, congratulations for viengoos, it really is a very + interesting project: ) + <neal> thanks + <braunr> i don't see the point of rewriting a mach clone after reading + about it eh + <neal> I would definately do the messenger concept again + <neal> but I'd not do persistence + <braunr> i don't fully understand how messengers deal with blocking + <neal> did you read chapter 4? + <braunr> i read all of it but didn't understand everything :) + <braunr> it's quite abstract and i didn't make time to read some of the + source code + <neal> If you have specific questions, I can try to help + <braunr> i'll read those chapter again and formulate my questions after + <neal> I may have to read them as well :) + <braunr> i don't understand how you manage to separate IPC from threading + actually + <braunr> are messengers queues ? + <neal> messengers are super-buffers + <neal> they contain a reference to a thread object + <neal> to send a message, I use a messenger + <neal> I put the data in a buffer + <neal> and then I attach the messenger to the target messenger + <antrik> braunr: my stance is that we should try to incorporate the ideas + from Viengoos into Mach in an evolutionary process... + <neal> this causes an activation to be sent to the target messenger's + thread object + <braunr> neal: which activation ? + <neal> an activation is like a CPU interrupt + <braunr> neal: is it "allocated" at that moment, or taken from the sending + thread ? + <braunr> (i'm not sure my question really makes sense to you :/) + <antrik> braunr: not sure what you are asking exactly; but the basic idea + is that the receiving process preallocates message buffers + <braunr> antrik: maybe, i'm not sure + <antrik> when someone sends a message, it's stored in one of these buffers, + and the process gets a scheduler activation, so it can decide what to do + with it + <neal> antrik is right + <neal> the traget messenger designates a memory buffer + <braunr> i'm wondering about the details of this activation + <braunr> is it similar to thread migration ? + <neal> just before the activation, the data is copied to the messenger's + buffer + <neal> now someone needs to be notified + <neal> (that a message arrived) + <neal> that someone is the thread designated in the target messenger's + thread field + <neal> this is done by an activation + <neal> an activation is just an upcall + <neal> a thread is forced to a particular IP + <neal> an activation isn't a "what" it's a "how" + <neal> I never understood thread migration + <neal> as it's not really about threads + <neal> nor it is about migration + <antrik> neal: what happens if another message comes in before the + activation handling tread is done with the previous one?... + <neal> the messenger is enqueued on the thread object + <neal> it is delivered when the thread is in normal mode + <neal> part of delivering an activation is putting the thread is activation + mode + <neal> when in activation mode, it can't receive any activations + <braunr> i see + <braunr> but then, when a thread receives an activation, does it handle + several queued messengers at once (not to loose events/messages) ? + <neal> (unless it does a blocking receive on a particular messenger, which + is necessary to support memory allocation in activated mode) + <neal> it handles one at a time + <braunr> ah right + <neal> it can't lose events + <braunr> activations are sent per messengers/events + <neal> well, it can + <neal> but it is possible to prevent this + <braunr> neal: also, is message passing completely atomic ? + <neal> I'm not sure what you mean + <neal> which part + <braunr> well, all parts of a message :) + <braunr> in mach, a message can contain several parts + <braunr> data, rights, passing one of them may fail + <braunr> only the header is atomically processed + <neal> it's not atomic in the sense that a thread can observe the data copy + <braunr> that's not what i meant + <braunr> is a message completely transferred or not at all in case of + failure ? + <neal> it may be partially transferred + <braunr> or can it be partially transferred + <braunr> ok + <neal> for instance, if the target thread doesn't provide a memory buffer + <neal> then the data can't be copied + <neal> I don't recall off hand how I dealt with bad addresses + <neal> may be it is not possible + <neal> I don't remember + <neal> sorry + <braunr> but if i read the message structure correctly, there can be one + data block, and several capability addresses in a single message, right ? + <neal> yes + <braunr> ok + <braunr> have you considered passing only one object (either data or + capability) per message ? + <braunr> or is it too inefficient ? + <neal> you at least need a reply port + <neal> s/port/messenger/ + <braunr> yes but can't it be passed separately ? + <neal> then you have server state + <neal> ik + <braunr> hm yes + <braunr> thanks for your answers: ) + <neal> no problem diff --git a/microkernel/viengoos/projects.mdwn b/microkernel/viengoos/projects.mdwn index 27dcc3e2..971206bb 100644 --- a/microkernel/viengoos/projects.mdwn +++ b/microkernel/viengoos/projects.mdwn @@ -8,58 +8,10 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!tag open_issue_viengoos]] - Some projects: -# Minor - -## New hash function - -The current hash function in libhurd-ihash results in a lot of -collisions when the hash table is 80% full. To overcome this, we keep -hash tables at most 30% full. This represents a fair amount of -overhead. Find a better algorithm. There can either be one that is -appropriate in the general case or one that works well in a relevant, -specific case, e.g., viengoos/object.c uses a hash to find the object -corresponding to a frame, which is keyed on its physical address. - -# Major - -## Address Space Management - -In Viengoos, a process's address space is managed entirely in user -space by the process itself. This creates two interesting problems: -dealing with circular dependencies resulting from having to manage the -address space data structures and accessing and manipulating the -address space data structures. - -First, managing the address space requires resources, which in turn -may require address space (e.g., data structures require memory which -require address space, etc.). We currently break this circular -dependency by trying to keep enough resources in reserve that -allocating resources for managing the address space never requires -more resources than are minimally in the reserve. The reserve is -currently chosen in an ad-hoc fashion. It would be nice to determine -it more systematically. Moreover, it would be nice to reduce the -cases in which a reserve is required. This may be possible by -restructuring some of the code. - -Second, the address space data structures are protected using a single -lock. This not only means that only a single thread can be updating -the address space at a time, but that if a thread faults and the -address space is locked, then the process dead locks! It should be -possible to at least walk the address space using lock-free -techniques. This requires updating the address space construction -code such that all addresses remain valid during any given -manipulation. Second, to avoid the mentioned dead-lock problem, we -try to ensure that accessing the data structures will never result in -a fault. This means protecting the stack. An alternative approach is -to use undo buffers. - -# Thesis - -## Capability aware compiler - -Modify, e.g., gcc to understand capability semantics and teach gcc how -to optimize it, e.g., how to batch and combine calls. +[[!inline +pages="microkernel/viengoos/projects/* and !microkernel/viengoos/projects/*/*" +show=0 +feeds=no +actions=yes]] diff --git a/microkernel/viengoos/projects/address_space_management.mdwn b/microkernel/viengoos/projects/address_space_management.mdwn new file mode 100644 index 00000000..2d00e4f4 --- /dev/null +++ b/microkernel/viengoos/projects/address_space_management.mdwn @@ -0,0 +1,40 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_viengoos]] + +In Viengoos, a process's address space is managed entirely in user +space by the process itself. This creates two interesting problems: +dealing with circular dependencies resulting from having to manage the +address space data structures and accessing and manipulating the +address space data structures. + +First, managing the address space requires resources, which in turn +may require address space (e.g., data structures require memory which +require address space, etc.). We currently break this circular +dependency by trying to keep enough resources in reserve that +allocating resources for managing the address space never requires +more resources than are minimally in the reserve. The reserve is +currently chosen in an ad-hoc fashion. It would be nice to determine +it more systematically. Moreover, it would be nice to reduce the +cases in which a reserve is required. This may be possible by +restructuring some of the code. + +Second, the address space data structures are protected using a single +lock. This not only means that only a single thread can be updating +the address space at a time, but that if a thread faults and the +address space is locked, then the process dead locks! It should be +possible to at least walk the address space using lock-free +techniques. This requires updating the address space construction +code such that all addresses remain valid during any given +manipulation. Second, to avoid the mentioned dead-lock problem, we +try to ensure that accessing the data structures will never result in +a fault. This means protecting the stack. An alternative approach is +to use undo buffers. diff --git a/microkernel/viengoos/projects/capability-aware_compiler.mdwn b/microkernel/viengoos/projects/capability-aware_compiler.mdwn new file mode 100644 index 00000000..b4e465d9 --- /dev/null +++ b/microkernel/viengoos/projects/capability-aware_compiler.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU Free Documentation License|/fdl]]."]]"""]] + +[[!tag open_issue_viengoos]] + +Modify, e.g., gcc to understand capability semantics and teach gcc how +to optimize it, e.g., how to batch and combine calls. + +This project is deemed suitable for a thesis. diff --git a/microkernel/viengoos/projects/new_hash_function.mdwn b/microkernel/viengoos/projects/new_hash_function.mdwn new file mode 100644 index 00000000..d0374720 --- /dev/null +++ b/microkernel/viengoos/projects/new_hash_function.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_viengoos]] + +The current hash function in libhurd-ihash results in a lot of +collisions when the hash table is 80% full. To overcome this, we keep +hash tables at most 30% full. This represents a fair amount of +overhead. Find a better algorithm. There can either be one that is +appropriate in the general case or one that works well in a relevant, +specific case, e.g., viengoos/object.c uses a hash to find the object +corresponding to a frame, which is keyed on its physical address. + +Note that this applies to the Hurd's [[hurd/libihash]], too. diff --git a/naming_context.mdwn b/naming_context.mdwn index 3a0751c0..2968b0a5 100644 --- a/naming_context.mdwn +++ b/naming_context.mdwn @@ -1,18 +1,22 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Names are bindings to objects, however, to find an object given a name, the relation must be looked up in a -naming context. A problem with using string as names is +*naming context*. + +A problem with using strings as names is that it is very easy to lose track of the correct naming -context. This is one of the problem with [[PassiveTranslators]]: +context. This is one of the problem with [[passive +translators|hurd/translator]]: a passive translator is a string. When the node is accessed on which the passive translator is set and there is no active translator, then an active translator is started using the @@ -22,3 +26,6 @@ passive translator. The passive translator settings are therefore resolved in the file system's naming context, which may be different from that of the program instance that set the passive translator setting. + +[[!tag open_issue_hurd open_issue_documentation]] <!-- Move the description of +the specific problem / example elsewhere. --> @@ -1,17 +1,18 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag stable_URL]] [[!inline pages="news/* and !*/discussion" show=0 feeds=no -sort=title -reverse=yes +template=newsitem actions=yes]] diff --git a/news/2002-01-13.mdwn b/news/2002-01-13.mdwn index 920c2593..684fed13 100644 --- a/news/2002-01-13.mdwn +++ b/news/2002-01-13.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-01-13"]] An <A HREF="http://www.pl-berichte.de/berichte/brinkmann.html">interview diff --git a/news/2002-01-19.mdwn b/news/2002-01-19.mdwn index c6923220..5adbfc60 100644 --- a/news/2002-01-19.mdwn +++ b/news/2002-01-19.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-01-19"]] The Toronto Hurd User Group meets: The University of Waterloo Computer Science Club will be hosting a talk on the Hurd and the diff --git a/news/2002-02-18.mdwn b/news/2002-02-18.mdwn index e550a8f6..a01bd857 100644 --- a/news/2002-02-18.mdwn +++ b/news/2002-02-18.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-02-18"]] Pro-Linux has published a <A HREF="http://www.pl-berichte.de/berichte/hurd/hurd-status/">GNU/Hurd diff --git a/news/2002-03-03.mdwn b/news/2002-03-03.mdwn index 8b60ed9b..6f88208b 100644 --- a/news/2002-03-03.mdwn +++ b/news/2002-03-03.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-03-03"]] There is a new mailing list called <A HREF="http://mail.gnu.org/mailman/listinfo/hurd-devel-readers"> diff --git a/news/2002-03-08.mdwn b/news/2002-03-08.mdwn index f64f04f1..aa3d6e8c 100644 --- a/news/2002-03-08.mdwn +++ b/news/2002-03-08.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-03-08"]] We are pleased to announce version 1.3 of the GNU distribution of the Mach 3.0 interface generator `MIG'. It may be found in the file diff --git a/news/2002-03-23.mdwn b/news/2002-03-23.mdwn index f3c12633..68180ba8 100644 --- a/news/2002-03-23.mdwn +++ b/news/2002-03-23.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-03-23"]] Added the [[hurd/Hurd_Hacking_Guide]] to the documentation section. Thanks to Wolfgang Jährling for providing this introduction into GNU/Hurd and Mach diff --git a/news/2002-05-05.mdwn b/news/2002-05-05.mdwn index 2b38863e..0908b78f 100644 --- a/news/2002-05-05.mdwn +++ b/news/2002-05-05.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-05-05"]] We are currently finishing the transition from a stdio-based GNU C Library (glibc) to a libio-based one. This is the result of about diff --git a/news/2002-05-18.mdwn b/news/2002-05-18.mdwn index 7017e410..10104a5e 100644 --- a/news/2002-05-18.mdwn +++ b/news/2002-05-18.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-05-18"]] The "Linux and Unix User Group Heilbronn" (in Germany) is organizing a Debian GNU/Hurd <A diff --git a/news/2002-05-24.mdwn b/news/2002-05-24.mdwn index a65d5c6d..57c7549f 100644 --- a/news/2002-05-24.mdwn +++ b/news/2002-05-24.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-05-24"]] Finally, the transition from the stdio-based GLibC Application Binary Interface (ABI) to the libio-based GLibC ABI has been diff --git a/news/2002-05-28.mdwn b/news/2002-05-28.mdwn index dcf7c86d..5cfe129b 100644 --- a/news/2002-05-28.mdwn +++ b/news/2002-05-28.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-05-28"]] We are pleased to announce version 1.3 of the GNU distribution of the Mach kernel, featuring advanced boot script support, support for diff --git a/news/2002-06-22.mdwn b/news/2002-06-22.mdwn index b6a606da..3bb316b3 100644 --- a/news/2002-06-22.mdwn +++ b/news/2002-06-22.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-06-22"]] Various developers of the Hurd and people interested in it will meet at the <A HREF="http://lsm.abul.org/">Libre Software Meeting</A> in diff --git a/news/2002-08-16.mdwn b/news/2002-08-16.mdwn index 9e70d686..9814295f 100644 --- a/news/2002-08-16.mdwn +++ b/news/2002-08-16.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-08-16"]] The Hurd sources have stabilized again after a short period in which some of the interfaces were changed to prepare support of long diff --git a/news/2002-10-03.mdwn b/news/2002-10-03.mdwn index 90f4da9f..5e25a55b 100644 --- a/news/2002-10-03.mdwn +++ b/news/2002-10-03.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-10-03"]] A new article about [[the_authentication_server|hurd/documentation/auth]] has been added to the web pages. It resembles the talk diff --git a/news/2002-10-03_2.mdwn b/news/2002-10-03_2.mdwn index e08e2b3c..281d24c8 100644 --- a/news/2002-10-03_2.mdwn +++ b/news/2002-10-03_2.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-10-03"]] Marcus Brinkmann speaks about the GNU Hurd at "Reflections | Projections 2002", the <A diff --git a/news/2002-10-19.mdwn b/news/2002-10-19.mdwn index 0d3f34a0..9153fb41 100644 --- a/news/2002-10-19.mdwn +++ b/news/2002-10-19.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-10-19"]] The Toronto Hurd Users Group meets again: The <A HREF="http://www.uwaterloo.ca/"> University of Waterloo</A> <A diff --git a/news/2002-11-18.mdwn b/news/2002-11-18.mdwn index 805f2726..9db912a1 100644 --- a/news/2002-11-18.mdwn +++ b/news/2002-11-18.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2002-11-18"]] For one month now, the pthread implementation by Neal Walfield is part of the Hurd CVS source tree, and has been used to compile more diff --git a/news/2003-01-18.mdwn b/news/2003-01-18.mdwn index 90c41f27..8f342d1d 100644 --- a/news/2003-01-18.mdwn +++ b/news/2003-01-18.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2003-01-18"]] Gaël Le Mignot, president of HurdFr, <A HREF="http://news.hurdfr.org/gen.php3/2002/11/05/44,0,1,0,0.html"> diff --git a/news/2003-02-14.mdwn b/news/2003-02-14.mdwn index 2754d737..4584c525 100644 --- a/news/2003-02-14.mdwn +++ b/news/2003-02-14.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2003-02-14"]] The <A HREF="/software/hurd/docs.html#UsersGuide">GNU/Hurd User's Guide</A> is now accessible through the <A HREF="/software/hurd/docs.html">Documentation diff --git a/news/2003-07-02.mdwn b/news/2003-07-02.mdwn index 7e9634b7..27d9702a 100644 --- a/news/2003-07-02.mdwn +++ b/news/2003-07-02.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2003-07-02"]] The tarball for Debian GNU/Hurd that Marcus Brinkmann made over the years has been discontinued in favour of Jeff Bailey's diff --git a/news/2003-07-16.mdwn b/news/2003-07-16.mdwn index da1fc12a..a37bed26 100644 --- a/news/2003-07-16.mdwn +++ b/news/2003-07-16.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2003-07-16"]] GNU/LinuxTag 2003 is now over and since there was a talk given about the Hurd, a demo GNU/Hurd machine running and the sale of Hurd diff --git a/news/2003-08-21.mdwn b/news/2003-08-21.mdwn index fcd2adb8..1a44c1d2 100644 --- a/news/2003-08-21.mdwn +++ b/news/2003-08-21.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2003, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2003, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2003-08-21"]] Added a link to Patrick Strasser's <A HREF="http://www.htu.tugraz.at/~past/hurd/global/">the Hurd Source diff --git a/news/2005-01-28.mdwn b/news/2005-01-28.mdwn index 3360fd3e..9e54ff60 100644 --- a/news/2005-01-28.mdwn +++ b/news/2005-01-28.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2005, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2005-01-28"]] Marcus Brinkmann added <A HREF="/software/hurd/hurd-l4.html">a small web page</A> describing diff --git a/news/2005-09-20.mdwn b/news/2005-09-20.mdwn index 09e156eb..e2af05d7 100644 --- a/news/2005-09-20.mdwn +++ b/news/2005-09-20.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2005, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2005, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2005-09-20"]] Material from the Operating System topic during the <A HREF="http://libresoftwaremeeting.org/">Libre Software diff --git a/news/2006-04-27.mdwn b/news/2006-04-27.mdwn index 9f99488a..befce295 100644 --- a/news/2006-04-27.mdwn +++ b/news/2006-04-27.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2006, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2006, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2006-04-27"]] <p>The GNU Hurd project will participate in this year's <strong>Google Summer of Code</strong>, under the aegis of the GNU project.</p> diff --git a/news/2007-01-07.mdwn b/news/2007-01-07.mdwn index 530491f2..3b7ed1be 100644 --- a/news/2007-01-07.mdwn +++ b/news/2007-01-07.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2007-01-07"]] A number of GNU Hurd developers will again (as already in the previous years) meet at the time of the FOSDEM 2007, which will take place from 2007-02-24 to diff --git a/news/2007-01-14.mdwn b/news/2007-01-14.mdwn index f99eda87..e33270e4 100644 --- a/news/2007-01-14.mdwn +++ b/news/2007-01-14.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2007-01-14"]] <p>Neal Walfield and Marcus Brinkmann have written and submitted for publication <a diff --git a/news/2007-03-14.mdwn b/news/2007-03-14.mdwn index 9895291c..5b601a35 100644 --- a/news/2007-03-14.mdwn +++ b/news/2007-03-14.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2007-03-14"]] <p>The GNU Hurd project will participate in this year's <strong>Google Summer of Code</strong>, under the aegis of the GNU project.</p> diff --git a/news/2007-10-01.mdwn b/news/2007-10-01.mdwn index b35bc337..0284f3dc 100644 --- a/news/2007-10-01.mdwn +++ b/news/2007-10-01.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2007-10-01"]] This year the GNU Hurd had again been assigned one slot within the **Google Summer of Code** program, which was assigned to the task **design and implement diff --git a/news/2007-10-12.mdwn b/news/2007-10-12.mdwn index ae125149..82ff8843 100644 --- a/news/2007-10-12.mdwn +++ b/news/2007-10-12.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2007-10-12"]] Stefan Siegl added [[support_for_IPv6_networking|hurd/translator/pfinet/ipv6]] to the *pfinet* translator. diff --git a/news/2008-02-11.mdwn b/news/2008-02-11.mdwn index 0805287c..060c0b94 100644 --- a/news/2008-02-11.mdwn +++ b/news/2008-02-11.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2008-02-11"]] A number of GNU Hurd developers will again (as already in the previous years) meet at the time of the FOSDEM 2008, which will take place from diff --git a/news/2008-03-19.mdwn b/news/2008-03-19.mdwn index 02ea4c5f..fbfb4c60 100644 --- a/news/2008-03-19.mdwn +++ b/news/2008-03-19.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2008-03-19"]] The GNU Hurd project has been accepted as a mentoring organisation for the **Google Summer of Code 2008**! If you are a student and looking for a job diff --git a/news/2008-09-11.mdwn b/news/2008-09-11.mdwn index 7d25e5a6..0765a269 100644 --- a/news/2008-09-11.mdwn +++ b/news/2008-09-11.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2008-09-11"]] All five students who worked on the Hurd during the **Google Summer of Code 2008** succeeded in their projects. For more information please see [[the_community/gsoc_page|community/gsoc]]. diff --git a/news/2008-11-14.mdwn b/news/2008-11-14.mdwn index 58e035c3..0d357900 100644 --- a/news/2008-11-14.mdwn +++ b/news/2008-11-14.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2008-11-14"]] [[Samuel_Thibault|samuelthibault]] has implemented support for the PAE feature offered by modern x86 processors. This largely faciliates the deployment of diff --git a/news/2008-12-12.mdwn b/news/2008-12-12.mdwn index b2e92ef0..0bd750b8 100644 --- a/news/2008-12-12.mdwn +++ b/news/2008-12-12.mdwn @@ -1,12 +1,14 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2008-12-12"]] Neal Walfield has submitted a paper to [[community/meetings/EuroSys_2009]] describing how resource management diff --git a/news/2009-03-28.mdwn b/news/2009-03-28.mdwn index 00aebb09..78c40688 100644 --- a/news/2009-03-28.mdwn +++ b/news/2009-03-28.mdwn @@ -1,12 +1,14 @@ -[[!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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2009-03-28"]] The application phase for the **Google Summer of Code 2009** has already started. Please see our [[page_about_the_GSoC|community/gsoc]] for diff --git a/news/2009-04-20.mdwn b/news/2009-04-20.mdwn index 69831cca..3755a7fb 100644 --- a/news/2009-04-20.mdwn +++ b/news/2009-04-20.mdwn @@ -1,12 +1,14 @@ -[[!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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2009-04-20"]] Sergiu Ivanov will be working on [[unionmount_translators|user/scolobb]] during the **Google Summer of Code 2009**. diff --git a/news/2009-06-30.mdwn b/news/2009-06-30.mdwn new file mode 100644 index 00000000..5031de6c --- /dev/null +++ b/news/2009-06-30.mdwn @@ -0,0 +1,31 @@ +[[!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 +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 date="2009-06-30"]] + +A month of the Hurd: *Git migration*, *stand-alone libpthread* and *updated +status*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" +> This month Thomas Schwinge [finished +> migrating](http://lists.gnu.org/archive/html/bug-hurd/2009-06/msg00147.html) +> the main Hurd, GNU Mach, MIG, libpthread and unionfs to Git. You can find +> the new repositories at <http://git.savannah.gnu.org/cgit/hurd/>. + +> Also, he made [libpthread buildable +> stand-alone](http://lists.gnu.org/archive/html/bug-hurd/2009-06/msg00166.html) +> by separating its build system from the Hurd's. + +> Additionally, Olaf Buddenhagen wrote a usability report about his experience +> with the [[GNU Hurd for everyday work|hurd/status]]. +"""]] diff --git a/news/2009-07-31.mdwn b/news/2009-07-31.mdwn new file mode 100644 index 00000000..21f09ae2 --- /dev/null +++ b/news/2009-07-31.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2009 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 date="2009-08-03 08:00 UTC"]] + +A month of the Hurd: *hurd Debian package*, *union mount translator*, *bug +fixes*, and a *job opening*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" +> Samuel Thibault uploaded a new version of the hurd +> [[Debian|hurd/running/debian]] package which improves system stability by +> fixing a long-standing bug in the [[hurd/translator/exec]] server that had +> randomly made it hang, inhibiting the creation of new processes. + +> [[Sergiu Ivanov|scolobb]] implemented most of the functionality of the +> [[union mount translator|hurd/translator/unionmount]] which allows combining +> the [[filesystem trees exported by several translators|hurd/translator]] with +> the filesystem tree of the underlying node (in contrast to a pure +> [[hurd/translator/unionfs]], which won't do that). The patches are currently +> undergoing testing and review on the [[bug-hurd mailing +> list|mailing_lists/bug-hurd]]. This work is being done as a [[Google Summer +> of Code|community/gsoc]] project, and we're happy to tell that Sergiu +> successfully passed the project's midterm evaluation. + +> Also, [[Zheng Da|zhengda]] [[!GNU_Savannah_patch 6851 desc="fixed a bug"]] in GNU Mach's +> [[!wikipedia Berkeley Packet Filter desc="BPF (Berkeley Packet Filter)"]] +> implementation and contributed a number of fixes and +> improvements for [[hurd/debugging/rpctrace]] which should help further debugging. + +> Aside from looking for new [[contributors|contributing]] all the time, +> here is another job opening that doesn't require specific Hurd knowledge: +> we're seeking [someone interested in writing a regression test suite for Hurd +> components](http://lists.gnu.org/archive/html/bug-hurd/2009-07/msg00177.html). +"""]] diff --git a/news/2009-09-30.mdwn b/news/2009-09-30.mdwn new file mode 100644 index 00000000..38f09bfa --- /dev/null +++ b/news/2009-09-30.mdwn @@ -0,0 +1,32 @@ +[[!meta copyright="Copyright © 2009 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 date="2009-10-01 11:52 UTC"]] + +A month of the Hurd: *Successful Google Summer of Code project: unionmount*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" +> This month saw the successful completion of the Google Summer of Code 2009, +> for which [[Sergiu Ivanov|scolobb]] created a +> [[unionmount_translator|hurd/translator/unionmount]]. +> His work allows you to simply union one directory or translator into another one, +> so you see the files of both of them side by side. +> +> He was mentored by Olaf Buddenhagen and both are now working on polishing the code +> and extending the namespace based translator selection ([[hurd/translator/nsmux]]) which allows you to +> read a node with a selected translator by simply appending `,,<translator>` to its name. +> +> That aside, we saw the usual steady rate of enhancement discussions, as well +> as bugs getting fixed: X server crashing, preventing that GCC versions after +> 4.2 optimize too much, etc. +"""]] diff --git a/news/2009-10-31.mdwn b/news/2009-10-31.mdwn new file mode 100644 index 00000000..db3537d0 --- /dev/null +++ b/news/2009-10-31.mdwn @@ -0,0 +1,49 @@ +[[!meta copyright="Copyright © 2009 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 date="2009-11-02 22:39 UTC"]] + +A month of the Hurd: new *installation CDs*, further *Git migration*, +*porting*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" +> This month Philip Charles created a new [installation +> CD](http://ftp.debian-ports.org/debian-cd/current/), the [L +> series](http://ftp.debian-ports.org/debian-cd/current/README-L1-disc-set), +> for the Hurd, which brings us a big step towards installing the Hurd from the +> Hurd (without the need of a Linux-based installer). If you enjoy testing +> stuff, please give it a try. + +> On the same front, Michael Banck uploaded a new version of +> [crosshurd](http://packages.debian.org/sid/crosshurd) that makes it again +> possible to use this package for creating a GNU/Hurd system image directly +> from Debian unstable packages. + +> Also, Thomas Schwinge migrated Sergiu Ivanov's [[hurd/translator/nsmux]], +> [[Flávio Cruz|flaviocruz]]' cl-hurd *(clisp bindings)*, and Carl Fredrik +> Hammar [[hurd/libchannel]] repositories into our new [*incubator* Git +> repository](http://git.savannah.gnu.org/cgit/hurd/incubator.git/), making +> them easier to access for other contributors. + +> Our bunch of porters continued to make further Debian packages usable on +> GNU/Hurd: Pino Toscano worked on a lot of packages, and Wesley W. Terpstra +> made [mlton](http://packages.debian.org/sid/mlton) build -- together with +> Samuel Thibault, who first had to enhance [[GNU +> Mach|microkernel/mach/gnumach]] to support allocating more than 1 GiB of RAM +> to one user-space process, which mlton needs. + +> On the go, Samuel also fixed a number of other bugs here and there, for +> example together with Eric Blake and Roland McGrath hashed out a difficile +> issue in the filesystem servers regarding POSIX conformance and system +> stability. +"""]] diff --git a/news/2009-11-30.mdwn b/news/2009-11-30.mdwn new file mode 100644 index 00000000..86a575bc --- /dev/null +++ b/news/2009-11-30.mdwn @@ -0,0 +1,51 @@ +[[!meta copyright="Copyright © 2009 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 date="2009-12-03 11:00 UTC"]] + +A month of the Hurd: initial work on *network device drivers in user space*, +*GRUB 2*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" +> This month [[Zheng Da|zhengda]], our [[former Google Summer of Code student +> working on network virtualization and some related +> topics|community/gsoc/2008]], published the code for the pcnet32 device +> driver that he had modified to run as a user-space process instead of inside +> the kernel, and posted some preliminary [performance benchmark +> results](http://lists.gnu.org/archive/html/bug-hurd/2009-11/msg00144.html). +> The test results are mostly on par with the in-kernel driver, so they show +> that moving the lower-layer parts of the networking stack, the device drivers +> themselves, into user space can be done without losing (much) performance. +> Given this encouraging start, work is going on to explore whether the [Device +> Driver Environment](http://wiki.tudos.org/DDE/DDEKit) that has been created +> for L4-based systems can be used for [providing GNU/Hurd systems with device +> drivers](http://lists.gnu.org/archive/html/bug-hurd/2009-11/msg00241.html) +> that (a) are more recent than our current ones, (b) support classes of +> devices that [[we don't support so +> far|microkernel/mach/gnumach/hardware_compatibility_list]], and (c) are +> running as (possibly separate, fault-isolated) user-space processes. + +> Thanks to Samuel Thibault, the latest Debian GRUB 2 package (1.97+20091130-1) +> [supports native +> installation](http://lists.debian.org/debian-hurd/2009/11/msg00095.html) from +> GNU/Hurd itself -- booting GNU/Hurd systems with GRUB has always been +> working, but until now it wasn't possible to *install* GRUB from a GNU/Hurd +> system. GNU GRUB has originally been written [for booting GNU/Hurd +> systems](http://www.gnu.org/software/grub/manual/grub.html#History), so this +> step completes its original purpose. + +> Samuel also continued to work on preparing the [[Xen branch of GNU +> Mach|microkernel/mach/gnumach/ports/xen]] for being merged with the mainline +> code, and he fixed a kernel panic in the kernel's floating point +> support code. +"""]] diff --git a/news/2009-12-31.mdwn b/news/2009-12-31.mdwn new file mode 100644 index 00000000..286350d1 --- /dev/null +++ b/news/2009-12-31.mdwn @@ -0,0 +1,85 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2009-12-31 17:33 UTC"]] + +A month of the Hurd: *official Xen domU support*, *DDE*, *porting*, and *FOSDEM 2010*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +> This month Samuel Thibault [merged his development branch into GNU Mach's +> master +> branch](http://lists.gnu.org/archive/html/bug-hurd/2009-12/msg00058.html) -- +> meaning that his [[GNU Mach Xen domU +> port|microkernel/mach/gnumach/ports/xen]] is now part of the official +> sources. Only the [[microkernel (GNU Mach)|microkernel/mach/gnumach]] needed +> to be extended, and no changes were needed in the Hurd, or glibc code bases. +> He had started this port in 2007 already, but it has been in heavy use over +> the last two years already, so merging it into the main source bases was long +> overdue. + +> He also got the necessary Xen patches committed into Xen's unstable branch, +> so that from Xen's 4.0 release on you'll be able to boot GNU/Hurd systems +> using `pv-grub`, without the need to prepare a special bootstrap image (like +> an initrd). + +> Of course, running GNU/Hurd systems in other virtualization environments is +> possible too, but the Xen domU approach offers superior performance compared +> to [[hurd/running/QEMU]]'s machine emulation, for example. + +> Samuel also spent some time on adding code for [detecting invalid (duplicate) +> port +> deallocations](http://lists.gnu.org/archive/html/commit-hurd/2009-12/msg00016.html), +> and started fixing these, as well as he fulfilled his usual share of +> miscellaneous bug fixing. + +> The [[DDE]] port of Zheng Da now [passes the first +> tests](http://lists.gnu.org/archive/html/bug-hurd/2009-12/msg00060.html), +> bringing us the first steps towards updated device drivers -- and much lower +> overhead for maintaining them. + +> Now that the Debian GNU/Hurd build stats are again hosted on the [master +> Debian build machine](https://buildd.debian.org/stats/), Debian developers +> see their packages' build failures more prominently, and quite a few started +> to fix their packages. + +> Thus, thanks to the [[hurd/running/debian/porting]] work of mainly Emilio Pozuelo +> Monfort and Pino Toscano, users of the Hurd can get many more packages +> directly via the [[Debian GNU/Hurd|hurd/running/debian]] distribution. +> Thanks to their and the other porters' relentless work, the percentage of +> available Debian packages [has reached +> 66%](https://buildd.debian.org/stats/hurd-i386.txt), rising. For a specific example, +> they ported many GNOME packages, so that the `gnome-core` metapackage [is +> installable +> again](http://lists.gnu.org/archive/html/bug-hurd/2009-12/msg00217.html). +> Please test these and [[report back|mailing lists/debian-hurd]]. + +> Thomas Schwinge started the planning for [[a GNU Hurd folks meeting at +> FOSDEM|community/meetings/fosdem 2010]] on February 6th/7th 2010 at the +> Université Libre de Bruxelles. + +> Guillem Jover jumped in and started [fixing GNU Mach build +> warnings](http://lists.gnu.org/archive/html/commit-hurd/2009-12/msg00008.html) +> -- meaning that Thomas Schwinge's evil plan finally worked out, when he +> enabled `-Wall` in an October 2006 commit: +> +> +# Yes, this makes the eyes hurt. But perhaps someone will finally take care of +> +# all that scruffy Mach code... Also see <http://savannah.gnu.org/task/?5726>. +> +AM_CFLAGS += \ +> + -Wall + +> --- + +> The GNU Hurd team wishes a pleasant Year 2010 to everyone! + +"""]] diff --git a/news/2010-01-31.mdwn b/news/2010-01-31.mdwn new file mode 100644 index 00000000..306a54b3 --- /dev/null +++ b/news/2010-01-31.mdwn @@ -0,0 +1,58 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2010-02-02 00:25 UTC"]] + +A month of the Hurd: *Arch Hurd*, *FOSDEM preparations* and a *thesis on mobile Hurd objects*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +> This month, we saw the first booting version of an [[hurd/running/Arch Hurd]] +> system, which seconds the [[Debian GNU/Hurd|hurd/running/debian]] +> distribution that already provides two third of the Debian software archive +> compiled for GNU/Hurd. + +> Nine Hurd developers will [[meet at FOSDEM +> 2010|community/meetings/fosdem_2010]] on February 6th and 7th in Bruxelles, +> Belgium. On Sunday, Olaf will be giving two presentations in the Alt-OS +> Developer Room: [*Why is Anyone Still Working on the GNU +> Hurd?*](http://fosdem.org/2010/schedule/events/altos_hurd) (10:30), and +> [*Porting KGI graphics drivers from Linux to GNU +> Hurd*](http://fosdem.org/2010/schedule/events/altos_kgi_hurd) (13:00). The +> day before, on Saturday, Bas will be giving a [talk about *Iris*, his new +> kernel](http://fosdem.org/2010/schedule/events/emb_iris) (18:00, Embedded +> Developer Room). + +> Carl Fredrik Hammar +> [finished and presented](http://lists.gnu.org/archive/html/bug-hurd/2010-01/msg00078.html) +> his thesis +> [*Generalizing mobility for the Hurd*](http://users.student.lth.se/cs07fh9/2009-hammar-hurd-mobility.pdf) +> and passed with distinction. Congratulations! Its abstract reads: + +> > The GNU Hurd features mobile objects +> > in its implementation of filesystem backing stores. +> > This thesis investigates the +> > limitations and security concerns +> > these objects present, +> > and how they can be overcome. +> > This is done in preparation for new applications +> > that feature mobile code and mobile objects. +> > In addition, +> > one such application is studied and implemented, +> > in which mobile code is used to make +> > the `ioctl` system call more extensible. + +> So, when are *YOU* going to do a thesis, or another project on a +> GNU/Hurd-related topic? [[Contact_us]] if you are interested! + +"""]] diff --git a/news/2010-02-28.mdwn b/news/2010-02-28.mdwn new file mode 100644 index 00000000..ee6e22ef --- /dev/null +++ b/news/2010-02-28.mdwn @@ -0,0 +1,72 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2010-03-10 15:55 UTC"]] + +A month of the Hurd: *DDE driver*, *X.org / libpciaccess*, *FOSDEM*, and +*Google Summer of Code 2010*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +> A bit late, but here it is finally: the *MotH* for February, 2010. + +> This month saw the first running and testable +> [[DDE driver by Zheng Da|user/zhengda]], +> with which he begins to reap the benefits of porting [[DDE]] to the Hurd -- +> essentially, allowing us to use current Linux device drivers. + +> Samuel Thibault pushed a [libpciaccess x86 +> backend](http://cgit.freedesktop.org/xorg/lib/libpciaccess/commit/?id=af2be74979aeab9a2fc4c933462e97ce70f816b6) +> to X.Org: + +> > This adds support on x86 for OSes that do not have a PCI interface, +> > tinkering with I/O ports, and makes use of it on GNU/Hurd. + +> In the course of this, he also got commit access to X.org, so it should be +> easier now to get further Hurd-related patches applied. + +> As announced in our [[previous news blurb|2010-01-31]], at FOSDEM, Bas did +> his presentation of [*Iris, a new capability-based microkernel +> OS*](http://fosdem.org/2010/schedule/events/emb_iris) in the Embedded +> Developer Room, and Olaf illustrated [*Why is Anyone Still Working on the GNU +> Hurd?*](http://fosdem.org/2010/schedule/events/altos_hurd), and presented his +> work of [*Porting KGI graphics drivers from Linux to GNU +> Hurd*](http://fosdem.org/2010/schedule/events/altos_kgi_hurd), in the Alt-OS +> Developer Room. + +> In [Mikel Olasagasti's +> words](http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00014.html): + +> > The room was full and people was "standing-up" for the talk. Some people +> > even couldn't enter to the room (+20?). +> > +> > Antrik [Olaf] made a good job. Was nice for the crowd to see Hurd running X, +> > slow but working. + +> The regular IRC meeting schedule has been +> [changed](http://lists.gnu.org/archive/html/bug-hurd/2010-02/msg00040.html) +> to Wednesdays, 11:00 UTC; see the [[IRC#regular_meetings]] page for details. + +> Last, but not least, it is time again to think about the [[Google Summer of +> Code|community/gsoc]]. In [[community/gsoc/2007]], the GNU Hurd had one +> successful project, in [[community/gsoc/2008]] five of them, +> [[community/gsoc/2009]] saw another one, so we obviously plan to make it five +> projects again this year. We already have [[dozens of +> ideas|community/gsoc/project ideas]] online, and will add yet more -- also +> based on YOUR suggestions and wishes! + +> So, if you're a student, and interested in working on the GNU Hurd, please +> join in; browse through the [[community/GSoC]] pages, and don't be shy to +> [[contact us]]! + +"""]] diff --git a/news/2010-03-31.mdwn b/news/2010-03-31.mdwn new file mode 100644 index 00000000..c3c424d1 --- /dev/null +++ b/news/2010-03-31.mdwn @@ -0,0 +1,48 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2010-04-01 07:55 UTC"]] + +A month of the Hurd: some more *bug squashing* and *Google Summer of Code 2010*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +> This month saw bugs dying as they met hackers like [Jérémie, +> Samuel](http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00027.html), or +> [Zheng, +> Thomas](http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00051.html), or +> [Jakub](http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00071.html) +> (keeping it to a few ones which were discussed on the [[bug-hurd mailing +> list|mailing_lists/bug-hurd]]). + +> Olaf, Thomas and Fredrik +> [wrote](http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00022.html) and +> submitted our [[community/gsoc/organization_application]] for the Google +> Summer of Code 2010. However, Google is [asking most GNU projects to work +> under the GNU project +> umbrella](http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00125.html), +> so we aren't listed as an organization on our own, but instead will again +> participate as a subproject of GNU. + +> Anyway, this organizational detail is not at all important for interested +> students; you can apply for any of the ideas that are listed on our +> [[community/gsoc/project_ideas]] page (or come up with your own ideas, of +> course!) via the [GNU project GSoC +> page](http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/gnuproject). If +> you apply, please also include the information we're asking for on our +> [[community/gsoc/student_application_form]]. Don't hesitate to +> [[contact_us]] beforehand, if there are any questions. We're looking forward +> to seeing your applications, please send them in [before +> 2010-04-09](http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline)! + +"""]] diff --git a/news/2010-04-30.mdwn b/news/2010-04-30.mdwn new file mode 100644 index 00000000..0b50122d --- /dev/null +++ b/news/2010-04-30.mdwn @@ -0,0 +1,92 @@ +[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2010-05-02 21:20 UTC"]] + +A month of the Hurd: *Arch Hurd*, *updated Debian GNU/Hurd QEMU image*, and *GSoC students*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +> The Arch Hurd folks keep [making good +> progress](http://lists.gnu.org/archive/html/help-hurd/2010-04/msg00003.html): +> their count of available packages keeps increasing, and one of their team +> reported the first instance of Arch Hurd [running on real +> hardware](http://www.archhurd.org/news/11) (and uploaded [a +> photo](http://wiki.archhurd.org/wiki/User:Giselher#ArchHurd_on_a_real_PC) as +> evidence). + +> Of course, our Debian port is still progressing, too: 66% of all Debian +> packages [are currently available for Debian +> GNU/Hurd](https://buildd.debian.org/stats/hurd-i386.txt). + +> *Samuel Thibault*'s fix got included in libxcb1, so X.org again [works out of +> the box](http://lists.debian.org/debian-hurd/2010/04/msg00034.html) using a +> simple `startx`. + +> *Philip Charles* [extended his +> offerings](http://lists.debian.org/debian-hurd/2010/04/msg00019.html) with an +> updated *GRUB USB stick for booting Debian GNU/Hurd*. + +> *Carl Fredrik Hammar* proposed a patch to [faciliate debugging the startup of +> misbehaving +> translators](http://lists.gnu.org/archive/html/bug-hurd/2010-04/msg00037.html). + +> Mainly thanks to *Jose Luis Alarcon Sanchez*, we now have a [new QEMU +> image](http://lists.debian.org/debian-hurd/2010/04/msg00098.html). It can be +> run with a simple `qemu -m 512 -hda debian-hurd-17042010-qemu.img`. + +> *Thomas Schwinge* updated [our glibc maintenance +> repository](http://git.savannah.gnu.org/cgit/hurd/glibc.git/?h=tschwinge/Roger_Whittaker) +> to a recent version, including a bunch of the patches from the Debian glibc +> package (and these are meant to eventually be submitted upstream). After a +> long break, he as well +> [updated](http://lists.gnu.org/archive/html/bug-hurd/2010-04/msg00062.html) +> his toolchain cross-compilation script [[`cross-gnu`|toolchain/cross-gnu]] +> to +> the current source code packages, and added C++ support. + +> On to the Google Summer of Code 2010: we got three students working on the +> Hurd this year: + +> * *Jérémie Koenig*, mentored by *Samuel Thibault*, will be working on +> adapting the Debian Installer to [produce working Debian GNU/Hurd +> installation +> images](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/debian/t127230758239) +> so we can easily offer up to date disc-sets. +> ([Details](http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig).) + +> * *Emilio Pozuelo Monfort*, mentored by *Carl Fredrik Hammar* (who was a +> GSoC student in 2007), will be working on a task that may be perceived as +> less exciting from the outside, but yet is extremely valuable: [fixing +> compatibility problems exposed by projects' +> testsuites](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759396). +> ([[Details|community/gsoc/project_ideas/testsuites]].) For starters, he +> already got a glibc patch [accepted +> upstream](http://sourceware.org/ml/libc-alpha/2010-04/msg00046.html). + +> * *Karim Allah Ahmed*, mentored by *Sergio López*, will be working on +> [tuning the VM Subsystem in +> GNU/Hurd](http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gnuproject/t127230759587) +> to bring the virtual memory management in Hurd/Mach up to date. +> ([[Details|community/gsoc/project_ideas/vm_tuning]].) + +> We'd be happy to see *YOU* sign up on our mailing lists +> ([[mailing_lists/bug-hurd]] and [[mailing_lists/debian-hurd]] are the main +> lists), and [[contribute|contributing]] towards making the Hurd usable for +> everyone, as written down in +> [[our_mission_statement|community/weblogs/antrik/hurd-mission-statement]]. +> Perhaps one of the unassigned projects (outside of the Google Summer of Code +> context) from our [[project_ideas_list|community/gsoc/project_ideas]] is fit +> for you? + +"""]] diff --git a/news/2010-05-31.mdwn b/news/2010-05-31.mdwn new file mode 100644 index 00000000..5bef328e --- /dev/null +++ b/news/2010-05-31.mdwn @@ -0,0 +1,66 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2010-06-06 22:15 UTC"]] + +A month of the Hurd: *DDE linux26*, *thread storms*, *patches*, *new live CD* and *IRC meetings*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +> [[Zheng_Da|user/zhengda]] +> [reported](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00037.html) +> on the state of his ongoing work of porting DDE linux26 to the Hurd, which is +> meant to improve the GNU/Hurd hardware support. The devices as emulated by +> QEMU and VMware already work fine, but he's still seeking help for testing on +> real hardware. + +> Sergio López published +> [patches](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00059.html) +> as well as [readily-usable +> packages](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00106.html) +> to prevent thread storms in ext2fs when synchronizing large pagers. This +> should improve system performance and stability. + +> Emilio Pozuelo Monfort and Sergio López developed further patches (for +> example: +> [exec](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html), +> [tmpfs](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00077.html)) to +> fix or improve the various internal Hurd servers, and discussed them with +> other Hurd developers. + +> Justus Winter [created a live +> CD](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00033.html) with an +> installation wizard in the spirit of the OpenBSD installer. He needs testers +> to help improve it. + +> Ludovic Courtès informed that he has added support for [cross-building +> packages from GNU/Linux to +> GNU/Hurd](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00105.html) +> to the Nix package manager, as well as doing [continuous cross-building of +> the GNU Hurd +> itself](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00111.html), +> and [glibc](http://sourceware.org/ml/libc-alpha/2010-05/msg00049.html). + +> The [[regular IRC meetings|irc#regular_meetings]] for [[Google Summer of Code +> students|community/gsoc]], their mentors, and any other interested parties +> [are +> continuing](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00148.html) +> on Mondays and Thursdays, 10:30 UTC, as Olaf Buddenhagen reported. If you +> want to catch up, have a look at the [#hurd channel +> logs](http://richtlijn.be/~larstiq/hurd/). + +> As always in the *Month of the Hurd*, these news blurbs are only a selection +> of what happened in the last month. There's always more to be found on our +> [[mailing_lists]], especially [[mailing_lists/bug-hurd]]. + +"""]] diff --git a/news/2010-06-30.mdwn b/news/2010-06-30.mdwn new file mode 100644 index 00000000..d435d2d2 --- /dev/null +++ b/news/2010-06-30.mdwn @@ -0,0 +1,77 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2010-07-08 14:00 UTC"]] + +A month of the Hurd: *Debian Installer*, *clustered page-in*, and *a bunch of +bug fixing*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +> A bunch of patches have hit the mailing lists and source code repositories: + +> Jérémie Koenig posted a [preliminary +> patch](http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00047.html) to +> add initrd (initial ramdisk) support in GNU Mach for his [[Google Summer of +> Code|community/gsoc]] 2010 project: [[Debian Installer|jkoenig]]. With this +> patch, and some other patches that are still in flux, he ended up being able +> to install a [[Debian GNU/Hurd|hurd/running/debian]] system using the Debian +> Installer -- which is the goal of his project. Patches being *in flux* means +> that there's still work left to be done to properly solve some issues, so +> there's no need to worry that Jérémie wouldn't have any work left until the +> GSoC ends. + +> Karim Allah Amed came up with the [first +> patch](http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html) for +> porting the clustered paging-in code from OSF Mach to GNU Mach, which should +> improve the virtual memory performance of the Hurd. + +> Emilio Pozuelo Monfort got a bug in [glibc +> fixed](http://sources.redhat.com/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=2a50c07836d2750baf70442f8f760bf6cd43b3af), +> which unblocks a problem we've seen in [coreutils' +> `ln`](https://savannah.gnu.org/bugs/?29655), and also continued to make +> progress on other grounds. + +> Zheng Da +> [began](http://lists.gnu.org/archive/html/commit-hurd/2010-06/msg00003.html) +> [to](http://lists.gnu.org/archive/html/commit-hurd/2010-06/msg00005.html) +> [commit](http://lists.gnu.org/archive/html/commit-hurd/2010-06/msg00014.html) +> patches to make his [[DDE project|zhengda]] support block device drivers, +> apart from fixing some other issues, too. + +> Samuel Thibault [fixed memory +> leaks](http://lists.gnu.org/archive/html/commit-hurd/2010-06/msg00018.html) +> in [[`pfinet`|hurd/translator/pfinet]], which is the Hurd's TCP/IP networking +> unit. Even though that a crashed `pfinet` [[server|hurd/translator]] will be +> restarted upon its next use, having it eat up all system memory is to be +> avoided, of course -- and is corrected with these patches. + +> Carl Fredrik Hammar submitted patches to improve the stability of the auth +> server ([rendezvous port +> death](http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00003.html) / +> [invalid rendezvous +> ports](http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00019.html)). + +> Lastly, if you haven't seen it already: Richard Hillesley has posted an +> article [*GNU HURD: Altered visions and lost +> promise*](http://www.h-online.com/open/features/GNU-HURD-Altered-visions-and-lost-promise-1030942.html) +> that caused [quite](http://lwn.net/Articles/394295/) +> [a](http://www.reddit.com/r/linux/comments/ckjt2/gnu_hurd_altered_visions_and_lost_promise/) +> [bunch](http://www.reddit.com/r/programming/comments/ckjud/the_hurd_altered_visions_and_lost_promise/) +> [of](http://www.osnews.com/comments/23511) +> [discussion](http://news.ycombinator.com/item?id=1474941) -- some of it valid +> and constructive criticism, some of it less so. If *you* want to come in +> contact with us GNU Hurd developers, there are [[numerous options to contact +> us|contact_us]]! + +"""]] diff --git a/news/2010-07-31.mdwn b/news/2010-07-31.mdwn new file mode 100644 index 00000000..68153c7a --- /dev/null +++ b/news/2010-07-31.mdwn @@ -0,0 +1,59 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2010-08-10 17:30 UTC"]] + +A month of the Hurd: *Thanks, Phil!*, *Debian Installer*, *compatibility*, and +*LWN article*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +> Philip Charles, our 72 years old provider of Debian GNU/Hurd installation CDs +> [has now resigned](http://lists.debian.org/debian-hurd/2010/07/msg00020.html) +> from that position. This has lead to a flood of [public thank-you +> responses](http://lists.debian.org/debian-hurd/2010/07/msg00020.html#00021), +> and surely yet more of those have been sent privately. Phil, thanks again +> for providing the many installation images you've started producing [nearly +> ten years ago](http://lists.debian.org/debian-hurd/2000/08/msg00249.html)! -- +> oh, the joy of (not) uploading CD-size images using a 56k modem... -- and +> that have been the first choice for many of us to get a [[Debian +> GNU/Hurd|hurd/running/debian]] system installed. + +> On the other hand, there's no need to worry about these news: Jérémie Koenig +> got the [Debian Installer for the +> Hurd](http://jk.fr.eu.org/debian/hurd-installer/) into a basically working +> state; there is a simple [four step installation +> guide](http://jk.fr.eu.org/debian/hurd-installer/README.txt). This brings us +> a big step forward towards easy installation of Debian GNU/Hurd and automated +> image creation. You can track Jérémie's progress on his [[user +> page|jkoenig]]. + +> Emilio Pozuelo Monfort also made progress with his Google Summer of Code +> work. For example, he posted a new iteration of his proposed [changes to +> exec](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00141.html) as +> well as he added support for [sending file descriptors over Unix +> sockets](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00145.html). +> These patches add features and improve compatibility to other systems, and +> thus help to get more software packages to work as expected on GNU/Hurd +> systems. + +> Ludovic Courtès [fixed `make +> dist`](http://lists.gnu.org/archive/html/bug-hurd/2010-07/threads.html#00107), +> which allows for easy tarball creation of the GNU Hurd sources. + +> We've been in the news [[last month|2010-06-30]] -- and this month yet again: +> LWN posted a well-researched article on the status of the Hurd: Koen +> Vervloesem: [*The Hurd: GNU's quest for the perfect +> kernel*](http://lwn.net/Articles/395150/). + +"""]] diff --git a/news/2010-08-31.mdwn b/news/2010-08-31.mdwn new file mode 100644 index 00000000..f3910b15 --- /dev/null +++ b/news/2010-08-31.mdwn @@ -0,0 +1,90 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2010-09-17 13:00 UTC"]] + +A month of the Hurd: *Media Appearances*, *procfs*, *Arch Hurd*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else="[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +> Neal Walfield and Michael Bank have been doing presentations related to the +> GNU Hurd: from the GNU Hackers Meeting in the Hague you can watch the +> {{$community/meetings/ghm2010#walfield_hurd}} where he details why we're +> still interested in working on the GNU Hurd, and there is another +> {{$community/meetings/debconf10#banck_hurd}} from DebConf10, including a very +> nice nod towards the main actors who are currently pushing the Hurd forward. + +> Jérémie Koenig wrapped up his Google Summer of Code project ([[Debian +> Installer|jkoenig]]) by posting his [*Hurd patches for +> installer/build*](http://lists.debian.org/debian-hurd/2010/08/threads.html#00016) +> as well as the [*patches used for hurd +> 20100802-1~jk7*](http://lists.debian.org/debian-hurd/2010/08/threads.html#00022) +> to the [[mailing_lists/debian-hurd]] mailing list. Most of them have been +> handled in the mean time, and we're still waiting for *you* to test his work +> by following his easy [four-step +> instructions](http://jk.fr.eu.org/debian/hurd-installer/README.txt). + +> However, even though that [[this year's GSoC|community/gsoc]] has come +> to an end, he didn't stop working: among other things, he has rewritten +> [[hurd/translator/procfs]] and [published his +> version](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00165.html) +> just before the end of the month: +> +> > I have successfully tested it with most of the Linux procps utilities, +> > as well as busybox and htop. It seems to be stable, not too slow, and +> > it stays under 1.5M in resident size. +> +> Testing it is as simple as this: +> +> $ git clone git://git.savannah.gnu.org/hurd/procfs.git +> $ cd procfs/ +> $ git checkout jkoenig/master +> $ make +> $ settrans -ca proc procfs --compatible +> $ ls -l proc/ + +> Thomas Schwinge [added some more +> information](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00066.html) +> to the web pages, notably a bunch of [[open_issues]] reports, to have them +> registered in a generic place, and to facilitate coordination. If you're +> looking for a Hurd-related project to work on, go looking +> [[there|open_issues]]! He also converted and merged some of the [hurdextras +> CVS repositories](http://www.nongnu.org/hurdextras/) into the [hurd Git +> repositories](http://git.savannah.gnu.org/cgit/hurd) and our +> [incubator](http://git.savannah.gnu.org/cgit/hurd/incubator.git/refs/). All +> of this should make it easier for new contributors to join in. + +> The [[hurd/running/Arch_Hurd]] guys have some news to share, too: +> +> * They reported on their [current status](http://www.archhurd.org/news/17), +> as well as they [released a new LiveCD +> image](http://www.barrucadu.co.uk/arch-hurd-livecd-i686-core-2010-08-25iso), +> and added a [Planet Arch Hurd](http://planet.archhurd.org/) which +> aggregates the different Arch Hurd Blogs. +> +> * The team [packaged everything](http://www.archhurd.org/news/18/) you need +> for the [[faq/GHAMP]] solution stack. +> +> * Their Diego Nieto Cid sent a patch series to [*bring console-driver-xkb +> up to +> date*](http://lists.gnu.org/archive/html/bug-hurd/2010-08/threads.html#00012). +> This is a add-on to allow using X keymaps to configure the [[Hurd +> console|hurd/console]] for non-US keyboard layouts. + +> Finally, amongst other bug fixing and other development work by the usual +> suspects, we had a short review of what the current Hurd contributors [[still +> need|community/weblogs/ArneBab/what_we_need]] to use a GNU/Hurd system for +> most of their day-to-day tasks. This may help to prioritize the development +> efforts. + +"""]] diff --git a/news/2010-09.mdwn b/news/2010-09.mdwn new file mode 100644 index 00000000..a35e1b3e --- /dev/null +++ b/news/2010-09.mdwn @@ -0,0 +1,129 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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 date="2010-10-23 12:47:26 UTC"]] + +A month of the Hurd: *new translators* / *bug fixing*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +Yes, we're a bit late this month. Arne Babenhauserheide, the guy who has +started and has been drafting the *Month of the Hurd* ever since June 2009 +(yes, that one and a half years already!), moves on to other duties -- his wife +has given birth to our first Hurd developer offspring (as far as I know): + +> Last friday my son Leandro entered our cold and too bright but friendly +> world, [...] + +We wish them good luck for their new parental duty! + +The other guy, Thomas Schwinge, who has been editing and publishing the *Month +of the Hurd* will take over -- at least temporarily (mind you, Arne). + +But, we got some Hurd news, too. + +Olaf Buddenhagen posted a patch that allows to [obtain number of ports in proc +and libps](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00036.html) by +means of adding a new [[RPC]] -- and subsequently held a discussion with Samuel +Thibault who proposed that instead of adding such functionality on an [ad hoc +basis](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00044.html), a +more generic solution could be found, too. In the end, they agreed that this +functionality was useful enough, and the patch was +[committed](http://lists.gnu.org/archive/html/commit-hurd/2010-09/msg00031.html). + +It is important to spend time on designing proper interfaces (RPCs in this +case), but on the other hand what we're doing now need not be set in stone +forever, as Olaf +[explains](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00045.html): + +> Well, we already have a mechanism for making communication protocols in +> the Hurd extensible: it's called the RPC mechanism... :-) Let's not try +> to invent another generic mechanism on top of RPCs. +> +> *If* ten year down the road we indeed end up with half a dozen +> miscallaneous info queries, we can *still* replace them by a new RPC +> covering all of it... + +Thomas Schwinge [moved some +packages](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00031.html) +([[hurd/translator/gopherfs]], [[hurd/translator/netio]], +[[hurd/translator/tarfs]]) from hurdextras to the Hurd's +[[source_repositories/incubator]] repository; these are now available as +[[Debian GNU/Hurd packages|hurd/running/debian]]. Manuel Menal also spent time +on actually making tarfs and good ol' gopherfs usable. + +Similar treatment [has been +applied](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00055.html) to +Jérémie Koenig's new [[hurd/translator/procfs]] implementation; +this one is now [used in Debian +GNU/Hurd](http://lists.gnu.org/archive/html/commit-hurd/2010-09/msg00063.html). + +Jérémie found some [problems with signal +delivery](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00006.html) -- +signals apparently are not delivered as expected. Roland McGrath, this *hairy +code*'s original author, [provided some +insight](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00008.html): + +> It's not that it's a bug, it's that the Hurd has never had POSIX-1996 +> multithreaded signal semantics. The Hurd implementation predates those +> specifications. + +He [continued to +explain](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00010.html): + +> The Hurd signal semantics are well-defined +> today. They are not the POSIX-1996 semantics in the presence of multiple +> threads per process. + +This explains for differences comparing to other recent Unixy systems, for +example Linux. Neal Walfield, our [[libpthread]]'s main author, +[states](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00017.html) that +he sees *no convincing reason to not adopt POSIX/Linux signal semantics and +abandon Hurd signal semantics*. Jérémie went on to [send a first +patch](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00011.html). +While already working in that area, Samuel Thibault applied some further fixes +to our two threading libraries, and among others, he also sent a related glibc +patch to [fix signal-catching +functions](http://sourceware.org/ml/libc-alpha/2010-09/msg00015.html). And +then, there is still the project about [[converting the Hurd's libraries and +servers to using libpthread instead of Mach's cthreads +(libthreads)|community/gsoc/project_ideas/pthreads]]; likely such signalling +system moderizations could be done [alongside of +that](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00021.html). + +Manuel Menal [fixed a +bug](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00061.html) that +occurred when sending file descriptors with `SCM_RIGHTS` over `PF_LOCAL` +sockets. He also identified this bug as the reason why the SSH daemon's +privilege separation was not working on GNU/Hurd -- now [this is +fixed](http://lists.gnu.org/archive/html/commit-hurd/2010-09/msg00036.html) and +you can use the default of `UsePrivilegeSeparation yes`. + +Michael Banck has, based on user feedback, applied some changes to the +[[!debpkg crosshurd]] package, and [uploaded a new +version](http://lists.debian.org/debian-hurd/2010/09/msg00037.html). + +In other news, the [[hurd/running/Arch_Hurd]] guys rightfully concluded that +now that they're having a package available for almighty GNU Emacs, [no further +user-land packages need to be +ported](http://blogs.archhurd.org/hayashi/2010/09/04/emacs-emacs/). If only +everyone was using Emacs... + +Last, and least, [there are +rumors](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00026.html) about +our colleagues over at the Duke Nukem Forever department getting serious again. +We shall see. :-) + +"""]] diff --git a/news/2010-10.mdwn b/news/2010-10.mdwn new file mode 100644 index 00000000..c7312256 --- /dev/null +++ b/news/2010-10.mdwn @@ -0,0 +1,65 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2010-12-20 11:10 UTC"]] + +A month of the Hurd: *bug fixing* / *flubber re-installation*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +A bit of bug fixing has been going on: + +Samuel Thibault taught [[GNU Mach|microkernel/mach/gnumach]] that Intel Pentium +4 and Opteron-class CPUs [are not just +i386](http://lists.gnu.org/archive/html/commit-hurd/2010-10/msg00021.html), but +in fact a bit more advanced. Not only does this help GNU Mach to select +optimized code paths, but this information is also propagated to the user +space, and used for the `uname` command, for example. + +Pino Toscano continued [fixing bugs in the socket-related glibc code and Hurd's +pfinet](http://lists.gnu.org/archive/html/bug-hurd/2010-10/msg00017.html). + +After finding out that our `pread` implementation does not conform to the POSIX +standard in one aspect, Manuel Menal analyzed this, and [posted a +patch](http://lists.gnu.org/archive/html/bug-hurd/2010-10/msg00056.html). + +Alexey Kuznetsov [privided IPv6 raw socket +fixes](http://lists.gnu.org/archive/html/commit-hurd/2010-10/msg00028.html) for +[[hurd/translator/pfinet]]. + +Michael Banck [uploaded a new version of +crosshurd](http://lists.gnu.org/archive/html/commit-hurd/2010-10/msg00006.html) +to keep up with recent packaging and dependency changes. + +Samuel Thibault uploaded [[hurd/translator/gopherfs]] packages [to the Debian +repository](http://lists.debian.org/debian-hurd/2010/10/msg00018.html). He +also [enabled IPv6 support for Debian Installer +installations](http://lists.gnu.org/archive/html/commit-hurd/2010-10/msg00034.html). + +Thomas Schwinge: + +> It's been a really long-long time (hooray!), but now +> [[flubber|public_hurd_boxen]]'s root file system is totally hosed, and thus +> needs to be +> [re-installed](http://lists.gnu.org/archive/html/bug-hurd/2010-10/msg00003.html). +> (I've been running `apt-get dist-upgrade` when the box apparently crashed.) +> Running `e2fsck` on it spew out over 50.000 lines of illegal and +> multiply-claimed block lists, before I terminated it, so no chance. I'll do +> this over the weekend. `/home/` etc. are not affected, thanks to being on a +> separate partition. + +As of two days later, the machine was +[re-installed](http://lists.gnu.org/archive/html/bug-hurd/2010-10/msg00011.html). + +"""]] diff --git a/news/2010-11.mdwn b/news/2010-11.mdwn new file mode 100644 index 00000000..0fcc6551 --- /dev/null +++ b/news/2010-11.mdwn @@ -0,0 +1,29 @@ +[[!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 date="2011-01-09 20:50 UTC"]] + +A month of the Hurd: *a short one*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +That's a short one. Apart from the regular business of having internal design +/ development / etc. discussions, and helping people to get their Hurd systems +running, we had Diego Nieto Cid post patches +([1](http://lists.gnu.org/archive/html/bug-hurd/2010-11/msg00019.html), +[2](http://lists.gnu.org/archive/html/bug-hurd/2010-11/msg00023.html)) to +correct two programming errors, which Samuel Thibault quickly reviewed and +applied to the [[source repositories]]. + +"""]] diff --git a/news/2010-12.mdwn b/news/2010-12.mdwn new file mode 100644 index 00000000..60d0226f --- /dev/null +++ b/news/2010-12.mdwn @@ -0,0 +1,45 @@ +[[!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 date="2011-01-09 21:25 UTC"]] + +A month of the Hurd: *CD images*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +Samuel Thibault [*updated the Debian GNU/Hurd installer +ISO*](http://lists.debian.org/debian-hurd/2010/12/msg00001.html), and also +again did his regular batch of bug fixing. + +*Arch Hurd is back in action!*, too: they uploaded a [first version of a +graphical live CD](http://www.archhurd.org/news/19/). + +Neal Walfield +[reported](http://lists.gnu.org/archive/html/l4-hurd/2010-12/msg00001.html) on +the state of his [[microkernel/Viengoos]] kernel / research project, which +unfortunately is currently on hold, due to other commitments. + +Olaf Buddenhagen raised an interesting use case: you can use a [[*subhurd* for +debugging the *main* Hurd system|hurd/subhurd#debugging_main_hurd_system]]. +That is [[hurd/virtualization]] at its best! + +Right before the end of the year, Diego Martin Nieto Cid sent a [patch series +to fix some issues with `make +dist`](http://lists.gnu.org/archive/html/bug-hurd/2010-12/msg00024.html). + +--- + +Happy New Year 2011, everyone! + +"""]] diff --git a/news/2010.mdwn b/news/2010.mdwn new file mode 100644 index 00000000..2ba85266 --- /dev/null +++ b/news/2010.mdwn @@ -0,0 +1,130 @@ +[[!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 date="2011-02-05 12:00 UTC"]] + +A year of the Hurd: *2010*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +Originally published in {{$gnu#gnustatus-2011-01}}. + +From Olaf Buddenhagen, Arne Babenhauserheide, Thomas Schwinge: Yeah, +that's quite right: the GNU Hurd project is still alive! + +According to our mission statement, the goal is creating *a +general-purpose kernel suitable for the GNU operating system, which is +viable for everyday use, and gives users and programs as much control +over their computing environment as possible*. It has a unique +multi-server microkernel-based architecture---bringing advanced +operating system research to the mainstream. More concretely, it's a +collection of user-space server processes that run on the GNU Mach +microkernel. + +The Hurd doesn't fully deliver on the *everyday usability* goal +yet, but it is seeing continuous improvement---and 2010 has been no +exception. Let's take a look at the progress throughout the year. + + * +Apart from having done a lot of other work, Samuel Thibault, our Jack +of all trades, merged his development branch that added Xen domU +support to GNU Mach, which makes it possible to run a GNU/Hurd system +as a Xen guest. Development of this started in 2007, and since then +it has been heavily tested by using it for the Debian GNU/Hurd build +servers, most of our public GNU/Hurd systems, +<http://www.gnu.org/software/hurd/public_hurd_boxen.html>, and the +Hurd project's wiki web server. + + * +We had Zheng Da work on a new hardware device driver framework, which +is based on the Dresden L4 (Fiasco) group's DDE project, and allows +running modern Linux kernel drivers as user-space server processes. +Many network cards already work perfectly with this new framework. +(It has not yet been integrated into the mainstream Hurd code base, so +it needs to be compiled and set up by hand.) Other driver classes, +such as hard disk controllers, will require further work. + + * +As in the previous years, we again participated in the Google Summer +of Code 2010. Olaf Buddenhagen is our main guy for organizing this. + + Jérémie Koenig ported the modern Debian Installer to Debian +GNU/Hurd. Installation images using the new installer are replacing +the previous CD images, which were using an installer based on the old +Debian boot floppies (and running under the Linux kernel)---Philip +Charles has been maintaining these single-handedly for almost ten +years! The new installer images are available from +<http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/>. + + Emilio Pozuelo Monfort was investigating specific compatibility +problems exposed by the extensive test suites coming with some +software packages. Emilio's analysis uncovered a number of +programming errors in the Hurd code, and he fixed several of them. As +these typically affected other programs too, this improved stability +and compatibility in general. + + * +Jérémie Koenig created a new implementation of a `procfs` +translator, which is considerably more robust and efficient than the +previous one. Tools such as `top` can now be used without +problems. + + Some other translators (`gopherfs`, `netio`, +`tarfs`) which have been created by external contributors in +the past have been fixed up by Manuel Menal, and packaged in Debian. +Thus, some of the results of Hurd's extensible architecture are now +easier to access, and these updated translators can serve as examples +for other developers to implement their own ideas. + + * +In addition to various general stability, compatibility, and +portability fixes, several people (Samuel Thibault, Pino Toscano, +Emilio Pozuelo Monfort, and others) have been working on fixing issues +with specific Debian packages. So far, about 68% of all Debian +packages are also available for Debian GNU/Hurd. + + * +Michael Walker started the Arch Hurd distribution, and together with +other enthusiastic Arch developers (Allan McRae, Matthias Lanzinger, +Alexander Preisinger, Stephen Gilles, Diego Nieto Cid) they got it +working in an amazingly short amount of time, both as an installable +system, and a live CD. So now there is a choice between two +well-featured distributions for the Hurd. These new people of course +also help forwarding Hurd development in general---Diego in particular +contributed various patches to the Hurd console and other components. + + * +Carl Fredrik Hammar finished and presented his thesis, *Generalizing +mobility for the Hurd*, +<http://lists.gnu.org/archive/html/bug-hurd/2010-01/msg00078.html>, +and passed with distinction. + +This is a very short digest of what happened in the last year. You +can read our regular *Month of the Hurd* at +<http://www.gnu.org/software/hurd/news.html>, or by subscribing to +our RSS feed at <http://www.gnu.org/software/hurd/index.rss>. + +If you are interested, for example, in doing a university project on a +multi-server microkernel-based operating system, or if you are +interested in contributing to Hurd development in general, please see +<http://www.gnu.org/software/hurd/contributing.html>. Or just +talk to us at <bug-hurd@gnu.org> or the `#hurd` IRC +channel on freenode. + +--- + +French article by Manuel Menal, [*Gnu : L'année 2010 du +Hurd*](http://linuxfr.org/news/lann%C3%A9e-2010-du-hurd). + +"""]] diff --git a/news/2011-03-26.mdwn b/news/2011-03-26.mdwn new file mode 100644 index 00000000..588f5fcf --- /dev/null +++ b/news/2011-03-26.mdwn @@ -0,0 +1,15 @@ +[[!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 date="2011-03-26 14:20 UTC"]] + +The **Google Summer of Code 2011** is on! If you're a student, consider +applying for a GNU Hurd project -- details to be found on our +*[[community/GSoC]] page*. diff --git a/news/2011-04-01.mdwn b/news/2011-04-01.mdwn new file mode 100644 index 00000000..3c0c3869 --- /dev/null +++ b/news/2011-04-01.mdwn @@ -0,0 +1,44 @@ +[[!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 date="2011-04-01 08:30 UTC"]] + +[[!meta title="2011-04-01: GNU/Hurd 0.401 is released!"]] + +We'd like to pass on these marvelous news from our Release Management +Team, headed by Release Manager Samuel Thibault: + +> Hello, +> +> There are rumors that Duke Nukem Forever will actually be released in +> Apr^WMa^WJune 2011, so there's no escape for the Hurd any more, we had +> to finish and release. There has been considerable progress lately, +> so it is with great pleasure that the Hurd maintainers team decided +> to release *version 0.401 of the GNU/Hurd Operating System*. As the +> version number and image size suggest, this is only a small preview +> of course, but we expect GNU/Hurd to be of production-quality within +> the third millenium, to be sure. +> +> A *LiveCD demo* is available on +> <http://people.debian.org/~sthibault/hurd-0.401/hurd-0.401.iso> +> and can be trivially tried using +> `qemu -cdrom hurd-0.401.iso` +> +> We hope that you will appreciate its features and speed. +> +> Are you interested in contributing to the GNU Hurd project? Just +> request an shell account on one of our servers and get started. +> +> <http://www.gnu.org/software/hurd/public_hurd_boxen.html> +> +> It is also worth noting that like in previous years, GNU/Hurd runs +> for the GSoC program, details can be found on +> +> <http://www.gnu.org/software/hurd/community/gsoc.html> diff --git a/news/2011-05-02-foss_factory.mdwn b/news/2011-05-02-foss_factory.mdwn new file mode 100644 index 00000000..298a5de6 --- /dev/null +++ b/news/2011-05-02-foss_factory.mdwn @@ -0,0 +1,98 @@ +[[!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 date="2011-05-02 09:30 UTC"]] + +[[!meta title="2011-05-02: Introducing FOSS Factory -- a Bounty System for GNU Hurd Work"]] + +> Hey, I have more money than time or programming skills, and I'd like to help +> GNU Hurd development specifically -- how can we arrange for this, where can I +> donate money for GNU Hurd development? + +If you're dwelling on such thoughts, here is the answer; here you can donate +money for GNU Hurd development. +[[!if test="included()" then="""[[!toggle id=full_news +text="Read on."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +As its principal idea, [FOSS Factory](http://www.fossfactory.org/), means to +serve as a hub and organizational platform for connecting Free/Open Source +Software developers with monetary sponsors. From +<http://www.fossfactory.org/aboutus.php>: + +[[!img donate/foss_factory/logo.png align=right link=no]] + +> FOSS Factory's mission is to accelerate the advancement of free/open source +> software by helping people collaborate on the design, funding, and +> development of innovative software ideas. All software solutions produced +> using our system are released under free/open source licenses. Our unique +> model brings the best of innovators from both the entrepreneurial and FOSS +> worlds together to solve real world problems using the mass resources of the +> FOSS community. + +In very general words, their modus operandi is that the community (including +the monetary sponsors) works together with the developers on splitting up tasks +into suitable and assessable sub-projects as necessary, and then act as the +reviewing instance, deciding on such sub-projects' success (and payment, +successively). For more details see their [System +Overview](http://www.fossfactory.org/overview.php). + +For now, we can assume that the amount of money to be made by working on a GNU +Hurd task in this framework is likely to be a symbolic amount only, rather than +being representative for the real effort that needs to be invested. Software +development is expensive, mostly due to the amount of time that is needed for +completing any non-trivial task. Instead, these bounties should be regarded as +an attraction/reward, perhaps also simply as a motivation for a developer to +focus on one specific problem, and bringing it to completion. + +Working on a task and/or suggesting/donating for a new task. + +In principle, any Hurd-related development task is applicable (for example, +from the [[GSoC project ideas|community/gsoc/project_ideas]], or from the +[[open_issues]] list), but it is of course recommendable to match sponsors' +ideas with those of the developers and maintainers. For this, if you want to +sponsor a project, but don't know which one to choose, or if you want to work +on a bounty that is not yet listed on the site, we suggest that you talk to us +first, either publically on the [[bug-hurd mailing +list|mailing_lists/bug-hurd]] or privately on <hurd-maintainers@gnu.org>, if +you prefer. + +Both for supporting (donating) as well as claiming a bounty, you have to +register [at their site](http://www.fossfactory.org/), and proceed from there. +Please don't hesitate to ask [[Thomas Schwinge|tschwinge]] if you need help. + +Continue to explore the [[list of open bounties|tag/bounty]]. + +--- + +This new installment is in no way meant to depreciate the developers' current, +un-paid, efforts. It is also not meant to replace the volunteer work in the +long term. Neither is it meant to trick the [general FSF fund +raising](http://donate.fsf.org/) out of a few dollars. Instead, this is simply +an additional means, a place for donators to give money for *Hurd-specific +tasks*. + +Everyone of the existing crew is eligible to do coding under this bounty +system, but we also hope to attract new developers -- in a sense similar to our +many years of participation in the [[Google Summer of Code|community/gsoc]]. + +Participation in/use of FOSS Factory's services has explicitly been set up +personally by me, Thomas Schwinge; there is no inherent connection to the GNU +Hurd maintainers. This also means that each contribution that comes to life +out of FOSS Factory's framework is subject to the same rules/review process as +any other contribution has always been. + +Unless willing to discuss these publically, any concerns, questions, requests +regarding this system can always be addressed directly to [[me|tschwinge]]. + +"""]] diff --git a/news/2011-q1.mdwn b/news/2011-q1.mdwn new file mode 100644 index 00000000..103f559b --- /dev/null +++ b/news/2011-q1.mdwn @@ -0,0 +1,57 @@ +[[!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 date="2011-04-05 21:30 UTC"]] + +A quarter of the Hurd, Q1 of 2011: *GSoC*, and *new faces*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +We're again participating in the [[Google Summer of Code's 2011 +edition|community/gsoc]]. If you know someone who knows that her neighbor +would be interested in getting mentored (by us) and paid (by Google) for +working on a [[GNU/Hurd task|community/gsoc/project_ideas]], please hurry up: +the *student application period* will end this Friday, 2011-04-08. + +There's further progress to be reported on the package porting front: +additionally to the usual suspects, Svante Signell +[has](http://lists.gnu.org/archive/html/bug-hurd/2011-01/msg00028.html) +actively [started](http://lists.debian.org/debian-hurd/2011/02/msg00021.html) +with [contributing](http://lists.debian.org/debian-hurd/2011/02/msg00036.html) +by [fixing](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00017.html) +or [porting](http://lists.debian.org/debian-hurd/2011/01/msg00025.html) his +[favorite](http://lists.debian.org/debian-hurd/2011/01/msg00062.html) packages +[to](http://lists.debian.org/debian-hurd/2011/01/msg00051.html) GNU/Hurd. +Welcome, Svante! + +Amongst other fixes, Diego Nieto Cid submitted his work for using [XKB's +keymaps for the Hurd +console](http://lists.gnu.org/archive/html/bug-hurd/2011-03/threads.html#00053). +Of course, he was not the only one to contribute fixes; there's always our +bunch of folks who appear every other month, or week, and send in some +contribution. Also, as we ask our GSoC applicants to submit patches in order +to substantiate their application, we've seen some additional ones due to that. +([[And you can, too.|contributing]]) + +The Arch Hurd folks published their [Year of Arch Hurd +report](http://www.barrucadu.co.uk/year-of-arch-hurd), wrapping up their +progress, including GHAMP (GNU/Hurd, Apache, MySQL, and PHP), X.org, and their +[Arch Hurd LiveCD](http://www.archhurd.org/gethurd.php#livecd). We had +published our [[YotH 2010|2010]], too. + +Finally we got a nice [recognition (or did they mean...) by +xkcd](http://xkcd.com/844/), *How to Write Good Code*, subtitled *You can +either hang out in the Android Loop or the HURD loop*. Go figure! ;-) + +"""]] diff --git a/news/2011-q2-ps.mdwn b/news/2011-q2-ps.mdwn new file mode 100644 index 00000000..28d2bbb0 --- /dev/null +++ b/news/2011-q2-ps.mdwn @@ -0,0 +1,163 @@ +[[!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 date="2011-10-13 10:00 UTC"]] + +A quarter of the Hurd, Q2 of 2011, PS: *GNU Hurd Truths and Myths*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +After our last *[[Quarter of the Hurd, Q2 of 2011|2011-q2]]* has been picked +up by a bunch of news sites, blogs, and so on, discussions and speculations +have been running all over the net: + + * {{$news/2011-q2#lwn}}; + * {{$news/2011-q2#phoronix-1}}; + * {{$news/2011-q2#phoronix-2}}; + * {{$news/2011-q2#golem}}; + * {{$news/2011-q2#h-online}}; + * {{$news/2011-q2#innocenthacker}}; + * {{$news/2011-q2#netzwelt}}; + * {{$news/2011-q2#operation-tunnelbau}}; + * {{$news/2011-q2#osnews}}; + * {{$news/2011-q2#pro-linux}}; + * {{$news/2011-q2#reddit-1}}; + * {{$news/2011-q2#reddit-2}}; + * {{$news/2011-q2#slashdot}}; + * and a lot more. + +We are happy to see that there is +considerable interest in the Hurd; but we also saw some +misunderstandings, false rumors, and outdated information floating +around. Thus we will try to clarify the situation regarding some of +the more common misunderstandings. + + * **Debian GNU/Hurd strives to become an official Debian port**: + The Debian GNU/Hurd team is working hard to prepare a technology + preview/release candidate for the next Debian release (Wheezy), to + eventually become an official port alongside GNU/Linux and GNU/kFreeBSD -- + but we don't know yet whether we will make it. This is also the + understanding of (for example) Debian's spokesperson + {{$news/2011-q2#schmehl}}. + There is still substantial work necessary to indeed become a release candidate. + If you + want to help, please see our [[contributing]] page and the *to do* + list maintained on <http://wiki.debian.org/Debian_GNU/Hurd>. We'd + be happy to have you on board! + + * **Java support for GNU Hurd is nearby**: Jérémie Koenig is working + on making a versatile Java programming environment available on + GNU/Hurd as part of his + [[Google Summer of Code project|user/jkoenig/java]], focusing on + OpenJDK 7. [Experimental + packages](http://jk.fr.eu.org/debian/experimental/) + are already available. + Also, Java support in GCC (via GCJ/ECJ) has been available before, + which Jérémie also improved. + + * **GNU Hurd supports X.Org, though a bit unstable**: + X support has been present for ages + (anyone remember + [1998's + XFree86](http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/os-support/hurd/hurd_video.c?rev=1.1&content-type=text/vnd.viewcvs-markup)?), + and X.Org also has been supported for a long time (for example, GNU Hurd + support is explicitly mentioned in the [X.Org 7.2 release + announcement](http://www.x.org/wiki/Other/Press/X11R72Released?action=show&redirect=PressReleases%2FX11R72Released)). + It is true though that many modern graphic card drivers don't work anymore, + as they require DRM (Direct Rendering Manager) support, + so often only VESA is available. + Also, X on the Hurd is [[somewhat_unstable|hurd/status]]. + + * **GNU Hurd has weaker device driver support than the Linux kernel**: + Most of the drivers we use today were imported from Linux 2.0 series. + For network cards, + Linux 2.6.29 drivers are available through [[DDE|hurd/dde]] -- + however, this is not fully integrated yet, + so using these drivers needs manual setup for now ([[hurd/dde/guide]]). + Support for other driver types is also possible with DDE in principle, + but it requires some not-trivial work for each additional class of drivers, + so this can take some time to become available. + (An additional benefit provided by DDE is that the device drivers run as + regular user-space processes -- + unlike the old drivers we were using so far, + which are part of the underlying GNU Mach microkernel.) + + * **The Hurd has SMP, but needs support for new chipsets**: + Both GNU Mach (the microkernel used by the Hurd), + and the Hurd servers themselves come with SMP support. + However, GNU Mach [[misses drivers for modern SMP chipsets|faq/smp]], and + there are also some SMP-related bugs in the implementation, + so further work is needed + for the Hurd to take advantage of multicore processors. + + * **Installation can still be challenging**: + Please [[take notice|http://xkcd.com/293/]] of the + [README file](http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/YES_REALLY_README.txt) -- + just like with any software in development, + there are some known pitfalls to avoid. + (Or better yet, help to fix.) :-) + Alternatively, you can simply use the the + [preinstalled + image](http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz) + in QEMU/KVM/VirtualBox/... + + * **GNU Hurd is not the same as GNU/Hurd**: + The GNU project set out in 1983 to create a complete free operating system. + When a distribution such as Debian combines their GNU-based userland + with the GNU kernel (named [[*GNU Hurd*|hurd/what_is_the_gnu_hurd]]), + the result is more or less a full GNU system. + However, such third-party distributions are distinct + from what an official complete GNU system release would be; + and thus we often call them *GNU/Hurd* for clarity, similar to *GNU/Linux* + or *GNU/kFreeBSD*. + + * **Performance**: + The benchmarks conducted by Phoronix (as reported by + {{$2011-q2#phoronix-3}}) (Phoronix/Michael: thanks for doing these!) + attest very good performance to the Hurd. + Keep in mind though that these benchmarks were almost completely CPU-bound, + so they essentially just confirm that we don't do anything stupid + regarding CPU initialization (cache setup, etc.). + The results would be different for benchmarks + that actually exercise the operating system functionality more. + The fact that the tests were performed in a virtualized environment, + might also have helped the results, + for example by mitigating the effects of our unoptimized I/O paths -- + which are currently the major bottleneck in most situations. + Nevertheless, these results are a hint + that the extra IPC required in microkernel systems + [[doesn't necessarily hamper performance|ipc#performance]] + quite as much as often believed. + We are glad to see such solid benchmarks + help dispel some of the myths around the Hurd and other microkernel-based + systems. + + * **Given the available manpower, the progress is very good**: + Over the past decade, + there were seldom more than [[*half a dozen developers* at any given + time|faq/how_many_developers]] + hacking on the Hurd, in their spare time -- + not hundreds of paid developers like Linux has nowadays. + Considering this, the progress made is quite encouraging + with the system being [[pretty usable|hurd/status]] for many day-to-day tasks now. + It is generally understood that the ambitious architecture of the Hurd + requires a lot of effort to get it working at all, + but the recent progress shows that once the foundations are in place, + the Hurd design indeed allows the developers to be very productive. + To see the progress over the last few years, you can have a look at our + [[news archive|news]]. If you're interested, you can find various ways of + [[contributing]]. We'd be happy to see you join in, because for the Hurd, + every single helping hand makes a big difference! + +"""]] diff --git a/news/2011-q2.mdwn b/news/2011-q2.mdwn new file mode 100644 index 00000000..f4dba68c --- /dev/null +++ b/news/2011-q2.mdwn @@ -0,0 +1,153 @@ +[[!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 stable_URL]] + +[[!meta date="2011-07-03 17:30 UTC"]] + +A quarter of the Hurd, Q2 of 2011: *Graphical Installer*, *GSoC*, and *Debian*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +[[!template id=note text="**Update**: + +[[*A quarter of the Hurd, Q2 of 2011, PS*|2011-q2-ps]] has been published."]] + +Jérémie Koenig started working on his [[Google Summer of Code +project|user/jkoenig/java]]: bringing not only Java to the Hurd, but also +fixing or adding missing parts in the Hurd's components along the way. For +example, he already contributed [a set of signal handling +improvements](http://sourceware.org/ml/libc-alpha/2011-06/threads.html#00119). + +Samuel Thibault +[created](http://lists.gnu.org/archive/html/bug-hurd/2011-05/msg00189.html) the +first Debian GNU/Hurd CD set with a graphical installer. You can dowload it at +[the usual place for Debian CD +images](http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/). + +Amongst others, Samuel also [tracked down and +fixed](http://lists.gnu.org/archive/html/bug-hurd/2011-05/msg00025.html) a port +leak in `file_reparent`. This one got visible on the Debian package builder +machine. + +On the organizational side, there is now a real plan to release a Hurd variant +of Debian with their next major release, Wheezy. Expected towards the end of +2012 or beginning of 2013, the Hurd-specific bits of that release effort's +process are being tracked on <http://wiki.debian.org/Debian_GNU/Hurd>. There +is still a lot of work left to be done, but -- as everyone knows -- a real goal +as well as a bit of pressure might help to actually get it done. If you want +to lend a helping hand in order to make this happen, [[porting +packages|contributing#porting]] is a great way to get started and do something +useful at the same time. + +Tanguy le Carrour offered to sponsor some Hurd work, and followed up on his +offer by adding to the Hurd bounties that Thomas Schwinge had set up over at on +FOSS Factory -- [[claim them if you can|2011-05-02-foss_factory]]! It's not +(not yet?) comparable to a Google Summer of Code student's salary, but a step +into the right direction. So, if you have more money than time and want the +Hurd to advance, why don't you [[join Tanguy|2011-05-02-foss_factory]]? + +At the end of August, Hurd folks will be meeting at the [[GNU Hackers +Meeting|community/meetings/ghm2011]] in Paris. Samuel Thibault will be giving +a talk (*GNU/Hurd, aka. Extensibility from the Ground*), and -- amongs others +-- Jérémie Koenig will be there too, ready to answer all the questions about +his Java/Hurd Google Summer of Code work. + +"""]] + + +[[!ymlfront data=""" + +golem: + + "Sebastian Grüner (golem): [Debian 7 kommt offiziell mit Hurd als + Kernel \[de\]](http://www.golem.de/1107/84947.html)" + +h-online: + + "Dj Walker-Morgan (The H Open): [Hurd Progresses - Debian GNU/Hurd by end of + 2012?](http://www.h-online.com/open/news/item/Hurd-Progresses-Debian-GNU-Hurd-by-end-of-2012-1279253.html)" + +innocenthacker: + + "Amit Khajuria (Innocent Hacker): [Debian 7 might come in a GNU Hurd + version](http://www.innocenthacker.com/2011/07/debian-7-might-come-in-gnu-hurd-version.html)" + +lwn: + + "Joe 'Zonker' Brockmeier (LWN): [Signs of life from GNU + Hurd](http://lwn.net/Articles/452296/)" + +netzwelt: + + "Markus Franz (netzwelt) [Debian 7.0 Wheezy: Erste Pläne für Hurd statt + Linux-Kernel + \[de\]](http://www.netzwelt.de/news/87551-debian-7-0-wheezy-erste-plaene-hurd-statt-linux-kernel.html)" + +operation-tunnelbau: + + "Jens Reil: [Hurd kommt zusammen mit Duke Nukem + Forever. Fast. \[de\]](http://blog.operation-tunnelbau.de/archives/66-Hurd-kommt-zusammen-mit-Duke-Nukem-Forever.-Fast..html)" + +osnews: + + "Thom Holwerda (OS News): [GNU Hurd Quarterly Status + Report](http://www.osnews.com/story/24942/GNU_Hurd_Quarterly_Status_Teport)" + +phoronix-1: + + "Michael Larabel (Phoronix): [A Status Update On GNU Hurd: Java, Debian, + Money](http://www.phoronix.com/scan.php?page=news_item&px=OTY2Nw)" + +phoronix-2: + + "Michael Larabel (Phoronix): [Coming Up: Benchmarks Of GNU + Hurd](http://www.phoronix.com/scan.php?page=news_item&px=OTY3NQ)" + +phoronix-3: + + "Michael Larabel (Phoronix): [Test Driving GNU Hurd, With Benchmarks Against + Linux](http://www.phoronix.com/scan.php?page=article&item=debian_gnu_hurd)" + +pro-linux: + + "Hans-Joachim Baader (Pro Linux): [GNU Hurd will offiziell in nächste + Debian-Version + \[de\]](http://www.pro-linux.de/news/1/17261/gnu-hurd-will-offiziell-in-naechste-debian-version.html)" + +reddit-1: + + "TheSilentNumber (reddit): [RMS may finally shout \"It's alive!\" at GNU+HURD + thanks to + Debian](http://www.reddit.com/r/linux/comments/j2ztr/rms_mlayout_finally_shout_its_alive_at_gnuhurd_thanks/)" + +reddit-2: + + "mepper (reddit): [Debian now has concrete plans to bring GNU Hurd to the + larger community. It is expected to be released with the release of Debian + 7.0 Wheezy towards the end of 2012 or beginning of + 2013](http://www.reddit.com/r/linux/comments/ipxxt/debian_now_has_concrete_plans_to_bring_gnu_hurd/)" + +schmehl: + + "Alexander \"Tolimar\" Reichle-Schmehl: [About Debian, The Hurd and Linux or + in short: Yes, we will still have a Linux + kernel](http://blog.schmehl.info/Debian/hurd-not-default)" + +slashdot: + + "timothy (Slashdot): [Watch Out Linux, GNU Hurd + Coming](http://news.slashdot.org/story/11/07/14/2141229/watch-out-linux-gnu-hurd-coming)" + +"""]] diff --git a/news/2011-q3.mdwn b/news/2011-q3.mdwn new file mode 100644 index 00000000..83fc30a5 --- /dev/null +++ b/news/2011-q3.mdwn @@ -0,0 +1,116 @@ +[[!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 date="2011-11-17 14:15 UTC"]] + +A quarter of the Hurd, Q3 of 2011: *Arch Hurd with DDE*, *Debian boxes*, *GHM +talk* and *GSoC: Java*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +In the third quarter of 2011, the Arch Hurd hackers [packaged DDE (Device +Driver Environment)](http://www.archhurd.org/news/22/), so a subset of the +Linux 2.6 device drivers can now easily be run as user-space processes on Arch +Hurd, replacing GNU Mach's in-kernel device drivers. (This has been possible +before, too, but involved several [[manual steps|hurd/dde/guide]].) At the +time of writing, our DDE port supports several network cards, while for other +driver types we will need to add further generic infrastructure. Also, Arch +Hurd had [a booth at +FrOSCon](http://www.froscon.de/en/exhibitors/projekte.html#c1413) and [released +a new Arch Hurd LiveCD](http://www.archhurd.org/news/24/), so new users can +easily test the current state of the Arch flavor of the Hurd. + +Richard Braun contributed additional GNU Hurd instances: [[a *Debian buildd*, a +*Debian porterbox*, and a *public Hurd box*|public_hurd_boxen]]. Especially +the last one is important for *you*: after requesting an account, you can use +it to test the Hurd without any own setup. + +Samuel Thibault sent a new [Bits from the Debian GNU/Hurd +porters](http://lists.debian.org/debian-devel-announce/2011/07/msg00002.html) +to keep the Debian folks up to date with our progres. And it is quite good: +thanks to the relentless work of our porters, you can now use [70 % of all +Debian packages with the Hurd](https://buildd.debian.org/stats/graph-big.png), +so we're getting closer to [the goal of finishing a Release Canditate in time +for Debian Wheezy](http://wiki.debian.org/Debian_GNU/Hurd). If you can, for +example, port Debian packages and want to help the Hurd, this is the perfect +time to get in contact and [port your favorite missing +package](http://www.debian.org/ports/hurd/hurd-devel-debian) to the Hurd. + +A different kind of status update was delivered by Samuel Thibault on the [[GNU +Hacker Meeting (GHM) in Paris|community/meetings/ghm2011]]. We hope you enjoy +watching the video of the {{$community/meetings/ghm2011#thibault_hurd}}. He +nicely explains how the simple yet powerful concept of a [[hurd/translator]] +gives power to a system's less-priviledged users (that is, without `root` +access), without any security implications, and how [[hurd/subhurd]]s and +[[hurd/neighborhurd]]s compare to Linux containers. *It's all about [freedom +0](http://www.gnu.org/philosophy/free-sw.html)*. + +On the technical side, Thomas Schwinge improved the technical documentation of +the [[I/O path|hurd/io_path]] when translators are involved, to make it easier +for new developers to understand how all the different system components +interact. Amongst others, Guillem Jover, Fridolín Pokorný and Jonathan +Neuschäfer +[sent](http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00184.html) +[many](http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00093.html) +[patches](http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00030.html) for +GNU Mach, improving stability, fixing memory leaks and generally cleaning up +the code. + +Maksym Planeta finished a project he has been doing as a university task: +replace GNU Mach's old zone memory allocator with a new [[!wikipedia +slab_allocation desc="slab allocator"]] written by Richard Braun, who also +mentored Maksym during the project. [This +allocator](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?h=mplaneta/libbraunr/master&id=59c9da87375ad3c8401890ecd4f7f101093f2463), +apart from being overally cleaner than the zone allocator, is meant to waste +less memory than the zone allocator (less fragmentation and more memory can be +reclaimed by the VM system), there are debugging/inspection features, and it's +SPM-ready, thus readily usable once we get up-do-date SMP support in GNU Mach. +It is now being tested and integrated. + +And last but definitely not least, Jérémie Koenig finished his Google Summer of +Code project to [[improve Java support on GNU Hurd|user/jkoenig/java]]. All in +all, he also [improved the Hurd signalling +code](http://lists.gnu.org/archive/html/bug-hurd/2011-06/msg00073.html), ported +OpenJDK and began designing and creating a [library for Java bindings for Mach +and Hurd](https://github.com/jeremie-koenig/hurd-java) which already allows +writing a [Hello World translator in +Java](https://github.com/jeremie-koenig/hurd-java/blob/master/HelloMach.java). +It is still pretty low-level, but it paves the way for extending the core of +the Hurd with Java, which is one of the benefits of the Hurd's distributed +multi-server architecture: different components of the operating system can be +written in different programming languages; not just +[C](http://www.gnu.org/software/hurd/hacking-guide/hhg.html#An-Example-using-trivfs), +but also C++, [[Common Lisp|user/flaviocruz]], and now Java -- and more to +come. + +So if you want to help getting the Debian GNU/Hurd Release Candidate done, or +want to dig deep into DDE to have more device drivers running as user-space +processes, please [[get in contact|contact_us]] -- and maybe already grab the +[[source code|source_repositories]]. + +--- + +The **GNU Hurd** is the GNU project's replacement for the Unix kernel. It is a +collection of servers that run on the Mach microkernel to implement file +systems, network protocols, file access control, and other features that are +implemented by the Unix kernel or similar kernels (such as Linux). [[More +detailed|hurd/documentation]]. + +**GNU Mach** is the microkernel upon which a GNU Hurd system is based. It +provides an Inter Process Communication (IPC) mechanism that the Hurd uses to +define interfaces for implementing in a distributed multi-server fashion the +services a traditional operating system kernel provides. [[More +detailed|microkernel/mach/gnumach]]. + +"""]] diff --git a/news/2011-q4.mdwn b/news/2011-q4.mdwn new file mode 100644 index 00000000..efed1001 --- /dev/null +++ b/news/2011-q4.mdwn @@ -0,0 +1,138 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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 date="2012-03-21 19:30 UTC"]] + +A quarter of the Hurd, Q4 of 2011: *Nix-based builds* and *bounty: slab +allocator merged*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +This quarter, Ludovic Courtès contributed a [continuously-built Nix-based QEMU +image](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00042.html), +raising the count of GNU/Hurd distributions to three: [[Debian +GNU/Hurd|hurd/running/debian]], [[hurd/running/Arch_Hurd]], and now +[[hurd/running/Nix]]. His build is still pretty basic, but a step into the +right direction: [[!wikipedia "continuous integration"]] is a great facility +for automated testing. + +Samuel Thibault followed suit with a [new Debian GNU/Hurd disk +set](http://lists.debian.org/debian-hurd/2011/12/msg00095.html) as a christmas +gift, and +[identified](http://lists.debian.org/debian-hurd/2011/11/msg00095.html) three +easy porting cases with solutions: + + * undefined reference to `dl_*`: add `-ldl` for building + * undefined reference to `main`: missing `gnu*` case in the linking part of + `configure.ac` or `.in` + * undefined reference to `clock_gettime` or `crypt`: add `-lrt` or `-lcrypt` + +These should help all those who want to help [[porting_packages|hurd/porting]]. + +Maksym Planeta and Richard Braun [finished +integration](http://lists.gnu.org/archive/html/bug-hurd/2011-12/msg00046.html) +of the slab allocator. From [[IRC]], freenode, #hurd, 2011-11-14: + + <braunr> there shouldn't be any noticeable difference [...] + <braunr> a bit less fragmentation + <braunr> more memory can be reclaimed by the VM system + <braunr> there are debugging features + <braunr> it's SMP ready + <braunr> and overall cleaner than the zone allocator + <braunr> although a bit slower on the free path (because of + what's performed to reduce fragmentation) + <braunr> but even "slower" here is completely negligible + +This also +[concludes](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00140.html) +our first [[FOSS Factory|donate#FOSS_Factory]] project -- one [[tag/bounty]] +has been redeemed, more are waiting. + +Sergio Lopez documented his work on +[[better_memory_management_and_memfs|Sergio_Lopez]], making it easier for other +hackers to join in working on that topic. + +Our hackers also used the quarter for porting a good number of packages and +fixing bugs. After fixing quirks in the Hurd's memory management system, +Sergio Lopez [reported success building +webkitgtk+](http://lists.debian.org/debian-hurd/2011/10/msg00025.html), whose +build stresses the available memory resources on a 32-bit architecture to a +large extent. Svante Signell was busy, too: +[pax](http://lists.debian.org/debian-hurd/2011/10/msg00105.html), +[abiword](http://lists.debian.org/debian-hurd/2011/11/msg00035.html), +[syslog-ng](http://lists.debian.org/debian-hurd/2011/11/msg00060.html), +[ecl](http://lists.debian.org/debian-hurd/2011/11/msg00058.html), +[fakeroot](http://lists.debian.org/debian-hurd/2011/12/msg00022.html), +[daemon](http://lists.debian.org/debian-hurd/2011/12/msg00025.html), and +[procps](http://lists.debian.org/debian-hurd/2011/12/msg00046.html), +[e2fsprogs' quota](http://lists.debian.org/debian-hurd/2011/10/msg00015.html). +Samuel Thibault handled +[packagekit](http://lists.debian.org/debian-hurd/2011/10/msg00071.html), +[evolution](http://lists.debian.org/debian-hurd/2011/10/msg00070.html), +[emacs23](http://lists.debian.org/debian-hurd/2011/12/msg00018.html), +[gcc-4.7](http://lists.debian.org/debian-hurd/2011/12/msg00065.html), and +[iceweasel +(firefox)](http://lists.debian.org/debian-hurd/2011/12/msg00080.html). Bouju +Alain [submitted a +patch](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00079.html) to +support `/proc/cpuinfo`. Ludovic Courtès contributed a patch to [allow for +`/hurd/init` being +symlink](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00032.html), +made the Hurd [build with glibc +2.14+](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00025.html), and +[worked with the GNU coreutils +team](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00067.html) on a +few issues. Pino Toscano improved [`recvfrom` with `NULL` address +ports](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00161.html). +Maksym Planeta continued working on +[tmpfs](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00118.html). +Samuel Thibault turned `/dev/random` and `/dev/urandom` into [native +translators](http://lists.debian.org/debian-hurd/2011/11/msg00092.html), +modernized [libtool's +configuration](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00073.html), +[mknod's cleanup in error +cases](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00070.html), +[fixed POSIX 2008 +visibility](http://lists.gnu.org/archive/html/bug-hurd/2011-12/msg00004.html), +and fixed an [[!debbug 645285 desc="issue in `setresuid` that broke `sudo`"]]. +[Pino +Toscano](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00013.html) and +[Thomas +Schwinge](http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00020.html) +improved key handling in libpthread. Guillem Jover [fixed Mach's `int` +vs. `long` +discrepancy](http://lists.debian.org/debian-hurd/2011/10/msg00053.html), which +takes us the first step towards [[porting the system to +x86_64|open_issues/64-bit_port]]. + +If you want to join us in our journey to realize more of the promises of the +architecture of the Hurd, please [[get in contact|contact_us]] -- and maybe +already grab the [[source code|source_repositories]] and have fun hacking on +Free Software! + +--- + +The **GNU Hurd** is the GNU project's replacement for the Unix kernel. It is a +collection of servers that run on the Mach microkernel to implement file +systems, network protocols, file access control, and other features that are +implemented by the Unix kernel or similar kernels (such as Linux). [[More +detailed|hurd/documentation]]. + +**GNU Mach** is the microkernel upon which a GNU Hurd system is based. It +provides an Inter Process Communication (IPC) mechanism that the Hurd uses to +define interfaces for implementing in a distributed multi-server fashion the +services a traditional operating system kernel provides. [[More +detailed|microkernel/mach/gnumach]]. + +"""]] diff --git a/news/2012-03-21.mdwn b/news/2012-03-21.mdwn new file mode 100644 index 00000000..3af7e9a9 --- /dev/null +++ b/news/2012-03-21.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2012-03-21 20:00 UTC"]] + +The **Google Summer of Code 2012** is on! If you're a student, consider +applying for a GNU Hurd project -- details to be found on our +*[[community/GSoC]] page*. diff --git a/open_issues.mdwn b/open_issues.mdwn index 8e6741c1..f77c1983 100644 --- a/open_issues.mdwn +++ b/open_issues.mdwn @@ -1,16 +1,18 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Open Issues"]] -This is a dumping ground for open issues. +This is a dumping ground for open issues. This list includes everything from +bug reports to open-ended research questions. [[!inline pages=none @@ -19,13 +21,14 @@ feeds=no actions=yes rootpage="open_issues" postformtext="Add a new item titled:"]] -[[!map pages="(./open_issues/* or */open_issues/* or -hurd/running/debian/porting/* or tagged(open_issue*)) and !tag/* and -!*/discussion" -show=title]] -The following [[!iki ikiwiki/directive/tag desc=tags]] are actively used at the -moment: +# List of Issues -[[!map pages="tag/* and !tag/*/* and !tag/open_issue_mach" +[[!map +pages="(./open_issues/* or */open_issues/* or hurd/running/debian/porting/* or tagged(open_issue*)) and !*/discussion" show=title]] + + +# List of Tags + +[[!inline pages=tag raw=yes feeds=no]] 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/active_vs_passive_symlink_translator.mdwn b/open_issues/active_vs_passive_symlink_translator.mdwn new file mode 100644 index 00000000..cbd9b077 --- /dev/null +++ b/open_issues/active_vs_passive_symlink_translator.mdwn @@ -0,0 +1,44 @@ +[[!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 open_issue_hurd]] + +IRC, freenode, #hurd, 2011-07-25 + +Set an *active* (not *passive*) `/hurd/symlink` translator on a node. + + < antrik> that's strange: the file doesn't look like a symlink in ls output + -- but it behaves like one... + < antrik> using firmlink instead of symlink yields less confusing + results... + < gg0> how does it behaves like one? + < antrik> perhaps the symlink mechanism only fully works for a passive + symlink translator, not an active one + < antrik> gg0: if you access it, you actually get the linked file contents + < antrik> it's only ls that's confused + < antrik> it might be because ls -l uses O_NOFOLLOW, which results in + O_NOTRANS, so it sees the original file contents + < gg0> stat says it's still 12264 bytes + < antrik> stat also seems to use NOFOLLOW + < antrik> wc will show the "correct" size + < gg0> ok + < antrik> if you set it as passive translator, it works as expected... but + then you better don't forget removing it, as it won't go away after a + reboot :-) + < antrik> but as I said, you can just ignore the weirdness -- or use + firmlink instead + < antrik> the thing is, if symlink is set as a passive translator, the + filesystem handles it specially, so it really looks like a symlink to + programs using NOFOLLOW. that's not the case with an active symlink... so + programs using NOFOLLOW simply do not see the active symlink at all + < antrik> firmlink OTOH ignores NOFOLLOW, so you always see the linked-to + file + + * [[hurd/translator/short-circuiting]] diff --git a/open_issues/address_space_memory_mapping_entries.mdwn b/open_issues/address_space_memory_mapping_entries.mdwn new file mode 100644 index 00000000..caf447dd --- /dev/null +++ b/open_issues/address_space_memory_mapping_entries.mdwn @@ -0,0 +1,19 @@ +[[!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-05-07 + + <braunr> and as a last example: memory mapping is heavily used in the hurd, + but for some reason, the map entries in an address space are still on a + linked list + <braunr> a bare linked list + <braunr> which makes faults and page cache lookups even slower diff --git a/open_issues/adduser.mdwn b/open_issues/adduser.mdwn index 23552301..7761ec61 100644 --- a/open_issues/adduser.mdwn +++ b/open_issues/adduser.mdwn @@ -34,3 +34,4 @@ errors, thus the warning. Copying files from `/etc/skel' ... [...] +Reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623199 diff --git a/open_issues/alarm_setitimer.mdwn b/open_issues/alarm_setitimer.mdwn new file mode 100644 index 00000000..99b2d7b6 --- /dev/null +++ b/open_issues/alarm_setitimer.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="alarm/setitimer"]] + +[[!tag open_issue_glibc open_issue_hurd]] + +`setitimer()`, called by `alarm()` when setting a new alarm, it is not able +to disable on its own the timer when the alarm is fired the first time. +On the other hand, manually invoking `alarm(0)` can cancel the running timer +for `SIGALRM`. + +See also the attached file: on other OSes (e.g. Linux) it blocks waiting +for a signal, while on GNU/Hurd it gets a new alarm and exits. + +[[alrm.c]] diff --git a/open_issues/alarm_setitimer/alrm.c b/open_issues/alarm_setitimer/alrm.c new file mode 100644 index 00000000..689020ee --- /dev/null +++ b/open_issues/alarm_setitimer/alrm.c @@ -0,0 +1,32 @@ +#include <signal.h> +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +static const char msg[] = "< got alarm\n"; + +static void sighandler(int signo __attribute__((unused))) +{ + write(STDOUT_FILENO, msg, sizeof(msg) - 1); +} + +int main() +{ + struct sigaction sa; + sa.sa_handler = sighandler; + sigemptyset(&sa.sa_mask); + sa.sa_flags = 0; + if (sigaction(SIGALRM, &sa, NULL) == -1) + return 1; + + printf("> alarm in 2 secs...\n"); + alarm(2); + pause(); + + printf("> alarm!\n"); + + pause(); + printf("> got a signal...\n"); + + return 0; +} diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn new file mode 100644 index 00000000..99ef170b --- /dev/null +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -0,0 +1,268 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]]."]]"""]] + +[[!taglink open_issue_documentation]] + +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: + + <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 + dependency relations between those units(roughly, nothing too pedantic + for now) + <antrik> there is GNU Mach (the microkernel); there are the server + libraries in the Hurd package; there are the actual servers in the same; + and there is the POSIX implementation layer in glibc + <antrik> relations are a bit tricky + <antrik> Mach is the base layer which implements IPC and memory management + <foocraft> hmm I'll probably allocate time for dependency graph generation, + in the worst case + <antrik> on top of this, the Hurd servers, using the server libraries, + implement various aspects of the system functionality + <antrik> client programs use libc calls to use the servers + <antrik> (servers also use libc to communicate with other servers and/or + Mach though) + <foocraft> so every server depends solely on mach, and no other server? + <foocraft> s/mach/mach and/or libc/ + <antrik> I think these things should be pretty clear one you are somewhat + familiar with the Hurd architecture... nothing really tricky there + <antrik> no + <antrik> servers often depend on other servers for certain functionality + +--- + +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? + <antrik> I/O is presently completely in Mach + <antrik> filesystems are in userspace + <antrik> the root filesystem and exec server are loaded by grub + <dEhiN> o I see + <dEhiN> so in order to start hurd, you would have to start mach and + simultaneously start the root filesystem and exec server? + <antrik> not exactly + <antrik> GRUB loads all three, and then starts Mach. Mach in turn starts + the servers according to the multiboot information passed from GRUB + <dEhiN> ok, so does GRUB load them into ram? + <dEhiN> I'm trying to figure out in my mind how hurd is initially started + up from a low-level pov + <antrik> yes, as I said, GRUB loads them + <dEhiN> ok, thanks antrik...I'm new to the idea of microkernels, but a + veteran of monolithic kernels + <dEhiN> although I just learned that windows nt is a hybrid kernel which I + never knew! + <rm> note there's a /hurd/ext2fs.static + <rm> I belive that's what is used initially... right? + <antrik> yes + <antrik> loading the shared libraries in addition to the actual server + would be unweildy + <antrik> so the root FS server is linked statically instead + <dEhiN> what does the root FS server do? + <antrik> well, it serves the root FS ;-) + <antrik> it also does some bootstrapping work during startup, to bring the + rest of the system up + +--- + +Provide a cross-linked sources documentation, including generated files, like +RPC stubs. + + * <http://www.gnu.org/software/global/> + +--- + +[[Hurd_101]]. + +--- + +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 + +--- + +IRC, OFTC, #debian-hurd, 2011-11-02: + + <sekon_> is __dir_lookup a RPC ?? + <sekon_> where can i find the source of __dir_lookup ?? + <sekon_> grepping most gives out rvalue assignments + <sekon_> -assignments + <sekon_> but in hurs/fs.h it is used as a function ?? + <pinotree> it should be the mig-generated function for that rpc + <sekon_> how do i know how its implemented ?? + <sekon_> is there any way to delve deeprer into mig-generated functions + <tschwinge> sekon_: The MIG-generated stuff will either be found in the + package's build directory (if it's building it for themselves), or in the + glibc build directory (libhurduser, libmachuser; which are all the + available user RPC stubs). + <tschwinge> sekon_: The implementation can be found in the various Hurd + servers/libraries. + <tschwinge> sekon_: For example, [hurd]/libdiskfs/dir-lookup.c. + <tschwinge> sekon_: What MIG does is provide a function call interface for + these ``functions'', and the Mach microkernel then dispatches the + invocation to the corresponding server, for example a /hurd/ext2fs file + system (via libdiskfs). + <tschwinge> sekon_: This may help a bit: + http://www.gnu.org/software/hurd/hurd/hurd_hacking_guide.html + +--- + +IRC, freenode, #hurd, 2012-01-08: + + <abique> can you tell me how is done in hurd: "ls | grep x" ? + <abique> in bash + <youpi> ls's standard output is a port to the pflocal server, and grep x's + standard input is a port to the pflocal server + <youpi> the connexion between both ports inside the pflocal server being + done by bash when it calls pipe() + <abique> youpi, so STDOUT_FILENO, STDIN_FILENO, STDERR_FILENO still exists + ? + <youpi> sure, hurd is compatible with posix + <abique> so bash 1) creates T1 (ls) and T2 (grep), then create a pipe at + the pflocal server, then connects both ends to T1 and T2, then start(T1), + start(T2) ? + <youpi> not exactly + <youpi> it's like on usual unix, bash creates the pipe before creating the + tasks + <youpi> then forks to create both of them, handling them each side of the + pipe + <abique> ok I see + <youpi> s/handling/handing/ + <abique> but when you do pipe() on linux, it creates a kernel object, this + time it's 2 port on the pflocal ? + <youpi> yes + <abique> how are spawned tasks ? + <abique> with fork() ? + <youpi> yes + <youpi> which is just task_create() and duplicating the ports into the new + task + <abique> ok + <abique> so it's easy to rewrite fork() with a good control of duplicated + fd + <abique> about threading, mutexes, conditions, etc.. are kernel objects or + just userland objects ? + <youpi> just ports + <youpi> (only threads are kernel objects) + <abique> so, about efficiency, are pipes and mutexes efficient ? + <youpi> depends what you call "efficient" + <youpi> it's less efficient than on linux, for sure + <youpi> but enough for a workable system + <abique> maybe hurd is the right place for a userland thread library like + pth or any fiber library + <abique> ? + <youpi> hurd already uses a userland thread library + <youpi> libcthreads + <abique> is it M:N ? + <youpi> libthreads, actually + <youpi> yes + <abique> nice + <abique> is the task scheduler in the kernel ? + <youpi> the kernel thread scheduler, yes, of course + <youpi> there has to be one + <abique> are the posix open()/readdir()/etc... the direct vfs or wraps an + hurd layer libvfs ? + <youpi> they wrap RPCs to the filesystem servers + <antrik> the Bushnell paper is probably the closest we have to a high-level + documentation of these concepts... + <antrik> the Hurd does not have a central VFS component at all. name + lookups are performed directly on the individual FS servers + <antrik> that's probably the most fundamental design feature of the Hurd + <antrik> (all filesystem operations actually, not only lookups) + +IRC, freenode, #hurd, 2012-01-09: + + <braunr> youpi: are you sure cthreads are M:N ? i'm almost sure they're 1:1 + <braunr> and no modern OS is a right place for any thread userspace + library, as they wouldn't have support to run threads on different + processors (unless processors can be handled by userspace servers, but + still, it requires intimate cooperation between the threading library and + the kernel/userspace server in any case + <youpi> braunr: in libthreads, they are M:N + <youpi> you can run threads on different processors by using several kernel + threads, there's no problem in there, a lot of projects do this + <braunr> a pure userspace library can't use kernel threads + <braunr> at least pth was explacitely used on systems like bsd at a time + when they didn't have kernel threads exactly for that reason + <braunr> explicitely* + <braunr> and i'm actually quite surprised to learn that we have an M:N + threading model :/ + <youpi> why do you say "can't" ? + <braunr> but i wanted to reply to abique and he's not around + <youpi> of course you need kernel threads + <youpi> but all you need is to bind them + <braunr> well, what i call a userspace threading library is a library that + completely implement threads without the support of the kernel + <braunr> or only limited support, like signals + <youpi> errr, you can't implement anything with absolutely no support of + the kernel + <braunr> pth used only SIGALRM iirc + <youpi> asking for more kernel threads to use more processors doesn't seem + much + <braunr> it's not + <braunr> but i'm refering to what abique said + <braunr> 01:32 < abique> maybe hurd is the right place for a userland + thread library like pth or any fiber library + <youpi> well, it's indeed more, because the glibc lets external libraries + provide their mutex + <youpi> while on linux, glibc doesn't + <braunr> i believe he meant removing thread support from the kernel :p + <youpi> ah + <braunr> and replying "nice" to an M:N threading model is also suspicious, + since experience seems to show 1:1 models are better + <youpi> "better" ???? + <braunr> yes + <youpi> well + <youpi> I don't have any time to argue about that + <youpi> because that'd be extremely long + <braunr> simpler, so far less bugs, and also less headache concerning posix + conformance + <youpi> but there's no absolute "better" here + <youpi> but less performant + <youpi> less flexible + <braunr> that's why i mention experience :) + <youpi> I mean experience too + <braunr> why less performant ? + <youpi> because you pay kernel transition + <youpi> because you don't know anything about the application threads + <youpi> etc. + <braunr> really ? + <youpi> yes + <braunr> i fail to see where the overhead is + <youpi> I'm not saying m:n is generally better than 1:1 either + <youpi> thread switch, thread creation, etc. + <braunr> creation is slower, i agree, but i'm not sure it's used frequently + enough to really matter + <youpi> it is sometimes used frequently enough + <youpi> and in those cases it would be a headache to avoid it + <braunr> ok + <braunr> i thought thread pools were used in those cases + <youpi> synchronized with kernel mutexes ? + <youpi> that's still slow + <braunr> it reduces to the thread switch overhead + <braunr> which, i agree is slightly slower + <braunr> ok, i's a bit less performant :) + <braunr> well don't futexes exist just for that too ? + <youpi> yes and no + <youpi> in that case they don't help + <youpi> because they do sleep + <youpi> they help only when the threads are living + <braunr> ok + <youpi> now as I said I don't have to talk much more, I have to leave :) diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn b/open_issues/automatic_backtraces_when_assertions_hit.mdwn new file mode 100644 index 00000000..1cfacaf5 --- /dev/null +++ b/open_issues/automatic_backtraces_when_assertions_hit.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <azeem> tschwinge: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion `! __spin_lock_locked (&ss->critical_section_lock)' failed. + <youpi> it'd be great if we could have backtraces in such case + <youpi> at least just the function names + <youpi> and in this case (static), just addresses would be enough diff --git a/open_issues/automatically_checking_port_deallocation.mdwn b/open_issues/automatically_checking_port_deallocation.mdwn new file mode 100644 index 00000000..fb8cfd01 --- /dev/null +++ b/open_issues/automatically_checking_port_deallocation.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date. + + <youpi> we really need something that is able to automatically check port deallocation + <youpi> at least for the trivial cases, for which we do have bugs I'm currently fixing... + <pochu> test suite? :) + <pochu> won't magically find them though, so not what you've asked for... + <youpi> test suites can trigger some of the bugs yes + <youpi> which is already a good thing + <youpi> of course the coverage can't be perfect + <youpi> one of the bugs I fixed happened only for setuid binaries for instance diff --git a/open_issues/bash.mdwn b/open_issues/bash.mdwn new file mode 100644 index 00000000..47598071 --- /dev/null +++ b/open_issues/bash.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +# *bash* 4.0 vs. typing `C-c` (*SIGINT*) + +Will show `-bash: echo: write error: (ipc/mig) wrong reply message ID` unter +certain conditions. + +After having noticed that this error doesn't occur if starting *bash* with +`--norc`, I isolated it to the following command in `.bashrc`: + + case $TERM in + xterm* | rxvt*) + PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007"';; + esac + +... and indeed: + + tschwinge@flubber:~ $ echo "$TERM" -- "$PROMPT_COMMAND" + xterm -- echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007" + tschwinge@flubber:~ $ ^C + -bash: echo: write error: (ipc/mig) wrong reply message ID + tschwinge@flubber:~ $ PROMPT_COMMAND= + tschwinge@flubber:~ $ ^C + tschwinge@flubber:~ $ + + bash-4.0$ PROMPT_COMMAND='echo >&2 -n foo\ ' + foo bash-4.0$ ^C + + bash-4.0$ PROMPT_COMMAND='echo >&1 -n foo\ ' + foo bash-4.0$ ^C + bash: echo: write error: (ipc/mig) wrong reply message ID + + bash-4.0$ PROMPT_COMMAND='/bin/echo >&1 -n foo\ ' + foo bash-4.0$ ^C + bash: start_pipeline: pgrp pipe: (ipc/mig) wrong reply message ID + +So, there's something different with stdout in / after the SIGINT handler. diff --git a/open_issues/bash_busy-loop.mdwn b/open_issues/bash_busy-loop.mdwn new file mode 100644 index 00000000..5228ba33 --- /dev/null +++ b/open_issues/bash_busy-loop.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +I've first seen this problem after having had the following command line run +for a week, or two, or three: + +Start `screen`. Find PID of pfinet. + + $ while sleep 66; do echo "$(date)" " $(ps --no-header --format=hurd -p [PID])"; done | tee ps-pfinet + +Leave it running, detach from `screen`. + +Eventually, the main `bash` process will go bonkers and eat 100 % CPU time. +Reproduced on four different systems. + +A faster way to reproduce this, again inside `screen`; every three seconds, +write text in 10 MiB bursts to the terminal: + + $ while sleep 3; do date > tmp/tmp && yes "$(date)" | dd bs=1M count=10; done + +This one only needs like ten hours, before `bash` starts its busy-loop, from +which it can only be terminated with `SIGKILL`. At this point, the `term`, +`screen`, `fifo` processes also have used 40, 52, 25 minutes of CPU time, +respectively, but appear to be still working fine. + +I did not yet start debugging this. diff --git a/open_issues/bash_interrupted_system_call.mdwn b/open_issues/bash_interrupted_system_call.mdwn new file mode 100644 index 00000000..9feab6ff --- /dev/null +++ b/open_issues/bash_interrupted_system_call.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, unknown channel, unknown date. + + <virtuoso015> i seem to be getting this message from the shell "-bash: /dev/fd/62: Interrupted system call" + <virtuoso015> is it significant ? + <youpi> I've seen this issue already yes + <youpi> it's not + <youpi> it's bash not handling EINTR properly + <antrik> youpi: so this is actually a bug in bash, not Hurd generating a bogus error? + <youpi> well, it's Hurd generating an error which bash doesn't expect to see diff --git a/open_issues/bash_vs_screen_vs_sigint.mdwn b/open_issues/bash_vs_screen_vs_sigint.mdwn new file mode 100644 index 00000000..9672041c --- /dev/null +++ b/open_issues/bash_vs_screen_vs_sigint.mdwn @@ -0,0 +1,12 @@ +[[!meta copyright="Copyright © 2009 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]]."]]"""]] + + * [[bash]] + * [[screen]] diff --git a/open_issues/benefits_of_a_native_hurd_implementation.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn new file mode 100644 index 00000000..afdcfb73 --- /dev/null +++ b/open_issues/benefits_of_a_native_hurd_implementation.mdwn @@ -0,0 +1,132 @@ +[[!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 +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]] + +What are the benefits of a native GNU/Hurd system, now that Linux et al. can do +so much? Think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux +and other virtualization techiques, and so on. + +It is possible to begin [[implementing_Hurd_on_top_of_another_system]], but... + +IRC, #hurd, August / September 2010 + + <marcusb> ArneBab: but Neal and I were not happy with that alone. We were + looking for deeper improvements to the system, for, I think, sound + reasons. That is what brought us to the L4/Coyotos technologies + <marcusb> ArneBab: as you are writing a kernel in user space, you can still + do kernel improvements there + <marcusb> ArneBab: if you take it very far, you end up with a kernel that + 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]]. + + <marcusb> ArneBab: so, with these different cuts, there are different + opportunities. on the one end, you can run Linux as normal and get some + of the Hurd features such as translators in some programs. At the other + end, you can do whatever you want and run some linux code for the drivers + or none at all. + <marcusb> ArneBab: one of the big questions then becomes: at which point + can the advantages offered by the Hurd be realized? + <marcusb> ArneBab: and that's not entirely clear to me + <marcusb> when I worked on this with Neal, we pushed further and further + into need-to-change-everything land + <marcusb> while the current efforts on the Hurd seem to be more equivalent + to the could-run-it-in-userspace-on-top-of-Linux camp + <ArneBab> marcusb: for that I think we need a way to move towards them step + by step. Would it be possible to get the advantages of better resource + allocation with a Viengoos in userspace, too? + <ArneBab> and when that is stable, just switch over? + <marcusb> ArneBab: I don't know. I suspect these people will know before + us: http://lxc.sourceforge.net/ + <ArneBab> something like implementing flip points: flip Linux with Hurd to + Hund with Linux. Flip Mach with L4 to L4 with Mach. + <ArneBab> lxc sounds interesting. + <marcusb> note that these efforts address security concerns more than other + concerns + <marcusb> so they will get isolation long before sharing is even considered + <marcusb> but some of the issues are the same + <marcusb> once you allow malware to do what it wants, it's a small step to + also allow the user to what he wants :) + <ArneBab> it kinda looks like hacking it where it doesn’t really fit again… + <ArneBab> there I ask myself when the point comes that doing a cleaner + design offsets the popularity + <ArneBab> they are pushing more and more stuff into userspace + <ArneBab> which is a good thing (to me) + <ArneBab> it’s hard to clearly describe how, but even though I like having + more stuff in userspace, the way it is bolted onto Linux doesn’t feel + good for me. + <ArneBab> FUSE is cool, but if I use it, I am at a disadvantage compared to + a non-fuse user + <ArneBab> while in the Hurd, these additional options are on eqal footing. + <marcusb> ArneBab: are they pushing more and more into user space? I don't + think so. I see more of the reverse, actually + <marcusb> or maybe both + <ArneBab> FUSE, lxd and scheduling in userspace move to userspace + <ArneBab> well, KMS moved to the kernel + <ArneBab> to avoid flickering when switching between X and the console? + <ArneBab> marcusb: Do you experience FUSE lxc and such being secondclass in + Linux, too, or is that just a strange feeling of me? + <ArneBab> marcusb: and that splits the users into those who can get stuff + into the kernel and those who can only work in userspace – which I don’t + really like. + <ArneBab> That’s one more advantage of the Hurd: eqal footing for all + (except the Mach hackers, but they have a very limited terrain) + <marcusb> ArneBab: but UML kernel module is minimal, and Linus didn't have + a principled objection to it (but just wanted a more general solution) + <marcusb> ArneBab: as a side note, although people keep complaining, the + linux kernel seems to be growing steadily, so getting stuff into the + kernel doesn't seem too hard. 8-O + +--- + +IRC, #hurd, 2010-12-28 + + <tim> but is monolithic so bad? + <sartakov> yep + <braunr> no it's not + <braunr> proof: it works very well for most people + [...] + <braunr> the real problem is extensibility and interfaces + <tim> :/ whats the huge advantage of micro-k + <braunr> extensibility + <tim> over? + <braunr> you can add a whole lot of new services for new purposes with new + interfaces without changing the kernel + <tim> oright + <braunr> it basically boils down to the original Unix idea: everything does + one thing well + [...] + <kilobug> well, I would say extensibility and fault-tolerance are the two + key advantages + <braunr> taht's a side effect + <braunr> there are fault taulerant monolithic kernels + [...] + <braunr> tolerant* + <braunr> and the hurd is for now a non fault-tolerant microkernel based OS + :/ + [...] + <kilobug> braunr: not really; you can't ensure fault tolerance for code + running in kernel space, code running in kernel space can do everything, + including reboot, crash, ... + [...] + <braunr> kilobug: right, a monolithick kernel is less folt-tolerant than a + well designed/implemented microkernel based os + <kilobug> braunr: well, the Hurd is buggy nowadays, but things like an + ext2fs translator doing a segfault and being restarted is a + fault-tolerance that would be almost impossible to have in Linux + <kilobug> braunr: sure, you can have fault-tolerance with FUSE, but FUSE is + applying micro-kernel paradigm to Linux + [...] + <braunr> the reason i don't care that much about fault tolerance is that + Linux obviously shows a monolithic kernel can run almost flawlessly if + well written + <braunr> but extensibility is really another matter diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn new file mode 100644 index 00000000..8d6b3a94 --- /dev/null +++ b/open_issues/binutils.mdwn @@ -0,0 +1,205 @@ +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag stable_URL open_issue_binutils]] + +Here's what's to be done for maintaining GNU Binutils. + +As these tools primarily deal with low-level parts of the target architecture +and the object file format (ELF ABI), which are essentially (at least meant to +be) the same, there shouldn't be many differences comparing the binutils +between the GNU/Hurd and GNU/Linux ports, for example. There are a few, +though, as explained below. + +[[!toc levels=2]] + + +# [[General information|/binutils]] + + +# [[Sources|source_repositories/binutils]] + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..sourceware/master +-i +/^commit |^---$|hurd|linux|nacl + +--> + +Last reviewed up to the [[Git mirror's dde164167b2db4c05d58b1941d610beb6d5ca99f +(2012-06-08) sources|source_repositories/binutils]]. + + * Globally + + * a.out (such as `ld/emulparams/i386linux.sh`, `ld/emultempl/linux.em`, + etc.), COFF, PE image support and 64-bit support are not interesting. + + * In the testsuites, `.exp` and `.d` files very likely should not only + care for `*-*-linux*`, but also `*-*-gnu*`. (If they need to be + conditionalized like this at all.) + + * `bfd/` + + * `config.bfd` + + * `i[3-7]86-*-gnu*` + + Comparing to `i[3-7]86-*-linux-*`: + + * `i386linux_vec` -- a.out. + + * `i386pei_vec` -- PE. + + * 64 bit. + + * `configure.host` + + Souldn't need anything. x86 Linux neither. + + * `configure.in` + + Linux: + + * `COREFILE=trad-core.lo` with `TRAD_HEADER='"hosts/i386linux.h"'` + + We don't have any such core file support configured. TODO: should + we? Where is this core file reading exactly used? GDB? + + * `i386linux_vec` -- a.out. + + * `i386pei_vec` -- PE. + + * `binutils/` + + * `configure.tgt` + + * `gas/` + + * `config/te-gnu.h` + + C.f. `te-linux.h`; search tree for `TE_LINUX` vs. `TE_GNU` usage. + + * `tc-i386.h` + + Sole `TE_LINUX` usage is for a.out. + + * `configure.tgt` + + * `ld/` + + * `configure.host` + + * `*-*-gnu*` + + TODO: resolve `crt0.o` vs. `crt1.o` issue. [[Testsuite + failures|binutils#static]]. + + * `configure.tgt` + + * `i[3-7]86-*-gnu*` + + Compare to `i[3-7]86-*-linux-*`, but don't need a.out (`i386linux`) + and 64 bit support. + + +# Build + +Here's a log of a binutils build run; this is from our [[Git repository's +e1104996559067c40207c803ab1a5847a4a05145 (2012-06-07) +sources|source_repositories/binutils]], run on kepler.SCHWINGE and +coulomb.SCHWINGE. + + $ export LC_ALL=C + $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. + +This takes up around 120 MiB, and needs roughly 4 min on kepler.SCHWINGE and +15 min on coulomb.SCHWINGE. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && make -k check 2>&1 | tee log_check + +--> + + +## Analysis + +x86 GNU/Linux' and GNU/Hurd's configurations are slightly different, thus mask +out most of the differences that are due to GNU/Linux supporting more core file +formats, and more emulation vectors. + + $ ssh kepler.SCHWINGE 'cd tmp/source/binutils/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/binutils/linux/log_build + $ ssh coulomb.SCHWINGE 'cd tmp/binutils/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/binutils/hurd/log_build + $ diff -wu <(sed -f toolchain/logs/binutils/linux/log_build.sed < toolchain/logs/binutils/linux/log_build) <(sed -f toolchain/logs/binutils/hurd/log_build.sed < toolchain/logs/binutils/hurd/log_build) > toolchain/logs/binutils/log_build.diff + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around 70 MiB, and needs roughly 1 min on kepler.SCHWINGE and 3 +min on coulomb.SCHWINGE. + + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/binutils/ && cat hurd/master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/binutils/linux/log_install + $ ssh coulomb.SCHWINGE 'cd tmp/binutils/ && cat hurd/master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/binutils/hurd/log_install + $ diff -wu <(sed -f toolchain/logs/binutils/linux/log_install.sed < toolchain/logs/binutils/linux/log_install) <(sed -f toolchain/logs/binutils/hurd/log_install.sed < toolchain/logs/binutils/hurd/log_install) > toolchain/logs/binutils/log_install.diff + + * `libtool: finish`: `ldconfig` is not run for the Hurd. + + +# Testsuite + + $ make -k check + [...] + +This needs roughly 3 min on kepler.SCHWINGE and 13 min on coulomb.SCHWINGE. + + $ ssh kepler.SCHWINGE 'cd tmp/source/binutils/ && cat hurd/master.build/*/*.sum hurd/master.build/*/*/*.sum | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/binutils/linux/sum + $ ssh coulomb.SCHWINGE 'cd tmp/binutils/ && cat hurd/master.build/*/*.sum hurd/master.build/*/*/*.sum | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/binutils/hurd/sum + $ diff -u -F ^Running toolchain/logs/binutils/linux/sum toolchain/logs/binutils/hurd/sum > toolchain/logs/binutils/sum.diff + + +## Analysis + + * <a name="static"><!-- stable_URL -->`FAIL: static [...]`</a> + + The testsuite isn't prepared for using `crt0.o` instead of `crt1.o` + depending on whether a static or dynamic executable is created. Documented + in `ld/configure.host`. Perhaps we should finally rewrite this messy code + in glibc? + + * <a name="64ksec">`FAIL: ld-elf/64ksec`</a> + + On the idle grubber, this one takes a few minutes wall time to complete + successfully ([[I/O system + weakness|performance/io_system/binutils_ld_64ksec]]), so assuming some + system load variation, the testsuite's timeout may trigger. + + * <a name="weak"><!-- stable_URL -->`FAIL: ELF weak [...]`</a> + + [[I|tschwinge]] suppose this is due to us having an override w.r.t. weak + symbol handling in glibc, needed for our external [[/libpthread]]. TODO: + document properly. diff --git a/open_issues/binutils_gold.mdwn b/open_issues/binutils_gold.mdwn new file mode 100644 index 00000000..9eeebf2d --- /dev/null +++ b/open_issues/binutils_gold.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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_binutils open_issue_porting]] + +Have a look at gold / port as needed. + +Apparently it needs [[glibc/mremap]]. diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn new file mode 100644 index 00000000..6ab39b2e --- /dev/null +++ b/open_issues/boehm_gc.mdwn @@ -0,0 +1,437 @@ +[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Here's what's to be done for maintaining Boehm GC. + +This one does need Hurd-specific configuration. + +It is, for example, used by [[/GCC]] (which has its own fork), so any changes +committed upstream should very like also be made there. + +[[!toc levels=2]] + + +# [[General information|/boehm_gc]] + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..upstream/master +-i +/^commit |^---$|hurd|linux|glibc + +--> + +Last reviewed up to the 5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08) +sources, and for `libatomic_ops` to the +6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15) sources. + + * `configure.ac` + + * `PARALLEL_MARK` is not enabled; doesn't make sense so far. + + * `*-*-kfreebsd*-gnu` defines `USE_COMPILER_TLS`. What's this, and + why does not other config? + + * TODO + + [ if test "$enable_gc_debug" = "yes"; then + AC_MSG_WARN("Should define GC_DEBUG and use debug alloc. in clients.") + AC_DEFINE([KEEP_BACK_PTRS], 1, + [Define to save back-pointers in debugging headers.]) + keep_back_ptrs=true + AC_DEFINE([DBG_HDRS_ALL], 1, + [Define to force debug headers on all objects.]) + case $host in + x86-*-linux* | i586-*-linux* | i686-*-linux* | x86_64-*-linux* ) + AC_DEFINE(MAKE_BACK_GRAPH) + AC_MSG_WARN("Client must not use -fomit-frame-pointer.") + AC_DEFINE(SAVE_CALL_COUNT, 8) + ;; + AM_CONDITIONAL([KEEP_BACK_PTRS], [test x"$keep_back_ptrs" = xtrue]) + + * `configure.host` + + Nothing. + + * `Makefile.am`, `include/include.am`, `cord/cord.am`, `doc/doc.am`, + `tests/tests.am` + + Nothing. + + * `include/gc_config_macros.h` + + Should be OK. + + * `include/private/gcconfig.h` + + Hairy. But should be OK. Search for *HURD*, compare to *LINUX*, + *I386* case. + + See `doc/porting.html` and `doc/README.macros` (and others) for + documentation. + + *LINUX* has: + + * `#define LINUX_STACKBOTTOM` + + Defined instead of `STACKBOTTOM` to have the value read from `/proc/`. + + * `#define HEAP_START (ptr_t)0x1000` + + May want to define it for us, too? + + * `#ifdef USE_I686_PREFETCH`, `USE_3DNOW_PREFETCH` --- [...] + + Apparently these are optimization that we also could use. Have a + look at *LINUX* for *X86_64*, which uses `__builtin_prefetch` + (which Linux x86 could use, too?). + + * TODO + + #if defined(LINUX) && defined(USE_MMAP) + /* The kernel may do a somewhat better job merging mappings etc. */ + /* with anonymous mappings. */ + # define USE_MMAP_ANON + #endif + + * TODO + + #if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC) + /* Nptl allocates thread stacks with mmap, which is fine. But it */ + /* keeps a cache of thread stacks. Thread stacks contain the */ + /* thread control blocks. These in turn contain a pointer to */ + /* (sizeof (void *) from the beginning of) the dtv for thread-local */ + /* storage, which is calloc allocated. If we don't scan the cached */ + /* thread stacks, we appear to lose the dtv. This tends to */ + /* result in something that looks like a bogus dtv count, which */ + /* tends to result in a memset call on a block that is way too */ + /* large. Sometimes we're lucky and the process just dies ... */ + /* There seems to be a similar issue with some other memory */ + /* allocated by the dynamic loader. */ + /* This should be avoidable by either: */ + /* - Defining USE_PROC_FOR_LIBRARIES here. */ + /* That performs very poorly, precisely because we end up */ + /* scanning cached stacks. */ + /* - Have calloc look at its callers. */ + /* In spite of the fact that it is gross and disgusting. */ + /* In fact neither seems to suffice, probably in part because */ + /* even with USE_PROC_FOR_LIBRARIES, we don't scan parts of stack */ + /* segments that appear to be out of bounds. Thus we actually */ + /* do both, which seems to yield the best results. */ + + # define USE_PROC_FOR_LIBRARIES + #endif + + * TODO + + # if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC) \ + && !defined(INCLUDE_LINUX_THREAD_DESCR) + /* Will not work, since libc and the dynamic loader use thread */ + /* locals, sometimes as the only reference. */ + # define INCLUDE_LINUX_THREAD_DESCR + # endif + + * TODO + + # if defined(UNIX_LIKE) && defined(THREADS) && !defined(NO_CANCEL_SAFE) \ + && !defined(PLATFORM_ANDROID) + /* Make the code cancellation-safe. This basically means that we */ + /* ensure that cancellation requests are ignored while we are in */ + /* the collector. This applies only to Posix deferred cancellation;*/ + /* we don't handle Posix asynchronous cancellation. */ + /* Note that this only works if pthread_setcancelstate is */ + /* async-signal-safe, at least in the absence of asynchronous */ + /* cancellation. This appears to be true for the glibc version, */ + /* though it is not documented. Without that assumption, there */ + /* seems to be no way to safely wait in a signal handler, which */ + /* we need to do for thread suspension. */ + /* Also note that little other code appears to be cancellation-safe.*/ + /* Hence it may make sense to turn this off for performance. */ + # define CANCEL_SAFE + # endif + + * `CAN_SAVE_CALL_ARGS` vs. -fomit-frame-pointer now being on by + default for Linux x86 IIRC? (Which is an [[!taglink + open_issue_gcc]] for not including us.) + + * TODO + + # if defined(REDIRECT_MALLOC) && defined(THREADS) && !defined(LINUX) + # error "REDIRECT_MALLOC with THREADS works at most on Linux." + # endif + + + *HURD* has: + + * `#define STACK_GROWS_DOWN` + + * `#define HEURISTIC2` + + Defined instead of `STACKBOTTOM` to have the value probed. + + Linux also has this: + + #if defined(LINUX_STACKBOTTOM) && defined(NO_PROC_STAT) \ + && !defined(USE_LIBC_PRIVATES) + /* This combination will fail, since we have no way to get */ + /* the stack base. Use HEURISTIC2 instead. */ + # undef LINUX_STACKBOTTOM + # define HEURISTIC2 + /* This may still fail on some architectures like IA64. */ + /* We tried ... */ + #endif + + Being on [[glibc]], we could perhaps do similar as `USE_LIBC_PRIVATES` + instead of `HEURISTIC2`. Pro: avoid `SIGSEGV` (and general fragility) + during probing at startup (if I'm understanding this correctly). Con: + rely on glibc internals. Or we instead add support to parse + [[`/proc/`|hurd/translator/procfs]] (can even use the same as Linux?), + or use some other interface. [[!tag open_issue_glibc]] + + * `#define SIG_SUSPEND SIGUSR1`, `#define SIG_THR_RESTART SIGUSR2` + + * We don't `#define MPROTECT_VDB` (WIP comment); but Linux neither. + + * Where does our `GETPAGESIZE` come from? Should we `#include + <unistd.h>` like it is done for *LINUX*? + + * `include/gc_pthread_redirects.h` + + * TODO + + Cancellation stuff is Linux-only. In other places, too. + + * `mach_dep.c` + + * `#define NO_GETCONTEXT` + + [[!taglink open_issue_glibc]], but this is not a real problem here, + because we can use the following GCC internal function without much + overhead: + + * `GC_with_callee_saves_pushed` + + The `HAVE_BUILTIN_UNWIND_INIT` case is ours. + + * `os_dep.c` + + * `read` + + Sure that it doesn't internally (in [[glibc]]) use `malloc`. Probably + only / mostly (?) a problem for `--enable-redirect-malloc` + configurations? Linux with threads uses `readv`. + + * TODO. + + * `dyn_load.c` + + For `DYNAMIC_LOADING`. TODO. + + * `pthread_support.c`, `pthread_stop_world.c` + + TODO. + + * TODO. + + Other files also contain *LINUX* and other conditionals. + + * `libatomic_ops/` + + * `configure.ac` + + Nothing. + + * `Makefile`, `src/Makefile`, `src/atomic_ops/Makefile`, + `src/atomic_ops/sysdeps/Makefile`, `doc/Makefile`, `tests/Makefile` + + Nothing. + + * `src/atomic_ops/sysdeps/gcc/x86.h` + + Nothing. + + * b8b65e8a5c2c4896728cd00d008168a6293f55b1 configure.ac probably not all + correct. + + * `mmap`, b64dd3bc1e5a23e677c96b478d55648a0730ab75 + + * `parallel mark`, 07c2b8e455c9e70d1f173475bbf1196320812154, pass + `--disable-parallel-mark` or enable for us, too? + + * `HANDLE_FORK`, e9b11b6655c45ad3ab3326707aa31567a767134b, + 806d656802a1e3c2b55cd9e4530c6420340886c9, + 1e882b98c2cf9479a9cd08a67439dab7f9622924 + + * Check `include/private/thread_local_alloc.h` re + `USE_COMPILER_TLS`/`USE_PTHREAD_SPECIFIC`. + + +# Build + +Here's a log of a binutils build run; this is from the +5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08) sources, and for +`libatomic_ops` for the 6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15) +sources, run on kepler.SCHWINGE and coulomb.SCHWINGE. + + $ export LC_ALL=C + $ (cd ../master/ && ln -sfn ../libatomic_ops/master libatomic_ops) + $ (cd ../master/ && autoreconf -vfi) + $ ../master/configure --prefix="$PWD".install SHELL=/bin/bash CC=gcc-4.6 CXX=g++-4.6 --enable-cplusplus --enable-gc-debug --enable-gc-assertions --enable-assertions 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. Using bash instead of dash as otherwise libtool explodes. + +This takes up around X MiB, and needs roughly X min on kepler.SCHWINGE and +X min on coulomb.SCHWINGE. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && { make -k check 2>&1 | tee log_check; (cd libatomic_ops/ && make -k check) 2>&1 | tee log_check_; } + +--> + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_build + $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_build + $ diff -wu <(sed -f toolchain/logs/boehm-gc/linux/log_build.sed < toolchain/logs/boehm-gc/linux/log_build) <(sed -f toolchain/logs/boehm-gc/hurd/log_build.sed < toolchain/logs/boehm-gc/hurd/log_build) > toolchain/logs/boehm-gc/log_build.diff + + * only GNU/Linux: `configure: WARNING: "Explicit GC_INIT() calls may be + required."` + + * only GNU/Linux: `configure: WARNING: "Client must not use + -fomit-frame-pointer."` + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around X MiB, and needs roughly X min on kepler.SCHWINGE and X +min on coulomb.SCHWINGE. + + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_install + $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_install + $ diff -wu toolchain/logs/boehm-gc/linux/log_install toolchain/logs/boehm-gc/hurd/log_install > toolchain/logs/boehm-gc/log_install.diff + + +# Testsuite + + $ make -k check + [...] + $ (cd libatomic_ops/ && make -k check) + [...] + +This needs roughly X min on kepler.SCHWINGE and X min on coulomb.SCHWINGE. + + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_check* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_check + $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_check* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_check + $ diff -wu <(sed -f toolchain/logs/boehm-gc/linux/log_check.sed < toolchain/logs/boehm-gc/linux/log_check) <(sed -f toolchain/logs/boehm-gc/hurd/log_check.sed < toolchain/logs/boehm-gc/hurd/log_check) > toolchain/logs/boehm-gc/log_check.diff + +There are different configurations possible, but in general, the testsuite +restults of GNU/Linux and GNU/Hurd look very similar. + + * GNU/Hurd is missing `Call chain at allocation: [...]` output. + + `os_dep.c`:`GC_print_callers` + + +# TODO + + * Port stuff to [[GCC]], and test it there. + + * What are other applications to test Boehm GC? Also especially in + combination with [[/libpthread]] and dynamic loading of shared libraries? + + * There are patches (apparently not committed) that GCC itself can use + it, too: <http://gcc.gnu.org/wiki/Garbage_collection_tuning>. + + * There's been some talking about it on GNU guile mailing lists, and two + Git branches (2010-12-15: last change 2009-09). + + * <http://www.hpl.hp.com/personal/Hans_Boehm/gc/#users> + + +## IRC, OFTC, #debian-hurd, 2012-02-05 + +[[!tag open_issue_porting]] + + <pinotree> youpi: i think i found out the possible cause of the ecl and + mono issuess + <pinotree> -s + <youpi> oh + <pinotree> basically, we don't have the realtime signals (so no + SIGRTMIN/SIGRTMAX defined), hence things use either SIGUSR1 or + SIGUSR2... which are used in libgc to resp. stop/resume threads when + "collecting" + <pinotree> i just patched ecl to use SIGINFO instead of SIGUSR1 (used when + no SIGRTMIN+2 is available), and it seems going on for a while + <youpi> uh, why would SIGINFO work better than SIGUSR1? + <pinotree> it was a test, i tried the first "not common" signal i saw + <pinotree> my test was, use any signal different than USR1/2 + <youpi> ah, sorry, I hadn't understood + <youpi> you mean there's a conflict between ecl and mono using SIGUSR1, as + well as libgc? + <pinotree> yes + <pinotree> for example, in ecl sources see src/c/unixint.d, + install_process_interrupt_handler() + <youpi> SIGINFO seems a sane choice + <youpi> SIGPWR could have been a better choice if it was available :) + <pinotree> i would have chose an "unassigned" number, say SIGLOST (the + bigger one) + 10, but it would be greater than _NSIG (and thus discarded) + <youpi> not a good idea indeed + <pinotree> it seems that linux, beside the range for rt signals, has some + "free space" + <pinotree> i'll start now another ecl build, from scratch this time, with + s/SIGUSR1/SIGINFO/ (making sure ctags won't bother), and if it works i'll + update svante's bug + + <pinotree> mmap(...PROT_NONE...) failed + <pinotree> hmm... + <pinotree> apparently enabling MMAP_ANON in mono's libgc copy was a good + step, let's see + + +### IRC, OFTC, #debian-hurd, 2012-03-18 + + <pinotree> youpi: mono is afflicted by the SIGUSR1/2 conflict with libgc + <youpi> pinotree: didn't we have a solution for that? + <pinotree> well, it works just for one signal + <pinotree> the ideal solution would be having a range for RT signals, and + make libgc use RTMIN+5/6, like done on most of other OSes + <youpi> but we don't have RT signals, do we? + <pinotree> right :( + + +### IRC, freenode, #hurd, 2012-03-21 + + <pinotree> civodul: given we have to realtime signals (so no range of + signals for them), libgc uses SIGUSR1/2 instead of using SIGRTMIN+5/6 for + its thread synchronization stuff + <pinotree> civodul: which means that if an application using libgc then + sets its own handlers for either of SIGUSR1/2, hell breaks + <civodul> pinotree: ok + <civodul> pinotree: is it a Debian-specific change, or included upstream? + <pinotree> libgc using SIGUSR1/2? upstream + <civodul> ok diff --git a/open_issues/bpf.mdwn b/open_issues/bpf.mdwn new file mode 100644 index 00000000..e24d761b --- /dev/null +++ b/open_issues/bpf.mdwn @@ -0,0 +1,587 @@ +[[!meta copyright="Copyright © 2009, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title=BPF]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +This is a collection of resources concerning *Berkeley Packet Filter*s. + + +# Documentation + + * Wikipedia: [[!wikipedia "Berkeley Packet Filter"]] + + * [The Packet Filter: An Efficient Mechanism for User-level Network + Code](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.8755), + 1987, Jeffrey C. Mogul, Richard F. Rashid, Michael J. Accetta + + * [The BSD Packet Filter: A New Architecture for User-level Packet + Capture](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.7849), + 1992, Steven Mccanne, Van Jacobson + + * [Protocol Service Decomposition for High-Performance + Networking](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.8387), + 1993, Chris Maeda, Brian N. Bershad + + * [Efficient Packet Demultiplexing for Multiple Endpoints and Large + Messages](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.44), + 1994, Masanobu Yuhara Fujitsu, Masanobu Yuhara, Brian N. Bershad, Chris + Maeda, J. Eliot, B. Moss + + * ... and many more + + +# Implementation + + * [[community/HurdFr]] + + * <http://wiki.hurdfr.org/index.php/BPF> + + * <http://wiki.hurdfr.org/index.php/Reseau_dans_gnumach> + + * Git repository: <http://rcs-git.duckcorp.org/hurdfr/bpf.git/> + + The patch for [[GNU Mach|microkernel/mach/gnumach]] is expected to be + complete and functional, the [[hurd/translator]] less so -- amongst others, + there are unresolved issues concerning support of [[hurd/glibc/IOCTL]]s. + + * <http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html> + + * [[zhengda]] + + * [[!GNU_Savannah_bug 25054]] -- Kernel panic with eth-multiplexer + + * [[!GNU_Savannah_patch 6619]] -- pfinet uses the virtual interface + + * [[!GNU_Savannah_patch 6620]] -- pfinet changes its filter rules with + its IP address + + * [[!GNU_Savannah_patch 6621]] -- pfinet sets the mach device into the + promiscuous mode + + * [[!GNU_Savannah_patch 6622]] -- pfinet uses the BPF filter + + * [[!GNU_Savannah_patch 6851]] -- fix a bug in BPF + + +# IRC + +## IRC, freenode, #hurd, 2012-01-13 + + <braunr> hm, i think the bpf code needs a complete redesign :p + <braunr> unless it's actually a true hurdish way to do things + <braunr> antrik: i need your help :) + <braunr> antrik: I need advice on the bpf "architecture" + <braunr> the current implementation uses a translator installed at /dev/bpf + <braunr> which means packets from the kernel are copied to that translator + and then to client applications + <braunr> does that seem ok to you ? + <braunr> couldn't the translator be used to set a direct link between the + kernel and the client app ? + <braunr> which approach seems the more Hurdish to you ? (<= this is what I + need your help on) + <pinotree> braunr: so there would be a roundtrip like kernel → bpf + translator → pfinet? + <antrik> braunr: TBH, I don't see why we need a BPF translator at all... + <braunr> antrik: it handles the ioctls + <braunr> pinotree: pfinet isn't involved (it was merely modified to use the + "new" filter format to specify it used the old packet filter, and not + bpf) + <antrik> braunr: do we really need to emulate the ioctl()s? can't we assume + that all packages using BPF will just use libpcap? + <antrik> (and even if we *do* want to emulate ioctl()s, why can't we handle + this is libc?) + <braunr> antrik: that's what i'm wondering actually + <braunr> even if assuming all packages use libpcap, i'd like our bpf + interface to be close to what bsds have, and most importantly, what + libpcap expects from a bpf interface + <antrik> well, why? if we already have a library handling the abstraction, + I don't see much point in complicating the design and use by adding + another layer :-) + <braunr> so you would advise adapting libpcap to include a hurd specific + module ? + <antrik> there are two reasons for adding translators: more robustness or + more flexibility... so far I don't see how a BPF translator would add + either + <braunr> right + <antrik> yes + <braunr> so we'd end up with a bpf-like interface, the same instructions + and format, with different control calls + <antrik> right + <antrik> note that I had more or less the same desicion to make for KGI + (emulate Linux/BSD ioctl()s, or implement a backend in libggi for + handling Hurd-specific RPC; and after much consideration, I decided on + the latter) + + +## IRC, freenode, #hurd, 2012-01-16 + + <braunr> antrik: is there an existing facility to easily give a send right + to the device master port to a task ? + <braunr> another function of the bpf translator is to handle the /dev/bpf + node, and most importantly its permissions + <braunr> so that users which have read/write access to the node have access + to the packet filter + <braunr> i guess the translator could limit itself to that functionality + <braunr> and then provide a device port on which libpcap operates directly + by means of device_{g,s}et_status/device_set_filter + <antrik> braunr: I don't see the point in seperating permissions for filter + from permissions from general network device access... + <antrik> as for device master port, all root tasks can obtain it from proc + IIRC + <braunr> antrik: yes, but how do we allow non-root users to access that + facility ? + <braunr> on a unix like system, it's a matter of changing the permissions + of /dev/bpf + <antrik> with devnode, non-root users can get access to specific device + nodes, including network devices + <braunr> i can't imagine the hurd being less flexible for that + <braunr> ah devnode + <braunr> good + <antrik> so we can for example make /dev/eth0 accessible by users of some + group + <braunr> what's devnode exactly ? + <antrik> it's a very simple translator that implements an FS node that + looks somewhat like a file, but the only operation it supports is + obtaining a pseudo device master port, giving access to a specific Mach + device + <braunr> is it already part of the hurd ? + <braunr> or hurdextras maybe ? + <antrik> it's only in zhengda's branch + <braunr> ah + <antrik> needed for both eth-multipexer and DDE + <braunr> and bpf soon i guess + <antrik> indeed :-) + <braunr> "obtaining a pseudo device master port", i believe you meant a + pseudo device port + <antrik> I must admit that I don't remember exactly whether devnode proxies + device_open(), so clients direct get a port to the device in question, or + whether it implements a pseudo device master port... + <antrik> but definitely not a pseudo device port :-) + <braunr> i'm almost positive it gives the target device port, otherwise i + don't see the point + <braunr> i don't understand the user of the "pseudo" word here either + <braunr> s/user/use/ + <braunr> aiui, devnode should be started as root (or in any way which gives + it the device master port) + <antrik> the point is that the client doesn't need to know the Mach device + name, and also is not bound to actual kernel devices + <braunr> and when started, implement the required permissions before giving + clients a device port to the specific device it was installed for + <braunr> right + <braunr> but it mustn't be a proxy + <antrik> yes, devnode needs access to either the real master device port + (for kernel devices), or one provided by eth-multiplexer or the DDE + network driver + <braunr> well, a very simple proxy for deviceopen + <braunr> ok + <braunr> that seems exactly what i wanted to do + <braunr> we now need to see if we can integrate it separately + <braunr> create a separate branch that works for the current gnumach code, + and merge dde/other specific code later on + <antrik> you mean independent of eth-multiplexer or DDE? yes, it was + generally agreed that devnode is a good idea in any case. I have no idea + why there are no device nodes for network devices on other UNIX + systems... + <braunr> i've been wondering that for years too :) + <antrik> zhengda's branch has a pfinet modified to a) use devnode, and b) + use BPF + <braunr> why bpf ? + <braunr> for more specific filters maybe ? + <antrik> hm... don't remember whether there was any technical reason for + going with BPF; I guess it just seemed more reasonable to invest new work + in BPF rather than obsolete Mach-specific NPF... + <braunr> cspf could be removed altogether, i agree + <antrik> another plus side of his modified pfinet is that it actually sets + an appropriate filter for TCP/IP and the IP in use, rather than just + setting a dummy filter catching app packets (including those irrelevant + to the specific pfinet instance) + <antrik> err... catching all packets + <braunr> that's what i meant by "for more specific filters maybe ?" + <braunr> he was probably more comfortable with the bpf interface to write + his filter rules + <antrik> well, it would probably be doable with NPF too :-) so by itself + it's not a reason for switching to BPF... + <antrik> it's rather the other way around: as it was necessary to implement + filters in eth-multiplexer, and implementing BPF seemed more reasoable, + pfinet had to be changed to use BPF... + <braunr> antrik: where is zhengda's branch btw ? + <antrik> (I guess using proper filters with eth-multiplexer is not strictly + necessary; but it would be a major performance hit not to) + <antrik> it's in incubator.git + <antrik> but it's very messy + <braunr> ok + <antrik> at some point I asked him to provide cleaned up branches, and I'm + pretty sure he said he did, but I totally fail to remember where he + published them :-( + <braunr> hm, i don't like how devnode is "architectured" :/ + <braunr> but it makes things a little more easy to get working i guess + <LarstiQ> antrik: any idea what to grep the logs on for that? + <braunr> ok never mind, devnode is fine + <braunr> exactly what i need + <braunr> i wonder however if it shouldn't be improved to better handle + permissions + <braunr> ok, never mind either, permission handling is fine + <braunr> so what are we waiting for ? :) + <antrik> I remember that there were some issues with permission handling, + but I don't remember whether all were fixed :-( + <antrik> LarstiQ: hm... good question... + <braunr> ah ? + <braunr> hm actually, there could be issues for packet filters, yes + <braunr> i guess we want to allow e.g. read-only opens for capture only + <antrik> braunr: that would have to be handled by the actual BPF + implementation I'd say + <braunr> it should already be the case + <antrik> what's the problem then? + <braunr> but when the actual device_open() is performed, the appropriate + permissions must be provided + <braunr> and checking those is the responsibility of the proxy, devnode in + this case + <antrik> and it doesn't do that? + <braunr> apparently not + <braunr> the only check is against the device name + <braunr> i'll begin playing with that first + <antrik> I vaguely remember that there has been discussion about the + relation of underlying device open mode and devnode open mode... but I + don't remember the outcome. in fact it was probably one of the + discussions I never got around to follow up on... :-( + <antrik> before you begin playing, take a look at the relevant messages in + the ML archive :-) + <antrik> must have been around two years ago + <braunr> ok + <antrik> some thread with me and scolobb (Sergiu Ivanov +- spelling) and + probably zhengda + <antrik> there might also be some outstanding patch(es) from scolobb, not + sure + + +## IRC, freenode, #hurd, 2012-01-17 + + <braunr> antrik: i think i found the thread you mentioned about devnode + <braunr> neither sergiu nor zhengda considered the use of a read-only + device for packet filtering + <braunr> leading to assumptions such as "only receiving packets + <braunr> is not terribly useful, in view of the fact that you have to at + least + <braunr> request them, which implies *sending* packets :-) + <braunr> " + <braunr> IMO, devnode should definitely check its node permissions to build + the device open flags + <braunr> good news is that it doesn't depend on anything specific to other + incubator projects + <braunr> making it almost readily mergeable in the hurd + <braunr> i'm not sure devnode is an appropriate name though + <braunr> maybe something like device, or devproxy + <braunr> proxy-devopen maybe + <antrik> braunr: well, I don't remember the details of the disucssion; but + as I mentioned in some mail, I did actually want to write a followup, + just didn't get around to it... so I was definitely not in agreement with + some of the statements made by others. I just don't remember on which + point :-) + <antrik> which thread was it? + <antrik> anyways, this should in no way be specific to network + devices... the idea is simply that if the client has only read + permissions on the device node, it should only get to open the underlying + device for read. it's up to the kernel to handle the read-only status for + the device once it's opened + <antrik> as for the naming, the idea is that devnode simply makes Mach + devices accessible through FS nodes... so the name seemed appropriate + <antrik> you may be right though that just "device" might be more + straightforward... I don't agree on the other variants + <braunr> antrik: + http://lists.gnu.org/archive/html/bug-hurd/2009-12/msg00155.html + <braunr> antrik: i agree with the general idea behind permission handling, + i was just referring to their thoughts about it, which probably led to + the hard coded READ | WRITE flags + <antrik> braunr: unfortunately, I don't remember the context of the + discussion... would take me a while to get into this again :-( + <antrik> the discussion seems to be about eth-multiplexer as much as about + devnode (if not more), and I don't remember the exact interaction + + +## IRC, freenode, #hurd, 2012-01-18 + + <braunr> so, does anyone have an objection to getting devnode into the hurd + and calling it something else like e.g. device ? + <youpi> braunr: it's Zhengda's work, right? + <braunr> yes + <youpi> I'm completely for it, it just perhaps needs some cleanup + <braunr> i have a few changes to add to what already exists + <braunr> ok + <braunr> well i'm assigning myself to the task + <antrik> braunr: I'm still not convinced just "device" is preferable + <antrik> perhaps machdevice ;-) + <antrik> but otherwise, I'd LOVE to see it in :-) + <braunr> i don't know .. what if the device is actually eth-multiplexer or + a dde one ? + <braunr> it's not really "mach", is it ? + <braunr> or do we only refer to the interface ? + <youpi> that translator is only for mach devices + <braunr> so you consider dde devices as being mach devices too ? + <braunr> it's a simple proxy for device_open really + <youpi> will these devices use that translator? + <youpi> ah + <youpi> I thought it was using a mach-specific RPC + <braunr> so we can consider whatever we want + <antrik> braunr: yes, the translator is for Mach device interface only. it + might be provided by other servers, but it's still Mach devices + <youpi> then drop the mach, yes + <braunr> i'd tend to agree with antrik + <youpi> antrik: I'd say the device interface is part of the hur dinterfaces + <braunr> then machdev :p + <braunr> no, it's really part of the mach interface + <youpi> it's part of the mach interface, yes + <youpi> but also of the Hurd, no? + <antrik> DDE network servers also use the Mach device interface + <braunr> no + <youpi> can't we say it's part of it? + <youpi> I mean + <youpi> even if we change the kernel + <braunr> dde is the only thing that implements it besides the kernel that i + know of + <youpi> we will probably want to keep the same interface + <braunr> yes but that's a mach thing + <youpi> what we have now is not necessarily a reason + <antrik> as for other DDE drivers, I for my part believe they should export + proper Hurd (UNIX) device nodes directly... but for some reason zhengda + insisted on implementing it as Mach devices too :-( + <braunr> antrik: i agree with you on that too + <braunr> i was a bit surprised to see the same interface was reused + <braunr> youpi: we can, we just have to agree on what we'll do + <braunr> what do you mean by "even if we change the kernel" ? + <antrik> the problem with "machdev" is that it might suggest the translator + actually implements the device... not sure whether this would cause + serious confusion + <antrik> "devopen" might be another option + <antrik> or "machdevopen" to be entirely verbose ;-) + <braunr> an option i suggested earlier which you disagreed on :p + <braunr> but devopen is the one i'd choose + <antrik> youpi: as I already mentioned in the libburn thread, I don't + actually think the Mach device interface is very nice; IMHO we should get + rid of it as soon as we can, rather than port it to other + architectures... + <antrik> but even *if* we decided to reuse it after all, it would still be + the Mach device interface :-) + <braunr> actually, zheng da already suggested that name a long time ago + <braunr> http://lists.gnu.org/archive/html/bug-hurd/2008-08/msg00005.html + <braunr> no actually antrik did eh + <braunr> ok let's use devopen + <antrik> braunr: you suggested proxy-devopen, which I didn't like because + of the "proxy" part :-) + <braunr> not only, but i don't have the logs any more :p + <antrik> oh, I already suggested devopen once? didn't expect myself to be + that consistent... ;-) + <antrik> braunr: you suggested device, devproxy or proxy-devopen + <braunr> ah, ok + <braunr> devopen is better + <antrik> I wonder whether it's more important for clarity to have "mach" in + there or "open"... or whether it's really too unweildy to have both + + +## IRC, freenode, #hurd, 2012-01-21 + + <braunr> oh btw, i made devopen run today, it shouldn't be hard getting it + in properly + <braunr> patching libpcap will be somewhat trickier + <braunr> i don't even really need it, but it allows having user access to + mach devices, which is nice for the libpcap patch and tcpdump tests + <braunr> permission checking is actually its only purpose + <braunr> well, no, not really, it also allows opening devices implemented + by user space servers transparently + + +## IRC, freenode, #hurd, 2012-01-27 + + <braunr> hmm, bpf needs more work :( + <braunr> or we can use the userspace bpf filter in libpcap, so that it + works with both gnumach and dde drivers + <antrik> braunr: there is a userspace BPF implementation in libpcap? I'm + surprised that zhengda didn't notice it, and ported the one from gnumach + instead... + <antrik> what is missing in the kernel implementation? + <braunr> antrik: filling the bpf header + <braunr> frankly, i'm not sure we want to bother with the kernel + implementation + <braunr> i'd like it to work with both gnumach and dde drivers + <braunr> and in the long run, we'll be using userspace drivers anyway + <braunr> the bpf header was one of the things the defunct translator did + <braunr> which involved ugly memcpy()s :p + <antrik> braunr: well, if you want to get rid of the kernel implementation, + basically you would have to take up eth-multiplexer and get it into + mainline + <antrik> (and make sure it's used by default in Debian) + <antrik> I frankly believe it's the better design anyways... but quite a + major change :-) + <braunr> not that major to me + <braunr> in the meantime i'll use the libpcap embedded implementation + <braunr> we'll have something useful faster, with minimum work when + eth-multiplexer is available + <antrik> eth-multiplexer is ready for use, it just needs to go upstream + <antrik> though it's probably desirable to switch it to the BPF + implementation from libpcap + <braunr> using the libpcap implementation in libpcap and in eth-multiplexer + are two different things + <braunr> the latter is preferrable + <braunr> (and yes, by available, i meant upstream ofc) + <antrik> eth-mulitplexer is already using libpcap anyways (for compiling + the filters); I'm sure zhengda just didn't realize it has an actual BPF + implementation too... + <braunr> we want the filter implementation as close to the packet source as + possible + <antrik> I have been using eth-multiplexer for at least two years now + <braunr> hm, there is a "snoop" source type, using raw sockets + <braunr> too far from the packet source, but i'll try it anyway + <braunr> hm wrong, snoop was the solaris packet filter fyi + + +## IRC, freenode, #hurd, 2012-01-28 + + <braunr> nice, i have tcpdump working :) + <braunr> let's see if it's as simple with wireshark + <pinotree> \o/ + <braunr> pinotree: it was actually very simple + <pinotree> heh, POV ;) + <braunr> yep, wireshark works too + <braunr> promiscuous mode is harder to test :/ + <braunr> but that's a start + + +## IRC, freenode, #hurd, 2012-01-30 + + <braunr> ok so next step: get tcpreplay working + <antrik> braunr: BTW, when you checked the status of the kernel BPF code, + did you take zhengda's enhancements/fixes into account?... + <braunr> no + <braunr> when did i check it ? + <antrik> braunr: well, you said the kernel BPF code has serious + shortcomings. did you take zhengda's changes into account? + <braunr> antrik: ah, when i mention the issues, i considered the userspace + translator only + <braunr> antrik: and stuff like non blocking io, exporting a selectable + file descriptor + <braunr> antrik: deb http://ftp.sceen.net/debian-hurd experimental/ + <braunr> antrik: this is my easy to use repository with a patched + libpcap0.8 + <braunr> and a small and unoptimized pcap-hurd.c module + <braunr> it doesn't use devopen yet + <braunr> i thought it would be better to have packet filtering working + first as a debian patch, then get the new translator+final patch upstream + <jkoenig> braunr, tcpdump works great here (awesome!). I'm probably using + exactly the same setup and "hardware" as you do, though :-P + + +## IRC, freenode, #hurd, 2012-01-31 + + <braunr> antrik: i tend to think we need a bpf translator, or anything + between the kernel and libpcap to provide selectable file descriptors + <braunr> jkoenig: do you happen to know how mach_msg (as called in a + hello.c file without special macros or options) deals with signals ? + <braunr> i mean, is it wrapped by the libc in a version that sets errno ? + <jkoenig> braunr: no idea. + <pinotree> braunr: what's up with it? (not that i have an idea about your + actual question, just curious) + <braunr> pinotree: i'm improving signal handling in my pcap-hurd module + <braunr> i guess checking for MACH_RCV_INTERRUPTED will dio + <braunr> -INFO is correctly handled :) + <braunr> ok new patch seems fine + <antrik> braunr: selectable file descriptors? + <braunr> antrik: see pcap_fileno() for example + <braunr> it returns a file descriptor matching the underlying object + (usually a socket) that can be multiplexed in a select/poll call + <braunr> obviously a mach port alone can't do the job + <braunr> i've upgraded the libpcap0.8 package with improved signal handling + for tests + <antrik> braunr: no idea what you are talking about :-( + + +## IRC, freenode, #hurd, 2012-02-01 + + <braunr> antrik: you do know about select/poll + <braunr> antrik: you know they work with multiple selectable/pollable file + descriptors + <braunr> on most unix systems, packet capture sources are socket + descriptors + <braunr> they're selectable/pollable + <antrik> braunr: what are packet capture sources? + <braunr> antrik: objects that provide applications with packets :) + <braunr> antrik: a PF_PACKET socket on Linux for example, or a Mach device, + or a BPF file descriptor on BSD + <antrik> for a single network device? or all of them? + <antrik> AIUI the userspace BPF implementation in libpcap opens this + device, waits for packets, and if any arrive, decides depending on the + rules whether to pass them to the main program? + <braunr> antrik: that's it, but it's not the point + <braunr> antrik: the point is that, if programs need to include packet + sources in select/poll calls, they need file descriptors + <braunr> without a translator, i can't provide that + <braunr> so we either decide to stick with the libpcap patch only, and keep + this limitation, or we write a translator that enables this feature + <pinotree> braunr: are the two options exclusive? + <braunr> pinotree: unless we implement a complete bpf translator like i did + years ago, we'll need a patch in libpcap + <braunr> pinotree: the problem with my early translator implementation is + that it's buggy :( + <braunr> pinotree: and it's also slower, as packets are small enough to be + passed through raw copies + <antrik> braunr: I'm not sure what you mean when talking about "programs + including packet sources". programs only interact with packet sources + through libpcap, right? + <antrik> braunr: or are you saying that programs somehow include file + descriptors for packet sources (how do they obtain them?) in their main + loop, and explicitly pass control to libpcap once something arrives on + the respecitive descriptors? + <braunr> antrik: that's the idea, yes + <antrik> braunr: what is the idea? + <braunr> 20:38 < antrik> braunr: or are you saying that programs somehow + include file descriptors for packet sources (how do they obtain them?) in + their main loop, and explicitly pass control to libpcap once something + arrives on the respecitive descriptors? + <antrik> braunr: you didn't answer my question though :-) + <antrik> braunr: how do programs obtain these FDs? + <braunr> antrik: using pcap_fileno() for example + + +## IRC, freenode, #hurd, 2012-02-02 + + <antrik> braunr: oh right, you already mentioned that one... + <antrik> braunr: so you want some entity that exposes the device as + something more POSIXy, so it can be used in standard FS calls, unlike the + Mach devices used for pfinet + <antrik> this is probably a good sentiment in general... but I'm not in + favour of a special solution only for BPF. rather I'd take this as an + indication that we probably should expose network interfaces as something + file-like in general after all, and adapt pfinet, eth-multiplexer, and + DDE accordingly + <braunr> antrik: i agree + <braunr> antrik: eth-multiplexer would be the right place + + +## IRC, freenode, #hurd, 2012-04-24 + + <gnu_srs> braunr: Is BPF fully supported by now? Can it be used for + isc-dhcp? + <braunr> gnu_srs: bpf isn't supported at all + <braunr> gnu_srs: instead of emulating it, i added a hurd-specific module + in libpcap + <braunr> if isc-dhcp can use libpcap, then fine + <braunr> (otherwise we could create a hurd-specific patch for dhcp that + uses the in-kernel bpf filter implementation) + <braunr> gnu_srs: can't it use a raw socket ? + <youpi> it can + <youpi> it's just that the shape of the patch to do so wasn't exactly how + they needed it + <youpi> so they have to rework it a bit + <youpi> and that takes time + <braunr> ok + <braunr> antrik: for now, we prefer encapsulating the system specific code + in libpcap, and let users of that library benefit from it + <braunr> instead of implementing the low level bpf interface, which + nonetheless has some system-specific variants .. 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/chroot_difference_from_linux.mdwn b/open_issues/chroot_difference_from_linux.mdwn new file mode 100644 index 00000000..f2009bd8 --- /dev/null +++ b/open_issues/chroot_difference_from_linux.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +\#hurd, freenode, 2010 + + <cfhammar> weird, even fd = open("/"), chroot("/tmp/chroot"), openat(fd, "/tmp/chroot/..) opens /tmp/chroot in linux + <pochu> cfhammar: isn't that expected? + <cfhammar> pochu: well, i didn't expect it :-) + <cfhammar> pochu: in hurd, /tmp gets opened, which i think is more natural + <pochu> cfhammar: oh right, didn't notice the ".." :-) diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn new file mode 100644 index 00000000..5345ed6b --- /dev/null +++ b/open_issues/clock_gettime.mdwn @@ -0,0 +1,71 @@ +[[!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="clock_gettime"]] + +[[!tag open_issue_glibc open_issue_gnumach]] + +Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel) + +It could be a mere matter of extending the mappable clock: add it to +`mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and +make `clock_gettime` use it. + +BTW, also make `gettimeofday()` use it, since it's way more efficient and some +applications assume that it is. + +What about adding a nanosecond-precision clock, too? --[[tschwinge]] + +IRC, freenode, #hurd, 2011-08-26: + + < pinotree> youpi: thing is: apparently i found a simple way to have a + monotonic clock as mmap-able device inside gnumach + < pinotree> currently, in kern/mach_clock.c there's a variable 'time', + which gets increased on clock interrupt, and optionally modified by + host_set_time + < pinotree> () + < pinotree> if i add a new variable next to it, only increasing it on + interrupt but not modifying it at all otherwise, would that give me a + monotonic clock? + < pinotree> at least on sme basic tests i did, it seems it could work that + way + < youpi> yes, it should work + < braunr> sure + < youpi> and that's the way I was considering implementing it + +IRC, freenode, #hurd, 2011-09-06: + + <pinotree> yeah, i had a draft of improved idea for also handling + nanoseconds + <tschwinge> pinotree: Ah, nice, I thought about nanoseconds as well. + <tschwinge> pinotree, youpi: This memory page is all-zero by default, + right? + <tschwinge> Can't we then say that its last int is a version code, and if + it is 0 (as it is now), we only have the normal mapped time field, if it + is 1, we also have the monotonic cliock and ns precision on address 8 and + 16 (or whatever)? + <tschwinge> In case that isn't your plan anyway. + <youpi> it's all-zero, yes + <tschwinge> Or, we say if a field is != 0 it is valid. + <youpi> making the last int a version code limits the size to one page + <youpi> I was thinking a field != 0 being valid is simpler + <youpi> but it's probably a problem too + <youpi> in that glibc usually caches whether interfaces are supported + <tschwinge> Wrap-around? + <youpi> for some clocks, it may be valid that the value is 0 + <youpi> wrap-around is another issue too + <tschwinge> Well, then we can do the version-field thing, but put it right + after the current time field (address 8, I think)? + <youpi> yes + <youpi> it's a bit ugly, but it's hidden behind the structure + <tschwinge> It's not too bad, I think. + <youpi> yes + <tschwinge> And it will forever be a witness of the evolving of this + map_time interface. :-) diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn new file mode 100644 index 00000000..00915651 --- /dev/null +++ b/open_issues/code_analysis.mdwn @@ -0,0 +1,135 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]]."]]"""]] + +In the topic of *code analysis* or *program analysis* ([[!wikipedia +Program_analysis_(computer_science) desc="Wikipedia article"]]), there is +static code analysis ([[!wikipedia Static_code_analysis desc="Wikipedia +article"]]) and dynamic program analysis ([[!wikipedia Dynamic_program_analysis +desc="Wikipedia article"]]). This topic overlaps with [[performance +analysis|performance]], [[formal_verification]], as well as general +[[debugging]]. + +[[!toc]] + + +# Bounty + +There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks. + + +# Static + + * [[GCC]]'s warnings. Yes, really. + + * GCC plugins can be used for additional semantic analysis. For example, + <http://lwn.net/Articles/457543/>, and search for *kernel context* in + the comments. + + * Have GCC make use of [[RPC]]/[[microkernel/mach/MIG]] *in*/*out* + specifiers, and have it emit useful warnings in case these are pointing + to uninitialized data (for *in* only). + + * [[Port Sequence Numbers|microkernel/mach/ipc/sequence_numbering]]. If + these are used, care must be taken to update them reliably, [[!message-id + "1123688017.3905.22.camel@buko.sinrega.org"]]. This could be checked by a + static analysis tool. + + * [Static Source Code Analysis Tools for C](http://spinroot.com/static/) + + * [[!wikipedia List_of_tools_for_static_code_analysis]] + + * [Cppcheck](http://sourceforge.net/apps/mediawiki/cppcheck/) + + For example, [Debian's hurd_20110319-2 + package](http://qa.debian.org/daca/cppcheck/sid/hurd_20110319-2.html) + (Samuel Thibault, 2011-08-05: *I had a look at those, some are spurious; + the realloc issues are for real*). + + * Coccinelle + + * <http://lwn.net/Articles/315686/> + + * <http://www.google.com/search?q=coccinelle+analysis> + + * clang + + * <http://www.google.com/search?q=clang+analysis> + + * Linux' sparse + + * <https://sparse.wiki.kernel.org/> + + * <http://klee.llvm.org/> + + * <http://blog.llvm.org/2010/04/whats-wrong-with-this-code.html> + + * [Smatch](http://smatch.sourceforge.net/) + + * [Parfait](http://labs.oracle.com/projects/parfait/) + + * <http://lwn.net/Articles/344003/> + + * [Saturn](http://saturn.stanford.edu/) + + * [Flawfinder](http://www.dwheeler.com/flawfinder/) + + * [sixgill](http://sixgill.org/) + + * [Coverity](http://www.coverity.com/) (nonfree?) + + +# Dynamic + + * [[community/gsoc/project_ideas/Valgrind]] + + * <http://en.wikipedia.org/wiki/Electric_Fence> + + * <http://sourceforge.net/projects/duma/> + + * <http://wiki.debian.org/Hardening> + + * <https://wiki.ubuntu.com/CompilerFlags> + + * IRC, freenode, #glibc, 2011-09-28 + + <vsrinivas> two things you can do -- there is an environment variable + (DEBUG_MALLOC_ iirc?) that can be set to 2 to make ptmalloc (glibc's + allocator) more forceful and verbose wrt error checking + <vsrinivas> another is to grab a copy of Tor's source tree and copy out + OpenBSD's allocator (its a clearly-identifyable file in the tree); + LD_PRELOAD it or link it into your app, it is even more aggressive + about detecting memory misuse. + <vsrinivas> third, Red hat has a gdb python plugin that can instrument + glibc's heap structure. its kinda handy, might help? + <vsrinivas> MALLOC_CHECK_ was the envvar you want, sorry. + + * In context of [[!message-id + "1341350006-2499-1-git-send-email-rbraun@sceen.net"]]/the `alloca` issue + mentioned in [[gnumach_page_cache_policy]]: + + IRC, freenode, #hurd, 2012-07-08: + + <youpi> braunr: there's actually already an ifdef REDZONE in libthreads + + It's `RED_ZONE`. + + <youpi> except it seems clumsy :) + <youpi> ah, no, the libthreads code properly sets the guard, just for + grow-up stacks + + * Input fuzzing + + Not a new topic; has been used (and a paper published) for early UNIX + tools, I[[I|tschwinge]]RC. + + * <http://caca.zoy.org/wiki/zzuf> + + What about some [[RPC]] fuzzing? diff --git a/open_issues/code_analysis/discussion.mdwn b/open_issues/code_analysis/discussion.mdwn new file mode 100644 index 00000000..f8a0657d --- /dev/null +++ b/open_issues/code_analysis/discussion.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-12-04 + + <mcsim> has anyone used splice on hurd? + <mcsim> splice -> splint + <youpi> not that I know of + <mcsim> this is tool for statically checking C programs + <mcsim> seems I made it work + <braunr> hm i realli i personnally dislike such tools a lot, but sometimes + it might help + <braunr> hello hurd people + <mcsim> braunr: hello + <braunr> mcsim: duma may be helpful as replacement for the memcheck part of + valgrind + <mcsim> defpager uses it's own dynamic memory allocator, which uses + vm_allocate/vm_deallocate as backing store? Am I able to use duma in such + case? + <braunr> you will have to adapt it + <braunr> but it's already designed to handle custom allocators + <braunr> iirc + <braunr> btw, are there special flags for that memory which the pager + allocates ? + <braunr> e.g. to use wired memory ? + <mcsim> yes, wired memory + <braunr> you'll have to change that in duma then + <braunr> but apart from such details, it should be straightforward + <antrik> braunr: I have no idea about duma; but if you think it's a useful + tool, please add it to open_issues/code_analysis.mdwn + <antrik> (I guess we should have a "proper" page listing useful debugging + tools...) diff --git a/open_issues/contributing.mdwn b/open_issues/contributing.mdwn new file mode 100644 index 00000000..7ae742f0 --- /dev/null +++ b/open_issues/contributing.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +This should be integrated into [[/contributing]]. + +--- + +Every now and then, people show up who have an inward urge to contribute to the +GNU Hurd, but have some difficulties about how to do that. + +For example, IRC, #hurd, 2010-10-06: + + <rah> I find it difficult to find the will to contribute to the hurd while hurd != hurd-ng + <pochu> hurd-ng? + <pochu> ah, http://www.gnu.org/software/hurd/hurd/ng.html + <pochu> rah: you may want to work on achieving that then + <rah> pochu: I'm not in a position to do OS research + <antrik> rah: if you are not into OS research, why do you need it to be ngHurd? :-) + <rah> antrik: I don't want to work on software which I know is already obsolete + <tschwinge> rah: My position on that can be found here; you may want to think about it. http://lists.gnu.org/archive/html/bug-hurd/2007-07/msg00111.html + <antrik> rah: the existing Hurd implementation is not any more obsolete than any other large software project + <antrik> there are always things that could be redone in a better way some time in the future + <antrik> but we have to start somewhere + <antrik> software development is a dynamic process + <antrik> trying to come up with a perfect design before you write any code will never lead anywhere, ever + <rah> antrik: of course, but when you know your start is wrong, have identified its problems, and are in the process of designing a second attempt, working on the first seems pointless + <antrik> rah: well, do you know all these things? because I do not + <antrik> what the experiments with new Hurd designs proved so far is that nobody is in a position to claim, "I have a better design" + <antrik> it's not hard to come up with a design that is better in some points -- but it's damn hard to come up with one that's not lacking in others + <antrik> the existing Hurd design is actually the only one which we *know* to work + <antrik> while research on improving the design is certainly beneficial, it's not like there is something new ready to replace the existing design at any moment + <antrik> and frankly, I'm more and more convinced that only iterative changes can ever result in any real improvement + <antrik> (and doing these changes requires a certain momentum, which we will never gain unless we actually have something usable first) + <LarstiQ> rah: afaik, not much is being done of designing another attempt + <rah> antrik: yes, I know all these things diff --git a/open_issues/crash_server.mdwn b/open_issues/crash_server.mdwn new file mode 100644 index 00000000..7ed4afbf --- /dev/null +++ b/open_issues/crash_server.mdwn @@ -0,0 +1,195 @@ +[[!meta copyright="Copyright © 2009, 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 +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]] + +Given an `a.out` executable that only does `raise (SIGABRT)`, invoking that +one... + + * ... against `crash-dump-core` will... + + * ... not overwrite existing `core` files. + + Is this reasonable? Linux does overwrite them, for example. + + * ... show big variances in running-time behavior: + + $ TIMEFORMAT='real %R user %U system %S' + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 1.350 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 21:59 core + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 22.771 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 21:59 core + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 1.367 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:00 core + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 5.789 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:00 core + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 22.664 user 0.010 system 0.000 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:01 core + + * ... produce a huge `core` file: + + $ du -hs core + 17M core + + On Linux, the `core` file occupies 76 KiB of disk space, which seems + much more reasonable. This is possibly related with the default 128MiB + heap preallocation. + + * ... does not always produce a useful backtrace: + + `abort();` + + $ gdb test core + warning: core file may not match specified executable file. + [New Thread 86678] + warning: Wrong size fpregset in core file. + ... + Core was generated by `./test'. + Program terminated with signal 6, Aborted. + warning: Wrong size fpregset in core file. + (gdb) bt + #0 0x00000000 in ?? () + #1 0x011f593f in __msg_sig_post (process=72, signal=6, sigcode=0, refport=1) + at /build/buildd-eglibc_2.10.2-7-hurd-i386-iGL6op/eglibc-2.10.2/build-tree/hurd-i386-libc/hurd/RPC_msg_sig_post.c:144 + #2 0x0109a433 in kill_port (pid=<value optimized out>) + at ../sysdeps/mach/hurd/kill.c:68 + #3 kill_pid (pid=<value optimized out>) at ../sysdeps/mach/hurd/kill.c:105 + #4 0x0109a69f in __kill (pid=21142, sig=6) at ../sysdeps/mach/hurd/kill.c:139 + #5 0x01099af6 in raise (sig=6) at ../sysdeps/posix/raise.c:27 + #6 0x0109de59 in abort () at abort.c:88 + #7 0x0804849f in main () + + `char *foo = 0; *foo = 1;` + + $ gdb test core + Program terminated with signal 11, Segmentation fault. + warning: Wrong size fpregset in core file. + #0 0x00000000 in ?? () + (gdb) bt + #0 0x00000000 in ?? () + #1 0x0108565b in __libc_start_main (main=0x8048464 <main>, argc=1, ubp_av=0x1023e64, + init=0x8048490 <__libc_csu_init>, fini=0x8048480 <__libc_csu_fini>, rtld_fini=0xea20 <_dl_fini>, + stack_end=0x1023e5c) at libc-start.c:251 + #2 0x080483d1 in _start () + + `raise (SIGABRT);` + + $ gdb a.out core + warning: core file may not match specified executable file. + [New Thread 76651] + + warning: Wrong size fpregset in core file. + Reading symbols from /lib/libc.so.0.3...[...] + Core was generated by `./a.out'. + Program terminated with signal 6, Aborted. + + warning: Wrong size fpregset in core file. + #0 0x00000000 in ?? () + (gdb) bt + #0 0x00000000 in ?? () + Cannot access memory at address 0x17 + + [[!tag open_issue_gdb]] Probably [[GDB]] doesn't manage to dig in the stack properly. + + * ... against `crash-suspend` will... + + * ... not work at all: + + $ CRASHSERVER=/servers/crash-suspend ./a.out + $ [returns to the shell and doesn't suspended] + + * ... show big variances in running-time behavior: + + $ TIMEFORMAT='real %R user %U system %S' + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.381 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.332 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 21.228 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.323 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:05 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 22.279 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:05 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.362 user 0.000 system 0.000 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 21.110 user 0.000 system 0.000 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.350 user 0.000 system 0.020 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core + + * ... can reliably crash GNU Mach: + + This happens if a `core` file is already present (and won't get + overwritten; see above). I reproduced this three times. + + $ TIMEFORMAT='real %R user %U system %S' + $ time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted + real 2.856 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core + + panic: zalloc: zone kalloc.8192 exhausted + Kernel Breakpoint trap, eip 0x20020a77 + Stopped at 0x20020a76: int $3 + db> trace + 0x20020a76(2006aba8,4d0f7e9c,200209b0,0,0) + 0x20020a4d(2006b094,2006ae40,2000,20016803,4a5f4114) + 0x2002bca5(49a03564,1,0,9,1000) + 0x20022f4c(2000,4a5f45d4,4a84879c,49a46564,4ac43e78) + 0x20021e65(4ac43e78,4a5f45d4,4a5f4114,0,0) + 0x2005309d(2106ba9c,3,38,28,1783) + Bad frame pointer: 0x2106ba78 + + $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020a4d 0x2002bca5 0x20022f4c 0x20021e65 0x2005309d + Debugger + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105 + panic + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:148 + zalloc + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/zalloc.c:470 + kalloc + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/kalloc.c:185 + ipc_kobject_server + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_kobject.c:76 + mach_msg_trap + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/ipc/mach_msg.c:1367 + +--- + +If someone is working in this area, they may want to have a look at +[[GDB_gcore]], and port <http://code.google.com/p/google-coredumper/>, too. diff --git a/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn b/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn new file mode 100644 index 00000000..4076d8d0 --- /dev/null +++ b/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, unknown channel, unknown date: + + <antrik> I have a theory + <antrik> when the system is under CPU load, the ext2 locking issues are more likely to happen + <antrik> I'm under the impression, that when doing something disk-intensive (like a compile job) *considerably* more often causes crashes, when doing *any* other activity in parallel -- be it other compile jobs, or CPU-only activities + <antrik> thinking about it, I'm not sure whether CPU-intensive is the decisive criterium, or maybe RPC-intensive... + <antrik> CPU load doesn't seem to have any effect -- neither alone, nor in combination with other testcases diff --git a/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn b/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn new file mode 100644 index 00000000..b94c0c1d --- /dev/null +++ b/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_gcc]] + + $ gcc -o /dev/null -x c /dev/null + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 0 has invalid symbol index 12 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 1 has invalid symbol index 13 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 2 has invalid symbol index 2 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 3 has invalid symbol index 2 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 4 has invalid symbol index 12 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 5 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 6 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 7 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 8 has invalid symbol index 2 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 9 has invalid symbol index 2 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 10 has invalid symbol index 13 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 11 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 12 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 13 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 14 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 15 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 16 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 17 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 18 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 19 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 20 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 21 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 22 has invalid symbol index 22 + /usr/lib/gcc/i486-gnu/4.4.5/../../../crt1.o: In function `_start': + (.text+0x18): undefined reference to `main' + collect2: ld returned 1 exit status + +Likewise for `-static`, `crt0.o`. diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn new file mode 100644 index 00000000..2f02579e --- /dev/null +++ b/open_issues/dbus.mdwn @@ -0,0 +1,90 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +The dbus problems are due to missing scm credentials [[sendmsg_scm_creds]] and socket credentials +[[pflocal_socket_credentials_for_local_sockets]]. There was also a problem with short timeout in +[[select]], but that has been solved in Debian by setting a minimum timeout of 1ms. + +--- + +IRC, freenode, #hurd, 2011-11-26: + + <antrik> BTW, how much effort is necessary to fix dbus? + <pinotree> basically, have pflocal know who's the sender + (pid/uid/gid/groups) in the socket send op + +IRC, freenode, #hurd, 2011-12-16: + + <braunr> pinotree: what's the problem with dbus ? + <pinotree> braunr: select() returning 0 changed fd's with very short (eg < + 1ms) timeouts when there are actually events; + +[[select]]. + + <pinotree> and missing socket credentials + +[[sendmsg_scm_creds]]. + + <braunr> oh + <braunr> which socket creds interface ? + <pinotree> bsd, i.e. with SCM_CREDENTIALS payload for cmsg on + {recv,send}msg() + <braunr> ok + <braunr> SCM_RIGHTS too ? + <braunr> the select issue seems weird though + <pinotree> hm no, that's for passing fd's to other processes + <braunr> is it specific to pflocal or does dbus use pfinet too ? + <pinotree> iirc on very short timeouts the application has no time waiting + for the reply of servers + <braunr> i see + <pinotree> braunr: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79358 + <braunr> thanks + <pinotree> (the interesting messages are from #53 and on) + <braunr> 2000 eh ... :) + <braunr> hm i agree with neal, i don't understand why the timeout is given + to the kernel as part of the mach_msg call + +IRC, freenode, #hurd, 2011-12-20: + + <braunr> hm, i don't see any occurrence of SCM_CREDENTIALS in dbus + <braunr> only SCM_RIGHTS + <pinotree> braunr: yes, that one + <braunr> oh + <braunr> i thought you said the opposite last time + <pinotree> dbus/dbus-sysdeps-unix.c, write_credentials_byte and + _dbus_read_credentials_socket (with #define HAVE_CMSGCRED) + <braunr> hm + <braunr> which version ? + <braunr> i don't see anything in 1.4.16 + <pinotree> 1.4.16 + <braunr> grmbl + <braunr> ah, i see + <braunr> SCM_CREDS + <pinotree> if you want, i have a simplier .c source with it + <braunr> no i'm just gathering info + <pinotree> ok + <braunr> what's the deal with SCM_CREDS and SCM_CREDENTIALS ? + <braunr> bsd vs sysv ? + <braunr> oh, http://lists.debian.org/debian-hurd/2002/03/msg00135.html + <braunr> so we actually do want both SCM_CREDS and SCM_RIGHTS for debus + <braunr> dbus + <pinotree> SCM_RIGHTS is a different matter, it is for passing fd's + <braunr> yes + <braunr> but it's used by dbus + <braunr> so if we can get it, it should help too + <pinotree> there's a preliminary patch for it done by emilio time ago, and + iirc it's applied to debian's glibc + <braunr> ah, he changed the libc + <braunr> right, that's the only sane way + <pinotree> iirc roland didn't like one or more parts of it (but i could be + wrong) + <braunr> ok diff --git a/open_issues/dbus_in_linux_kernel.mdwn b/open_issues/dbus_in_linux_kernel.mdwn new file mode 100644 index 00000000..a94e1fed --- /dev/null +++ b/open_issues/dbus_in_linux_kernel.mdwn @@ -0,0 +1,64 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Might be interesting to watch how this develops. + +IRC, #hurd, August / September 2010 + + <neal> check this out: + <neal> someone is working on implementing dbus in linux + <neal> linux finally gets mach ipc ;-) + <marcusb> it's old news though, unless there is an update + <marcusb> and I think it was only the client? + <neal> youpi : someone is adding dbus ipc to the linux kernel + <neal> marcusb: I just heard about it. + <youpi> (it's crazy how this drives backward compared to a hurdish approach) + <youpi> what is the motivation for moving to the kernel? + <neal> context switch overhead + <azeem_> they wanna use it to talk to device drivers? :) + <kilobug> well, they did that with the in-kernel web server, but they + abandonned it later on + <neal> azeem: I don't think so. + <neal> dbus in the kernel is actually good for the Hurd as dbus IPC is + basically neutered Mach IPC + <marcusb> I don't think anybody wants to put the dbus server in the kernel + <neal> well, there is at least one person + <marcusb> maybe this is a different news from the one I read + <neal> Alban Crequy (albanc) is working out. He works for collabora, fwiw + +<http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/> + + <marcusb> what I read was about hal etc + <marcusb> so that you don't need a user space daemon to glue the kernel to the + dbus world + <neal> I don't think that is what he is talking about + <marcusb> I can't find it anymore though. I mentioned it in this channel at + the time though, so it should be in the backlog + <marcusb> neal, yeah could very well be a separate thing + <marcusb> neal, dbus does have marginal support for fd passing though, and some + attempts on the mailing list to make "fds" an official type in the message + failed (as far as I could see, I didn't read the whole discussion) + <marcusb> so no mach ipc just yet + <neal> wrong + <neal> FD handling is in 1.4 + <neal> type o, if I'm not mistaken + <marcusb> then the discussion moved on from initial rejection + <neal> no, 'h' + <marcusb> I'm out of date by two months + <marcusb> ok + <guillem> neal: AFAIR Marcel Holtmann talked about dbus in-kernel several years + ago, but he never ended up implementing it, or there were rumors he had + private "working code" + + * Related Mailing List Discussion + + * [\[PATCH 0/5\] RFC: Multicast and filtering features on + AF_UNIX](http://article.gmane.org/gmane.linux.kernel/1040481), + 2010-09-24 diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn new file mode 100644 index 00000000..aff988d5 --- /dev/null +++ b/open_issues/dde.mdwn @@ -0,0 +1,463 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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_gnumach]] + +[[General Information|/dde]]. + +Still waiting for interface finalization and proper integration. + +[[!toc]] + + +# Disk Drivers + +Not yet supported. + +The plan is to use [[libstore_parted]] for accessing partitions. + + +## Booting + +A similar problem is described in +[[community/gsoc/project_ideas/unionfs_boot]], and needs to be implemented. + + +# Upstream Status + + +## IRC, freenode, #hurd, 2012-02-08 + +At the microkernel davroom at [[community/meetings/FOSDEM_2012]]: + + <antrik> there was quite some talk about DDE. I learnt that there are newer + versions in Genode and in Minix (as opposed to the DROPS one we are + using) + <antrik> but apparently none of the guys involved is interested in creating + a proper upstream project with central repository and communication + channels :-( + <antrik> the original DDE creator was also there, but said he isn't working + on it anymore + <tschwinge> OK, and the other two projects basically have their own forks. + <tschwinge> Or are they actively cooperating? + <tschwinge> (If you know about it.) + <antrik> well, Genode is also part of the Dresden L4 group; but apart from + that, I'd rather call it a fork... + <antrik> hm... actually, I'm not sure anymore whether the guy I talked to + was from Genode or Nova... + <antrik> (both from the Dresdem L4 group) + + +## IRC, freenode, #hurd, 2012-02-19 + + <youpi> antrik: do we know exactly which DDE version Zheng Da took as a + base ? + <youpi> (so as to be able to merge new changes easily) + <antrik> youpi: not sure... but from what I gathered at FOSDEM, the version + he based on (from DROPS) is not really actively developed right now; if + we want to go for newer versions, we probably have to look at other + projects (like Genode or Nova or Minix) + <youpi> there's no central project for dde ? + <youpi> that sucks + <antrik> no... and nobody seemed interested in having one :-( + <youpi> pff + <antrik> which makes me seriously question the original decision to build + on DDE... + <braunr> .. + <antrik> if we have to basically maintain it ourselfs anyways, we could + just as well have gone with custom glue + <youpi> well, the advantage of DDE is that it already exists now + <antrik> on the positive side, one of the projcets (not sure which) + apparently have both USB and SATA working with some variant of DDE + + +# IRC, OFTC, #debian-hurd, 2012-02-15 + + <pinotree> i have no idea how the dde system works + <youpi> gnumach patch to provide access to physical memory and interrupts + <youpi> then userland accesses i/o ports by hand to drive things + <youpi> but that assumes that no kernel driver is interfering + <youpi> so one has to disable kernel drivers + <pinotree> how are dde drivers used? can they be loaded on their own + automatically, or you have to settrans yourself to setup a device? + <youpi> there's no autoloader for now + <youpi> we'd need a bus arbitrer that'd do autoprobing + <pinotree> i see + <pinotree> (you see i'm not really that low level, so pardon the flood of + posssibly-noobish questions ;) ) + <youpi> I haven't set it up yet, but IIRC you need to specify which driver + to be used + <youpi> well, I mostly have the same questions actually :) + <youpi> I just have some guesswork here :) + <pinotree> i wonder whether the following could be feasible: + <youpi> I'm wondering how we'll manage to make it work in d-i + <pinotree> a) you create a package which would b-d on linux-source, build a + selection of (network only for now) drivers and install them in + /hurd/dde/ + <youpi> probably through a choice at the boot menu + <youpi> I wouldn't dare depending on linux-source + <youpi> dde is usually not up-to-date + <pinotree> b) add a small utility over the actual fsys_settrans() which + would pick the driver from /hurd/dde/ + <pinotree> ... so you could do `set-dde-driver b43 <device>` (or something + like that) + <youpi> we can provide something like b) yes + <youpi> although documenting the settrans should be fine enough ;) + <pinotree> the a) would help/ease with the fact that you need to compile on + your own the drivers + <pinotree> otherwise we would need to create a new linux-dde-sources-X.Y.Z + only with the sources of the drivers we want from linux X.Y.Z + <pinotree> (or hurd-dde-linux-X.Y.Z) + <CIA-4> samuel.thibault * raccdec3 gnumach/debian/ (changelog + patches/70_dde.patch patches/series): + <CIA-4> Add DDE experimental support + <CIA-4> * debian/patches/70_dde.patch: Add experimental support for irq + passing and + <CIA-4> physical memory allocation for DDE. Also adds nonetdev boot + parameter to + <CIA-4> disable network device drivers. + <youpi> ok, boots fine with the additional nonetdev option + <youpi> now I need to try that dde hurd branch :) + <CIA-4> samuel.thibault * rf8b9426 gnumach/debian/patches/70_dde.patch: Add + experimental.defs to gnuamch-dev + + +# IRC, freenode, #hurd, 2012-02-19 + + * youpi got dde almost working + <youpi> it's able to send packets, but apparently not receive them + <youpi> (e1000) + <youpi> ok, rtl8139 works + <youpi> antrik: the wiki instructions are correct + <youpi> with e1000 I haven't investigated + <antrik> (Archhurd guys also reported problems with e1000 IIRC... the one I + built a while back works fine though on my T40p with real e1000 NIC) + <antrik> maybe I should try with current versions... something might got + broken by later changes :-( + <youpi> at least testing could tell the changeset which breaks it + <youpi> Mmm, it's very odd + <youpi> with the debian package, pfinet's call to device_set_filter returns + D_INVALID_OPERATION + <youpi> and indeed devnode.c returns that + <youpi> ah but it's libmachdev which is supposed to answer here + <antrik> youpi: so, regarding the failing device_set_filter... I guess you + are using some wrong combination of gnumach and pfinet + <youpi> no it's actually that my pfinet was not using bpf + <youpi> I've now fixed it + <antrik> the DDE drivers rely on zhengda's modified pfinet, which uses + devnode, but also switched to using proper BPF filters. so you also need + his BPF additions/fixes in gnumach + <antrik> OK + <youpi> that's the latter + <youpi> I had already fixed the devnode part + <youpi> but hadn't seen that the filter was different + <antrik> err... did I say gnumach? that of course doesn't come into play + here + <antrik> so yes, you just need a pfinet using BPF + <youpi> libmachdev does ;) + <antrik> I'm just using pfinet from zhengda's DDE branch... I think devnode + and BPF are the only modifications + <youpi> there's also a libpcap modification in the incubator + <youpi> probably for tcpdump etc. + <antrik> libpcap is used by the modified pfinet to compile the filter rule + <youpi> why does pfinet need to compile the rule ? + <youpi> it's libbpf which is used in the dde driver + <antrik> it doesn't strictly need to... but I guess zhengda considered it + more elegant to put the source rule in pfinet on compile it live, rather + than the compiled blob + <antrik> I probably discussed this with him myself a few years back... but + my memory on this is rather hazy ;-) + <antrik> err... and compile it live + <youpi> ah, right, it's only used when asking pfinet to change its filter + <youpi> but it does not need it for the default filter + <youpi> which is hardcoded + <antrik> I see + <antrik> when would pfinet change its filter? + * youpi now completely converting his hurd box to debian packages with dde + support + <youpi> on SIOCSIFADDR apparently + <youpi> to set "arp or (ip host %s)", + <antrik> well, that sounds like the default filter... + <youpi> the default filter does not choose an IP + <antrik> oh, right... pfinet has to readjust the filter when setting the IP + <youpi> arg we lack support for kernel options for gnumach in update-grub + <antrik> again, I have a vague recollection of discussing this + * youpi crosses fingers + <youpi> yay, works + <antrik> so we *do* need libpcap in pfinet to set proper rules... though I + guess it can also work with a static catchall rule (like it did before + zhengda's changes), only less efficient + <youpi> well in the past we were already catching everything anyway, so at + least it's not a regression :) + <antrik> right + + +# IRC, freenode, #hurd, 2012-02-19 + + <youpi> antrik: we should probably add a gsoc idea on pci bus arbitration + <youpi> DDE is still experimental for now so it's ok that you have to + configure it by hand, but it should be automatic at some ponit + + +## IRC, freenode, #hurd, 2012-02-21 + + <braunr> i'm not familiar with the new gnumach interface for userspace + drivers, but can this pci enumerator be written with it as it is ? + <braunr> (i'm not asking for a precise answer, just yes - even probably - + or no) + <braunr> (idk or utsl will do as well) + <youpi> I'd say yes + <youpi> since all drivers need is interrupts, io ports and iomem + <youpi> the latter was already available through /dev/mem + <youpi> io ports through the i386 rpcs + <youpi> the changes provide both interrupts, and physical-contiguous + allocation + <youpi> it should be way enough + <braunr> youpi: ok + <braunr> youpi: thanks for the details :) + <antrik> braunr: this was mentioned in the context of the interrupt + forwarding interface... the original one implemented by zhengda isn't + suitable for a PCI server; but the ones proposed by youpi and tschwinge + would work + <antrik> same for the physical memory interface: the current implementation + doesn't allow delegation; but I already said that it's wrong + + +# IRC, freenode, #hurd, 2012-02-20 + + <youpi> I was a bit wary of including the ton of dde headers in hurd-dev + <youpi> maybe adding another package for that + <youpi> but that would have delayed introducing the dde binaries + <youpi> probably we can do that for next upload + <pinotree> i can try to work on it, if is feasible (ie if the dde drivers + can currently be built from outside the hurd source tree) + <youpi> it should be, it's a matter of pointing its makefile to a place + where the make scripts and include headers are + <youpi> (and the libraries) + <pinotree> ok + <antrik> youpi: you mean DDEKit headers? + <antrik> pinotree: actually it doesn't matter where the dde-ified Linux + drivers are built -- libdde_linux26 and the actual drivers use a + completetly different build system anyways + <antrik> in fact we concluded at some point that they should live in a + separate repository -- but that change never happened + <antrik> only the base stuff (ddekit, libmachdev etc.) belong in the Hurd + source tree + <youpi> antrik: yes + <youpi> antrik: err, not really completely different + <youpi> the actual drivers' Makefile include the libdde_linux26 mk files + <youpi> the build itself is separate, though + <antrik> youpi: yes, I mean both libdde_linux26 and the drivers use a build + system that is completely distinct from the Hurd one + <youpi> ah, yes + <youpi> libdde_linux26 should however be shipped in the system + <antrik> ideally libdde_linux26 and all the drivers should be built in one + go I'd say... + <youpi> it should be easily feasible to also have a separate driver too + <youpi> e.g. to quickly try a 2.6 driver + <antrik> youpi: I'm not sure about that. it's not even dynamically linked + IIRC?... + <youpi> with scripts to build it + <youpi> it's not + <youpi> but that doesn't mean it can't be separate + <youpi> .a files are usually shipped in -dev packages + <antrik> youpi: ideally we should try to come with a build system that + reuses the original Linux makefile snippets to build all the drivers + automatically without any manual per-driver work + <youpi> there's usually no modification of the drivers themselves? + <youpi> but yeah + <youpi> "ideally", when somebody takes the time to do it + <antrik> unfortunately, it's necessary to include one particular + Hurd/DDE-specific header file in each driver :-( + <youpi> can't it be done through gcc's -include option? + <antrik> zhengda didn't find a way to avoid this... though I still hope + that it must be possible somehow + <antrik> I think the problem is that it has to be included *after* the + other Linux headers. don't remember the details though + <youpi> uh + <youpi> well, a good script can add a line after the last occurrence of + #include + <antrik> yeah... rather hacky, but might work + <youpi> even with a bit of grep, tail, cut, and sed it should work :) + <antrik> note that this is Hurd-specific; the L4 guys didn't need that + <youpi> what is it? + <antrik> don't remember off-hand + + +# IRC, freenode, #hurd, 2012-02-22 + + <youpi> antrik: AIUI, it should be possible to include all network drivers + in just one binary? + <youpi> that'd permit to use it in d-i + <youpi> and completely replace the mach drivers + <youpi> we just need to make sure to include at least what the mach drivers + cover + <youpi> (all DDE network drivers, I mean) + <youpi> of course that doesn't hinder from people to carefully separate + drivers in several binaries if they wish + <youpi> antrik: it does link at least, I'll give a try later + <youpi> yes it works! + <youpi> that looks like a plan + <youpi> throw all network drivers in a /hurd/dde_net + <youpi> settrans it on /dev/dde_net, and settrans devnode on /dev/eth[0-9] + <youpi> I'm also uploading a version of hurd which includes headers & + libraries, so you just need a make in dde_{e100,e1000,etc,net} + <youpi> (uploading it with the dde driver itself :) ) + <youpi> btw, a nice thing is that we don't really care that all drivers are + stuffed into a single binary, since it's a normal process only the useful + pages are mapped and actually take memory :) + <Tekk_> is that really a nice thing though? compared to other systems I + mean + <Tekk_> I know on linux it only loads the modules I need, for example. It's + definitely a step up for hurd though :D + <youpi> that's actually precisely what I mean + <youpi> you don't need to load only the modules you need + <youpi> you just load them all + <youpi> and paging eliminates automatically what's not useful + <youpi> even parts of the driver that your device will not need + <Tekk_> ooh + <Tekk_> awesome + <youpi> (actually, it's not even loaded, but the pci tables of the drivers + are loaded, then paged out) + + +# IRC, freenode, #hurd, 2012-02-24 + + <youpi> antrik_: about the #include <ddekit/timer.h>, I see the issue, it's + about jiffies + <youpi> it wouldn't be a very good thing to have a jiffies variable which + we'd have to update 100times per second + <youpi> so ZhengDa preferred to make jiffies a macro which calls a function + which reads the mapped time + <youpi> however, that break any use of the work "jiffies", e.g. structure + members & such + <youpi> actually it's not only after headers that the #include has to be + done, but after any code what uses the word "jiffies" for something else + than the variable + <youpi> pb is: it has to be done *before* any code that uses the word + "jiffies" for the variable, e.g. inline functions in headers + <youpi> in l4dde, there's already the jiffies variable so it's not a + problem + + +# IRC, OFTC, #debian-hurd, 2012-02-27 + + <tschwinge> I plan to do some light performance testing w.r.t. DDE + Ethernet. That is DDE vs. Mach, etc. + <youpi> that'd be good, indeed + <youpi> I'm getting 4MiB/s with dde + <youpi> I don't remember with mach + <tschwinge> Yes. It just shouldn't regress too much. + <tschwinge> Aha, OK. + + +## IRC, freenode, #hurd, 2012-02-27 + + <youpi> tschwinge: nttcp tells me ~80Mbps for mach-rtl8139, ~72Mbps for + dde-rtl8139, ~72Mbps for dde-e1000 + <youpi> civodul: ↑ btw + <ArneBab> youpi: so the dde network device is not much slower than the + kernel-one? + <civodul> youpi: yes, looks good + <ArneBab> rather almost the same speed + <youpi> apparently + <ArneBab> that’s quite a deal. + <ArneBab> what speed should it have as maximum? + <ArneBab> (means: does the mach version get out all that’s possible?) + <ArneBab> differently put: What speed would GNU/Linux get? + <youpi> I'm checking that right now + <ArneBab> cool! + <ArneBab> we need those numbers for the moth after the next + <youpi> Mmm, I'm not sure you really want the linux number :) + <youpi> 1.6Gbps :) + <ArneBab> oh… + <youpi> let me check with udp rather than tcp + <ArneBab> so the Hurd is a “tiny bit” worse at using the network… + <youpi> it might simply be an issue with tcp tuning in pfinet + <ArneBab> hm, yes + <ArneBab> tcp is not that cheap + <ArneBab> and has some pretty advanced stuff for getting to high speeds + <youpi> well, I'm not thinking about being cheap + <youpi> but using more recent tuning + <youpi> that does not believe only 1Mbps network cards exist :) + <ArneBab> like adaptive windows and such? + <ArneBab> :) + <youpi> yes + * ArneBab remembers that TCP was invented when the connections went over + phone lines - by audio :) + <youpi> yep + <ArneBab> what’s the system load while doing the test? + <youpi> yes, udp seems not so bad + <ArneBab> ah, cool! + <youpi> it's very variable (300-3000Mbps), but like on linux + <ArneBab> that pushing it into user space has so low cost is pretty nice. + * ArneBab thinks that that’s a point where Hurd pays off + <youpi> that's actually what AST said to fosdem + <youpi> he doesn't care about putting an RPC for each and every port i/o + <youpi> because hardware is slow anyway + <ArneBab> jupp + <ArneBab> but it is important to see that in real life + + +# IRC, freenode, #hurd, 2012-04-01 + + <youpi> antrik: I wonder whether you could actually not route the IRQs to a + non-zero ring, AIUI you can in the x86 IDT table + <antrik> youpi: you mean having a userspace server for each (non-timer) + interrupt? + <antrik> youpi: how would a userspace IRQ handler interact with the + scheduler? + <youpi> antrik: it doesn't necessarily have to + <youpi> provided that it's trusted + <antrik> youpi: how would you do CPU time accounting if there is no + interaction with the scheduler?... + <youpi> antrik: you don't necessarily want to care about it + <antrik> youpi: well, that would mean that all drivers handling interrupts + would have to be trusted to not use more than a very small part of CPU + time... + <youpi> yes + <youpi> which is usually needed for interrupt handlers anyway + <antrik> youpi: nah, the bottom handler only has to do very basic stuff; + afterwards, we can pass off to "normal" driver processes, scheduled just + like other processes... but that requires some interaction between the + IRQ handler and the scheduler I think + <youpi> the IRQ handler can wake up a thread, yes + <youpi> no need for anything special there + <antrik> so the userspace IRQ server would just decide what process to wake + up, and then call the scheduler to do a normal task switch? I guess + that's possible; but I'm not sure it would buy much... + <youpi> it would permit userland to quickly react to the IRQ + <youpi> such as acknowledge it to the hardware etc. + <antrik> yeah, but my point is that I don't see much benefit in having this + part of the code isolated in a userspace process... it has to be trusted + anyways, and it's pretty trivial too + <youpi> I never said it was a good idea + + +# IRC, freenode, #hurd, 2012-04-06 + + <braunr> oh i forgot about my work on pcap + <braunr> is devnode (or devopen or whatever) in the upstream repository now + ? + <antrik> can't say for sure, but I'd be surprised... don't remember seeing + any movement in that regard :-( + <braunr> wasn't it needed for dde ? + <antrik> hm... good point + + +# virtio + + +## IRC, freenode, #hurd, 2012-07-01 + + <braunr> hm, i haven't looked but, does someone know if virtio is included + in netdde ? + <youpi> braunr: nope, there's an underlying virtio layer needed before diff --git a/open_issues/debian_cross_toolchain.mdwn b/open_issues/debian_cross_toolchain.mdwn new file mode 100644 index 00000000..e0665466 --- /dev/null +++ b/open_issues/debian_cross_toolchain.mdwn @@ -0,0 +1,15 @@ +[[!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]] + +Have a look at the Debian *Cross Toolchain* project, +<https://alioth.debian.org/projects/crosstoolchain/>, +<http://wiki.debian.org/ToolChain/Cross>. diff --git a/open_issues/debootstrap.mdwn b/open_issues/debootstrap.mdwn new file mode 100644 index 00000000..8e6c4900 --- /dev/null +++ b/open_issues/debootstrap.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +\#hurd, freenode, 2010 + + <azeem_> you know, you would really help the Hurd if you tried debootstrap instead + <tschwinge> Oh? Does that have everying in place by now? + <azeem_> applying the patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498731#25 + <azeem_> they are waiting for feedbacl + <azeem_> feedback* + +\#hurd, freenode, June (?) 2010 + + <azeem_> jd823592: if you want to use debootstrap, you should apply a patch + <azeem_> and test + <azeem_> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=debootstrap_hurd.patch;att=1;bug=498731 + <azeem_> we desperately need somebody to test the patch diff --git a/open_issues/debugging.mdwn b/open_issues/debugging.mdwn new file mode 100644 index 00000000..b2d49b26 --- /dev/null +++ b/open_issues/debugging.mdwn @@ -0,0 +1,53 @@ +[[!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 +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]]."]]"""]] + + +# Existing + +We have debugging infrastructure. For example: + + * [[GDB]] + + * [[GNU Mach debugging|microkernel/mach/gnumach/debugging]] + + * [[GNU Hurd debugging|hurd/debugging]], including + [[hurd/debugging/rpctrace]], and more. + + +# To Do + + * [[ltrace]] + + * [[latrace]] + + * [[profiling]] + + * *Checkpoint/restart allows the state of a set of processes to be saved to + persistent storage, then restarted at some future time* -- quoting from + Jonathan Corbet's [2010 Linux Kernel Summit + report](http://lwn.net/Articles/412749/). + + This is surely a very useful facility to have for reproducing failures, for + example. But on the other hand it's questionable how it can help with + debugging failures in [[GNU Hurd server|hurd/translator]]s' interactions, + as their state is typically spread between several processes. + + Continues: <http://lwn.net/Articles/414264/>, which introduces + <http://dmtcp.sourceforge.net/>. + + * [[crash_server}}, [[GDB_gcore]], + <http://code.google.com/p/google-coredumper/> + + * [[community/gsoc/project_ideas/libdiskfs_locking]] + + * <http://lwn.net/Articles/415728/>, or <http://lwn.net/Articles/415471/> -- + just two examples; there's a lot of such stuff for Linux. + + * [[debugging_gnumach_startup_QEMU_GDB]] diff --git a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn new file mode 100644 index 00000000..e3a6b648 --- /dev/null +++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn @@ -0,0 +1,116 @@ +[[!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="Debugging GNU Mach's startup in QEMU with GDB"]] + +[[!tag open_issue_gdb open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2011-07-14 + + <mcsim> Hello. I have problem with debugging gnumach. I set 2 brakepoints + in file i386/i386at/model_dep.c on functions gdt_init and idt_init. Then + I start qemu with patched gnumach kernel and stop at gdt_init. When I + enter command "continue" in gdb, qemu hangs. But when I go step by step, + using command "next", I freely reach idt_init. What can cause this + problem? + <braunr> hm + <braunr> not sure + <braunr> let me try + <braunr> mcsim: works for me :/ + <mcsim> it works without my patch, but with it qemu hangs + <braunr> oh, i thought it worked when not using continue + <mcsim> with my patch I can reach idt_init only using next + <mcsim> and without all works fine + <braunr> mcsim: are you sure you correctly built it with debugging symbols + ? + <mcsim> I've written in /etc/dpkg/buildflags.conf SET CFLAGS -g3 -O0 + <braunr> hm + <braunr> i have internal kvm errors actually + <braunr> mcsim: do you use kvm ? + <braunr> mcsim: and why break on those functions ? + <braunr> i'm not sure the address space is already fine at this point + <mcsim> no. I don't have hardware virtualisation support. + <braunr> hm actually, you won't be able to use gdb + <braunr> i just remembered how gnumach is linked and mapped :/ + <braunr> the addresses in the elf image are low addresses, matching the + image as it is loaded by the boot loader + <mcsim> I was wondering why qemu hangs. + <braunr> then the kernel uses segmentation to map itself at 2 (or 3 + previously) GiB + <braunr> well, if the addresses are wrong, your breakpoints are wrong + <braunr> i even wonder how it can work when stepping + <braunr> i don't have the issue with x15 because of its linker script + <mcsim> Are there any ways of such debugging without qemu? + <braunr> i don't think so + <braunr> as antrik told you, the in kernel debugger needs many services + running before being usable + <braunr> you'll have to use printf, and there may be steps during bootstrap + when even that isn't available + <mcsim> So I need computer with hardware virtualisation? + <braunr> well, of course stepping works, since the breakpoints are relative + <braunr> no + <braunr> kvm has nothing to do with the problem + <braunr> it's just that the problem appears differently with kvm enabled + <mcsim> ok. thank you. + <braunr> good luck + <antrik> braunr: would it be hard to "fix" gnumach to avoid the + segmentation magic?... + <braunr> antrik: because of the linux drivers, it may + <antrik> or alternatively, implement something in GDB to deal with that?... + <braunr> antrik: i didn't study that part enough to know for sure + <antrik> uhm... why would the Linux drivers depend on that? does Linux also + do such magic?... + <braunr> well it should simply be a matter of shifting the address by a + fixed offset + <braunr> antrik: linux drivers rely on physical memory being allocated + through kmalloc + <braunr> so there must be a direct mapping between virtual kernel memory + and physical memory + <braunr> they don't specifically need that segmentation settings + <braunr> so if you remove the offset implemented through segmentation, you + have to replace it with page mapping + <braunr> and i don't know how much needs to be done for that + <braunr> you also need to link the kernel differently + <antrik> hm, OK + <antrik> so adding GDB support for the offset would probably be easier... + <braunr> yes + <braunr> but using the offset must only be done once segmentation is set up + <braunr> so you must break after gdt_init + <braunr> not on it + <braunr> mcsim: why do you break on these functions btw ? + <mcsim> I just wanted to find out why qemu hangs + <braunr> yes but why those ? + <mcsim> I found out that before gdt_init all workes fine, but after qemu + hangs. So idt_init is just the next function + <braunr> ok + <braunr> and does your patch change something to how segmentation is + initialized ? + <mcsim> now + <mcsim> no + <braunr> try to build it with the regular cflags + <braunr> i don't know if gnumach can work with -O0 + <mcsim> I've tried. But all the same + <mcsim> Regular are -g -O2 + <braunr> can you make your patch available ? + <mcsim> yes + <mcsim> it is available in gnumach repository at savannah + <mcsim> tree mplaneta/libbraunr/master + <antrik> well, if the segmentation stuff is the thing GDB has problems + with, I don't see how it can work without your patch... + <braunr> without ? + <antrik> well, the patch shouldn't affect the segmentation... so I don't + see how it can make a difference + <braunr> he said qemu hanged + <braunr> so let's not introduce gdb yet + <braunr> qemu can hang for other reasons + <antrik> oh, right, without GDB... + <antrik> though if that's what he meant, his statement was very misleading + at least diff --git a/open_issues/default_pager.mdwn b/open_issues/default_pager.mdwn new file mode 100644 index 00000000..9a8e9412 --- /dev/null +++ b/open_issues/default_pager.mdwn @@ -0,0 +1,37 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-08-31 + + <antrik> braunr: do you have any idea what could cause the paging errors + long before swap is exhausted? + <braunr> antrik: not really, but i know every project based on the mach vm + have rewritten their swap pager + <antrik> (and also I/O performance steadily dropping before that point is + reached?) + +[[performance/degradation]], [[ext2fs_page_cache_swapping_leak]]. + + <antrik> hm + <braunr> there could too many things + <antrik> perhaps we could "borrow" from one of them? :-) + <braunr> map entry fragmentation for example + <braunr> the freebsd one is the only possible candidate + <braunr> uvm is too different + <braunr> dragonflybsd maybe, but it's very close to freebsd + <braunr> i didn't look at darwin/xnu + + +# [[trust_the_behavior_of_translators]] 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 new file mode 100644 index 00000000..5bda0213 --- /dev/null +++ b/open_issues/device_drivers_and_io_systems.mdwn @@ -0,0 +1,94 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +This is a collection of resources concerning *device drivers* and *I/O systems* +in general. + +Also see [[user-space device drivers]]. +[[community/gsoc/project ideas/driver glue code]]. + +[[!toc levels=2]] + + +# Documentation + + * [An I/O System for Mach + 3.0](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.3210), + 1991, Alessandro Forin, David Golub, Brian Bershad + + * [Linux Device Driver Emulation in + Mach](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.7252), + 1996, Shantanu Goel, Dan Duchamp + + * [Eliminating receive livelock in an interrupt-driven + kernel](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.127.8257), + 1997, Jeffrey Mogul, Dec Western, Jeffrey C. Mogul, K. K. Ramakrishnan + + * [IO-Lite: A Unified I/O Buffering and Caching + System](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4224), + 1997, Vivek S. Pai, Peter Druschel, Willy Zwaenepoel + + * [The Flux OSKit: A substrate for kernel and language + research](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.118.534), + 1997, Bryan Ford, Godmar Back, Greg Benson, Jay Lepreau, Albert Lin, Olin + Shivers + + * [Reuse Linux Device Drivers in Embedded + Systems](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.6951), + 1998, Chi-wei Yang, Paul C. H. Lee, Ruei-Chuan Chang + + * [THINK: A Software Framework for Component-based Operating System + Kernels](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.133.9239), + 2002, Jean-Philippe Fassino, Jean-Bernard Stefani, Julia Lawall, Gilles + Muller + + * [An I/O Architecture for Microkernel-Based Operating + Systems](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.5.4337), + 2003, Hermann Haertig, Jork Loeser, Jork Löser, Frank Mehnert, Lars + Reuther, Martin Pohlack, Alexander Warg + + * [High-Speed I/O: The Operating System as a Signalling + Mechanism](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.9.6991), + 2003, Matthew Burnside, Angelos D. Keromytis + + * [Unmodified device driver reuse and improved system dependability via + virtual + machines](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.5317), + 2004, Joshua Levasseur, Volkmar Uhlig, Jan Stoess, Stefan Götz + + +# External Projects + + * [[/DDE]] + + * [Building Linux Device Drivers on + FreeBSD](http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html) + + * [Project UDI](http://www.projectudi.org/), a multi-company effort to define + a Uniform Driver Interface + + * [The Free Software Movement and + UDI](http://www.gnu.org/philosophy/udi.html) + + * [OSKit](http://www.cs.utah.edu/flux/oskit/) + + * [Unofficial OSKit source](http://www.nongnu.org/oskit/) on Savannah + + * [[microkernel/Mach]]-like + + It might be possible to integrate these systems' device drivers, as they're + expected to mostly be using the same interfaces as the current in-kernel + Mach drivers are. + + * OSF Mach + + * Darwin diff --git a/open_issues/dir-lookup_authority.mdwn b/open_issues/dir-lookup_authority.mdwn new file mode 100644 index 00000000..64866eb5 --- /dev/null +++ b/open_issues/dir-lookup_authority.mdwn @@ -0,0 +1,68 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <cfhammar> I have discovered a bug in the dir-lookup protocol though + <cfhammar> Currently, I'm investigating the bug a bit further + <cfhammar> when doing dir-lookups with several path components, the look-up is done with the authority of the user who opened the directory, as opposed to the user doing the lookup + <cfhammar> e.g, consider foo/bar/baz, where bar can only be used by its owner and foo and baz are world readable + <cfhammar> if foo is opened, then transferred to another user, he can open baz, which he shouldn't be able to + <cfhammar> this is possible where foo/bar/baz is within a single translator, and the lookup is done in a single dir-lookup + <antrik> cfhammar: I'm not sure this is a bug + <cfhammar> I have a test case that triggers the bug, and another that doesn't which currently confuses me + <antrik> cfhammar: it's probably not very usual to pass around open directory ports; but if somebody does it, it's probably actually desired that it keeps the authority + <antrik> it's kinda consistent with passing normal FDs + <cfhammar> antrik: it should only allow accesses to entries not sub-entries + <cfhammar> antrik: it isn't allowed in Linux atleast, and I'm guessing it's mandated by posix + <cfhammar> also note that a more common scenario is a process that opens a directory and then drops authority + <cfhammar> probably more common, that is + <antrik> cfhammar: I'm not really familiar with directory access functions... I wasn't even aware that it's possible to pass around directory FDs + <antrik> but if it is, it would indeed be good to know what POSIX says about this + <antrik> cfhammar: I don't see how this is related?... + <cfhammar> antrik: after the process has dropped authority it can still make lookups in directories that it should no longer be able to + <antrik> cfhammar: interesting point... + <antrik> cfhammar: do you think this is fixable? + <cfhammar> antrik: Not without (defacto) changing the interface + <cfhammar> e.g only looking up a singe path component at a time + <cfhammar> or doing the auth check lazily on io_reauthenticate + <antrik> cfhammar: yeah, obviously it's not possible without an API change. I just wonder whether it's possible without throwing the current auth/lookup mechanism overboard alltogether... + <cfhammar> antrik: both my solutions are only minor changes to the API, but fairly major in the sense that we need to change all callers :-( + <cfhammar> diskfs_S_dir_lookup is a very large function, for example + <antrik> cfhammar: OK + <antrik> cfhammar: I wonder whether there is a possible transition path without breaking all existing installations... + <cfhammar> we could provide a new RPC while supporting the old one + <cfhammar> note that changing fs.defs only affects glibc and the Hurd, normal apps should be fine + <antrik> cfhammar: have you posted your findings to the ML yet? + <cfhammar> No, I'm still investigating why my second test-case doesn't trigger the bug + <cfhammar> Intrestingly it's the one using all POSIX functions... + <cfhammar> Perhaps its a bug that maskes the lookup bug ;-) + <antrik> I guess there is some quirk which you do not fully understand yet :-) + <cfhammar> Oh, there's always a new quirk to find in the Hurd :-) + <cfhammar> antrik: seems that dir_lookup isn't buggy after all + <cfhammar> antrik: as all FDs are reauthenticated on setauth + <antrik> ah + <cfhammar> antrik: and (presumably) ports are unauthenticated and reauthenticated when transfered + <antrik> yeah, that's the idea behind the auth protocol... + <antrik> users obtain specific capabilities by authenticating generic ports against their own ID + <cfhammar> I didn't really have a coherent view on how open flags are handled on reauth + <cfhammar> it seems open flags always win, so that a O_READ port that is unauthed is still readable + <antrik> not sure what you mean + <cfhammar> if I open a file to read it, then reauth it with a user that isn't permitted to read it, I can still read from it + <cfhammar> (as it should be) + <cfhammar> by contrast permission to do lookups in a directory is determined by who authed it + <cfhammar> so I won't be able to do lookups after a reauth, if it's not permitted by the file bits + <youpi> Mmm, openat should however be able to + <youpi> since you've first opened the directory with the auth + <cfhammar> it isn't since open FDs are reauthed on setauth + <cfhammar> not sure whether it should though, Linux behaves the same way atleast + <cfhammar> though it could be done with POSIX.2008's O_SEARCH open flag diff --git a/open_issues/e2fsck_i_file_acl_hi.mdwn b/open_issues/e2fsck_i_file_acl_hi.mdwn new file mode 100644 index 00000000..d03b733c --- /dev/null +++ b/open_issues/e2fsck_i_file_acl_hi.mdwn @@ -0,0 +1,38 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, unknown channel, unknown date. + + <Duck> something's broken in ext2, fsck, or the like + <Duck> /dev/hd0s1: i_file_acl_hi for inode 81872 (/proc) is 32, shoud be 0. + <Duck> youpi: the other problem is probably related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526524 + <Duck> i'll just check when it is fixed + <antrik> youpi: I've seen a lot of these fsck errors since the upgrade to 1.41.x + <antrik> youpi: seems to happen whenever a passive translator is still active while the machine reboots + <Duck> antrik: ho, so in my example this could be related to procfs then + <antrik> Duck: don't know... I got it with various terminal-related nodes + <antrik> other translators get terminated before ext2 it seems, so the problem doesn't happen there + <antrik> unless the machine crashes of course + <antrik> ah, right, it told you that it's the /proc node :-) + <antrik> was it the only node it complained about? + <antrik> Duck: ^ + <Duck> antrik: yes, the only one + <youpi> so it's most probably i + <youpi> t + <Duck> but currently i don't have much translators around besides the base install + <antrik> that's strange... my theory about translators active at reboot seems wrong then + <youpi> well, maybe procps is not behaving properly + <youpi> procfs* + <antrik> youpi: I doubt it. I regularily get the same issue with various term nodes; and when the machine crashes rather than rebooting cleanly, many other nodes as well + <youpi> k + <antrik> but it's always passive translator nodes + +This is due to an erroneous read/write from e2fsck, see +<http://sourceforge.net/tracker/?func=detail&aid=3379227&group_id=2406&atid=102406>. diff --git a/open_issues/elinks.mdwn b/open_issues/elinks.mdwn new file mode 100644 index 00000000..ee372971 --- /dev/null +++ b/open_issues/elinks.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +IRC, unknown channel, 2008-05-26 and later + + <paakku> In elinks/src/network/state.h, there is an assumption that values of errno are between 0 and 100000. Now looking at glibc-2.5/sysdeps/mach/hurd/bits/errno.h, I see that you're using values outside this range. Have there been problems because of this? + <youpi> eeerf + <youpi> I had never seen a program assuming that + <youpi> that sucks + <paakku> It can be fixed, but that'd require some work, so I'd like to first have a clear idea of the effects. + <youpi> fixed where ? + <paakku> in elinks + <youpi> k + <paakku> by allocating just one number from our enum connection_state for system errors, and then stashing the errno value in a separate variable. + <paakku> Anyway, if you see this cause any user-visible bugs in ELinks, please report. + + <kahmalo> I mentioned here on 2008-05-26 that ELinks assumes errno values are between 0 and 100000 whereas the Hurd uses other values. I fixed this in ELinks last weekend; the most recent 0.12 and 0.13 snapshots should include the fix. If you find any remaining errno assumptions, please post to: http://bugzilla.elinks.cz/show_bug.cgi?id=1013 + <kahmalo> or to one of our mailing lists. + <kahmalo> I guess the pflocal select() bug http://savannah.gnu.org/bugs/?22861 is the primary hindrance to running ELinks on the Hurd. Has any decision been made on how that will be fixed? diff --git a/open_issues/emacs.mdwn b/open_issues/emacs.mdwn new file mode 100644 index 00000000..cdd1b10d --- /dev/null +++ b/open_issues/emacs.mdwn @@ -0,0 +1,1527 @@ +[[!meta copyright="Copyright © 2009 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="GNU Emacs"]] + +[[!tag open_issue_porting]] + +GNU Emacs mostly does work, however there are a few issues. + + * `dired` on a directory hangs. (Use `C-g C-g` to break the unresponsive + operation.) + + * Configuration in `src/s/`: `gnu.h` uses `bsd-common.h`. `gnu-kfreebsd.h` + uses `gnu-linux.h` -- we probably should too. + + * `gnu-linux.h` makes a few things depend on `/proc` (also see + `HAVE_PROCFS`) -- either resort to our own ways, or enhance our + [[hurd/translator/procfs]] accordingly. + + * `sysdep.c` + + * Got a hang when compiling GNU Emacs 23, when it was compiling `.el` to + `.elc` files. Looked like busy-looping inside glibc. This was not + reproducible so far. + + * Debian emacs23_23.1+1-2, grubber, (probably) busy-looping in `ext2fs` on + `/media/data` when resuming emacs23 build in `~/tmp/emacs/emacs23-*/` + (`dpkg-buildpackage -B -uc -nc 2>&1 | tee L`). No modifications to + `emacs23-*` so far, I think. Hangs always in the same place, it seems, and + reproducible. Tarred to `emacs23-23.1+1.tar.bz2` (beware: empty and + zero-permission files: + `emacs23-23.1+1/.pc/debian-site-init-el.diff/lisp/site-init.el`, + `emacs23-23.1+1/.pc/autofiles.diff/src/config.in~`). At hang-time: the + rootfs is fine (`syncfs -c -s /` works; `syncfs` involving `/media/data` + hangs). Plan: GDB on that ext2fs, and see what's hanging / locked. [[!tag + open_issue_hurd]] + + +--- + +# 2010-10-11 + +Apparently, none of the Debian emacs packages are installable at the moment. + +Try to compile bzr trunk. + +System (sort-of) crashed during build. Perhaps while / or shortly after +dumping `src/emacs`, as there was such a zero-sized file. (Log file doesn't +show anything useful.) Removed the truncated `src/emacs`, continued build: + + [...] + Compiling /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el + Parsing *srecode-map-tmp* (LALR)... + Parsing *srecode-map-tmp* (LALR)...done + Segmentation fault + make[2]: *** [cedet/srecode/mode.elc] Error 139 + make[2]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp' + make[1]: *** [compile-main] Error 2 + make[1]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp' + make: *** [lisp] Error 2 + +Command line: + + $ EMACSLOADPATH=/home/tschwinge/tmp/emacs/trunk/lisp LC_ALL=C /home/tschwinge/tmp/emacs/trunk.build/src/emacs -batch --no-site-file -f batch-byte-compile /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el + +GDB: + + Program received signal SIGSEGV, Segmentation fault. + mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343 + 5343 if (STRING_MARKED_P (ptr)) + (gdb) bt + #0 mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343 + #1 0x0818080f in Fgarbage_collect () at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:4993 + #2 0x08196db3 in Ffuncall (nargs=1, args=0x23fce70) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2987 + #3 0x081ce8e1 in Fbyte_code (bytestr=139696577, vector=141708997, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #4 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #5 0x08196bb3 in Ffuncall (nargs=1, args=0x23fcff0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #6 0x081ce8e1 in Fbyte_code (bytestr=139922913, vector=141583493, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #7 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #8 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd170) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #9 0x081ce8e1 in Fbyte_code (bytestr=140515737, vector=141583205, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #10 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #11 0x08196bb3 in Ffuncall (nargs=2, args=0x23fd2f0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #12 0x081ce8e1 in Fbyte_code (bytestr=139911193, vector=139312997, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #13 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #14 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #15 0x081ce8e1 in Fbyte_code (bytestr=136508105, vector=136508125, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #16 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #17 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #18 0x081ce8e1 in Fbyte_code (bytestr=136508849, vector=136508869, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #19 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #20 0x08195bff in apply_lambda (fun=136508805, args=139814646, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 + #21 0x08195ef4 in Feval (form=139814582) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 + #22 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139636697, printflag=0, unibyte=138364586, readfun=138364586, + start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 + #23 0x081bbad7 in Fload (file=140023529, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) + at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 + #24 0x081a1357 in Frequire (feature=141037690, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 + #25 0x08196d83 in Ffuncall (nargs=2, args=0x23fdb90) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 + #26 0x081ce8e1 in Fbyte_code (bytestr=140023705, vector=141489853, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #27 0x08196304 in Feval (form=141177630) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358 + #28 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=140023785, printflag=0, unibyte=138364586, readfun=138364586, + start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 + #29 0x081bbad7 in Fload (file=139743441, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) + at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 + #30 0x081a1357 in Frequire (feature=140528330, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 + #31 0x08196d83 in Ffuncall (nargs=2, args=0x23fe030) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 + #32 0x081ce8e1 in Fbyte_code (bytestr=139743489, vector=139592949, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #33 0x08196304 in Feval (form=139785254) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358 + #34 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139743569, printflag=0, unibyte=138364586, readfun=138364586, + start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 + #35 0x081bbad7 in Fload (file=139985769, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) + at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 + #36 0x081a1357 in Frequire (feature=140528282, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 + #37 0x08196d83 in Ffuncall (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 + #38 0x0819879e in Fapply (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2453 + #39 0x08196e26 in Ffuncall (nargs=3, args=0x23fe5c0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2971 + #40 0x081ce8e1 in Fbyte_code (bytestr=139665665, vector=140243293, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #41 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #42 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe730) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #43 0x081ce8e1 in Fbyte_code (bytestr=139663633, vector=140113917, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #44 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #45 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe8a0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #46 0x081ce8e1 in Fbyte_code (bytestr=139651313, vector=141733317, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #47 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #48 0x08196bb3 in Ffuncall (nargs=1, args=0x23fea20) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #49 0x081961cd in Feval (form=142062606) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2324 + #50 0x08198ec2 in internal_lisp_condition_case (var=139619738, bodyform=142062606, handlers=142059126) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407 + #51 0x081cdb3a in Fbyte_code (bytestr=139651065, vector=138947149, maxdepth=64) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869 + #52 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #53 0x08196bb3 in Ffuncall (nargs=3, args=0x23fed10) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #54 0x081ce8e1 in Fbyte_code (bytestr=139638617, vector=140190309, maxdepth=32) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #55 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #56 0x08195bff in apply_lambda (fun=141815293, args=139024998, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 + #57 0x08195ef4 in Feval (form=139025038) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 + #58 0x08198ec2 in internal_lisp_condition_case (var=138727490, bodyform=139025038, handlers=138994086) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407 + #59 0x081cdb3a in Fbyte_code (bytestr=141397873, vector=139422605, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869 + #60 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #61 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff150) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #62 0x081ce8e1 in Fbyte_code (bytestr=141396361, vector=138448733, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #63 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #64 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff2d0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #65 0x081ce8e1 in Fbyte_code (bytestr=136699577, vector=136699597, maxdepth=40) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #66 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #67 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #68 0x081ce8e1 in Fbyte_code (bytestr=136685793, vector=136685813, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #69 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #70 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #71 0x081ce8e1 in Fbyte_code (bytestr=136683265, vector=136683285, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #72 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #73 0x08195bff in apply_lambda (fun=136683245, args=138364586, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 + #74 0x08195ef4 in Feval (form=138740766) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 + #75 0x0812dd83 in top_level_2 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1336 + #76 0x081951dc in internal_condition_case (bfun=0x812dd70 <top_level_2>, handlers=138394034, hfun=0x8132020 <cmd_error>) + at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1460 + #77 0x08131de5 in top_level_1 (ignore=138364586) at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1344 + #78 0x081952a9 in internal_catch (tag=138392170, func=0x8131d80 <top_level_1>, arg=138364586) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1204 + #79 0x08131e53 in command_loop () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1299 + #80 0x0813220a in recursive_edit_1 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:929 + #81 0x08132332 in Frecursive_edit () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:991 + #82 0x0812727b in main (argc=<value optimized out>, argv=0x23ffad8) at /home/tschwinge/tmp/emacs/trunk/src/emacs.c:1718 + +Next: restarted from scratch, rebuilt without optimizations. +`--prefix=$PWD.install --build=i686-pc-gnu --enable-asserts +--enable-checking=all CFLAGS=-g` + + $ make + [...] + Dumping under the name emacs [sits here for a long time] + + $ vmstat + pagesize: 4K + size: 324M + free: 9.16M + active: 56M + inactive: 242M + wired: 17.6M + zero filled: 8.75G + reactivated: 0 + pageins: 289M + pageouts: 371M + page faults: 12508128 + cow faults: 1411724 + memobj hit ratio: 99% + swap size: 512M + swap free: 512M + +Apparently low memory, but doesn't swap out. + +Uses a lot of CPU time, as observed with `xm top`. + +Creating another `screen` window as user tschwinge doesn't get to the shell +prompt. + +Running `vmstat` works in a `screen` window that is already open, but running +`ps -Af` just hangs; adding `-M` helps. + +Perhaps the /media/data/ file system (which backs /home/) is in a inconsistent +state / deadlocked? + +More specifically, this does not work / does not exit: + + login> syncfs -s -c /media/data/ & + [2] 10785 + +But this works: + + login> syncfs -s -c / & + [3] 10786 + login> + [3]+ Done syncfs -s -c / + +Thus, the rootfs still is responsive; /media/data/ is not. + + login> ps -F hurd-long -T -M -w -A & + [4] 10796 + login> PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 0 0 1 1 1 16 132M 1M 0.0 0:04.84 0:54.84 /hurd/proc + 0 0.0 0:00.00 0:00.13 + 1 0.0 0:00.30 0:03.55 + 2 0.0 0:00.30 0:04.21 + 3 0.0 0:00.65 0:06.88 + 4 0.0 0:00.02 0:00.31 + 5 0.0 0:00.32 0:03.72 + 6 0.0 0:00.00 0:00.23 + 7 0.0 0:00.00 0:00.03 + 8 0.0 0:00.30 0:03.17 + 9 0.0 0:00.47 0:04.69 + 10 0.0 0:00.62 0:06.42 + 11 0.0 0:00.40 0:05.91 + 12 0.0 0:00.47 0:04.18 + 13 0.0 0:00.10 0:00.73 + 14 0.0 0:00.56 0:05.97 + 15 0.0 0:00.26 0:04.61 + 1 0 1 1 1 1 146M 368K 0.0 0:00.00 0:00.03 /hurd/init root=device:hd0 + 0 0.0 0:00.00 0:00.03 + 2 - 1 1 1 7 418M 19.5M 0.0 0:00.00 0:12.16 root=device:hd0 + 0 0.0 0:00.00 0:00.00 + 1 92.6 0:00.00 46:33.66 + 2 0.0 0:00.00 0:12.07 + 3 0.0 0:00.00 0:00.05 + 4 0.0 0:00.00 0:00.02 + 5 0.0 0:00.00 0:00.00 + 6 0.0 0:00.00 0:00.01 + 3 0 1 1 1 173 409M 15.7M 0.2 4:39.39 34:08.86 ext2fs -A --multiboot-command-line=root=device:hd0 --host-priv-port=1 --device-master-port=2 -- + [165CM-exec-server-task=3 -T typed device:hd0 + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:21.78 2:32.67 + 2 0.0 0:00.15 0:01.33 + 3 0.0 0:00.07 0:01.13 + 4 0.0 0:22.09 2:32.56 + 5 0.0 0:00.11 0:01.30 + 6 0.0 0:21.57 2:32.78 + 7 0.2 0:04.10 0:54.37 + 8 0.0 0:00.00 0:00.01 + 9 0.0 0:20.96 2:30.00 + 10 0.0 0:00.09 0:01.05 + 11 0.0 0:00.09 0:00.94 + 12 0.0 0:21.59 2:32.40 + 13 0.0 0:21.50 2:32.02 + 14 0.0 0:00.00 0:00.92 + 15 0.0 0:00.07 0:00.60 + 16 0.0 0:00.09 0:00.86 + 17 0.0 0:00.04 0:00.88 + 18 0.0 0:00.13 0:00.91 + 19 0.0 0:00.04 0:00.91 + 20 0.0 0:00.02 0:00.89 + 21 0.0 0:00.08 0:00.97 + 22 0.0 0:00.05 0:00.84 + 23 0.0 0:00.04 0:00.86 + 24 0.0 0:00.09 0:00.86 + 25 0.0 0:00.11 0:00.88 + 26 0.0 0:00.04 0:00.64 + 27 0.0 0:21.10 2:32.22 + 28 0.0 0:20.32 2:29.92 + 29 0.0 0:20.58 2:31.51 + 30 0.0 0:20.50 2:32.72 + 31 0.0 0:21.05 2:30.05 + 32 0.0 0:19.78 2:33.40 + 33 0.0 0:20.55 2:31.88 + 34 0.0 0:00.00 0:00.06 + 35 0.0 0:00.00 0:00.07 + 36 0.0 0:00.00 0:00.02 + 37 0.0 0:00.01 0:00.05 + 38 0.0 0:00.00 0:00.03 + 39 0.0 0:00.00 0:00.02 + 40 0.0 0:00.00 0:00.06 + 41 0.0 0:00.02 0:00.02 + 42 0.0 0:00.00 0:00.03 + 43 0.0 0:00.00 0:00.05 + 44 0.0 0:00.00 0:00.07 + 45 0.0 0:00.00 0:00.02 + 46 0.0 0:00.00 0:00.02 + 47 0.0 0:00.00 0:00.04 + 48 0.0 0:00.00 0:00.03 + 49 0.0 0:00.00 0:00.03 + 50 0.0 0:00.00 0:00.05 + 51 0.0 0:00.00 0:00.05 + 52 0.0 0:00.00 0:00.04 + 53 0.0 0:00.00 0:00.04 + 54 0.0 0:00.00 0:00.02 + 55 0.0 0:00.00 0:00.03 + 56 0.0 0:00.01 0:00.01 + 57 0.0 0:00.03 0:00.01 + 58 0.0 0:00.01 0:00.00 + 59 0.0 0:00.00 0:00.00 + 60 0.0 0:00.00 0:00.00 + 61 0.0 0:00.00 0:00.03 + 62 0.0 0:00.00 0:00.00 + 63 0.0 0:00.00 0:00.08 + 64 0.0 0:00.00 0:00.06 + 65 0.0 0:00.01 0:00.00 + 66 0.0 0:00.00 0:00.07 + 67 0.0 0:00.00 0:00.01 + 68 0.0 0:00.02 0:00.02 + 69 0.0 0:00.01 0:00.02 + 70 0.0 0:00.01 0:00.01 + 71 0.0 0:00.01 0:00.04 + 72 0.0 0:00.00 0:00.01 + 73 0.0 0:00.01 0:00.00 + 74 0.0 0:00.00 0:00.06 + 75 0.0 0:00.00 0:00.04 + 76 0.0 0:00.02 0:00.05 + 77 0.0 0:00.00 0:00.03 + 78 0.0 0:00.00 0:00.02 + 79 0.0 0:00.00 0:00.05 + 80 0.0 0:00.01 0:00.00 + 81 0.0 0:00.00 0:00.02 + 82 0.0 0:00.00 0:00.03 + 83 0.0 0:00.00 0:00.00 + 84 0.0 0:00.00 0:00.00 + 85 0.0 0:00.00 0:00.04 + 86 0.0 0:00.00 0:00.04 + 87 0.0 0:00.00 0:00.02 + 88 0.0 0:00.01 0:00.00 + 89 0.0 0:00.00 0:00.04 + 90 0.0 0:00.00 0:00.04 + 91 0.0 0:00.00 0:00.05 + 92 0.0 0:00.00 0:00.02 + 93 0.0 0:00.00 0:00.03 + 94 0.0 0:00.00 0:00.02 + 95 0.0 0:00.00 0:00.01 + 96 0.0 0:00.00 0:00.02 + 97 0.0 0:00.00 0:00.03 + 98 0.0 0:00.00 0:00.05 + 99 0.0 0:00.00 0:00.04 + 100 0.0 0:00.00 0:00.03 + 101 0.0 0:00.00 0:00.01 + 102 0.0 0:00.00 0:00.01 + 103 0.0 0:00.00 0:00.05 + 104 0.0 0:00.00 0:00.06 + 105 0.0 0:00.01 0:00.04 + 106 0.0 0:00.00 0:00.00 + 107 0.0 0:00.01 0:00.02 + 108 0.0 0:00.00 0:00.00 + 109 0.0 0:00.00 0:00.02 + 110 0.0 0:00.00 0:00.01 + 111 0.0 0:00.00 0:00.02 + 112 0.0 0:00.01 0:00.04 + 113 0.0 0:00.01 0:00.01 + 114 0.0 0:00.00 0:00.02 + 115 0.0 0:00.01 0:00.02 + 116 0.0 0:00.01 0:00.03 + 117 0.0 0:00.00 0:00.03 + 118 0.0 0:00.01 0:00.01 + 119 0.0 0:00.00 0:00.01 + 120 0.0 0:00.00 0:00.05 + 121 0.0 0:00.00 0:00.02 + 122 0.0 0:00.00 0:00.02 + 123 0.0 0:00.00 0:00.04 + 124 0.0 0:00.00 0:00.04 + 125 0.0 0:00.00 0:00.02 + 126 0.0 0:00.00 0:00.02 + 127 0.0 0:00.01 0:00.01 + 128 0.0 0:00.00 0:00.01 + 129 0.0 0:00.01 0:00.03 + 130 0.0 0:00.01 0:00.05 + 131 0.0 0:00.00 0:00.02 + 132 0.0 0:00.00 0:00.03 + 133 0.0 0:00.00 0:00.03 + 134 0.0 0:00.00 0:00.02 + 135 0.0 0:00.00 0:00.00 + 136 0.0 0:00.00 0:00.01 + 137 0.0 0:00.01 0:00.03 + 138 0.0 0:00.00 0:00.03 + 139 0.0 0:00.00 0:00.02 + 140 0.0 0:00.01 0:00.01 + 141 0.0 0:00.01 0:00.02 + 142 0.0 0:00.00 0:00.00 + 143 0.0 0:00.00 0:00.02 + 144 0.0 0:00.01 0:00.00 + 145 0.0 0:00.00 0:00.01 + 146 0.0 0:00.00 0:00.00 + 147 0.0 0:00.00 0:00.00 + 148 0.0 0:00.00 0:00.03 + 149 0.0 0:00.00 0:00.00 + 150 0.0 0:00.00 0:00.01 + 151 0.0 0:00.00 0:00.00 + 152 0.0 0:00.00 0:00.01 + 153 0.0 0:00.00 0:00.00 + 154 0.0 0:00.00 0:00.00 + 155 0.0 0:00.00 0:00.00 + 156 0.0 0:00.00 0:00.00 + 157 0.0 0:00.00 0:00.01 + 158 0.0 0:00.00 0:00.00 + 159 0.0 0:00.00 0:00.01 + 160 0.0 0:00.00 0:00.01 + 161 0.0 0:00.00 0:00.00 + 162 0.0 0:00.00 0:00.00 + 163 0.0 0:00.00 0:00.00 + 164 0.0 0:00.00 0:00.01 + 165 0.0 0:00.00 0:00.00 + 166 0.0 0:00.00 0:00.00 + 167 0.0 0:00.00 0:00.00 + 168 0.0 0:00.00 0:00.00 + 169 0.0 0:00.00 0:00.00 + 170 0.0 0:00.00 0:00.00 + 171 0.0 0:00.00 0:00.00 + 172 0.0 0:00.00 0:00.00 + 4 0 3 1 1 6 131M 1.32M 0.0 0:02.20 0:26.26 /hurd/exec + 0 0.0 0:00.43 0:05.32 + 1 0.0 0:00.41 0:05.54 + 2 0.0 0:00.44 0:05.38 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.45 0:05.05 + 5 0.0 0:00.44 0:04.95 + 5 0 1 1 1 6 130M 580K 0.0 0:01.17 0:14.92 /hurd/auth + 0 0.0 0:00.20 0:02.99 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.24 0:03.03 + 3 0.0 0:00.18 0:02.86 + 4 0.0 0:00.22 0:03.01 + 5 0.0 0:00.31 0:03.01 + 6 0 1 6 6 2 147M 1.09M 0.0 0:00.01 0:00.13 /bin/bash /libexec/runsystem root=device:hd0 + 0 0.0 0:00.01 0:00.13 + 1 0.0 0:00.00 0:00.00 + 7 0 3 1 1 7 130M 880K 0.1 0:00.35 0:10.10 /hurd/term /dev/console device console + 0 0.0 0:00.07 0:01.15 + 1 0.0 0:00.00 0:00.01 + 2 0.0 0:00.14 0:03.10 + 3 0.1 0:00.10 0:01.87 + 4 0.0 0:00.01 0:00.50 + 5 0.0 0:00.00 0:01.54 + 6 0.0 0:00.02 0:01.91 + 9 0 3 1 1 19 131M 1.13M 0.0 0:05.41 1:17.29 /hurd/pflocal + 0 0.0 0:00.06 0:00.48 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.05 0:00.48 + 3 0.0 0:00.78 0:09.10 + 4 0.0 0:00.49 0:06.13 + 5 0.0 0:00.56 0:07.07 + 6 0.0 0:00.30 0:03.41 + 7 0.0 0:00.47 0:05.58 + 8 0.0 0:00.27 0:06.00 + 9 0.0 0:00.04 0:00.47 + 10 0.0 0:00.43 0:06.17 + 11 0.0 0:00.70 0:09.21 + 12 0.0 0:00.00 0:00.04 + 13 0.0 0:00.59 0:10.75 + 14 0.0 0:00.14 0:01.86 + 15 0.0 0:00.04 0:01.49 + 16 0.0 0:00.02 0:00.76 + 17 0.0 0:00.22 0:05.59 + 18 0.0 0:00.16 0:02.62 + 12 0 1 12 12 6 129M 1.2M 0.0 0:00.00 0:00.06 /hurd/mach-defpager + 0 0.0 0:00.00 0:00.06 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.00 + 5 0.0 0:00.00 0:00.00 + 14 0 3 1 1 3 131M 504K 0.0 0:00.00 0:00.05 /hurd/storeio hd1 + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 18 0 3 1 1 3 131M 512K 0.0 0:00.39 0:06.71 /hurd/storeio hd0 + 0 0.0 0:00.13 0:01.66 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.25 0:05.04 + 19 0 3 1 1 3 131M 656K 0.0 0:00.27 0:04.89 /hurd/storeio hd2 + 0 0.0 0:00.10 0:01.48 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.16 0:03.41 + 21 0 3 1 1 4 130M 648K 0.0 0:00.55 0:06.94 /hurd/null + 0 0.0 0:00.24 0:02.09 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.08 0:02.16 + 3 0.0 0:00.22 0:02.68 + 22 0 3 1 1 4 130M 820K 0.0 0:00.00 0:00.05 /hurd/procfs + 0 0.0 0:00.00 0:00.04 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 71 1 1 71 71 2 146M 728K 0.0 0:00.00 0:00.03 /usr/sbin/atd + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 77 0 3 1 1 4 130M 896K 0.0 0:00.00 0:00.02 /hurd/streamio kmsg + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 117 0 1 117 117 2 146M 1.02M 0.0 0:00.00 0:00.04 /usr/sbin/cron + 0 0.0 0:00.00 0:00.04 + 1 0.0 0:00.00 0:00.00 + 122 101 1 122 122 2 7.75M 1.07M 0.0 0:00.00 0:00.05 /usr/bin/dbus-daemon --system + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 128 0 3 1 1 4 130M 908K 0.0 0:00.00 0:00.02 /hurd/fifo + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 131 8 1 6 6 2 147M 880K 0.0 0:00.01 0:00.07 /usr/sbin/nullmailer-send -d + 0 0.0 0:00.01 0:00.07 + 1 0.0 0:00.00 0:00.00 + 139 0 3 1 1 19 133M 2.19M 0.3 0:18.66 1:17.98 /hurd/pfinet -i eth0 -a 192.168.10.63 -g 192.168.10.1 -m 255.255.255.0 + 0 0.0 0:00.01 0:00.03 + 1 0.0 0:00.00 0:00.00 + 2 0.1 0:12.72 0:14.56 + 3 0.2 0:01.65 0:12.23 + 4 0.0 0:01.67 0:18.56 + 5 0.0 0:00.50 0:05.93 + 6 0.0 0:00.40 0:06.16 + 7 0.0 0:00.57 0:05.95 + 8 0.0 0:00.30 0:04.15 + 9 0.0 0:00.15 0:01.92 + 10 0.0 0:00.13 0:01.45 + 11 0.0 0:00.14 0:01.47 + 12 0.0 0:00.07 0:01.06 + 13 0.0 0:00.08 0:01.23 + 14 0.0 0:00.08 0:00.92 + 15 0.0 0:00.03 0:00.63 + 16 0.0 0:00.03 0:00.45 + 17 0.0 0:00.05 0:00.72 + 18 0.0 0:00.03 0:00.49 + 140 0 3 1 1 3 131M 1.16M 0.0 0:00.00 0:00.05 /hurd/storeio --no-cache time + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 142 0 1 142 142 2 10.5M 1.23M 0.0 0:00.00 0:00.05 /usr/sbin/sshd + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 157 0 3 1 1 6 130M 1M 0.0 0:00.02 0:00.01 /hurd/term /dev/tty1 hurdio /dev/vcs/1/console + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.01 + 5 0.0 0:00.01 0:00.00 + 158 0 6 158 158 2 146M 824K 0.0 0:00.00 0:00.01 /libexec/runttys + 0 0.0 0:00.00 0:00.01 + 1 0.0 0:00.00 0:00.00 + 159 0 3 1 1 15 133M 1.67M 0.0 0:00.01 0:00.06 /hurd/console + 0 0.0 0:00.01 0:00.02 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.01 + 5 0.0 0:00.00 0:00.00 + 6 0.0 0:00.00 0:00.00 + 7 0.0 0:00.00 0:00.02 + 8 0.0 0:00.00 0:00.00 + 9 0.0 0:00.00 0:00.00 + 10 0.0 0:00.00 0:00.00 + 11 0.0 0:00.00 0:00.00 + 12 0.0 0:00.00 0:00.01 + 13 0.0 0:00.00 0:00.00 + 14 0.0 0:00.00 0:00.00 + 160 - 158 160 160 2 147M 1.82M 0.0 0:00.02 0:00.16 -login prompt (bash) + 0 0.0 0:00.02 0:00.14 + 1 0.0 0:00.00 0:00.02 + 161 - 158 161 161 2 147M 1.78M 0.0 0:00.00 0:00.07 -login prompt (bash) + 0 0.0 0:00.00 0:00.07 + 1 0.0 0:00.00 0:00.00 + 162 - 158 162 162 2 147M 1.78M 0.0 0:00.01 0:00.07 -login prompt (bash) + 0 0.0 0:00.01 0:00.07 + 1 0.0 0:00.00 0:00.00 + 163 - 158 163 163 2 147M 1.78M 0.0 0:00.00 0:00.03 -login prompt (bash) + 0 0.0 0:00.00 0:00.03 + 1 0.0 0:00.00 0:00.00 + 164 - 158 164 164 2 147M 1.78M 0.0 0:00.02 0:00.03 -login prompt (bash) + 0 0.0 0:00.02 0:00.03 + 1 0.0 0:00.00 0:00.00 + 165 - 158 165 165 2 147M 1.78M 0.0 0:00.00 0:00.08 -login prompt (bash) + 0 0.0 0:00.00 0:00.08 + 1 0.0 0:00.00 0:00.00 + 166 - 158 166 166 2 147M 1.78M 0.0 0:00.01 0:00.01 -login prompt (bash) + 0 0.0 0:00.01 0:00.01 + 1 0.0 0:00.00 0:00.00 + 167 0 3 1 1 6 130M 1016K 0.0 0:00.01 0:00.11 /hurd/term /dev/tty2 hurdio /dev/vcs/2/console + 0 0.0 0:00.01 0:00.06 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.01 + 4 0.0 0:00.00 0:00.03 + 5 0.0 0:00.00 0:00.00 + 168 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.04 /hurd/term /dev/tty3 hurdio /dev/vcs/3/console + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.01 + 4 0.0 0:00.00 0:00.00 + 5 0.0 0:00.00 0:00.01 + 169 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.04 /hurd/term /dev/tty5 hurdio /dev/vcs/5/console + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.04 + 5 0.0 0:00.00 0:00.00 + 170 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.05 /hurd/term /dev/tty4 hurdio /dev/vcs/4/console + 0 0.0 0:00.00 0:00.04 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.01 + 5 0.0 0:00.00 0:00.00 + 171 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.01 /hurd/term /dev/tty6 hurdio /dev/vcs/6/console + 0 0.0 0:00.00 0:00.01 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.00 + 5 0.0 0:00.00 0:00.00 + 172 0 3 1 1 4 130M 892K 0.0 0:00.00 0:00.01 /hurd/password + 0 0.0 0:00.00 0:00.01 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 173 0 142 173 173 3 10.7M 3.09M 0.0 0:02.09 0:12.63 /usr/sbin/sshd -R + 0 0.0 0:02.09 0:12.63 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 174 0 3 1 1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2 + 0 0.0 0:00.01 0:00.03 + 1 0.0 0:00.00 0:00.00 + 2 0.0 1:34.24 6:26.66 + 3 0.0 0:00.04 0:00.31 + 4 0.0 0:00.13 0:00.47 + 5 0.0 0:00.05 0:00.57 + 6 0.0 1:36.91 6:26.41 + 7 0.0 0:12.98 0:34.83 + 8 0.0 1:37.85 6:26.20 + 9 0.0 1:35.07 6:17.07 + 10 0.0 0:00.05 0:00.50 + 11 0.0 0:00.04 0:00.48 + 12 0.0 0:00.07 0:00.55 + 13 0.0 0:00.03 0:00.46 + 14 0.0 0:00.03 0:00.42 + 15 0.0 0:00.06 0:00.32 + 16 0.0 0:00.05 0:00.56 + 17 0.0 0:00.05 0:00.50 + 18 0.0 0:00.05 0:00.48 + 19 0.0 0:00.03 0:00.37 + 20 0.0 0:00.08 0:00.48 + 21 0.0 0:00.01 0:00.52 + 22 0.0 0:00.02 0:00.44 + 23 0.0 0:00.02 0:00.44 + 24 0.0 0:00.03 0:00.31 + 25 0.0 0:00.05 0:00.32 + 26 0.0 0:00.04 0:00.37 + 27 0.0 0:00.00 0:00.31 + 28 0.0 0:00.03 0:00.23 + 29 0.0 0:00.05 0:00.33 + 30 0.0 0:00.04 0:00.31 + 31 0.0 0:00.01 0:00.29 + 32 0.0 0:00.07 0:00.27 + 33 0.0 0:00.05 0:00.28 + 34 0.0 0:00.04 0:00.23 + 35 0.0 0:00.04 0:00.46 + 36 0.0 0:00.02 0:00.31 + 37 0.0 0:00.02 0:00.38 + 38 0.0 0:00.06 0:00.29 + 39 0.0 0:00.03 0:00.22 + 40 0.0 0:00.02 0:00.28 + 41 0.0 0:00.03 0:00.26 + 42 0.0 0:00.05 0:00.39 + 43 0.0 0:00.06 0:00.37 + 44 0.0 0:00.03 0:00.36 + 45 0.0 0:00.04 0:00.20 + 46 0.0 0:00.02 0:00.28 + 47 0.0 0:00.01 0:00.29 + 48 0.0 0:00.03 0:00.23 + 49 0.0 0:00.04 0:00.22 + 50 0.0 0:00.07 0:00.25 + 51 0.0 0:00.00 0:00.33 + 52 0.0 0:00.05 0:00.49 + 53 0.0 0:00.02 0:00.31 + 54 0.0 0:00.00 0:00.27 + 55 0.0 0:00.06 0:00.25 + 56 0.0 0:00.05 0:00.35 + 57 0.0 0:00.01 0:00.28 + 58 0.0 0:00.06 0:00.25 + 59 0.0 0:00.05 0:00.30 + 60 0.0 0:00.03 0:00.36 + 61 0.0 0:00.04 0:00.31 + 62 0.0 0:00.05 0:00.18 + 63 0.0 0:00.02 0:00.31 + 64 0.0 0:00.00 0:00.27 + 65 0.0 0:00.02 0:00.26 + 66 0.0 0:00.00 0:00.31 + 67 0.0 0:00.00 0:00.15 + 68 0.0 0:00.04 0:00.32 + 69 0.0 0:00.04 0:00.21 + 70 0.0 0:00.01 0:00.31 + 71 0.0 0:00.05 0:00.22 + 72 0.0 0:00.01 0:00.28 + 73 0.0 0:00.04 0:00.31 + 74 0.0 0:00.06 0:00.20 + 75 0.0 0:00.04 0:00.38 + 76 0.0 0:00.03 0:00.37 + 77 0.0 0:00.06 0:00.32 + 78 0.0 0:00.04 0:00.22 + 79 0.0 0:00.04 0:00.25 + 80 0.0 0:00.04 0:00.29 + 81 0.0 0:00.07 0:00.31 + 82 0.0 0:00.04 0:00.27 + 83 0.0 0:00.04 0:00.23 + 84 0.0 0:00.02 0:00.37 + 85 0.0 0:00.03 0:00.24 + 86 0.0 0:00.01 0:00.29 + 87 0.0 0:00.03 0:00.24 + 88 0.0 0:00.01 0:00.31 + 89 0.0 0:00.03 0:00.39 + 90 0.0 0:00.00 0:00.30 + 91 0.0 0:00.03 0:00.32 + 92 0.0 0:00.00 0:00.24 + 93 0.0 0:00.03 0:00.32 + 94 0.0 0:00.04 0:00.30 + 95 0.0 0:00.00 0:00.33 + 96 0.0 0:00.02 0:00.24 + 97 0.0 0:00.01 0:00.26 + 98 0.0 0:00.04 0:00.33 + 99 0.0 0:00.03 0:00.26 + 100 0.0 0:00.05 0:00.29 + 101 0.0 0:00.05 0:00.34 + 102 0.0 0:00.04 0:00.38 + 103 0.0 0:00.00 0:00.22 + 104 0.0 0:00.03 0:00.38 + 105 0.0 0:00.01 0:00.43 + 106 0.0 0:00.03 0:00.37 + 107 0.0 0:00.05 0:00.31 + 108 0.0 0:00.02 0:00.31 + 109 0.0 0:00.00 0:00.26 + 110 0.0 0:00.03 0:00.27 + 111 0.0 0:00.03 0:00.25 + 112 0.0 0:00.02 0:00.30 + 113 0.0 0:00.05 0:00.23 + 114 0.0 0:00.02 0:00.32 + 115 0.0 0:00.02 0:00.29 + 116 0.0 0:00.04 0:00.22 + 117 0.0 0:00.04 0:00.26 + 118 0.0 0:00.02 0:00.36 + 119 0.0 0:00.03 0:00.31 + 120 0.0 0:00.04 0:00.26 + 121 0.0 0:00.05 0:00.28 + 122 0.0 0:00.01 0:00.27 + 123 0.0 0:00.03 0:00.34 + 124 0.0 0:00.03 0:00.36 + 125 0.0 0:00.02 0:00.33 + 126 0.0 0:00.04 0:00.36 + 127 0.0 0:00.00 0:00.41 + 128 0.0 0:00.02 0:00.33 + 129 0.0 0:00.07 0:00.32 + 130 0.0 0:00.03 0:00.29 + 131 0.0 0:00.00 0:00.34 + 132 0.0 0:00.04 0:00.28 + 133 0.0 0:00.04 0:00.24 + 134 0.0 0:00.03 0:00.35 + 135 0.0 0:00.04 0:00.38 + 136 0.0 0:00.04 0:00.37 + 137 0.0 0:00.04 0:00.26 + 138 0.0 0:00.00 0:00.26 + 139 0.0 0:00.06 0:00.40 + 140 0.0 1:23.58 6:28.86 + 141 0.0 0:25.74 1:55.97 + 142 0.0 0:00.00 0:00.00 + 143 0.0 0:00.00 0:00.00 + 144 0.0 0:00.00 0:00.00 + 145 0.0 0:00.00 0:00.00 + 146 0.0 0:00.00 0:00.00 + 147 0.0 0:00.00 0:00.00 + 148 0.0 0:00.00 0:00.00 + 149 0.0 0:00.00 0:00.00 + 150 0.0 0:00.00 0:00.00 + 151 0.0 0:00.00 0:00.00 + 152 0.0 0:00.00 0:00.00 + 153 0.0 0:00.00 0:00.00 + 154 0.0 0:00.00 0:00.00 + 155 0.0 0:00.00 0:00.00 + 156 0.0 0:00.00 0:00.00 + 157 0.0 0:00.00 0:00.00 + 158 0.0 0:00.00 0:00.00 + 159 0.0 0:00.00 0:00.00 + 160 0.0 0:00.00 0:00.00 + 161 0.0 0:00.00 0:00.00 + 162 0.0 0:00.00 0:00.00 + 163 0.0 0:00.00 0:00.00 + 164 0.0 0:00.00 0:00.00 + 165 0.0 0:00.00 0:00.00 + 166 0.0 0:00.00 0:00.00 + 167 0.0 0:00.00 0:00.00 + 168 0.0 0:00.00 0:00.00 + 169 0.0 0:00.00 0:00.00 + 170 0.0 0:00.00 0:00.00 + 171 0.0 0:00.00 0:00.00 + 172 0.0 0:00.00 0:00.00 + 173 0.0 0:00.00 0:00.00 + 174 0.0 0:00.00 0:00.00 + 175 0.0 0:00.00 0:00.00 + 176 0.0 0:00.00 0:00.00 + 177 0.0 0:00.00 0:00.00 + 178 0.0 0:00.00 0:00.00 + 179 0.0 0:00.00 0:00.00 + 180 0.0 0:00.00 0:00.00 + 181 0.0 0:00.00 0:00.00 + 182 0.0 0:00.00 0:00.00 + 183 0.0 0:00.00 0:00.00 + 184 0.0 0:00.00 0:00.00 + 185 0.0 0:00.00 0:00.00 + 186 0.0 0:00.00 0:00.00 + 187 0.0 0:00.00 0:00.00 + 188 0.0 0:00.00 0:00.00 + 189 0.0 0:00.00 0:00.00 + 190 0.0 0:00.00 0:00.00 + 191 0.0 0:00.00 0:00.00 + 192 0.0 0:00.00 0:00.00 + 193 0.0 0:00.00 0:00.00 + 194 0.0 0:00.00 0:00.00 + 195 0.0 0:00.00 0:00.00 + 196 0.0 0:00.00 0:00.00 + 197 0.0 0:00.00 0:00.00 + 198 0.0 0:00.00 0:00.00 + 199 0.0 0:00.00 0:00.00 + 200 0.0 0:00.00 0:00.00 + 201 0.0 0:00.00 0:00.00 + 202 0.0 0:00.00 0:00.00 + 203 0.0 0:00.00 0:00.00 + 204 0.0 0:00.00 0:00.00 + 205 0.0 0:00.00 0:00.00 + 206 0.0 0:00.00 0:00.00 + 207 0.0 0:00.00 0:00.00 + 208 0.0 0:00.00 0:00.00 + 209 0.0 0:00.00 0:00.00 + 210 0.0 0:00.00 0:00.00 + 211 0.0 0:00.00 0:00.00 + 212 0.0 0:00.00 0:00.00 + 213 0.0 0:00.00 0:00.00 + 214 0.0 0:00.00 0:00.00 + 215 0.0 0:00.00 0:00.00 + 216 0.0 0:00.00 0:00.00 + 217 0.0 0:00.00 0:00.00 + 218 0.0 0:00.00 0:00.00 + 219 0.0 0:00.00 0:00.00 + 220 0.0 0:00.00 0:00.00 + 221 0.0 0:00.00 0:00.00 + 222 0.0 0:00.00 0:00.00 + 223 0.0 0:00.00 0:00.00 + 224 0.0 0:00.00 0:00.00 + 225 0.0 0:00.00 0:00.00 + 226 0.0 0:00.00 0:00.00 + 227 0.0 0:00.00 0:00.00 + 228 0.0 0:00.00 0:00.00 + 229 0.0 0:00.00 0:00.00 + 230 0.0 0:00.00 0:00.00 + 231 0.0 0:00.00 0:00.00 + 232 0.0 0:00.00 0:00.00 + 233 0.0 0:00.00 0:00.00 + 234 0.0 0:00.00 0:00.00 + 235 0.0 0:00.00 0:00.00 + 236 0.0 0:00.00 0:00.00 + 237 0.0 0:00.00 0:00.00 + 238 0.0 0:00.00 0:00.00 + 239 0.0 0:00.00 0:00.00 + 240 0.0 0:00.00 0:00.00 + 241 0.0 0:00.00 0:00.00 + 242 0.0 0:00.00 0:00.00 + 243 0.0 0:00.00 0:00.00 + 244 0.0 0:00.00 0:00.00 + 245 0.0 0:00.00 0:00.00 + 246 0.0 0:00.00 0:00.00 + 247 0.0 0:00.00 0:00.00 + 248 0.0 0:00.00 0:00.00 + 249 0.0 0:00.00 0:00.00 + 250 0.0 0:00.00 0:00.00 + 251 0.0 0:00.00 0:00.00 + 252 0.0 0:00.00 0:00.00 + 253 0.0 0:00.00 0:00.00 + 254 0.0 0:00.00 0:00.00 + 255 0.0 0:00.00 0:00.00 + 256 0.0 0:00.00 0:00.00 + 257 0.0 0:00.00 0:00.00 + 258 0.0 0:00.00 0:00.00 + 259 0.0 0:00.00 0:00.00 + 260 0.0 0:00.00 0:00.00 + 261 0.0 0:00.00 0:00.00 + 262 0.0 0:00.00 0:00.00 + 263 0.0 0:00.00 0:00.00 + 264 0.0 0:00.00 0:00.00 + 265 0.0 0:00.00 0:00.00 + 266 0.0 0:00.00 0:00.00 + 267 0.0 0:00.00 0:00.00 + 268 0.0 0:00.00 0:00.00 + 269 0.0 0:00.00 0:00.00 + 270 0.0 0:00.00 0:00.00 + 271 0.0 0:00.00 0:00.00 + 272 0.0 0:00.00 0:00.00 + 273 0.0 0:00.00 0:00.00 + 274 0.0 0:00.00 0:00.00 + 275 0.0 0:00.00 0:00.00 + 276 0.0 0:00.00 0:00.00 + 277 0.0 0:00.00 0:00.00 + 278 0.0 0:00.00 0:00.00 + 279 0.0 0:00.00 0:00.00 + 280 0.0 0:00.00 0:00.00 + 281 0.0 0:00.00 0:00.00 + 282 0.0 0:00.00 0:00.00 + 283 0.0 0:00.00 0:00.00 + 284 0.0 0:00.00 0:00.00 + 285 0.0 0:00.00 0:00.00 + 286 0.0 0:00.00 0:00.00 + 287 0.0 0:00.00 0:00.00 + 288 0.0 0:00.00 0:00.00 + 289 0.0 0:00.00 0:00.00 + 290 0.0 0:00.00 0:00.00 + 291 0.0 0:00.00 0:00.00 + 292 0.0 0:00.00 0:00.00 + 293 0.0 0:00.00 0:00.00 + 294 0.0 0:00.00 0:00.00 + 295 0.0 0:00.00 0:00.00 + 296 0.0 0:00.00 0:00.00 + 297 0.0 0:00.00 0:00.00 + 298 0.0 0:00.00 0:00.00 + 299 0.0 0:00.00 0:00.00 + 300 0.0 0:00.00 0:00.00 + 301 0.0 0:00.00 0:00.00 + 302 0.0 0:00.00 0:00.00 + 303 0.0 0:00.00 0:00.00 + 304 0.0 0:00.00 0:00.00 + 305 0.0 0:00.00 0:00.00 + 306 0.0 0:00.00 0:00.00 + 307 0.0 0:00.00 0:00.00 + 308 0.0 0:00.00 0:00.00 + 309 0.0 0:00.00 0:00.00 + 310 0.0 0:00.00 0:00.00 + 311 0.0 0:00.00 0:00.00 + 312 0.0 0:00.00 0:00.00 + 313 0.0 0:00.00 0:00.00 + 314 0.0 0:00.00 0:00.00 + 315 0.0 0:00.00 0:00.00 + 316 0.0 0:00.00 0:00.00 + 317 0.0 0:00.00 0:00.00 + 318 0.0 0:00.00 0:00.00 + 319 0.0 0:00.00 0:00.00 + 320 0.0 0:00.00 0:00.00 + 321 0.0 0:00.00 0:00.00 + 322 0.0 0:00.00 0:00.00 + 323 0.0 0:00.00 0:00.00 + 324 0.0 0:00.00 0:00.00 + 325 0.0 0:00.00 0:00.00 + 326 0.0 0:00.00 0:00.00 + 327 0.0 0:00.00 0:00.00 + 328 0.0 0:00.00 0:00.00 + 329 0.0 0:00.00 0:00.00 + 330 0.0 0:00.00 0:00.00 + 331 0.0 0:00.00 0:00.00 + 332 0.0 0:00.00 0:00.00 + 333 0.0 0:00.00 0:00.00 + 334 0.0 0:00.00 0:00.00 + 335 0.0 0:00.00 0:00.00 + 336 0.0 0:00.00 0:00.00 + 337 0.0 0:00.00 0:00.00 + 338 0.0 0:00.00 0:00.00 + 339 0.0 0:00.00 0:00.00 + 340 0.0 0:00.00 0:00.00 + 341 0.0 0:00.00 0:00.00 + 342 0.0 0:00.00 0:00.00 + 343 0.0 0:00.00 0:00.00 + 344 0.0 0:00.00 0:00.00 + 345 0.0 0:00.00 0:00.00 + 346 0.0 0:00.00 0:00.00 + 347 0.0 0:00.00 0:00.00 + 348 0.0 0:00.00 0:00.00 + 349 0.0 0:00.00 0:00.00 + 350 0.0 0:00.00 0:00.00 + 351 0.0 0:00.00 0:00.00 + 352 0.0 0:00.00 0:00.00 + 353 0.0 0:00.00 0:00.00 + 354 0.0 0:00.00 0:00.00 + 355 0.0 0:00.00 0:00.00 + 356 0.0 0:00.00 0:00.00 + 357 0.0 0:00.00 0:00.00 + 358 0.0 0:00.00 0:00.00 + 359 0.0 0:00.00 0:00.00 + 360 0.0 0:00.00 0:00.00 + 361 0.0 0:00.00 0:00.00 + 362 0.0 0:00.00 0:00.00 + 363 0.0 0:00.00 0:00.00 + 364 0.0 0:00.00 0:00.00 + 365 0.0 0:00.00 0:00.00 + 366 0.0 0:00.00 0:00.00 + 367 0.0 0:00.00 0:00.00 + 368 0.0 0:00.00 0:00.00 + 369 0.0 0:00.00 0:00.00 + 370 0.0 0:00.00 0:00.00 + 371 0.0 0:00.00 0:00.03 + 372 0.0 0:00.00 0:00.00 + 373 0.0 0:00.00 0:00.00 + 374 0.0 0:00.00 0:00.00 + 375 0.0 0:00.00 0:00.00 + 376 0.0 0:00.00 0:00.00 + 377 0.0 0:00.00 0:00.00 + 378 0.0 0:00.00 0:00.00 + 379 0.0 0:00.00 0:00.00 + 380 0.0 0:00.00 0:00.00 + 381 0.0 0:00.00 0:00.00 + 382 0.0 0:00.00 0:00.00 + 383 0.0 0:00.00 0:00.00 + 384 0.0 0:00.00 0:00.00 + 385 0.0 0:00.00 0:00.00 + 386 0.0 0:00.00 0:00.00 + 387 0.0 0:00.00 0:00.00 + 388 0.0 0:00.00 0:00.00 + 389 0.0 0:00.00 0:00.00 + 390 0.0 0:00.00 0:00.00 + 391 0.0 0:00.00 0:00.00 + 392 0.0 0:00.00 0:00.00 + 393 0.0 0:00.00 0:00.00 + 394 0.0 0:00.00 0:00.00 + 395 0.0 0:00.00 0:00.00 + 396 0.0 0:00.00 0:00.00 + 397 0.0 0:00.00 0:00.00 + 398 0.0 0:00.00 0:00.00 + 399 0.0 0:00.00 0:00.00 + 400 0.0 0:00.00 0:00.00 + 401 0.0 0:00.00 0:00.00 + 402 0.0 0:00.00 0:00.00 + 403 0.0 0:00.00 0:00.00 + 404 0.0 0:00.00 0:00.00 + 405 0.0 0:00.00 0:00.00 + 406 0.0 0:00.00 0:00.00 + 407 0.0 0:00.00 0:00.00 + 408 0.0 0:00.00 0:00.00 + 409 0.0 0:00.00 0:00.00 + 410 0.0 0:00.00 0:00.00 + 411 0.0 0:00.00 0:00.00 + 412 0.0 0:00.00 0:00.00 + 413 0.0 0:00.00 0:00.00 + 414 0.0 0:00.00 0:00.00 + 415 0.0 0:00.00 0:00.00 + 416 0.0 0:00.00 0:00.00 + 417 0.0 0:00.00 0:00.00 + 418 0.0 0:00.00 0:00.00 + 419 0.0 0:00.00 0:00.00 + 420 0.0 0:00.00 0:00.00 + 421 0.0 0:00.00 0:00.00 + 422 0.0 0:00.00 0:00.00 + 423 0.0 0:00.00 0:00.00 + 424 0.0 0:00.00 0:00.00 + 425 0.0 0:00.00 0:00.00 + 426 0.0 0:00.00 0:00.00 + 427 0.0 0:00.00 0:00.00 + 428 0.0 0:00.00 0:00.00 + 429 0.0 0:00.00 0:00.00 + 430 0.0 0:00.00 0:00.00 + 431 0.0 0:00.00 0:00.00 + 432 0.0 0:00.00 0:00.00 + 433 0.0 0:00.00 0:00.00 + 434 0.0 0:00.00 0:00.00 + 435 0.0 0:00.00 0:00.00 + 436 0.0 0:00.00 0:00.00 + 437 0.0 0:00.00 0:00.00 + 438 0.0 0:00.00 0:00.00 + 439 0.0 0:00.00 0:00.00 + 440 0.0 0:00.00 0:00.00 + 441 0.0 0:00.00 0:00.00 + 442 0.0 0:00.00 0:00.00 + 443 0.0 0:00.00 0:00.00 + 444 0.0 0:00.00 0:00.00 + 445 0.0 0:00.00 0:00.00 + 446 0.0 0:00.00 0:00.00 + 447 0.0 0:00.00 0:00.00 + 448 0.0 0:00.00 0:00.00 + 449 0.0 0:00.00 0:00.00 + 450 0.0 0:00.00 0:00.00 + 451 0.0 0:00.00 0:00.00 + 452 0.0 0:00.00 0:00.00 + 453 0.0 0:00.00 0:00.00 + 454 0.0 0:00.00 0:00.00 + 455 0.0 0:00.00 0:00.00 + 456 0.0 0:00.00 0:00.00 + 457 0.0 0:00.00 0:00.00 + 458 0.0 0:00.00 0:00.00 + 459 0.0 0:00.00 0:00.00 + 460 0.0 0:00.00 0:00.00 + 461 0.0 0:00.00 0:00.00 + 462 0.0 0:00.00 0:00.00 + 463 0.0 0:00.00 0:00.00 + 464 0.0 0:00.00 0:00.00 + 465 0.0 0:00.00 0:00.00 + 466 0.0 0:00.00 0:00.00 + 467 0.0 0:00.00 0:00.00 + 468 0.0 0:00.00 0:00.00 + 469 0.0 0:00.00 0:00.00 + 470 0.0 0:00.00 0:00.00 + 471 0.0 0:00.00 0:00.00 + 472 0.0 0:00.00 0:00.00 + 473 0.0 0:00.00 0:00.00 + 474 0.0 0:00.00 0:00.00 + 475 0.0 0:00.00 0:00.00 + 476 0.0 0:00.00 0:00.00 + 477 0.0 0:00.00 0:00.00 + 478 0.0 0:00.00 0:00.00 + 479 0.0 0:00.00 0:00.00 + 480 0.0 0:00.00 0:00.00 + 481 0.0 0:00.00 0:00.00 + 482 0.0 0:00.00 0:00.00 + 483 0.0 0:00.00 0:00.00 + 484 0.0 0:00.00 0:00.00 + 485 0.0 0:00.00 0:00.00 + 486 0.0 0:00.00 0:00.00 + 487 0.0 0:00.00 0:00.00 + 488 0.0 0:00.00 0:00.00 + 489 0.0 0:00.00 0:00.00 + 490 0.0 0:00.00 0:00.00 + 491 0.0 0:00.00 0:00.00 + 492 0.0 0:00.00 0:00.00 + 493 0.0 0:00.00 0:00.00 + 494 0.0 0:00.00 0:00.00 + 495 0.0 0:00.00 0:00.00 + 496 0.0 0:00.00 0:00.00 + 497 0.0 0:00.00 0:00.00 + 498 0.0 0:00.00 0:00.00 + 499 0.0 0:00.00 0:00.00 + 500 0.0 0:00.00 0:00.00 + 501 0.0 0:00.00 0:00.00 + 502 0.0 0:00.00 0:00.00 + 503 0.0 0:00.00 0:00.00 + 504 0.0 0:00.00 0:00.00 + 505 0.0 0:00.00 0:00.00 + 506 0.0 0:00.00 0:00.00 + 507 0.0 0:00.00 0:00.00 + 508 0.0 0:00.00 0:00.00 + 509 0.0 0:00.00 0:00.00 + 510 0.0 0:00.00 0:00.00 + 511 0.0 0:00.00 0:00.00 + 512 0.0 0:00.00 0:00.00 + 513 0.0 0:00.00 0:00.00 + 514 0.0 0:00.00 0:00.00 + 515 0.0 0:00.00 0:00.00 + 516 0.0 0:00.00 0:00.00 + 517 0.0 0:00.00 0:00.00 + 518 0.0 0:00.00 0:00.00 + 519 0.0 0:00.00 0:00.00 + 520 0.0 0:00.00 0:00.00 + 521 0.0 0:00.00 0:00.00 + 522 0.0 0:00.00 0:00.00 + 523 0.0 0:00.00 0:00.00 + 524 0.0 0:00.00 0:00.00 + 525 0.0 0:00.00 0:00.00 + 526 0.0 0:00.00 0:00.00 + 527 0.0 0:00.00 0:00.00 + 528 0.0 0:00.00 0:00.00 + 529 0.0 0:00.00 0:00.00 + 530 0.0 0:00.00 0:00.00 + 531 0.0 0:00.00 0:00.00 + 532 0.0 0:00.00 0:00.00 + 533 0.0 0:00.00 0:00.00 + 534 0.0 0:00.00 0:00.00 + 535 0.0 0:00.00 0:00.00 + 536 0.0 0:00.00 0:00.00 + 537 0.0 0:00.00 0:00.00 + 538 0.0 0:00.00 0:00.00 + 539 0.0 0:00.00 0:00.00 + 540 0.0 0:00.00 0:00.00 + 541 0.0 0:00.00 0:00.00 + 542 0.0 0:00.00 0:00.00 + 543 0.0 0:00.00 0:00.00 + 544 0.0 0:00.00 0:00.00 + 545 0.0 0:00.00 0:00.00 + 546 0.0 0:00.00 0:00.00 + 547 0.0 0:00.00 0:00.00 + 548 0.0 0:00.00 0:00.00 + 549 0.0 0:00.00 0:00.00 + 550 0.0 0:00.00 0:00.00 + 551 0.0 0:00.00 0:00.00 + 552 0.0 0:00.00 0:00.00 + 553 0.0 0:00.00 0:00.00 + 554 0.0 0:00.00 0:00.00 + 555 0.0 0:00.00 0:00.00 + 556 0.0 0:00.00 0:00.00 + 557 0.0 0:00.00 0:00.00 + 558 0.0 0:00.00 0:00.00 + 559 0.0 0:00.00 0:00.00 + 560 0.0 0:00.00 0:00.00 + 561 0.0 0:00.00 0:00.00 + 562 0.0 0:00.00 0:00.00 + 563 0.0 0:00.00 0:00.00 + 564 0.0 0:00.00 0:00.00 + 565 0.0 0:00.00 0:00.00 + 566 0.0 0:00.00 0:00.00 + 567 0.0 0:00.00 0:00.00 + 568 0.0 0:00.00 0:00.00 + 569 0.0 0:00.00 0:00.00 + 570 0.0 0:00.00 0:00.00 + 571 0.0 0:00.00 0:00.00 + 572 0.0 0:00.00 0:00.00 + 573 0.0 0:00.00 0:00.00 + 574 0.0 0:00.00 0:00.00 + 575 0.0 0:00.00 0:00.00 + 576 0.0 0:00.00 0:00.00 + 577 0.0 0:00.00 0:00.00 + 578 0.0 0:00.00 0:00.00 + 579 0.0 0:00.00 0:00.00 + 580 0.0 0:00.00 0:00.00 + 581 0.0 0:00.00 0:00.00 + 582 0.0 0:00.00 0:00.00 + 583 0.0 0:00.00 0:00.00 + 584 0.0 0:00.00 0:00.00 + 585 0.0 0:00.00 0:00.00 + 586 0.0 0:00.00 0:00.00 + 587 0.0 0:00.00 0:00.00 + 588 0.0 0:00.00 0:00.00 + 589 0.0 0:00.00 0:00.00 + 590 0.0 0:00.00 0:00.00 + 591 0.0 0:00.00 0:00.00 + 592 0.0 0:00.00 0:00.00 + 593 0.0 0:00.00 0:00.00 + 594 0.0 0:00.00 0:00.00 + 595 0.0 0:00.00 0:00.00 + 596 0.0 0:00.00 0:00.00 + 597 0.0 0:00.00 0:00.00 + 598 0.0 0:00.00 0:00.00 + 599 0.0 0:00.00 0:00.00 + 600 0.0 0:00.00 0:00.00 + 601 0.0 0:00.00 0:00.00 + 602 0.0 0:00.00 0:00.00 + 603 0.0 0:00.00 0:00.00 + 604 0.0 0:00.00 0:00.00 + 605 0.0 0:00.00 0:00.00 + 606 0.0 0:00.00 0:00.00 + 607 0.0 0:00.00 0:00.00 + 608 0.0 0:00.00 0:00.00 + 609 0.0 0:00.00 0:00.00 + 610 0.0 0:00.00 0:00.00 + 611 0.0 0:00.00 0:00.00 + 612 0.0 0:00.00 0:00.00 + 613 0.0 0:00.00 0:00.00 + 614 0.0 0:00.00 0:00.00 + 615 0.0 0:00.00 0:00.00 + 616 0.0 0:00.00 0:00.00 + 617 0.0 0:00.00 0:00.00 + 618 0.0 0:00.00 0:00.00 + 619 0.0 0:00.00 0:00.00 + 620 0.0 0:00.00 0:00.00 + 621 0.0 0:00.00 0:00.00 + 622 0.0 0:00.00 0:00.00 + 623 0.0 0:00.00 0:00.00 + 624 0.0 0:00.00 0:00.00 + 625 0.0 0:00.00 0:00.00 + 626 0.0 0:00.00 0:00.00 + 627 0.0 0:00.00 0:00.00 + 628 0.0 0:00.00 0:00.00 + 629 0.0 0:00.00 0:00.00 + 630 0.0 0:00.00 0:00.00 + 631 100.3 8:11.86 17:35.07 + 175 0 3 1 1 6 130M 1.08M 0.0 0:03.06 0:33.84 /hurd/term /dev/ptyp0 pty-master /dev/ttyp0 + 0 0.0 0:00.80 0:07.55 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.56 0:05.97 + 3 0.0 0:00.50 0:06.99 + 4 0.0 0:00.56 0:06.99 + 5 0.0 0:00.62 0:06.32 + 176 1000 173 176 176 2 148M 2.19M 0.0 0:00.08 0:00.54 -bash + 0 0.0 0:00.08 0:00.47 + 1 0.0 0:00.00 0:00.07 + 284 1000 1 284 284 2 20.5M 700K 0.0 0:00.00 0:00.00 ssh-agent + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 302 1000 176 302 176 3 148M 1.37M 0.0 0:00.03 0:00.14 screen -S S_main + 0 0.0 0:00.02 0:00.07 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.01 0:00.06 + 304 1000 302 304 304 3 148M 2.45M 0.0 0:02.86 0:13.03 SCREEN -S S_main + 0 0.0 0:02.86 0:12.97 + 1 0.0 0:00.00 0:00.03 + 2 0.0 0:00.00 0:00.02 + 305 1000 3 1 1 5 130M 960K 0.0 0:01.57 0:15.62 /hurd/fifo + 0 0.0 0:00.31 0:04.04 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.31 0:03.95 + 3 0.0 0:00.45 0:03.78 + 4 0.0 0:00.49 0:03.84 + 306 0 3 1 1 5 130M 1.02M 0.0 0:01.42 0:16.72 /hurd/term /dev/ptyp1 pty-master /dev/ttyp1 + 0 0.0 0:00.43 0:06.13 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.40 0:04.77 + 3 0.0 0:00.00 0:00.14 + 4 0.0 0:00.59 0:05.67 + 309 1000 304 309 309 2 148M 2.12M 0.0 0:00.02 0:00.09 /bin/bash + 0 0.0 0:00.02 0:00.09 + 1 0.0 0:00.00 0:00.00 + 319 1000 309 319 309 2 153M 7.29M 0.0 0:00.33 0:00.74 emacs + 0 0.0 0:00.33 0:00.74 + 1 0.0 0:00.00 0:00.00 + 320 0 3 1 1 6 130M 1.48M 0.0 0:03.25 0:38.79 /hurd/term /dev/ptyp2 pty-master /dev/ttyp2 + 0 0.0 0:00.60 0:07.07 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.69 0:08.43 + 3 0.0 0:00.78 0:07.78 + 4 0.0 0:00.55 0:07.98 + 5 0.0 0:00.60 0:07.52 + 323 1000 304 323 323 2 148M 2.19M 0.0 0:00.12 0:00.60 /bin/bash + 0 0.0 0:00.12 0:00.54 + 1 0.0 0:00.00 0:00.06 + 411 0 3 1 1 5 130M 1.02M 0.0 0:01.17 0:16.40 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3 + 0 0.0 0:00.42 0:03.74 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.15 0:02.70 + 3 0.0 0:00.24 0:05.48 + 4 0.0 0:00.33 0:04.45 + 414 1000 304 414 414 2 148M 2.13M 0.0 0:00.05 0:00.23 /bin/bash + 0 0.0 0:00.04 0:00.21 + 1 0.0 0:00.00 0:00.02 + 425 0 3 1 1 3 130M 872K 0.0 0:00.02 0:00.05 /hurd/proxy-defpager + 0 0.0 0:00.02 0:00.04 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.01 + 3087 0 3 1 1 5 130M 1.02M 0.0 0:00.23 0:01.39 /hurd/term /dev/ptyp4 pty-master /dev/ttyp4 + 0 0.0 0:00.05 0:00.39 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.07 0:00.43 + 3 0.0 0:00.07 0:00.31 + 4 0.0 0:00.04 0:00.26 + 3648 0 3 1 1 3 130M 876K 0.0 0:00.00 0:00.05 /hurd/crash --kill + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 5512 0 3 1 1 5 130M 1.01M 0.0 0:00.05 0:00.70 /hurd/term /dev/ptyp5 pty-master /dev/ttyp5 + 0 0.0 0:00.00 0:00.26 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.03 0:00.16 + 3 0.0 0:00.02 0:00.14 + 4 0.0 0:00.00 0:00.14 + 10286 1000 323 10286 323 2 135M 1.28M 0.0 0:00.06 0:00.20 make + 0 0.0 0:00.06 0:00.20 + 1 0.0 0:00.00 0:00.00 + 10287 1000 323 10286 323 2 147M 884K 0.0 0:00.00 0:00.33 tee standard output L_ LC_PAPER=en_US.utf8 LC_ADDRESS=en_US.utf8 SSH_AGENT_PID=284 LC_MONETARY= + [165CM=en_US.utf8 SP_REPLACE_LINKS=n SHELL=/bin/bash TERM=screen SP_STOP_AFTER=build HISTSIZE=10000 SSH_CLIENT=192.168.10.60 55972 22 LC_NUMERIC=en_US.utf8 OLDPWD=/home/tsch + [165CMhwinge SSH_TTY=/dev/ttyp0 USER=tschwinge HISTFILESIZE=10000 LD_LIBRARY_PATH= LC_TELEPHONE=en_US.utf8 SP_COMPAT=n LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01; + [165CM;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=0 + [165CM01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31: + [165CM:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35 + [165CM5:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=0 + [165CM01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm + [165CMm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.an + [165CMnx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*. + [165CM.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36: SSH_AUTH_SOCK=/home/tschwinge/.ssh/auth_sock.grubber.bddebian.com TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal + [165CMl:\^K^J:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\^K^J:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\^K^J:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH + [165CMH:up=\EM:\^K^J:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\^K^J:li#50:co#166:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\^K^J:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E + [165CME[P:DC=\E[%dP:\^K^J:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\^K^J:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\^K^J:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E + [165CME[24m:so=\E[3m:\^K^J:se=\E[23m:mb=\E[5m:md=\E[1m:mr=\E[7m:me=\E[m:ms:\^K^J:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\^K^J:vb=\Eg:G0:as=\E(0:ae=\E(B:\^K^J:ac=\1 + [165CM140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\^K^J:po=\E[5i:pf=\E[4i:k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:\^K^J:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E + [165CME[18~:k8=\E[19~:\^K^J:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:F3=\E[1;2P:\^K^J:F4=\E[1;2Q:F5=\E[1;2R:F6=\E[1;2S:F7=\E[15;2~:\^K^J:F8=\E[17;2~:F9=\E[18;2~:FA=\E[19;2~:k + [165CMkb=\177:K2=\EOE:\^K^J:kB=\E[Z:kF=\E[1;2B:kR=\E[1;2A:*4=\E[3;2~:*7=\E[1;2F:\^K^J:#2=\E[1;2H:#3=\E[2;2~:#4=\E[1;2D:%c=\E[6;2~:%e=\E[5;2~:\^K^J:%i=\E[1;2C:kh=\E[1~:@1=\E[ + [165CM[1~:kH=\E[4~:@7=\E[4~:\^K^J:kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:\^K^J:kr=\EOC:kl=\EOD:km: have_bash_profile=y SPF_SOURCE_DEBUG=y PATH=/home/tschwinge/c + [165CMcommand:/home/tschwinge/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games MAIL=/var/mail/tschwinge LC_MESSAGES=en_US.utf8 SP_TARDIR=/ + [165CM/home/tschwinge/tmp/source/package STY=304.S_main LC_COLLATE=C LC_IDENTIFICATION=en_US.utf8 SP_FOREIGN_DIR=/home/tschwinge/shared.old/package/host/schwinge.homeip.net/ + [165CM/sp-foreign-snippets/snippets PWD=/home/tschwinge/tmp/emacs/trunk.build _LD_LIBRARY_PATH= EDITOR=emacsclient LANG=en_US.utf8 TZ=Europe/Berlin LC_MEASUREMENT=en_US.utf + [165CMf8 KRB5CCNAME=/tmp/krb5cc.tschwinge HISTCONTROL=ignoreboth HOME=/home/tschwinge SHLVL=2 SPF_COMPAT=n LOGNAME=tschwinge LESS=-M -R CVS_RSH=ssh WINDOW=1 SSH_CONNECTION=1 + [165CM192.168.10.60 55972 192.168.10.63 22 LC_CTYPE=en_US.utf8 LESSOPEN=| /usr/bin/lesspipe %s EMAIL=thomas@schwinge.name ALTERNATE_EDITOR=joe LC_TIME=en_US.utf8 LESSCLOSE=/ + [165CM/usr/bin/lesspipe %s %s SPF_SOURCE_DATA_DIR=/home/tschwinge/shared.old/source/package/misc/spf LC_NAME=en_US.utf8 _=/usr/bin/tee + 0 0.0 0:00.00 0:00.33 + 1 0.0 0:00.00 0:00.00 + 10377 1000 10286 10286 323 2 146M 828K 0.0 0:00.00 0:00.00 /bin/sh -c boot=bootstrap-emacs; \^Kif [ ! -x "src/$boot" ]; then + [165CM \^K cd src; make all \^K CC='gcc' CFLAGS='-g' CPPFLAGS='-DXASSERTS=1' \^K LDFLA + [165CMAGS='-Wl,-znocombreloc ' MAKE='make' BOOTSTRAPEMACS="$boot"; \^Kfi; + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 10378 1000 10377 10286 323 2 135M 1.65M 0.0 0:00.71 0:02.12 make all CC=gcc CFLAGS=-g CPPFLAGS=-DXASSERTS=1 LDFLAGS=-Wl,-znocombreloc MAKE=make BOOTSTRAPE + [165CMEMACS=bootstrap-emacs + 0 0.0 0:00.71 0:01.92 + 1 0.0 0:00.00 0:00.19 + 10770 1000 10378 10286 323 2 146M 852K 0.0 0:00.00 0:00.03 /bin/sh -c if test "no" = "yes"; then \^K ln -f temacs bootstrap-emacs; \^Kelse \^K `/bin/pwd + [165CMd`/temacs --batch --load loadup bootstrap || exit 1; \^K mv -f emacs bootstrap-emacs; \^Kfi + 0 0.0 0:00.00 0:00.03 + 1 0.0 0:00.00 0:00.00 + 10772 1000 10770 10286 323 3 180M 38.8M 0.0 1:16.35 0:05.27 /media/data/home/tschwinge/tmp/emacs/trunk.build/src/temacs --batch --load loadup bootstrap + 0 0.0 1:16.35 0:05.27 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 10778 1000 304 304 304 2 148M 396K 0.0 0:00.00 0:00.00 SCREEN -S S_main + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 10784 - 160 10784 160 2 146M 672K 0.0 0:00.00 0:00.01 syncfs -s + 0 0.0 0:00.00 0:00.01 + 1 0.0 0:00.00 0:00.00 + 10785 - 160 10785 160 2 146M 672K 0.0 0:00.00 0:00.02 syncfs -s -c /media/data/ + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 10787 0 160 10787 160 2 146M 876K 0.0 0:00.00 0:00.06 ps -Af + 0 0.0 0:00.00 0:00.06 + 1 0.0 0:00.00 0:00.00 + 10795 8 131 6 6 2 147M 1.38M 0.1 0:00.02 0:00.04 /usr/lib/nullmailer/qmqp -d -s mail.schwinge.homeip.net + 0 0.1 0:00.02 0:00.04 + 1 0.0 0:00.00 0:00.00 + 10796 0 160 10796 160 2 146M 1.23M 0.0 0:00.00 0:00.08 ps -F hurd-long -T -M -w -A + 0 0.0 0:00.00 0:00.03 + 1 0.0 0:00.00 0:00.00 + + [4]+ Done ps -F hurd-long -T -M -w -A + login> + +TH# 631 of PID 174 (which is indeed ext2fs for /media/data) looks very +suspicious, likely together in combination with TH# 1 of PID 2 (GNU Mach), so +likely some IPC ping-pong? + + PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 0 0 1 1 1 16 132M 1M 0.0 0:04.84 0:54.84 /hurd/proc + [...] + 2 - 1 1 1 7 418M 19.5M 0.0 0:00.00 0:12.16 root=device:hd0 + 0 0.0 0:00.00 0:00.00 + 1 92.6 0:00.00 46:33.66 + 2 0.0 0:00.00 0:12.07 + 3 0.0 0:00.00 0:00.05 + 4 0.0 0:00.00 0:00.02 + 5 0.0 0:00.00 0:00.00 + 6 0.0 0:00.00 0:00.01 + [...] + 174 0 3 1 1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2 + 0 0.0 0:00.01 0:00.03 + 1 0.0 0:00.00 0:00.00 + 2 0.0 1:34.24 6:26.66 + 3 0.0 0:00.04 0:00.31 + [...] + 630 0.0 0:00.00 0:00.00 + 631 100.3 8:11.86 17:35.07 + [...] + +Attaching GDB hangs. Should have used noninvasive mode... + +Having a look again after an hour or two, GNU Mach's thread 1's (system) time +count has gone up to nearly 120 minutes, and ext2fs' thread 631's is up to 12 +minutes user and 26 minutes system time. + +I was able to get another root shell via plain `ssh root@grubber`, and I'm able +to attach GDB in noninvasive mode. Hopefully the first unsuccessful (but still +running) GDB didn't cause any interference. + +Due to differences in [[thread_numbering_of_ps_and_gdb]], GDB's thread 632 +(which is the last one anyways) should be the offending one. GDB's thread 631 +and earlier ones (manually checked down to 600) are sitting in `mach_msg_trap`. + + (gdb) thread apply 632 bt + + Thread 632 (Thread 174.632): + #0 0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2 + #1 0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0) + at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54 + #2 0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397 + #3 0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724 + #4 0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341 + #5 0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72 + #6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 + #7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 + #8 0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 + #9 0x00000000 in ?? () + + (gdb) thread apply 632 bt full + + Thread 632 (Thread 174.632): + #0 0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2 + No locals. + #1 0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0) + at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54 + err = <value optimized out> + #2 0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397 + base = 321454080 + #3 0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724 + child = 0x83774a8 + n = <value optimized out> + #4 0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341 + t = 0x8377430 + #5 0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72 + status = <value optimized out> + pi = 0x0 + link = {thread = 2050, next = 0x0, prevp = 0x2000, notifies = 0x12, interrupted_next = 0x0} + __PRETTY_FUNCTION__ = "internal_demuxer" + lock = -1073758644 + nreqthreads = -1073750240 + totalthreads = 137852072 + bucket = 0x10b1c64 + demuxer = 0x10b01eb <alloc_stack+11> + #6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 + request = 0xbfffdf20 + reply = 0xbfffbf10 + mr = 3 + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 + timeout = 0 + err = <value optimized out> + hook = 0 + global_timeout = 0 + thread_timeout = 0 + bucket = 0x805f6c0 + lock = 0 + totalthreads = 497 + nreqthreads = 1 + #8 0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 + t = 0x8376bd8 + #9 0x00000000 in ?? () + No symbol table info available. + +May this simply be an out-of-memory situation where Mach won't / can't satisfy +libports / libthreads demand? (Looks like the latter library is currently +creating a new thread.) If yes, should the code be prepared for that? Is it +perhaps prepared (I did not yet have a look), and re-tries again and again? +Why doesn't Mach page out some pages to make memory available? + +This is stock GNU Mach from Git, no patches, configured for Xen domU usage. diff --git a/open_issues/error_message_disk_full.mdwn b/open_issues/error_message_disk_full.mdwn new file mode 100644 index 00000000..f72cd66a --- /dev/null +++ b/open_issues/error_message_disk_full.mdwn @@ -0,0 +1,14 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, unknown channel, unknown date: + + <antrik> /usr/bin/install: writing `/usr/src/gnumach-20060408.dfsg.1/debian/gnumach-dbg/boot/gnumach': (os/kern) memory error + <antrik> interesting way to tell that the disk is full ;-) diff --git a/open_issues/etc_fstab.mdwn b/open_issues/etc_fstab.mdwn new file mode 100644 index 00000000..eb2a34f9 --- /dev/null +++ b/open_issues/etc_fstab.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2009 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="/etc/fstab"]] + +Even though we don't need a `/etc/fstab` for mounting filesystems +(passive [[hurd/translator]]s to the rescue; they have problems on their +own, see the [[hurd/critique]]), we still need this file for `fsck -a` +and `swapon -a` to function. + +[[!tag open_issue_hurd]] diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn new file mode 100644 index 00000000..47d1560a --- /dev/null +++ b/open_issues/exec.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <youpi> oh my, disabling gzip/bzip2 support makes apt preconfigure hang + <youpi> support in exec* I meant + + <youpi> now a funny bug: if I disable gzip/bzip2 support from exec + <youpi> trying to run a zero-byte file hangs + +--- + +May want to have a look at using BFD / libiberty/simpleobject. diff --git a/open_issues/ext2fs_deadlock.mdwn b/open_issues/ext2fs_deadlock.mdwn new file mode 100644 index 00000000..369875fe --- /dev/null +++ b/open_issues/ext2fs_deadlock.mdwn @@ -0,0 +1,55 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +On 2010-10-26, [[I|tschwinge]]'ve been doing the following: `cp -a +../tmpdir/dump*.o ./` (65 files), changed my mind, hit `C-c`, continued with +`cp -a ../tmpdir/dump*.o ./` (to preserve timestamps), wondered why this takes +so long, hit `C-c` again, then found the FS deadlocked (using no CPU; but +`syncfs -s -c` wouldn't finish, for example). Judging from the files' +timestamps (after rebooting and `fsck`), I would assume that it already hung at +the second `cp`'s time, and the deadlock thus is not due to the second `C-c`, +but due to the first one. + + # gdb /hurd/ext2fs + [...] + (gdb) set noninvasive on + (gdb) attach 177 + [...] + [New Thread 177.535] + Reading symbols [...] + (gdb) info threads + [all the same from 177.535 down to...] + 11 Thread 177.11 0x010e3efc in mach_msg_trap () + at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 10 Thread 177.10 0x010e3efc in mach_msg_trap () + at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + [doesn't continue with thread 9, but hangs, taking all CPU time] + +New GDB instance, again noninvasive, I'm able to continue. + +Here are backtraces for threads [[1 to 8|bt_1-8]] and [[10 to 535|bt_10-535]], +I didn't succeed to get any information about thread 9 (which thus would +probably be the most interesting one...) -- GDB would always hang when +accessing it, no matter whether noninvasive mode or not. (Didn't have time to +pull the information out of the process' memory manually (how to do that, +anyways?), and also didn't have time to continue with debugging GDB itself, but +this sounds like a [[!taglink open_issue_gdb]]...) + +--- + +IRC, #hurd, 2010-10-27 + + <youpi> thread 8 hung on ports_begin_rpc + <youpi> that's probably where one could investigated first + <youpi> yes, a lot of threads are hung on that + <tschwinge> You mean 0x10b9488, right? + <youpi> yes diff --git a/open_issues/ext2fs_deadlock/bt_1-8 b/open_issues/ext2fs_deadlock/bt_1-8 new file mode 100644 index 00000000..f3045fb4 --- /dev/null +++ b/open_issues/ext2fs_deadlock/bt_1-8 @@ -0,0 +1,88 @@ + +Thread 1 (Thread 177.1): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x131fd54, option=2, send_size=0, rcv_size=24, rcv_name=10, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af2d8 in condition_wait (c=0x10b1e80, m=0x10b1e50) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:783 +#4 0x010afc7f in cthread_exit (result=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:393 +#5 0x0804e9e5 in main (argc=2, argv=0x131fec4) at /home/sthibaul-guest/hurd-debian/./ext2fs/ext2fs.c:204 + +Thread 2 (Thread 177.2): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x132df20, option=3, send_size=40, rcv_size=4096, rcv_name=12, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x10f5930 <msgport_server>, max_size=4096, rcv_name=12, option=0, timeout=0) at msgserver.c:151 +#3 0x010e4efb in __mach_msg_server (demux=0x10f5930 <msgport_server>, max_size=4096, rcv_name=12) at msgserver.c:196 +#4 0x010f58ff in _hurd_msgport_receive () at msgportdemux.c:68 +#5 0x010b0058 in cthread_body (self=0x805ed38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#6 0x00000000 in ?? () + +Thread 3 (Thread 177.3): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x133bd18, option=2, send_size=0, rcv_size=24, rcv_name=22, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x133be70, outheadp=0x133de80) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=1) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b4fc7 in ports_manage_port_operations_multithread (bucket=0x805f6c0, demuxer=0x103d9b0 <diskfs_demuxer>, hook=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:164 +#9 0x0104b256 in master_thread_function (demuxer=0x103d9b0) at /home/sthibaul-guest/hurd-debian/./libdiskfs/init-first.c:37 +#10 0x010b0058 in cthread_body (self=0x805f800) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#11 0x00000000 in ?? () + +Thread 4 (Thread 177.4): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x134de80, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=1) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b4fc7 in ports_manage_port_operations_multithread (bucket=0x805f8f0, demuxer=0x105ad80 <pager_demuxer>, hook=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:164 +#5 0x01041904 in service_paging_requests (arg=0x805f8f0) at /home/sthibaul-guest/hurd-debian/./libdiskfs/disk-pager.c:41 +#6 0x010b0058 in cthread_body (self=0x805f9a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#7 0x00000000 in ?? () + +Thread 5 (Thread 177.5): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x135df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8060a40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 6 (Thread 177.6): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x136bbb8, option=2, send_size=0, rcv_size=24, rcv_name=34, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8292d98) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11852, seqno=93, control=4806, offset=0, data=83726336, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11852, seqno=93, control=4806, offset=0, data=83726336, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x136df20, OutHeadP=0x136bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x136df20, outp=0x136bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x136df20, outheadp=0x136bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x80614f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 7 (Thread 177.7): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x137bdb8, option=2, send_size=0, rcv_size=24, rcv_name=38, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x137df20, outheadp=0x137bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8061d88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 8 (Thread 177.8): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x138fe80, option=2, send_size=0, rcv_size=24, rcv_name=44, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4b48 in ports_begin_rpc (portstruct=0x80625a0, msg_id=0, info=0x138ff68) at /home/sthibaul-guest/hurd-debian/./libports/begin-rpc.c:33 +#5 0x01052c15 in periodic_sync (interval=5) at /home/sthibaul-guest/hurd-debian/./libdiskfs/sync-interval.c:100 +#6 0x010b0058 in cthread_body (self=0x8062698) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#7 0x00000000 in ?? () diff --git a/open_issues/ext2fs_deadlock/bt_10-535 b/open_issues/ext2fs_deadlock/bt_10-535 new file mode 100644 index 00000000..79ed145a --- /dev/null +++ b/open_issues/ext2fs_deadlock/bt_10-535 @@ -0,0 +1,5240 @@ + +Thread 10 (Thread 177.10): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13adf20, option=2051, send_size=48, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x806b9a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 11 (Thread 177.11): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=87, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11822, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x13bdf20, outheadp=0x13bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x806b578) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 12 (Thread 177.12): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8069bf8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 13 (Thread 177.13): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x806a4e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 14 (Thread 177.14): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8071118) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 15 (Thread 177.15): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=46, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11881, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x13fdf20, outheadp=0x13fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8070e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 16 (Thread 177.16): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x140bbb8, option=2, send_size=0, rcv_size=24, rcv_name=165, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a35c80) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6731, seqno=93, control=11865, offset=0, data=68448256, length=131072, dirty=1, kcopy=1, initializing=0) + at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6731, seqno=93, control=11865, offset=0, data=68448256, length=131072, dirty=1, kcopy=1) + at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x140df20, OutHeadP=0x140bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x140df20, outp=0x140bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x140df20, outheadp=0x140bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8070f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 17 (Thread 177.17): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x141bdb8, option=2, send_size=0, rcv_size=24, rcv_name=159, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11840, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x141df20, outheadp=0x141bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80731b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 18 (Thread 177.18): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x142bdb8, option=2, send_size=0, rcv_size=24, rcv_name=175, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x142bf10, outheadp=0x142df20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8073f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 19 (Thread 177.19): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x143df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8070df8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 20 (Thread 177.20): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x144df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073c60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 21 (Thread 177.21): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x145df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073db8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 22 (Thread 177.22): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x146df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073af0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 23 (Thread 177.23): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x147bbb8, option=2, send_size=0, rcv_size=24, rcv_name=187, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8260de8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11699, seqno=93, control=6878, offset=0, data=85233664, length=131072, dirty=1, kcopy=1, initializing=0) + at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11699, seqno=93, control=6878, offset=0, data=85233664, length=131072, dirty=1, kcopy=1) + at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x147df20, OutHeadP=0x147bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x147df20, outp=0x147bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x147df20, outheadp=0x147bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +Quit + +Thread 10 (Thread 177.10): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13adf20, option=2051, send_size=48, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x806b9a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 11 (Thread 177.11): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=87, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11822, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x13bdf20, outheadp=0x13bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x806b578) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 12 (Thread 177.12): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8069bf8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 13 (Thread 177.13): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x806a4e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 14 (Thread 177.14): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8071118) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 15 (Thread 177.15): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=46, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11881, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x13fdf20, outheadp=0x13fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8070e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 16 (Thread 177.16): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x140bbb8, option=2, send_size=0, rcv_size=24, rcv_name=165, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a35c80) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6731, seqno=93, control=11865, offset=0, data=68448256, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6731, seqno=93, control=11865, offset=0, data=68448256, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x140df20, OutHeadP=0x140bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x140df20, outp=0x140bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x140df20, outheadp=0x140bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8070f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 17 (Thread 177.17): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x141bdb8, option=2, send_size=0, rcv_size=24, rcv_name=159, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11840, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x141df20, outheadp=0x141bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80731b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 18 (Thread 177.18): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x142bdb8, option=2, send_size=0, rcv_size=24, rcv_name=175, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x142bf10, outheadp=0x142df20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8073f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 19 (Thread 177.19): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x143df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8070df8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 20 (Thread 177.20): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x144df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073c60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 21 (Thread 177.21): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x145df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073db8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 22 (Thread 177.22): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x146df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073af0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 23 (Thread 177.23): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x147bbb8, option=2, send_size=0, rcv_size=24, rcv_name=187, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8260de8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11699, seqno=93, control=6878, offset=0, data=85233664, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11699, seqno=93, control=6878, offset=0, data=85233664, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x147df20, OutHeadP=0x147bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x147df20, outp=0x147bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x147df20, outheadp=0x147bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8071588) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 24 (Thread 177.24): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x148df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80716e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 25 (Thread 177.25): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x149df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8071838) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 26 (Thread 177.26): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8071880) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 27 (Thread 177.27): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8074d80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 28 (Thread 177.28): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14cbc6c, option=3, send_size=24, rcv_size=32, rcv_name=209, timeout=0, notify=0) at msg.c:110 +#2 0x012d73dc in __thread_suspend (target_thread=66) at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/RPC_thread_suspend.c:85 +#3 0x01100e07 in hurd_thread_cancel (thread=66) at thread-cancel.c:57 +#4 0x010b5b2a in ports_interrupt_rpcs (portstruct=0x8137000) at /home/sthibaul-guest/hurd-debian/./libports/interrupt-rpcs.c:35 +#5 0x010b6434 in ports_S_interrupt_operation (port=11806, seqno=7) at /home/sthibaul-guest/hurd-debian/./libports/interrupt-operation.c:37 +#6 0x010b7a40 in _Xinterrupt_operation (InHeadP=0x14cdf20, OutHeadP=0x14cbf10) at interruptServer.c:74 +#7 0x010b79b4 in ports_interrupt_server (InHeadP=0xd1, OutHeadP=0xffffffe7) at interruptServer.c:113 +#8 0x0103da44 in diskfs_demuxer (inp=0x14cdf20, outp=0x14cbf10) at /home/sthibaul-guest/hurd-debian/./libdiskfs/demuxer.c:38 +#9 0x010b5163 in internal_demuxer (inp=0x14cdf20, outheadp=0x14cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#10 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#11 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#12 0x010b0058 in cthread_body (self=0x8079e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#13 0x00000000 in ?? () + +Thread 29 (Thread 177.29): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=294, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4812, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x14ddf20, outheadp=0x14dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x807fee0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 30 (Thread 177.30): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=297, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11858, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x14edf20, outheadp=0x14ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x807f960) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 31 (Thread 177.31): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x807f0a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 32 (Thread 177.32): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x150bdb8, option=2, send_size=0, rcv_size=24, rcv_name=312, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6314, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x150df20, outheadp=0x150bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x807b5d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 33 (Thread 177.33): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x151bdb8, option=2, send_size=0, rcv_size=24, rcv_name=315, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11858, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x151df20, outheadp=0x151bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8079d88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 34 (Thread 177.34): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x152df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8082708) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 35 (Thread 177.35): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x153df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8082f60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 36 (Thread 177.36): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x154bdb8, option=2, send_size=0, rcv_size=24, rcv_name=324, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5360, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x154df20, outheadp=0x154bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80837b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 37 (Thread 177.37): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x155df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8084010) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 38 (Thread 177.38): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x156bdb8, option=2, send_size=0, rcv_size=24, rcv_name=330, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6765, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x156df20, outheadp=0x156bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8084868) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 39 (Thread 177.39): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x157df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80850c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 40 (Thread 177.40): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x158df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8085918) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 41 (Thread 177.41): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x159df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8086170) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 42 (Thread 177.42): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15abdb8, option=2, send_size=0, rcv_size=24, rcv_name=342, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=12846, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x15adf20, outheadp=0x15abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80869c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 43 (Thread 177.43): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8087220) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 44 (Thread 177.44): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8087a78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 45 (Thread 177.45): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=351, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11872, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x15ddf20, outheadp=0x15dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80882d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 46 (Thread 177.46): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8088b28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 47 (Thread 177.47): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8089380) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 48 (Thread 177.48): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x160bdb8, option=2, send_size=0, rcv_size=24, rcv_name=360, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6518, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x160df20, outheadp=0x160bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8089bd8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 49 (Thread 177.49): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x161bdb8, option=2, send_size=0, rcv_size=24, rcv_name=363, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5340, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x161df20, outheadp=0x161bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808a430) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 50 (Thread 177.50): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x162bdb8, option=2, send_size=0, rcv_size=24, rcv_name=366, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11840, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x162df20, outheadp=0x162bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808ac88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 51 (Thread 177.51): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x163df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808b4e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 52 (Thread 177.52): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x164df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808bd38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 53 (Thread 177.53): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x165df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808c590) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 54 (Thread 177.54): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x166df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808cde8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 55 (Thread 177.55): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x167bdb8, option=2, send_size=0, rcv_size=24, rcv_name=381, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4864, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x167df20, outheadp=0x167bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808d640) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 56 (Thread 177.56): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x168df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808de98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 57 (Thread 177.57): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x169df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808e6f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 58 (Thread 177.58): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808ef48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 59 (Thread 177.59): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=393, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5339, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16bdf20, outheadp=0x16bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808f7a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 60 (Thread 177.60): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=396, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6731, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16cdf20, outheadp=0x16cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808fff8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 61 (Thread 177.61): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=399, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4785, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16ddf20, outheadp=0x16dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8090850) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 62 (Thread 177.62): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=402, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11824, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16edf20, outheadp=0x16ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80910a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 63 (Thread 177.63): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=405, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11863, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16fdf20, outheadp=0x16fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8091900) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 64 (Thread 177.64): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x170df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8092158) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 65 (Thread 177.65): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x171df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80929b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 66 (Thread 177.66): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x172bdb8, option=2, send_size=0, rcv_size=24, rcv_name=414, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11855, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x172df20, outheadp=0x172bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8093208) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 67 (Thread 177.67): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x173bdb8, option=2, send_size=0, rcv_size=24, rcv_name=417, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6308, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x173df20, outheadp=0x173bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8093a60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 68 (Thread 177.68): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x174bdb8, option=2, send_size=0, rcv_size=24, rcv_name=420, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4830, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x174df20, outheadp=0x174bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80942b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 69 (Thread 177.69): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x175bdb8, option=2, send_size=0, rcv_size=24, rcv_name=423, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11875, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x175df20, outheadp=0x175bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8094b10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 70 (Thread 177.70): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x176bdb8, option=2, send_size=0, rcv_size=24, rcv_name=426, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6876, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x176df20, outheadp=0x176bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8095368) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 71 (Thread 177.71): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x177bdb8, option=2, send_size=0, rcv_size=24, rcv_name=429, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5321, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x177df20, outheadp=0x177bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8095bc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 72 (Thread 177.72): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x178df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8096418) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 73 (Thread 177.73): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x179df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8096c70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 74 (Thread 177.74): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80974c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 75 (Thread 177.75): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8097d20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 76 (Thread 177.76): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8098578) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 77 (Thread 177.77): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8098dd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 78 (Thread 177.78): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=450, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4859, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x17edf20, outheadp=0x17ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8099628) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 79 (Thread 177.79): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8099e80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 80 (Thread 177.80): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x180bdb8, option=2, send_size=0, rcv_size=24, rcv_name=456, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6876, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x180df20, outheadp=0x180bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809a6d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 81 (Thread 177.81): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x181df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809af30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 82 (Thread 177.82): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x182df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809b788) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 83 (Thread 177.83): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x183df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809bfe0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 84 (Thread 177.84): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x184df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809c838) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 85 (Thread 177.85): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x185bdb8, option=2, send_size=0, rcv_size=24, rcv_name=471, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4834, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x185df20, outheadp=0x185bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809d090) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 86 (Thread 177.86): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x186bdb8, option=2, send_size=0, rcv_size=24, rcv_name=474, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4845, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x186df20, outheadp=0x186bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809d8e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 87 (Thread 177.87): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x187bbb8, option=2, send_size=0, rcv_size=24, rcv_name=477, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a450d8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11860, seqno=93, control=11864, offset=0, data=82976768, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11860, seqno=93, control=11864, offset=0, data=82976768, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x187df20, OutHeadP=0x187bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x187df20, outp=0x187bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x187df20, outheadp=0x187bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x809e140) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 88 (Thread 177.88): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x188bdb8, option=2, send_size=0, rcv_size=24, rcv_name=480, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6778, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x188df20, outheadp=0x188bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809e998) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 89 (Thread 177.89): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x189df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809f1f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 90 (Thread 177.90): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18abdb8, option=2, send_size=0, rcv_size=24, rcv_name=486, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4959, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x18adf20, outheadp=0x18abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809fa48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 91 (Thread 177.91): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a02a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 92 (Thread 177.92): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18cbc48, option=2, send_size=0, rcv_size=24, rcv_name=492, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473816, control=28, offset=2453504, data=14823424, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473816, control=28, offset=2453504, data=14823424, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x18cdf20, OutHeadP=0x18cbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x18cdf20, outp=0x18cbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x18cdf20, outheadp=0x18cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x80a0af8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 93 (Thread 177.93): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a1350) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 94 (Thread 177.94): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a1ba8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 95 (Thread 177.95): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a2400) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 96 (Thread 177.96): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x190bdb8, option=2, send_size=0, rcv_size=24, rcv_name=504, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4851, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x190df20, outheadp=0x190bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80a2c58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 97 (Thread 177.97): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x191df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a34b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 98 (Thread 177.98): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x192df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a3d08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 99 (Thread 177.99): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x193df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a4560) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 100 (Thread 177.100): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x194bdb8, option=2, send_size=0, rcv_size=24, rcv_name=516, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11837, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x194df20, outheadp=0x194bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80a4db8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 101 (Thread 177.101): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x195df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a5610) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 102 (Thread 177.102): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x196df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a5e68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 103 (Thread 177.103): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x197df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a66c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 104 (Thread 177.104): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x198df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a6f18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 105 (Thread 177.105): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x199bdb8, option=2, send_size=0, rcv_size=24, rcv_name=531, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5402, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x199df20, outheadp=0x199bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80a7770) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 106 (Thread 177.106): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19abdb8, option=2, send_size=0, rcv_size=24, rcv_name=534, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11872, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x19adf20, outheadp=0x19abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80a7fc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 107 (Thread 177.107): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a8820) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 108 (Thread 177.108): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a9078) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 109 (Thread 177.109): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a98d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 110 (Thread 177.110): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80aa128) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 111 (Thread 177.111): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8075b68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 112 (Thread 177.112): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80ab848) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 113 (Thread 177.113): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80ae9a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 114 (Thread 177.114): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80ac0f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 115 (Thread 177.115): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x807f030) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 116 (Thread 177.116): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b2ae0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 117 (Thread 177.117): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b2b28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 118 (Thread 177.118): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b5e78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 119 (Thread 177.119): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b66d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 120 (Thread 177.120): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b6f28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 121 (Thread 177.121): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b7780) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 122 (Thread 177.122): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1aabdb8, option=2, send_size=0, rcv_size=24, rcv_name=692, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5327, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1aadf20, outheadp=0x1aabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80b7fd8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 123 (Thread 177.123): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1abbdb8, option=2, send_size=0, rcv_size=24, rcv_name=695, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11861, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1abdf20, outheadp=0x1abbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80b8830) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 124 (Thread 177.124): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1acbdb8, option=2, send_size=0, rcv_size=24, rcv_name=698, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5595, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1acdf20, outheadp=0x1acbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80b9088) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 125 (Thread 177.125): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1addf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b98e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 126 (Thread 177.126): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1aebdb8, option=2, send_size=0, rcv_size=24, rcv_name=704, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6972, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1aedf20, outheadp=0x1aebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80ba138) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 127 (Thread 177.127): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1afdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80ba990) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 128 (Thread 177.128): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b0bdb8, option=2, send_size=0, rcv_size=24, rcv_name=710, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11847, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1b0df20, outheadp=0x1b0bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80bb1e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 129 (Thread 177.129): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bba40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 130 (Thread 177.130): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bc298) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 131 (Thread 177.131): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bcaf0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 132 (Thread 177.132): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bd348) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 133 (Thread 177.133): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bdba0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 134 (Thread 177.134): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80be3f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 135 (Thread 177.135): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bec50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 136 (Thread 177.136): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b8bdb8, option=2, send_size=0, rcv_size=24, rcv_name=734, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4785, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1b8df20, outheadp=0x1b8bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80bf4a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 137 (Thread 177.137): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bfd00) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 138 (Thread 177.138): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1badf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80c0558) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 139 (Thread 177.139): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bbbdb8, option=2, send_size=0, rcv_size=24, rcv_name=743, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=13223, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1bbdf20, outheadp=0x1bbbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80c0db0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 140 (Thread 177.140): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bcdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80c1608) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 141 (Thread 177.141): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80c1e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 142 (Thread 177.142): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80c26b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 143 (Thread 177.143): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bfdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81198b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 144 (Thread 177.144): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81196f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 145 (Thread 177.145): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8119848) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 146 (Thread 177.146): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8117318) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 147 (Thread 177.147): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8115880) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 148 (Thread 177.148): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c4bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2159, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11826, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1c4df20, outheadp=0x1c4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81199c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 149 (Thread 177.149): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8115600) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 150 (Thread 177.150): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8118b18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 151 (Thread 177.151): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c7bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2168, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6298, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1c7df20, outheadp=0x1c7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81197b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 152 (Thread 177.152): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8119ba0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 153 (Thread 177.153): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x811d050) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 154 (Thread 177.154): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cabdb8, option=2, send_size=0, rcv_size=24, rcv_name=2177, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6298, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1cadf20, outheadp=0x1cabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x811d8a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 155 (Thread 177.155): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cbbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2180, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5340, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1cbdf20, outheadp=0x1cbbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x811e100) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 156 (Thread 177.156): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1ccbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2183, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4830, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1ccdf20, outheadp=0x1ccbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x811e958) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 157 (Thread 177.157): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cdbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2186, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5321, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1cddf20, outheadp=0x1cdbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x811f1b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 158 (Thread 177.158): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x811fa08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 159 (Thread 177.159): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cfdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8120260) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 160 (Thread 177.160): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8120ab8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 161 (Thread 177.161): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d1bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2198, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11846, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1d1df20, outheadp=0x1d1bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8121310) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 162 (Thread 177.162): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8121b68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 163 (Thread 177.163): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d3bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2204, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5883, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1d3df20, outheadp=0x1d3bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81223c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 164 (Thread 177.164): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d4bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2207, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4861, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1d4df20, outheadp=0x1d4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8122c18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 165 (Thread 177.165): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8123470) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 166 (Thread 177.166): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8123cc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 167 (Thread 177.167): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d7bbb8, option=2, send_size=0, rcv_size=24, rcv_name=2216, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8133588) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6841, seqno=93, control=11809, offset=0, data=66523136, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6841, seqno=93, control=11809, offset=0, data=66523136, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x1d7df20, OutHeadP=0x1d7bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x1d7df20, outp=0x1d7bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x1d7df20, outheadp=0x1d7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8124520) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 168 (Thread 177.168): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8124d78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 169 (Thread 177.169): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81255d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 170 (Thread 177.170): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dabdb8, option=2, send_size=0, rcv_size=24, rcv_name=2225, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11849, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1dadf20, outheadp=0x1dabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8125e28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 171 (Thread 177.171): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8126680) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 172 (Thread 177.172): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dcbc48, option=2, send_size=0, rcv_size=24, rcv_name=2231, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473817, control=28, offset=4096, data=14979072, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473817, control=28, offset=4096, data=14979072, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x1dcdf20, OutHeadP=0x1dcbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x1dcdf20, outp=0x1dcbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x1dcdf20, outheadp=0x1dcbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8126ed8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 173 (Thread 177.173): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8127730) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 174 (Thread 177.174): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1debdb8, option=2, send_size=0, rcv_size=24, rcv_name=2237, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11878, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1dedf20, outheadp=0x1debf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8127f88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 175 (Thread 177.175): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dfbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2240, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11869, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1dfdf20, outheadp=0x1dfbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81287e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 176 (Thread 177.176): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8129038) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 177 (Thread 177.177): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8129890) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 178 (Thread 177.178): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e2bbd8, option=2, send_size=0, rcv_size=24, rcv_name=2249, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82c8510) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11826, seqno=66, control=4763, offset=32768, data=66375680, length=98304, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11826, seqno=66, control=4763, offset=32768, data=66375680, length=98304, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x1e2df20, OutHeadP=0x1e2bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x17, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x1e2df20, outp=0x1e2bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x1e2df20, outheadp=0x1e2bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x812a0e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 179 (Thread 177.179): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x812a940) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 180 (Thread 177.180): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8159660) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 181 (Thread 177.181): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x814c4c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 182 (Thread 177.182): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8137e10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 183 (Thread 177.183): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x813f2a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 184 (Thread 177.184): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8154568) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 185 (Thread 177.185): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e9bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2967, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11843, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1e9df20, outheadp=0x1e9bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8151aa8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 186 (Thread 177.186): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1eabdb8, option=2, send_size=0, rcv_size=24, rcv_name=2970, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11816, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1eadf20, outheadp=0x1eabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x814aaa8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 187 (Thread 177.187): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1ebbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2973, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11855, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1ebdf20, outheadp=0x1ebbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80f1e70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 188 (Thread 177.188): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1ecbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2976, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4939, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1ecdf20, outheadp=0x1ecbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x814ee10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 189 (Thread 177.189): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1edbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2979, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6526, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1eddf20, outheadp=0x1edbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8135588) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 190 (Thread 177.190): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1eedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8140a08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 191 (Thread 177.191): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1efdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80f27e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 192 (Thread 177.192): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x813db08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 193 (Thread 177.193): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f1bbb8, option=2, send_size=0, rcv_size=24, rcv_name=2991, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8306a00) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4845, seqno=93, control=5059, offset=0, data=82788352, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4845, seqno=93, control=5059, offset=0, data=82788352, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x1f1df20, OutHeadP=0x1f1bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x1f1df20, outp=0x1f1bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x1f1df20, outheadp=0x1f1bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81555c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 194 (Thread 177.194): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f2bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2994, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6765, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f2df20, outheadp=0x1f2bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80c99e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 195 (Thread 177.195): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8159088) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 196 (Thread 177.196): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f4bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3000, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11881, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f4df20, outheadp=0x1f4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81548f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 197 (Thread 177.197): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f5bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3003, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11805, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f5df20, outheadp=0x1f5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8153f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 198 (Thread 177.198): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x814ffd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 199 (Thread 177.199): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f7bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3009, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5144, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f7df20, outheadp=0x1f7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8151548) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 200 (Thread 177.200): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f8bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3012, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6308, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f8df20, outheadp=0x1f8bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8137480) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 201 (Thread 177.201): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81450d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 202 (Thread 177.202): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fadf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80f2fc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 203 (Thread 177.203): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81565c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 204 (Thread 177.204): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fcdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8153f28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 205 (Thread 177.205): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x814b820) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 206 (Thread 177.206): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8145130) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 207 (Thread 177.207): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1ffdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81133e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 208 (Thread 177.208): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x200df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8159170) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 209 (Thread 177.209): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x201df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8153628) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 210 (Thread 177.210): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x202df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8133f08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 211 (Thread 177.211): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x203bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3045, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11831, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x203df20, outheadp=0x203bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x814f088) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 212 (Thread 177.212): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x204df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8151d20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 213 (Thread 177.213): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x205bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3051, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4782, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x205df20, outheadp=0x205bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8154e10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 214 (Thread 177.214): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x206bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3054, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a1d690) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4830, seqno=93, control=11851, offset=0, data=84103168, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4830, seqno=93, control=11851, offset=0, data=84103168, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x206df20, OutHeadP=0x206bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x206df20, outp=0x206bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x206df20, outheadp=0x206bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81595f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 215 (Thread 177.215): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x207bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3057, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11866, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x207df20, outheadp=0x207bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8138498) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 216 (Thread 177.216): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x208df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80f1bd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 217 (Thread 177.217): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x209df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816a648) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 218 (Thread 177.218): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816aea0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 219 (Thread 177.219): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3069, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4834, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x20bdf20, outheadp=0x20bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x816b6f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 220 (Thread 177.220): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816bf50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 221 (Thread 177.221): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816c7a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 222 (Thread 177.222): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20ebc48, option=2, send_size=0, rcv_size=24, rcv_name=3078, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473819, control=28, offset=0, data=15933440, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473819, control=28, offset=0, data=15933440, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x20edf20, OutHeadP=0x20ebf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x20edf20, outp=0x20ebf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x20edf20, outheadp=0x20ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x816d000) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 223 (Thread 177.223): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816d858) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 224 (Thread 177.224): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x210df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816e0b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 225 (Thread 177.225): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x211bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3087, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4853, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x211df20, outheadp=0x211bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x816e908) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 226 (Thread 177.226): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x212df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816f160) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 227 (Thread 177.227): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x213df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816f9b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 228 (Thread 177.228): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x214bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3096, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6841, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x214df20, outheadp=0x214bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8170210) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 229 (Thread 177.229): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x215bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3099, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6203, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x215df20, outheadp=0x215bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8170a68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 230 (Thread 177.230): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x216bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3102, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6314, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x216df20, outheadp=0x216bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81712c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 231 (Thread 177.231): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x217df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8171b18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 232 (Thread 177.232): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x218bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3108, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5402, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x218df20, outheadp=0x218bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8172370) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 233 (Thread 177.233): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x219df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8172bc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 234 (Thread 177.234): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21abdb8, option=2, send_size=0, rcv_size=24, rcv_name=3114, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5354, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x21adf20, outheadp=0x21abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8173420) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 235 (Thread 177.235): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3117, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4787, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x21bdf20, outheadp=0x21bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8173c78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 236 (Thread 177.236): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3120, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11862, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x21cdf20, outheadp=0x21cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81744d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 237 (Thread 177.237): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8174d28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 238 (Thread 177.238): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8175580) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 239 (Thread 177.239): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3129, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11837, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x21fdf20, outheadp=0x21fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8175dd8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 240 (Thread 177.240): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x220bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3132, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=12846, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x220df20, outheadp=0x220bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8176630) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 241 (Thread 177.241): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x221df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8176e88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 242 (Thread 177.242): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x222df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81776e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 243 (Thread 177.243): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x223df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8177f38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 244 (Thread 177.244): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x224bc48, option=2, send_size=0, rcv_size=24, rcv_name=3144, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473818, control=28, offset=2125824, data=15642624, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473818, control=28, offset=2125824, data=15642624, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x224df20, OutHeadP=0x224bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x224df20, outp=0x224bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x224df20, outheadp=0x224bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8178790) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 245 (Thread 177.245): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x225bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3147, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4782, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x225df20, outheadp=0x225bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8178fe8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 246 (Thread 177.246): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x226df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8179840) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 247 (Thread 177.247): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x227df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817a098) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 248 (Thread 177.248): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x228df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817a8f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 249 (Thread 177.249): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x229bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3159, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11805, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x229df20, outheadp=0x229bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x817b148) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 250 (Thread 177.250): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22abdb8, option=2, send_size=0, rcv_size=24, rcv_name=3162, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11831, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x22adf20, outheadp=0x22abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x817b9a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 251 (Thread 177.251): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817c1f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 252 (Thread 177.252): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817ca50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 253 (Thread 177.253): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817d2a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 254 (Thread 177.254): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=3174, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11875, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x22edf20, outheadp=0x22ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x817db00) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 255 (Thread 177.255): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817e358) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 256 (Thread 177.256): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x230df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817ebb0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 257 (Thread 177.257): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x231df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817f408) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 258 (Thread 177.258): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x232df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817fc60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 259 (Thread 177.259): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x233bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3189, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5963, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x233df20, outheadp=0x233bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81804b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 260 (Thread 177.260): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x234df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8180d10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 261 (Thread 177.261): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x235df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8181568) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 262 (Thread 177.262): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x236df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8181dc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 263 (Thread 177.263): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x237df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8182618) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 264 (Thread 177.264): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x238df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8182e70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 265 (Thread 177.265): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x239bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3207, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4859, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x239df20, outheadp=0x239bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81836c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 266 (Thread 177.266): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8183f20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 267 (Thread 177.267): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8184778) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 268 (Thread 177.268): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8184fd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 269 (Thread 177.269): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8185828) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 270 (Thread 177.270): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8186080) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 271 (Thread 177.271): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81868d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 272 (Thread 177.272): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x240df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8187130) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 273 (Thread 177.273): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x241bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3231, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4814, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x241df20, outheadp=0x241bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8187988) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 274 (Thread 177.274): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x242df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81881e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 275 (Thread 177.275): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x243df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8188a38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 276 (Thread 177.276): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x244df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8189290) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 277 (Thread 177.277): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x245bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3243, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11843, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x245df20, outheadp=0x245bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8189ae8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 278 (Thread 177.278): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x246bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3246, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6517, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x246df20, outheadp=0x246bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x818a340) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 279 (Thread 177.279): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x247df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818ab98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 280 (Thread 177.280): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x248df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818b3f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 281 (Thread 177.281): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x249bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3255, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5315, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x249df20, outheadp=0x249bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x818bc48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 282 (Thread 177.282): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818c4a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 283 (Thread 177.283): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818ccf8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 284 (Thread 177.284): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818d550) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 285 (Thread 177.285): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818dda8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 286 (Thread 177.286): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818e600) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 287 (Thread 177.287): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3273, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11861, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x24fdf20, outheadp=0x24fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x818ee58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 288 (Thread 177.288): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x250df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818f6b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 289 (Thread 177.289): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x251df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818ff08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 290 (Thread 177.290): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x252df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8190760) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 291 (Thread 177.291): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x253df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8190fb8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 292 (Thread 177.292): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x254bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3288, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11852, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x254df20, outheadp=0x254bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8191810) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 293 (Thread 177.293): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x255df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8192068) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 294 (Thread 177.294): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x256bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3294, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5144, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x256df20, outheadp=0x256bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81928c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 295 (Thread 177.295): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x257df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8193118) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 296 (Thread 177.296): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x258df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8193970) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 297 (Thread 177.297): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x259df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81941c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 298 (Thread 177.298): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8194a20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 299 (Thread 177.299): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8195278) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 300 (Thread 177.300): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3312, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5339, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x25cdf20, outheadp=0x25cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8195ad0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 301 (Thread 177.301): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3315, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=13223, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x25ddf20, outheadp=0x25dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8196328) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 302 (Thread 177.302): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8196b80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 303 (Thread 177.303): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3321, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6517, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x25fdf20, outheadp=0x25fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81973d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 304 (Thread 177.304): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x260df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8197c30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 305 (Thread 177.305): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x261bcc8, option=2, send_size=0, rcv_size=24, rcv_name=3327, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82c8510) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059a84 in _pager_seqnos_memory_object_data_unlock (object=11826, seqno=68, control=4763, offset=131072, length=4096, access=2) at /home/sthibaul-guest/hurd-debian/./libpager/data-unlock.c:87 +#6 0x0105c1b4 in _Xmemory_object_data_unlock (InHeadP=0x261df20, OutHeadP=0x261bf10) at memory_objectServer.c:467 +#7 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x20000, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#8 0x0105adac in pager_demuxer (inp=0x261df20, outp=0x261bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#9 0x010b5163 in internal_demuxer (inp=0x261df20, outheadp=0x261bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#10 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#11 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#12 0x010b0058 in cthread_body (self=0x8198488) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#13 0x00000000 in ?? () + +Thread 306 (Thread 177.306): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x262bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3330, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11829, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x262df20, outheadp=0x262bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8198ce0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 307 (Thread 177.307): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x263df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8199538) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 308 (Thread 177.308): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x264bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3336, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11846, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x264df20, outheadp=0x264bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8199d90) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 309 (Thread 177.309): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x265bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3339, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4797, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x265df20, outheadp=0x265bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x819a5e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 310 (Thread 177.310): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x266bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3342, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5883, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x266df20, outheadp=0x266bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x819ae40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 311 (Thread 177.311): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x267df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819b698) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 312 (Thread 177.312): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x268df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819bef0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 313 (Thread 177.313): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x269df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819c748) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 314 (Thread 177.314): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819cfa0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 315 (Thread 177.315): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819d7f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 316 (Thread 177.316): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819e050) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 317 (Thread 177.317): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819e8a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 318 (Thread 177.318): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819f100) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 319 (Thread 177.319): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819f958) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 320 (Thread 177.320): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x270bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3372, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11822, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x270df20, outheadp=0x270bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a01b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 321 (Thread 177.321): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x271df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a0a08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 322 (Thread 177.322): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x272df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a1260) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 323 (Thread 177.323): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x273df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a1ab8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 324 (Thread 177.324): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x274bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3384, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11818, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x274df20, outheadp=0x274bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a2310) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 325 (Thread 177.325): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x275bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3387, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11818, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x275df20, outheadp=0x275bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a2b68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 326 (Thread 177.326): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x276df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a33c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 327 (Thread 177.327): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x277df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a3c18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 328 (Thread 177.328): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x278df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a4470) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 329 (Thread 177.329): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x279bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3399, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11856, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x279df20, outheadp=0x279bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a4cc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 330 (Thread 177.330): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a5520) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 331 (Thread 177.331): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3405, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5049, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x27bdf20, outheadp=0x27bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a5d78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 332 (Thread 177.332): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a65d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 333 (Thread 177.333): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3411, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5127, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x27ddf20, outheadp=0x27dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a6e28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 334 (Thread 177.334): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=3414, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6203, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x27edf20, outheadp=0x27ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a7680) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 335 (Thread 177.335): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a7ed8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 336 (Thread 177.336): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x280bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3420, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11878, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x280df20, outheadp=0x280bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a8730) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 337 (Thread 177.337): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x281df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a8f88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 338 (Thread 177.338): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x282bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3426, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3aa2370) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=10039, seqno=93, control=9839, offset=0, data=85422080, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=10039, seqno=93, control=9839, offset=0, data=85422080, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x282df20, OutHeadP=0x282bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x282df20, outp=0x282bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x282df20, outheadp=0x282bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81a97e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 339 (Thread 177.339): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x283df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81aa038) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 340 (Thread 177.340): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x284df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81aa890) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 341 (Thread 177.341): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x285bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3435, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5963, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x285df20, outheadp=0x285bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ab0e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 342 (Thread 177.342): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x286df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ab940) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 343 (Thread 177.343): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x287df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ac198) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 344 (Thread 177.344): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x288df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ac9f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 345 (Thread 177.345): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x289bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3447, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4862, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x289df20, outheadp=0x289bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ad248) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 346 (Thread 177.346): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81adaa0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 347 (Thread 177.347): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ae2f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 348 (Thread 177.348): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81aeb50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 349 (Thread 177.349): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81af3a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 350 (Thread 177.350): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81afc00) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 351 (Thread 177.351): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b0458) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 352 (Thread 177.352): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x290df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b0cb0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 353 (Thread 177.353): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x291df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b1508) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 354 (Thread 177.354): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x292df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b1d60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 355 (Thread 177.355): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x293df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b25b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 356 (Thread 177.356): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x294bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3480, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a35f50) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4864, seqno=93, control=11880, offset=0, data=81281024, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4864, seqno=93, control=11880, offset=0, data=81281024, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x294df20, OutHeadP=0x294bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x294df20, outp=0x294bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x294df20, outheadp=0x294bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81b2e10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 357 (Thread 177.357): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x295df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b3668) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 358 (Thread 177.358): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x296df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b3ec0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 359 (Thread 177.359): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x297df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b4718) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 360 (Thread 177.360): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x298bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3492, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82156d0) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11818, seqno=93, control=11814, offset=0, data=84856832, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11818, seqno=93, control=11814, offset=0, data=84856832, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x298df20, OutHeadP=0x298bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x298df20, outp=0x298bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x298df20, outheadp=0x298bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81b4f70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 361 (Thread 177.361): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x299bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3495, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11888, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x299df20, outheadp=0x299bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81b57c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 362 (Thread 177.362): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b6020) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 363 (Thread 177.363): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b6878) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 364 (Thread 177.364): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b70d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 365 (Thread 177.365): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b7928) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 366 (Thread 177.366): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b8180) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 367 (Thread 177.367): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b89d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 368 (Thread 177.368): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b9230) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 369 (Thread 177.369): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b9a88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 370 (Thread 177.370): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a2bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3522, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11829, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2a2df20, outheadp=0x2a2bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ba2e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 371 (Thread 177.371): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a3bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3525, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11856, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2a3df20, outheadp=0x2a3bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81bab38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 372 (Thread 177.372): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bb390) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 373 (Thread 177.373): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a5bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3531, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4873, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2a5df20, outheadp=0x2a5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81bbbe8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 374 (Thread 177.374): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a6bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3534, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11862, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2a6df20, outheadp=0x2a6bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81bc440) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 375 (Thread 177.375): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bcc98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 376 (Thread 177.376): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bd4f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 377 (Thread 177.377): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bdd48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 378 (Thread 177.378): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2aadf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81be5a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 379 (Thread 177.379): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2abdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bedf8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 380 (Thread 177.380): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2acbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3552, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11819, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2acdf20, outheadp=0x2acbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81bf650) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 381 (Thread 177.381): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2addf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bfea8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 382 (Thread 177.382): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2aedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c0700) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 383 (Thread 177.383): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2afbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3561, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4845, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2afdf20, outheadp=0x2afbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c0f58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 384 (Thread 177.384): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b0bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3564, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6972, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2b0df20, outheadp=0x2b0bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c17b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 385 (Thread 177.385): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c2008) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 386 (Thread 177.386): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c2860) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 387 (Thread 177.387): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b3bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3573, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4959, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2b3df20, outheadp=0x2b3bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c30b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 388 (Thread 177.388): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c3910) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 389 (Thread 177.389): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b5bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3579, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a1d730) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11847, seqno=93, control=6869, offset=0, data=84291584, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11847, seqno=93, control=6869, offset=0, data=84291584, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2b5df20, OutHeadP=0x2b5bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2b5df20, outp=0x2b5bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2b5df20, outheadp=0x2b5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81c4168) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 390 (Thread 177.390): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c49c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 391 (Thread 177.391): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b7bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3585, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11819, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2b7df20, outheadp=0x2b7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c5218) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 392 (Thread 177.392): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c5a70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 393 (Thread 177.393): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b9bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3591, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11866, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2b9df20, outheadp=0x2b9bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c62c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 394 (Thread 177.394): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2badf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c6b20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 395 (Thread 177.395): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c7378) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 396 (Thread 177.396): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bcbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3600, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11869, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2bcdf20, outheadp=0x2bcbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c7bd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 397 (Thread 177.397): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c8428) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 398 (Thread 177.398): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c8c80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 399 (Thread 177.399): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bfdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c94d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 400 (Thread 177.400): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c9d30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 401 (Thread 177.401): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ca588) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 402 (Thread 177.402): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81cade0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 403 (Thread 177.403): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c3bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3621, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4862, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2c3df20, outheadp=0x2c3bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cb638) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 404 (Thread 177.404): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81cbe90) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 405 (Thread 177.405): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c5bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3627, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5360, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2c5df20, outheadp=0x2c5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cc6e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 406 (Thread 177.406): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c6bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3630, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82b1050) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11824, seqno=93, control=5619, offset=0, data=84668416, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11824, seqno=93, control=5619, offset=0, data=84668416, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2c6df20, OutHeadP=0x2c6bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2c6df20, outp=0x2c6bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2c6df20, outheadp=0x2c6bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81ccf40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 407 (Thread 177.407): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c7bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3633, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5288, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2c7df20, outheadp=0x2c7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cd798) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 408 (Thread 177.408): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81cdff0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 409 (Thread 177.409): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ce848) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 410 (Thread 177.410): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cabdb8, option=2, send_size=0, rcv_size=24, rcv_name=3642, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4812, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2cadf20, outheadp=0x2cabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cf0a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 411 (Thread 177.411): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cbbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3645, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5595, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2cbdf20, outheadp=0x2cbbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cf8f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 412 (Thread 177.412): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2ccbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3648, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8318a20) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6778, seqno=93, control=4919, offset=0, data=67067904, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6778, seqno=93, control=4919, offset=0, data=67067904, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2ccdf20, OutHeadP=0x2ccbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2ccdf20, outp=0x2ccbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2ccdf20, outheadp=0x2ccbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81d0150) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 413 (Thread 177.413): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d09a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 414 (Thread 177.414): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d1200) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 415 (Thread 177.415): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cfbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3657, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4939, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2cfdf20, outheadp=0x2cfbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81d1a58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 416 (Thread 177.416): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d22b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 417 (Thread 177.417): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d2b08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 418 (Thread 177.418): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d3360) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 419 (Thread 177.419): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d3bb8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 420 (Thread 177.420): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d4bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3672, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5354, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2d4df20, outheadp=0x2d4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81d4410) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 421 (Thread 177.421): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d4c68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 422 (Thread 177.422): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d54c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 423 (Thread 177.423): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d5d18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 424 (Thread 177.424): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d6570) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 425 (Thread 177.425): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d6dc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 426 (Thread 177.426): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dabdb8, option=2, send_size=0, rcv_size=24, rcv_name=3690, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5288, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2dadf20, outheadp=0x2dabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81d7620) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 427 (Thread 177.427): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d7e78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 428 (Thread 177.428): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dcbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3696, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5127, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2dcdf20, outheadp=0x2dcbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81d86d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 429 (Thread 177.429): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d8f28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 430 (Thread 177.430): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d9780) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 431 (Thread 177.431): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dfdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d9fd8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 432 (Thread 177.432): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e0bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3708, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4797, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2e0df20, outheadp=0x2e0bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81da830) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 433 (Thread 177.433): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81db088) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 434 (Thread 177.434): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81db8e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 435 (Thread 177.435): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81dc138) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 436 (Thread 177.436): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e4bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3720, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x835c670) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11829, seqno=93, control=11823, offset=0, data=84480000, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11829, seqno=93, control=11823, offset=0, data=84480000, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2e4df20, OutHeadP=0x2e4bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2e4df20, outp=0x2e4bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2e4df20, outheadp=0x2e4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81dc990) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 437 (Thread 177.437): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81dd1e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 438 (Thread 177.438): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e6bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3726, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4814, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2e6df20, outheadp=0x2e6bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81dda40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 439 (Thread 177.439): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81de298) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 440 (Thread 177.440): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81deaf0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 441 (Thread 177.441): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81df348) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 442 (Thread 177.442): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2eabdb8, option=2, send_size=0, rcv_size=24, rcv_name=3738, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6526, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2eadf20, outheadp=0x2eabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81dfba0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 443 (Thread 177.443): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2ebdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e03f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 444 (Thread 177.444): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2ecdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e0c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 445 (Thread 177.445): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2edbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3747, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6518, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2eddf20, outheadp=0x2edbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81e14a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 446 (Thread 177.446): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2eedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e1d00) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 447 (Thread 177.447): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2efdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e2558) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 448 (Thread 177.448): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e2db0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 449 (Thread 177.449): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e3608) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 450 (Thread 177.450): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e3e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 451 (Thread 177.451): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e46b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 452 (Thread 177.452): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e4f10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 453 (Thread 177.453): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f5bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3771, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5327, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2f5df20, outheadp=0x2f5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81e5768) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 454 (Thread 177.454): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e5fc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 455 (Thread 177.455): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e6818) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 456 (Thread 177.456): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e7070) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 457 (Thread 177.457): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e78c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 458 (Thread 177.458): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fabdb8, option=2, send_size=0, rcv_size=24, rcv_name=3786, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11824, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2fadf20, outheadp=0x2fabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81e8120) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 459 (Thread 177.459): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e8978) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 460 (Thread 177.460): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fcbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3792, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5315, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2fcdf20, outheadp=0x2fcbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81e91d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 461 (Thread 177.461): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fdbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3795, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x824b9a8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4861, seqno=93, control=11977, offset=0, data=81657856, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4861, seqno=93, control=11977, offset=0, data=81657856, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2fddf20, OutHeadP=0x2fdbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2fddf20, outp=0x2fdbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2fddf20, outheadp=0x2fdbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81e9a28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 462 (Thread 177.462): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ea280) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 463 (Thread 177.463): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2ffbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3801, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82a5fa8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11849, seqno=93, control=6975, offset=0, data=83914752, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11849, seqno=93, control=6975, offset=0, data=83914752, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2ffdf20, OutHeadP=0x2ffbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2ffdf20, outp=0x2ffbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2ffdf20, outheadp=0x2ffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81eaad8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 464 (Thread 177.464): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x300bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3804, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11860, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x300df20, outheadp=0x300bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81eb330) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 465 (Thread 177.465): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x301bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3807, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4861, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x301df20, outheadp=0x301bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ebb88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 466 (Thread 177.466): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x302df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ec3e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 467 (Thread 177.467): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x303df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ecc38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 468 (Thread 177.468): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x304df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ed490) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 469 (Thread 177.469): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x305bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3819, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11816, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x305df20, outheadp=0x305bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81edce8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 470 (Thread 177.470): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x306bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3822, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11847, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x306df20, outheadp=0x306bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ee540) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 471 (Thread 177.471): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x307bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3825, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5049, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x307df20, outheadp=0x307bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81eed98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 472 (Thread 177.472): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x308df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ef5f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 473 (Thread 177.473): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x309df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81efe48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 474 (Thread 177.474): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30abdb8, option=2, send_size=0, rcv_size=24, rcv_name=3834, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11852, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x30adf20, outheadp=0x30abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f06a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 475 (Thread 177.475): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f0ef8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 476 (Thread 177.476): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3840, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11827, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x30cdf20, outheadp=0x30cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f1750) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 477 (Thread 177.477): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f1fa8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 478 (Thread 177.478): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f2800) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 479 (Thread 177.479): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30fbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3849, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x81432f0) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6765, seqno=93, control=11752, offset=0, data=67751936, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6765, seqno=93, control=11752, offset=0, data=67751936, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x30fdf20, OutHeadP=0x30fbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x30fdf20, outp=0x30fbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x30fdf20, outheadp=0x30fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81f3058) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 480 (Thread 177.480): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x310bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3852, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4853, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x310df20, outheadp=0x310bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f38b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 481 (Thread 177.481): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x311bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3855, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11888, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x311df20, outheadp=0x311bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f4108) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 482 (Thread 177.482): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x312df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f4960) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 483 (Thread 177.483): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x313df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f51b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 484 (Thread 177.484): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x314df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f5a10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 485 (Thread 177.485): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x315df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f6268) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 486 (Thread 177.486): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x316bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3870, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4873, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x316df20, outheadp=0x316bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f6ac0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 487 (Thread 177.487): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x317df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f7318) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 488 (Thread 177.488): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x318df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f7b70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 489 (Thread 177.489): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x319bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3879, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11827, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x319df20, outheadp=0x319bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f83c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 490 (Thread 177.490): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f8c20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 491 (Thread 177.491): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f9478) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 492 (Thread 177.492): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3888, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4851, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x31cdf20, outheadp=0x31cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f9cd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 493 (Thread 177.493): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fa528) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 494 (Thread 177.494): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fad80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 495 (Thread 177.495): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3897, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11849, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x31fdf20, outheadp=0x31fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81fb5d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 496 (Thread 177.496): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x320df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fbe30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 497 (Thread 177.497): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x321df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fc688) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 498 (Thread 177.498): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x322df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fcee0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 499 (Thread 177.499): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x323df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fd738) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 500 (Thread 177.500): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x324df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fdf90) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 501 (Thread 177.501): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x325df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fe7e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 502 (Thread 177.502): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x326bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3918, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6841, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x326df20, outheadp=0x326bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ff040) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 503 (Thread 177.503): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x327df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ff898) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 504 (Thread 177.504): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x328bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3924, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4864, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x328df20, outheadp=0x328bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x82000f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 505 (Thread 177.505): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x329df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8200948) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 506 (Thread 177.506): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x82011a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 507 (Thread 177.507): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x82019f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 508 (Thread 177.508): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8202250) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 509 (Thread 177.509): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8202aa8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 510 (Thread 177.510): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=3942, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6778, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x32edf20, outheadp=0x32ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8203300) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 511 (Thread 177.511): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32fbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3945, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8133628) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4787, seqno=93, control=2767, offset=0, data=85045248, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4787, seqno=93, control=2767, offset=0, data=85045248, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x32fdf20, OutHeadP=0x32fbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x32fdf20, outp=0x32fbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x32fdf20, outheadp=0x32fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8203b58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 512 (Thread 177.512): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x330df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x82043b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 513 (Thread 177.513): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x331bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3951, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8260d48) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11856, seqno=91, control=5370, offset=0, data=83353600, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11856, seqno=91, control=5370, offset=0, data=83353600, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x331df20, OutHeadP=0x331bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x331df20, outp=0x331bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x331df20, outheadp=0x331bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8204c08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 514 (Thread 177.514): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x332df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8205460) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 515 (Thread 177.515): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x333df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8205cb8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 516 (Thread 177.516): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x334df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8206510) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 517 (Thread 177.517): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x335df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8206d68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 518 (Thread 177.518): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x336df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x82075c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 519 (Thread 177.519): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x337df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8207e18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 520 (Thread 177.520): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x338df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8208670) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 521 (Thread 177.521): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x339bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3975, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11863, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x339df20, outheadp=0x339bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8208ec8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 522 (Thread 177.522): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33abdb8, option=2, send_size=0, rcv_size=24, rcv_name=3978, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4787, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x33adf20, outheadp=0x33abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8209720) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 523 (Thread 177.523): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33bbc48, option=2, send_size=0, rcv_size=24, rcv_name=3981, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473815, control=28, offset=14811136, data=12541952, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473815, control=28, offset=14811136, data=12541952, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x33bdf20, OutHeadP=0x33bbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x33bdf20, outp=0x33bbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x33bdf20, outheadp=0x33bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8209f78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 524 (Thread 177.524): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3984, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11860, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x33cdf20, outheadp=0x33cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x820a7d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 525 (Thread 177.525): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x820b028) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 526 (Thread 177.526): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=3990, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6731, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x33edf20, outheadp=0x33ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x820b880) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 527 (Thread 177.527): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x820c0d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 528 (Thread 177.528): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x395bdb8, option=2, send_size=0, rcv_size=24, rcv_name=8764, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=11800, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x395bf10, outheadp=0x395df20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x3a006a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 529 (Thread 177.529): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x39bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=8881, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x39bbf10, outheadp=0x39bdf20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x3a016f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 530 (Thread 177.530): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x40ebf10, option=2051, send_size=48, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x83a9420) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 531 (Thread 177.531): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x43adf20, option=2051, send_size=40, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x3a4efc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 532 (Thread 177.532): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x47abdb8, option=2, send_size=0, rcv_size=24, rcv_name=13165, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=11806, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x47adf20, outheadp=0x47abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x3a31a48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 533 (Thread 177.533): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x48cdf20, option=2051, send_size=40, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8400f30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 534 (Thread 177.534): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x4bbbdb8, option=2, send_size=0, rcv_size=24, rcv_name=4850, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=13460, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x4bbdf20, outheadp=0x4bbbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x83bb9c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 535 (Thread 177.535): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x4bcbdb8, option=2, send_size=0, rcv_size=24, rcv_name=5058, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x4bcbf10, outheadp=0x4bcdf20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x82b9038) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () diff --git a/open_issues/ext2fs_page_cache_swapping_leak.mdwn b/open_issues/ext2fs_page_cache_swapping_leak.mdwn new file mode 100644 index 00000000..7c4cf52d --- /dev/null +++ b/open_issues/ext2fs_page_cache_swapping_leak.mdwn @@ -0,0 +1,364 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +There is a [[!FF_project 272]][[!tag bounty]] on this task. + +[[!toc]] + + +# IRC, OFTC, #debian-hurd, 2011-03-24 + + <youpi> I still believe we have an ext2fs page cache swapping leak, however + <youpi> as the 1.8GiB swap was full, yet the ld process was only 1.5GiB big + <pinotree> a leak at swapping time, you mean? + <youpi> I mean the ext2fs page cache being swapped out instead of simply + dropped + <pinotree> ah + <pinotree> so the swap tends to accumulate unuseful stuff, i see + <youpi> yes + <youpi> the disk content, basicallyt :) + + +# IRC, freenode, #hurd, 2011-04-18 + + <antrik> damn, a cp -a simply gobbles down swap space... + <braunr> really ? + <braunr> that's weird + <braunr> why would a copy use so much anonymous memory ? + <braunr> unless the external pager is so busy that the kernel falls back to + its default pager + <youpi> that's what I suggested some time ago + <braunr> maybe this case should be traced in the kernel + <braunr> a simple message in the kernel buffer to warn that this condition + happened may help + <youpi> I'm seeing swap space being kept used on buildds for no real reason + except possibly backing ext2fs pages + <youpi> that could help, yes + <antrik> youpi: I think it was actually slpz who suggested that... + <youpi> I think we're generally missing feedback from memory behavior + <antrik> youpi: do you think andrei's kernel instrumentation work might be + helpful with analyzing such things? + <youpi> antrik: I think I suggested it too, but never mind + <youpi> antrik: no, because it's not a trace of events that you want + <youpi> some specific events would be useful + <youpi> but then we don't really need a whole framework for that + <antrik> apt-get upgrade eats swap too + <youpi> the upgrade itself, or the computation of the ugprade? + <youpi> apt is a memory eater nowadays + <antrik> installing the packages + <antrik> seems to have stabilized though after a while... + <antrik> so perhaps it's not a leak in this case + <youpi> ideally we should have a way to know what was put in the swap + <braunr> how would you represent what's in the swap ? + <antrik> the apt-get process has 46M of virtual memory above the 128 M + baseline + <braunr> mostly libraries i guess + <braunr> are trheads stacks 8 MiB like on Linux ? + <youpi> braunr: at least knowing how much of each process is in the swap + <youpi> braunr: 2MiB + <braunr> ok + <youpi> vminfo could also report which parts of the address space are in + the swap + <antrik> youpi: would be nice to have some simple utility reporting how + much of a process' address space is anonymous + <antrik> (in fact, I wonder why it's not reported by standard tools such as + ps or top... this shouldn't be too difficult I would think?) + <antrik> it would be much more useful information than the total virt size, + which includes rather meaningless disk and device mappings... + <youpi> agreed + <braunr> well + <braunr> there are tools like pmap for this + <braunr> unfortunately, it's difficult in mach to know what backs a + non-anonymous mapping + <braunr> pagers should be able to name their mappings + <youpi> that'd be helpful for debugging yes + <braunr> there is almost no overhead in doing that, and it would be very + useful + <youpi> and could lead to /proc/pid/maps + <braunr> yes + <braunr> isn't there a maps already ? + <youpi> nope + <braunr> ok + <youpi> (probably not very useful without the names) + <braunr> ithought i remembered maps without names, and guessed it might + have been on the hurd for that reason + <braunr> but i'm not sure + <youpi> there's the vminfo command, yes + <braunr> 14:06 < youpi> braunr: at least knowing how much of each process + is in the swap + <braunr> wouldn't it be clearer to do it the other way around ? + <braunr> like a swapinfo tool indicating what it contains ? + <youpi> sure, but it's a lot more difficult + <braunr> really ? + <braunr> why ? + <youpi> because you have to traverse all the mappings + <youpi> etc + <youpi> (in all processes, I mean) + <youpi> and you have to name what is waht + <braunr> there are other ways + <braunr> the swap is a central structure + <youpi> while simply introducing the swap % in vminfo + <youpi> for a given process you know what is what + <braunr> right + <youpi> and doing that introduction is probably very simple + <braunr> that's a good point + <braunr> top-down is effectively easier than bottom-up resolution in Mach + VM + <antrik> hm... the memory use caused by cp doesn't seem to be reflected in + the virtual size of any particular process + <antrik> ghost memory + <braunr> what's cp vmsize at the time of the problem ? + <antrik> it's at 134 M right now... so considering the 128 M baseline, + nothing worth speaking of + <braunr> right + <braunr> maybe a copy map during I/O + <braunr> but I don't know Mach copy maps in detail, as they have been + eliminated from UVM + <antrik> BTW, the memory eatup happens even before swap comes into + play... swapping seems to be a result of the problem, not the cause + <braunr> what do you mean ? + <braunr> I thought swapping was the issue + <braunr> you mean RAM is full before swapping ? + <antrik> well, I don't know what the actual problem is... I just don't + understand why the memory use increases without any particular process + seeing an increase in size + <antrik> the "free" size in vmstat decreses + <antrik> once it's eatun up, swap space use increases + <braunr> well it doesn't change much of it + <braunr> the anonymous memory pager will use RAM before resorting to the + external default-pager + <antrik> I would suspect normal block caching... but then, shouldn't this + show up in the memory info of the ext2 process? + <braunr> although, again, I'm not sure of the behaviour of the anonymous + memory pager + <braunr> antrik: I don't know how block caching behaves + <antrik> BTW, is it a know problem that doing ^C on a "cp -a" seems to hang + the whole system?... + <antrik> (the whole hurd instance that is... the other instance is not + affected) + <youpi> not that I know of + <braunr> seems like a deadlock in the anonymous memory handling + <youpi> (and I've never seen that) + <antrik> happens both in my main system (using ancient hurd/libc) and in my + subhurd (recently upgraded to current stuff) + <antrik> this make testing this stuff quite a lot harder... [sigh] + <antrik> any suggestions how to debug this hang? + <braunr> antrik: no :/ + +2011-04-28: [[!taglink open_issue_documentation]] + + <antrik> hm... is it normal that "swap free" doesn't increase as a process' + memory is paged back in? + <youpi> yes + <youpi> there's no real use cleaning swap + <youpi> on the contrary, it makes paging the process out again longer + <antrik> hm... so essentially, after swapping back and forth a bit, a part + of the swap equal to the size of physical RAM will be occupied with stuff + that is actually in RAM? + <youpi> yes + <youpi> so that that RAM can be freed immediately if needed + <antrik> hm... that means my effective swap size is only like 300 MB... no + wonder I see crashes under load + <antrik> err... make that 230 actually + <antrik> indeed, quitting the application freed both the physical RAM and + swap space + <braunr> 02:28 < antrik> hm... is it normal that "swap free" doesn't + increase as a process' memory is paged back in? + <braunr> swap is the backing store of anonymous memory, like ext2fs is the + backing store of memory objects created from its pager + <braunr> so you can view swap as the file system for everything that isn't + an external memory object + + +# IRC, freenode, #hurd, 2011-11-15 + + <braunr> hm, now my system got unstable + <braunr> swap is increasing, without any apparent reason + <antrik> you mean without any load? + <braunr> with load, yes + <braunr> :) + <antrik> well, with load is "normal"... + <antrik> at least for some loads + <braunr> i can't create memory pressure to stress reclaiming without any + load + <antrik> what load are you using? + <braunr> ftp mirrorring + <antrik> hm... never tried that; but I guess it's similar to apt-get + <antrik> so yes, that's "normal". I talked about it several times, and also + wrote to the ML + <braunr> antrik: ok + <antrik> if you find out how to fix this, you are my hero ;-) + <braunr> arg :) + <antrik> I suspect it's the infamous double swapping problem; but that's + just a guess + <braunr> looks like this + <antrik> BTW, if you give me the exact command, I could check if I see it + too + <braunr> i use lftp (mirror -Re) from a linux git repository + <braunr> through sftp + <braunr> (lots of small files, big content) + <antrik> can't you just give me the exact command? I don't feel like + figuring it out myself + <braunr> antrik: cd linux-stable; lftp sftp://hurd_addr/ + <braunr> inside lftp: mkdir linux-stable; cd linux-stable; mirror -Re + <braunr> hm, half of physical memory just got freed + <braunr> our page cache is really weird :/ + <braunr> (i didn't delete any file when that happened) + <antrik> hurd_addr? + <braunr> ssh server ip address + <braunr> or name + <braunr> of your hurd :) + <antrik> I'm confused. you are mirroring *from* the Hurd box? + <braunr> no, to it + <antrik> ah, so you login via sftp and then push to it? + <braunr> yes + <braunr> fragmentation looks very fine + <braunr> even for the huge pv_entry cache and its 60k+ entries + <braunr> (and i'm running a kernel with the cpu layer enabled) + <braunr> git reset/status/diff/log/grep all work correctly + <braunr> anyway, mcsim's branch looks quite stable to me + <antrik> braunr: I can't reproduce the swap leak with ftp. free memory + idles around 6.5 k (seems to be the threshold where paging starts), and + swap use is constant + <antrik> might be because everything swappable is already present in swap + from previous load I guess... + <antrik> err... scratch that. was connected to the wrong host, silly me + <antrik> indeed swap gets eaten away, as expected + <antrik> but only if free memory actually falls below the + threshold. otherwise it just oscillates around a constant value, and + never touches swap + <antrik> so this seems to confirm the double swapping theory + <youpi> antrik: is that "double swap" theory written somewhere? + <youpi> (no, a quick google didn't tell me) + + +## IRC, freenode, #hurd, 2011-11-16 + + <antrik> youpi: + http://lists.gnu.org/archive/html/l4-hurd/2002-06/msg00001.html talks + about "double paging". probably it's also the term others used for it; + however, the term is generally used in a completely different meaning, so + I guess it's not really suitable for googling either ;-) + <antrik> IIRC slpz (or perhaps someone else?) proposed a solution to this, + but I don't remember any details + <youpi> ok so it's the same thing I was thinking about with swap getting + filled + <youpi> my question was: is there something to release the double swap, + once the ext2fs pager managed to recover? + <antrik> apparently not + <antrik> the only way to free the memory seems to be terminating the FS + server + <youpi> uh :/ + + +# IRC, freenode, #hurd, 2011-11-30 + + <antrik> slpz: basically, whenever free memory goes below the paging + threshold (which seems to be around 6 MiB) while there is other I/O + happening, swap usage begins to increase continuously; and only gets + freed again when the filesystem translator in question exits + <antrik> so it sounds *very* much like pages go to swap because the + filesystem isn't quick enough to properly page them out + <antrik> slpz: I think it was you who talked about double paging a while + back? + <slpz> antrik: probably, sounds like me :-) + <antrik> slpz: I have some indication that the degenerating performance and + ultimate hang issues I'm seeing are partially or entirely caused by + double paging... + <antrik> slpz: I don't remember, did you propose some possible fix? + <slpz> antrik: hmm... perhaps it wasn't me, because I don't remember trying + to fix that problem... + <slpz> antrik: at which point do you think pages get duplicated? + <antrik> slpz: it was a question. I don't remember whether you proposed + something or not :-) + <antrik> slpz: basically, whenever free memory goes below the paging + threshold (which seems to be around 6 MiB) while there is other I/O + happening, swap usage begins to increase continuously; and only gets + freed again when the filesystem translator in question exits + <antrik> so it sounds *very* much like pages go to swap because the + filesystem isn't quick enough to properly page them out + <tschwinge> + http://www.bddebian.com:8888/~hurd-web/open_issues/ext2fs_page_cache_swapping_leak/ + <slpz> tschwinge: thanks + <slpz> antrik: I see + <tschwinge> Always at your service. ;-) + <slpz> antrik: I didn't addressed this problem directly, but when I've + modified the pageout mechanism to provide a special treatment for + external pages, I also removed the possibility of sending them to the + default pager + <slpz> antrik: this was in my experimental environment, of course + <antrik> slpz: oh, nice... so it may fix the issues I'm seeing? :-) + <antrik> anything testable yet? + <slpz> antrik: yes, only anonymous memory could be swapped with that + <slpz> antrik: it works, but is ugly as hell + <antrik> tschwinge: these is also your observation about compilations + getting slower on further runs, and my followups... I *suspect* it's the + same issue + +[[performance/degradation]]. + + <slpz> antrik: I'm thinking about establishing a repository for these + experimental versions, so they don't get lost with the time + <antrik> slpz: please do :-) + <slpz> antrik: perhaps in savannah's HARD project + <antrik> even if it's not ready for upstream, it would be nice if I could + test it -- right now it's bothering me more than any other Hurd issues I + think... + <slpz> also, there's another problem which causes performance degradation + with the simple use of the system + <tschwinge> slpz: Please just push to Savannah Hurd. Under your + slpz/... or similar. + <tschwinge> antrik: Might very well be, yes. + <slpz> and I almost sure it is the fragmentation of the task map + <slpz> tschwinge: ok + <slpz> after playing a bit with a translator, it can easily get more than + 3000 entries in its map + <antrik> slpz: yeah, other issues might play a role here as well. I + observed that terminating the problematic FS servers does free most of + the memory and remove most of the performance degradation, but in some + cases it's still very slow + <slpz> that makes vm_map_lookup a lot slower + <antrik> on a related note: any idea what can cause paging errors and a + system hang even when there is plenty of free swap? + <antrik> (I'm not entirely sure, but my impression is that it *might* be + related to the swap usage and performance degradation problems) + <slpz> I think this degree of fragmentation has something to do with the + reiterative mapping of memory objects which is done in pager-memcpy.c + <slpz> antrik: which kind of paging errors? + <antrik> hm... I don't think I ever noted down the exact message; but I + think it's the same you get when actually running out of swap + <slpz> antrik: that could be the default pager dying for some internal bug + <antrik> well, but it *seems* to go along with the performance degradation + and/or swap usage + <slpz> I also have the impression that we're using memory objects the wrong + way + <antrik> basically, once I get to a certain level of swap use and slowness + (after about a month of use), the system eventually dies + <slpz> antrik: I never had a system running for that time, so it could be a + completely different problem from what I've seen before :-/ + <slpz> Anybody has experience with block-level caches on microkernel + environments? + <antrik> slpz: yeah, it typically happens after about a month of my normal + use... but I can significantly accellerate it by putting some problematic + load on it, such as large apt-get runs... + <slpz> I wonder if it would be better to put them in kernel or in user + space. And in the latter, if it would be better to have one per-device + shared for all accesing translators, or just each task should have its + own cache... + <antrik> slpz: + http://lists.gnu.org/archive/html/bug-hurd/2011-09/msg00041.html is where + I described the issue(s) + <antrik> (should send another update for the most recent findings I + guess...) + <antrik> slpz: well, if we move to userspace drivers, the kernel part of + the question is already answered ;-) + <antrik> but I'm not sure about per-device cache vs. caching in FS server diff --git a/open_issues/extern_inline.mdwn b/open_issues/extern_inline.mdwn new file mode 100644 index 00000000..a3a22b16 --- /dev/null +++ b/open_issues/extern_inline.mdwn @@ -0,0 +1,109 @@ +[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +[[!toc]] + + +# IRC, unknown channel, unknown date + + <tschwinge> youpi: Did you ever review the Savannah hurd branch master-fix_extern_inline? + <youpi> why static inlines instead of extern lines ? + <youpi> +in + <youpi> static inlines can lead to space waste where it isn't inlined + <tschwinge> Are you sure about that -- I don't think so. + <tschwinge> At least with 99 inlining. + <youpi> what can the compiler do where it isn't inlined ? + <youpi> include a copy + <youpi> thus space waste + <youpi> 00000000004004b1 t f + <youpi> 00000000004004d5 t f + <youpi> I've juste checked + <youpi> two copies of my inline function + <youpi> one per .o + <tschwinge> Yes, but isn't it expected tobe that way? ARen't these functions those that are never included in a libarary, as opposed to those which I switched to __extern_inline in the next patch? + <tschwinge> It's been a long time that I had a look at this... + <tschwinge> The problem with the patch from the Debian package is that the functions didn't end up in the libraries anymore. + <youpi> ah you mean these are private functions and thus shouldn't be exposed (unexpected_reply for instance) + <youpi> but the duplication issue still holds + <youpi> the functions not ending up in the library is a concern indeed + <tschwinge> That's what my second patch fixes, I think. + <youpi> grah, callisto rebooted for no reason + <youpi> ah, indeed the second patch fixes things correctly + <youpi> uh, indeed it's --dbg-package=hurd in there + <youpi> how odd + <youpi> tschwinge: for the libftpconn case, yes unexpected_reply should probably be a static inline + <tschwinge> Is this true: + <tschwinge> static inline -- either inline or emit a local symbol vs. extern inline -- either inline or emit a reference to an external symbol. + <youpi> so as to not expose it + <youpi> for other cases we can keep an extern inline as they are just programs + <tschwinge> Then everything that's not expected to end up in a libarary must be static inline, as otherwise, when the compiler can't inline, there wouldn't be a reference to it available. + <youpi> and that avoids duplicate code + <youpi> yes + <youpi> but as long as you provide the extern inlines by compiling an xinl.c there's no problem + <tschwinge> Sure, that'd be the alternative. + <youpi> for libraries you need to take care of the symbols you want to export (which can thus be in xinl.c), and those you don't want to export (and thus keep static inlines) + <tschwinge> So you say it'd be better to do that (xinl.c) instead of static inline? + <youpi> for programs, you can just keep them all extern inlines + <youpi> yes, it shares code + <youpi> it's only in the case of symbols that shouldn't be exported by the library that we need to use static inlines + <tschwinge> ANd in .c files that are part of programs I'd also use extern inline or static inline? + <youpi> for programs just always use extern lines + <youpi> +in + <youpi> as you don't care about symbol exposure + <youpi> unless the inline is defined in a .c file of course, in that case it's useless to make it extern + <tschwinge> But then I also always need xinl.c files for those, which we apparently don't have in a few places. + <youpi> yes + <tschwinge> But probably didn't notice so far, as the functions could always be inlined. + <youpi> probably because we used to have luck + <youpi> yes + <tschwinge> Yes, I was thinking about the term/munge.c thing. + <tschwinge> OK, I think I get it now. Then I'll try to fix this accordingly. + <tschwinge> But not now. Thanks for the help! + <youpi> ok, thanks + <tschwinge> It was quite a bit confusing to me. + <tschwinge> Due to the mostly reversed definition of extern inline in glibc (I think). + <youpi> inline definitely is confusing + <youpi> especially since the semantic has changed over time and according to standards :) + <tschwinge> And then GCC changing that according to C99. + <tschwinge> Yes. + + +# IRC, freenode, #hurd, 2012-03-14 + + <youpi> + http://anonscm.debian.org/gitweb/?p=pkg-hurd/hurd.git;a=blob;f=debian/patches/extern_inline_fix.patch;h=b9eacbff97dc56e99a69ddb601a5fc948f6e44a7;hb=HEAD + <youpi> maybe review it, and then we apply it + <pinotree> + http://patch-tracker.debian.org/patch/series/view/hurd/20120222-1/extern_inline_fix.patch + ;) + <civodul> youpi: the #ifdef __USE_EXTERN_INLINES in there and the extra + "extern" decls look wrong to me + <youpi> iirc USE_EXTERN_INLINES is needed + <youpi> otherwise it's not compliant + <youpi> or maybe it's for -O0 + <youpi> anyway IIRC it's needed + <civodul> when !defined __USE_EXTERN_INLINES, you end up with extern decls + with no corresponding definition + <youpi> yes + <youpi> they are defined in the code + <civodul> where? + <youpi> there's a special .c file in each lib + <youpi> libdiskfs/extern-inline.c + <youpi> etc + <civodul> oooh, right + <youpi> extern inline means that anyway + <youpi> the compiler is allowed to not always inline + <civodul> yes + <civodul> that looks good to me, then + <civodul> youpi: can you apply it, with proper authorship & co.? + <civodul> (no rush, though) + <youpi> sure diff --git a/open_issues/faccessat.mdwn b/open_issues/faccessat.mdwn new file mode 100644 index 00000000..911acbb6 --- /dev/null +++ b/open_issues/faccessat.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_hurd]] + +`faccessat()` fails on some cases; in particular when: + +* flags does not have `AT_EACCESS` +* dirfd is not `AT_FDCWD` +* pathname is not an absolute path + +In such case, it will return -1 setting `ENOTSUP` as errno. + +[[faccessat.c]] diff --git a/open_issues/faccessat/faccessat.c b/open_issues/faccessat/faccessat.c new file mode 100644 index 00000000..24b1233c --- /dev/null +++ b/open_issues/faccessat/faccessat.c @@ -0,0 +1,26 @@ +#include <fcntl.h> +#include <unistd.h> +#include <stdio.h> +#include <errno.h> +#include <string.h> +#include <stdlib.h> + +#define TESTFN "faccessat-test-file" + +int main() +{ + int fd; + int ret; + + system("touch " TESTFN ); + fd = open(".", O_RDONLY); + printf("> open: %d\n", fd); + + errno = 0; + ret = faccessat(fd, TESTFN, R_OK, 0); + printf("> faccessat: %d, %d (%s)\n", ret, errno, strerror(errno)); + + close(fd); + + return 0; +} diff --git a/open_issues/fakeroot_exit_0.mdwn b/open_issues/fakeroot_exit_0.mdwn new file mode 100644 index 00000000..c6075b17 --- /dev/null +++ b/open_issues/fakeroot_exit_0.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]]."]]"""]] + + $ fakeroot ./scripts/mkinstalldirs /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/debian/tmp-libc/usr/include + [...] + + LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot + + LD_PRELOAD=libfakeroot-tcp.so + + ./scripts/mkinstalldirs /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/debian/tmp-libc/usr/include + libfakeroot: connect: Interrupted system call + + RESULT=0 + + exit $RESULT + + exit 0 + kill -s HUP 23612 + + kill -s HUP 23612 + +(The `EINTR` issue has been [[!debbug desc="fixed" 641200]].) + +`connect() < 0` invokes `fail()` which invokes `exit(1)`. Not yet figured out +why the process exits 0 dispite that. `LD_PRELOAD` issue? ([[!taglink +open_issue_glibc]].) + + +# Build + +`libacl1-dev` is missing. + + $ DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -uc -b -d diff --git a/open_issues/fcntl_locking_dev_null.mdwn b/open_issues/fcntl_locking_dev_null.mdwn new file mode 100644 index 00000000..4c65a5c4 --- /dev/null +++ b/open_issues/fcntl_locking_dev_null.mdwn @@ -0,0 +1,38 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="fcntl locking /dev/null"]] + +[[!tag open_issue_hurd]] + + +# IRC, OFTC, #debian-hurd, 2012-07-06 + + <pinotree> regarding the libwibble failure (which holds libbuffy → + libbuffy-bindings), the failing test happens because it logs to /dev/null + as test file, + <pinotree> and while doing that, it wants to lock it first, having a + ENOTSUP in return + <youpi> oh + <youpi> locking null, how interesting + <youpi> what is that supposed to do ? :o) + <pinotree> from what i was reading posix, it would seem that such object is + considered a "File" + <youpi> is it our unimplemented record lock, or just the lock operation + that /dev/null doesn't support ? + <youpi> what size is null supposed to be? zero, right? + <pinotree> the latter + <youpi> ah + <youpi> so we can simply make lock return 0 + <youpi> since there's no byte to lock? + <youpi> I don't remember whether you can lock unexistant bytes + <pinotree> indeed, if i change the libwibble unit test to use eg /tmp/foo, + they pas + <pinotree> s diff --git a/open_issues/fdisk.mdwn b/open_issues/fdisk.mdwn new file mode 100644 index 00000000..ece8fc89 --- /dev/null +++ b/open_issues/fdisk.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + Command (m for help): w + The partition table has been altered! + + Calling ioctl() to re-read partition table. + *Segmentation fault* + +Changes have been saved, though. + +Perhaps realted to the [[BLKRRPART_IOCTL]]? diff --git a/open_issues/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/file_locking.mdwn b/open_issues/file_locking.mdwn new file mode 100644 index 00000000..563307a4 --- /dev/null +++ b/open_issues/file_locking.mdwn @@ -0,0 +1,74 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd open_issue_glibc]] + +IRC, #hurd, 2010-12-31. + + <pinotree> youpi: i found the issue with python-apt + <pinotree> s/with/of/ + <youpi> good! + <pinotree> lock file issue, though :/ + <youpi> :/ + <pinotree> this is the sample test case, derived from apt's code: + http://paste.debian.net/103536/ + <pinotree> basically, it seems asking for a file lock in the same process + where there's already such lock on the file, fails + <pinotree> youpi: ↑ + <youpi> uh, posix doesn't even define some nesting + <pinotree> it seems it just talks about concurrency with other processes + <youpi> posix tells more about it later + <youpi> saying that if a lock already exists, then it is replaced by the + new + <youpi> (when inside the same process) + <pinotree> yay, found a bug in hurd :p + <youpi> well, actually it's known + <youpi> i.e. setlk is completely bogus, based on flock + <youpi> and flock doesn't have the same semantic in that regard + <youpi> so we can't fix it without really implementing setlk + <pinotree> the XXX comment in glibc/sysdeps/mach/hurd/fcntl.c, by chance? + :) + <youpi> of course :) + <pinotree> youpi: hm, flock's man page says: + <pinotree> "A process may only hold one type of lock (shared or exclusive) + on a file. Subsequent flock() calls on an already locked file will + convert an existing lock to the new lock mode." + <pinotree> so a new lock in the same process over the original lock should + replace the old one? + <youpi> uh, that's not what I had seen + <pinotree> http://linux.die.net/man/2/flock + <youpi> An attempt to lock the file using one of these file descrip- + <youpi> tors may be denied by a lock that the calling process + has already + <youpi> placed via another descriptor. + <youpi> so it's really not that easy + <pinotree> that's in case of trying to create a lock on a file with a + different fd than the existing lock + <youpi> that's what your testcase does + <pinotree> which, hm, is python-apt's case + <youpi> that being said, the sentence I pasted does not seem to appear in + posix + <pinotree> flock() does not seem posix + <youpi> it may have been the behavior of Linux at some point in the past + <youpi> it's not , but F_SETLK is + <youpi> and in linux world, flock <=> F_SETLK, iirc + <youpi> in glibc world, even + <youpi> (just checked it, see sysdeps/posix/flock.c + <youpi> pinotree: I guess your testcase works on Linux? + <pinotree> which means we should get a proper F_SETLK working, and then + just use this flock version (instead of the custom one), no? + <pinotree> yes, it works on linux (and on kfreebsd, see that python-apt + builds) + <youpi> no, I mean our flock() should probably be happy with locking part + of a file several times + <youpi> (that is, hurd's file_lock() RPC) + <youpi> ah, no, on Linux flock is its own system call + <youpi> (which is independant from lockf from the locking point of view, + iirc) diff --git a/open_issues/file_system_exerciser.mdwn b/open_issues/file_system_exerciser.mdwn new file mode 100644 index 00000000..c51863b9 --- /dev/null +++ b/open_issues/file_system_exerciser.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +Test our file system implementations with the File System Exerciser. + + * <http://codemonkey.org.uk/projects/fsx/> + + +# Alternatives + + +## fs_mark + + +### IRC, freenode, #hurd, 2012-04-30 + + <pinotree> mcsim: http://sourceforge.net/projects/fsmark/ + <pinotree> mcsim: just saw it in debian's NEW queue and from the + description it seemed like something it could be helpful for you + <pinotree> (and in general to test fs'es) diff --git a/open_issues/fork_deadlock.mdwn b/open_issues/fork_deadlock.mdwn new file mode 100644 index 00000000..6b90aa0a --- /dev/null +++ b/open_issues/fork_deadlock.mdwn @@ -0,0 +1,65 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +This started appearing when Jérémie's [[glibc]] signal patches were integrated: +very sporadically, but still now and then, `fork` will hang, as follows, and +typically in `/bin/sh`. + +From a `libtool` invocation: + + #0 0x0107b13c in swtch_pri () at /build/eglibc-Q9jlik/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x0107c9c4 in __spin_lock_solid (lock=0x125080c) at spin-solid.c:27 + No locals. + #2 0x01091427 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55 + No locals. + #3 _hurd_sigstate_lock (ss=0x1250008) at hurdsig.c:172 + No locals. + #4 0x011261ec in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235 + No locals. + #5 __fork () at ../sysdeps/mach/hurd/fork.c:706 + env = {{__jmpbuf = {18784244, 19197896, 1, 16925832, 16925460, 17980399}, __mask_was_saved = 0, __saved_mask = 33}} + pid = 0 + err = <optimized out> + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1250008 + threads = 0x0 + nthreads = 0 + stopped = 1 + i = 6 + [...] + + +Another one in `dash`: + + #0 0x0105927c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x0105ac44 in __spin_lock_solid (lock=0x123580c) at spin-solid.c:27 + No locals. + #2 0x010701c7 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55 + No locals. + #3 _hurd_sigstate_lock (ss=0x1235008) at hurdsig.c:172 + No locals. + #4 0x011048f0 in _hurd_critical_section_unlock (our_lock=0x1235008) at ../hurd/hurd/signal.h:235 + ss = 0x1235008 + pending = <optimized out> + #5 __fork () at ../sysdeps/mach/hurd/fork.c:706 + env = {{__jmpbuf = {18780148, 19087304, 134621988, 0, 16938700, 17842902}, __mask_was_saved = 0, __saved_mask = 4294967295}} + pid = 0 + err = 0 + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1235008 + threads = 0x0 + nthreads = 0 + stopped = 1 + i = 6 + [...] diff --git a/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn b/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn new file mode 100644 index 00000000..39003ae4 --- /dev/null +++ b/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn @@ -0,0 +1,185 @@ +[[!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 +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="fork: mach_port_mod_refs: EKERN_UREFS_OWERFLOW"]] + +[[!toc]] + + +# Original Report + +In the [[GCC testsuite|gcc]], at this point: + + Running /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/unsorted.exp ... + +... `expect` had gone bonkers: + + $ ps --all --format=hurd-long -w + PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + [...] + 3567 1000 10295 3567 3567 2 137M 856K 98.2 5hrs 28 hours expect -- /usr/share/dejagnu/runtest.exp --tool gcc + [...] + +Last lines of `gcc/testsuite/gcc/gcc.sum`: + + PASS: gcc.c-torture/unsorted/q.c, -O2 -flto -flto-partition=none + PASS: gcc.c-torture/unsorted/q.c, -O2 -flto + PASS: gcc.c-torture/unsorted/r.c, -O0 + PASS: gcc.c-torture/unsorted/r.c, -O1 + PASS: gcc.c-torture/unsorted/r.c, -O2 + PASS: gcc.c-torture/unsorted/r.c, -O3 -fomit-frame-pointer + PASS: gcc.c-torture/unsorted/r.c, -O3 -g + PASS: gcc.c-torture/unsorted/r.c, -Os + PASS: gcc.c-torture/unsorted/r.c, -O2 -flto -flto-partition=none + +Last lines of `gcc/testsuite/gcc/gcc.log`: + + Executing on host: /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -flto-partition=none -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c (timeout = 300) + spawn /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -flto-partition=none -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c + PASS: gcc.c-torture/unsorted/r.c, -O2 -flto -flto-partition=none + Executing on host: /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c (timeout = 300) + spawn /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c + +The root filesystem is sort-of deadlocked: `syncfs -c /` doesn't finish +-- even without `-s`. But it is fine to spawn new processes, execute new +commands, etc. + +GDB on 3567: + + (gdb) info threads + 2 Thread 3567.2 0x011aaf4c in mach_msg_trap () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + * 1 Thread 3567.1 0x011aaf9c in swtch_pri () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + (gdb) bt + #0 0x011aaf9c in swtch_pri () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + #1 0x011ac824 in __spin_lock_solid (lock=0x131e8e0) at spin-solid.c:27 + #2 0x011aca1d in __mutex_lock_solid (lock=0x131e8e0) at mutex-solid.c:31 + #3 0x0122dd0b in __mutex_lock (oldmem=0x8076458, bytes=94) at ../mach/lock-intern.h:89 + #4 __libc_realloc (oldmem=0x8076458, bytes=94) at malloc.c:3814 + #5 0x0121de62 in _IO_vasprintf (result_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n", args=0x15f3c9c "") at vasprintf.c:86 + #6 0x01206d1b in ___asprintf (string_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n") at asprintf.c:37 + #7 0x011e2fc8 in __assert_perror_fail (errnum=19, file=0x1305a98 "../sysdeps/mach/hurd/fork.c", line=466, function=0x1305acf "__fork") at assert-perr.c:62 + #8 0x012586c8 in __fork () at ../sysdeps/mach/hurd/fork.c:466 + #9 0x011f92e9 in do_system (line=0x15f42dc "/bin/stty sane > /dev/ttypa") at ../sysdeps/posix/system.c:119 + #10 0x0105bea6 in ?? () from /usr/lib/libexpect.so.5.44.1.15 + #11 0x0105bf6d in ?? () from /usr/lib/libexpect.so.5.44.1.15 + #12 0x0105c229 in exp_getptyslave () from /usr/lib/libexpect.so.5.44.1.15 + #13 0x0103e4b2 in ?? () from /usr/lib/libexpect.so.5.44.1.15 + #14 0x01087d79 in ?? () from /usr/lib/libtcl8.5.so.0 + #15 0x01088beb in ?? () from /usr/lib/libtcl8.5.so.0 + #16 0x0108826a in Tcl_EvalEx () from /usr/lib/libtcl8.5.so.0 + #17 0x0108985f in TclEvalObjEx () from /usr/lib/libtcl8.5.so.0 + [...] + (gdb) bt full + #0 0x011aaf9c in swtch_pri () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x011ac824 in __spin_lock_solid (lock=0x131e8e0) at spin-solid.c:27 + No locals. + #2 0x011aca1d in __mutex_lock_solid (lock=0x131e8e0) at mutex-solid.c:31 + No locals. + #3 0x0122dd0b in __mutex_lock (oldmem=0x8076458, bytes=94) at ../mach/lock-intern.h:89 + No locals. + #4 __libc_realloc (oldmem=0x8076458, bytes=94) at malloc.c:3814 + ar_ptr = <value optimized out> + nb = 104 + newp = 0x68 + oldp = 0x8076450 + oldsize = 104 + __func__ = "__libc_realloc" + #5 0x0121de62 in _IO_vasprintf (result_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n", args=0x15f3c9c "") at vasprintf.c:86 + sf = {_sbf = {_f = {_flags = -72515584, + _IO_read_ptr = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_read_end = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_read_base = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_write_base = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_write_ptr = 0x80764b5 "", _IO_write_end = 0x80764bc "\201\004", + _IO_buf_base = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_buf_end = 0x80764bc "\201\004", _IO_save_base = 0x0, _IO_backup_base = 0x0, _IO_save_end = 0x0, _markers = 0x0, _chain = 0x0, _fileno = 20046008, + _flags2 = 0, _old_offset = 23018464, _cur_column = 0, _vtable_offset = 49 '1', _shortbuf = "\001", _lock = 0x0, _offset = 85643859813466072, + _codecvt = 0x1304583, _wide_data = 0x15f3bc0, _freeres_list = 0x0, _freeres_buf = 0x15f3c58, _freeres_size = 0, _mode = -1, + _unused2 = "\240;_\001\236D0\001\005\000\000\000\340;_\001(K3\001\000\000\000\000\005\000\000\000\000\000\000\000\250\230\060\001\260\303\031\001"}, + vtable = 0x131b9c0}, _s = {_allocate_buffer = 0x122cdf0 <__libc_malloc>, _free_buffer = 0x122cd20 <__libc_free>}} + ret = <value optimized out> + needed = 94 + #6 0x01206d1b in ___asprintf (string_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n") at asprintf.c:37 + done = 1 + #7 0x011e2fc8 in __assert_perror_fail (errnum=19, file=0x1305a98 "../sysdeps/mach/hurd/fork.c", line=466, function=0x1305acf "__fork") at assert-perr.c:62 + errbuf = "\334\r", '\000' <repeats 14 times>, "\f\265\032\001\000\000\000\000x\262\004\b\000\000\000\000\000\000\000\000\377\377\377\377 \262\004\b\250\065\063\001\070A_\001k\000\000\000\000\000\000\000ı2\001\002", '\000' <repeats 11 times>"\366, \377\377\377\270\235\004\bk\000\000\000X=_\001\037\343\037\001\377\377\377\377\000\000\000\000s=_\001\361\t\006\001\070A_\001\362\t\006\001\350\t\006\001\000\000\000\000\304B_\001\350\t\006\001\330\377_\001\033\000\000\000)\036\024\001\364\267\025\001x=_\001Bq\022\001\000\000\000\000\350:\b\b\230=_\001\364\267\025\001X\313\031\b S\005\b\230=_\001\004\334\f\001X\313\031\b\000\022\030\b\300L\005\b\364\267\025\001\370\021\030\b S\005\b\bB_\001\a\365\f\001 S\005\b\320\021\030\b\001\000\000\000\274A_\001,\316\024\001\001\000\000\000\001\000\000\000\344"... + buf = <value optimized out> + #8 0x012586c8 in __fork () at ../sysdeps/mach/hurd/fork.c:466 + newproc = 122 + sigthread_refs = 4 + portnames = 0x63000 + porttypes = 0x64000 + sigthread = 130 + state = {gs = 1, fs = 18236712, es = 20390776, ds = 17004532, edi = 1, esi = 143348, ebp = 23020160, esp = 0, ebx = 23020088, edx = 23020016, + ecx = 23020028, eax = 3966371413, eip = 23020088, cs = 18236712, efl = 0, uesp = 20138312, ss = 18488015} + newtask = 121 + thread = 139 + thread_refs = 65534 + statecount = <value optimized out> + nportnames = 142 + nporttypes = 142 + env = {{__jmpbuf = {20037620, 23068628, 23020252, 23020128, 23019736, 19231503}, __mask_was_saved = 0, __saved_mask = 4222451713}} + pid = <value optimized out> + err = EKERN_INVALID_ADDRESS + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1376808 + threads = 0x65000 + nthreads = 2 + stopped = 0 + i = 2 + #9 0x011f92e9 in do_system (line=0x15f42dc "/bin/stty sane > /dev/ttypa") at ../sysdeps/posix/system.c:119 + status = <value optimized out> + save = <value optimized out> + pid = <value optimized out> + sa = {__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 524288, sa_flags = 0} + omask = 0 + [...] + +`fork` failed here: + + 458 /* We have one extra user reference created at the beginning of this + 459 function, accounted for by mach_port_names (and which will thus be + 460 accounted for in the child below). This extra right gets consumed + 461 in the child by the store into _hurd_sigthread in the child fork. */ + 462 if (thread_refs > 1 && + 463 (err = __mach_port_mod_refs (newtask, ss->thread, + 464 MACH_PORT_RIGHT_SEND, + 465 thread_refs))) + 466 LOSE; + +This is in the parent, before signal thread setup, registering with the +proc server, and starting the new process. + +The error is 19, `EKERN_UREFS_OVERFLOW`. + +(This is likely also the reason why the error path did not execute +successfully.) + +[[!tag open_issue_glibc]] + +On 2010-11-30 and 2010-12-04, when I had again started the GCC testsuite, it +failed again, but at another position (understandably), but with the same +symptoms as shown below. In particular, the `thread_refs` values were the same +ones. + + +# Discussion + + * <http://lists.gnu.org/archive/html/bug-hurd/2010-11/msg00028.html> + + * <http://lists.gnu.org/archive/html/bug-hurd/2010-12/msg00002.html> + +This is likely *simply* a programming error in glibc's fork implementation. + + +# Bounty + +There is a [[!FF_project 273]][[!tag bounty]] on this task. diff --git a/open_issues/formal_verification.mdwn b/open_issues/formal_verification.mdwn new file mode 100644 index 00000000..b7db76ee --- /dev/null +++ b/open_issues/formal_verification.mdwn @@ -0,0 +1,30 @@ +[[!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 +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]]."]]"""]] + +*Formal verification* ([[!wikipedia Formal_verification desc="Wikipedia +article"]]) deals with formally reasoning about a program's correctness. + +Especially in the field of [[DSL]]s, this is used for asserting program codes' +correctness, as explained in {{$microkernel/barrelfish#fof_plos09}}, for +example. + +[[!toc]] + + +# Issues + + * [[locking_issues]] + + * [[term_blocking]] + + +# Bounty + +There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks. diff --git a/open_issues/fsync.mdwn b/open_issues/fsync.mdwn new file mode 100644 index 00000000..d36a75ad --- /dev/null +++ b/open_issues/fsync.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date + + <youpi> azeem: I think I found why apt-get throws Hurd down sometimes + <youpi> the problem is that it basically write(file, 20MB); fsync(); + <youpi> i.e. it throws a storm of dirty-writeback to ext2fs + <youpi> which thus goes into throttling threads + <youpi> since posix explicitely says that fsync() can be void, I think I'll patch apt-get on the buildd + <youpi> (that bug has bitten me too many times in the past days to let it go further) + <youpi> for now it works + * youpi crosses fingers diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn index 76832165..d9940716 100644 --- a/open_issues/gcc.mdwn +++ b/open_issues/gcc.mdwn @@ -1,20 +1,131 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!tag open_issue_porting open_issue_gcc fixed_in_debian]] +[[!tag open_issue_gcc]] -For GCC trunk: +Here's what's to be done for maintaining GCC. -Debian package has patches (for 4.3). Some have been forwarded upstream. (And -have been ignored.) [[Thomas_Schwinge|tschwinge]] is working on getting them -integrated. +Apart from the target-specific configuration machinery, there shouldn't be any +major differences within GCC between the GNU/Hurd and GNU/Linux ports, for +example. Especially all the compiler magic is all the same. + +[[!toc levels=2]] + + +# [[General information|/gcc]] + + +# [[Sources|source_repositories/gcc]] + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..upstream/trunk +-i +/^commit |^---$|hurd|linux|nptl|glibc + +--> + +Last reviewed up to the [[Git mirror's dfed30bca14de84e0446cc02f5a27407dbfdc3e1 +(2012-06-11) sources|source_repositories/gcc]]. + +<http://gcc.gnu.org/install/configure.html> has documentation for the +`configure` switches. + + * Configure fragments that have `*linux*` cases might/should often contain + those for us (and GNU/k*BSD) as well. + + * `configure.ac` + + * `libgomp/configure.tgt` + + * `libstdc++-v3/configure.host` + + `abi_baseline_pair` etc. setting. + + * `libstdc++-v3/config/os/gnu-linux/*` + + Is used for all GNU systems, as per `libstdc++-v3/configure.host`. + Should rename to `gnu-user` to reflect this? + + * `gcc/acinclude.m4`:`gcc_GAS_FLAGS`: always pass `--32` to assembler for + x86 Linux. (Why?) + + * `hurd/usr` + + `NATIVE_SYSTEM_HEADER_DIR`, `638454a19c1c08f01c10517bc72a114250fc4f33`, + [[!message-id "mcrzkhcbftp.fsf@coign.corp.google.com"]]. + + Debian. + + * Eventually: get rid of this special-casing. [[!message-id + "gckk1s$e0b$1@ger.gmane.org"]]. + + * [[`libmudflap`|libmudflap]]. + + * Might [`-fsplit-stack`](http://nickclifton.livejournal.com/6889.html) be + worthwhile w.r.t. our [[multithreaded|multithreading]] libraries? + + * Also see `libgcc/config/i386/morestack.S`: comments w.r.t + `TARGET_THREAD_SPLIT_STACK_OFFSET`; likely needs porting. + + As per `libgcc/config/i386/t-stack-i386`, the former file is only used for + `-fsplit-stack` support -- which is currently enabled for us in + `libgcc/config.host`, but not usable via GCC proper. + + * `gcc/config/gnu-user.h` defines `*SPLIT_STACK*` macros -- which aren't + valid for us (yet), I think. + + * `--enable-languages=[...]` + + * GNAT is not yet ported / bootstrapped? + + * The Google Go's libgo (introduced in + e440a3286bc89368b8d3a8fd6accd47191790bf2 (2010-12-03)) needs + OS configuration / support. + + * `--enable-frame-pointer` + + `gcc/configure.ac`: `enable_frame_pointer=no` + + * `--with-dwarf2`? + + * `--enable-werror` + + * `--enable-checking` + + * `--enable-linker-build-id` + + * `--enable-gnu-unique-object` + + * `--enable-lto`, `--enable-gold` + + [[binutils_gold]] + + * `--enable-indirect-function` + + [[IFUNC]] + + * <http://gcc.gnu.org/ml/gcc/2007-11/msg00289.html>, + <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00672.html> + + * `gcc/config/t-linux` should be named `gcc/config/t-gnu-user` or + similar. Likewise for `gcc/config/i386/t-linux`. + + * Debian's GCC package has Hurd-specific patches. Some have been forwarded + upstream (and have been ignored). [[Thomas_Schwinge|tschwinge]] is working + on getting them integrated. * [\[meta-bug\] bootstrap bugs for \*-gnu\*](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824) @@ -25,26 +136,402 @@ integrated. * [-fstack-protector shouldn't use TLS in freestanding mode](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838) - * [Tool chain configuration: GNU/\* sharing stuff with - GNU/Linux](http://gcc.gnu.org/ml/gcc/2007-11/msg00289.html) + * Check before/after Joseph changes. (Should be fine.) + * 34618b3190c110b8926cc2b1db4b4eac95451995 + What's this used for? (Check ML.) Ask to include i686-pc-gnu (once it is + buildable out of the box)? See also + 73905b5de0d9a086f22ded7638bb1c0ae1b91326. -Additionally: + * Various testsuite bits should include `*-*-gnu*`, too. - * Configure fragments that have `*linux*` cases might/should often contain - those for us (and GNU/k*BSD) as well. + * [low] [[toolchain/cross-gnu]] toolchain bootstrap vs. `fenv.h` in libgcc's + libbid: - * `libgcc/configure.ac` [might - need](http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00315.html) to be - aligned for us to the `*linux*` cases. As well as at the end of - `libgcc/config.host`. Check. + [...]/xgcc [...] -DIN_LIBGCC2 -fbuilding-libgcc [...] -Dinhibit_libc [...] -o bid_decimal_globals.o [...] -c [...]/libgcc/config/libbid/bid_decimal_globals.c + [...]/libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory + compilation terminated. + make[1]: *** [bid_decimal_globals.o] Error 1 + make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/i686-pc-gnu/libgcc' + make: *** [all-target-libgcc] Error 2 - checking whether decimal floating point is supported... no - checking whether fixed-point is supported... no + See threads at [[!message-id + "AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]], + [[!message-id "20110328225532.GE5293@synopsys.com"]], [[!message-id + "4D52D522.1040804@gmail.com"]]. Can simply configure the first GCC with + `--disable-decimal-float`. - * `libgomp/configure.tgt` + Alternatively, can we use `#ifndef inhibit_libc` for this (these?) file(s)? + See `generic-nonstrack.c`, for example. The latter (and also + `generic-morestack-thread.c`) also has a nice explanation of `inhibit_libc` + which could be centralized at one place, for example definition of + `inhibit_libc`. - * [[`libmudflap`|libmudflap]]. + * [low] [[toolchain/cross-gnu]] + + The directory that should contain system headers does not exist: + /media/boole-data/thomas/tmp/gnu-0/sys_root/usr/include + make[2]: *** [stmp-fixinc] Error 1 + make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/gcc' + make[1]: *** [all-gcc] Error 2 + make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj' + + `mkdir` the directory for now, but what is really going on? GCC has *use + `/usr/include` patch*, but glibc still installs into `/include/`? + + * `__GLIBC__` + + IRC, freenode, #hurd, 2012-01-05: + + <civodul> on GNU/kFreeBSD, it's GCC that defines __GLIBC__, funny + <youpi> ?? + <youpi> not from features.h ? + <civodul> in gcc/config/kfreebsd-gnu.h + <civodul> :-) + <pinotree> correct, it's enabled in gcc's config + <pinotree> i discovered that after banging my head on the wall trying + to find out why some stuff wasn't compiling even after kfreebsd + porting patches adding preprocessors checks for __GLIBC__ + + IRC, freenode, #hurd, 2012-05-25: + + <gnu_srs> Hi, looks like __GLIBC__ is not defined by default for GNU? + <gnu_srs> touch foo.h; cpp -dM foo.h|grep LIBC: empty + <braunr> gnu_srs: well, this only tells your the compiler defaults + <tschwinge> gnu_srs: See the email I just sent. + + [[!message-id "87396od3ej.fsf@schwinge.name"]] + + <braunr> __GLIBC__ would probably be introduced by a glibc header + <gnu_srs> tschwinge: I saw your email. I wonder if features.h is + included in the kFreeBSD build of webkit. + <gnu_srs> It is defined in their build, but not in the Hurd build. + <pinotree> gcc on kfreebsd unconditionally defines __GLIBC__ + <pinotree> (a bit stupid choice imho, but hardly something that could + be changed now...) + <braunr> :/ + <braunr> personally i don't consider this only "a bit" stupid, as + kfreebsd is one of the various efforts pushing towards portability + <braunr> and using such hacks actually hinders portability ... + <pinotree> yeah don't tell me, i can remember at least half dozen of + occasions when a code wouldn't have been compiling at all on other + glibc platforms otherwise + <pinotree> sure, i have nothing against kfreebsd's efforts, but making + gcc define something which is proper of the libc used is stupid + <braunr> it is + <pinotree> i spotted changes like: + <pinotree> -#ifdef __linux + <pinotree> +#if defined(__linux__) || defined(__GLIBC__) + <pinotree> and wondered why they wouldn't work at all for us... and + then realized there were no #include in that file before that + preprocessor check + <tschwinge> This is even in upstream GCC gcc/config/kfreebsd-gnu.h: + <tschwinge> #define GNU_USER_TARGET_OS_CPP_BUILTINS() \ + <tschwinge> do \ + <tschwinge> { \ + <tschwinge> builtin_define ("__FreeBSD_kernel__"); \ + <tschwinge> builtin_define ("__GLIBC__"); \ + <tschwinge> builtin_define_std ("unix"); \ + <tschwinge> builtin_assert ("system=unix"); \ + <tschwinge> builtin_assert ("system=posix"); \ + <tschwinge> } \ + <tschwinge> while (0) + <tschwinge> I might raise this upstream at some point. + <pinotree> tschwinge: i could guess the change was proposed by the + kfreebsd people, so asking them before at d-bsd@d.o would be a start + <tschwinge> pinotree: Ack. + <pinotree> especially that they would need to fix stuff afterwards + <pinotree> imho we could propose them the change, and if they agree put + that as local patch to debian's gcc4.6/.7 after wheezy, so there is + plenty of time for them to fix stuff + <pinotree> what should be done first is, however, find out why that + define has been added to gcc + + * [low] Does `-mcpu=native` etc. work? (For example, + 2ae1f0cc764e998bfc684d662aba0497e8723e52.) + + * transactional memory, 4c0315d05fa0f707875686abc4f91f7a979a7c7b + + * `config/mmap.m4` + + * In `libitm/config/`, is the generic stuff (`tls.h`, etc.) enough for + us? + + * f29a2041f32773464e226a83f41762c2e9cf658e + (e53a96c2136f7cdff4699475fea41afeed9dece3) + + Testresults same as for GNU/Linux. + + * [high] 3efc00f6f17778172d3fa7ac737fa1473b3b4d5a, `Check __GLIBC__ when + using __SIGRTMIN`. GCC PR52390. Fixed by + 8d2259c83f94c082ad8a00b5d00bb639ce24efce. + + * 15ac1e637ad0cb92bf7629205c617ea847a4b810 `Build 64-bit libffi multilib for + i?86-linux`. + + * `libstdc++`: uses `_GLIBCXX_HAVE_TLS`, but where is this defined? Supposed + to come from `config/tls.m4:GCC_CHECK_TLS`? + + * `libgcc/gthr-posix.h:__gthread_active_p` -- is this suitable for us? This + is used in libgcc for ObjC wrapper stuff and similar in libstdc++. + C.f. [[!message-id "x57jobtqx89w.fsf@frobland.mtv.corp.google.com"]], + [[!message-id "x57jd359fkx3.fsf@frobland.mtv.corp.google.com"]] as well as + [[!debbug 629866]]/[[!message-id + "20110609002620.GA16719@const.famille.thibault.fr"]]. + + +# Build + +Here's a log of a GCC build run; this is from our [[Git repository's +2e2db3f92b534460c68c2f9ae64455884424beb6 (2012-06-15; 2012-06-06) +sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE. + + $ export LC_ALL=C + $ (cd ../master/ && contrib/gcc_update --touch) + $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 --enable-build-with-cxx --enable-languages=all,ada 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. + +This takes up around 3.1 GiB, and needs roughly 3.0 h on kepler.SCHWINGE and +12.75 h on coulomb.SCHWINGE. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && make -k RUNTESTFLAGS=-v check 2>&1 | tee log_check + +--> + + +## Analysis + + $ toolchain/logs/process gcc build + + * [[`checking if gcc static flag -static + works... no`|glibc_madvise_vs_static_linking]] + + Addressed in Debian glibc. + + * DFP + + Addressed in *hurd/decimal_floating_point* branch. + + +configure: WARNING: decimal float is not supported for this target, ignored + + ... and later on: + + -checking for decimal floating point... bid + +checking for decimal floating point... configure: WARNING: decimal float is not supported for this target, ignored + +dpd + + ... and later on: + + -checking whether decimal floating point is supported... yes + +checking whether decimal floating point is supported... no + +configure: WARNING: decimal float is not supported for this target, ignored + + * `libstdc++-v3/acinclude.m4`: ISO/IEC TR 24733 + + -checking for ISO/IEC TR 24733 ... yes + +checking for ISO/IEC TR 24733 ... no + + * `--enable-decimal-float`, `--enable-fixed-point`, `--with-long-double-128` + + `configure: WARNING: decimal float is not supported for this target, + ignored` + + * `libgcc/configure.ac` [might + need](http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00315.html) to be + aligned for us to the `*linux*` cases. As well as at the end of + `libgcc/config.host`. Check. + + checking whether decimal floating point is supported... no + checking whether fixed-point is supported... no + + * `host-linux.c` vs. `host-default.c` + + * *fixincludes* stuff + + * malloc? + + -cat ../../hurd/gcc/config/i386/pmm_malloc.h > mm_malloc.h + +cat ../../hurd/gcc/config/i386/gmm_malloc.h > mm_malloc.h + + Comes from `gcc/config.gcc`: `i386/t-pmm_malloc` vs. `i386/t-gmm_malloc` + for `i[34567]86-*-linux*` vs. `i[34567]86-*-*`. + + * *libgomp* + + * `libgomp/config/linux/`, `libgomp/config/linux/x86` + + `sed`ed away. + + * `-ftls-model=initial-exec -march=i486 -mtune=i686` + + `sed`ed away. + + * Missing `EOWNERDEAD`, `ENOTRECOVERABLE`. What're they used for? + + * `RLIMIT_VMEM`. Usage kosher? + + * `libtool: link: ar rc .libs/libstdc++.a [...]` + + Just different order of object files, or another problem? TODO + + * `libobjc/encoding.c`: + + libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/encoding.c -c [...] + +[...]/hurd/master/libobjc/encoding.c:128:1: warning: '_darwin_rs6000_special_round_type_align' defined but not used [-Wunused-function] + + * `libobjc/thr.c`: `gcc/gthr-posix.h` + + libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/thr.c -c [...] + +In file included from [...]/hurd/master/libobjc/../libgcc/gthr.h:142:0, + + from [...]/hurd/master/libobjc/thr.c:45: + +../libgcc/gthr-default.h: In function '__gthread_objc_thread_set_priority': + +../libgcc/gthr-default.h:388:41: warning: unused parameter 'priority' [-Wunused-parameter] + + * `/proc/self/*` + + -checking for /proc/self/exe... yes + -checking for /proc/self/maps... yes + +checking for /proc/self/exe... no + +checking for /proc/self/maps... no + + * GCJ: `java-signal.h`, `java-signal-aux.h` + + -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal.h + -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal-aux.h + +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal.h + +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal-aux.h + + * GCJ: `jni_md.h` + + -checking jni_md.h support... yes + +checking jni_md.h support... configure: WARNING: no + + * *default library search path* + + -checking for the default library search path... /lib /usr/lib /lib/i386-linux-gnu /usr/lib/i386-linux-gnu /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib /lib64 /usr/lib64 + +checking for the default library search path... /lib /usr/lib + + * `./classpath/[...]/*.properties` + + Just different order of files, or another problem? + + * `libjava/gnu/gcj/util/natGCInfo.cc` + + libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] -c ../../../master/libjava/gnu/gcj/util/natGCInfo.cc [...] + +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:440:1: warning: unused parameter 'name' [-Wunused-parameter] + +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:446:1: warning: unused parameter 'name' [-Wunused-parameter] + +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:452:1: warning: unused parameter 'name' [-Wunused-parameter] + + * `libgcj.la` + + Just different order of object files, or another problem? + + Is there a pattern that GNU/Hurd hands out the files alphabetically sorted + where it wouldn't need to ([[!taglink open_issue_hurd]])? + + * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0` + + `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` + + * `jar` + + make[2]: Entering directory `[...]/hurd/master.build/[ARCH]/libjava' + -: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=[...]/hurd/master.build/[ARCH]/libjava/scripts/jar" DO=all multi-do + +: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=jar" DO=all multi-do + + Probably because kepler.SCHWINGE has an OpenJDK `/usr/bin/jar`, and + coulomb.SCHWINGE a GCJ one. + + There are other instances of this in the following. + + * *default library search path* + + -checking for the default library search path... /lib /usr/lib /lib/[MULTIARCH] /usr/lib/[MULTIARCH] /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib /lib64 /usr/lib64 + +checking for the default library search path... /lib /usr/lib + + Should be aligned by Samuel's binutils patch. + + * `value-unwind.h` + + -DEFINES='' HEADERS='../../../master/libgcc/config/i386/value-unwind.h' \ + +DEFINES='' HEADERS='' \ + ../../../master/libgcc/mkheader.sh > tmp-libgcc_tm.h + + Comes from `gcc/config.gcc`: for `i[34567]86-*-linux*` + vs. `i[34567]86-*-*`, but apparently is important only for *x86_64* anyway. + + * `soft-fp` prototypes + + ../../../master/libgcc/soft-fp/eqtf2.c:34:9: warning: no previous prototype for '__eqtf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/eqtf2.c:50:1: warning: no previous prototype for '__netf2' [-Wmissing-prototypes] + + ../../../master/libgcc/soft-fp/getf2.c:34:9: warning: no previous prototype for '__getf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/getf2.c:50:1: warning: no previous prototype for '__gttf2' [-Wmissing-prototypes] + + ../../../master/libgcc/soft-fp/letf2.c:34:9: warning: no previous prototype for '__letf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/letf2.c:50:1: warning: no previous prototype for '__lttf2' [-Wmissing-prototypes] + + * `libatomic` on GNU/Linux compiles several more files than on GNU/Hurd. Is + that correct? Probably futex support. + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around 850 MiB, and needs roughly 4 min on kepler.SCHWINGE and 45 +min on coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process gcc install + + * `libtool: finish`: `ldconfig` is not run for the Hurd. + + [[libtool]]. + + * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0` + + `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` (as above) + + * `jar`: as above. + + +# Testsuite + +<http://gcc.gnu.org/install/test.html> + +Testing on GNU/Hurd is blocked on +[[fork_mach_port_mod_refs_ekern_urefs_owerflow]]. + +TODO. Can use parallel testing, see [[!message-id +"20110331070322.GI11563@sunsite.ms.mff.cuni.cz"]]. + + $ make -k RUNTESTFLAGS=-v check 2>&1 | tee log_check + [...] + +This needs roughly 6.5 h on kepler.SCHWINGE and 50.25 h on coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process gcc test + +TODO. + + +# Specific Languages + + * [[GNAT]] - * [[C++]]. + * [[gccgo]] diff --git a/open_issues/gcc/c++.mdwn b/open_issues/gcc/c++.mdwn deleted file mode 100644 index cab4c1f1..00000000 --- a/open_issues/gcc/c++.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -[[!tag open_issue_porting open_issue_gcc fixed_in_debian]] - -Modify the [[hurd/building/cross-compiling]] shell script to configure GCC for -building GCC with C++ support when building its second (i.e., final) version. - -Compiling a most-trivial C++ program used to work with GCC 4.2 and 4.3 (and the -resulting binaries would also work), but linking fails with GCC SVN trunk: - - $ $TARGET-g++ -Wall a.cc -lpthread - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__multf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__fixunstfsi' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__subtf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__divtf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__copysigntf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__addtf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__lttf2' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__floatsitf' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__netf2' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__floatunsitf' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__eqtf2' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__fabstf2' - collect2: ld returned 1 exit status - -Whether this defect report also applies to a natively-build GCC from SVN trunk -has not yet been checked. - -[[Thomas_Schwinge|tschwinge]] suspects the problem to be a configuration issue -of a GCC helper library, whose configuration setup has changed after GCC 4.3. - -The need for `-lpthread` is another story. See the Debian glibc patches -repository for details. diff --git a/open_issues/gccgo.mdwn b/open_issues/gccgo.mdwn new file mode 100644 index 00000000..0ecc1228 --- /dev/null +++ b/open_issues/gccgo.mdwn @@ -0,0 +1,45 @@ +[[!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="Enable Google Go programming (GCC: gccgo)"]] + +[[!tag open_issue_gcc]] + +Make the [Google Go programming language](http://golang.org/) available on +GNU/Hurd in its [[GCC]] *gccgo* implementation, and enable Hurd-specific +features. + +There is a [[!FF_project 263]][[!tag bounty]] on this task. + +--- + + +# Part I + +First, make the language functional, have its test suite pass without errors. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/gccgo feeds=no]] + +--- + + +# Part II + +Next, Hurd-specific features can be added. Add an interface to the +language/environment for being able to do [[RPC]] calls, in order to program +[[hurd/translator]]s natively in the Google Go programming language. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]] diff --git a/open_issues/gdb-heap.mdwn b/open_issues/gdb-heap.mdwn new file mode 100644 index 00000000..75c31bbe --- /dev/null +++ b/open_issues/gdb-heap.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gdb]] + +Might be interesting to have a look at +[*gdb-heap*](https://fedorahosted.org/gdb-heap/) with respect to our +long-lived [[hurd/translator]] processes. diff --git a/open_issues/gdb.mdwn b/open_issues/gdb.mdwn new file mode 100644 index 00000000..1652031b --- /dev/null +++ b/open_issues/gdb.mdwn @@ -0,0 +1,127 @@ +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gdb]] + +Here's what's to be done for maintaining GNU GDB. + +[[!toc levels=2]] + + +# [[General information|/gdb]] + + +# [[Sources|source_repositories/gdb]] + + +# Configuration + +Last reviewed up to the [[Git mirror's ea9812279fe436be9a010d07ef1dbe465199a3d7 +(2011-09-07) sources|source_repositories/gdb]]. + + * Globally + + * a.out, COFF, PE image support and 64 bit support are not interesting. + + * In the testsuites, `.exp` and `.d` files very likely should not only + care for `*-*-linux*`, but also `*-*-gnu*`. (If the need to be + conditionalized like this at all.) + + * `bfd/` + + See [[binutils]]. + + * `libdecnumber/` + + Should/can probably align to GNU/Linux. + + * Have a look at config/i386/i386gnu.mh. + + * configure.tgt + + * glibc-tdep et al. also for GNU/Hurd? + + * [[gdbserver]] + + +# Build + +Here's a log of a GDB build run; this is from our [[Git repository's +695f61ff0f378e1680964128585044799de27015 (2011-09-06) +sources|source_repositories/gdb]], run on kepler.SCHWINGE and coulomb.SCHWINGE. + + $ export LC_ALL=C + $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 --disable-werror 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. + +There are several occurences of *error: dereferencing type-punned pointer will +break strict-aliasing rules* in the MIG-generated stub files; thus no `-Werror` +until that is resolved ([[strict_aliasing]]). + +This takes up around 140 MiB and needs roughly 6 min on kepler.SCHWINGE and 30 +min on coulomb.SCHWINGE. + + +## Analysis + +x86 GNU/Linux' and GNU/Hurd's configurations are slightly different, thus mask +out most of the differences that are due to GNU/Linux supporting more core file +formats and more emulation vectors. + + $ ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/gdb/linux/log_build + $ ssh coulomb.SCHWINGE 'cd tmp/gdb/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/gdb/hurd/log_build + $ diff -wu <(sed -f toolchain/logs/gdb/linux/log_build.sed < toolchain/logs/gdb/linux/log_build) <(sed -f toolchain/logs/gdb/hurd/log_build.sed < toolchain/logs/gdb/hurd/log_build) > toolchain/logs/gdb/log_build.diff + + * Why do we specify `-D_GNU_SOURCE`, and GNU/Linux doesn't? + + * Why does GNU/Linux have an additional `-ldl -rdynamic` when linking `gdb`? + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around 50 MiB, and needs roughly 1 min on kepler.SCHWINGE and 3 +min on coulomb.SCHWINGE. + + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && cat hurd/master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/gdb/linux/log_install + $ ssh coulomb.SCHWINGE 'cd tmp/gdb/ && cat hurd/master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/gdb/hurd/log_install + $ diff -wu <(sed -f toolchain/logs/gdb/linux/log_install.sed < toolchain/logs/gdb/linux/log_install) <(sed -f toolchain/logs/gdb/hurd/log_install.sed < toolchain/logs/gdb/hurd/log_install) > toolchain/logs/gdb/log_install.diff + + * `libtool: finish`: `ldconfig` is not run for the Hurd. + + +# Testsuite + +On GNU/Hurd, hampered by the [[term_blocking]] issue. + + $ make -k check + [...] + +This needs roughly 45 min on kepler.SCHWINGE and TODO min on coulomb.SCHWINGE. + + $ ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && sed -e "s%\(/media/data\)\?${PWD}%[...]%g" < hurd/master.build/gdb/testsuite/gdb.sum' > toolchain/logs/gdb/linux/sum + $ ssh coulomb.SCHWINGE 'cd tmp/gdb/ && sed -e "s%\(/media/erich\)\?${PWD}%[...]%g" < hurd/master.build/gdb/testsuite/gdb.sum' > toolchain/logs/gdb/hurd/sum + $ diff -u -F ^Running toolchain/logs/gdb/linux/sum toolchain/logs/gdb/hurd/sum > toolchain/logs/gdb/sum.diff + + +## Analysis + +TODO. diff --git a/open_issues/gdb/gdbserver.mdwn b/open_issues/gdb/gdbserver.mdwn new file mode 100644 index 00000000..fe239bbc --- /dev/null +++ b/open_issues/gdb/gdbserver.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gdb]] + +Needs porting. Can probably use/share most code from GDB proper. + +# Miscellaneous Issues + + * ``m addr,length'` + + What is `errno`? Is is *the* `errno`? If yes, of the system GDB is + running on, or the system gdbserver is running on? Clarify documentation. diff --git a/open_issues/gdb_attach.mdwn b/open_issues/gdb_attach.mdwn new file mode 100644 index 00000000..4e4f2ea0 --- /dev/null +++ b/open_issues/gdb_attach.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="GDB: attach"]] + +[[!tag open_issue_gdb]] + + +# [[gdb_thread_ids]] + + +# IRC, freenode, #hurd, 2012-06-30 + + <braunr> hm, gdb isn't able to determine which thread is running when + attaching to a process + + +# IRC, freenode, #hurd, 2012-07-02 + + <braunr> woah, now that's a weird message ! + <braunr> when using gdb on a hanged ext2fs : + <braunr> Pid 938 has an additional task suspend count of 1; clear it? (y or + n) + <braunr> when hanged, gdb thinks the target task is already being debugged + :/ + <braunr> no wonder why it's completely stuck + <braunr> hm, the task_suspend might actually be the crash-dump-core server + attempting to create the core :/ + <braunr> hm interesting, looks like a problem with the + diskfs_catch_exception macro + <pinotree> braunr: what's up with it? + <braunr> pinotree: it uses setjmp + <braunr> hm random corruptions :/ + <braunr> definitely looks like a concurrency problem diff --git a/open_issues/gdb_catch_syscall.mdwn b/open_issues/gdb_catch_syscall.mdwn new file mode 100644 index 00000000..366c88f5 --- /dev/null +++ b/open_issues/gdb_catch_syscall.mdwn @@ -0,0 +1,18 @@ +[[!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="GDB: catch syscall"]] + + (gdb) catch syscall + The feature 'catch syscall' is not supported on this architeture yet. + +[[!tag open_issue_gdb]] + +Perhaps can ``marry'' that one with [[hurd/debugging/rpctrace]]? diff --git a/open_issues/gdb_gcore.mdwn b/open_issues/gdb_gcore.mdwn new file mode 100644 index 00000000..69211ac0 --- /dev/null +++ b/open_issues/gdb_gcore.mdwn @@ -0,0 +1,26 @@ +[[!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 +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="GDB: gcore"]] + +[[!tag open_issue_gdb]] + +GDB's `gcore` command doesn't work / needs to be implemented / ported in GDB: + + tschwinge@flubber:~ $ gcore 8371 + [New Thread 8371.1] + [New Thread 8371.2] + [New Thread 8371.3] + /media/data/home/tschwinge/core.cA0ICY:2: Error in sourced command file: + Undefined command: "gcore". Try "help". + gcore: failed to create core.8371 + +If someone is working in this area, they may want to port +<http://code.google.com/p/google-coredumper/>, too. diff --git a/open_issues/gdb_noninvasive_mode_new_threads.mdwn b/open_issues/gdb_noninvasive_mode_new_threads.mdwn new file mode 100644 index 00000000..9b3992f4 --- /dev/null +++ b/open_issues/gdb_noninvasive_mode_new_threads.mdwn @@ -0,0 +1,15 @@ +[[!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_gdb]] + +Debugging a translator. `gdb binary`. `set noninvasive on`. `attach [PID]`. +Translator does some work. GDB doesn't notice new threads. `detach`. `attach +[PID]` -- now new threads are visible. diff --git a/open_issues/gdb_qemu_debugging_gnumach.mdwn b/open_issues/gdb_qemu_debugging_gnumach.mdwn new file mode 100644 index 00000000..d3105f50 --- /dev/null +++ b/open_issues/gdb_qemu_debugging_gnumach.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gdb open_issue_gnumach]] + +\#hurd, freenode, June (?) 2010 + + <jkoenig> is there a way to get gdb to map addresses as required when debugging mach with qemu ? + <jkoenig> I can examine the data if I manually map the addresses th 0xc0000000 but maybe there's an easier way... + <youpi> jkoenig: I haven't found a way + <youpi> I'm mostly using the internal kdb + diff --git a/open_issues/gdb_signal_thread_bt.mdwn b/open_issues/gdb_signal_thread_bt.mdwn new file mode 100644 index 00000000..74065922 --- /dev/null +++ b/open_issues/gdb_signal_thread_bt.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2009 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="GDB: bt on the signal thread"]] + +[[!tag open_issue_gdb]] + + (gdb) r + Starting program: /media/data/home/tschwinge/tmp/h + [New Thread 26731.15] + + Breakpoint 1, 0x08048236 in main () + (gdb) info threads + 5 Thread 26731.15 0x080a97fc in mach_msg_trap () + * 4 Thread 26731.14 0x08048236 in main () + (gdb) thread 5 + [Switching to thread 5 (Thread 26731.15)]#0 0x080a97fc in mach_msg_trap () + (gdb) bt + #0 0x080a97fc in mach_msg_trap () + #1 0x080a272e in mach_msg () + #2 0x080a9934 in mach_msg_server_timeout () + #3 0x080a99ff in mach_msg_server () + #4 0x080a327e in _hurd_msgport_receive () + Cannot access memory at address 0x1012000 diff --git a/open_issues/gdb_thread_ids.mdwn b/open_issues/gdb_thread_ids.mdwn index eeb67f30..c04a10ee 100644 --- a/open_issues/gdb_thread_ids.mdwn +++ b/open_issues/gdb_thread_ids.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="GDB: thread ids"]] @@ -19,3 +20,12 @@ GNU GDB's Pedro Alves: > was, if gnu-nat.c couldn't be using the port's id as thread ids instead of a > locally auto-generated number. Maybe the thread id of the main thread would > be preserved across execs this way + + +Also see [[thread numbering of ps and GDB]]. + +--- + +`attach` to a multi-threaded process. See threads 1 to 5. `detach`. `attach` +again -- thread numbers continue where they stopped last time: now they're +threads 6 to 10. diff --git a/open_issues/git-core-2.mdwn b/open_issues/git-core-2.mdwn index 84e002b5..2d8ad96b 100644 --- a/open_issues/git-core-2.mdwn +++ b/open_issues/git-core-2.mdwn @@ -1,17 +1,25 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!meta title="Hiccup of git clone when checking out files"]] +[[!meta title="Hiccups of Git"]] [[!tag open_issue_porting]] +[[!toc]] + + +# Log + +December, 2008. + On the otherwise-idle flubber: $ git clone git://sources.redhat.com/git/glibc.git @@ -40,7 +48,7 @@ On the otherwise-idle flubber: -rw-r--r-- 1 tschwinge tschwinge 0 2008-12-15 15:49 localedata/charmaps/IBM862 So these files are indeed of zero-length in the checked-out tree. Is this -git's fault or something else's? +Git's fault or something else's? Fixing this situation is easy enough: @@ -48,3 +56,135 @@ Fixing this situation is easy enough: $ git status # On branch master nothing to commit (working directory clean) + +Still seen on 2010-03-16. + +--- + +A very similar issue, seen on 2010-11-17. The working tree had a lot of +differences to HEAD. + + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: unable to unlink old 'gcc/config/darwin.h' (Interrupted system call) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: unable to unlink old 'gcc/config/iq2000/iq2000.md' (Interrupted system call) + error: git checkout-index: unable to create file gcc/config/lm32/lm32.c (File exists) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ ls -l gcc/config/iq2000/iq2000.md gcc/config/lm32/lm32.c + ls: cannot access gcc/config/iq2000/iq2000.md: No such file or directory + -rw-r--r-- 1 tschwinge tschwinge 32159 Nov 17 19:09 gcc/config/lm32/lm32.c + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: git checkout-index: unable to create file gcc/fortran/expr.c (Interrupted system call) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: git checkout-index: unable to create file gcc/config/sol2.h (Interrupted system call) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: unable to unlink old 'gcc/config/i386/i386.c' (Interrupted system call) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + Checking out files: 100% (1149/1149), done. + HEAD is now at fe3e43c Merge commit 'refs/top-bases/hurd/master' into hurd/master + +--- + +2010-12-22, grubber: + + $ git remote update + Fetching savannah + remote: Counting objects: 582331, done. + remote: Compressing objects: 100% (124133/124133), done. + remote: Total 582331 (delta 460856), reused 578352 (delta 457598) + Receiving objects: 100% (582331/582331), 525.15 MiB | 204 KiB/s, done. + fatal: cannot pread pack file: Interrupted system call + fatal: index-pack failed + error: Could not fetch savannah + +--- + +2011-06-10, coulomb.SCHWINGE, checking out [[binutils]]' master branch, +starting from an empty working directory (after an external `git push`): + + $ git checkout -f + fatal: cannot create directory at 'gas/testsuite/gas/bfin': Interrupted system call + $ git checkout -f + error: unable to create file gas/testsuite/gas/i386/ilp32/x86-64-sse4_1-intel.d (File exists) + warning: unable to unlink gas/testsuite/gas/m68k-coff: Operation not permitted + fatal: cannot create directory at 'gas/testsuite/gas/m68k-coff': Operation not permitted + $ git checkout -f + error: unable to create file gas/testsuite/gas/h8300/h8300.exp (File exists) + error: unable to create file gas/testsuite/gas/i386/x86-64-addr32-intel.d (File exists) + error: unable to create file gas/testsuite/gas/ia64/secname.d (File exists) + error: unable to create file gas/testsuite/gas/m68k/pr11676.s (File exists) + Checking out files: 100% (12315/12315), done. + $ git status + # On branch master + # Changes not staged for commit: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: gas/testsuite/gas/h8300/h8300.exp + # modified: gas/testsuite/gas/i386/x86-64-addr32-intel.d + # modified: gas/testsuite/gas/ia64/secname.d + # modified: gas/testsuite/gas/m68k/pr11676.s + # + no changes added to commit (use "git add" and/or "git commit -a") + $ rm gas/testsuite/gas/h8300/h8300.exp gas/testsuite/gas/i386/x86-64-addr32-intel.d gas/testsuite/gas/ia64/secname.d gas/testsuite/gas/m68k/pr11676.s + $ git checkout -f + $ git status + # On branch master + nothing to commit (working directory clean) + + +# Analysis + +2011-06-13 + +Running `git checkout -f` under GDB: + + error: git checkout-index: unable to create file gas/testsuite/gas/cris/string-1.s (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/i386/x86-64-sse-check.d (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/i386/x86-64-sse4_1.d (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/ppc/astest.d (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/tic6x/reloc-bad-4.s (File exists) + warning: unable to unlink include/cgen: Operation not permitted + fatal: cannot create directory at 'include/cgen': Operation not permitted + +Again: + + error: git checkout-index: unable to create file gas/config/te-vxworks.h (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/cris/string-1.s (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/d10v/warning-019.s (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/i860/dual03.s (File exists) + error: git checkout-index: unable to create file ld/testsuite/ld-mmix/sec-7a.s (File exists) + warning: unable to unlink ld/testsuite/ld-powerpc: Operation not permitted + fatal: cannot create directory at 'ld/testsuite/ld-powerpc': Operation not permitted + +And: [[git_duplicated_content]]. + +All these (very likely) have the same root cause: `SA_RESTART` restarting too +much. + +With `git checkout`, Git uses in progress.c a SIGALRM handler (`SA_RESTART`; +invoked every second via `setitimer(ITIMER_REAL)`) to display status messages: +*x % already checked out*. + +To avoid the status update signals every second, in +`[git]/progress.c:start_progress_delay` we can just return `NULL` (manually in +GDB, for example), then both the *error: git checkout-index* and the +[[duplicated content|git_duplicated_content]] issues go away. + +I'm guessing that when returning from a `SA_RESTART` signal handler, too much +of the \`\`syscall''s is being restarted. For example, if a file has already +been created, the restarted creation attempt would fail: *File exists*. If +data has been written, it might get written again (duplication issue). Then, +there are cases where `unlink` apparently returns EINTR, which is not kosher +either. Etc. + +Do we have problems with `SA_RESTART` vs. the atomicity of our syscall-alikes? diff --git a/open_issues/git_duplicated_content.mdwn b/open_issues/git_duplicated_content.mdwn new file mode 100644 index 00000000..cbc171a7 --- /dev/null +++ b/open_issues/git_duplicated_content.mdwn @@ -0,0 +1,131 @@ +[[!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_porting]] + + $ git-new-workdir ~/tmp/binutils/git /media/hd1s1/tmp/master master + error: unable to create file gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d (Interrupted system call) + Checking out files: 100% (12315/12315), done. + Already on 'master' + $ cd /media/hd1s1/tmp/master + $ git status + # On branch master + # Changes not staged for commit: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d + # + no changes added to commit (use "git add" and/or "git commit -a") + $ git checkout -f + $ git status + # On branch master + nothing to commit (working directory clean) + +([[Git issue|git-core-2]] is known.) + + $ git-new-workdir ~/tmp/binutils/git /media/hd1s2/tmp/master master + error: unable to create file bfd/elf32-dlx.c (Interrupted system call) + error: unable to create file bfd/sunos.c (Interrupted system call) + error: unable to create file gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d (Interrupted system call) + error: unable to create file gas/testsuite/gas/mmix/regx-op.d (Interrupted system call) + error: unable to create file gas/testsuite/gas/tic6x/reloc-bad-4.s (Interrupted system call) + error: unable to create file gold/testsuite/script_test_2.t (Interrupted system call) + error: unable to create file ld/testsuite/ld-mmix/loc7m.d (Interrupted system call) + error: unable to create file ld/testsuite/ld-powerpc/tlsexe.g (Interrupted system call) + Checking out files: 100% (12315/12315), done. + Already on 'master' + $ cd /media/hd1s2/tmp/master + $ git status + # On branch master + # Changes not staged for commit: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: bfd/elf32-dlx.c + # modified: bfd/sunos.c + # modified: gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d + # modified: gas/testsuite/gas/mmix/regx-op.d + # modified: gas/testsuite/gas/tic6x/reloc-bad-4.s + # modified: gold/testsuite/script_test_2.t + # modified: ld/testsuite/ld-mmix/loc7m.d + # modified: ld/testsuite/ld-powerpc/tlsexe.g + # + no changes added to commit (use "git add" and/or "git commit -a") + $ git checkout -f + $ git status + # On branch master + nothing to commit (working directory clean) + +Now you'd expect these directories to have identical content, but: + + $ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff + $ ls -l /tmp/diff + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff + $ grep '^[^ @+-]' < /tmp/diff + diff -x .git -ru /media/hd1s1/tmp/master//ld/configure /media/hd1s2/tmp/master//ld/configure + +(Note that this isn't a file that Git had issues with.) + +Try again: + + $ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff_ + $ ls -l /tmp/diff* + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:17 /tmp/diff_ + $ cmp /tmp/diff{,_}; echo $? + 0 + +At least it's consistent. Force a reload: + + # settrans -ag /media/hd1s1 + # settrans -ag /media/hd1s2 + +Try again: + + $ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff__ + $ ls -l /tmp/diff* + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:17 /tmp/diff_ + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:30 /tmp/diff__ + $ cmp /tmp/diff{,__}; echo $? + 0 + +Consistent; thus very likely corrupt on-disk. + +After a few tries, the pattern generally is that for the files where there are +differences, once the file regularely ends, its content appears once more. +That is, the files' content appears once (regularely), and then the same again. + +Some more copying: + + $ (cd /media/hd1s1/tmp/ && cp -a master master_) + $ (cd /media/hd1s2/tmp/ && cp -a master master_) + $ diff -x .git -ru /media/hd1s1/tmp/master{,_}/ > /tmp/diff1 + $ diff -x .git -ru /media/hd1s2/tmp/master{,_}/ > /tmp/diff2 + $ ls -l /tmp/diff{1,2} + -rw-r--r-- 1 thomas thomas 0 10. Jun 19:46 /tmp/diff1 + -rw-r--r-- 1 thomas thomas 0 10. Jun 19:46 /tmp/diff2 + +No further difference. + +--- + + $ git-new-workdir git master master + $ diff -x .git -ur tar_master/ master/ > master.diff + + $ rm -rf ar_master* && (cd git/ && git archive master) | (mkdir ar_master && cd ar_master/ && tar -x) && diff -x .git -ru tar_master/ ar_master/ > ar_master.diff; ls -l ar_master.diff + $ (cd git/ && git archive master) | md5sum + +--- + +2011-06-13 + +-> [[git-core-2]] diff --git a/open_issues/git_nfs_mmap.mdwn b/open_issues/git_nfs_mmap.mdwn new file mode 100644 index 00000000..21067022 --- /dev/null +++ b/open_issues/git_nfs_mmap.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + $ git-new-workdir /media/kepler-data/home/thomas/tmp/source/binutils/git master master + fatal: Out of memory? mmap failed: No such device + $ echo $? + 128 + $ showtrans /media/kepler-data + /hurd/nfs kepler.schwinge.homeip.net:/media/data + +With `sh -x`: + + [...] + + ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/remotes master/.git/remotes + + ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/rr-cache master/.git/rr-cache + + ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/svn master/.git/svn + + cd master + + cp /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/HEAD .git/HEAD + + git checkout -f master + fatal: Out of memory? mmap failed: No such device + +As one can easily guess (and confirm with [[hurd/debugging/rpctrace]]), `git` +tries to [[glibc/mmap]] a file via the [[hurd/translator/nfs]] translator, this +fails, and it isn't prepared to cope with that: + + [...] + 88->dir_lookup (".git/objects/pack/pack-37ca560e7877fa0cc6e5ddcd556aa73e5a3e3f40.idx" 2049 0) = 0 3 "/media/kepler-data/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37" (null) + 62->dir_lookup ("media/kepler-data/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37c" 2049 0) = 0 1 "/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37ca560e7877fa0cc6e5" 61 + 61->dir_lookup ("home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37ca560e7877fa0cc6e5d" 2049 0) = 0 1 "" 84 + task3741-> 3206 (pn{ 33}) = 0 + 84->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) + 84->io_stat_request () = 0 {1 704 0 36308992 0 0 -1 33060 1 1000 1000 4712 0 1307711395 0 1307657003 0 1307657003 0 4096 16 0 1000 0 0 100663296 1836017780 29537 0 0 0 0} + 84->io_map_request () = 0x4000002d (Operation not supported) + 84->io_map_request () = 0x4000002d (Operation not supported) + 76->io_write_request ("fatal: Out of memory? mmap failed: No such device + " -1) = 0 50 + 64->proc_mark_exit_request (32768 0) = 0 + task3741-> 2008 () = 0 + Child 3741 exited with 128 + +This is the [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] issue. + +There is a `NO_MMAP` conditional in Git's source code, but it is a compile-time +conditional. diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn new file mode 100644 index 00000000..31cafbfe --- /dev/null +++ b/open_issues/glibc.mdwn @@ -0,0 +1,943 @@ +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +Here's what's to be done for maintaining glibc. + +[[!toc levels=2]] + + +# [[General information|/glibc]] + + +# [[Sources|source_repositories/glibc]] + + +# [[Debian]] Cheat Sheet + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..sourceware/master +-i +/^commit |^Merge:|^---$|hurd|linux|gs:|__ASSUME + +--> + +Last reviewed up to the [[Git mirror's 56e49b714ecd32c72c334802b00e3d62008d98e3 +(2012-07-25) sources|source_repositories/glibc]]. + + * `t/hurdsig-fixes` + + hurdsig.c: In function '_hurd_internal_post_signal': + hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized] + hurdsig.c:1168:12: note: 'pending' was declared here + + * `t/host-independency` + + [[!message-id "87bougerfb.fsf@kepler.schwinge.homeip.net"]], [[!message-id + "20120525202732.GA31088@intel.com"]], commit + 918b56067a444572f1c71b02f18255ae4540b043. [[!GCC_PR 53183]], GCC commit + c05436a7e361b8040ee899266e15bea817212c37. + + * `t/sysvshm` + + ../sysdeps/mach/hurd/shmat.c: In function '__shmat': + ../sysdeps/mach/hurd/shmat.c:57:7: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration] + ../sysdeps/mach/hurd/shmget.c: In function 'get_exclusive': + ../sysdeps/mach/hurd/shmget.c:85:8: warning: variable 'is_private' set but not used [-Wunused-but-set-variable] + ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'dir' may be used uninitialized in this function [-Wmaybe-uninitialized] + ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'file' may be used uninitialized in this function [-Wmaybe-uninitialized] + + * [[`t/tls`|t/tls]] + + * [[`t/tls-threadvar`|t/tls-threadvar]] + + * t/verify.h + + People didn't like this too much. + + Other examples: + + * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- `static_assert` + + * [[toolchain/cross-gnu]], without `--disable-multi-arch` + + i686-pc-gnu-gcc ../sysdeps/i386/i686/multiarch/strcmp.S -c [...] + ../sysdeps/i386/i686/multiarch/../strcmp.S: Assembler messages: + ../sysdeps/i386/i686/multiarch/../strcmp.S:31: Error: symbol `strcmp' is already defined + make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/string/strcmp.o] Error 1 + make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/string' + + Might simply be a missing patch(es) from master. + + * --build=X + + `long double` test: due to `cross_compiling = maybe` wants to execute a + file, which fails. Thus `--build=X` has to be set. + + * Check what all these are: + + running configure fragment for sysdeps/mach/hurd + checking Hurd header version... ok + running configure fragment for sysdeps/mach + checking for i586-pc-gnu-mig... i586-pc-gnu-mig + checking for mach/mach_types.h... yes + checking for mach/mach_types.defs... yes + checking for task_t in mach/mach_types.h... task_t + checking for thread_t in mach/mach_types.h... thread_t + checking for creation_time in task_basic_info... yes + checking for mach/mach.defs... yes + checking for mach/mach4.defs... yes + checking for mach/clock.defs... no + checking for mach/clock_priv.defs... no + checking for mach/host_priv.defs... no + checking for mach/host_security.defs... no + checking for mach/ledger.defs... no + checking for mach/lock_set.defs... no + checking for mach/processor.defs... no + checking for mach/processor_set.defs... no + checking for mach/task.defs... no + checking for mach/thread_act.defs... no + checking for mach/vm_map.defs... no + checking for mach/memory_object.defs... yes + checking for mach/memory_object_default.defs... yes + checking for mach/default_pager.defs... yes + checking for mach/i386/mach_i386.defs... yes + checking for egrep... grep -E + checking for host_page_size in mach_host.defs... no + checking for mach/machine/ndr_def.h... no + checking for machine/ndr_def.h... no + checking for i386_io_perm_modify in mach_i386.defs... yes + checking for i386_set_gdt in mach_i386.defs... yes + checking whether i586-pc-gnu-mig supports the retcode keyword... yes + + * `sysdeps/i386/stackguard-macros.h` + + See [[t/tls|t/tls]]. + + * Verify 77c84aeb81808c3109665949448dba59965c391e against + `~/shared/glibc/make_TAGS.patch`. + + * `HP_SMALL_TIMING_AVAIL` not defined anywhere. + + * Unify `CPUCLOCK_WHICH` stuff in `clock_*` files. + + * Not all tests are re-run in a `make -k tests; make tests-clean; make -k + tests` cycle. For example, after `make tests-clean`: + + $ find ./ -name \*.out + ./localedata/tst-locale.out + ./localedata/sort-test.out + ./localedata/de_DE.out + ./localedata/en_US.out + ./localedata/da_DK.out + ./localedata/hr_HR.out + ./localedata/sv_SE.out + ./localedata/tr_TR.out + ./localedata/fr_FR.out + ./localedata/si_LK.out + ./localedata/tst-mbswcs.out + ./iconvdata/iconv-test.out + ./iconvdata/tst-tables.out + ./stdlib/isomac.out + ./posix/wordexp-tst.out + ./posix/annexc.out + ./posix/tst-getconf.out + ./elf/check-textrel.out + ./elf/check-execstack.out + ./elf/check-localplt.out + ./c++-types-check.out + ./check-local-headers.out + ./begin-end-check.out + + * `CPUCLOCK_WHICH`, `t/cpuclock` + + /media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt_pic.a(clock_settime.os): In function `clock_settime': + /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:113: undefined reference to `CPUCLOCK_WHICH' + /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:114: undefined reference to `CPUCLOCK_WHICH' + collect2: error: ld returned 1 exit status + make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt.so] Error 1 + make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/rt' + make[1]: *** [rt/others] Error 2 + make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc' + make: *** [all] Error 2 + + * Missing interfaces, amongst many more. + + Many more are missing, some of which have been announced in `NEWS`, others + typically haven't (like new flags to existing functions). Typically, + porters will notice missing functionaly. But in case you're looking for + something to work on, here's a list. + + `AT_EMPTY_PATH`, `CLOCK_BOOTTIME`, `CLOCK_BOOTTIME_ALARM`, + `CLOCK_REALTIME_ALARM`, `O_PATH`, + `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27), + `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`) + `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`, + `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `sendmmsg`, + `setns`, `sync_file_range` + + * `chflags` + + IRC, OFTC, #debian-hurd, 2012-04-27: + + <Steap> Does anyone have any idea why int main(void) { return + chflags(); } will compile with gcc but not with g++ ? It says + that "chflags" was not declared in this scope. + <Steap> I get the same error on FreeBSD, but including sys/stat.h + makes it work + <Steap> Can't find a solution on Hurd though :/ + <youpi> the Hurd doesn't have chflags + <youpi> apparently linux neither + <youpi> what does it do? + <Steap> change flags :) + <Steap> Are you sure the Hurd does not have chflags ? Because gcc + does not complain + <youpi> there is no chflags function in /usr/include + <youpi> but what flags does it change? + <Steap> According to the FreeBSD manpage, it can set flags such as + UF_NODUMP, UF_IMMUTABLE etc. + <youpi> Hum, there is actually a chflags() definition + <youpi> but no declaration + <youpi> so actually chflags is supported, but the declaration was + forgotten + <youpi> probably because since linux doens't have it, it has never + been a problem up to now + <youpi> so I'd say ignore the error for now, we'll add the + declaration + + * `getcontext`/`setcontext` + + Needed for [[gccgo]]. + + IRC, freenode, #hurd, 2012-04-19: + + <gnu_srs> How much work/knowledge is needed to implement + getcontext/setcontext? + <gnu_srs> Any already implemented alternatives available? + <youpi> x86 registers knowledge, as well as unix signal masks + <youpi> there's the linux implementation that can be taken as an + exxample, but the signal part has to be rewritten + <gnu_srs> Well, it's a pity they are not implemented. That's the + remaining hurdle to get gccgo working :-( + <youpi> uh :/ + <gnu_srs> Everything builds, but the testsuite fails due to these + missing functions. + <gnu_srs> Regarding getcontext/setcontext they seem to be written + in assembly for linux but the code is not very long. + <gnu_srs> How much effort would it be to write something similar + for Hurd? Anybody fluent in asm? + <gnu_srs> And registers and signals. + <tschwinge> gnu_srs: Signals is the key thing -- everything else we + can probably just copy. I have never/not yet looked at it, + though. + <gnu_srs> For kfreebsd it is written in C: kern_context.c, 3/4 in + one file: getcontext, setcontext, swapcontext, not makecontext. + <gnu_srs> Dunno how much assembly calls used though. + <gnu_srs> Hi, any preferences about implementing get/setcontext in + C or Asm? + <tschwinge> gnu_srs: I think these will have to be implemented in + assembly. Based on the Linux x86 variants. + + IRC, freenode, #hurd, 2012-04-20: + + <tschwinge> youpi: Your understanding of that is better than mine + -- the *context stuff can't be very useful at the moment, because + when the user changes uc_stack.ss_sp (which the glibc tests are + doing), we're losing access to the _hurd_threadvars. Correct? + <tschwinge> At least the getcontext test works, the other get a + SIGILL. + <tschwinge> others + <tschwinge> _hurd_threadvars issue is just guessing. + <youpi> tschwinge: yes, threadvars are on the stack + <youpi> threadvars is not much code, it should just work, but care + has to be taken on the libpthread/libthread side, which does some + initialization + <tschwinge> OK, that at least matches my understanding. + + * [[`mremap`|mremap]] + + * `syncfs` + + We should be easily able to implement that one. + + * `futimesat`, `readlinkat`, `renameat` + + If we have all of 'em (check Linux kernel), `#define __ASSUME_ATFCTS`. + + * `bits/stat.h [__USE_ATFILE]`: `UTIME_NOW`, `UTIME_OMIT` + + * `io/fcntl.h [__USE_ATFILE]` + + Do we support `AT_FDCWD` et al.? + (80b4e5f3ef231702b24d44c33e8dceb70abb3a06.) + + * `MAP_POPULATE` (`mmap`, `sys/mman.h`) -- *Populate (prefault) + pagetables.* + + Some Linux kernel version, `mm/mmap.c`: + + if (vm_flags & VM_LOCKED) { + if (!mlock_vma_pages_range(vma, addr, addr + len)) + mm->locked_vm += (len >> PAGE_SHIFT); + } else if ((flags & MAP_POPULATE) && !(flags & MAP_NONBLOCK)) + make_pages_present(addr, addr + len); + return addr; + + Is only advisory, so can worked around with `#define MAP_POPULATE 0`, + 8069478040336a7de3461be275432493cc7e4c91. + + * `t/opendirat`: `opendirat` (`scandirat`, `scandirat64`) + + Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 + + 14d96785125abee5e9a49a1c3037f35a581750bd. + + * `madvise`, `MADV_DONTNEED`, `MADV_DONTDUMP`, `MADV_DODUMP` + + [[glibc_madvise_vs_static_linking]]. + + * `msync` + + Then define `_POSIX_MAPPED_FILES`, `_POSIX_SYNCHRONIZED_IO`. + + * `sys/epoll.h` + + Used by [[wayland]], for example. + + * `sys/eventfd.h` + + * `sys/inotify.h` + + * `sys/signalfd.h` + + * `sys/timerfd.h` + + * `timespec_get` (74033a2507841cf077e31221de2481ff30b43d51) + + * `waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`) + + IRC, freenode, #hurd, 2012-04-20: + + <pinotree> in glibc, we use the generic waitflags.h which, unlike + linux's version, does not define WEXITED, WNOWAIT, WSTOPPED, + WCONTINUED + <pinotree> should the generic bits/waitflags.h define them anyway, + since they are posix? + <youpi> well, we'd have to implement them anyway + <youpi> but otherwise, I'd say yes + <pinotree> sure, but since glibc headers should expose at least + everything declared by posix, i thought they should be defined + anyway + <youpi> that might bring bugs + <youpi> some applications might be #ifdefing them + <youpi> and break when they are defined but not working + <pinotree> i guess they would define them to 0, andd having them to + non-zero values shouldn't break them (since those values don't do + anything, so they would act as if they were 0.. or not?) + <youpi> no, I mean they would do something else, not define them to + 0 + <pinotree> like posix/tst-waitid.c, you mean? + <youpi> yes + + For specific packages: + + * [[octave]] + + * Create `t/cleanup_kernel-features.h`. + + * Add tests from Linux kernel commit messages for `t/dup3` et al. + + * In `sysdeps/unix/sysv/linux/Makefile`, there are a bunch of + `-DHAVE_SENDFILE` -- but we do have `sendfile`, too. + + * `/usr/include/pthread.h` overwrite issue + + `make`, after editing `nss/nss_db/db-initgroups.c`: + + [...] + make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/resolv' + make subdir=nss -C nss ..=../ others + make[2]: Entering directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss' + /usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h + /usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied + make[2]: *** [/usr/include/pthread.h] Error 1 + make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss' + make[1]: *** [nss/others] Error 2 + make[1]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker' + make: *** [all] Error 2 + + See [[!message-id "871uv99c59.fsf@kepler.schwinge.homeip.net"]]. Passing + `install_root=/INVALID` to `make`/`make check` is a cheap cure. For `make + install`, prepending an additional slash to `install_root` (that is, + `install_root=//[...]`) is enough to obfuscate the Makefile rules. + + * `sysdeps/unix/sysv/linux/syslog.c` + + * Verify baseline changes, if we need any follow-up changes: + + * a11ec63713ea3903c482dc907a108be404191a02 + * 7e2b0c8562b35155820f87b5ff02a8b6850344cc + * 8c0677fe5d91b7269364ca08fa08ed09e4c2d8c9 + * 5a2a1d75043138e696222ced4560de2fb90b8024 + * 5ae958d74180e2572d198bd7872c86f391de6da7 + * 5b08ac571ff8e94fe96511a532f0d20997de5f52 + * 3d04ff3a5d3ce3616837e1d15e03b6e1b360cf26 + * b2ef2c014b9c66995a3eb4f310ae7c5c510279bf + * 63c4ed22b5048c8701d8806026c23cc95f0df756 + * ac2b484c02b01307ab6bbe5d45ddbf16d64edf8c + * e35fcef8b739ed24e083ff8a3078ac14e101cf67 + * 6fb8cbcb58a29fff73eb2101b34caa19a7f88eba + * 8a492a675e566dc1e666df0a86cbf541442cb179 + * 5dbc3b6cc0b759bf4b22d851ccb9cbf3e3cbc6ef + * c86434ccb576a3ce35b5a74f72b9f03bd45b522a + * d22e4cc9397ed41534c9422d0b0ffef8c77bfa53 + * 15bac72bac03faeb3b725b1d208c62160f0c3ad7 + * c08fb0d7bba4015078406b28d3906ccc5fda9d5a + * 10b3bedcb03386cc280113f552479793e4bac35f + * 754f7da38b0904b4b989d3500cc8dd5be625cf6a + * 3cdaa6adb113a088fdfb87aa6d7747557eccc58d + * 962dba7828cf251a9025ccb43bc6effa30379b72 + * 3162f12e58c3a848db883916843b332b9f8c9d39 + * 1c06ba3100847da6bd1f2e011dc24fa8debd9615 + * 84b9230c404aed4fd3a7bb3d045ca367043dde8c + * 090555538d4347a52807ba9f08cf20ed13206afe + * 817328eea788c746131cf151b64fd250200da333 + * c3758feebf7c8786231465da664743c6f0ec79cc + * 1ac7a2c7b448c851eb8976fcc290a906a4075203 + * c21cc9bcb38a87ff638d1099ca871d94a2192b31 + * 6484ba5ef092b62b7d2112c0d976dbd6d1a40fde + * b8b4863d78bf26b39918fc753b03ed98ef262903 + * b76b818e6fe2061e778b3a9bbe63c554c3f9b3c1 + * 8e9f92e9d5d7737afdacf79b76d98c4c42980508 -- `_dl_map_object` in + `sysdeps/mach/hurd/dl-sysdep.c` + * 0e516e0e14f2f9783a21cd1727bc53776341f857 + * a1fb5e3ebe9d38b5ae6c5bfbfaa04882d52355bc + * cf7c9078a5acdbb435498ace92cd81009637a971 + * db753e2cfb2051ebf20dc089f87c5b1297cc2cff + * 4a531bb0b3b582cb693de9f76d2d97d970f9a5d5 -- looks good. + * 5bd6dc5c2c68fe98691db9b40f87d9b68ea9565b + * 451f001b50870604e1f2daef12f04f9f460d3997 + + a85b5cb4d4a5fc56e2b38638d270bf2daa67eb6c -- BZ10484. `nptl/Versions + [libc] (GLIBC_PRIVATE): Export __libc_alloca_cutoff`. We don't even + define it yet. Also see + [[glibc___libc_alloca_cutoff_should_be_lowered]]. + * 1086d70d916fd0eb969b3d89ff88abd35f6a5c34 + * cfa28e560ef69372b9e15e9a2d924a0fbcfc7bca + * 8cf8ce1702c354a8266e3cfa6ab54c2467d1873f + * 68dc949774cb651d53541df4abdc60327f7e096b + * 70181fddf1467996bea393d13294ffe76b8a0853 + * a77e8cbc394ab098aa1fc3f0a6645a38348d21ca + * 32465c3ea007065acd8ca8199f130cdf4068130d + * 18ba70a559c52719fd94a713cc380514d9d19125 + * 620a05296fe3380b7441ba7720e8b25c48a8c28c + * [low] e6c61494125126d2ba77e5d99f83887a2ed49783 -- `Fix memory leak in + TLS of loaded objects.` Do we need to replicate `nptl/allocatestack.c` + hunk? + * 6e04cbbe79f5965809fdbf1f28d7ae8b4af74d31 + + 1bfbe0d335d3fc44a492648b974a0db19975f6d8 -- `Fix + pathconf(_PC_BUF_SIZE).` + * 28377d1bf58625172a1734b92e835591d4d23a18 -- `Optimize fdopendir a bit.` + * 7fb90fb89bbdf273ab7ab96517fe1b156cd7aee1 + + 6fb2dde3f1aa3a1419cb6c2dfa53dd1d506722a4 -- `Fix Linux getcwd for long + paths` + * f574184a0e4b6ed69a5d9a3234543fba6d2a7367 -- `Fix sched_setscheduler + call in spawn implementation` + * 3b85df27870a47ed1db84e948e37a5a50a178a92 + + f50ef8f1efdd1f2b040acbb8324604f168e8832a -- sysconf + * 68a3f91fcad464c4737c1eaed4ae0bf539801fb2 -- `Fix reporting of invalid + timeouts in emulated pselect` + * ea389b12b3b65c4a7fa91fa76f8c99867eb37865 -- `strndup -> __strndup`; + strndupa? + * 7e4afad5bcf49e03c3b987399c6a8f66a9018660 -- `Nicer output for negative + error numbers in strerror_r`. Change needed for + `sysdeps/mach/_strerror.c`? + * 7ea72f99966a65a56aedba817ee2413ff9b1f23c + + adcd5c15d2a37794d021104160b425ff61f88219 -- `Always fill output buffer + in XPG strerror function`. Change needed for + `sysdeps/mach/xpg-strerror.c`? + * a91710475294c66d0005bdaae0919d36ef8ce3d2 -- sotruss. Does it work? + * b1ebd700c5295a449f8d114740f0d1fb6e6b2eb5 + + 80e2212d8e59933a1641f029ebd360526ff0e074 + + 4997db742946d08be4378cf91221f558f928bc73 -- `Don't document si_code + used for raise()`. Also for `bits/siginfo.h`? + * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- pldd, Does it work? + Probably not: needs `/proc/[PID]/auxv`, `/proc/[PID]/exe`, + `/proc/[PID]/mem` ([[!tag open_issue_hurd]], + [[hurd/translator/procfs]]). + * 9113ea1f3f29b3aee710efc829e85a9772bcb836 -- `--experimental-malloc`. + Watch what happens. + * 4e34ac6a1e256f40ab0d8eeed37aa1ea83440e76 -- `-defsym=_begin=0`. Watch + what happens. Native build: apparently OK. + * f781ef4015504e8a1da649c266584976238aa079 (`--with-default-link`) + + 1b74661a6b93a892ecb1c717dedeedba5c2a976c + + fd5e21c75d8e9221d766f4bc922a237265514ec2. Watch what happens. Native + build: `use-default-link = no`. + * de283087c74f720cf8a7171972e72b5fa2b45e79 (`Handle Lustre filesystem`), + 4e5f31c847982997c856f03bbc35134e9fd0f61f (`Handle ext4 in + {,f}pathconf`). What about stuff like that for us? + * d30cf5bb00bfb286ff14d931fb69f5b53724bcdc (`Find readelf with + AC_CHECK_TOOL`). Aren't there more in other configure.in and Makefile + files? + * 7a03a9c8c4b37b88ac5e82b557d974f3161ddaf9 (`Add read barriers in + cancellation initialization`). Is this needed in other places, too? + * [low] 5744c68d78f6ca6c6500e2c8d3d85b3a31f4ed2a (`Align x86 TCB to 64 + bytes`). Probably we have hidden somewhere such a constant, too (in + libpthread). + * d96de9634a334af16c0ac711074c15ac1762b23c + + ecb1482ffd85fd3279642b1dc045aa867ad4d415 (`Try shell in posix_spawn* + only in compat mode`). Change looks good, but what about + `SPAWN_XFLAGS_TRY_SHELL` for us? + * 3ce1f2959437e952b9db4eaeed2407424f11a4d1 (`Make several tool features + mandatory and simplify the code.`). Generally looks good. + * `locale/global-locale.c`: Apparently, no one is using + `_HURD_THREADVAR_LOCALE`. But it is exported via + `hurd/threadvar.h`. + * `mach/devstream.c`: reversed. Fixed in + `t/repair-mach_devstream.c`. + * `malloc/arena.c`: should be OK. + * `Remove support for !USE___THREAD`. + d063d164335938d557460bebaa7cfe388157b627 (generally looks good; + `csu/errno-loc.c` (should be OK); `include/errno.h` (fixed)) + + (de82006d43e198fd162807c9adc720c7ebd728a3 + + 037e9fe21c92216ef7032ea2796781ec27ca182a) + + 995a80dfbcb443ead5aa22682c884ec5c827a2ea (discussing) + + bc7e1c3667b577ad418f7520df2a7dbccea04ee9 (should be ok). + * [OK] 22a89187139a9083ca73989bfd11597e0f85cb61 (`malloc: Remove all + kinds of unused configuration options and dead code.`). `NO_STARTER` + changes (should be OK). + * [high] `pagesize`, 02d46fc4b969e25e4ba0c54aa95fa98d7279bd05 (`Simplify + malloc initialization`); aebae0537dcb408100b88c6b7647a7e858c43237, `BZ + 11929`. Is this all kosher for us? See [[!message-id + "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]]. + * [OK] 83cd14204559abbb52635006832eaf4d2f42514a (`Remove --wth-tls + option, TLS support is required`). + * a7c8e6a1478de9f990b11e5e853318ccbe4330f2 (`Fix invalid conversion in + __cmsg_nxthdr`). Probably just a C++ thing and not relevant for us; + see [[!message-id "87r52nk1kx.fsf@kepler.schwinge.homeip.net"]]. + * [low] `mmap`, 110946e473b38fc3896212e416d9d7064fecd5b7. Kosher with + respect to our [[glibc/mmap]] peculiarities? + * [OK] `__attribute__ ((__leaf__))`, `BZ #13344`, + aa78043a4aafe5db1a1a76d544a833b63b4c5f5c + + 49a43d80ec5c97cf6136b1ee2687414773b2d5aa + + 3871f58f065dac3917eb18220a479e9591769c8c + + 9beb2334930db81ceada5aa6051fe5ac0554db32 + + 0ffc4f3ebaace42cd545db55a2ac50b6e0cc7d89 + + edc5984d4d18296d7aa3d8f4ed8f7336a743170e + + 57769839788e2c62b68d9dfbf4b35052321278ba. + <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>. + * [low] `conformtest`, 3134156779108fe8b46e0f4cd60d837572faaa93 + + 4efeffc1d583597e4f52985b9747269e47b754e2 + + d94a4670800de6e8f088b8630ad5142866127980 -- should probably mirror + `bits/siginfo.h` changes. + * [low] stack guard, 6c6a98c983c44b440ae66d2aa8f32529a9dd7bfe, + [[!message-id "4F3BE241.9090409@mentor.com"]] -- anything needed for + us? + * [low] `libc-lockP.h` 9463518d0d314d7bd0160315e0ef30e15be08985 -- + probably should do similar changes, also to the generic file. + * [low] `bits/socket.h`/`bits/socket_type.h` [[!message-id + "Pine.LNX.4.64.1203090206420.18868@digraph.polyomino.org.uk"]] + 02a6f887cb3e2c048937111eb4cf150d397609de -- probably should do the same + for the generic version as used by GNU Hurd. + * [low] CFI for `_start`, 6a1bd2a100c958d30bbfe8c9b8f9071d24b7c3f4, + [[!message-id "20120316180551.GA6291@host2.jankratochvil.net"]] -- what + about other architectures? + * `sendmmsg` usage, c030f70c8796c7743c3aa97d6beff3bd5b8dcd5d -- need a + `ENOSYS` stub, [[!message-id "87a9zubdm9.fsf@schwinge.name"]], + `t/sendmmsg`. + * `linkobj/libc.so`, 510bbf14b4f25fec8ee3a2d24de3f24bdbf84333 -- need to + adapt for (conditional?) Sun RPC reversion (if that was the original + cause for the patch)? + * [low] `Add __fsword_t and use it in bits/statfs.h`, + 3e5aef87d76cfa7354f2b0d82b96e59280720796, [[!message-id + "20120517134700.GA19046@intel.com"]] -- only updates one copy of + `bits/statfs.h`; update the others, too, for consistency. + * *baseline* + + +# Build + +Here's a log of a glibc build run; this is from our [[Git repository's +8958805c11c741d9211e20612c86271d906c9a0b (2012-07-28; 2012-06-30) +sources|source_repositories/glibc]], run on coulomb.SCHWINGE. + + $ export LC_ALL=C + $ ../Roger_Whittaker/configure AUTOCONF=: --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build + [...] + $ make install_root=/INVALID 2>&1 | tee log_build_ + [...] + +This takes up around 500 MiB and needs roughly X min on kepler.SCHWINGE and 100 +min on coulomb.SCHWINGE. + +<!-- + + $ (make install_root=/INVALID && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install_root="$PWD".install install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && ln -s /usr/lib/i386-*gnu/libstdc++.so.6 /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 mach/libmachuser.so.1 hurd/libhurduser.so.0.3 ./ && make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test + +Mask out gcc-4.X (with possibly a backslash before the dot), GCC 4.5's column +output for (warning, error) messages, GCC 4.6's `[-Wsomething]` or `[enabled by +default]` identifiers which warning flag triggered. + + $ for f in log_*; do sed -e 's%gcc-4\\\?.[456]%[GCC]%g' -e 's%g++-4\\\?.[456]%[G++]%g' -e 's%\(:[0-9]\+:\)[0-9]\+:%\1%' -e 's% \[\(-W[a-z-]\+\|enabled by default\)\]$%%' < "$f" > "$f".nv; done + + $ 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 + +--> + + +## Analysis + + $ toolchain/logs/process gcc build fetch coulomb.SCHWINGE + +TODO. + + * With GCC 4.5, there's a ton of these warnings: + + hurd/hurd.h: In function '__hurd_fail': + hurd/hurd.h:73: warning: case value '0' not in enumerated type 'error_t' + + ... as well as a few individual instances: + + hurdselect.c: In function '_hurd_select': + hurdselect.c:265: warning: case value '0' not in enumerated type 'error_t' + get-host.c: In function '_hurd_get_host_config': + get-host.c:38: warning: case value '0' not in enumerated type 'error_t' + hurdmsg.c: In function '_S_msg_get_init_ints': + hurdmsg.c:186: warning: case value '0' not in enumerated type 'error_t' + hurdmsg.c: In function '_S_msg_set_init_ints': + hurdmsg.c:273: warning: case value '0' not in enumerated type 'error_t' + intr-msg.c: In function '_hurd_intr_rpc_mach_msg': + intr-msg.c:363: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/setitimer.c: In function 'timer_thread': + sysdeps/mach/hurd/setitimer.c:117: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/wait4.c: In function '__wait4': + sysdeps/mach/hurd/wait4.c:40: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/fork.c: In function '__fork': + sysdeps/mach/hurd/fork.c:423: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/spawni.c: In function '__spawni': + sysdeps/mach/hurd/spawni.c:600: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/setpriority.c: In function 'setonepriority': + sysdeps/mach/hurd/setpriority.c:66: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/ioctl.c: In function 'send_rpc': + sysdeps/mach/hurd/ioctl.c:177: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/ioctl.c: In function '__ioctl': + sysdeps/mach/hurd/ioctl.c:306: warning: case value '0' not in enumerated type 'error_t' + + [[!message-id "20120723195143.7F8142C0B9@topped-with-meat.com"]]. + + * baseline + fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b + introduces: + + genops.c: In function '_IO_flush_all_lockp': + genops.c:869:3: warning: passing argument 1 of '__save_FCT' makes pointer from integer without a cast [enabled by default] + genops.c:869:3: note: expected 'void *' but argument is of type 'int' + + A similar warning has already been (and still is) seen here: + + dl-iteratephdr.c:83:3: warning: passing argument 1 of '__save_FCT' makes pointer from integer without a cast [enabled by default] + dl-iteratephdr.c:83:3: note: expected 'void *' but argument is of type 'int' + + * baseline + fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b + (or probably Samuel's mmap backport) introduces: + + ../sysdeps/mach/hurd/mmap.c: In function '__mmap': + ../sysdeps/mach/hurd/mmap.c:54:15: warning: comparison between pointer and integer [enabled by default] + ../sysdeps/mach/hurd/mmap.c:66:21: warning: comparison between pointer and integer [enabled by default] + ../sysdeps/mach/hurd/mmap.c:143:13: warning: comparison between pointer and integer [enabled by default] + ../sysdeps/mach/hurd/mmap.c:165:24: warning: comparison between pointer and integer [enabled by default] + + * baseline + fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b + introduces: + + nscd_gethst_r.c: In function '__nscd_get_nl_timestamp': + nscd_gethst_r.c:112:4: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration] + + This was already present before: + + nscd_gethst_r.c: In function 'nscd_gethst_r': + nscd_gethst_r.c:426:5: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration] + + * baseline + 2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b..7a270350a9bc3110cd5ba12bbd8c5c8c365e0032 + introduces: + + In file included from regex.c:62:0: + regcomp.c: In function 'init_word_char': + regcomp.c:935:4: warning: large integer implicitly truncated to unsigned type [-Woverflow] + regcomp.c:936:4: warning: large integer implicitly truncated to unsigned type [-Woverflow] + + tst-relsort1.c:6:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] + + +# Install + +TODO. + + $ make install_root="$PWD".install install 2>&1 | tee log_install + [...] + +This takes up around 100 MiB, and needs roughly X min on kepler.SCHWINGE and 16 +min on coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process gcc install fetch coulomb.SCHWINGE + +TODO. + +<!-- + $ diff -wu <(ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && cat hurd/master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' | sed -f open_issues/gdb/log_install-linux.sed) <(ssh coulomb.SCHWINGE 'cd tmp/gdb/ && cat hurd/master.build/log_install | sed "s%\(/media/erich\)\?${PWD}%[...]%g"' | sed -f open_issues/gdb/log_install-hurd.sed) > open_issues/gdb/log_install.diff + +[[log_install.diff]]. + + * `libtool: finish`: `ldconfig` is not run for the Hurd. + +--> + + +# Testsuite + + $ make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test + [...] + +This needs roughly X min on kepler.SCHWINGE and 60 min on coulomb.SCHWINGE. + +Specifying `fast-check=yes` disables the `conformtest` which takes 1.75 h (out +of 2.75 h total) on coulomb.SCHWINGE, doesn't pass anyway, and clearly isn't +our most critical issue to solve. + +<!-- + $ ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && sed < hurd/master.build/gdb/testsuite/gdb.sum -e "s%\(/media/data\)\?${PWD}%[...]%g"' > open_issues/gdb/sum_linux + $ ssh coulomb.SCHWINGE 'cd tmp/gdb/ && sed < hurd/master.build/gdb/testsuite/gdb.sum -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > open_issues/gdb/sum_hurd + +Comparing the results files, [[sum_linux]] to [[sum_hurd]]: + + $ diff -u -F ^Running open_issues/gdb/sum_linux open_issues/gdb/sum_hurd > open_issues/gdb/sum.diff + +[[open_issues/gdb/sum.diff]]. +--> + + +## Analysis + + $ toolchain/logs/process gcc test fetch coulomb.SCHWINGE + +There is quite a baseline of failures. + + +### Additional Failures Compared to Debian + + $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_test > log_test.filtered + $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/compare.sh ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/expected-results-i486-gnu-libc log_test.filtered + + * `bug-atexit3.out`, `debug/tst-chk4`, `debug/tst-chk5`, `debug/tst-chk6`, + `debug/tst-lfschk4`, `debug/tst-lfschk5`, `debug/tst-lfschk6` + + dlopen failed: libstdc++.so.6: cannot open shared object file: No such file or directory + + See [[!message-id "20090420002344.11798.qmail@s461.sureserver.com"]]. + Hacked around with `ln -s /usr/lib/i386-*gnu/libstdc++.so.6 + /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 ./`. + This is a bug in the glibc test harness. Should probably use some + `configure` magic akin to the `fixincludes` stuff (`gcc-4.4 + -print-file-name=libstdc++.so.6`, etc.). + + * `debug/tst-chk4`, `debug/tst-chk5`, `debug/tst-chk6`, `debug/tst-lfschk4`, + `debug/tst-lfschk5`, `debug/tst-lfschk6` + + Fail in the same way as the C ones, `tst-chk1..3`. + + * `io/ftwtest`, `posix/globtest`, `iconvdata/iconv-test`, `intl/tst-gettext`, + `malloc/tst-mtrace`, `elf/tst-pathopt`, `iconvdata/tst-tables`, + `grp/tst_fgetgrent`, `dlfcn/tststatic`, `dlfcn/tststatic2`, + `posix/wordexp-tst`, `localedata/bug-setlocale1.out`, `posix/tst-getconf` + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/io/ftwtest: error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory + + Looking into `localedata/bug-setlocale1.c`, it is clear what it going on: + only the root of the build directory is added for `--library-path`, but + none of the other directories that are additionally used. This is a bug in + the glibc test harness. Hacked around by `ln -s mach/libmachuser.so.1 + hurd/libhurduser.so.0.3 ./`. Hopefully the other instances are similar. + + * `posix/tst-getconf` + + Ends with: + + getconf POSIX_ALLOC_SIZE_MIN /: /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486/posix/getconf: pathconf: /: Invalid argument + + * `dlfcn/tststatic`, `dlfcn/tststatic2` + + No output, SEGFAULT. + + * `math/test-idouble`, `math/test-ifloat`, `math/test-ildoubl`, + `math/test-ldouble` + + SIGSEGV. + + * `rt/tst-aio10`, `rt/tst-aio9` + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10.o: In function `do_test': + tst-aio10.c:(.text+0x1b): undefined reference to `pthread_self' + tst-aio10.c:(.text+0x78): undefined reference to `pthread_barrier_init' + tst-aio10.c:(.text+0xf7): undefined reference to `pthread_create' + tst-aio10.c:(.text+0x10b): undefined reference to `pthread_barrier_wait' + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10.o: In function `tf': + tst-aio10.c:(.text+0x5ae): undefined reference to `pthread_barrier_wait' + tst-aio10.c:(.text+0x5ef): undefined reference to `pthread_kill' + collect2: ld returned 1 exit status + make[2]: *** [/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10] Error 1 + + * `rt-tst-aio2`, `rt-tst-aio3`, `rt/tst-mqueue3`, `rt/tst-mqueue6`, + `rt/tst-mqueue8`, `elf/tst-thrlock`, `rt/tst-timer3`, + `nss//libnss_test1.so` + + Compilation: missing `pthread_attr_init`, `pthread_barrier_init`, + `pthread_create`, etc. + + * `elf/tst-audit1`, `elf/tst-audit2` + + SIGKILL. + + * `inet/tst-ether_line` + + tst-ether_line.c:19: error: 'ETH_ALEN' undeclared (first use in this function) + + Will either need a `hurd/netinet/if_ether.h` that includes + `<net/if_ether.h>`, or can do that in the generic `netinet/if_ether.h`? + See also [[!sourceware_PR 11142]]. + + * `gmon/tst-sprofil` + + Floating point exception + + * `posix/bug-regex31-mem`, `posix/tst-fnmatch-mem` + + *output* files: some memory not freed. + + * `assert/test-assert.out` + + Fails sometimes... + + * `stdlib/bug-getcontext.out` + + getcontext failed, errno: 1073741902. + + Is not implemented; see above. In 8958805c11c741d9211e20612c86271d906c9a0b + testing, `stdlib/bug-getcontext.out` now says: *Skipping test; no support + for FP exceptions.* + + * `elf/tst-unique3lib.so`, `elf/tst-unique3lib2.so`, `elf/tst-unique4lib.so` + + Only with GCC 4.4; no longer with 4.5 or 4.6: + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486/elf/tst-unique3lib.os:(.data.DW.ref.__gxx_personality_v0[DW.ref.__gxx_personality_v0]+0x0): undefined reference to `__gxx_personality_v0' + + * `math/test-fenv.out` + + Used to fail (is listed in Debian eglibc-2.13-21's + `expected-results-i486-gnu-libc`), but something between + 22bcba37dd3b782b1a1ec7bf51da468e48f4d2eb and + 005b7594ffe209639dd1ef2b9ed9a4c22307dec1 causes it to passe -- very likely + Jérémie's signaling work. + + * `posix/tst-waitid.out` + + Fails sometimes (is listed in Debian eglibc-2.13-21's + `expected-results-i486-gnu-libc`). + + * `elf/tst-unused-dep.out` (1f393a11f65dcaa1952bdcaf0317a65a5f8aff9d, + [[!sourceware_PR 13706]], [[!message-id "4F4210C1.1090704@redhat.com"]]) + + Unused direct dependencies: + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.6-486/dlfcn/libdl.so.2 + + As of 8958805c11c741d9211e20612c86271d906c9a0b, this test now passes -- + correct? + + +## OLD + +`configure --without-cvs --prefix= --disable-profile --build=i486-gnu +--host=i486-gnu` + +`make -k check` changes from 538603af899057a9ef9583cc447804ec602a45e5 to +c9fd33ef070def49c078c94f8d9bc9f8a8e267f7. + +Configured with `--prefix=/usr` instead of `--prefix=`. + +Resolved failures: + + * localedata/tst_mblen.out + * localedata/tst_mbrlen.out + * localedata/tst_mbrtowc.out + * localedata/tst_mbsrtowcs.out + * localedata/tst_mbstowcs.out + * localedata/tst_mbtowc.out + * localedata/tst_swscanf.out + * localedata/tst_wcrtomb.out + * localedata/tst_wcsrtombs.out + * localedata/tst_wcstombs.out + * localedata/tst_wctob.out + * localedata/tst_wctomb.out + * localedata/bug-iconv-trans.out + * localedata/tst-wctype.out + * math/test-float.out + * math/test-double.out + * posix/tst-vfork3-mem + * io/tst-mkdirat.out + +New: + + * A lot of `error while loading shared libraries: libmachuser.so.1: cannot + open shared object file: No such file or directory`. Is it perhaps picking + that library up from `$prefix/lib/`? + + New failures; likely due to that: + + * iconvdata/iconv-test.out + * iconvdata/tst-tables.out + * malloc/tst-mtrace.out + * grp/tst_fgetgrent.out + * posix/globtest.out + * posix/wordexp-tst.out + * io/ftwtest.out + * elf/tst-pathopt.out + + Changed failures; likely due to that: + + * debug/tst-chk4.out / debug/tst-chk5.out + + -error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory + +error while loading shared libraries: libpthread-stubs.so.0: cannot open shared object file: No such file or directory + +--- + +Changes to b367d4f996512af6841c3cefdb943cb0a826a6a1: nothing interesting. + +--- + +Changes to b85c54a1f7e5241c1ef99dfeaecbd1bf4117564f: nothing interesting. + +New failures: + + * posix/bug-glob3.out (SEGFAULT; but also on Linux) + * wctype/bug-wctypeh.o (compile error; but also on Linux) diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn new file mode 100644 index 00000000..331632f3 --- /dev/null +++ b/open_issues/glibc/debian.mdwn @@ -0,0 +1,64 @@ +[[!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]]."]]"""]] + + +# Open Issues + +`threads = yes` is set in `debian/sysdeps/linux.mk` and +`debian/sysdeps/kfreebsd.mk`, `debian/sysdeps/hurd.mk` set to `no`. But this +is only read in `debian/rules` for deciding some `nscd` package issue? + +`debian/sysdeps/hurd.mk`'s `libc_extra_install` for `ld.so`: check with GCC +configuration. + +Could add a toggle to `$(stamp)build_%` in `debian/rules.d/build.mk` to skip +locale stuff. + +`--disable-compatible-utmp`? + + +# Building + +Run `debian/rules patch` to apply patches (instead of having it done during the +build). Then you can edit files manually. + +Several passes: `libc`, `i686`, `xen`; `EGLIBC_PASSES='libc i686'`, etc. + +If building with `EGLIBC_PASSES=libc` (more specifically, without `xen`), the +`libc0.3-dev_extra_pkg_install` rule in `debian/sysdeps/hurd-i386.mk` will +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, 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. + +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/getlogin_r.mdwn b/open_issues/glibc/getlogin_r.mdwn new file mode 100644 index 00000000..9980ea1f --- /dev/null +++ b/open_issues/glibc/getlogin_r.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="getlogin_r"]] + +[[!tag open_issue_glibc]] + + +# IRC, freenode, #hurd, 2012-04-23 + + * pinotree spots how our getlogin_r() implementation uses a static + buffer... + <braunr> oO + <pinotree> braunr: yeah, the _r means "reentrantbutnotreally" xD + <braunr> pinotree: that's amazing .. + <antrik> pinotree: without having checked the actual implementation, that + doesn't sound like a problem... + <antrik> caching doesn't break reentrancy. the problem with the plain + getlogin() is that a static buffer is *returned to the user* + <pinotree> antrik: http://paste.debian.net/164727/ + <braunr> ah, caching + <pinotree> i don't think this is caching at all + <antrik> pinotree: OK, not actually caching... but same effect as far as I + can tell + <antrik> pinotree: or is it the fixed size of the temporary variable you + are concerned about? + <pinotree> antrik: my concern was about the "static" of the buffer used for + the get_login rpc + <antrik> pinotree: I'm not sure that's a problem. can the login actually + ever change for a running process? + <pinotree> dunno + <pinotree> but if so, it would be pointless to do the rpc every time + instead of just once + <antrik> pinotree: true + * pinotree would just make it non-static and be safe + <antrik> pinotree: well, one might argue that allocating a KiB of stack + space is not very friendly, especially in a low-level library... + <antrik> not sure what the general policy is about such things in libc diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn new file mode 100644 index 00000000..a293eea0 --- /dev/null +++ b/open_issues/glibc/mremap.mdwn @@ -0,0 +1,221 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +[[!toc]] + + +# binutils gold + +## IRC, freenode, #hurd, 2011-01-12 + + <teythoon> I've been looking into building gold on hurd and it built fine + with one minor tweak + <teythoon> and it's working fine according to its test suite + <teythoon> the only problem is that the build system is failing to detect + the hurdish mremap which lives in libmemusage + <teythoon> on linux it is in the libc so the check succeeds + <teythoon> any hints on how to fix this properly? + <antrik> hm... it's strange that it's a different library on the Hurd + <antrik> are the implementations compatible? + <teythoon> antrik: it seems so, though the declarations differ slightly + <antrik> I guess the best thing is to ask on the appropriate list(s) why + they are different... + <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ grep -A1 + mremap /usr/include/sys/mman.h + <teythoon> extern void *mremap (void *__addr, size_t __old_len, size_t + __new_len, int __flags, ...) __THROW; + <teythoon> vs + <antrik> of course it would be possible to modify the configure script to + check for the Hurd variant too; but first we should establish whether + here is actually any reason for being different, or it's just some + historical artefact that should be fixed... + <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ fgrep 'extern + void *mremap' mremap.c + <teythoon> extern void *mremap (void *, size_t, size_t, int, ...); + <teythoon> the problem is that the test fails to link due to the fact that + mremap isn't in the libc on hurd + <antrik> yeah, it would be possible for the configure script to check + whether it works when the hurdish extra library is added explicitely + <antrik> but again, I don't see any good reason for being different here in + the first place... + <teythoon> so should I create a patch to move mremap? + <antrik> if it's not too complicated, that would be nice... it's always + easier to discuss when you already have code :-) + <antrik> OTOH, asking first might spare you some useless work if it turns + out there *is* some reason for being different after all... + so where is the right place to discuss this? + <antrik> bug-hurd mailing list and/or glibc mailing list. not sure which + one is better -- I guess it doesn't hurt to crosspost... + +[[mailing_lists/libc-alpha]] is the correct list, and cross-posting to +[[mailing_lists/bug-hurd]] would be fine, too. + + <teythoon> antrik: some further digging revealed that mremap belongs to + /lib/libmemusage.so on both hurd and linux + <teythoon> the only difference is that on linux there is a weak reference + to that function in /lib/libc-2.11.2.so + <teythoon> $ objdump -T /lib/libc-2.11.2.so | fgrep mremap + <teythoon> 00000000000cf7e0 w DF .text 0000000000000028 GLIBC_2.2.5 + mremap + <antrik> ah, it's probably simply a bug that we don't have this weak + reference too + <antrik> IIRC we had similar bugs before + <antrik> teythoon: can you provide a patch for that? + <teythoon> antrik: unfortunately I have no idea how that weak ref ended up + there + + <guillem> teythoon: also the libmemusage.s seems to be just a debugging + library to be used by LD_PRELOAD or similar + <guillem> which override those memory functions + <guillem> the libc should provide actual code for those functions, even if + the symbol is declared weak (so overridable) + <guillem> teythoon: are you sure that's the actual problem? can you paste + somewhere the build logs with the error? + <teythoon> guillem: sure + <teythoon> http://paste.debian.net/104437/ + <teythoon> that's the part of config.log that shows the detection (or the + failure to detect it) of mremap + <teythoon> this results in HAVE_MREMAP not being defined + <teythoon> as a consequence it is declared in gold.h and this declaration + conflicts with the one from sys/mman.h http://paste.debian.net/104438/ + <teythoon> on linux the test for mremap succeeds + <guillem> teythoon: hmm oh I guess it's just what that, mremap is linux + specific so it's not available on the hurd + <guillem> teythoon: I just checked glibc and seems to confirm that + <braunr> CONFORMING TO This call is Linux-specific, and should not be used + in programs intended to be portable. + <teythoon> ah okay + <teythoon> so I guess we shouldn't ship an header with that declaration... + <guillem> teythoon: yeah :/ good luck telling that to drepper :) + <guillem> teythoon: I guess he'll suggest that everyone else needs to get + our own copy of sys/mman.h + <guillem> s/our/their/ + <teythoon> hm, so how should I proceed? + <braunr> what's your goal ? + <braunr> detecting mremap ? + <teythoon> making binutils/gold compile ootb on hurd + <teythoon> I picked it from the open issues page ;) + <braunr> well, if there is no mremap, you need a replacement + <teythoon> gold has a replacement + <braunr> ok + <braunr> so your problem is fixing the detection of mremap right ? + <teythoon> yes + <braunr> ok, that's a build system question then :/ + <braunr> you need to ask an autotools guy + <teythoon> well, actually the build system correctly detects the absence of + mremap + <braunr> (gold does use the autotools right ?) + <teythoon> yes + <braunr> oh, i'm lost now (i admit i didn't read the whole issue :/) + <teythoon> it is just that the declaration in sys/mman.h conflicts with + their own declaration + <braunr> ah + <braunr> so in the absence of mremap, they use their own builtin function + <teythoon> yes + <teythoon> and according to the test suite it is working perfectly + <teythoon> gold that is + <teythoon> the declaration in mman.h has an extra __THROW + <guillem> a workaround would be to rename gold's mremap to something else, + gold_mremap for example + <braunr> that's really the kind of annoying issue + <braunr> you either have to change glibc, or gold + <guillem> yeah + <braunr> you'll face difficulty changing glibc, as guillem told you + <guillem> the correct solution though IMO is to fix glibc + <braunr> but this may be true for gold too + <braunr> guillem: i agree + <antrik> maybe it would be easiest actually to implement mremap()?... + <braunr> but as this is something quite linux specific, it makes sense to + use another internal name, and wrap that to the linux mremap if it's + detected + <braunr> antrik: i'm nto sure + <antrik> braunr: I don't think using such workarounds is a good + idea. clearly there would be no issue if the header file wouldn't be + incorrect on Hurd + <braunr> antrik: that's why i said i agree with guillem when he says "the + correct solution though IMO is to fix glibc" + <teythoon> what exactly is the problem with getting a patch into glibc? + <braunr> the people involved + <guillem> teythoon: and touching a generic header file + <braunr> but feel free to try, you could be lucky + <teythoon> but glibc is not an linux specific piece of software, right? + <braunr> teythoon: no, it's not + <guillem> erm... + <braunr> teythoon: but in practice, it is + <guillem> supposedly not :) + <antrik> braunr: BTW, by "easiest" I don't mean coding alone, but + coding+pushing upstream :-) + <guillem> so the problem is, misc/sys/mman.h should be a generic header and + as such not include linux specific parts, which are not present on hurd, + kfreebsd, etc etc + <braunr> antrik: yes, that's why guillem and i suggested the workaround + thing in gold + <antrik> that also requires pushing upstream. and quite frankly, if I were + the gold maintainer, I wouldn't accept it. + <guillem> but the easiest (and wrong) solution in glibc to avoid maintainer + conflict will probably be copying that file under hurd's glibc tree and + install that instead + <braunr> antrik: implementing mremap could be relatively easy to do + actually + <braunr> antrik: IIRC, vm_map() supports overlapping + <antrik> well, actually the easiest solution would be to create a patch + that never goes upstream but is included in Debian, like many + others... but that's obviously not a good long-term plan + <antrik> braunr: yes, I think so too + <antrik> braunr: haven't checked, but I have a vague recollection that the + fundamentals are pretty much there + <antrik> teythoon: so, apart from an ugly workaround in gold, there are + essentially three options: 1. implement mremap; 2. make parts of mman.h + conditional; 3. use our own copy of mman.h + <antrik> 1. would be ideal, but might be non-trivial; 2. would might be + tricky to get right, and even more tricky to get upstream; 3. would be + simple, but a maintenance burden in the long term + <teythoon> looking at golds replacement code (mmap & memcpy) 1 sounds like + the best option performance wise + +[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`. +[[I|tschwinge]] remember some discussion about this, but have not yet worked on +locating it. [[Talk to me|tschwinge]] if you'd like to have a look at this. + + +# IRC, OFTC, #debian-hurd, 2012-06-19 + + <bdefreese> OK, how the heck do you get an undefined reference to mremap? + <youpi> simply because we don't have it + <pinotree> mremap exists only on linux + <bdefreese> It's in sys/mman.h + <pinotree> on linux? + <bdefreese> No, on GNU/Hurd + <bdefreese> /usr/include/i386-gnu/sys/mman.h + <youpi> that's just the common file with linux + <youpi> containing just the prototype + <youpi> that doesn't mean there's an implementation behind + <pinotree> youpi: hm no, linux has an own version + <youpi> uh + <bdefreese> Ah, aye, I didn't look at the implementation.. :( + <youpi> it's then odd that it was added to the generic sys/mman.h :) + <bdefreese> Just another stub? + <pinotree> ah, only few linux archs have own versions + <youpi> for the macro values I guess + <pinotree> http://paste.debian.net/175173/ on glibc/master + <bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from? + <youpi> rgrep on a linux box ;) + <youpi> <bits/mman.h> + <youpi> but that's again linuxish + <bdefreese> Aye but with us having that in the header it is causing some + code to be run which utilizes mremap. If that wasn't defined we wouldn't + be calling it. + <youpi> ah + <youpi> we could try to remove it indeed + <bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined + __GNU__? + <youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself diff --git a/open_issues/glibc/octave.mdwn b/open_issues/glibc/octave.mdwn new file mode 100644 index 00000000..b12b7558 --- /dev/null +++ b/open_issues/glibc/octave.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + + +# IRC, OFTC, #debian-hurd, 2012-04-23 + + <pinotree> diffing the octave i386 vs hurd-i386 build logs gives + interesting surprises + <youpi> checking whether this system has an arbitrary file name length + limit... no | checking whether this system has an arbitrary + file name length limit... yes + <youpi> ? + <pinotree> not only that + <youpi> checking whether getcwd handles long file names properly... yes + | checking whether getcwd handles long file names properly... no, but it + is partly worki+ + <youpi> ? + <pinotree> -checking whether fdopendir works... yes + <pinotree> +checking whether fdopendir works... no + <pinotree> (- is i386, + is hurd-i386) + <pinotree> -checking whether getlogin_r works with small buffers... yes + <pinotree> +checking whether getlogin_r works with small buffers... no + <pinotree> -checking for working mkstemp... yes + <pinotree> +checking for working mkstemp... no + <pinotree> +checking for working nanosleep... no (mishandles large + arguments) diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn new file mode 100644 index 00000000..e72732ab --- /dev/null +++ b/open_issues/glibc/t/tls-threadvar.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +This basically means to get rid of `sysdeps/mach/hurd/bits/libc-tsd.h` (and +thus the `_HURD_THREADVAR_*`/`_hurd_threadvar_location` interface), and +directly use `__thread` instead. + +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]]. + +After this has been done, probably the whole `__libc_tsd_*` stuff can be +dropped altogether, and `__thread` directly be used in glibc. diff --git a/open_issues/glibc/t/tls.mdwn b/open_issues/glibc/t/tls.mdwn new file mode 100644 index 00000000..68db2cc1 --- /dev/null +++ b/open_issues/glibc/t/tls.mdwn @@ -0,0 +1,70 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +# To Do + + * Discuss d2431f633e6139a62e1575ec18830f7e81160cf0 with Samuel. + + * `TLS_INIT_TP_EXPENSIVE` is unused; Hurd def. can be removed. + + +# Documentation + +[[!taglink open_issue_documentation]] + + * IRC, freenode, #hurd, 2011-11-26 + + <tschwinge> In glibc multiarch support (strcasecmp for i686 SSE3, etc.) + there is access to memory via gs: -- this will need to be changed for + us, right? + <youpi> depends on the access + <tschwinge> * `optimized strcasecmp and strncasecmp for x86-32` + (multiarch), + <tschwinge> 76e3966e9efc3808a9e7ad09121c5dfc1211c20b + + <tschwinge> 6abf346582ba678f4850a88b4a5950593841df1d + + <tschwinge> 5583a0862cf94f71cbcde91c4043a20af65facca. `gs` + access. + <youpi> + movl __libc_tsd_LOCALE@GOTNTPOFF(%ebx), %eax + <youpi> that's handled by the linker fine + <youpi> it's only the things held in the tcb_t structure which can pose + problem + <tschwinge> tcbhead_t? + <tschwinge> I'm looking at this. + <tschwinge> So, at gs:0, there is the TCB. + <tschwinge> And we have the same layout as NPTL/Linux, just that we + don't have as much data there as they have. + <tschwinge> We're missing multiple_threads, sysinfo, sttack_guard, + pointer_guard, gscope_flag, private_futex, __private_tm[5]. + <tschwinge> So, if one of these is referenced (be it my name or by + numeric offset), this is invalid for us. + <tschwinge> Anything else should work equivalently. + <youpi> yes + <youpi> usually the only numeric offset being used is 0 + <youpi> so it would simply not build + <tschwinge> And the other offsers are generated via tcb-offsets.sym. + <tschwinge> glibc's elf/stackguard-macros.h is wrong for us (but not + used anywhere apart from elf/tst-stackguard1.c, I think). + +After commit a9538892adfbb9f092e0bb14ff3a1703973968af, it's +`sysdeps/i386/stackguard-macros.h`; problem remains. + + <tschwinge> __thread __locale_t __libc_tsd_LOCALE = &_nl_global_locale; + -- this means that a __libc_tsd_LOCALE values will be in the TLS + segment, and this is what is being accessed from the assembler code + with %gs:__libc_tsd_LOCALE@NTPOFF, and the linker will resolve this. + <youpi> yes + <youpi> see in the nm output, the libc_tsd symbols + <youpi> these provide the offsets + <tschwinge> youpi: Thank you, I'm now understanding this part of TLS + much better. + <youpi> have you had a look at the tls.pdf from Uli ? + <youpi> all the gory details are there :) diff --git a/open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn b/open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn new file mode 100644 index 00000000..6d1b4bea --- /dev/null +++ b/open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="glibc: __libc_alloca_cutoff should be lowered"]] + +[[!tag open_issue_hurd open_issue_glibc]] + +Ognyan Kulev, *[LIBC] \_\_libc\_alloca\_cutoff should be lowered*, bug-hurd, +2003-06-12, <http://lists.gnu.org/archive/html/bug-hurd/2003-06/msg00050.html> + +Replace second link (mail.gnu.org) with +<http://lists.gnu.org/archive/html/bug-hurd/2002-09/msg00143.html>. diff --git a/open_issues/glibc_ioctls.mdwn b/open_issues/glibc_ioctls.mdwn new file mode 100644 index 00000000..14329d0f --- /dev/null +++ b/open_issues/glibc_ioctls.mdwn @@ -0,0 +1,72 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <pinotree> d'oh, broken defines for ioctl()! + <pinotree> http://paste.debian.net/45021/ ← any idea about this? looks like something fishy with the SIO* defines + <pinotree> tschwinge: ↑ know anything about this? + <pinotree> #define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← looks like it is missing for bits/ioctls.h + <pinotree> eglibc patch submitted-ioctl-unsigned-size_t.diff should be pimped a bit + + <pinotree> youpi: while trying to compile ossp-uuid (needed by pgsql 8.4, needed by various other stuff), i found a bug in a hurd libc header + <youpi> that's possible + <pinotree> it has a ioctrl() using an id with a value having type 'struct arpreq' + <youpi> ah, that's not a bug then + <youpi> see the ioctl section of the porting page of the wiki + <pinotree> due to the sort of "mangling" done in bits/ioctrls.h, there should be an helper macro for the size of the struct arpreq + <pinotree> +#define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← adding this before any header was enough + * pinotree looks + <youpi> it's not to be done so simply + <youpi> see the page :) + <youpi> I'm afraid _IOT_arpreq can't be properly defined + * pinotree is not finding it... + <pinotree> the closest i see is http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html + <youpi> that's it yes + <youpi> I mean, that's the kind of thing + <youpi> but not the wiki page, let me look + <youpi> http://www.gnu.org/software/hurd/hurd/porting/guidelines.html + <pinotree> i also saw a glib patch adding few types like that (char, short, int) + <youpi> yes that's the same kind of thing + <pinotree> i see + <youpi> setting it to _IOT_SIMPLE(struct arpreq) would probably work with 32bit gnumach and 32bit userland, but may not with e.g. 64bit gnumach and 32bit userland and such + <pinotree> hmmm, sockaddr,sockaddr,int,sockaddr,char[16] + <pinotree> so basically it would support at most 3 elements in a passed struct? + <pinotree> s/elements/fields/ + <youpi> 3 kinds of fields + <youpi> as you provide a count + <pinotree> youpi: so basically: #define _IOT_arpreq _IOT (_IOTS (struct sockaddr), 3, _IOTS (int), 1, _IOTS (char), 16) ? + <pinotree> ie the order of the fields in the struct does not matter, it seems? + <youpi> the order of the fields does matter + <youpi> as this encodes how mig will read the struct to send them + <pinotree> uhm + <youpi> also, _IOTS(struct sockaddr) won't work + <pinotree> yeah i should define it too + <youpi> no, it even needs to be replaced by its content + <pinotree> ah + <pinotree> it is possible to compose the _IOTS()? + <pinotree> (to build structs with more than 3 kind of fields) + <youpi> no + <pinotree> d'oh + <youpi> that's a hard shortcoming of the whole ioctl encoding + * pinotree scratches his head + <youpi> there's no way but redefining ioctl(), really + <youpi> it was a funny trick to encode it this way, but unrealistic + <pinotree> i see, yes + <youpi> not to mention ioctls which contain pointers, which just can not be passed to mig + <pinotree> indeed + <youpi> actually it's not mach's ioctl issue + <youpi> as mach doesn't know ioctl + <youpi> but the hurd ioctl interface + <pinotree> right + <youpi> which might end up in mach, other processes, other machines, etc. + * pinotree s/Mach/Hurd/ :) diff --git a/open_issues/glibc_libpthread_robust_mutexes.mdwn b/open_issues/glibc_libpthread_robust_mutexes.mdwn new file mode 100644 index 00000000..a92c984d --- /dev/null +++ b/open_issues/glibc_libpthread_robust_mutexes.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +libpthread: glibc 44e2ad5ab8c21dbfed3e384ba2ed31d7a8fc4744 +998e5fc14595229101561d76282036839e5b66ab -- The robust mutex functions are in +POSIX 2008. + +--- + +IRC, #hurd, unknown date. + + <youpi> neal: bad news: you remember the PTHREAD_RECURSIVE_MUTEX_INITIALIZER that points to a global __pthread_recursive_mutexattr? + <youpi> that doesn't work + <youpi> because some libraries like libstdc++ do not link against libpthread, while still using pthread_mutex_lock/unlock (counting on them being provided by either libc or libpthread-stubs) + <CIA-1> sthibaul-guest * r626 pkg-hurd/hurd/trunk/debian/ (changelog patches/series): + <CIA-1> * debian/patches/libpthread_rwlock_initializer.patch: Disable patch for now: + <CIA-1> our initializer does not work when the application does not link against + <CIA-1> libpthread. + + <CIA-1> sthibaul-guest * r629 pkg-hurd/hurd/trunk/debian/ (changelog patches/series): do not disable adding PTHREAD_RWLOCK_INITIALIZER, that's not the one that poses problems + <CIA-1> sthibaul-guest * r630 pkg-hurd/hurd/trunk/debian/ (3 files in 2 dirs): + <CIA-1> * debian/patches/libpthread_no_recursive_mutex_initializer.patch: New patch + <CIA-1> to drop undefined references to __pthread_recursive_mutexattr. + + <youpi> I'm thinking about how to fix the PTHREAD_RECURSIVE_MUTEX_INITIALIZER + <youpi> instead of a pointer to a static attribute variable, which posed problem + <youpi> could we perhaps consider that page 0 is never mapped + <youpi> and thus not only pointer 0 but also 1 2, etc. are invalid + <neal> I think that is a good solution + <youpi> and use them as special values + <neal> alternatively, we could assume that -PAGESIZE is never valid + <youpi> that makes us test it in all pthread_mutex_* functions, but it's not so bad + <neal> I'm not sure which is better + <youpi> why isn't it? + <neal> because the kernel is mapped there normally + <youpi> the kernel could be elsewhere + <neal> true + <youpi> in a 64bit adressing space for instance + <neal> I think your solution is a good one + <youpi> ok + + <CIA-1> sthibault * r633 pkg-hurd/hurd/trunk/debian/ (3 files in 2 dirs): + <CIA-1> * debian/patches/libpthread_recursive_mutex_initializer.patch: New patch + <CIA-1> to fix the recursive mutex initializers usage in libraries not linking + <CIA-1> against libpthread. diff --git a/open_issues/glibc_madvise_vs_static_linking.mdwn b/open_issues/glibc_madvise_vs_static_linking.mdwn new file mode 100644 index 00000000..ab633b0f --- /dev/null +++ b/open_issues/glibc_madvise_vs_static_linking.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +[[!sourceware_PR 4822]]. + + $ echo 'int main() {}' | gcc -o /dev/null -static -x c - + /usr/lib/gcc/i486-gnu/4.4.5/../../../libcrt.a(malloc.o): In function `_int_free': + (.text+0xdc3): warning: warning: madvise is not implemented and will always fail + +This is correct, but it does confuse GNU Autoconf, for example, which then +thinks that static linking is not supported and sets a flag accordingly, which +luckly no / not many packages use. + +*This call does not influence the semantics of the application (except in the +case of MADV_DONTNEED), but may influence its performance. The kernel is free +to ignore the advice.* (`man madvise`), so we may simply want to turn it into a +no-op in glibc, avoiding the link-time warning. + +GCC c5db973fdab3db3e13db575e5650c0bcfd3630f4 (2011-10-17) makes use of this. +As we now export the symbol (and `MADV_DONTNEED`, too), GCC will no longer +`munmap` pages, but will keep them mapped for later re-use. This may increase +memory usage. + +2011-07: This is what Samuel has [done for Debian +glibc](http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/local-madvise_warn.diff). + + +# IRC, freenode, #hurd, 2012-02-16 + + <tschwinge> youpi: With Roland's fix the situation will be that just using + gcc -static doesn't emit the stub warning, but still will do so in case + that the source code itself links in madvise. Is this acceptable for + you/Debian/...? + <youpi> packages with -Werror will still bug out + <youpi> not that I consider -Werror to be a good idea, though :) + <tschwinge> youpi: Indeed. Compiler warnings can be caused by all kinds of + things. -Werror is good for development, but not for releases. diff --git a/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn b/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn new file mode 100644 index 00000000..47f104c6 --- /dev/null +++ b/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <youpi> you can hardcode DTV_OFFSET as 4 for now + <youpi> it's the offset of the dtv field in the tcbhead_t structure from hurd/libpthread + <tschwinge> youpi: May very well be that I'm misunderstanding something, but wouldn't it rather be the offset of tcb in __pthread + the offset of dtv in tcbhead_t (which indeed is 4)? + <youpi> what you don't know is that DTV_OFFSET is not relative to __pthread, but to the tls segment + <tschwinge> Oh, aha. Thanks. + <youpi> and drepper abused the fact that in nptl __pthread appears at the start of the tls segment + +kFreeBSD, glibc: + + ++#if 0 + + DTV_OFFSET offsetof(struct pthread, header.dtv) + ++#else + ++DTV_OFFSET offsetof(struct _pthread_descr_struct, p_header.data.dtvp) + ++#endif diff --git a/open_issues/glusterfs.mdwn b/open_issues/glusterfs.mdwn new file mode 100644 index 00000000..68518938 --- /dev/null +++ b/open_issues/glusterfs.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, unknown channel, unknown date. + + <antrik> "GlusterFS is one of the most sophisticated file system in terms of features and extensibility. It + <antrik> borrows a powerful concept called Translators from GNU Hurd kernel." + <antrik> seems to be more similar to libstore than actual translators, though diff --git a/open_issues/gnumach_console_timestamp.mdwn b/open_issues/gnumach_console_timestamp.mdwn new file mode 100644 index 00000000..52b574d5 --- /dev/null +++ b/open_issues/gnumach_console_timestamp.mdwn @@ -0,0 +1,29 @@ +[[!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]] + +There is a [[!FF_project 267]][[!tag bounty]] on this task. + +IRC, freenode, #hurd, 2011-02-17 + + <azeem> task 39011c10 deallocating an invalid port 349, most probably a + bug. + <azeem> kernel: Page fault (14), code=6 + <azeem> Stopped at 0x28b9c7: orb %bh,0(%ecx,%edi,2) + <azeem> db> + [...] + <antrik> tschwinge: I doubt the deallocating warning is related to the + later fault + <tschwinge> antrik: YOu may be right. + <tschwinge> Perhaps it'd be a good idea to add some sort of timestamp to + Mach messages. + <tschwinge> Like in Linux' dmesg. + <tschwinge> Or just RDTSC (internal processor counter). diff --git a/open_issues/gnumach_constants.mdwn b/open_issues/gnumach_constants.mdwn new file mode 100644 index 00000000..16c8cf41 --- /dev/null +++ b/open_issues/gnumach_constants.mdwn @@ -0,0 +1,32 @@ +[[!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]] + +At compile-time, GNU Mach is parameterized with several constants. These might +need some tuning. Debian has some patches. + + +# IRC, freenode, #hurd, 2011-06-09 + + <braunr> youpi: in ipc/ipc_hash.c, there is code which computes the size of + the global (space, port)->entry hash table + <braunr> youpi: you may be interested in tuning this one too + <youpi> I know + <braunr> ok + <youpi> the current value is not so bad + <youpi> it's big enough for buildds to run fine + <braunr> 256 if i'm right + <braunr> well + <braunr> it won't fail + <youpi> we're limited by the 4000 object limitation anyway + <braunr> since it's a chained hash table + <braunr> but increasing it may help performances a bit + <braunr> and it certainly can't hurt much diff --git a/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn b/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn new file mode 100644 index 00000000..2df74301 --- /dev/null +++ b/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn @@ -0,0 +1,142 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date. + + <antrik> youpi: I have found an interesting Mach problem, but I'm a bit scared of debugging it... + <antrik> (it is related to VM stuff) + <antrik> I have a memory region that is mapped by the iopl device (it's an mmio region -- graphics memory to be precise) + <antrik> when gdb tries to read that region with vm_read() (for a "print" command), it triggers a general protection trap... + <youpi> antrik: does the general protection trap kill the whole kernel or just gdb? + <antrik> kernel + <antrik> kernel: General protection trap (13), code=0 + <antrik> pmap_copy_page(41000000,49f2000,1,0,1) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../i386/i386/phys.c:62 + <antrik> vm_object_copy_slowly(209c1c54,41000000,1000,1,20994908) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1150 + <antrik> vm_object_copy_strategically(209c1c54,41000000,1000,20994908,2099490c) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1669 + <antrik> vm_map_copyin(209ba6e4,2c000,1000,0,25394ec8) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_map.c:3297 + <antrik> vm_read(209ba6e4,2c000,1000,208d303c,25394f00) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_user.c:228 + <antrik> _Xvm_read(2095cfe4,208d3010,0,1fff3e48,2095cfd4) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/kern/mach.server.c:1164 + <antrik> ipc_kobject_server(2095cfd4,2095cfe4,28,127ca0,0) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../kern/ipc_kobject.c:201 + <antrik> mach_msg_trap(1024440,3,28,30,2c) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../ipc/mach_msg.c:1367 + <antrik> Bad frame pointer: 0x102441c + <antrik> BTW, is it useful at all to write down the paramenters as well?... + <antrik> argments I mean + <youpi> in the trace you mean? + <antrik> yes + <youpi> apparently the problem here is that the call to vm_fault_page() didn't perform its task + <youpi> which address is faulty? + <antrik> not sure what you mean + <youpi> ah shit the gpf wouldn't tell you + <youpi> does examine 49f2000 work? + <youpi> oh, wait, 4100000, that can't work + <youpi> +0 + <youpi> which physical address is your mmio at? + <antrik> haven't tried it... but I can provoke the fault again if it helps :-) + <youpi> we have the 1GB limitation issue + <antrik> oh... lemme check + <youpi> no need to, I think the problem is that + <youpi> the iopl driver should check that it's not above phys_last_addr + <antrik> it's only vm_read() that fails, though... + <antrik> the actual program I debugged in gdb works perfectly fine + <youpi> yes, but that's because it's accessing the memory in a different way + <youpi> in the case of direct reads it just uses the page table + <youpi> in the case of vm_read() it uses kernel's projection + <youpi> but in that case it's not in the kernel projection + <antrik> phys = 1090519040 + <youpi> that's it, it's beyond 1GB + <youpi> there's not much to do except changing mach's adressing organization + <antrik> yeah, that's the 0x41000000 + <antrik> hm... I guess we could make the vm_read() bail out instead of crashing?... + <youpi> yes + <youpi> but there are a lot of places like this + <antrik> still, it's not exactly fun when trying to debug a program and the kernel crashes :-) + <youpi> right :) + <antrik> I could try to add the check... if you tell me where it belongs ;-) + <youpi> antrik: it's not just one place, that's the problem + <youpi> it's all the places that call pmap_zero_page, pmap_copy_page, copy_to_phys or copy_from_phys + <youpi> and since we do want to let the iopl device create such kind of page, in principle we have to cope with them all + <youpi> pmap_zero_page should be ok, though + <youpi> the rest isn't + <antrik> is that tricky, or just a matter of doing it in all places? + + <antrik> hm... now it crashed in "normal" usage as well... + <antrik> hm... a page fault trap for a change... + <antrik> hm... now gdb tried to vm_read() something that is mapped to physical address 0x0... + <antrik> so I guess I fucked something up in the mapping code + <antrik> is it expected that such a vm_read() causes a kernel page fault, though?... + <antrik> youpi: ^ + <youpi> nope + <youpi> in principle the check for validity of the page is done earlier + <youpi> physical address 0x0 makes sense, though + <antrik> OK, here is the trace: + <antrik> Kernel page fault (14), code=0 at address 0x0 + <antrik> pmap_copy_page(0,6e54000,1,0,1) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../i386/i386/phys.c:62 + <antrik> vm_object_copy_slowly(20a067b0,0,1000,1,0acacec) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1150 + <antrik> vm_object_copy_strategically(20a067b0,0,1000,20acacec,20acacf0) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1669 + <antrik> vm_map_copyin(20a0f1c4,120d000,1000,0,253cdec8) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_map.c:3297 + <antrik> vm_read(20a0f1c4,120d000,1000,20a5703c,253cdf00) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_user.c:228 + <antrik> _Xvm_read(20a52c80,20a57010,253cdf40,20ae33cc,20a52c70) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/kern/mach.server.c:1164 + <antrik> ipc_kobject_server(20a52c70,20a52c80,28,20873074,20873070) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../kern/ipc_kobject.c:201 + <antrik> mach_msg_trap(10247d0,3,28,30,2f) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../ipc/mach_msg.c:1367 + <antrik> Bad frame pointer: 0x10247ac + <antrik> seems to be exactly the same, except for the different arguments... + <antrik> hm... interesting... it *does* write something to the framebuffer, before it crashes... + <antrik> (which unfortunately makes it a bit hard to read the panic message... ;-) ) + <LarstiQ> heh :) + <antrik> wait, it must write to something else than the frame buffer as well, or else the debugger should just paint over the crap... + <antrik> or perhaps it crashes so hard that the debugger doesn't even work? ;-) + <antrik> hm... I guess the first thing I should actually do is finding out what's up with e2fsck... this make testing crashes kinda annoying :-( + <antrik> oh, "interesting"... I ran it on one of my other hurd partitions, and it complained about an endless number of files... (perhaps all) + <antrik> however, the value for the normal files was different than for the passive translator nodes + <antrik> it doesn't happen only on crashes; it seems that all passive translators that are still in use at time of shutdown (or crash) have the offending bit set in the inode + <antrik> ouch... seems it doesn't write into the framebuffer after all, but rather scribbles all over the first 4 MiB of memory -- which includes also the VGA window, before it goes on killing the kernel... + <youpi> which iopl driver are you using ? + <antrik> ? + <youpi> the one from the debian patch? + <youpi> upstream, gnumach doesn't have an iopl device any more + <antrik> I guess so... standard Debian stuff here + <antrik> oh. how does X map the memory, then? + <youpi> X does yes + <antrik> ? + <youpi> X uses the iopl() device to access the video memory, yes + <youpi> I don't know if that was what you were asking for, but that's what I meant by my answer :) + <antrik> yeah, I know how it does *currently* do it -- I stole the code from there :-) + <antrik> my question is, how is X supposed to get at the framebuffer, when there is no iopl device anymore? + <youpi> ah, I hadn't noticed the "how" word + <youpi> in Debian there is + <LarstiQ> !debian → !x? + <youpi> the clean "access device memory" interface is yet to be done + <antrik> err... that sounds like Xorg philosophy + <youpi> what, to wait for a nice interface ? + <antrik> "let's kill the old stuff, fuck regressions... maybe someone will figure out how to do it with the new stuff at some point. if not, not our problem" + <youpi> that's also a GNU philosophy + <youpi> ah, that one + <antrik> anyone know how device_map() is supposed to behave? the documentation isn't really clear... + <antrik> my understanding was then when an offset is specified, then the resulting object will be relative to that object; i.e. the offset of a later vm_map() on this object is applied on top of the object's internal offset... + <antrik> but that doesn't seem to be how it works for the iopl device, if I read the xf86 code correctly... + <antrik> yeah, the offset parameter seems a nop when doing device_map() on the iopl device diff --git a/open_issues/gnumach_i686.mdwn b/open_issues/gnumach_i686.mdwn new file mode 100644 index 00000000..b34df73b --- /dev/null +++ b/open_issues/gnumach_i686.mdwn @@ -0,0 +1,26 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-07-05 + + <braunr> we could use a gnumach-i686 too + <pinotree> how would you compile gnumach as i686 variant btw? add + -march=.. or something like that in CFLAGS? + <braunr> yes + <braunr> at least we'll get some cmovs :) + + +## IRC, freenode, #hurd, 2012-07-07 + + <braunr> it was rejected in the past because we didn't think it would bring + real performance benefit, but it actually may diff --git a/open_issues/gnumach_integer_overflow.mdwn b/open_issues/gnumach_integer_overflow.mdwn new file mode 100644 index 00000000..2166e591 --- /dev/null +++ b/open_issues/gnumach_integer_overflow.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-07-04 + + <braunr> yes, we have integer overflows on resident_page_count, but + luckily, the member is rarely used diff --git a/open_issues/gnumach_kernel_threads.mdwn b/open_issues/gnumach_kernel_threads.mdwn new file mode 100644 index 00000000..9591986b --- /dev/null +++ b/open_issues/gnumach_kernel_threads.mdwn @@ -0,0 +1,23 @@ +[[!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-07-13 + + <braunr> jkoenig: why does gnumach appear as "root=device:hd0s1" in ps ? + <jkoenig> braunr, it's the closest we can do to its command line + <braunr> doesn't it deserve something special like kernel threads in linux + ? + <braunr> so that it's actually clear that it's a special task/process + <jkoenig> you mean something like [mach root=device:hd0s1] ? + <braunr> something like that yes + <braunr> also, it would be nice if gnumach threads could actually be seen, + i don't remember if the mach interface allows it though diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn new file mode 100644 index 00000000..9feb30c8 --- /dev/null +++ b/open_issues/gnumach_memory_management.mdwn @@ -0,0 +1,2135 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +There is a [[!FF_project 266]][[!tag bounty]] on this task. + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-04-12 + + <antrik> braunr: do you think the allocator you wrote for x15 could be used + for gnumach? and would you be willing to mentor this? :-) + <braunr> antrik: to be willing to isn't my current problem + <braunr> antrik: and yes, I think my allocator can be used + <braunr> it's a slab allocator after all, it only requires reap() and + grow() + <braunr> or mmap()/munmap() whatever you want to call it + <braunr> a backend + <braunr> antrik: although i've been having other ideas recently + <braunr> that would have more impact on our usage patterns I think + <antrik> mcsim: have you investigated how the zone allocator works and how + it's hooked into the system yet? + <braunr> mcsim: now let me give you a link + <braunr> mcsim: + http://git.sceen.net/rbraun/libbraunr.git/?a=blob;f=mem.c;h=330436e799f322949bfd9e2fedf0475660309946;hb=HEAD + <braunr> mcsim: this is an implementation of the slab allocator i've been + working on recently + <braunr> mcsim: i haven't made it public because i reworked the per + processor layer, and this part isn't complete yet + <braunr> mcsim: you could use it as a reference for your project + <mcsim> braunr: ok + <braunr> it used to be close to the 2001 vmem paper + <braunr> but after many tests, fragmentation and accounting issues have + been found + <braunr> so i rewrote it to be closer to the linux implementation (cache + filling/draining in bukl transfers) + <braunr> bulk* + <braunr> they actually use the word draining in linux too :) + <mcsim> antrik: not complete yet. + <antrik> braunr: oh, it's unfinished? that's unfortunate... + <braunr> antrik: only the per processor part + <braunr> antrik: so it doesn't matter much for gnumach + <braunr> and it's not difficult to set up + <antrik> mcsim: hm, OK... but do you think you will have a fairly good + understanding in the next couple of days?... + <antrik> I'm asking because I'd really like to see a proposal a bit more + specific than "I'll look into things..." + <antrik> i.e. you should have an idea which things you will actually have + to change to hook up a new allocator etc. + <antrik> braunr: OK. will the interface remain unchanged, so it could be + easily replaced with an improved implementation later? + <braunr> the zone allocator in gnumach is a badly written bare object + allocator actually, there aren't many things to understand about it + <braunr> antrik: yes + <antrik> great :-) + <braunr> and the per processor part should be very close to the phys + allocator sitting next to it + <braunr> (with the slight difference that, as per cpu caches have variable + sizes, they are allocated on the free path rather than on the allocation + path) + <braunr> this is a nice trick in the vmem paper i've kept in mind + <braunr> and the interface also allows to set a "source" for caches + <antrik> ah, good point... do you think we should replace the physmem + allocator too? and if so, do it in one step, or one piece at a time?... + <braunr> no + <braunr> too many drivers currently depend on the physical allocator and + the pmap module as they are + <braunr> remember linux 2.0 drivers need a direct virtual to physical + mapping + <braunr> (especially true for dma mappings) + <antrik> OK + <braunr> the nice thing about having a configurable memory source is that + <antrik> whot do you mean by "allocated on the free path"? + <braunr> even if most caches will use the standard vm_kmem module as their + backend + <braunr> there is one exception in the vm_map module, allowing us to get + rid of either a static limit, or specific allocation code + <braunr> antrik: well, when you allocate a page, the allocator will lookup + one in a per cpu cache + <braunr> if it's empty, it fills the cache + <braunr> (called pools in my implementations) + <braunr> it then retries + <braunr> the problem in the slab allocator is that per cpu caches have + variable sizes + <braunr> so per cpu pools are allocated from their own pools + <braunr> (remember the magazine_xx caches in the output i showed you, this + is the same thing) + <braunr> but if you allocate them at allocation time, you could end up in + an infinite loop + <braunr> so, in the slab allocator, when a per cpu cache is empty, you just + fall back to the slab layer + <braunr> on the free path, when a per cpu cache doesn't exist, you allocate + it from its own cache + <braunr> this way you can't have an infinite loop + <mcsim> antrik: I'll try, but I have exams now. + <mcsim> As I understand amount of elements which could be allocated we + determine by zone initialization. And at this time memory for zone is + reserved. I'm going to change this. And make something similar to kmalloc + and vmalloc (support for pages consecutive physically and virtually). And + pages in zones consecutive always physically. + <mcsim> Am I right? + <braunr> mcsim: don't try to do that + <mcsim> why? + <braunr> mcsim: we just need a slab allocator with an interface close to + the zone allocator + <antrik> mcsim: IIRC the size of the complete zalloc map is fixed; but not + the number of elements per zone + <braunr> we don't need two allocators like kmalloc and vmalloc + <braunr> actually we just need vmalloc + <braunr> IIRC the limits are only present because the original developers + wanted to track leaks + <braunr> they assumed zones would be large enough, which isn't true any + more today + <braunr> but i didn't see any true reservation + <braunr> antrik: i'm not sure i was clear enough about the "allocation of + cpu caches on the free path" + <braunr> antrik: for a better explanation, read the vmem paper ;) + <antrik> braunr: you mean there is no fundamental reason why the zone map + has a limited maximal size; and it was only put in to catch cases where + something eats up all memory with kernel object creation?... + <antrik> braunr: I think I got it now :-) + <braunr> antrik: i'm pretty certin of it yes + <antrik> I don't see though how it is related to what we were talking + about... + <braunr> 10:55 < braunr> and the per processor part should be very close to + the phys allocator sitting next to it + <braunr> the phys allocator doesn't have to use this trick + <braunr> because pages have a fixed size, so per cpu caches all have the + same size too + <braunr> and the number of "caches", that is, physical segments, is limited + and known at compile time + <braunr> so having them statically allocated is possible + <antrik> I see + <braunr> it would actually be very difficult to have a phys allocator + requiring dynamic allocation when the dynamic allocator isn't yet ready + <antrik> hehe :-) + <mcsim> total size of all zone allocations is limited to 12 MB. And is "was + only put in to catch cases where something eats up all memory with kernel + object creation?" + <braunr> mcsim: ah right, there could be a kernel submap backing all the + zones + <braunr> but this can be increased too + <braunr> submaps are kind of evil :/ + <antrik> mcsim: I think it's actually 32 MiB or something like that in the + Debian version... + <antrik> braunr: I'm not sure I ever fully understood what the zalloc map + is... I looked through the code once, and I think I got a rough + understading, but I was still pretty uncertain about some bits. and I + don't remember the details anyways :-) + <braunr> antrik: IIRC, it's a kernel submap + <braunr> it's named kmem_map in x15 + <antrik> don't know what a submap is + <braunr> submaps are vm_map objects + <braunr> in a top vm_map, there are vm_map_entries + <braunr> these entries usually point to vm_objects + <braunr> (for the page cache) + <braunr> but they can point to other maps too + <braunr> the goal is to reduce fragmentation by isolating allocations + <braunr> this also helps reducing contention + <braunr> for exemple, on BSD, there is a submap for mbufs, so that the + network code doesn't interfere too much with other kernel allocations + <braunr> antrik: they are similar to spans in vmem, but vmem has an elegant + importing mechanism which eliminates the static limit problem + <antrik> so memory is not directly allocated from the physical allocator, + but instead from another map which in turn contains physical memory, or + something like that?... + <braunr> no, this is entirely virtual + <braunr> submaps are almost exclusively used for the kernel_map + <antrik> you are using a lot of identifies here, but I don't remember (or + never knew) what most of them mean :-( + <braunr> sorry :) + <braunr> the kernel map is the vm_map used to represent the ~1 GiB of + virtual memory the kernel has (on i386) + <braunr> vm_map objects are simple virtual space maps + <braunr> they contain what you see in linux when doing /proc/self/maps + <braunr> cat /proc/self/maps + <braunr> (linux uses entirely different names but it's roughly the same + structure) + <braunr> each line is a vm_map_entry + <braunr> (well, there aren't submaps in linux though) + <braunr> the pmap tool on netbsd is able to show the kernel map with its + submaps, but i don't have any image around + <mcsim> braunr: is limit for zones is feature and shouldn't be changed? + <braunr> mcsim: i think we shouldn't have fixed limits for zones + <braunr> mcsim: this should be part of the debugging facilities in the slab + allocator + <braunr> is this fixed limit really a major problem ? + <braunr> i mean, don't focus on that too much, there are other issues + requiring more attention + <antrik> braunr: at 12 MiB, it used to be, causing a lot of zalloc + panics. after increasing, I don't think it's much of a problem anymore... + <antrik> but as memory sizes grow, it might become one again + <antrik> that's the problem with a fixed size... + <braunr> yes, that's the issue with submaps + <braunr> but gnumach is full of those, so let's fix them by order of + priority + <antrik> well, I'm still trying to digest what you wrote about submaps :-) + <braunr> i'm downloading netbsd, so you can have a good view of all this + <antrik> so, when the kernel allocates virtual address space regions + (mostly for itself), instead of grabbing chunks of the address space + directly, it takes parts out of a pre-reserved region? + <braunr> not exactly + <braunr> both statements are true + <mcsim> antrik: only virtual addresses are reserved + <braunr> it grabs chunks of the address space directly, but does so in a + reserved region of the address space + <braunr> a submap is like a normal map, it has a start address, a size, and + is empty, then it's populated with vm_map_entries + <braunr> so instead of allocating from 3-4 GiB, you allocate from, say, + 3.1-3.2 GiB + <antrik> yeah, that's more or less what I meant... + <mcsim> braunr: I see two problems: limited zones and absence of caching. + <mcsim> with caching absence of readahead paging will be not so significant + <braunr> please avoid readahead + <mcsim> ok + <braunr> and it's not about paging, it's about kernel memory, which is + wired + <braunr> (well most of it) + <braunr> what about limited zones ? + <braunr> the whole kernel space is limited, there has to be limits + <braunr> the problem is how to handle them + <antrik> braunr: almost all. I looked through all zones once, and IIRC I + found exactly one that actually allows paging... + <braunr> currently, when you reach the limit, you have an OOM error + <braunr> antrik: yes, there are + <braunr> i don't remember which implementation does that but, when + processes haven't been active for a minute or so, they are "swapedout" + <braunr> completely + <braunr> even the kernel stack + <braunr> and the page tables + <braunr> (most of the pmap structures are destroyed, some are retained) + <antrik> that might very well be true... at least inactive processes often + show up with 0 memory use in top on Hurd + <braunr> this is done by having a pageable kernel map, with wired entries + <braunr> when the swapper thread swaps tasks out, it unwires them + <braunr> but i think modern implementations don't do that any more + <antrik> well, I was talking about zalloc only :-) + <braunr> oh + <braunr> so the zalloc_map must be pageable + <braunr> or there are two submaps ? + <antrik> not sure whether "morden implementations" includes Linux ;-) + <braunr> no, i'm talking about the bsd family only + <antrik> but it's certainly true that on Linux even inactive processes + retain some memory + <braunr> linux doesn't make any difference between processor-bound and + I/O-bound processes + <antrik> braunr: I have no idea how it works. I just remember that when + creating zones, one of the optional flags decides whether the zone is + pagable. but as I said, IIRC there is exactly one that actually is... + <braunr> zone_map = kmem_suballoc(kernel_map, &zone_min, &zone_max, + zone_map_size, FALSE); + <braunr> kmem_suballoc(parent, min, max, size, pageable) + <braunr> so the zone_map isn't + <antrik> IIRC my conclusion was that pagable zones do not count in the + fixed zone map limit... but I'm not sure anymore + <braunr> zinit() has a memtype parameter + <braunr> with ZONE_PAGEABLE as a possible flag + <braunr> this is wierd :) + <mcsim> There is no any zones which use ZONE_PAGEABLE flag + <antrik> mcsim: are you sure? I think I found one... + <braunr> if (zone->type & ZONE_PAGEABLE) { + <antrik> admittedly, it is several years ago that I looked into this, so my + memory is rather dim... + <braunr> if (kmem_alloc_pageable(zone_map, &addr, ... + <braunr> calling kmem_alloc_pageable() on an unpageable submap seems wrong + <mcsim> I've greped gnumach code and there is no any zinit procedure call + with ZONE_PAGEABLE flag + <braunr> good + <antrik> hm... perhaps it was in some code that has been removed + alltogether since ;-) + <antrik> actually I think it would be pretty neat to have pageable kernel + objects... but I guess it would require considerable effort to implement + this right + <braunr> mcsim: you also mentioned absence of caching + <braunr> mcsim: the zone allocator actually is a bare caching object + allocator + <braunr> antrik: no, it's easy + <braunr> antrik: i already had that in x15 0.1 + <braunr> antrik: the problem is being sure the objects you allocate from a + pageable backing store are never used when resolving a page fault + <braunr> that's all + <antrik> I wouldn't expect that to be easy... but surely you know better + :-) + <mcsim> braunr: indeed. I was wrong. + <antrik> braunr: what is a caching object allocator?... + <braunr> antrik: ok, it's not easy + <braunr> antrik: but once you have vm_objects implemented, having pageable + kernel object is just a matter of using the right options, really + <braunr> antrik: an allocator that caches its buffers + <braunr> some years ago, the term "object" would also apply to + preconstructed buffers + <antrik> I have no idea what you mean by "caches its buffers" here :-) + <braunr> well, a memory allocator which doesn't immediately free its + buffers caches them + <mcsim> braunr: but can it return objects to system? + <braunr> mcsim: which one ? + <antrik> yeah, obviously the *implementation* of pageable kernel objects is + not hard. the tricky part is deciding which objects can be pageable, and + which need to be wired... + <mcsim> Can zone allocator return cached objects to system as in slab? + <mcsim> I mean reap() + <braunr> well yes, it does so, and it does that too often + <braunr> the caching in the zone allocator is actually limited to the + pagesize + <braunr> once page is completely free, it is returned to the vm + <mcsim> this is bad caching + <braunr> yes + <mcsim> if object takes all page than there is now caching at all + <braunr> caching by side effect + <braunr> true + <braunr> but the linux slab allocator does the same thing :p + <braunr> hm + <braunr> no, the solaris slab allocator does so + <mcsim> linux's slab returns objects only when system ask + <antrik> without preconstructed objects, is there actually any point in + caching empty slabs?... + <mcsim> Once I've changed my allocator to slab and it cached more than 1GB + of my memory) + <braunr> ok wait, need to fix a few mistakes first + <mcsim> s/ask/asks + <braunr> the zone allocator (in gnumach) actually has a garbage collector + <antrik> braunr: well, the Solaris allocator follows the slab/magazine + paper, right? so there is caching at the magazine layer... in that case + caching empty slabs too would be rather redundant I'd say... + <braunr> which is called when running low on memory, similar to the slab + allocaotr + <braunr> antrik: yes + <antrik> (or rather the paper follows the Solaris allocator ;-) ) + <braunr> mcsim: the zone allocator reap() is zone_gc() + <antrik> braunr: hm, right, there is a "collectable" flag for zones... but + I never understood what it means + <antrik> braunr: BTW, I heard Linux has yet another allocator now called + "slob"... do you happen to know what that is? + <braunr> slob is a very simple allocator for embedded devices + <mcsim> AFAIR this is just heap allocator + <braunr> useful when you have a very low amount of memory + <braunr> like 1 MiB + <braunr> yes + <antrik> just googled it :-) + <braunr> zone and slab are very similar + <antrik> sounds like a simple heap allocator + <mcsim> there is another allocator that calls slub, and it better than slab + in many cases + <braunr> the main difference is the data structures used to store slabs + <braunr> mcsim: i disagree + <antrik> mcsim: ah, you already said that :-) + <braunr> mcsim: slub is better for systems with very large amounts of + memory and processors + <braunr> otherwise, slab is better + <braunr> in addition, there are accounting issues with slub + <braunr> because of cache merging + <mcsim> ok. This strange that slub is default allocator + <braunr> well both are very good + <braunr> iirc, linus stated that he really doesn't care as long as its + works fine + <braunr> he refused slqb because of that + <braunr> slub is nice because it requires less memory than slab, while + still being as fast for most cases + <braunr> it gets slower on the free path, when the cpu performing the free + is different from the one which allocated the object + <braunr> that's a reasonable cost + <mcsim> slub uses heap for large object. Are there any tests that compare + what is better for large objects? + <antrik> well, if slub requires less memory, why do you think slab is + better for smaller systems? :-) + <braunr> antrik: smaller is relative + <antrik> mcsim: for large objects slab allocation is rather pointless, as + you don't have multiple objects in a page anyways... + <braunr> antrik: when lameter wrote slub, it was intended for systems with + several hundreds processors + <antrik> BTW, was slqb really refused only because the other ones are "good + enough"?... + <braunr> yes + <antrik> wow, that's a strange argument... + <braunr> linus is already unhappy of having "so many" allocators + <antrik> well, if the new one is better, it could replace one of the others + :-) + <antrik> or is it useful only in certain cases? + <braunr> that's the problem + <braunr> nobody really knows + <antrik> hm, OK... I guess that should be tested *before* merging ;-) + <antrik> is anyone still working on it, or was it abandonned? + <antrik> mcsim: back to caching... + <antrik> what does caching in the kernel object allocator got to do with + readahead (i.e. clustered paging)?... + <mcsim> if we cached some physical pages we don't need to find new ones for + allocating new object. And that's why there will not be a page fault. + <mcsim> antrik: Regarding kam. Hasn't he finished his project? + <antrik> err... what? + <antrik> one of us must be seriously confused + <antrik> I totally fail to see what caching of physical pages (which isn't + even really a correct description of what slab does) has to do with page + faults + <antrik> right, KAM didn't finish his project + <mcsim> If we free the physical page and return it to system we need + another one for next allocation. But if we keep it, we don't need to find + new physical page. + <mcsim> And physical page is allocated only then when page fault + occurs. Probably, I'm wrong + <antrik> what does "return to system" mean? we are talking about the + kernel... + <antrik> zalloc/slab are about allocating kernel objects. this doesn't have + *anything* to do with paging of userspace processes + <antrik> only thing the have in common is that they need to get pages from + the physical page allocator. but that's yet another topic + <mcsim> Under "return to system" I mean ability to use this page for other + needs. + <braunr> mcsim: consider kernel memory to be wired + <braunr> here, return to system means releasing a page back to the vm + system + <braunr> the vm_kmem module then unmaps the physical page and free its + virtual address in the kernel map + <mcsim> ok + <braunr> antrik: the problem with new allocators like slqb is that it's + very difficult to really know if they're better, even with extensive + testing + <braunr> antrik: there are papers (like wilson95) about the difficulties in + making valuable results in this field + <braunr> see + http://www.sceen.net/~rbraun/dynamic_storage_allocation_a_survey_and_critical_review.pdf + <mcsim> how can be allocated physically continuous object now? + <braunr> mcsim: rephrase please + <mcsim> what is similar to kmalloc in Linux to gnumach? + <braunr> i know memory is reserved for dma in a direct virtual to physical + mapping + <braunr> so even if the allocation is done similarly to vmalloc() + <braunr> the selected region of virtual space maps physical memory, so + memory is physically contiguous too + <braunr> for other allocation types, a block large enough is allocated, so + it's contiguous too + <mcsim> I don't clearly understand. If we have fragmentation in physical + ram, so there aren't 2 free pages in a row, but there are able apart, we + can't to allocate these 2 pages along? + <braunr> no + <braunr> but every system has this problem + <mcsim> But since we have only 12 or 32 MB of memory the problem becomes + more significant + <braunr> you're confusing virtual and physical memory + <braunr> those 32 MiB are virtual + <braunr> the physical pages backing them don't have to be contiguous + <mcsim> Oh, indeed + <mcsim> So the only problem are limits? + <braunr> and performance + <braunr> and correctness + <braunr> i find the zone allocator badly written + <braunr> antrik: mcsim: here is the content of the kernel pmap on NetBSD + (which uses a virtual memory system close to the Mach VM) + <braunr> antrik: mcsim: http://www.sceen.net/~rbraun/pmap.out + +[[pmap.out]] + + <braunr> you can see the kmem_map (which is used for most general kernel + allocations) is 128 MiB large + <braunr> actually it's not the kernel pmap, it's the kernel_map + <antrik> braunr: why is it called pmap.out then? ;-) + <braunr> antrik: because the tool is named pmap + <braunr> for process map + <braunr> it also exists under Linux, although direct access to + /proc/xx/maps gives more info + <mcsim> braunr: I've said that this is kernel_map. Can I see kernel_map for + Linux? + <braunr> mcsim: I don't know how to do that + <mcsim> s/I've/You've + <braunr> but Linux doesn't have submaps, and uses a direct virtual to + physical mapping, so it's used differently + <antrik> how are things (such as zalloc zones) entered into kernel_map? + <braunr> in zone_init() you have + <braunr> zone_map = kmem_suballoc(kernel_map, &zone_min, &zone_max, + zone_map_size, FALSE); + <braunr> so here, kmem_map is named zone_map + <braunr> then, in zalloc() + <braunr> kmem_alloc_wired(zone_map, &addr, zone->alloc_size) + <antrik> so, kmem_alloc just deals out chunks of memory referenced directly + by the address, and without knowing anything about the use? + <braunr> kmem_alloc() gives virtual pages + <braunr> zalloc() carves them into buffers, as in the slab allocator + <braunr> the difference is essentially the lack of formal "slab" object + <braunr> which makes the zone code look like a mess + <antrik> so kmem_suballoc() essentially just takes a bunch of pages from + the main kernel_map, and uses these to back another map which then in + turn deals out pages just like the main kernel_map? + <braunr> no + <braunr> kmem_suballoc creates a vm_map_entry object, and sets its start + and end address + <braunr> and creates a vm_map object, which is then inserted in the new + entry + <braunr> maybe that's what you meant with "essentially just takes a bunch + of pages from the main kernel_map" + <braunr> but there really is no allocation at this point + <braunr> except the map entry and the new map objects + <antrik> well, I'm trying to understand how kmem_alloc() manages things. so + it has map_entry structures like the maps of userspace processes? do + these also reference actual memory objects? + <braunr> kmem_alloc just allocates virtual pages from a vm_map, and backs + those with physical pages (unless the user requested pageable memory) + <braunr> it's not "like the maps of userspace processes" + <braunr> these are actually the same structures + <braunr> a vm_map_entry can reference a memory object or a kernel submap + <braunr> in netbsd, it can also referernce nothing (for pure wired kernel + memory like the vm_page array) + <braunr> maybe it's the same in mach, i don't remember exactly + <braunr> antrik: this is actually very clear in vm/vm_kern.c + <braunr> kmem_alloc() creates a new kernel object for the allocation + <braunr> allocates a new entry (or uses a previous existing one if it can + be extended) through vm_map_find_entry() + <braunr> then calls kmem_alloc_pages() to back it with wired memory + <antrik> "creates a new kernel object" -- what kind of kernel object? + <braunr> kmem_alloc_wired() does roughly the same thing, except it doesn't + need a new kernel object because it knows the new area won't be pageable + <braunr> a simple vm_object + <braunr> used as a container for anonymous memory in case the pages are + swapped out + <antrik> vm_object is the same as memory object/pager? or yet something + different? + <braunr> antrik: almost + <braunr> antrik: a memory_object is the user view of a vm_object + <braunr> as in the kernel/user interfaces used by external pagers + <braunr> vm_object is a more internal name + <mcsim> Is fragmentation a big problem in slab allocator? + <mcsim> I've tested it on my computer in Linux and for some caches it + reached 30-40% + <antrik> well, fragmentation is a major problem for any allocator... + <antrik> the original slab allocator was design specifically with the goal + of reducing fragmentation + <antrik> the revised version with the addition of magazines takes a step + back on this though + <antrik> have you compared it to slub? would be pretty interesting... + <mcsim> I have an idea how can it be decreased, but it will hurt by + performance... + <mcsim> antrik: no I haven't, but there will be might the same, I think + <mcsim> if each cache will handle two types of object: with sizes that will + fit cache sizes (or I bit smaller) and with sizes which are much smaller + than maximal cache size. For first type of object will be used standard + slab allocator and for latter type will be used (within page) heap + allocator. + <mcsim> I think that than fragmentation will be decreased + <antrik> not at all. heap allocator has much worse fragmentation. that's + why slab allocator was invented + <antrik> the problem is that in a long-running program (such an the + kernel), objects tend to have vastly varying lifespans + <mcsim> but we use heap only for objects of specified sizes + <antrik> so often a few old objects will keep a whole page hostage + <mcsim> for example for 32 byte cache it could be 20-28 byte objects + <antrik> that's particularily visible in programs such as firefox, which + will grow the heap during use even though actual needs don't change + <antrik> the slab allocator groups objects in a fashion that makes it more + likely adjacent objects will be freed at similar times + <antrik> well, that's pretty oversimplyfied, but I hope you get the + idea... it's about locality + <mcsim> I agree, but I speak not about general heap allocation. We have + many heaps for objects with different sizes. + <mcsim> Could it be better? + <antrik> note that this has been a topic of considerable research. you + shouldn't seek to improve the actual algorithms -- you would have to read + up on the existing research at least before you can contribute anything + to the field :-) + <antrik> how would that be different from the slab allocator? + <mcsim> slab will allocate 32 byte for both 20 and 32 byte requests + <mcsim> And if there was request for 20 bytes we get 12 unused + <antrik> oh, you mean the implementation of the generic allocator on top of + slabs? well, that might not be optimal... but it's not an often used case + anyways. mostly the kernel uses constant-sized objects, which get their + own caches with custom tailored size + <antrik> I don't think the waste here matters at all + <mcsim> affirmative. So my idea is useless. + <antrik> does the statistic you refer to show the fragmentation in absolute + sizes too? + <mcsim> Can you explain what is absolute size? + <mcsim> I've counted what were requested (as parameter of kmalloc) and what + was really allocated (according to best fit cache size). + <antrik> how did you get that information? + <mcsim> I simply wrote a hook + <antrik> I mean total. i.e. how many KiB or MiB are wasted due to + fragmentation alltogether + <antrik> ah, interesting. how does it work? + <antrik> BTW, did you read the slab papers? + <mcsim> Do you mean articles from lwn.net? + <antrik> no + <antrik> I mean the papers from the Sun hackers who invented the slab + allocator(s) + <antrik> Bonwick mostly IIRC + <mcsim> Yes + <antrik> hm... then you really should know the rationale behind it... + <mcsim> There he says about 11% percent of memory waste + <antrik> you didn't answer my other questions BTW :-) + <mcsim> I've corrupted kernel tree with patch, and tomorrow I'm going to + read myself up for exam (I have it on Thursday). But than I'll send you a + module which I've used for testing. + <antrik> OK + <mcsim> I can send you module now, but it will not work without patch. + <mcsim> It would be better to rewrite it using debugfs, but when I was + writing this test I didn't know about trace_* macros + + +# IRC, freenode, #hurd, 2011-04-15 + + <mcsim> There is a hack in zone_gc when it allocates and frees two + vm_map_kentry_zone elements to make sure the gc will be able to allocate + two in vm_map_delete. Isn't it better to allocate memory for these + entries statically? + <youpi> mcsim: that's not the point of the hack + <youpi> mcsim: the point of the hack is to make sure vm_map_delete will be + able to allocate stuff + <youpi> allocating them statically will just work once + <youpi> it may happen several times that vm_map_delete needs to allocate it + while it's empty (and thus zget_space has to get called, leading to a + hang) + <youpi> funnily enough, the bug is also in macos X + <youpi> it's still in my TODO list to manage to find how to submit the + issue to them + <braunr> really ? + <braunr> eh + <braunr> is that because of map entry splitting ? + <youpi> it's git commit efc3d9c47cd744c316a8521c9a29fa274b507d26 + <youpi> braunr: iirc something like this, yes + <braunr> netbsd has this issue too + <youpi> possibly + <braunr> i think it's a fundamental problem with the design + <braunr> people think of munmap() as something similar to free() + <braunr> whereas it's really unmap + <braunr> with a BSD-like VM, unmap can easily end up splitting one entry in + two + <braunr> but your issue is more about harmful recursion right ? + <youpi> I don't remember actually + <youpi> it's quite some time ago :) + <braunr> ok + <braunr> i think that's why i have "sources" in my slab allocator, the + default source (vm_kern) and a custom one for kernel map entries + + +# IRC, freenode, #hurd, 2011-04-18 + + <mcsim> braunr: you've said that once page is completely free, it is + returned to the vm. + <mcsim> who else, besides zone_gc, can return free pages to the vm? + <braunr> mcsim: i also said i was wrong about that + <braunr> zone_gc is the only one + + +# IRC, freenode, #hurd, 2011-04-19 + + <braunr> antrik: mcsim: i added back a new per-cpu layer as planned + <braunr> + http://git.sceen.net/rbraun/libbraunr.git/?a=blob;f=mem.c;h=c629b2b9b149f118a30f0129bd8b7526b0302c22;hb=HEAD + <braunr> mcsim: btw, in mem_cache_reap(), you can clearly see there are two + loops, just as in zone_gc, to reduce contention and avoid deadlocks + <braunr> this is really common in memory allocators + + +# IRC, freenode, #hurd, 2011-04-23 + + <mcsim> I've looked through some allocators and all of them use different + per cpu cache policy. AFAIK gnuhurd doesn't support multiprocessing, but + still multiprocessing must be kept in mind. So, what do you think what + kind of cpu caches is better? As for me I like variant with only per-cpu + caches (like in slqb). + <antrik> mcsim: well, have you looked at the allocator braunr wrote + himself? :-) + <antrik> I'm not sure I suggested that explicitly to you; but probably it + makes most sense to use that in gnumach + + +# IRC, freenode, #hurd, 2011-04-24 + + <mcsim> antrik: Yes, I have. He uses both global and per cpu caches. But he + also suggested to look through slqb, where there are only per cpu + caches.\ + <braunr> i don't remember slqb in detail + <braunr> what do you mean by "only per-cpu caches" ? + <braunr> a whole slab sytem for each cpu ? + <mcsim> I mean that there are no global queues in caches, but there are + special queues for each cpu. + <mcsim> I've just started investigating slqb's code, but I've read an + article on lwn about it. And I've read that it is used for zen kernel. + <braunr> zen ? + <mcsim> Here is this article http://lwn.net/Articles/311502/ + <mcsim> Yes, this is linux kernel with some patches which haven't been + approved to torvald's tree + <mcsim> http://zen-kernel.org/ + <braunr> i see + <braunr> well it looks nice + <braunr> but as for slub, the problem i can see is cross-CPU freeing + <braunr> and I think nick piggins mentions it + <braunr> piggin* + <braunr> this means that sometimes, objects are "burst-free" from one cpu + cache to another + <braunr> which has the same bad effects as in most other allocators, mainly + fragmentation + <mcsim> There is a special list for freeing object allocated for another + CPU + <mcsim> And garbage collector frees such object on his own + <braunr> so what's your question ? + <mcsim> It is described in the end of article. + <mcsim> What cpu-cache policy do you think is better to implement? + <braunr> at this point, any + <braunr> and even if we had a kernel that perfectly supports + multiprocessor, I wouldn't care much now + <braunr> it's very hard to evaluate such allocators + <braunr> slqb looks nice, but if you have the same amount of fragmentation + per slab as other allocators do (which is likely), you have tat amount of + fragmentation multiplied by the number of processors + <braunr> whereas having shared queues limit the problem somehow + <braunr> having shared queues mean you have a bit more contention + <braunr> so, as is the case most of the time, it's a tradeoff + <braunr> by the way, does pigging say why he "doesn't like" slub ? :) + <braunr> piggin* + <mcsim> http://lwn.net/Articles/311093/ + <mcsim> here he describes what slqb is better. + <braunr> well it doesn't describe why slub is worse + <mcsim> but not very particularly + <braunr> except for order-0 allocations + <braunr> and that's a form of fragmentation like i mentioned above + <braunr> in mach those problems have very different impacts + <braunr> the backend memory isn't physical, it's the kernel virtual space + <braunr> so the kernel allocator can request chunks of higher than order-0 + pages + <braunr> physical pages are allocated one at a time, then mapped in the + kernel space + <mcsim> Doesn't order of page depend on buffer size? + <braunr> it does + <mcsim> And why does gnumach allocates higher than order-0 pages more? + <braunr> why more ? + <braunr> i didn't say more + <mcsim> And why in mach those problems have very different impact? + <braunr> ? + <braunr> i've just explained why :) + <braunr> 09:37 < braunr> physical pages are allocated one at a time, then + mapped in the kernel space + <braunr> "one at a time" means order-0 pages, even if you allocate higher + than order-0 chunks + <mcsim> And in Linux they allocated more than one at time because of + prefetching page reading? + <braunr> do you understand what virtual memory is ? + <braunr> linux allocators allocate "physical memory" + <braunr> mach kernel allocator allocates "virtual memory" + <braunr> so even if you allocate a big chunk of virtual memory, it's backed + by order-0 physical pages + <mcsim> yes, I understand this + <braunr> you don't seem to :/ + <braunr> the problem of higher than order-0 page allocations is + fragmentation + <braunr> do you see why ? + <mcsim> yes + <braunr> so + <braunr> fragmentation in the kernel space is less likely to create issues + than it does in physical memory + <braunr> keep in mind physical memory is almost always full because of the + page cache + <braunr> and constantly under some pressure + <braunr> whereas the kernel space is mostly empty + <braunr> so allocating higher then order-0 pages in linux is more dangerous + than it is in Mach or BSD + <mcsim> ok + <braunr> on the other hand, linux focuses pure performance, and not having + to map memory means less operations, less tlb misses, quicker allocations + <braunr> the Mach VM must map pages "one at a time", which can be expensive + <braunr> it should be adapted to handle multiple page sizes (e.g. 2 MiB) so + that many allocations can be made with few mappings + <braunr> but that's not easy + <braunr> as always: tradeoffs + <mcsim> There are other benefits of physical allocating. In big DMA + transfers can be needed few continuous physical pages. How does mach + handles such cases? + <braunr> gnumach does that awfully + <braunr> it just reserves the whole DMA-able memory and uses special + allocation functions on it, IIRC + <braunr> but kernels which have a MAch VM like memory sytem such as BSDs + have cleaner methods + <braunr> NetBSD provides a function to allocate contiguous physical memory + <braunr> with many constraints + <braunr> FreeBSD uses a binary buddy system like Linux + <braunr> the fact that the kernel allocator uses virtual memory doesn't + mean the kernel has no mean to allocate contiguous physical memory ... + + +# IRC, freenode, #hurd, 2011-05-02 + + <braunr> hm nice, my allocator uses less memory than glibc (squeeze + version) on both 32 and 64 bits systems + <braunr> the new per-cpu layer is proving effective + <neal> braunr: Are you reimplementation malloc? + <braunr> no + <braunr> it's still the slab allocator for mach, but tested in userspace + <braunr> so i wrote malloc wrappers + <neal> Oh. + <braunr> i try to heavily test most of my code in userspace now + <neal> it's easier :-) + <neal> I agree + <braunr> even the physical memory allocator has been implemented this way + <neal> is this your mach version? + <braunr> virtual memory allocation will follow + <neal> or are you working on gnu mach? + <braunr> for now it's my version + <braunr> but i intend to spend the summer working on ipc port names + management + +[[rework_gnumach_IPC_spaces]]. + + <braunr> and integrate the result in gnu mach + <neal> are you keeping the same user-space API? + <neal> Or are you experimenting with something new? + <antrik> braunr: to be fair, it's not terribly hard to use less memory than + glibc :-) + <braunr> yes + <braunr> antrik: well ptmalloc3 received some nice improvements + <braunr> neal: the goal is to rework some of the internals only + <braunr> neal: namely, i simply intend to replace the splay tree with a + radix tree + <antrik> braunr: the glibc allocator is emphasising performace, unlike some + other allocators that trade some performance for much better memory + utilisation... + <antrik> ptmalloc3? + <braunr> that's the allocator used in glibc + <braunr> http://www.malloc.de/en/ + <antrik> OK. haven't seen any recent numbers... the comparision I have in + mind is many years old... + <braunr> i also made some additions to my avl and red-black trees this week + end, which finally make them suitable for almost all generic uses + <braunr> the red-black tree could be used in e.g. gnu mach to augment the + linked list used in vm maps + <braunr> which is what's done in most modern systems + <braunr> it could also be used to drop the overloaded (and probably over + imbalanced) page cache hash table + + +# IRC, freenode, #hurd, 2011-05-03 + + <mcsim> antrik: How should I start porting? Have I just include rbraun's + allocator to gnumach and make it compile? + <antrik> mcsim: well, basically yes I guess... but you will have to look at + the code in question first before we know anything more specific :-) + <antrik> I guess braunr might know better how to start, but he doesn't + appear to be here :-( + <braunr> mcsim: you can't juste put my code into gnu mach and make it run, + it really requires a few careful changes + <braunr> mcsim: you will have to analyse how the current zone allocator + interacts with regard to locking + <braunr> if it is used in interrupt handlers + <braunr> what kind of locks it should use instead of the pthread stuff + available in userspace + <braunr> you will have to change the reclamiing policy, so that caches are + reaped on demand + <braunr> (this basically boils down to calling the new reclaiming function + instead of zone_gc()) + <braunr> you must be careful about types too + <braunr> there is work to be done ;) + <braunr> (not to mention the obvious about replacing all the calls to the + zone allocator, and testing/debugging afterwards) + + +# IRC, freenode, #hurd, 2011-07-14 + + <braunr> can you make your patch available ? + <mcsim> it is available in gnumach repository at savannah + <mcsim> tree mplaneta/libbraunr/master + <braunr> mcsim: i'll test your branch + <mcsim> ok. I'll give you a link in a minute + <braunr> hm why balloc ? + <mcsim> Braun's allocator + <braunr> err + <braunr> + http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=kern/kmem.c;h=37173fa0b48fc9d7e177bf93de531819210159ab;hb=HEAD + <braunr> mcsim: this is the interface i had in mind for a kernel version :) + <braunr> very similar to the original slab allocator interface actually + <braunr> well, you've been working + <mcsim> But I have a problem with this patch. When I apply it to gnumach + code from debian repository. I have to make a change in file ramdisk.c + with sed -i 's/kernel_map/\&kernel_map/' device/ramdisk.c + <mcsim> because in git repository there is no such file + <braunr> mcsim: how do you configure the kernel before building ? + <braunr> mcsim: you should keep in touch more often i think, so that you + get feedback from us and don't spend too much time "off course" + <mcsim> I didn't configure it. I just run dpkg-buildsource -b. + <braunr> oh you build the debian package + <braunr> well my version was by configure --enable-kdb --enable-rtl8139 + <braunr> and it seems stuck in an infinite loop during bootstrap + <mcsim> and printf doesn't work. The first function called by c_boot_entry + is printf(version). + <braunr> mcsim: also, you're invited to get the x15mach version of my + files, which are gplv2+ licensed + <braunr> be careful of my macros.h file, it can conflict with the + macros_help.h file from gnumach iirc + <mcsim> There were conflicts with MACRO_BEGIN and MACRO_END. But I solved + it + <braunr> ok + <braunr> it's tricky + <braunr> mcsim: try to find where the first use of the allocator is made + + +# IRC, freenode, #hurd, 2011-07-22 + + <mcsim> braunr, hello. Kernel with your allocator already compiles and + runs. There still some problems, but, certainly, I'm on the final stage + already. I hope I'll finish in a few days. + <tschwinge> mcsim: Oh, cool! Have you done some measurements already? + <mcsim> Not yet + <tschwinge> OK. + <tschwinge> But if it able to run a GNU/Hurd system, then that already is + something, a big milestone! + <braunr> nice + <braunr> although you'll probably need to tweak the garbage collecting + process + <mcsim> tschwinge: thanks + <mcsim> braunr: As back-end for allocating memory I use + kmem_alloc_wired. But in zalloc was an opportunity to use as back-end + kmem_alloc_pageable. Although there was no any zone that used + kmem_alloc_pageable. Do I need to implement this functionality? + <braunr> mcsim: do *not* use kmem_alloc_pageable() + <mcsim> braunr: Ok. This is even better) + <braunr> mcsim: in x15, i've taken this even further: there is *no* kernel + vm object, which means all kernel memory is wired and unmanaged + <braunr> making it fast and safe + <braunr> pageable kernel memory was useful back when RAM was really scarce + <braunr> 20 years ago + <braunr> but it's a source of deadlock + <mcsim> Indeed. I'll won't use kmem_alloc_pageable. + + +# IRC, freenode, #hurd, 2011-08-09 + + < braunr> mcsim: what's the "bug related to MEM_CF_VERIFY" you refer to in + one of your commits ? + < braunr> mcsim: don't use spin_lock_t as a member of another structure + < mcsim> braunr: I confused with types in *_verify functions, so they + didn't work. Than I fixed it in the commit you mentioned. + < braunr> in gnumach, most types are actually structure pointers + < braunr> use simple_lock_data_t + < braunr> mcsim: ok + < mcsim> > use simple_lock_data_t + < mcsim> braunr: ok + < braunr> mcsim: don't make too many changes to the code base, and if + you're unsure, don't hesitate to ask + < braunr> also, i really insist you rename the allocator, as done in x15 + for example + (http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=vm/kmem.c), instead of + a name based on mine :/ + < mcsim> braunr: Ok. It was just work name. When I finish I'll rename the + allocator. + < braunr> other than that, it's nice to see progress + < braunr> although again, it would be better with some reports along + < braunr> i won't be present at the meeting tomorrow unfortunately, but you + should use those to report the status of your work + < mcsim> braunr: You've said that I have to tweak gc process. Did you mean + to call mem_gc() when physical memory ends instead of calling it every x + seconds? Or something else? + < braunr> there are multiple topics, alhtough only one that really matters + < braunr> study how zone_gc was called + < braunr> reclaiming memory should happen when there is pressure on the VM + subsystem + < braunr> but it shouldn't happen too ofte, otherwise there is trashing + < braunr> and your caches become mostly useless + < braunr> the original slab allocator uses a 15-second period after a + reclaim during which reclaiming has no effect + < braunr> this allows having a somehow stable working set for this duration + < braunr> the linux slab allocator uses 5 seconds, but has a more + complicated reclaiming mechanism + < braunr> it releases memory gradually, and from reclaimable caches only + (dentry for example) + < braunr> for x15 i intend to implement the original 15 second interval and + then perform full reclaims + < mcsim> In zalloc mem_gc is called by vm_pageout_scan, but not often than + once a second. + < mcsim> In balloc I've changed interval to once in 15 seconds. + < braunr> don't use the code as it is + < braunr> the version you've based your work on was meant for userspace + < braunr> where there isn't memory pressure + < braunr> so a timer is used to trigger reclaims at regular intervals + < braunr> it's different in a kernel + < braunr> mcsim: where did you see vm_pageout_scan call the zone gc once a + second ? + < mcsim> vm_pageout_scan calls consider_zone_gc and consider_zone_gc checks + if second is passed. + < braunr> where ? + < mcsim> Than zone_gc can be called. + < braunr> ah ok, it's in zaclloc.c then + < braunr> zalloc.c + < braunr> yes this function is fine + < mcsim> so old gc didn't consider vm pressure. Or I missed something. + < braunr> it did + < mcsim> how? + < braunr> well, it's called by the pageout daemon + < braunr> under memory pressure + < braunr> so it's fine + < mcsim> so if mem_gc is called by pageout daemon is it fine? + < braunr> it must be changed to do something similar to what + consider_zone_gc does + < mcsim> It does. mem_gc does the same work as consider_zone_gc and + zone_gc. + < braunr> good + < mcsim> so gc process is fine? + < braunr> should be + < braunr> i see mem.c only includes mem.h, which then includes other + headers + < braunr> don't do that + < braunr> always include all the headers you need where you need them + < braunr> if you need avltree.h in both mem.c and mem.h, include it in both + files + < braunr> and by the way, i recommend you use the red black tree instead of + the avl type + < braunr> (it's the same interface so it shouldn't take long) + < mcsim> As to report. If you won't be present at the meeting, I can tell + you what I have to do now. + < braunr> sure + < braunr> in addition, use GPLv2 as the license, teh BSD one is meant for + the userspace version only + < braunr> GPLv2+ actually + < braunr> hm you don't need list.c + < braunr> it would only add dead code + < braunr> "Zone for dynamical allocator", don't mix terms + < braunr> this comment refers to a vm_map, so call it a map + < mcsim> 1. Change constructor for kentry_alloc_cache. + < mcsim> 2. Make measurements. + < mcsim> + + < mcsim> 3. Use simple_lock_data_t + < mcsim> 4. Replace license + < braunr> kentry_alloc_cache <= what is that ? + < braunr> cache for kernel map entries in vm_map ? + < braunr> the comment for mem_cpu_pool_get doesn't apply in gnumach, as + there is no kernel preemption + < braunr> "Don't attempt mem GC more frequently than hz/MEM_GC_INTERVAL + times a second. + < braunr> " + < mcsim> sorry. I meant vm_map_kentry_cache + < braunr> hm nothing actually about this comment + < braunr> mcsim: ok + < braunr> yes kernel map entries need special handling + < braunr> i don't know how it's done in gnumach though + < braunr> static preallocation ? + < mcsim> yes + < braunr> that's ugly :p + < mcsim> but it uses dynamic allocation further even for vm_map kernel + entries + < braunr> although such bootstrapping issues are generally difficult to + solve elegantly + < braunr> ah + < mcsim> now I use only static allocation, but I'll add dynamic allocation + too + < braunr> when you have time, mind the coding style (convert everything to + gnumach style, which mostly implies using tabs instead of 4-spaces + indentation) + < braunr> when you'll work on dynamic allocation for the kernel map + entries, you may want to review how it's done in x15 + < braunr> the mem_source type was originally intended for that purpose, but + has slightly changed once the allocator was adapted to work in my kernel + < mcsim> ok + < braunr> vm_map_kentry_zone is the only zone created with ZONE_FIXED + < braunr> and it is zcram()'ed immediately after + < braunr> so you can consider it a statically allocated zone + < braunr> in x15 i use another strategy: there is a special kernel submap + named kentry_map which contains only one map entry (statically allocated) + < braunr> this map is the backend (mem_source) for the kentry_cache + < braunr> the kentry_cache is created with a special flag that tells it + memory can't be reclaimed + < braunr> when the cache needs to grow, the single map entry is extended to + cover the allocated memory + < braunr> it's similar to the way pmap_growkernel() works for kernel page + table pages + < braunr> (and is actually based on that idea) + < braunr> it's a compromise between full static and dynamic allocation + types + < braunr> the advantage is that the allocator code can be used (so there is + no need for a special allocator like in netbsd) + < braunr> the drawback is that some resources can never be returned to + their source (and under peaks, the amount of unfreeable resources could + become large, but this is unexpected) + < braunr> mcsim: for now you shouldn't waste your time with this + < braunr> i see the number of kernel map entries is fixed at 256 + < braunr> and i've never seen the kernel use more than around 30 entries + < mcsim> Do you think that I have to left this problem to the end? + < braunr> yes + + +# IRC, freenode, #hurd, 2011-08-11 + + < mcsim> braunr: Hello. Can you give me an advice how can I make + measurements better? + < braunr> mcsim: what kind of measurements + < mcsim> braunr: How much is your allocator better than zalloc. + < braunr> slightly :p + < braunr> that's why i never took the time to put it in gnumach + < mcsim> braunr: Just I thought that there are some rules or + recommendations of such measurements. Or I can do them any way I want? + < braunr> mcsim: i don't know + < braunr> mcsim: benchmarking is an art of its own, and i don't even know + how to use the bits of profiling code available in gnumach (if it still + works) + < antrik> mcsim: hm... are you saying you already have a running system + with slab allocator?... :-) + < braunr> mcsim: the main advantage i can see is the removal of many + arbitrary hard limits + < mcsim> antrik: yes + < antrik> \o/ + < antrik> nice work! + < braunr> :) + < braunr> the cpu layer should also help a bit, but it's hard to measure + < braunr> i guess it could be seen on the ipc path for very small buffers + < mcsim> antrik: Thanks. But I still have to 1. Change constructor for + kentry_alloc_cache. and 2. Make measurements. + < braunr> and polish the whole thing :p + < antrik> mcsim: I'm not sure this can be measured... the performance + differente in any real live usage is probably just a few percent at most + -- it's hard to construct a benchmark giving enough precision so it's not + drowned in noise... + < antrik> perhaps it conserves some memory -- but that too would be hard to + measure I fear + < braunr> yes + < braunr> there *should* be better allocation times, less fragmentation, + better accounting ... :) + < braunr> and no arbitrary limits ! + < antrik> :-) + < braunr> oh, and the self debugging features can be nice too + < mcsim> But I need to prove that my work wasn't useless + < braunr> well it wasn't, but that's hard to measure + < braunr> it's easy to prove though, since there are additional features + that weren't present in the zone allocator + < mcsim> Ok. If there are some profiling features in gnumach can you give + me a link with their description? + < braunr> mcsim: sorry, no + < braunr> mcsim: you could still write the basic loop test, which counts + the number of allocations performed in a fixed time interval + < braunr> but as it doesn't match many real life patterns, it won't be very + useful + < braunr> and i'm afraid that if you consider real life patterns, you'll + see how negligeable the improvement can be compared to other operations + such as memory copies or I/O (ouch) + < mcsim> Do network drivers use this allocator? + < mcsim> ok. I'll scrape up some test and than I'll report results. + + +# IRC, freenode, #hurd, 2011-08-26 + + < mcsim> hello. Are there any analogs of copy_to_user and copy_from_user in + linux for gnumach? + < mcsim> Or how can I determine memory map if I know address? I need this + for vm_map_copyin + < guillem> mcsim: vm_map_lookup_entry? + < mcsim> guillem: but I need to transmit map to this function and it will + return an entry which contains specified address. + < mcsim> And I don't know what map have I transmit. + < mcsim> I need to transfer static array from kernel to user. What map + contains static data? + < antrik> mcsim: Mach doesn't have copy_{from,to}_user -- instead, large + chunks of data are transferred as out-of-line data in IPC messages + (i.e. using VM magic) + < mcsim> antrik: can you give me an example? I just found using + vm_map_copyin in host_zone_info. + < antrik> no idea what vm_map_copyin is to be honest... + + +# IRC, freenode, #hurd, 2011-08-27 + + < braunr> mcsim: the primitives are named copyin/copyout, and they are used + for messages with inline data + < braunr> or copyinmsg/copyoutmsg + < braunr> vm_map_copyin/out should be used for chunks larger than a page + (or roughly a page) + < braunr> also, when writing to a task space, see which is better suited: + vm_map_copyout or vm_map_copy_overwrite + < mcsim> braunr: and what will be src_map for vm_map_copyin/out? + < braunr> the caller map + < braunr> which you can get with current_map() iirc + < mcsim> braunr: thank you + < braunr> be careful not to leak anything in the transferred buffers + < braunr> memset() to 0 if in doubt + < mcsim> braunr:ok + < braunr> antrik: vm_map_copyin() is roughly vm_read() + < antrik> braunr: what is it used for? + < braunr> antrik: 01:11 < antrik> mcsim: Mach doesn't have + copy_{from,to}_user -- instead, large chunks of data are transferred as + out-of-line data in IPC messages (i.e. using VM magic) + < braunr> antrik: that "VM magic" is partly implemented using vm_map_copy* + functions + < antrik> braunr: oh, you mean it doesn't actually copy data, but only page + table entries? if so, that's *not* really comparable to + copy_{from,to}_user()... + + +# IRC, freenode, #hurd, 2011-08-28 + + < braunr> antrik: the equivalent of copy_{from,to}_user are + copy{in,out}{,msg} + < braunr> antrik: but when the data size is about a page or more, it's + better not to copy, of course + < antrik> braunr: it's actually not clear at all that it's really better to + do VM magic than to copy... + + +# IRC, freenode, #hurd, 2011-08-29 + + < braunr> antrik: at least, that used to be the general idea, and with a + simpler VM i suspect it's still true + < braunr> mcsim: did you progress on your host_zone_info replacement ? + < braunr> mcsim: i think you should stick to what the original + implementation did + < braunr> which is making an inline copy if caller provided enough space, + using kmem_alloc_pageable otherwise + < braunr> specify ipc_kernel_map if using kmem_alloc_pageable + < mcsim> braunr: yes. And it works. But I use kmem_alloc, not pageable. Is + it worse? + < mcsim> braunr: host_zone_info replacement is pushed to savannah + repository. + < braunr> mcsim: i'll have a look + < mcsim> braunr: I've pushed one more commit just now, which has attitude + to host_zone_info. + < braunr> mem_alloc_early_init should be renamed mem_bootstrap + < mcsim> ok + < braunr> mcsim: i don't understand your call to kmem_free + < mcsim> braunr: It shouldn't be there? + < braunr> why should it be there ? + < braunr> you're freeing what the copy object references + < braunr> it's strange that it even works + < braunr> also, you shouldn't pass infop directly as the copy object + < braunr> i guess you get a warning for that + < braunr> do what the original code does: use an intermediate copy object + and a cast + < mcsim> ok + < braunr> another error (without consequence but still, you should mind it) + < braunr> simple_lock(&mem_cache_list_lock); + < braunr> [...] + < braunr> kr = kmem_alloc(ipc_kernel_map, &info, info_size); + < braunr> you can't hold simple locks while allocating memory + < braunr> read how the original implementation works around this + < mcsim> ok + < braunr> i guess host_zone_info assumes the zone list doesn't change much + while unlocked + < braunr> or that's it's rather unimportant since it's for debugging + < braunr> a strict snapshot isn't required + < braunr> list_for_each_entry(&mem_cache_list, cache, node) max_caches++; + < braunr> you should really use two separate lines for readability + < braunr> also, instead of counting each time, you could just maintain a + global counter + < braunr> mcsim: use strncpy instead of strcpy for the cache names + < braunr> not to avoid overflow but rather to clear the unused bytes at the + end of the buffer + < braunr> mcsim: about kmem_alloc vs kmem_alloc_pageable, it's a minor + issue + < braunr> you're handing off debugging data to a userspace application + < braunr> a rather dull reporting tool in most cases, which doesn't require + wired down memory + < braunr> so in order to better use available memory, pageable memory + should be used + < braunr> in the future i guess it could become a not-so-minor issue though + < mcsim> ok. I'll fix it + < braunr> mcsim: have you tried to run the kernel with MC_VERIFY always on + ? + < braunr> MEM_CF_VERIFY actually + < mcsim1> yes. + < braunr> oh + < braunr> nothing wrong + < braunr> ? + < mcsim1> it is always set + < braunr> ok + < braunr> ah, you set it in macros.h .. + < braunr> don't + < braunr> put it in mem.c if you want, or better, make it a compile-time + option + < braunr> macros.h is a tiny macro library, it shouldn't define such + unrelated options + < mcsim1> ok. + < braunr> mcsim1: did you try fault injection to make sure the checking + code actually works and how it behaves when an error occurs ? + < mcsim1> I think that when I finish I'll merge files cpu.h and macros.h + with mem.c + < braunr> yes that would simplify things + < mcsim1> Yes. When I confused with types mem_buf_fill worked wrong and + panic occurred. + < braunr> very good + < braunr> have you progressed concerning the measurements you wanted to do + ? + < mcsim1> not much. + < braunr> ok + < mcsim1> I think they will be ready in a few days. + < antrik> what measurements are these? + < mcsim1> braunr: What maximal size for static data and stack in kernel? + < braunr> what do you mean ? + < braunr> kernel stacks are one page if i'm right + < braunr> static data (rodata+data+bss) are limited by grub bugs only :) + < mcsim1> braunr: probably they are present, because when I created too big + array I couldn't boot kernel + < braunr> local variable or static ? + < mcsim1> static + < braunr> how large ? + < mcsim1> 4Mb + < braunr> hm + < braunr> it's not a grub bug then + < braunr> i was able to embed as much as 32 MiB in x15 while doing this + kind of tests + < braunr> I guess it's the gnu mach boot code which only preallocates one + page for the initial kernel mapping + < braunr> one PTP (page table page) maps 4 MiB + < braunr> (x15 does this completely dynamically, unlike mach or even + current BSDs) + < mcsim1> antrik: First I want to measure time of each cache + creation/allocation/deallocation and then compile kernel. + < braunr> cache creation is irrelevant + < braunr> because of the cpu pools in the new allocator, you should test at + least two different allocation patterns + < braunr> one with quick allocs/frees + < braunr> the other with large numbers of allocs then their matching frees + < braunr> (larger being at least 100) + < braunr> i'd say the cpu pool layer is the real advantage over the + previous zone allocator + < braunr> (from a performance perspective) + < mcsim1> But there is only one cpu + < braunr> it doesn't matter + < braunr> it's stil a very effective cache + < braunr> in addition to reducing contention + < braunr> compare mem_cpu_pool_pop() against mem_cache_alloc_from_slab() + < braunr> mcsim1: work is needed to polish the whole thing, but getting it + actually working is a nice achievement for someone new on the project + < braunr> i hope it helped you learn about memory allocation, virtual + memory, gnu mach and the hurd in general :) + < antrik> indeed :-) + + +# IRC, freenode, #hurd, 2011-09-06 + + [some performance testing] + <braunr> i'm not sure such long tests are relevant but let's assume balloc + is slower + <braunr> some tuning is needed here + <braunr> first, we can see that slab allocation occurs more often in balloc + than page allocation does in zalloc + <braunr> so yes, as slab allocation is slower (have you measured which part + actually is slow ? i guess it's the kmem_alloc call) + <braunr> the whole process gets a bit slower too + <mcsim> I used alloc_size = 4096 for zalloc + <braunr> i don't know what that is exactly + <braunr> but you can't hold 500 16 bytes buffers in a page so zalloc must + have had free pages around for that + <mcsim> I use kmem_alloc_wired + <braunr> if you have time, measure it, so that we know how much it accounts + for + <braunr> where are the results for dealloc ? + <mcsim> I can't give you result right now because internet works very + bad. But for first DEALLOC result are the same, exept some cases when it + takes balloc for more than 1000 ticks + <braunr> must be the transfer from the cpu layer to the slab layer + <mcsim> as to kmem_alloc_wired. I think zalloc uses this function too for + allocating objects in zone I test. + <braunr> mcsim: yes, but less frequently, which is why it's faster + <braunr> mcsim: another very important aspect that should be measured is + memory consumption, have you looked into that ? + <mcsim> I think that I made too little iterations in test SMALL + <mcsim> If I increase constant SMALL_TESTS will it be good enough? + <braunr> mcsim: i don't know, try both :) + <braunr> if you increase the number of iterations, balloc average time will + be lower than zalloc, but this doesn't remove the first long + initialization step on the allocated slab + <mcsim> SMALL_TESTS to 500, I mean + <braunr> i wonder if maintaining the slabs sorted through insertion sort is + what makes it slow + <mcsim> braunr: where do you sort slabs? I don't see this. + <braunr> mcsim: mem_cache_alloc_from_slab and its free counterpart + <braunr> mcsim: the mem_source stuff is useless in gnumach, you can remove + it and directly call the kmem_alloc/free functions + <mcsim> But I have to make special allocator for kernel map entries. + <braunr> ah right + <mcsim> btw. It turned out that 256 entries are not enough. + <braunr> that's weird + <braunr> i'll make a patch so that the mem_source code looks more like what + i have in x15 then + <braunr> about the results, i don't think the slab layer is that slow + <braunr> it's the cpu_pool_fill/drain functions that take time + <braunr> they preallocate many objects (64 for your objects size if i'm + right) at once + <braunr> mcsim: look at the first result page: some times, a number around + 8000 is printed + <braunr> the common time (ticks, whatever) for a single object is 120 + <braunr> 8132/120 is 67, close enough to the 64 value + <mcsim> I forgot about SMALL tests here are they: + http://paste.debian.net/128533/ (balloc) http://paste.debian.net/128534/ + (zalloc) + <mcsim> braunr: why do you divide 8132 by 120? + <braunr> mcsim: to see if it matches my assumption that the ~8000 number + matches the cpu_pool_fill call + <mcsim> braunr: I've got it + <braunr> mcsim: i'd be much interested in the dealloc results if you can + paste them too + <mcsim> dealloc: http://paste.debian.net/128589/ + http://paste.debian.net/128590/ + <braunr> mcsim: thanks + <mcsim> second dealloc: http://paste.debian.net/128591/ + http://paste.debian.net/128592/ + <braunr> mcsim: so the main conclusion i retain from your tests is that the + transfers from the cpu and the slab layers are what makes the new + allocator a bit slower + <mcsim> OPERATION_SMALL dealloc: http://paste.debian.net/128593/ + http://paste.debian.net/128594/ + <braunr> mcsim: what needs to be measured now is global memory usage + <mcsim> braunr: data from /proc/vmstat after kernel compilation will be + enough? + <braunr> mcsim: let me check + <braunr> mcsim: no it won't do, you need to measure kernel memory usage + <braunr> the best moment to measure it is right after zone_gc is called + <mcsim> Are there any facilities in gnumach for memory measurement? + <braunr> it's specific to the allocators + <braunr> just count the number of used pages + <braunr> after garbage collection, there should be no free page, so this + should be rather simple + <mcsim> ok + <mcsim> braunr: When I measure memory usage in balloc, what formula is + better cache->nr_slabs * cache->bufs_per_slab * cache->buf_size or + cache->nr_slabs * cache->slab_size? + <braunr> the latter + + +# IRC, freenode, #hurd, 2011-09-07 + + <mcsim> braunr: I've disabled calling of mem_cpu_pool_fill and allocator + became faster + <braunr> mcsim: sounds nice + <braunr> mcsim: i suspect the free path might not be as fast though + <mcsim> results for first calling: http://paste.debian.net/128639/ second: + http://paste.debian.net/128640/ and with many alloc/free: + http://paste.debian.net/128641/ + <braunr> mcsim: thanks + <mcsim> best result are for second call: average time decreased from 159.56 + to 118.756 + <mcsim> First call slightly worse, but this is because I've added some + profiling code + <braunr> i still see some ~8k lines in 128639 + <braunr> even some around ~12k + <mcsim> I think this is because of mem_cache_grow I'm investigating it now + <braunr> i guess so too + <mcsim> I've measured time for first call in cache and from about 22000 + mem_cache_grow takes 20000 + <braunr> how did you change the code so that it doesn't call + mem_cpu_pool_fill ? + <braunr> is the cpu layer still used ? + <mcsim> http://paste.debian.net/128644/ + <braunr> don't forget the free path + <braunr> mcsim: anyway, even with the previous slightly slower behaviour we + could observe, the performance hit is negligible + <mcsim> Is free path a compilation? (I'm sorry for my english) + <braunr> mcsim: mem_cache_free + <braunr> mcsim: the last two measurements i'd advise are with big (>4k) + object sizes and, really, kernel allocator consumption + <mcsim> http://paste.debian.net/128648/ http://paste.debian.net/128646/ + http://paste.debian.net/128649/ (first, second, small) + <braunr> mcsim: these numbers are closer to the zalloc ones, aren't they ? + <mcsim> deallocating slighty faster too + <braunr> it may not be the case with larger objects, because of the use of + a tree + <mcsim> yes, they are closer + <braunr> but then, i expect some space gains + <braunr> the whole thing is about compromise + <mcsim> ok. I'll try to measure them today. Anyway I'll post result and you + could read them in the morning + <braunr> at least, it shows that the zone allocator was actually quite good + <braunr> i don't like how the code looks, there are various hacks here and + there, it lacks self inspection features, but it's quite good + <braunr> and there was little room for true improvement in this area, like + i told you :) + <braunr> (my allocator, like the current x15 dev branch, focuses on mp + machines) + <braunr> mcsim: thanks again for these numbers + <braunr> i wouldn't have had the courage to make the tests myself before + some time eh + <mcsim> braunr: hello. Look at the small_4096 results + http://paste.debian.net/128692/ (balloc) http://paste.debian.net/128693/ + (zalloc) + <braunr> mcsim: wow, what's that ? :) + <braunr> mcsim: you should really really include your test parameters in + the report + <braunr> like object size, purpose, and other similar details + <mcsim> for balloc I specified only object_size = 4096 + <mcsim> for zalloc object_size = 4096, alloc_size = 4096, memtype = 0; + <braunr> the results are weird + <braunr> apart from the very strange numbers (e.g. 0 or 4429543648), none + is around 3k, which is the value matching a kmem_alloc call + <braunr> happy to see balloc behaves quite good for this size too + <braunr> s/good/well/ + <mcsim> Oh + <mcsim> here is significant only first 101 lines + <mcsim> I'm sorry + <braunr> ok + <braunr> what does the test do again ? 10 loops of 10 allocs/frees ? + <mcsim> yes + <braunr> ok, so the only slowdown is at the beginning, when the slabs are + created + <braunr> the two big numbers (31844 and 19548) are strange + <mcsim> on the other hand time of compilation is + <mcsim> balloc zalloc + <mcsim> 38m28.290s 38m58.400s + <mcsim> 38m38.240s 38m42.140s + <mcsim> 38m30.410s 38m52.920s + <braunr> what are you compiling ? + <mcsim> gnumach kernel + <braunr> in 40 mins ? + <mcsim> yes + <braunr> you lack hvm i guess + <mcsim> is it long? + <mcsim> I use real PC + <braunr> very + <braunr> ok + <braunr> so it's normal + <mcsim> in vm it was about 2 hours) + <braunr> the difference really is negligible + <braunr> ok i can explain the big numbers + <braunr> the slab size depends on the object size, and for 4k, it is 32k + <braunr> you can store 8 4k buffers in a slab (lines 2 to 9) + <mcsim> so we need use kmem_alloc_* 8 times? + <braunr> on line 10, the ninth object is allocated, which adds another slab + to the cache, hence the big number + <braunr> no, once for a size of 32k + <braunr> and then the free list is initialized, which means accessing those + pages, which means tlb misses + <braunr> i guess the zone allocator already has free pages available + <mcsim> I see + <braunr> i think you can stop performance measurements, they show the + allocator is slightly slower, but so slightly we don't care about that + <braunr> we need numbers on memory usage now (at the page level) + <braunr> and this isn't easy + <mcsim> For balloc I can get numbers if I summarize nr_slabs*slab_size for + each cache, isn't it? + <braunr> yes + <braunr> you can have a look at the original implementation, function + mem_info + <mcsim> And for zalloc I have to summarize of cur_size and then add + zalloc_wasted_space? + <braunr> i don't know :/ + <braunr> i think the best moment to obtain accurate values is after zone_gc + removes the collected pages + <braunr> for both allocators, you could fill a stats structure at that + moment, and have an rpc copy that structure when a client tool requests + it + <braunr> concerning your tests, there is another point to have in mind + <braunr> the very first loop in your code shows a result of 31844 + <braunr> although you disabled the call to cpu_pool_fill + <braunr> but the reason why it's so long is that the cpu layer still exists + <braunr> and if you look carefully, the cpu pools are created as needed on + the free path + <mcsim> I removed cpu_pool_drain + <braunr> but not cpu_pool_push/pop i guess + <mcsim> http://paste.debian.net/128698/ + <braunr> see, you still allocate the cpu pool array on the free path + <mcsim> but I don't fill it + <braunr> that's not the point + <braunr> it uses mem_cache_alloc + <braunr> so in a call to free, you can also have an allocation, that can + potentially create a new slab + <mcsim> I see, so I have to create cpu_pool at the initialization stage? + <braunr> no, you can't + <braunr> there is a reason why they're allocated on the free path + <braunr> but since you don't have the fill/drain functions, i wonder if you + should just comment out the whole cpu layer code + <braunr> but hmm + <braunr> no really, it's not worth the effort + <braunr> even with drains/fills, the results are really good enough + <braunr> it makes the allocator smp ready + <braunr> we should just keep it that way + <braunr> mcsim: fyi, the reason why cpu pool arrays are allocated on the + free path is to avoid recursion + <braunr> because cpu pool arrays are allocated from caches just as almost + everything else + <mcsim> ok + <mcsim> summ of cur_size and then adding zalloc_wasted_space gives 0x4e1954 + <mcsim> but this value isn't even page aligned + <mcsim> For balloc I've got 0x4c6000 0x4aa000 0x48d000 + <braunr> hm can you report them in decimal, >> 10 so that values are in KiB + ? + <mcsim> 4888 4776 4660 for balloc + <mcsim> 4998 for zalloc + <braunr> when ? + <braunr> after boot ? + <mcsim> boot, compile, zone_gc + <mcsim> and then measure + <braunr> ? + <mcsim> I call garbage collector before measuring + <mcsim> and I measure after kernel compilation + <braunr> i thought it took you 40 minutes + <mcsim> for balloc I got results at night + <braunr> oh so you already got them + <braunr> i can't beleive the kernel only consumes 5 MiB + <mcsim> before gc it takes about 9052 Kib + <braunr> can i see the measurement code ? + <braunr> oh, and how much ram does your machine have ? + <mcsim> 758 mb + <mcsim> 768 + <braunr> that's really weird + <braunr> i'd expect the kernel to consume much more space + <mcsim> http://paste.debian.net/128703/ + <mcsim> it's only dynamically allocated data + <braunr> yes + <braunr> ipc ports, rights, vm map entries, vm objects, and lots of other + hanging buffers + <braunr> about how much is zalloc_wasted_space ? + <braunr> if it's small or constant, i guess you could ignore it + <mcsim> about 492 + <mcsim> KiB + <braunr> well it's another good point, mach internal structures don't imply + much overhead + <braunr> or, the zone allocator is underused + + <tschwinge> mcsim, braunr: The memory allocator project is coming along + good, as I get from your IRC messages? + <braunr> tschwinge: yes, but as expected, improvements are minor + <tschwinge> But at the very least it's now well-known, maintainable code. + <braunr> yes, it's readable, easier to understand, provides self inspection + and is smp ready + <braunr> there also are less hacks, but a few less features (there are no + way to avoid sleeping so it's unusable - and unused - in interrupt + handlers) + <braunr> is* no way + <braunr> tschwinge: mcsim did a good job porting and measuring it + + +# IRC, freenode, #hurd, 2011-09-08 + + <antrik> braunr: note that the zalloc map used to be limited to 8 MiB or + something like that a couple of years ago... so it doesn't seems + surprising that the kernel uses "only" 5 MiB :-) + <antrik> (yes, we had a *lot* of zalloc panics back then...) + + +# IRC, freenode, #hurd, 2011-09-14 + + <mcsim> braunr: hello. I've written a constructor for kernel map entries + and it can return resources to their source. Can you have a look at it? + http://paste.debian.net/130037/ If all be OK I'll push it tomorrow. + <braunr> mcsim: send the patch through mail please, i'll apply it on my + copy + <braunr> are you sure the cache is reapable ? + <mcsim> All slabs, except first I allocate with kmem_alloc_wired. + <braunr> how can you be sure ? + <mcsim> First slab I allocate during bootstrap and use pmap_steal_memory + and further I use only kmem_alloc_wired + <braunr> no, you use kmem_free + <braunr> in kentry_dealloc_cache() + <braunr> which probably creates a recursion + <braunr> using the constructor this way isn't a good idea + <braunr> constructors are good for preconstructed state (set counters to 0, + init lists and locks, that kind of things, not allocating memory) + <braunr> i don't think you should try to make this special cache reapable + <braunr> mcsim: keep in mind constructors are applied on buffers at *slab* + creation, not at object allocation + <braunr> so if you allocate a single slab with, say, 50 or 100 objects per + slab, kmem_alloc_wired would be called that number of times + <mcsim> why kentry_dealloc_cache can create recursion? kentry_dealloc_cache + is called only by mem_cache_reap. + <braunr> right + <braunr> but are you totally sure mem_cache_reap() can't be called by + kmem_free() ? + <braunr> i think you're right, it probably can't + + +# IRC, freenode, #hurd, 2011-09-25 + + <mcsim> braunr: hello. I rewrote constructor for kernel entries and seems + that it works fine. I think that this was last milestone. Only moving of + memory allocator sources to more appropriate place and merge with main + branch left. + <braunr> mcsim: it needs renaming and reindenting too + <mcsim> for reindenting C-x h Tab in emacs will be enough? + <braunr> mcsim: make sure which style must be used first + <mcsim> and what should I rename and where better to place allocator? For + example, there is no lib directory, like in x15. Should I create it and + move list.* and rbtree.* to lib/ or move these files to util/ or + something else? + <braunr> mcsim: i told you balloc isn't a good name before, use something + more meaningful (kmem is already used in gnumach unfortunately if i'm + right) + <braunr> you can put the support files in kern/ + <mcsim> what about vm_alloc? + <braunr> you should prefix it with vm_ + <braunr> shouldn't + <braunr> it's a top level allocator + <braunr> on top of the vm system + <braunr> maybe mcache + <braunr> hm no + <braunr> maybe just km_ + <mcsim> kern/km_alloc.*? + <braunr> no + <braunr> just km + <mcsim> ok. + + +# IRC, freenode, #hurd, 2011-09-27 + + <mcsim> braunr: hello. When I've tried to speed of new allocator and bad + I've removed function mem_cpu_pool_fill. But you've said to undo this. I + don't understand why this function is necessary. Can you explain it, + please? + <mcsim> When I've tried to compare speed of new allocator and old* + <braunr> i'm not sure i said that + <braunr> i said the performance overhead is negligible + <braunr> so it's better to leave the cpu pool layer in place, as it almost + doesn't hurt + <braunr> you can implement the KMEM_CF_NO_CPU_POOL I added in the x15 mach + version + <braunr> so that cpu pools aren't used by default, but the code is present + in case smp is implemented + <mcsim> I didn't remove cpu pool layer. I've just removed filling of cpu + pool during creation of slab. + <braunr> how do you fill the cpu pools then ? + <mcsim> If object is freed than it is added to cpu poll + <braunr> so you don't fill/drain the pools ? + <braunr> you try to get/put an object and if it fails you directly fall + back to the slab layer ? + <mcsim> I drain them during garbage collection + <braunr> oh + <mcsim> yes + <braunr> you shouldn't touch the cpu layer during gc + <braunr> the number of objects should be small enough so that we don't care + much + <mcsim> ok. I can drain cpu pool at any other time if it is prohibited to + in mem_gc. + <mcsim> But why do we need to fill cpu poll during slab creation? + <mcsim> In this case allocation consist of: get object from slab -> put it + to cpu pool -> get it from cpu pool + <mcsim> I've just remove last to stages + <braunr> hm cpu pools aren't filled at slab creation + <braunr> they're filled when they're empty, and drained when they're full + <braunr> so that the number of objects they contain is increased/reduced to + a value suitable for the next allocations/frees + <braunr> the idea is to fall back as little as possible to the slab layer + because it requires the acquisition of the cache lock + <mcsim> oh. You're right. I'm really sorry. The point is that if cpu pool + is empty we don't need to fill it first + <braunr> uh, yes we do :) + <mcsim> Why cache locking is so undesirable? If we have free objects in + slabs locking will not take a lot if time. + <braunr> mcsim: it's undesirable on a smp system + <mcsim> ok. + <braunr> mcsim: and spin locks are normally noops on a up system + <braunr> which is the case in gnumach, hence the slightly better + performances without the cpu layer + <braunr> but i designed this allocator for x15, which only supports mp + systems :) + <braunr> mcsim: sorry i couldn't look at your code, sick first, busy with + server migration now (new server almost ready for xen hurds :)) + <mcsim> ok. + <mcsim> I ended with allocator if didn't miss anything important:) + <braunr> i'll have a look soon i hope :) + + +# IRC, freenode, #hurd, 2011-09-27 + + <antrik> braunr: would it be realistic/useful to check during GC whether + all "used" objects are actually in a CPU pool, and if so, destroy them so + the slab can be freed?... + <antrik> mcsim: BTW, did you ever do any measurements of memory + use/fragmentation? + <mcsim> antrik: I couldn't do this for zalloc + <antrik> oh... why not? + <antrik> (BTW, I would be interested in a comparision between using the CPU + layer, and bare slab allocation without CPU layer) + <mcsim> Result I've got were strange. It wasn't even aligned to page size. + <mcsim> Probably is it better to look into /proc/vmstat? + <mcsim> Because I put hooks in the code and probably I missed something + <antrik> mcsim: I doubt vmstat would give enough information to make any + useful comparision... + <braunr> antrik: isn't this draining cpu pools at gc time ? + <braunr> antrik: the cpu layer was found to add a slight overhead compared + to always falling back to the slab layer + <antrik> braunr: my idea is only to drop entries from the CPU cache if they + actually prevent slabs from being freed... if other objects in the slab + are really in use, there is no point in flushing them from the CPU cache + <antrik> braunr: I meant comparing the fragmentation with/without CPU + layer. the difference in CPU usage is probably negligable anyways... + <antrik> you might remember that I was (and still am) sceptical about CPU + layer, as I suspect it worsens the good fragmentation properties of the + pure slab allocator -- but it would be nice to actually check this :-) + <braunr> antrik: right + <braunr> antrik: the more i think about it, the more i consider slqb to be + a better solution ...... :> + <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 + + +# IRC, freenode, #hurd, 2011-11-14 + + <braunr> i've just realized that replacing the zone allocator removes most + (if not all) static limit on allocated objects + <braunr> as we have nothing similar to rlimits, this means kernel resources + are actually exhaustible + <braunr> and i'm not sure every allocation is cleanly handled in case of + memory shortage + <braunr> youpi: antrik: tschwinge: is this acceptable anyway ? + <braunr> (although IMO, it's also a good thing to get rid of those limits + that made the kernel panic for no valid reason) + <youpi> there are actually not many static limits on allocated objects + <youpi> only a few have one + <braunr> those defined in kern/mach_param.h + <youpi> most of them are not actually enforced + <braunr> ah ? + <braunr> they are used at zinit() time + <braunr> i thought they were + <youpi> yes, but most zones are actually fine with overcoming the max + <braunr> ok + <youpi> see zone->max_size += (zone->max_size >> 1); + <youpi> you need both !EXHAUSTIBLE and FIXED + <braunr> ok + <pinotree> making having rlimits enforced would be nice... + <pinotree> s/making// + <braunr> pinotree: the kernel wouldn't handle many standard rlimits anyway + + <braunr> i've just committed my final patch on mcsim's branch, which will + serve as the starting point for integration + <braunr> which means code in this branch won't change (or only last minute + changes) + <braunr> you're invited to test it + <braunr> there shouldn't be any noticeable difference with the master + branch + <braunr> a bit less fragmentation + <braunr> more memory can be reclaimed by the VM system + <braunr> there are debugging features + <braunr> it's SMP ready + <braunr> and overall cleaner than the zone allocator + <braunr> although a bit slower on the free path (because of what's + performed to reduce fragmentation) + <braunr> but even "slower" here is completely negligible + + +# IRC, freenode, #hurd, 2011-11-15 + + <mcsim> I enabled cpu_pool layer and kentry cache exhausted at "apt-get + source gnumach && (cd gnumach-* && dpkg-buildpackage)" + <mcsim> I mean kernel with your last commit + <mcsim> braunr: I'll make patch how I've done it in a few minutes, ok? It + will be more specific. + <braunr> mcsim: did you just remove the #if NCPUS > 1 directives ? + <mcsim> no. I replaced macro NCPUS > 1 with SLAB_LAYER, which equals NCPUS + > 1, than I redefined macro SLAB_LAYER + <braunr> ah, you want to make the layer optional, even on UP machines + <braunr> mcsim: can you give me the commands you used to trigger the + problem ? + <mcsim> apt-get source gnumach && (cd gnumach-* && dpkg-buildpackage) + <braunr> mcsim: how much ram & swap ? + <braunr> let's see if it can handle a quite large aptitude upgrade + <mcsim> how can I check swap size? + <braunr> free + <braunr> cat /proc/meminfo + <braunr> top + <braunr> whatever + <mcsim> total used free shared buffers + cached + <mcsim> Mem: 786368 332296 454072 0 0 + 0 + <mcsim> -/+ buffers/cache: 332296 454072 + <mcsim> Swap: 1533948 0 1533948 + <braunr> ok, i got the problem too + <mcsim> braunr: do you run hurd in qemu? + <braunr> yes + <braunr> i guess the cpu layer increases fragmentation a bit + <braunr> which means more map entries are needed + <braunr> hm, something's not right + <braunr> there are only 26 kernel map entries when i get the panic + <braunr> i wonder why the cache gets that stressed + <braunr> hm, reproducing the kentry exhaustion problem takes quite some + time + <mcsim> braunr: what do you mean? + <braunr> sometimes, dpkg-buildpackage finishes without triggering the + problem + <mcsim> the problem is in apt-get source gnumach + <braunr> i guess the problem happens because of drains/fills, which + allocate/free much more object than actually preallocated at boot time + <braunr> ah ? + <braunr> ok + <braunr> i've never had it at that point, only later + <braunr> i'm unable to trigger it currently, eh + <mcsim> do you use *-dbg kernel? + <braunr> yes + <braunr> well, i use the compiled kernel, with the slab allocator, built + with the in kernel debugger + <mcsim> when you run apt-get source gnumach, you run it in clean directory? + Or there are already present downloaded archives? + <braunr> completely empty + <braunr> ah just got it + <braunr> ok the limit is reached, as expected + <braunr> i'll just bump it + <braunr> the cpu layer drains/fills allocate several objects at once (64 if + the size is small enough) + <braunr> the limit of 256 (actually 252 since the slab descriptor is + embedded in its slab) is then easily reached + <antrik> mcsim: most direct way to check swap usage is vmstat + <braunr> damn, i can't live without slabtop and the amount of + active/inactive cache memory any more + <braunr> hm, weird, we have active/inactive memory in procfs, but not + buffers/cached memory + <braunr> we could set buffers to 0 and everything as cached memory, since + we're currently unable to communicate the purpose of cached memory + (whether it's used by disk servers or file system servers) + <braunr> mcsim: looks like there are about 240 kernel map entries (i forgot + about the ones used in kernel submaps) + <braunr> so yes, addin the cpu layer is what makes the kernel reach the + limit more easily + <mcsim> braunr: so just increasing limit will solve the problem? + <braunr> mcsim: yes + <braunr> slab reclaiming looks very stable + <braunr> and unfrequent + <braunr> (which is surprising) + <pinotree> braunr: "unfrequent"? + <braunr> pinotree: there isn't much memory pressure + <braunr> slab_collect() gets called once a minute on my hurd + <braunr> or is it infrequent ? + <braunr> :) + <pinotree> i have no idea :) + <braunr> infrequent, yes + + +# IRC, freenode, #hurd, 2011-11-16 + + <braunr> for those who want to play with the slab branch of gnumach, the + slabinfo tool is available at http://git.sceen.net/rbraun/slabinfo.git/ + <braunr> for those merely interested in numbers, here is the output of + slabinfo, for a hurd running in kvm with 512 MiB of RAM, an unused swap, + and a short usage history (gnumach debian packages built, aptitude + upgrade for a dozen of packages, a few git commands) + <braunr> http://www.sceen.net/~rbraun/slabinfo.out + <antrik> braunr: numbers for a long usage history would be much more + interesting :-) + + +## IRC, freenode, #hurd, 2011-11-17 + + <braunr> antrik: they'll come :) + <etenil> is something going on on darnassus? it's mighty slow + <braunr> yes + <braunr> i've rebooted it to run a modified kernel (with the slab + allocator) and i'm building stuff on it to stress it + <braunr> (i don't have any other available machine with that amount of + available physical memory) + <etenil> ok + <antrik> braunr: probably would be actually more interesting to test under + memory pressure... + <antrik> guess that doesn't make much of a difference for the kernel object + allocator though + <braunr> antrik: if ram is larger, there can be more objects stored in + kernel space, then, by building something large such as eglibc, memory + pressure is created, causing caches to be reaped + <braunr> our page cache is useless because of vm_object_cached_max + <braunr> it's a stupid arbitrary limit masking the inability of the vm to + handle pressure correctly + <braunr> if removing it, the kernel freezes soon after ram is filled + <braunr> antrik: it may help trigger the "double swap" issue you mentioned + <antrik> what may help trigger it? + <braunr> not checking this limit + <antrik> hm... indeed I wonder whether the freezes I see might have the + same cause + + +## IRC, freenode, #hurd, 2011-11-19 + + <braunr> http://www.sceen.net/~rbraun/slabinfo.out <= state of the slab + allocator after building the debian libc packages and removing all files + once done + <braunr> it's mostly the same as on any other machine, because of the + various arbitrary limits in mach (most importantly, the max number of + objects in the page cache) + <braunr> fragmentation is still quite low + <antrik> braunr: actually fragmentation seems to be lower than on the other + run... + <braunr> antrik: what makes you think that ? + <antrik> the numbers of currently unused objects seem to be in a similar + range IIRC, but more of them are reclaimable I think + <antrik> maybe I'm misremembering the other numbers + <braunr> there had been more reclaims on the other run + + +# IRC, freenode, #hurd, 2011-11-25 + + <braunr> mcsim: i've just updated the slab branch, please review my last + commit when you have time + <mcsim> braunr: Do you mean compilation/tests? + <braunr> no, just a quick glance at the code, see if it matches what you + intended with your original patch + <mcsim> braunr: everything is ok + <braunr> good + <braunr> i think the branch is ready for integration + + +# IRC, freenode, #hurd, 2011-12-17 + + <braunr> in the slab branch, there now is no use for the defines in + kern/mach_param.h + <braunr> should the file be removed or left empty as a placeholder for + future arbitrary limits ? + <braunr> (i'd tend ro remove it as a way of indicating we don't want + arbitrary limits but there may be a good reason to keep it around .. :)) + <youpi> I'd just drop it + <braunr> ok + <braunr> hmm maybe we do want to keep that one : + <braunr> #define IMAR_MAX (1 << 10) /* Max number of + msg-accepted reqs */ + <antrik> whatever that is... + <braunr> it gets returned in ipc_marequest_info + <braunr> but the mach_debug interface has never been used on the hurd + <braunr> there now is a master-slab branch in the gnumach repo, feel free + to test it + + +# IRC, freenode, #hurd, 2011-12-22 + + <youpi> braunr: does the new gnumach allocator has profiling features? + <youpi> e.g. to easily know where memory leaks reside + <braunr> youpi: you mean tracking call traces to allocated blocks ? + <youpi> not necessarily traces + <youpi> but at least means to know what kind of objects is filling memory + <braunr> it's very close to the zone allocator + <braunr> but instead of zones, there are caches + <braunr> each named after the type they store + <braunr> see http://www.sceen.net/~rbraun/slabinfo.out + <youpi> ok, so we can know, per-type, how much memory is used + <braunr> yes + <youpi> good + <braunr> if backtraces can easily be forged, it wouldn't be hard to add + that feature too + <youpi> does it dump such info when memory goes short? + <braunr> no but it can + <braunr> i've done this during tests + <youpi> it'd be good + <youpi> because I don't know in advance when a buildd will crash due to + that :) + <braunr> each time slab_collect() is called for example + <youpi> I mean not on collect, but when it's too late + <youpi> and thus always enabled + <braunr> ok + <youpi> (because there's nothing better to do than at least give infos) + <braunr> you just have to define "when it's too late", and i can add that + <youpi> when there is no memory left + <braunr> you mean when the number of free pages strictly reaches 0 ? + <youpi> yes + <braunr> ok + <youpi> i.e. just before crashing the kernel + <braunr> i see + + +# IRC, freenode, #hurdfr, 2012-01-02 + + <youpi> braunr: le code du slab allocator, il est écrit from scratch ? + <youpi> il y a encore du copyright carnegie mellon + <youpi> (dans slab_info.h du moins) + <youpi> ipc_hash_global_size = 256; + <youpi> il faudrait mettre 256 comme constante dans un header + <youpi> sinon c'est encore une valeur arbitraire cachée dans du code + <youpi> de même pour ipc_marequest_size etc. + <braunr> youpi: oui, from scratch + <braunr> slab_info.h est à l'origine zone_info.h + <braunr> pour les valeurs fixes, elles étaient déjà présentes de cette + façon, j'ai pensé qu'il valait mieux laisser comme ça pour faciliter la + lecture des diffs + <braunr> je ferai des macros à la place + <braunr> du coup il faudra peut-être remettre mach_param.h + <braunr> ou alors dans les .h ipc + + +# IRC, freenode, #hurd, 2012-01-18 + + <braunr> does the slab branch need other reviews/reports before being + integrated ? + + +# IRC, freenode, #hurd, 2012-01-30 + + <braunr> youpi: do you have some idea about when you want to get the slab + branch in master ? + <youpi> I was considering as soon as mcsim gets his paper + <braunr> right + + +# IRC, freenode, #hurd, 2012-02-22 + + <mcsim> Do I understand correct, that real memory page should be + necessarily in one of following lists: vm_page_queue_active, + vm_page_queue_inactive, vm_page_queue_free? + <braunr> cached pages are + <braunr> some special pages used only by the kernel aren't + <braunr> pages can be both wired and cached (i.e. managed by the page + cache), so that they can be passed to external applications and then + unwired (as is the case with your host_slab_info() function if you + remember) + <braunr> use "physical" instead of "real memory" + <mcsim> braunr: thank you. + + +# IRC, freenode, #hurd, 2012-04-22 + + <braunr> youpi: tschwinge: when the slab code was added, a few new files + made into gnumach that come from my git repo and are used in other + projects as well + <braunr> they're licensed under BSD upstream and GPL in gnumach, and though + it initially didn't disturb me, now it does + <braunr> i think i should fix this by leaving the original copyright and + adding the GPL on top + <youpi> sure, submit a patch + <braunr> hm i have direct commit acces if im right + <youpi> then fix it :) + <braunr> do you want to review ? + <youpi> I don't think there is any need to + <braunr> ok diff --git a/open_issues/gnumach_memory_management/pmap.out b/open_issues/gnumach_memory_management/pmap.out new file mode 100644 index 00000000..b1af1e66 --- /dev/null +++ b/open_issues/gnumach_memory_management/pmap.out @@ -0,0 +1,85 @@ +Start End Size Offset rwxpc RWX I/W/A Dev Inode - File +c0000000-c16c1fff 23304k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +c16c2000-c16c2fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +c16c3000-c16e2fff 128k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +c16e3000-c999cfff 133864k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ kmem_map ] + c16e3000-c16e3fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c16e4000-c1736fff 332k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1737000-c1737fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1738000-c1766fff 188k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1767000-c1767fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1768000-c182dfff 792k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c182e000-c182efff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c182f000-c187bfff 308k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c187c000-c187cfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c187d000-c187dfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1880000-c189ffff 128k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +c999d000-ca99cfff 16384k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ pager_map ] +ca99d000-ca9b7fff 108k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +ca9b8000-ca9b9fff 8k 0a9b8000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +ca9ba000-ca9bbfff 8k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +ca9bc000-ca9bffff 16k 0a9bc000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +ca9c0000-ca9dffff 128k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +ca9e0000-cab0bfff 1200k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ phys_map ] +cab0c000-cad16fff 2092k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ mb_map ] + cab0c000-cab0cfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + cab0d000-cab3afff 184k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cad17000-cad26fff 64k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cad27000-cad2cfff 24k 0ad27000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cad2d000-cad2dfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cad2e000-cad2ffff 8k 0ad2e000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cad30000-cae0ffff 896k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cae10000-cae11fff 8k 0ae10000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cae12000-cae81fff 448k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cae82000-cae83fff 8k 0ae82000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cae84000-caecbfff 288k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caecc000-caecdfff 8k 0aecc000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +caece000-caecefff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caecf000-caecffff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caed0000-caed1fff 8k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caed2000-caed3fff 8k 0aed2000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +caed4000-caee5fff 72k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caee6000-caee9fff 16k 0aee6000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +caeea000-caeeefff 20k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caeef000-caef4fff 24k 0aeef000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +caef5000-cb00cfff 1120k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb00d000-cb01cfff 64k 0b00d000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb01d000-cb02afff 56k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb02b000-cb82afff 8192k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ ubc_pager ] +cb82b000-cb838fff 56k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb839000-cb839fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb83a000-cb83bfff 8k 0b83a000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb83c000-cb855fff 104k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb856000-cb857fff 8k 0b856000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb858000-cb858fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb859000-cb85cfff 16k 0b859000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb85d000-cb85dfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb85e000-cb85ffff 8k 0b85e000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb860000-cb88ffff 192k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb890000-cb8cffff 256k 0b890000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb8d0000-cb8f0fff 132k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb8f1000-cb8f4fff 16k 0b8f1000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb8f5000-cba03fff 1084k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cba04000-cba04fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cba05000-cbaf1fff 948k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbaf2000-cbaf3fff 8k 0baf2000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbaf4000-cbaf7fff 16k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbaf8000-cbafffff 32k 0baf8000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbb00000-cbb70fff 452k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbb71000-cbb76fff 24k 0bb71000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbb77000-cbb7bfff 20k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbb7c000-cbb7ffff 16k 0bb7c000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbb80000-cbbc1fff 264k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbc2000-cbbc2fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbc3000-cbbc3fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbc4000-cbbc5fff 8k 0bbc4000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbbc6000-cbbc8fff 12k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbc9000-cbbcafff 8k 0bbc9000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbbcb000-cbbcdfff 12k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbce000-cbbcffff 8k 0bbce000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbbd0000-cbca1fff 840k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbca2000-cbcadfff 48k 0bca2000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbcae000-cbcaefff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbcaf000-cbcb2fff 16k 0bcaf000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbcc0000-cbcdffff 128k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + total 193356k 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/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn new file mode 100644 index 00000000..03cb3725 --- /dev/null +++ b/open_issues/gnumach_page_cache_policy.mdwn @@ -0,0 +1,627 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +[[!toc]] + + +# [[page_cache]] + + +# IRC, freenode, #hurd, 2012-04-26 + + <braunr> another not-too-long improvement would be changing the page cache + policy + <youpi> to drop the 4000 objects limit, you mean ? + <braunr> yes + <youpi> do you still have my patch attempt ? + <braunr> no + <youpi> let me grab that + <braunr> oh i won't start it right away you know + <braunr> i'll ask for it when i do + <youpi> k + <braunr> (otherwise i fell i'll just loose it again eh) + <youpi> :) + <braunr> but i imagine it's not too hard to achieve + <youpi> yes + <braunr> i also imagine to set a large threshold of free pages to avoid + deadlocks + <braunr> which will still be better than the current situation where we + have either lots of free pages because tha max limit is reached, or lots + of pressure and system freezes :/ + <youpi> yes + + +## IRC, freenode, #hurd, 2012-06-17 + + <braunr> youpi: i don't understand your patch :/ + <youpi> arf + <youpi> which part don't you understand? + <braunr> the global idea :/ + <youpi> first, drop the limit on number of objects + <braunr> you added a new collect call at pageout time + <youpi> (i.e. here, hack overflow into 0) + <braunr> yes + <braunr> obviously + <youpi> but then the cache keeps filling up with objects + <youpi> which sooner or later become empty + <youpi> thus the collect, which is supposed to look for empty objects, and + just drop them + <braunr> but not at the right time + <braunr> objects should be collected as soon as their ref count drops to 0 + <braunr> err + <youpi> now, the code of the collect is just a crude attempt without + knowing much about the vm + <braunr> when their resident page count drops to 0 + <youpi> so don't necessarily read it :) + <braunr> ok + <braunr> i've begin playing with the vm recently + <braunr> the limits (arbitrary, and very old obviously) seem far too low + for current resources + <braunr> (e.g. the threshold on free pages is 50 iirc ...) + <youpi> yes + <braunr> i'll probably use a different approach + <braunr> the one i mentioned (collecting one object at a time - or pushing + them on a list for bursts - when they become empty) + <braunr> this should relax the kernel allocator more + <braunr> (since there will be less empty vm_objects remaining until the + next global collecttion) + + +## IRC, freenode, #hurd, 2012-06-30 + + <braunr> the threshold values of the page cache seem quite enough actually + <youpi> braunr: ah + <braunr> youpi: yes, it seems the problems are in ext2, not in the VM + <youpi> k + <youpi> the page cache limitation still doesn't help :) + <braunr> the problem in the VM is the recycling of vm_objects, which aren't + freed once empty + <braunr> but it only wastes some of the slab memory, it doesn't prevent + correct processing + <youpi> braunr: thus the limitation, right? + <braunr> no + <braunr> well + <braunr> that's the policy they chose at the time + <braunr> for what reason .. i can't tell + <youpi> ok, but I mean + <youpi> we can't remove the policy because of the non-free of empty objects + <braunr> we must remove vm_objects at some point + <braunr> but even without it, it makes no sense to disable the limit while + ext2 is still unstable + <braunr> also, i noticed that the page count in vm_objects never actually + drop to 0 ... + <youpi> you mean the limit permits to avoid going into the buggy scenarii + too often? + <braunr> yes + <youpi> k + <braunr> at least, that's my impression + <braunr> my test case is tar xf files.tar.gz, which contains 50000 files of + 12k random data + <braunr> i'll try with other values + <braunr> i get crashes, deadlocks, livelocks, and it's not pretty :) + <braunr> and always in ext2, mach doesn't seem affected by the issue, other + than the obvious + <braunr> (well i get the usual "deallocating an invalid port", but as + mentioned, it's "most probably a bug", which is the case here :) + <youpi> braunr: looks coherent with the hangs I get on the buildds + <braunr> youpi: so that's the nasty bug i have to track now + <youpi> though I'm also still getting some out of memory from gnumach + sometimes + <braunr> the good thing is i can reproduce it very quickly + <youpi> a dump from the allocator to know which zone took all the room + might help + <braunr> youpi: yes i promised that too + <youpi> although that's probably related with ext2 issues :) + <braunr> youpi: can you send me the panic message so i can point the code + which must output the allocator state please ? + <youpi> next time I get it, sure :) + <pinotree> braunr: you could implement a /proc/slabinfo :) + <braunr> pinotree: yes but when a panic happens, it's too late + <braunr> http://git.sceen.net/rbraun/slabinfo.git/ btw + <braunr> although it's not part of procfs + <braunr> and the mach_debug interface isn't provided :( + + +## IRC, freenode, #hurd, 2012-07-03 + + <braunr> it looks like pagers create a thread per memory object ... + <antrik> braunr: oh. so if I open a lot of files, ext2fs will *inevitably* + have lots of threads?... + <braunr> antrik: i'm not sure + <braunr> it may only be required to flush them + <braunr> but when there are lots of them, the threads could run slowly, + giving the impression there is one per object + <braunr> in sync mode i don't see many threads + <braunr> and i don't get the bug either for now + <braunr> while i can see physical memory actually being used + <braunr> (and the bug happens before there is any memory pressure in the + kernel) + <braunr> so it definitely looks like a corruption in ext2fs + <braunr> and i have an idea .... :> + <braunr> hm no, i thought an alloca with a big size parameter could erase + memory outside the stack, but it's something else + <braunr> (although alloca should really be avoided) + <braunr> arg, the problem seems to be in diskfs_sync_everything -> + ports_bucket_iterate (pager_bucket, sync_one); :/ + <braunr> :( + <braunr> looks like the ext2 problem is triggered by calling pager_sync + from diskfs_sync_everything + <braunr> and is possibly related to + http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00127.html + <braunr> (and for reference, the rest of the discussion + http://lists.gnu.org/archive/html/bug-hurd/2010-04/msg00012.html) + <braunr> multithreading in libpager is scary :/ + <antrik> braunr: s/in libpager/ ;-) + <braunr> antrik: right + <braunr> omg the ugliness :/ + <braunr> ok i found a bug + <braunr> a real one :) + <braunr> (but not sure it's the only one since i tried that before) + <braunr> 01:38 < braunr> hm no, i thought an alloca with a big size + parameter could erase memory outside the stack, but it's something else + <braunr> turns out alloca is sometimes used for 64k+ allocations + <braunr> which explains the stack corruptions + <pinotree> ouch + <braunr> as it's used to duplicate the node table before traversing it, it + also explains why the cache limit affects the frequency of the bug + <braunr> now the fun part, write the patch following GNU protocol .. :) + +[[!message-id "1341350006-2499-1-git-send-email-rbraun@sceen.net"]] + + <braunr> if someone feels like it, there are a bunch of alloca calls in the + hurd (like around 30 if i'm right) + <braunr> most of them look safe, but some could trigger that same problem + in other servers + <braunr> ok so far, no problem with the upstream ext2fs code :) + <braunr> 20 loops of tar xf / rm -rf consuming all free memory as cache :) + <braunr> the hurd uses far too much cpu time for no valid reason in many + places :/ + * braunr happy + <braunr> my hurd is completely using its ram :) + <gnu_srs> Meaning, the bug is solved? Congrats if so :) + <braunr> well, ext2fs looks way more stable now + <braunr> i haven't had a single issue since the change, so i guess i messed + something with my previous test + <braunr> and the Mach VM cache implementation looks good enough + <braunr> now the only thing left is to detect unused objects and release + them + <braunr> which is actually the core of my work :) + <braunr> but i'm glad i could polish ext2fs + <braunr> with luck, this is the issue that was striking during "thread + storms" in the past + * pinotree hugs braunr + <braunr> i'm also very happy to see the slab allocator reacting well upon + memory pressure :> + <mcsim> braunr: Why alloca corrupted memory diskfs_node_iterate? Was + temporary node to big to keep it in stack? + <braunr> mcsim: yes + <braunr> 17:54 < braunr> turns out alloca is sometimes used for 64k+ + allocations + <braunr> and i wouldn't be surprised if our thread stacks are + simplecontiguous 64k mappings of zero-filled memory + <braunr> (as Mach only provides bottom-up allocation) + <braunr> our thread implementation should leave unmapped areas between + thread stacks, to easily catch such overflows + <pinotree> braunr: wouldn't also fatfs/inode.c and tmpfs/node.c need the + same fix? + <braunr> pinotree: possibly + <braunr> i haven't looked + <braunr> more than 300 loops of tar xf / rm -rf on an archive of 20000 + files of 12 KiB each, without any issue, still going on :) + <youpi> braunr: yay + + +## [[!message-id "20120703121820.GA30902@mail.sceen.net"]], 2012-07-03 + + +## IRC, freenode, #hurd, 2012-07-04 + + <braunr> mach is so good it caches objects which *no* page in physical + memory + <braunr> hm i think i have a working and not too dirty vm cache :> + <kilobug> braunr: congrats :) + <braunr> kilobug: hey :) + <braunr> the dangerous side effect is the increased swappiness + <braunr> we'll have to monitor that on the buildds + <braunr> otherwise the cache is effectively used, and the slab allocator + reports reasonable amounts of objects, not increasing once the ram is + full + <braunr> let's see what happens with 1.8 GiB of RAM now + <braunr> damn glibc is really long to build :) + <braunr> and i fear my vm cache patch makes non scalable algorithms negate + some of its benefits :/ + <braunr> 72 tasks, 2090 threads + <braunr> we need the ability to monitor threads somewhere + + +## IRC, freenode, #hurd, 2012-07-05 + + <braunr> hm i get kernel panics when not using the host cache :/ + <braunr> no virtual memory for stack allocations + <braunr> that's scary + <antrik> ? + <braunr> i guess the lack of host cache makes I/O slow enough to create a + big thread storm + <braunr> that completely exhausts the kernel space + <braunr> my patch challenges scalability :) + <antrik> and not having a zalloc zone anymore, instead of getting a nice + panic when trying to allocate yet another thread, you get an address + space exhaustion on an unrelated event instead. I see ;-) + <braunr> thread stacks are not allocated from a zone/cache + <braunr> also, the panic concerned aligned memory, but i don't think that + matters + <braunr> the kernel panic clearly mentions it's about thread stack + allocation + <antrik> oh, by "stack allocations" you actually mean allocating a stack + for a new thread... + <braunr> yes + <antrik> that's not what I normally understand when reading "stack + allocations" :-) + <braunr> user stacks are simple zero filled memory objects + <braunr> so we usually get a deadlock on them :> + <braunr> i wonder if making ports_manage_port_operations_multithread limit + the number of threads would be a good thing to do + <antrik> braunr: last time slpz did that, it turned out that it causes + deadlocks in at least one (very specific) situation + <braunr> ok + <antrik> I think you were actually active at the time slpz proposed the + patch (and it was added to Debian) -- though probably not at the time + where youpi tracked it down as the cause of certain lockups, so it was + dropped again... + <braunr> what seems very weird though is that we're normally using + continuations + <antrik> braunr: you mean in the kernel? how is that relevant to the topic + at hand?... + <braunr> antrik: continuations have been designed to reduce the number of + stacks to one per cpu :/ + <braunr> but they're not used everywhere + <antrik> they are not used *anywhere* in the Hurd... + <braunr> antrik: continuations are supposed to be used by kernel code + <antrik> braunr: not sure what you are getting at. of course we should use + some kind of continuations in the Hurd instead of having an active thread + for every single request in flight -- but that's not something that could + be done easily... + <braunr> antrik: oh no, i don't want to use continuations at all + <braunr> i just want to use less threads :) + <braunr> my panic definitely looks like a thread storm + <braunr> i guess increasing the kmem_map will help for the time bein + <braunr> g + <braunr> (it's not the whole kernel space that gets filled up actually) + <braunr> also, stacks are kept on a local cache until there is memory + pressure oO + <braunr> their slab cache can fill the backing map before there is any + pressure + <braunr> and it makes a two level cache, i'll have to remove that + <antrik> well, how do you reduce the number of threads? apart from + optimising scheduling (so requests are more likely to be completed before + new ones are handled), the only way to reduce the number of threads is to + avoid having a thread per request + <braunr> exactly + <antrik> so instead the state of each request being handled has to be + explicitly stored... + <antrik> i.e. continuations + <braunr> hm actually, no + <braunr> you use thread migration :) + <braunr> i don't want to artificially use the number of kernel threads + <braunr> the hurd should be revamped not to use that many threads + <braunr> but it looks like a hard task + <antrik> well, thread migration would reduce the global number of threads + in the system... it wouldn't prevent a server from having thousands of + threads + <braunr> threads would allready be allocated before getting in the server + <antrik> again, the only way not to use a thread for each outstanding + request is having some explicit request state management, + i.e. continuations + <braunr> hm right + <braunr> but we can nonetheless reduce the number of threads + <braunr> i wonder if the sync threads are created on behalf of the pagers + or the kernel + <braunr> one good thing is that i can already feel better performance + without using the host cache until the panic happens + <antrik> the tricky bit about that is that I/O can basically happen at any + point during handling a request, by hitting a page fault. so we need to + be able to continue with some other request at any point... + <braunr> yes + <antrik> actually, readahead should help a lot in reducing the number of + request and thus threads... still will be quite a lot though + <braunr> we should have a bunch of pageout threads handling requests + asynchronously + <braunr> it depends on the implementation + <braunr> consider readahead detects that, in the next 10 pages, 3 are not + resident, then 1 is, then 3 aren't, then 1 is again, and the last two + aren't + <braunr> how is this solved ? :) + <braunr> about the stack allocation issue, i actually think it's very + simple to solv + <braunr> the code is a remnant of the old BSD days, when processes were + heavily swapped + <braunr> so when a thread is created, its stack isn't allocated + <braunr> the allocation happens when the thread is dispatched, and the + scheduler finds it's swapped (which is the initial state) + <braunr> the stack is allocated, and the operation is assumed to succeed, + which is why failure produces a panic + <antrik> well, actually, not just readahead... clustered paging in + general. the thread storms happen mostly on write not read AIUI + <braunr> changing that to allocate at thread creation time will allow a + cleaner error handling + <braunr> antrik: yes, at writeback + <braunr> antrik: so i guess even when some physical pages are already + present, we should aim at larger sizes for fewer I/O requests + <antrik> not sure that would be worthwhile... probably doesn't happen all + that often. and if some of the pages are dirty, we would have to make + sure that they are ignored although they were part of the request... + <braunr> yes + <braunr> so one request per missing area ? + <antrik> the opposite might be a good idea though -- if every other page is + dirty, it *might* indeed be preferable to do a single request rewriting + even the clean ones in between... + <braunr> yes + <braunr> i personally think one request, then replace only what was + missing, is simpler and preferable + <antrik> OTOH, rewriting clean pages might considerably increase write time + (and wear) on SSDs + <braunr> why ? + <antrik> I doubt the controller is smart enough to recognies if a page + doesn't really need rewriting + <antrik> so it will actually allocate and write a new cluster + <braunr> no but it won't spread writes on different internal sectors, will + it ? + <braunr> sectors are usually really big + <antrik> "sectors" is not a term used in SSDs :-) + <braunr> they'll be erased completely whatever the amount of data at some + point if i'm right + <braunr> ah + <braunr> need to learn more about that + <braunr> i thought their internal hardware was much like nand flash + <antrik> admittedly I don't remember the correct terminology either... + <antrik> they *are* NAND flash + <antrik> writing is actually not the problem -- it can happen in small + chunks. the problem is erasing, which is only possible in large blocks + <braunr> yes + <braunr> so having larger requests doesn't seem like a problem to me + <braunr> because of that + <antrik> thus smart controllers (which pretty much all SSD nowadays have, + and apparently even SD cards) do not actually overwrite. instead, writes + always happen to clean portions, and erasing only happens when a block is + mostly clean + <antrik> (after relocating the remaining used parts to other clean areas) + <antrik> braunr: the problem is not having larger requests. the problem is + rewriting clusters that don't really need rewriting. it means the dist + performs unnecessary writing actions. + <antrik> it doesn't hurt for magnetic disks, as the head has to pass over + the unchanged sectors anyways; and rewriting the unnecessarily doesn't + increase wear + <antrik> but it's different for SSDs + <antrik> each write has a penalty there + <braunr> i thought only erases were the real penalty + <antrik> well, erase happens in the background with modern controllers; so + it has no direct penalty. the write has a direct performance penalty when + saturating the bandwith, and always has a direct wear penalty + <braunr> can't controllers handle 32k requests ? like everything does ? :/ + <antrik> sure they can. but that's beside the point... + <braunr> if they do, they won't mind the clean data inside such large + blocks + <antrik> apparently we are talking past each other + <braunr> i must be missing something important about SSD + <antrik> braunr: the point is, the controller doesn't *know* it's clean + data; so it will actually write it just like the really unclean data + <braunr> yes + <braunr> and it will choose an already clean sector for that (previously + erased), so writing larger blocks shouldn't hurt + <braunr> there will be a slight increase in bandwidth usage, but that's + pretty much all of it + <braunr> isn't it ? + <antrik> well, writing always happens to clean blocks. but writing more + blocks obviously needs more time, and causes more wear... + <braunr> aiui, blocks are always far larger than the amount of pages we + want to writeback in one request + <braunr> the only way to use more than one is crossing a boundary + <antrik> no. again, the blocks that can be *written* are actually quite + small. IIRC most SSDs use 4k nowadays + <braunr> ok + <antrik> only erasing operates on much larger blocks + <braunr> so writing is a problem too + <braunr> i didn't think it would cause wear leveling to happen + <antrik> well, I'm not sure whether the wear actually happens on write or + on erase... but that doesn't matter, as the number of blocks that need to + be erased is equivalent to the number of blocks written... + <braunr> sorry, i'm really not sure + <braunr> if you erase one sector, then write the first and third block, + it's clearly not equivalent + <braunr> i mean + <braunr> let's consider two kinds of pageout requests + <braunr> 1/ a big one including clean pages + <braunr> 2/ several ones for dirty pages only + <braunr> let's assume they both need an erase when they happen + <braunr> what's the actual difference between them ? + <braunr> wear will increase only if the controller handle it on writes, if + i'm right + <braunr> but other than that, it's just bandwidth + <antrik> strictly speaking erase is only *necessary* when there are no + clean blocks anymore. but modern controllers will try to perform erase of + unused blocks in the background, so it doesn't delay actual writes + <braunr> i agree on that + <antrik> but the point is that for each 16 pages (or so) written, we need + to erase one block so we get 16 clean pages to write... + <braunr> yes + <braunr> which is about the size of a request for the sequential policy + <braunr> so it fits + <antrik> just to be clear: it doesn't matter at all how the pages + "fit". the controller will reallocate them anyways + <antrik> what matters is how many pages you write + <braunr> ah + <braunr> i thought it would just put the whole request in a single sector + (or two) + <antrik> I'm not sure what you mean by "sector". as I said, it's not a term + used in SSD technology + <braunr> so do you imply that writes can actually get spread over different + sectors ? + <braunr> the sector is the unit at the nand flash level, its size is the + erase size + <antrik> actually, I used the right terminology... the erase unit is the + block; the write unit is the page + <braunr> sector is a synonym of block + <antrik> never seen it. and it's very confusing, as it isn't in any way + similar to sectors in magnetic disks... + <braunr> http://en.wikipedia.org/wiki/Flash_memory#NAND_flash + <braunr> it's actually in the NOR part right before, paragraph "Erasing" + <braunr> "Modern NOR flash memory chips are divided into erase segments + (often called blocks or sectors)." + <antrik> ah. I skipped the NOR part :-) + <braunr> i've only heard sector where i worked, but i don't consider french + computer engineers to be authorities on the matter :) + <antrik> hehe + <braunr> let's call them block + <braunr> so, thread stacks are allocated out of the kernel map + <braunr> this is already a bad thing (which is probably why there is a + local cache btw) + <antrik> anyways, yes. modern controllers might split a contiguous write + request onto several blocks, as well as put writes to completely + different logical pages into one block. the association between addresses + and actual blocks is completely free + <braunr> now i wonder why the kernel map is so slow, as the panic happens + at about 3k threads, so about 11M of thread stacks + <braunr> antrik: ok + <braunr> antrik: well then it makes sense to send only dirty pages + <braunr> s/slow/low/ + <antrik> it's different for raw flash (using MTD subsystem in Linux) -- but + I don't think this is something we should consider any time soon :-) + <antrik> (also, raw flash is only really usable with specialised + filesystems anyways) + <braunr> yes + <antrik> are the thread stacks really only 4k? I would expect them to be + larger in many cases... + <braunr> youpi reduced them some time ago, yes + <braunr> they're 4k on xen + <braunr> uh, 16k + <braunr> damn, i'm wondering why i created separate submaps for the slab + allocator :/ + <braunr> probably because that's how it was done by the zone allocator + before + <braunr> but that's stupid :/ + <braunr> hm the stack issue is actually more complicated than i thought + because of interrupt priority levels + <braunr> i increased the kernel map size to avoid the panic instead + <braunr> now libc0.3 seems to build fine + <braunr> and there seems to be a clear decrease of I/O :) + + +### IRC, freenode, #hurd, 2012-07-06 + + <antrik> braunr: there is a submap for the slab allocator? that's strange + indeed. I know we talked about this; and I am pretty sure we agreed + removing the submap would actually be among the major benefits of a new + allocator... + <braunr> antrik: a submap is a good idea anyway + <braunr> antrik: it avoids fragmenting the kernel space too much + <braunr> it also breaks down locking + <braunr> but we could consider it + <braunr> as a first step, i'll merge the kmem and kalloc submaps (the ones + used for the slab caches and the malloc-like allocations respectively) + <braunr> then i'll change the allocation of thread stacks to use a slab + cache + <braunr> and i'll also remove the thread swapping stuff + <braunr> it will take some time, but by the end we should be able to + allocate tens of thousands of threads, and suffer no panic when the limit + is reached + <antrik> braunr: I'm not sure "no panic" is really a worthwhile goal in + such a situation... + <braunr> antrik: uh ?N + <braunr> antrik: it only means the system won't allow the creation of + threads until there is memory available + <braunr> from my pov, the microkernel should never fail up to a point it + can't continue its job + <antrik> braunr: the system won't be able to recover from such a situation + anyways. without actual resource management/priorisation, not having a + panic is not really helpful. it only makes it harder to guess what + happened I fear... + <braunr> i don't see why it couldn't recover :/ + + +## IRC, freenode, #hurd, 2012-07-07 + + <braunr> grmbl, there are a lot of issues with making the page cache larger + :( + <braunr> it actually makes the system slower in half of my tests + <braunr> we have to test that on real hardware + <braunr> unfortunately my current results seem to indicate there is no + clear benefit from my patch + <braunr> the current limit of 4000 objects creates a good balance between + I/O and cpu time + <braunr> with the previous limit of 200, I/O is often extreme + <braunr> with my patch, either the working set is less than 4k objects, so + nothing is gained, or the lack of scalability of various parts of the + system add overhead that affect processing speed + <braunr> also, our file systems are cached, but our block layer isn't + <braunr> which means even when accessing data from the cache, accesses + still cause some I/O for metadata + + +## IRC, freenode, #hurd, 2012-07-08 + + <braunr> youpi: basically, it works fine, but exposes scalability issues, + and increases swapiness + <youpi> so it doens't help with stability? + <braunr> hum, that was never the goal :) + <braunr> the goal was to reduce I/O, and increase performance + <youpi> sure + <youpi> but does it at least not lower stability too much? + <braunr> not too much, no + <youpi> k + <braunr> most of the issues i found could be reproduced without the patch + <youpi> ah + <youpi> then fine :) + <braunr> random deadlocks on heavy loads + <braunr> youpi: but i'm not sure it helps with performance + <braunr> youpi: at least not when emulated, and the host cache is used + <youpi> that's not very surprising + <braunr> it does help a lot when there is no host cache and the working set + is greater (or far less) than 4k objects + <youpi> ok + <braunr> the amount of vm_object and ipc_port is gracefully adjusted + <youpi> that'd help us with not having to tell people to use the complex + -drive option :) + +([[hurd/running/qemu/writeback_caching]].) + + <braunr> so you can easily run a hurd with 128 MiB with decent performance + and no leak in ext2fs + <braunr> yes + <braunr> for example + <youpi> braunr: I'd say we should just try it on buildds + <braunr> (it's not finished yet, i'd like to work more on reducing + swapping) + <youpi> (though they're really not busy atm, so the stability change can't + really be measured) + <braunr> when building the hurd, which takes about 10 minutes in my kvm + instances, there is only a 30 seconds difference between using the host + cache and not using it + <braunr> this is already the case with the current kernel, since the + working set is less than 4k objects + <braunr> while with the previous limit of 200 objects, it took 50 minutes + without host cache, and 15 with it + <braunr> so it's a clear benefit for most uses, except my virtual machines + :) + <youpi> heh + <braunr> because there, the amount of ram means a lot of objects can be + cached, and i can measure an increase in cpu usage + <braunr> slight, but present + <braunr> youpi: isn't it a good thing that buildds are resting a bit ? :) + <youpi> on one hand, yes + <youpi> but on the other hand, that doesn't permit to continue + stress-testing the Hurd :) + <braunr> we're not in a hurry for this patch + <braunr> because using it really means you're tickling the pageout daemon a + lot :) + + +## [[metadata_caching]] diff --git a/open_issues/gnumach_rpc_timeouts.mdwn b/open_issues/gnumach_rpc_timeouts.mdwn new file mode 100644 index 00000000..68cfcb5a --- /dev/null +++ b/open_issues/gnumach_rpc_timeouts.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-28 + + <pinotree> uhm, apparently mach cannot handle timeouts for rpc's of more + than (2^(sizeof(mach_msg_timeout_t) * 8) - 1) / HZ + <pinotree> it seems that how ticks are calculated in mach, it becomes 0 + <pinotree> +because of diff --git a/open_issues/gnumach_tick.mdwn b/open_issues/gnumach_tick.mdwn new file mode 100644 index 00000000..eed447f6 --- /dev/null +++ b/open_issues/gnumach_tick.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-07-05 + + <pinotree> braunr: wrt to mach: it seems to me it ticks every 10ms or so, + it is true? + <braunr> yes + <braunr> and it's not preemptible + <pinotree> braunr: that means a gnumach kernel currently has a maximum + uptime of almost 500 days + <braunr> pinotree: what do you mean ? + <pinotree> there's an int (or uint, i don't remember) variable that keeps + the tick count + <braunr> yes the tick variable should probably be a 64-bits type + <braunr> or a struct + <braunr> but the tick count should only be used for computation on "short" + delays + <braunr> and it should be safe to use it even when it overflows + <braunr> it's not the wall clock + <pinotree> i found that when investigating why the maximum timeout for a + mach_msg is like INT_MAX >> 2 (or 4) or something like that, also due to + the tick count + <braunr> iirc, in linux, they mostly use the lower 32-bits on 32-bits + architecture, updating the 32 upper only when necessary diff --git a/open_issues/gnumach_tlb_flushing.mdwn b/open_issues/gnumach_tlb_flushing.mdwn new file mode 100644 index 00000000..45d0730d --- /dev/null +++ b/open_issues/gnumach_tlb_flushing.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date. + + <tschwinge> gianluca, youpi: Why the value 32 for the TLB flushing decision, by the way? + <youpi> completely arbitrary + <tschwinge> I thought whether that might perhaps be worth a macro definition with a comment? + <verte> what's the typical TLB size these days? + <youpi> tschwinge: right + <youpi> note that the 32 value would be probably different between native and xen + <gianluca> tschwinge: just arbitrary diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn new file mode 100644 index 00000000..90137766 --- /dev/null +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -0,0 +1,200 @@ +[[!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-07-20 + + <braunr> could we add gnumach forward map entry merging as an open issue ? + <braunr> probably hurting anything using bash extensively, like build most + build systems + <braunr> mcsim: this map entry merging problem might interest you + <braunr> tschwinge: see vm/vm_map.c, line ~905 + <braunr> "See whether we can avoid creating a new entry (and object) by + extending one of our neighbors. [So far, we only attempt to extend from + below.]" + <braunr> and also vm_object_coalesce + <braunr> "NOTE: Only works at the moment if the second object is NULL - + if it's not, which object do we lock first?" + <braunr> although map entry merging should be enough + <braunr> this seems to be the cause for bash having between 400 and 1000+ + map entries + <braunr> thi makes allocations and faults slow, and forks even more + <braunr> but again, this should be checked before attempting anything + <braunr> (for example, this comment still exists in freebsd, although they + solved the problem, so who knows) + <antrik> braunr: what exactly would you want to check? + <antrik> braunr: this rather sounds like something you would just have to + try... + <braunr> antrik: that map merging is actually incomplete + <braunr> and that entries can actually be merged + <antrik> hm, I see... + <braunr> (i.e. they are adjacent and have compatible properties + <braunr> ) + <braunr> antrik: i just want to avoid the "hey, splay trees mak fork slow, + let's work on it for a month to see it wasn't the problem" + <antrik> so basically you need a dump of a task's map to check whether + there are indeed entries that could/should be merged? + <antrik> hehe :-) + <braunr> well, vminfo should give that easily, i just didn't take the time + to check it + <jkoenig> braunr, as you pointed out, "vminfo $$" seems to indicate that + merging _is_ incomplete. + <braunr> this could actually have a noticeable impact on package builds + <braunr> hm + <braunr> the number of entries for instances of bash running scripts don't + exceed 50-55 :/ + <braunr> the issue seems to affect only certain instances (login shells, + and su -) + <braunr> jkoenig: i guess dash is just much lighter than bash in many ways + :) + <jkoenig> braunr, the number seems to increase with usage (100 here for a + newly started interactive shell, vs. 150 in an old one) + <braunr> yes, merging is far from complete in the vm_map code + <braunr> it only handles null objects (private zeroed memory), and only + tries to extend a previous entry (this isn't even a true merge) + <braunr> this works well for the kernel however, which is why there are so + few as 25 entries + <braunr> but any request, be it e.g. mmap(), or mprotect(), can easily + split entries + <braunr> making their number larger + <jkoenig> my ext2fs has ~6500 entries, but I guess this is related to + mapping blocks from the filesystem, right? + <braunr> i think so + <braunr> hm not sure actually + <braunr> i'd say it's fragmentation due to copy on writes when client have + mapped memory from it + <braunr> there aren't that many file mappings though :( + <braunr> jkoenig: this might just be the same problem as in bash + <braunr> 0x1308000[0x3000] (prot=RW, max_prot=RWX, mem_obj=584) + <braunr> 0x130b000[0x6000] (prot=RW, max_prot=RWX, mem_obj=585) + <braunr> 0x1311000[0x3000] (prot=RX, max_prot=RWX, mem_obj=586) + <braunr> 0x1314000[0x1000] (prot=RW, max_prot=RWX, mem_obj=586) + <braunr> 0x1315000[0x2000] (prot=RX, max_prot=RWX, mem_obj=587) + <braunr> the first two could be merged but not the others + <jkoenig> theoritically, those may correspond to memory objects backed by + different portions of the disk, right? + <braunr> jkoenig: this looks very much like the same issue (many private + mappings not merged) + <braunr> jkoenig: i'm not sure + <braunr> jkoenig: normally there is an offset when the object is valid + <braunr> but vminfo may simply not display it if 0 + * jkoenig goes read about memory object + <braunr> ok, vminfo can't actually tell if the object is anonymous or + file-backed memory + <jkoenig> (I'm perplexed about how the kernel can merge two memory objects + if disctinct port names exist in the tasks' name space -- that's what + mem_obj is, right?) + <braunr> i don't see why + <braunr> jkoenig: can you be more specific ? + <jkoenig> braunr, if, say, 584 and 585 above are port names which the task + expects to be able to access and do stuff with, what will happen to them + when the memory objects are merged? + <braunr> good question + <braunr> but hm + <braunr> no it's not really a problem + <braunr> memory objects aren't directly handled by the vm system + <braunr> vm_object and memory_object are different things + <braunr> vm_objects can be split and merged + <braunr> and shadow objects form chains ending on a final vm_object + <braunr> which references a memory object + <braunr> hm + <braunr> jkoenig: ok no solution, they can't be merged :) + <jkoenig> braunr, I'm confused :-) + <braunr> jkoenig: but at least, if two vm_objects are created but reference + the same externel memory object, the vm should be able to merge them back + <braunr> external* + <braunr> are created as a result of a split + <braunr> say, you map a memory object, mprotect part of it (=split), then + mprotect the reste of it (=merge), it should work + <braunr> jkoenig: does that clarify things a bit ? + <jkoenig> ok so if I get it right, the entries shown by vmstat are the + vm_object, and the mem_obj listed is a send right to the memory object + they're referencing ? + <braunr> yes + <braunr> i'm not sure about the type of the integer showed (port name or + simply an index) + <braunr> jkoenig: another possibility explaining the high number of entries + is how anonymous memory is implemented + <braunr> if every vm_allocate request implies the creation of a memory + object from the default pager + <braunr> the vm has no way to merge them + <jkoenig> and a vm_object is not a capability, but just an internal kernel + structure used to record the composition of the address space + <braunr> jkoenig: not exactly the address space, but close enough + <braunr> jkoenig: it's a container used to know what's in physical memory + and what isn't + <jkoenig> braunr, ok I think I'm starting to get it, thanks. + <braunr> glad i could help + <braunr> i wonder when vm_map_enter() gets null objects though :/ + <braunr> "If this port is MEMORY_OBJECT_NULL, then zero-filled memory is + allocated instead" + <braunr> which means vm_allocate() + <jkoenig> braunr, when the task uses vm_allocate(), or maybe vm_map_enter() + with MEMORY_OBJECT_NULL, there's an opportunity to extend an existing + object though, is that what you referred to earlier ? + <braunr> jkoenig: yes, and that's what is done + <jkoenig> but how does that play out with the default pager? (I'm thinking + aloud, as always feel free to ignore ;-) + <braunr> the default pager backs vm_objects providing zero filled memory + <braunr> hm, guess it wasn't your question + <braunr> well, swap isn't like a file, pages can be placed dynamically, + which is why the offset is always 0 for this type of memory + <jkoenig> hmm I see, apparently a memory object does not have a size + <braunr> are you sure ? + <jkoenig> from what I can gather from + http://www.gnu.org/software/hurd/gnumach-doc/External-Memory-Management.html, + but I looked very quickly + <braunr> vm_objects have a size + <braunr> and each map entry recors the offset within the object where the + mapping begins + <braunr> offset and sizes are used by the kernel when querying the memory + object pager + <braunr> see memory_object_data_request for example + <jkoenig> right. + <braunr> but the default pager has another interface + <braunr> jkoenig: after some simple tests, i haven't seen a simple case + where forward merging could be applied :( + <braunr> which means it's a lot harder than it first looked + <braunr> hm + <braunr> actually, there seems to be cases where this can be done + <braunr> all of them occurring after a first merge was done + <braunr> (which means a mapping request perfectly fits between two map + entries) + + +# IRC, freenode, #hurd, 2011-07-21 + + <braunr> tschwinge: you may remove the forward map entry merging issue :/ + <pinotree> what did you discover? + <braunr> tschwinge: it's actually much more complicated than i thought, and + needs major changes in the vm, and about the way anonymous memory is + handled + <braunr> from what i could see, part of the problem still exists in freebsd + <braunr> for the same reasons (shadow objects being one of them) + + +# GCC build time using bash vs. dash + +<http://gcc.gnu.org/ml/gcc/2011-07/msg00444.html> + + +# Procedure + + * Analyze. + + * Measure. + + * Fix. + + * Measure again. + + * Have Samuel measure on the buildd. diff --git a/open_issues/gnumach_vm_map_red-black_trees.mdwn b/open_issues/gnumach_vm_map_red-black_trees.mdwn new file mode 100644 index 00000000..d7407bfe --- /dev/null +++ b/open_issues/gnumach_vm_map_red-black_trees.mdwn @@ -0,0 +1,174 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-04-23 + + <braunr> btw, i'm running a gnumach version using red-black trees for vm + map entries + <antrik> braunr: sounds fashionable ;-) + <youpi> braunr: with some perf improvement? + <braunr> looks promising for our ext2fs instances showing several thousands + of map entries + <braunr> youpi: i'm not using it for lookups yet + <braunr> but the tree is there, maintained, used for both regular and copy + maps, and it doesn't crash + <youpi> good :) + <braunr> antrik: isn't it ? :) + <braunr> youpi: and the diff stat is like 50/15 + <antrik> braunr: what's the goal of using the fashionable trees? + <braunr> antrik: speeding up lookups in address spaces + <antrik> braunr: so the idea is that if we have a heavily fragmented + address space, the performance penalty is smaller? + <braunr> yes + <antrik> OK + <antrik> I take it you gave up on attempts to actually decrease + fragmentation?... + <braunr> it's not as good as reducing fragmentation, which requires + implementing a powerful merge, but it's still better + <braunr> yes + <braunr> it's too messy for my brain :/ + <antrik> I see + <antrik> oh + <braunr> it will add some overhead though + <youpi> I guess log(n) ? + <braunr> but if there is a significant performance gain, it'll be worth it + <braunr> yes + <braunr> i was more thinking about the memory overhead + <antrik> right now it's a linear list? + <youpi> I don't think we care nowadays :) + <braunr> antrik: yes + <antrik> ouch + <braunr> antrik: yes ... :> + <braunr> the original authors expected vm maps to have like 30 entries + <braunr> so they used a list for the maps, and a hash table for the + object/offset to physical page lookups + <braunr> there is a small lookup cache though, which is a nice optimization + <braunr> my code now uses it first, and falls back to the RB tree if the + hint didn't help + <antrik> braunr: well, don't forget to check whether it actually *is* still + an optimisation, when using fashionable trees ;-) + <braunr> antrik: i checked that already :) + <braunr> i did the same in x15 + <antrik> I see + <braunr> both bsd and linux uses a similar technique + <braunr> use* + <braunr> (well, bsd actually use what is done in mach :) + <antrik> (or perhaps the other way around... ;-) ) + <braunr> i don't think so, as the bsd vm is really the mach vm + <braunr> but we don't care much + <antrik> oh, right... that part actually went full circle + <braunr> youpi: i have a patch ready for test on machines with significant + amounts of map entries (e.g. the buildds ..) + <braunr> youpi: i won't have time for tests tonight, are you interested ? + <braunr> (i've been running it for 15 minutes without any issue for now) + <youpi> I'd say post to the list + <braunr> ok + <youpi> braunr: your patch uses the rb tree for lookups, right? + <youpi> braunr: the buildd using rbtree seems swift + <youpi> but maybe it's just a psychologic effect :) + <youpi> the chroot ext2fs already has 1392 lines in vminfo + <youpi> an rbtree can't hurt there :) + <youpi> braunr: it really seems faster + <youpi> the reboot might have helped too + <youpi> benchmarks shall say + <youpi> for now, I'll just let ironforge use it + <antrik> youpi: it's always fast after a reboot ;-) + <youpi> sure + <youpi> but still + <youpi> I mean + <youpi> *obviously* the reboot has helped + <youpi> but it might not be all + <youpi> at least it feels so + <youpi> and obviously only benchmarks can say + <antrik> the major benefit AIUI is rather that the slowdown happening over + time will be less noticable + +[[performance/degradation]]. + + <youpi> "over time" is actually quite fast + <youpi> ext2 fills up very quickly when you build a package + <youpi> it went up to 1700 lines very quickly + <youpi> and stabilized around there + <antrik> yeah, it can be very fast under heavy load + <youpi> that's why I say reboot seems not all + <youpi> it's already not so fresh + <youpi> with 1700 lines in vminfo + <antrik> well, I don't know how much of the slowdown I'm experiencing + (after doing stuff under memory pressure) is actually related to VM map + fragmentation... + <antrik> might be all, might be none, might be something in between + <youpi> then try his patch + <antrik> guess I should play a bit with vminfo... + <antrik> well, currently I actually experience pretty little slowdown, as + for certain reasons (only indirectly related to the Hurd) I'm not running + mutt on this machine, so I don't really have memory pressure... + + +## IRC, freenode, #hurd, 2012-04-24 + + <braunr> youpi: yes, it uses bst lookups + <braunr> youpi: FYI, the last time i checked, one ext2fs instance had 4k+ + map entries, and another around 7.5k + <braunr> (on ironforge) + + +## IRC, freenode, #hurd, 2012-04-24 + + <youpi> braunr: $ sudo vminfo 624 | wc -l + <youpi> 22957 + <youpi> there's no way it can not help :) + <braunr> youpi: 23k, that's really huge + + +## IRC, freenode, #hurd, 2012-04-26 + + <braunr> youpi: any new numbers wrt the rbtree patch ? + <youpi> well, buildd times are not really accurate :) + <youpi> but what I can tell is that it managed to build qtwebkit fine + <braunr> ok + <youpi> so the patch is probably safe :) + <braunr> i'll commit it soon then + <youpi> I'd say feel free to, yes + <braunr> thanks + + +## IRC, freenode, #hurd, 2012-04-27 + + <braunr> elmig: don't expect anything grand though, this patch is mostly + useful when address spaces get really fragmented, which mainly happens on + buildds + <braunr> (and it only speeds lookups, which isn't as good as reducing + fragmentation; things like fork still have to copy thousands of map + entries) + +[[glibc/fork]]. + + +## IRC, freenode, #hurdfr, 2012-06-02 + + <youpi> braunr: oh, un bug de rbtree + <youpi> Assertion `diff != 0' failed in file "vm/vm_map.c", line 1002 + <youpi> c'est dans rbtree_insert() + <youpi> vm_map_enter (vm/vm_map.c:1002). + <youpi> vm_map (vm/vm_user.c:373). + <youpi> syscall_vm_map (kern/ipc_mig.c:657). + <youpi> erf j'ai tué mon débuggueur, je ne peux pas inspecter plus + <youpi> le peu qui me reste c'est qu'apparemment target_map == 1, size == + 0, mask == 0 + <youpi> anywhere = 1 + <braunr> youpi: ça signifie sûrement que des adresses overlappent + <braunr> je rejetterai un coup d'oeil sur le code demain + <braunr> (si ça se trouve c'est un bug rare de la vm, le genre qui fait + crasher le noyau) + <braunr> (enfin jveux dire, qui faisait crasher le noyau de façon très + obscure avant le patch rbtree) diff --git a/open_issues/gnumach_vm_object_resident_page_count.mdwn b/open_issues/gnumach_vm_object_resident_page_count.mdwn new file mode 100644 index 00000000..cc1b8897 --- /dev/null +++ b/open_issues/gnumach_vm_object_resident_page_count.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-07-03 + + <braunr> omg the ugliness + <braunr> the number of pages in physical memory for on object is a short + ... which limits the amount to .. 128 MiB + * braunr cries + <braunr> luckily, this should be easy to solve + +`vm/vm_object.h:vm_object:resident_page_count`. diff --git a/open_issues/grub_legacy.mdwn b/open_issues/grub_legacy.mdwn deleted file mode 100644 index cb69d10b..00000000 --- a/open_issues/grub_legacy.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -[[!meta copyright="Copyright © 2005, 2009 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="GRUB (legacy)"]] - -[[!tag open_issue_porting]] - -Even though it is customarily used *for* booting GNU/Hurd systems, [[GRUB]], -specifically GRUB legacy (which is still in wide-spread use, despite that -rather depricative nickname), has never been ported to be installable when -attempted to be installed *from* GNU/Hurd systems: - - # grub-install \(hd0\) - df: Warning: cannot read table of mounted filesystems - df: Warning: cannot read table of mounted filesystems - Could not find device for /boot: Not found or not a block device. - -There is a patch, [[grub-install.patch]], to fix that. - - -`grub-install`, however, still fails while invoking `grub`: - - # grub-install \(hd0\) - The file /boot/grub/stage1 not read correctly. - - # grub - [...] - grub> dump (hd0,0)/boot/grub/stage1 /tmp/grub_stage1 - - Error 18: Selected cylinder exceeds maximum supported by BIOS - - -The successor, [[GRUB2]], also needs to be ported. diff --git a/open_issues/grub_legacy/grub-install.patch b/open_issues/grub_legacy/grub-install.patch deleted file mode 100644 index 3f6341b4..00000000 --- a/open_issues/grub_legacy/grub-install.patch +++ /dev/null @@ -1,23 +0,0 @@ -2005-08-23 Thomas Schwinge <tschwinge@gnu.org> - - * grub-install (find_device): Rough port for GNU/Hurd. - - ---- grub-install.orig 2005-08-23 16:56:02.000000000 +0200 -+++ grub-install 2005-08-23 17:01:55.000000000 +0200 -@@ -263,7 +263,14 @@ - find_device () { - # For now, this uses the program `df' to get the device name, but is - # this really portable? -- tmp_fname=`df $1/ | sed -n 's%.*\(/dev/[^ ]*\).*%\1%p'` -+ # No. (Not even on GNU/Linux.) - Thomas Schwinge -+ -+ case $host_os in -+ gnu*) # TODO: What about using multiple devices? -+ tmp_fname=`fsysopts $1/ | sed -n 's%.*device:\([^ ]*\).*%/dev/\1%p'`;; -+ *) -+ tmp_fname=`df $1/ | sed -n 's%.*\(/dev/[^ ]*\).*%\1%p'`;; -+ esac - - if test -z "$tmp_fname"; then - echo "Could not find device for $1" 2>&1 diff --git a/open_issues/hurd_101.mdwn b/open_issues/hurd_101.mdwn new file mode 100644 index 00000000..6146885d --- /dev/null +++ b/open_issues/hurd_101.mdwn @@ -0,0 +1,41 @@ +[[!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]]."]]"""]] + +(See Wikipedia page for the meaning of [[!wikipedia "101_(term)"]].) + +Not the first time that something like this is proposed... + +IRC, freenode, #hurd, 2011-07-25 + + [failed GNU/Hurd project] + < antrik> gnu_srs1: I wouldn't say he was on track. just one of the many + many people who insist on picking a hard task; realizing that indeed it's + hard; and going into hiding + < antrik> we see that happen every couple of months + < cluck> maybe we need a "hurd 101" + < cluck> getting a teacher and setting up a regularly held "class" for hurd + noobs + < Tekk_> cluck: what would that include? + < cluck> explaining core concepts, giving out "homework" (small tasks), etc + +[[Anatomy_of_a_Hurd_system]]. + + < cluck> that way "the big guys" could focus on the hard stuff and have an + army of code monkeys at their disposal to write speced stuff + < cluck> (then again this idea would heavily depend on available "teachers" + and "students", which, going by gsoc numbers, may not be all that + helpful) + < Tekk_> cluck: gsoc isn't an accurate indicator + < Tekk_> cluck: I'm not allowed to participate in gsoc but I'd join :P + < antrik> cluck: we don't need code monkeys... we need hackers + < Tekk_`> antrik: code monkeys involve into hackers + < Tekk_`> under the right conditions + < cluck> antrik: jokes aside some sort of triage system/training ground for + newcomers could be helpful diff --git a/open_issues/hurd_build_without_parted.mdwn b/open_issues/hurd_build_without_parted.mdwn new file mode 100644 index 00000000..06ecf56d --- /dev/null +++ b/open_issues/hurd_build_without_parted.mdwn @@ -0,0 +1,16 @@ +[[!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]] + +Seen with `cross-gnu`. + +If the *parted* libraries aren't available, we explicitly have to set +`--without-parted` or the build will fail. diff --git a/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn b/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn new file mode 100644 index 00000000..b1eaf9a5 --- /dev/null +++ b/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, #hurd, 2009-08-25 + + <cfhammar> also I fixed (what I think is) a bug in hurd_file_name_lookup_retry when opening FDs with FS_RETRY_MAGIC + <cfhammar> it didn't actually reopen the FD, rather it just (effectively) duped it + <scolobb> cfhammar: That's great! I think I had some problems because of not being able to truly reopen a port to a file. + <antrik> cfhammar: what is the difference, and why do you consider it a bug?... + <cfhammar> antrik: for one thing you can't change open modes, and it doesn't reset the file cursor + <cfhammar> (which I actually needed, though I could have done it manually) + <cfhammar> antrik: and also it isn't consistant with linux + <cfhammar> you can trigger the bug from the shell: cat /dev/fd/3 3>> /tmp/foo + <antrik> cfhammar: I can't say that I understand the test case... but I can at least confirm that it behaves differently on Hurd and on Linux :-) diff --git a/open_issues/hurdextras.mdwn b/open_issues/hurdextras.mdwn new file mode 100644 index 00000000..f31802da --- /dev/null +++ b/open_issues/hurdextras.mdwn @@ -0,0 +1,87 @@ +[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +This is about merging some hurdextras stuff into Hurd proper repostitories. + +[[!toc levels=2]] + + +# OK + +## mboxfs + +Tarball-import, plus trivial changes. + + * Ludovic Courtes -- OK + * mmenal -- OK + +## notice + +Tarball-import. + + * Wolfgang Jährling <wolfgang@pro-linux.de> -- OK + +## run + +Tarball-import. + + * Marcus Brinkmann <marcus@gnu.org> -- OK + * Manuel Menal <mmenal@hurdfr.org> -- OK + + +# Not Interesting + +## procfs + +Not interesting anymore, but perhaps import for posterity? Likewise for Neal's +tarball(s). + + +# Not OK + +## httpfs + + * Arun V. <arunsark@yahoo.com> -- NOK + * Gopika U. K. <gopika78@yahoo.com> -- NOK + * mrphython / James A. Morrison <ja2morri@uwaterloo.ca> -- OK + +## jfs + + * Sajith T S <sajith@symonds.net> -- NOK + * mmenal / Manuel Menal <mmenal@hurdfr.org> -- OK + +## memfs + + * Farid Hajji <farid.hajji@ob.kamp.net> -- NOK + * Ludovic Courtes <ludo@chbouib.org> -- OK + * mmenal -- OK + +## pith + +[[tschwinge]] has some tarballs, too. + + * John Tobey <jtobey@john-edwin-tobey.org> -- NOK + * Manuel Menal <mmenal@hurdfr.org> -- OK + +## pptop + + * Miles Bader -- OK + * Paul Emsley <paule@chem.gla.ac.uk> -- NOK + * James Morrison -- OK + * Neal Walfield -- OK + * Jon Arney <jarney1@cox.net> -- OK + * Alfredo Beaumont Sainz <alfredo.beaumont@gmail.com> -- NOK (but trivial) -- OK + +## xmlfs + +Tarball-import. + + * Marc de Saint Sauveur <marc@hurdfr.org> -- NOK + * mmenal -- OK diff --git a/open_issues/ifunc.mdwn b/open_issues/ifunc.mdwn new file mode 100644 index 00000000..c357c99c --- /dev/null +++ b/open_issues/ifunc.mdwn @@ -0,0 +1,49 @@ +[[!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 +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_binutils open_issue_gcc open_issue_glibc]] + +Needs porting / support in [[/binutils]] and [[/glibc]], and then some target +configure magic for [[/GCC]]. + +<http://nickclifton.livejournal.com/6612.html> has a short summary about how to +use it from GCC. + + * binutils + + Already passes the ifunc testsuite bits for GAS, but notably for LD + (`ld/testsuite/ld-ifunc/ifunc.exp`), too, but that one contains a bunch of + stuff explicitly tailored towards Linux. For example, we get *OS/ABI: UNIX + - Linux*. (This should be fixed through using [[toolchain/ELFOSABI_GNU]].) + + Most of the executables that the testsuite generates don't actually + execute. (Though, this is partly due to the [[static + issue|binutils#static]].) + + $ tmpdir/local_prog + ifunc working correctly + $ tmpdir/static_prog + Killed + $ tmpdir/dynamic_prog + tmpdir/dynamic_prog: error while loading shared libraries: ./tmpdir/libshared_ifunc.so: ELF file OS ABI invalid + $ tmpdir/static_nonifunc_prog + Killed + $ tmpdir/test-1 + tmpdir/test-1: error while loading shared libraries: tmpdir/libshared_ifunc.so: ELF file OS ABI invalid + + * [[glibc]] + + * [[libc_variant_selection]] + + * [[GCC]] + + In `gcc/config.gcc`, set `default_gnu_indirect_function=yes` for us, like + done for GNU/Linux. See thread starting at [[!message-id + "CAFULd4YZsAQ6ckFjXtU5-yyv=3tYQwTJOPhU9zmJxFOrnotj8g@mail.gmail.com"]]. diff --git a/open_issues/implementing_hurd_on_top_of_another_system.mdwn b/open_issues/implementing_hurd_on_top_of_another_system.mdwn new file mode 100644 index 00000000..95b71ebb --- /dev/null +++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn @@ -0,0 +1,117 @@ +[[!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 +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]] + +It is possible to run Hurd stuff on top of another system instead of on Mach. +One obvious variant is [[emulation]] (using [[hurd/running/QEMU]], for +example), but +doing that does not really integratable the Hurd guest into the host system. +There is also a more direct way, more powerful, but it also has certain +requirements to do it effectively: + +IRC, #hurd, August / September 2010 + + <marcusb> silver_hook: the Hurd can also refer to the interfaces of the + filesystems etc, and a lot of that is really just server/client APIs that + could be implemented on any system that has transferable rights to + message capabilities. + <marcusb> silver_hook: it's surprising how few systems *have* transferable + rights, though! + <marcusb> silver_hook: usually it is added as an afterthought + <marcusb> and comes with restriction + <youpi> marcusb: there's SCM_RIGHTS to transfer fds, which is quite often + available + <marcusb> youpi: yes, I know this as "fdpassing" + <marcusb> youpi: it's described in the Stevens series even + [...] + <marcusb> ArneBab: well, let me put it this way. the Linux kernel has no + interface to manipulate another tasks's virtual address space, ie you + can't map/unmap stuff in another process + <marcusb> ArneBab: you would have to use ptrace and load some stub code in + that process to make that happen. + <marcusb> ArneBab: so for complete transparent manipulation, you need a + kernel module + <marcusb> that is what the User Mode Linux kernel module does + <marcusb> ArneBab: so say you use the User Mode Linux kernel module for + that one feature. Then you can do everything that User Mode Linux can + do, which, I assure you, includes running subhurds :) + <marcusb> it can be a bit tricky to implement those features, but it is not + harder than writing a kernel in the first place + <ArneBab> So, if I got an admin to install User Mode Linux and Mach + emulation, I’d get the flexibility (and independence from admin + decisions) I have in the Hurd? + <marcusb> ArneBab: one problem is that you still use Linux. For those who + want to get rid of Linux for political reasons, that would mean complete + failure + <marcusb> ArneBab: if you have UML kernel module, you can implement Mach in + user space + <marcusb> ArneBab: in fact, John Tobey did this a couple of years ago, or + started it + +([[tschwinge]] has tarballs of John's work.) + + <marcusb> ArneBab: or you can just implement parts of it and relay to Linux + for the rest + <marcusb> the point is, that if you don't care for kernel improvements, and + are sufficiently happy with the translator stuff, it's not hard to bring + the Hurd to Linux or BSD + +Continue reading about the [[benefits of a native Hurd implementation]]. + +--- + +IRC, #hurd, 2010-12-28 + + <antrik> kilobug: there is no real requirement for the Hurd to run on a + microkernel... as long as the important mechanisms are provided (most + notably external pagers and Mach IPC), the Hurd could run an top of + pretty much any kernel... + <antrik> whether it makes sense is another question of course :-) + <antrik> though I must say that I'm more and more convinced running the + Hurd on top of a monolithic kernel would actually be a useful approach + for the time being... + +--- + +IRC, #hurd, 2011-02-11 + + <neal> marcus and I were discussing how to add Mach to Linux + <neal> one could write a module to implement Mach IPC + <neal> and another to implement Mach VM + <neal> the big thing missing with Mach VM is the ability for a tracing + process to easily map or unmap an inferior process's memory + <antrik> neal: why would a tracing process need to map the inferior's + memory? + <neal> the simple answer is that is how it is done on Mach + <antrik> neal: is it? not sure we are talking about the same thing + here. GDB uses vm_read()/vm_write() to access the inferior's memory AFAIK + <neal> on linux? + <neal> I think it use /proc/pid/mem + <antrik> on Hurd + <neal> I'm talking about adding Mach to Linux + <neal> by adding some functionality to Linux + <neal> and then implementing a bunch in user space + <antrik> yeah, but I don't understand the point about mapping inferior's + memory :-( + <antrik> what would be in user space? + <neal> there are a number of different cut points + <neal> one could imagine just using Linux's device drivers, CPU scheduler, + memory management, etc. + <neal> another possibility would be something higher where Hurd processes + just use some Hurdish servers + <antrik> neal: yeah, these are all options I have been considering... too + bad I wasn't able to come to FOSDEM -- I'd love to have participated in + this discussion :-( + <antrik> neal: BTW, were you just discussing this as a hypothetical idea, + or something you are seriously considering? + <neal> I'm unlikely to work on it, sorry + <antrik> didn't really expect that :-) + <antrik> would be nice though if you could write up your conclusions... diff --git a/open_issues/inotify_file_notice_changes.mdwn b/open_issues/inotify_file_notice_changes.mdwn new file mode 100644 index 00000000..6d644788 --- /dev/null +++ b/open_issues/inotify_file_notice_changes.mdwn @@ -0,0 +1,47 @@ +[[!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]]."]]"""]] + +IRC, freenode, #hurd, 2011-03-28 + +[[!tag open_issue_hurd]] + + <barrucadu> I've been going through the xmlfs code, and plan to have it + monitor the backing store (xml file) for changes and update the presented + directory hierarchy when something is changed; is there a better way to + check a file for changes beyond checking its modification time every few + minutes? + <tschwinge> barrucadu: In the Hurd spirit, you'd use file_notice_changes + (fs.defs). + <barrucadu> thanks + <youpi> we should manage to work out an inotify interface around it, btw + <pochu> like gamin? + <pinotree> imho making gamin work should gain all the fam-using + applications + <pochu> (which, looking at the sources, seems to support hurd already, not + sure why it's not built) + <pinotree> pochu: the hurd_notify of gamin does not build OOTB + <pochu> > /build/buildd/gamin-0.1.10/./libgamin/gam_data.c:476: error: + 'PTHREAD_MUTEX_RECURSIVE' undeclared (first use in this function) + <pinotree> there are few patches in bugzilla to make it compile + <pochu> if they work, and you point me to them, I can upload a new gamin + with them included + <pinotree> #315644, #588337. #605246 + <pinotree> and iirc there's something else i have locally but not send yet + <pochu> please check and submit :) + <pinotree> ah no, those three contains all the build issues + <pinotree> .. plus relative proposed fixes + <pochu> ok, I'll try to get to it soonish + <pinotree> and you should know about two of them already ;D + <pochu> please remind me if I don't :) + +--- + +Apparently fanotify is cosidered inotify's successor, so we might directly go +supporting that one instead, or both. --[[tschwinge]], 2011-05-10 diff --git a/open_issues/issue_tracking.mdwn b/open_issues/issue_tracking.mdwn new file mode 100644 index 00000000..72bb3b77 --- /dev/null +++ b/open_issues/issue_tracking.mdwn @@ -0,0 +1,196 @@ +[[!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]] + + +# Savannah Trackers, Open Issues, debbugs + +There are the Savannah trackers. Nobody really likes them. + +There is a proposal to add/move to <http://debbugs.gnu.org/>. It can be +operated by email, Debian people (developers and users) already know how to use +it. + +There are the [[Open_Issues]] pages. This is basically just free-form text +enriched by some tags for grouping, editable via the web and through Git +commit. [[tschwinge]] added this to the set, and/but mostly is the sole user +of it, even though casually there are a few other people contributing, and +surely these pages do show up in web searches. A more traditional system (like +the Savannah trackers or the new debbugs) do have their advantages, too, so +perhaps there's a niche for both these and the [[Open_Issues]]. + +IRC, freenode, #hurd, 2011-08-31: + + <tschwinge> So. Savannah trackers vs. Open Issues vs. debbugs. Any input? + <youpi> I like *both* open issues and debbugs + <youpi> open issues is good for exposing things that people may encounter + in other situations + <youpi> while debbugs is useful to actually work on a bug + <tschwinge> youpi: The advantage of debbugs being the email interface and + the well-known procedure, or something else? + <youpi> email interface, which nicely flows into a mailing list + <youpi> the savannah bug updates suffer from the additional layout + <tschwinge> How does one decide what to put in a debbug and what in an Open + Issue page? + <youpi> I'd say it's not exclusive at all + <youpi> like, a bug on a specific case can start as debbug, and as we + discover it's more general and will not be fixed immediately, get an open + issue page + <youpi> and conversely, when we know some shortcoming, start with an open + issue, and if some bugs are submitted which are actually due to it, + cross-link + <tschwinge> OK. + <youpi> (some general short coming I mean, like SIGINFO) + <tschwinge> And we would keep the current stuff in the trackers, and let + these ``get empty'' gradually (it'll be years...) ;-) or migrate the + remaining issues? + <tschwinge> What we can do is inhibiting the creation of new issues in the + trackers. + <youpi> I'd say move + <youpi> else they will be forgotten + <tschwinge> Hrm. + <antrik> actually, I considered creating a track-like plugin for ikiwiki, + as both the popularity of trac and the usefulness of open_issues show + that something wiki-like is actually more useful than a rigid traditional + bugtracker. but I'm not really willing to do the work, which is why I + didn't propose it before :-) + <antrik> err... trac-like + <youpi> yes, the wiki part is really useful to keep a good summary of the + issue + <tschwinge> antrik: Same for me. I always hoped that someone would do + it... :-) + <antrik> hehe + <tschwinge> antrik: But, as you surely know, this email parsing business is + just too ugly to do realiable, etc. + <antrik> youpi: my point is that adding a few additional bits (like a + comfortable tagging functionality, and some mail interface) could turn + into a full-blown tracker unifying the advantages of both... but as I + said, I'm not really willing to do the work :-) + <youpi> additional to open_issue you mean? + <youpi> yes, but like you say :) + <antrik> tschwinge: hm... seems to work well enough it debbugs + <youpi> debbugs just piles things + <youpi> and has a few commands + <youpi> you'd still need the web interface to edit the wiki part for + instance + <antrik> of course. that wouldn't change at all + <antrik> (except for adding a tagging GUI perhaps) + <antrik> (debbugs of course is not the only mail-operable bugtracking + system... there are a number of others -- and I heard rumors even + bugzilla grew a mail interface now...) + <youpi> antrik: a .mdwn diff should however be sent to the bug for + information + <youpi> atm, what happens sometimes is somebody saying something here on + #hurd, tschwinge turning that into an open_issue, and it does not show up + on the mailing list + <tschwinge> debbugs surely has the advantage that it is available (nearly) + right now. + <mattl> RT (request tracker) and ikiwiki play quite nicely together. + <tschwinge> mattl: You'Re using that at GNU/FSF/somewhere, right? + <mattl> you can close tickets from the wiki, and RT has a good command line + interface, email interface and web interface. + <mattl> tschwinge: yeah, we use RT and ikiwiki. + <mattl> RT for all FSF communications, and ikiwiki for internal organising. + <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 + + * ikiwiki + + * <http://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/> + + * <http://ikiwiki.info/todo/Better_bug_tracking_support/> + + * <http://ikiwiki.info/todo/tracking_bugs_with_dependencies/> + + * <http://ikiwiki.info/todo/Updated_bug_tracking_example/> + + * <http://bugseverywhere.org/> diff --git a/open_issues/keymap_mach_console.mdwn b/open_issues/keymap_mach_console.mdwn new file mode 100644 index 00000000..3063dd00 --- /dev/null +++ b/open_issues/keymap_mach_console.mdwn @@ -0,0 +1,40 @@ +[[!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]]."]]"""]] + +IRC, freenode, #hurd, 2011-04-26 + + <guillem> pavkac: btw are you aware there's already some code to change the + keymap for the mach console (I think originally from the hurdfr guys, but + I cannot remember exactly from where I got it from :/) + <guillem> pavkac: http://www.hadrons.org/~guillem/tmp/hurd-keymap.tgz + <pavkac> guillem: No, I didn't know. I'll diff it and try to follow. + <guillem> pavkac: it would be nice to maybe integrate it properly into the + hurd + <guillem> you'll see the code is pretty basic, so extending it would be + nice too I guess :) + <pavkac> guillem: OK, I'll see to it. Unfortunately I'm quite busy this + week. Have a lot of homeworks to school. :/ + <pavkac> guillem: But, I'll find some time during weekend. + <youpi> maybe it'd be simpler to add it to the hurd package and use that + from the console-setup package indeed + <youpi> but copyright issues should be solved + <youpi> unless we simply put this into hurdextras + <guillem> ok found this: + http://www.mail-archive.com/debian-hurd@lists.debian.org/msg02456.html + <guillem> and + http://www.mail-archive.com/debian-hurd@lists.debian.org/msg01173.html + <guillem> which seems to be the original Mark's code + <guillem> AFAIR I contributed the the spanish keymap and some additional + key definitions for loadkeys + <guillem> and http://lists.debian.org/debian-hurd/2000/10/msg00130.html + <pavkac> I've fetched all. :) But I must leave, good night if you're in + Europe. :) + <guillem> pavkac: the tarball I provided should be the latest, the others + are mostly to track the provenance of the source diff --git a/open_issues/kvm.mdwn b/open_issues/kvm.mdwn new file mode 100644 index 00000000..6dfffc9a --- /dev/null +++ b/open_issues/kvm.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Issues when running Hurd under KVM: un-synced filesystems, etc. No problems +with Virtualbox. + +2010-07-28, #hurd + + <youpi> pochu: you were the one reporting issues with qemu/kvm and hurd, right? + <youpi> is your machine somehow smp (like multicore for instance) + <youpi> ? + <pochu> youpi: yes, it's a Core 2 Duo + <pochu> so 2 cores + <youpi> ok, you might want to try to bind qemu/kvm + <youpi> e.g. install hwloc, and prepend "hwloc-bind 1 --" before the qemu/kvm command line + <pochu> ok, ty + +2010-07-31, GNU Mach commit 039176372b4271f370ef38eb2ee5d43923a5b28b. diff --git a/open_issues/largefile.mdwn b/open_issues/largefile.mdwn new file mode 100644 index 00000000..a6f76a0e --- /dev/null +++ b/open_issues/largefile.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-04-26 + + <pinotree> i kind of understood why (at least in some parts) largefile doesn't seem to work properly + <pinotree> libdiskfs/io-seek.c, SEEK_SET case: cred->po->filepointer = offset; + <pinotree> offset is off_t, which becomes off64_t when compiled with largefile, but filepointer seems to be... int + <pinotree> at least in libdiskfs/diskfs.h, while in libnetfs/netfs.h seems ok (loff_t) + <pinotree> diskfs.h is a public header though :/ + <youpi> well, we can change the soname to mark ABI change diff --git a/open_issues/latrace.mdwn b/open_issues/latrace.mdwn new file mode 100644 index 00000000..b5a2928c --- /dev/null +++ b/open_issues/latrace.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Check whether <http://people.redhat.com/jolsa/latrace/> works. diff --git a/open_issues/lexical_dot-dot.mdwn b/open_issues/lexical_dot-dot.mdwn new file mode 100644 index 00000000..3299dfa0 --- /dev/null +++ b/open_issues/lexical_dot-dot.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]]."]]"""]] + +[[!meta title="Lexical .. Resolution"]] + +[[!tag open_issue_glibc open_issue_hurd]] + +There is a [[!FF_project 279]][[!tag bounty]] on this task. + + +# Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/lexical_dot-dot feeds=no]] diff --git a/open_issues/libasyncns.mdwn b/open_issues/libasyncns.mdwn new file mode 100644 index 00000000..bbd34bff --- /dev/null +++ b/open_issues/libasyncns.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +IRC, unknown channel, unknown date. + + <pinotree> tschwinge: btw, would you be able to tell if and what's wrong with a socket-related problem? + <pinotree> it is reproducible with a very small self-contained C library + <pinotree> http://0pointer.de/lennart/projects/libasyncns/ + <pinotree> it has a test case with it, which fails + <pinotree> tschwinge: if that can ring some bell, imho the problem is related to SOCK_STREAM sockets created with socketpair and used with send/recv diff --git a/open_issues/libc_variant_selection.mdwn b/open_issues/libc_variant_selection.mdwn new file mode 100644 index 00000000..afcd9ae0 --- /dev/null +++ b/open_issues/libc_variant_selection.mdwn @@ -0,0 +1,34 @@ +[[!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 +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_porting]] + +There is a [[!FF_project 274]][[!tag bounty]] on this task. + +There are now specialized variants of Debian's libc package, libc0.3-i686 and +libc0.3-xen. + + +On Thu, Oct 07, 2010 at 11:22:46AM +0200, Samuel Thibault wrote: +> Thomas Schwinge, le Thu 07 Oct 2010 10:11:07 +0200, a écrit : +> > Also, this text says ``will be selected instead when running under Xen'' +> > -- is this meant to be automatically done? +> +> It's supposed to be, we need to add support for it. +> +> > If so, then it didn't work. +> +> Yes, you need to copy it by hand. Same for libc0.3-i686, we just need to +> steal the cpuid code from the kfreebsd port of glibc. + +--- + +Having working CPUID code inside [[glibc]] is also a prerequisite for proper +[[IFUNC]] support. diff --git a/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn b/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn new file mode 100644 index 00000000..1e4a6acb --- /dev/null +++ b/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <tschwinge> By the way: your libdiskfs ., .. fix -- is that relevant for libnetfs as well? (Didn't look it up so far.) + <youpi> it could be a good idea to protect netfs users directly from there yes + <tschwinge> But probably the backend (e.g., NFS server) would protect us in the netfs case, right? + <youpi> possibly, but we could have locking issues in between like in libdiskfs + <youpi> and POSIX says it's invalid anyway + <youpi> so we'd probably better just forbid it diff --git a/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn b/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn new file mode 100644 index 00000000..817dac76 --- /dev/null +++ b/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_libpthread]] + +IRC, unknown channel, unknown date: + + <azeem> neal: libgomp (GNU's implementation of OpenMP) uses PTHREAD_STACK_MIN, which we do not define apparently + <neal> azeem: We have fixed sized stacks. + <neal> so the pthread_attr_setstacksize will fail once you define PTHREAD_STACK_MIN) diff --git a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn new file mode 100644 index 00000000..80fc9fcd --- /dev/null +++ b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn @@ -0,0 +1,106 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_hurd]] + +[[!toc]] + + +# bug-hurd discussion. + + +# IRC, freenode, #hurd, 2010-08-12 + + <jkoenig> Looking at hurd.git, shouldn't {hurd,include}/Makefile's "all" + target do something, and shouldn't pretty much everything depend on them? + As it stands it seems that the system headers are used and the + potentially newer ones never get built, except maybe on "install" (which + is seemingly never called from the top-level Makefile) + <jkoenig> I would fix it, but something tells me that maybe it's a feature + :-) + <antrik> jkoenig: the headers are provided by glibc, along with the stubs + <jkoenig> antrik, you mean, even those built from the .defs files in hurd/ + ? + <antrik> yes + <jkoenig> oh, ok then. + <antrik> as glibc provides the stubs (in libhurduser), the headers also + have to come from there, or they would get out of sync + <jkoenig> hmm, shouldn't glibc also provide /usr/share/msgids/hurd.msgids, + then? + <antrik> jkoenig: not necessarily. the msgids describe what the servers + actually understand. if the stubs are missing from libhurduser, that's no + reason to leave out the msgids... + <jkoenig> ok this makes sense + + +# IRC, OFTC, #debian-hurd, 2011-09-29 + + <tschwinge> pinotree: I don't like their existence. IMO (but I haven't + researched this in very much detail), every user of RPC stubs should + generated them for themselves (and glibc should directly include the + stubs it uses internally). + <pinotree> sounds fair + <pinotree> maybe they could be moved from glibc to hurd? + <tschwinge> pinotree: Yeah; someone needs to research why we have them (or + if it's only convenience), and whether we want to keep them. + <pinotree> you could move them to hurd, leaving them unaltered, so binary + compatibility with eventual 3rd party users is not broken + <pinotree> but those using them, other than hurd itself, won't compile + anymore, so you fix them progressively + + +# IRC, freenode, #hurd, 2011-11-16 + + <braunr> is the mach_debug interface packaged in debian ? + <antrik> what mach_debug interface? + <braunr> include/include/mach_debug/mach_debug.defs in gnumach + <braunr> include/mach_debug/mach_debug.defs in gnumach + <antrik> what exactly is supposed to be packaged there? + <braunr> i'm talking about the host_*_info client code + <antrik> braunr: you mean MIG-generated stubs? + <braunr> antrik: yes + <braunr> i wrote a tiny slabinfo tool, and rpctrace doesn't show the + host_slab_info call + <braunr> do you happen to know why ? + <antrik> braunr: doesn't show it at all, or just doesn't translate? + <braunr> antrik: doesn't at all, the msgids file contains what's needed to + translate + <braunr> btw, i was able to build the libc0.3 packages with a kernel using + the slab allocator today, while monitoring it with the aforementioned + slabinfo tool, everything went smoothly + <antrik> great :-) + <braunr> i'll probably add a /proc/slabinfo entry some day + <braunr> and considering the current state of our beloved kernel, i'm + wondering why host_*_info rpcs are considered debugging calls + <braunr> imo, they should always be included by default + <braunr> and part of the standard mach interface + <braunr> (if the rpc is missing, an error is simply returned) + <antrik> I guess that's been inherited from original Mach + <antrik> so you think the stubs should be provided by libmachuser? + <braunr> i'm not sure + <antrik> actually, it's a bit arguable. if interfaces are not needed by + libc itself, it isn't really necessary to build them as part of the libc + build... + <braunr> i don't know the complete list of potential places for such calls + <antrik> OTOH, as any updates will happen in sync with other Mach updates, + it makes sense to keep them in one place, to reduce transition pain + <braunr> and i didn't want to imply they should be part of libc + <braunr> on the contrary, libmachuser seems right + <antrik> libmachuser is part of libc + <braunr> ah + <braunr> :) + <braunr> why so ? + <antrik> well, for one, libc needs the Mach (and Hurd) stubs itself + <antrik> also, it's traditionally the role of libc to provide the call + wrappers for syscalls... so it makes some sense + <braunr> sure, but why doesn't it depend on an external libmachuser instead + of embedding it ? + <braunr> right + <antrik> now that's a good question... no idea TBH :-) diff --git a/open_issues/libnetfs_io_map.mdwn b/open_issues/libnetfs_io_map.mdwn new file mode 100644 index 00000000..dc6da202 --- /dev/null +++ b/open_issues/libnetfs_io_map.mdwn @@ -0,0 +1,42 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="libnetfs: io_map"]] + +[[!tag open_issue_hurd]] + +This hampers [[hurd/translator/nfs]] usability, for example: + + $ fsysopts ./ + /hurd/nfs [...] + $ cp -a /bin/true ./ + cp: failed to preserve authorship for `./true': Operation not supported + $ ./true + $ /lib/ld.so /bin/true + $ /lib/ld.so $PWD/true + [...]/true: error while loading shared libraries: [...]/true: failed to map segment from shared object: Error 1073741869 + +IRC, freenode, #hurd, 2012-03-14: + + <civodul> i just realized that ld.so uses mmap unconditionally + <civodul> so executables or shared libs can't be used off a netfs-based + file system + <civodul> that's annoying + <tschwinge> civodul: Do you know what it takes to fix libnetfs? I have no + idea. + <tschwinge> Never looked at it. + <civodul> tschwinge: implementing io_map + <civodul> but i think the idea is that io_map typically isn't convenient + for network file systems + <civodul> which is why it doesn't have it + <civodul> the GCS says "thou shall not require mmap" ;-) + +<http://lists.gnu.org/archive/html/bug-hurd/2001-10/msg00306.html>. Analysis +to be found on [[glibc/mmap]] page. diff --git a/open_issues/libnfs.mdwn b/open_issues/libnfs.mdwn new file mode 100644 index 00000000..8cadefa4 --- /dev/null +++ b/open_issues/libnfs.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, freenode, #hurd, 2012-01-09: + + <pinotree> https://github.com/sahlberg/libnfs ← maybe it could be used for + nfs support, instead of the rpc stuff "removed" in newer glibc versions + <antrik> pinotree: sounds like it could do much more than just the RPC + stuff -- definitely interesting :-) + <pinotree> hm but it seems to be an abstraction over either classic rpc or + tirpc + <pinotree> (anyway, it is packaged already in debian) + <antrik> good licensing too + <antrik> I guess I'll modify the GSoC task to "rework the Hurd NFS client + to use libnfs" :-) + <pinotree> the nfs translator? + <antrik> yes + +[[hurd/translator/nfs]] diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn new file mode 100644 index 00000000..c5054b7f --- /dev/null +++ b/open_issues/libpthread.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +[[!toc]] + + +# cthreads -> pthreads + +Get rid of cthreads; switch to pthreads. + +There is a [[!FF_project 275]][[!tag bounty]] on this task. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/pthreads feeds=no]] + + +## IRC, freenode, #hurd, 2012-04-26 + + <pinotree> youpi: just to be sure: even if libpthread is compiled inside + glibc (with proper symbols forwarding etc), it doesn't change that you + cannot use both cthreads and pthreads in the same app, right? + +[[Packaging_libpthread]]. + + <youpi> it's the same libpthread + <youpi> symbol forwarding does not magically resolve that libpthread lacks + some libthread features :) + <pinotree> i know, i was referring about the clash between actively using + both + <youpi> there'll still be the issue that only one will be initialized + <youpi> and one that provides libc thread safety functions, etc. + <pinotree> that's what i wanted to knew, thanks :) diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn new file mode 100644 index 00000000..2c8f10f8 --- /dev/null +++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn @@ -0,0 +1,78 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="libpthread: CLOCK_MONOTONIC"]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +[[!message-id "201204220058.37328.toscano.pino@tiscali.it"]] + + +# IRC, freenode, #hurd, 2012-04-22 + + <pinotree> youpi: what i thought would be creating a + glib/hurd/hurdtime.{c,h}, adding _hurd_gettimeofday and + _hurd_clock_{gettime,settime,getres} to it and making the current .c in + sysdeps call those + <youpi> yep + <youpi> that's unfortunate, but that's what nptl actually does + <pinotree> this way we could add inside hurdtime.c the mapped time stuff + too + <pinotree> most probably a noobish question, but why does rt link to + pthread? + <youpi> no idea :) + <youpi> possibly due to aio implementation + <youpi> ./sysdeps/pthread/aio_cancel.c + <youpi> probably due to that + <youpi> (and others) + + +## IRC, freenode, #hurd, 2012-04-23 + + <youpi> pinotree: about librt vs libpthread, don't worry too much for now + <youpi> libpthread can lib against the already-installed librt + <youpi> it does work + <pinotree> youpi: wouldn't that cause a dependency loop? + <youpi> pinotree: what dependency loop? + <pinotree> youpi: librt wouldd link to pthread, no? + <youpi> and ? + <youpi> I don't think it's an issue that .so link with each other + <pinotree> it isn't? + <youpi> well, try + * pinotree never did that + <youpi> but I don't think it will pose problem + <youpi> well, perhaps initialization order + <youpi> anyway, I now have packages built, I'll test that + <youpi> pinotree: ok, it seems it doesn't work indeed :) + <youpi> early in initialization + <youpi> pinotree: the initialization bug might actually not be due to librt + at all + <youpi> pinotree: yes, things work even with -lrt + <pinotree> wow + + +## IRC, OFTC, #debian-hurd, 2012-06-04 + + <youpi> pinotree: -lrt in libpthread is what is breaking glib2.0 + <youpi> during ./configure it makes clock_gettime linked in, while at + library link it doesn't + <youpi> probably for obscure reasons + <youpi> I'll have to disable it in debian + + +### IRC, OFTC, #debian-hurd, 2012-06-05 + + <pinotree> youpi: i saw your message about the linking issues with + pthread/rt; do you want me to provide a patch to switch clock_gettime → + gettimeofday in libpthread? + <youpi> you mean switch it back as it was previously? + <pinotree> kind of, yes + <youpi> I have reverted the change in libc for now + <pinotree> ok 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_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn new file mode 100644 index 00000000..05a07ef2 --- /dev/null +++ b/open_issues/libpthread_dlopen.mdwn @@ -0,0 +1,129 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_libpthread]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2010-01-24 + + <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed + libraries + <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs, + we're the only one with such configuration + <pinotree> i was looking at the gcc 4.4 patch hurd-pthread.diff, could it + be it does not set THREADLIBS in the configure.ac switch case? + <youpi> that's expected + <youpi> on linux the libc provides hooks itself, on hurd-i386 it's + pthread-stubs + <pinotree> why not explicitly link to pthread though? + <youpi> because there is no strict need to, for applications that don't + need libpthread + <youpi> the dlopen case is a tricky case that pthread-stubs had not thought + about + <pinotree> hm + <pinotree> what if the pthread stubs would be moved in our glibc? + <youpi> that's what we should do yes + <youpi> (ideally) + <youpi> but for this we need to build libpthread along glibc, to get it + really working + +[[Packaging_libpthread]]. + + <youpi> and that's the tricky part (Makefile & such) which hasn't been done + yet + <pinotree> why both (stubs + actual libpthread)? + <youpi> because you need the stubs to be able to call the actual libpthread + <youpi> as soon libpthread gets dlopened for instance + <youpi> +as + <pinotree> i see + <youpi> (remember that nptl does this if you want to see how) + <youpi> (it's the libc files in nptl/) + <youpi> (and forward.c) + <guillem> also if libpthreads gets integrated with glibc don't we need to + switch the hurd from cthreads then? Which has been the blocker all this + time AFAIR? + <youpi> we don't _need_ to + <guillem> ok + + +# IRC, OFTC, #debian-hurd, 2011-07-21 + + <youpi> there's one known issue with pthreads + <youpi> you can't dlopen() it + +... if the main application is not already linked against it. + + <youpi> which also means you can't dlopen() a module which depends on it if + the main application hasn't used -lpthread already + <youpi> (so as to get libpthread initialized early, not at the dlopen() + call) + <lucas> I get this while building simgrid: + <lucas> cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && + /usr/bin/cmake -E create_symlink + /home/lucas/simgrid-3.6.1/obj-i486-gnu/lib/libsimgrid.so + /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console/simgrid.so + <lucas> cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && + lua /home/lucas/simgrid-3.6.1/examples/gras/console/ping_generator.lua + <lucas> lua: + /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libpthread/sysdeps/generic/pt-mutex-timedlock.c:68: + __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. + <lucas> Aborted (core dumped) + <youpi> that's it, yes + <youpi> (or at least it has the same symptoms) + <lucas> it would need fixing in lua, not in SG, then, right? + <youpi> yes + <lucas> ok, thanks + +The fix thus being: link the main application with -lpthread. + +IRC, freenode, #hurd, 2011-08-17 + + < youpi> i.e. openjade apparently dlopen()s modules which use pthreads, but + openjade itself is not liked against libpthread + < youpi> which means unexpectedly loading pthreads on the fly, which is + not implemented + < youpi> (and hard to implement of course) + < youpi> gnu_srs: so simply tell openjade people to link it with -lpthread + < gnu_srs> Shuoldn't missing linking with pthread create an error when + building openjade then? + < youpi> no + < youpi> because it's just a module which needs pthread + < youpi> and that module _is_ linked with -lpthread + < youpi> and dlopen() loads libpthreads too due to that + < youpi> but that's unexpected, for the libpthread initialization stuff + < youpi> (and too late to fix initlaization) + < gnu_srs> How come that other OSes build opensp w/o problems? + < youpi> because there are stubs in the libc + < gnu_srs> Sorry for the delay: What hinders stubs to be present also in + the Hurd libc parts too, to cope with this problem? + < youpi> doing it + < youpi> which is hard because you need libpthread bits inside the libc + < youpi> making it simpler would need building libpthread at the same time + as libc + +[[packaging_libpthread]] + +--- + +The same symptom appears in an odd case, for instance: + + buildd@hurd:~$ ldd /usr/bin/openjade + libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) + libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000) + libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000) + libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000) + [...] + +openjade links against *both* libthreads and libpthread. The result is that libc +early-initializes libthreads only, and thus libpthread is not early-initialized, +and later on raises assertions. The solution is to just get rid of libthreads, +to have only one threading library. diff --git a/open_issues/libpthread_glibc_nptl_testsuite.mdwn b/open_issues/libpthread_glibc_nptl_testsuite.mdwn new file mode 100644 index 00000000..687f8eea --- /dev/null +++ b/open_issues/libpthread_glibc_nptl_testsuite.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +For fun and profit we should run [[glibc]]'s [[NPTL]] testsuite against +[[libpthread]]. + +Also, there are sometimes issues fixed in NPTL that libpthread should also be +checked against. Totally incomplete list: + + * Return `EAGAIN` instead of `ENOMEM`, glibc + 5bdcc10322c488f53557440acf71623d8b313ab5. + * `pthread_cancel` when single-threaded, glibc + 439bf404b8fa125cf950dc1aa37838702c5353ea, [[!sourceware_PR 13613]], + [[!message-id "20120509202437.268a72b9@spoyarek"]]. + * `__libc_stack_end`, glibc 9c6ea9facbba4d430807bd21fa82892d713b1ecd, + 18b5e737de22462ab6b3fc89f26c9ad480ebb843, [[!sourceware_PR 12416]], + [[!message-id "20120419120021.4780e8c8@spoyarek"]], [[!message-id + "20120615005913.4f517e02@spoyarek"]], [[!message-id + "4FE378DE.8050906@mentor.com"]]. 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/libpthread_weak_symbols.mdwn b/open_issues/libpthread_weak_symbols.mdwn new file mode 100644 index 00000000..6f135979 --- /dev/null +++ b/open_issues/libpthread_weak_symbols.mdwn @@ -0,0 +1,50 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +IRC, unknown channel, unknown date. + + <youpi> btw, the issue with pthread_cancel is tricky + <youpi> I'm afraid there might be no fix + <youpi> clean fix, I mean + <pinotree> oh, hm + <pinotree> where it the problem located, actually? + <youpi> it's a lot more than just one place + <youpi> in some c++ header there is a weak reference to pthread_cancel + <youpi> libpthreadstubs0 provides a weak definition of pthread_cancel, which can suit well + <youpi> problem comes when also linking with a library which pulls libpthread + <youpi> oops no libpthreadstubs0 doesn't provide a weak definition of pthread_cancel + <youpi> it couldn't implement it anyway + <youpi> and the problem here is that the linker seems to be looking for pthread_cancel in the libpthreadstubs0 library, not libpthread + <youpi> and can't find it + <youpi> I don't know how this translate to english, but we're “walking on eggs + <youpi> ” on this issue + <pinotree> i see + <youpi> i.e. we already know we're not respecting the ELF standard + <youpi> we need a feature that is not in the standard to make pthread symbols working + <youpi> the solution would be to integrate libpthread into the glibc + <pinotree> you mean in the sources, but still providing separate libc.so and libpthread.so? + <youpi> yes + <pinotree> would that be difficult/tricky? + <youpi> because that permits to put pthread_* functions forwarding directly in the glibc, as is done on linux + <youpi> problem is upstream, you know... + <youpi> if we put libpthread there, it'll be difficult for us to maintain it + <pinotree> ah, the friendly ulrich mate? + <youpi> we already have difficults to get almost trivial patches commited + <youpi> and the "yes I'll handle it someday" Roland mate + <youpi> Roland is supposed to be the GNU part maintainer, but he doesn't have a box running at the moment + <youpi> what we could do is to do it in Debian for the moment + <pinotree> yeah + <pinotree> iirc eglibc is maintained within git, isn't it? + <pinotree> maybe you could do a hurd branch, putting all the hurd patches and the pthread sources, and then releasing from that + <youpi> we're already moving to something like that, yes + <youpi> at least for all the other glibc patches we have + <youpi> maybe we'll just do that on sourceware actually diff --git a/open_issues/librpci.mdwn b/open_issues/librpci.mdwn new file mode 100644 index 00000000..a3af16b1 --- /dev/null +++ b/open_issues/librpci.mdwn @@ -0,0 +1,31 @@ +[[!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_hurd]] + +2004 to 2007, Anand Babu has been working some on this project. It is still in +rather early stages. It's meant to become an extension/complement to +[[hurd/debugging/rpctrace]]. + + * <https://savannah.nongnu.org/projects/rpci> + + > A C language library for interposing ports of a Hurd task running on top + > of GNU Mach micro-kernel. Using this library, it would be possible to + > implement a trace/replay system, RPC debugger, sandbox, etc. + + On top of that, a debugger was planned: + + > A RPC level debugger with useful command set to analyze/manipulate a task + > at run time. For example, the user will be able to set RPC break points, + > manipulate port rights and data, trace and replay a task. + +If there is interest, the existing source code could be moved from the CVS +repository into the [[source_repositories/incubator]] ([[tschwinge]] already +locally converted it to Git.) diff --git a/open_issues/libstore_parted.mdwn b/open_issues/libstore_parted.mdwn new file mode 100644 index 00000000..852c8fa8 --- /dev/null +++ b/open_issues/libstore_parted.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta redir=hurd/libstore/part]] diff --git a/open_issues/libtool.mdwn b/open_issues/libtool.mdwn new file mode 100644 index 00000000..7b2e0fe0 --- /dev/null +++ b/open_issues/libtool.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +# [[GCC]]: `libtool: finish`: `ldconfig` is not run for the Hurd. + +This probably comes from libtool's `libltdl/m4/libtool.m4` (or similar): +`finish_cmds`. + +There are a few other differences between `gnu` and `linux* | k*bsd*-gnu | +kopensolaris*-gnu`. diff --git a/open_issues/linux_as_the_kernel.mdwn b/open_issues/linux_as_the_kernel.mdwn new file mode 100644 index 00000000..1d84d777 --- /dev/null +++ b/open_issues/linux_as_the_kernel.mdwn @@ -0,0 +1,237 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Instead of attempting a [[history/port_to_another_microkernel]], or writing an +own one, an implementation of a Hurd system could use another existing +operating system/kernel, like [[UNIX]], for example, the Linux kernel. This is +not a [[microkernel]], but that is not an inherent hindrance; depending on what +the goals are. + +There has been an attempt for building a [[Mach_on_top_of_POSIX]]. + + +# IRC, freenode, #hurd, 2012-02-08 + +Richard's X-15 Mach re-implementation: + + <braunr> and in case you didn't notice, it's stalled + <braunr> actually i don't intend to work on it for the time being + <braunr> i'd rather do as neal suggested: take linux, strip it, and give it + a mach interface + <braunr> (if your goal really is to get something usable for real world + tasks) + <antrik> braunr: why would you want to strip down Linux? I think one of the + major benefits of building a Linux-Frankenmach would be the ability to + use standard Linux functionality alongside Hurd... + <braunr> we could have a linux x86_64 based mach replacement in "little" + time, with a compatible i386 interface for the hurd + <braunr> antrik: well, many of the vfs and network subsystems would be hard + to use + <antrik> BTW, one of the talks at FOSDEM was about the possibility of using + different kernels for Genode, and pariticularily focused on the + possibilities with using Linux... unfortunately, I wasn't able to follow + the whole talk; but they mentioned similar possibilities to what I'm + envisioning here :-) + + +## IRC, freenode, #hurd, 2012-03-28 + + <mel__> is there currently any work going on with respect to + Mach-alternatives? + <antrik> mel__: no + <antrik> we have other priorities to take care of :-) + <braunr> antrik: i still intend to try giving linux a "mach personality" :) + <braunr> antrik: but i don't have much time for development currently :( + <mel__> antrik: which means that the hope is that Mach can be turned into + something really well working (i.e. secure/scalable/etc.)? + <antrik> mel__: yes, that's the venue we are pursuing + <antrik> (and IMHO the right one... though the Linux layer mentioned by + braunr is also one of my favourite projects, that we should pursue *in + parallel* to the existing Mach-based implementation) + <mel__> what is this Linux Layer exactly? + <mel__> a Linux instance running on top of Mach in parallel to Hurd + serverS? + <braunr> mel__: not exactly + <braunr> mel__: it would involve adding a mach layer on top of linux + actually + <braunr> mel__: so that linux can be used as a mach kernel + <mel__> Ah! + <mel__> Running Hurd on top of Linux + <mel__> :-D + <mel__> Funny + <braunr> ironic, yes + <braunr> but very pragmatic + <mel__> and THEN + <antrik> yeah. I most like the name: Hurd Emulation Layer on + Linux... i.e. HELL :-) + <mel__> we use a device driver framework something so that we can use Linux + device drivers in Hurd! + <mel__> on top of Linux.... + <braunr> yes + <braunr> i guess a transition phase would include using in kernel drivers + directly for a while + <mel__> and somebody is working on that? + <antrik> mel__: well, for using Linux drivers we are persuing DDE, which + allows us doing that with Mach as well + <braunr> then grabbing them out of the kernel and into dde + <braunr> not yet + <antrik> (in fact we have been using Linux drivers since forever... they + just haven't been updated for ages) + <mel__> I would _guess_ that it is not that hard. + <braunr> it's not + <mel__> Basically one would need to implement the message passing interface + thing in linux I guess. + <braunr> and many exported kernel objects like tasks, threads, etc.. + <braunr> and implement all the RPCs normally implemented by the kernel + <braunr> but it's doable + <antrik> mel__: the IPC aspect is one part, but probably the less tricky + one. the external pager interface is really the crucial element + <mel__> uh + <mel__> yeah + <mel__> hooking into linux virtual memory stuff + <mel__> sounds delicate + <braunr> it's true that some interactions between the linux VM and file + systems (the linux equivalent of our pagers) is synchronous + <braunr> but i don't think it would be that hard considering the amount of + facilities available in linux + <braunr> it's just work, takes time, needs debugging, reviewing, testing, + etc.. + <lcc> hurd on top of linux. how would that work? + <braunr> 15:30 < braunr> antrik: i still intend to try giving linux a "mach + personality" :) + <braunr> lcc: 7 system calls and a few hundreds of RPCs on top, the + internal magic of course, and voila .. + <antrik> of course porting Mach still requires work + <mel__> that would then be GNU/Hurd/Linux + <mel__> :-) + <antrik> hehe + <braunr> eh + <antrik> braunr: BTW, are you more thinking of a userspace solution on top + of standard Linux mechanisms, or additions to Linux itself?... + <antrik> (we probably talked about it already, but I don't remember all the + details...) + <braunr> antrik: adding to linux + <antrik> do you think a pure userspace solution would be realistic at all? + (at the expense of some performance of course) + <mel__> it's probably comparable to the qemu vs. qemu/kvm thing + <antrik> yeah, I guess that pretty much sums it up... + <braunr> antrik: i don't know :/ + <antrik> OK + <lcc> how challenging is it to port mach? + <antrik> lcc: it requires good low-level knowledge of the platform in + question. having that, I guess it shouldn't be too hard to add the + necessary code in Mach... + <antrik> TBH I'm not sure how much knowledge of Mach internals is required + <braunr> the pmap module is the main thing to port + <antrik> braunr: well, sartakov seemed to have most trouble with the + scheduler when he attempted the ARM port... + <braunr> that's strange + <antrik> at least there was quite a long thread where he asked about how + task switching works in Mach + <braunr> ok + <braunr> that would be interesting + <braunr> i thought intereacting with the hardclock was enough + + +## IRC, freenode, #hurd, 2012-04-05 + + <braunr> antrik: don't you think HELL is worth a try for the GSoC btw ? + <antrik> braunr: definitely. I haven't managed to rework the project ideas + list at all this year... but it's something I wanted there for a long + time + + <youngrw> just out of curiousity, what is HELL ? + <antrik> Hurd Emulation Layer on Linux + <braunr> youngrw: it can be described in several ways + <braunr> youngrw: basically, it's a mach interface on top of linux + <youngrw> implementing I suppose both the IPC mechanism and memory + management interface? + <mel__> youngrw: basically that. more generally: implement everything in + order to let Hurd run on that layer. + <antrik> well, it's slightly more complicated in my view... it's basically + anything that allows running a Hurdish environment on top of + GNU/Linux. it might be simply an implementation/emulation of Mach + mechanisms; but it also *might* work on a slightly higher level... + <youngrw> antrik: how might HELL operate at the slighty higher level like + you describe? + <antrik> let's call it low-level HELL and high-level HELL ;-) + <antrik> (a more descriptive name would be hurdenv... but HELL is so much + more catchy :-) ) + <antrik> so, high-level HELL... basically, the idea would be not to emulate + the kernel facilities and run all the real Hurd servers; but instead to + use special servers implementing the Hurd interfaces, but on top of + standard Linux facilities + <antrik> hurdish programs could run in such an environment, as long as they + aren't too low-level + <antrik> I wonder whether generic RPC interfaces could be implemented with + some side channel tunneled though the ordinary Linux FS interfaces... + <antrik> so translators would be loaded as FUSE modules for example, but + could still present generic interfaces + <youngrw> That's actually pretty different from what I was expecting + <antrik> what were you expecting? + <youngrw> maybe something where the entire kernel interface is emulated by + a running user process, like a kind of virtual machine + <youngrw> I hope that makes sense--I may be using my words incorrectly. + <antrik> youngrw: that would be in the low-level HELL category + <youngrw> antrik: right; I had the misconception that the level was defined + by how it made use of the underlying linux system + <youngrw> and that different HELL designs would always implement the mach + interface + + +## IRC, freenode, #hurd, 2012-04-06 + + <braunr> antrik: i think we have diverging ideas about how to use linux for + the hurd + <braunr> antrik: what you seem to want are really emulation componants, + like e.g. ext2fs and pfinet actually using the linux implementation + <braunr> (correct me if i'm mistaken) + <braunr> whereas my project is to make linux behave as a mach clone + <antrik> braunr: as I said, I consider both variants -- either a high-level + HELL or a low-level HELL + <braunr> ok + <antrik> (or perhaps a mix of both) + <braunr> a mix would be best imho + <antrik> yeah, probably + <braunr> so we have the real hurd, the real mach interface, and a set of + native translators (e.g. ext2fs) along some emulating their functionality + using linux code (e.g. a hypothetical ext4fs) + <antrik> I don't think we would have emulation servers for individual Linux + filesystems. rather, a generic server interfacing with the Linux VFS + tree... + <braunr> ok + + <antrik> braunr: BTW, I think I mentioned a couple of years ago that the + most realistic route towards a modern Mach in my opinion would be taking + a modern BSD (or Linux), and redo what the original Mach developers did + -- i.e. add the Mach-specific features, and drop the unnecessary UNIX + stuff + <braunr> antrik: :) + <braunr> we had discussions about it some time ago yes + <antrik> later I realised that it's better *not* to drop the UNIX + interfaces, but rather to keep them in parallel :-) + <braunr> antrik: for what purpose ? + <braunr> (i can imagine a few, but i'd like to know your idea) + <antrik> for the purpose of HELL :-) + <braunr> well hell would be the implementation, but what do you keep these + unix interfaces for ? + <antrik> i.e. people being able to play around with a Hurd environment + while staying with their existing system + <braunr> yes, i see + <braunr> i was considering doing that for development, yes + <braunr> uml first, and then i realized i wouldn't need it :) + <braunr> then i remembed netbsd and its syscall emulation layer + <antrik> also we might leverage some "foreign" userspace infrastructure + that way, such as udev + <antrik> (in the case of Linux that is... not sure whether NetBSD has + something similar at all ;-) ) + <braunr> i'll have to check, it's been a long time since i've really used + it + <braunr> they must use a pure devfs instance now diff --git a/open_issues/linux_vmsig.mdwn b/open_issues/linux_vmsig.mdwn new file mode 100644 index 00000000..a4311d3e --- /dev/null +++ b/open_issues/linux_vmsig.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Linux: vmsig"]] + +[[!tag open_issue_gnumach open_issue_hurd]] + + * *cooperating with the VM when memory pressure increases* + + * *notify user applications of virtual memory events via real-time signals* + +<http://www.cs.umass.edu/~emery/pubs/bookmarking-collector/>, and discussion at +<http://lambda-the-ultimate.org/node/2391> and +<http://marc.info/?t=113269321800003&r=1&w=2>. + +Found this via <http://lambda-the-ultimate.org/node/4094#comment-62100>, which +was linked from [LWN](http://lwn.net/Articles/409416/). + +From a quick glance, this sounds to [[me|tschwinge]] quite a bit like +mechanisms also found in (originating in?) Mach's +[[microkernel/mach/external_pager_mechanism]]. May be worth having a look at +it. diff --git a/open_issues/lisp_cross-compile.mdwn b/open_issues/lisp_cross-compile.mdwn new file mode 100644 index 00000000..c9100aec --- /dev/null +++ b/open_issues/lisp_cross-compile.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +flaviocruz-soc2008-lisp-branch: lisp stuff can't be cross-compiled. diff --git a/open_issues/llvm.mdwn b/open_issues/llvm.mdwn new file mode 100644 index 00000000..d0b7b91d --- /dev/null +++ b/open_issues/llvm.mdwn @@ -0,0 +1,17 @@ +[[!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_llvm open_issue_porting]] + +[LLVM](http://www.llvm.org/) needs a little bit of porting for being usable on +GNU/Hurd. + +Apparently this has already been done within Debian; +<http://anonscm.debian.org/viewvc/pkg-llvm/llvm/trunk/debian/patches/>. diff --git a/open_issues/locking_issues.mdwn b/open_issues/locking_issues.mdwn new file mode 100644 index 00000000..e15562bc --- /dev/null +++ b/open_issues/locking_issues.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_hurd]] + +There are locking issues in the Hurd's libraries. + +[[!toc]] + + +# Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/libdiskfs_locking feeds=no]] + + +# ext2fs Deadlock + +[[ext2fs_deadlock]]. + + +# Formal Verification + +Methods of [[formal_verification]] should be applied to get an understanding of +the behavior of the locking logic. There are tools for formal +verification/[[code_analysis]] that can likely help here. + +There is a [[!FF_project 278]][[!tag bounty]] on this task. diff --git a/open_issues/low_memory.mdwn b/open_issues/low_memory.mdwn new file mode 100644 index 00000000..22470c65 --- /dev/null +++ b/open_issues/low_memory.mdwn @@ -0,0 +1,113 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_glibc open_issue_hurd]] + +Issues relating to system behavior under memory pressure. + +[[!toc]] + + +# [[gnumach_page_cache_policy]] + + +# IRC, freenode, #hurd, 2012-07-08 + + <braunr> am i mistaken or is the default pager simply not vm privileged ? + <braunr> (which would explain the hangs when memory is very low) + <youpi> no idea + <youpi> but that's very possible + <youpi> we start it by hand from the init scripts + <braunr> actually, i see no way provided by mach to set that + <braunr> i'd assume it would set the property when a thread would register + itself as the default pager, but it doesn't + <braunr> i'll check at runtime and see if fixing helps + <youpi> thread_wire(host, thread, 1) ? + <youpi> ./hurd/mach-defpager/wiring.c: kr = + thread_wire(priv_host_port, + <braunr> no + <braunr> look in cprocs.c + <braunr> iir + <braunr> iirc + <braunr> iiuc, it sets a 1:1 kernel/user mapping + <youpi> ?? + <youpi> thread_wire, not cthread_wire + <braunr> ah + <braunr> right, i'm getting tired + <braunr> youpi: do you understand the comment in default_pager_thread() ? + <youpi> well, I'm not sure to know what external vs internal is + <braunr> i'm almost sure the default pager is blocked because of a relation + with an unprivlege thread + <braunr> +d + <braunr> when hangs happen, the pageout daemon is still running, waiting + for an event so he can continue + <braunr> it* + + <braunr> all right, our pageout stuff completely sucks + <braunr> when you think the system is hanged, it's actually not + <pinotree> and what's happening instead? + <braunr> instead, it seems it's in a very complex resursive state which + ends in the slab allocator not being able to allocate kernel map entries + <braunr> recursive* + <braunr> the pageout daemon, unable to continue, progressively slows + <braunr> in hope the default pager is able to service the pageout requests, + but it's not + <braunr> probably the most complicated deadlock i've seen :) + <braunr> luckily ! + <braunr> i've been playing with some tunables involved in waking up the + pageout daemon + <braunr> and got good results so far + <braunr> (although it's clearly not a proper solution) + <braunr> one thing the kernel lacks is a way to separate clean from dirty + pages + <braunr> this stupid kernel doesn't try to free clean pages first .. :) + <braunr> hm + <braunr> now i can see the system recover, but some applications are still + stuck :( + <braunr> (but don't worry, my tests are rather aggressive) + <braunr> what i mean by aggressive is several builds and various dd of a + few hundred MiB in parallel, on various file systems + <braunr> so far the file systems have been very resilient + <braunr> ok, let's try running the hurd with 64 MiB of RAM + <braunr> after some initial swapping, it runs smoothly :) + <braunr> uh ? + <braunr> ah no, i'm still doing my parallel builds + <braunr> although less + <braunr> gcc: internal compiler error: Resource lost (program as) + <braunr> arg + <braunr> lol + <braunr> the file system crashed under the compiler + <pinotree> too much memory required during linking? or ram+swap should have + been enough? + <braunr> there is a lot of swap, i doubt it + <braunr> the hurd is such a dumb and impressive system at the same time + <braunr> pinotree: what does this tell you ? + <braunr> git: hurdsig.c:948: post_signal: Unexpected error: (os/kern) + failure. + <pinotree> something samuel spots often during the builds of haskell + packages + +Probably also the *sigpost* case mentioned in [[!message-id +"87bol6aixd.fsf@schwinge.name"]]. + + <braunr> actually i should be asking jkoenig + <braunr> it seems the lack of memory has a strong impact on signal delivery + <braunr> which is bad + <antrik> braunr: I have a vague recollection of slpz also saying something + about missing dirty page tracking a while back... I might be confusing + stuff though + <braunr> pinotree: yes it happens often during links + <braunr> which makes sense + <pinotree> braunr: "happens often" == "hurdsig.c:948: post_signal: ..."? + <braunr> yes + <pinotree> if you can reproduce it often, what about debugging it? :P + <braunr> i mean, the few times i got it, it was often during a link :p + <braunr> i'd rather debug the pageout deadlock :( + <braunr> but it's hard diff --git a/open_issues/lsof.mdwn b/open_issues/lsof.mdwn new file mode 100644 index 00000000..2cbf2302 --- /dev/null +++ b/open_issues/lsof.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +We don't have a `lsof` tool. Perhaps we could cook something with having a +look at which ports are open at the moment (as [[`portinfo`|hurd/portinfo]] +does, for example)? diff --git a/open_issues/ltrace.mdwn b/open_issues/ltrace.mdwn new file mode 100644 index 00000000..cf0df759 --- /dev/null +++ b/open_issues/ltrace.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <youpi> it'd be good to have ltrace eventually + <youpi> rpctrace has too many issues to be usable + <youpi> (and a lot of them are hard to fix iirc) + <youpi> ltrace traces library calls + <youpi> in principle it should just work at the dynamic linker stage, so should be portable diff --git a/open_issues/m4_vs_stack.mdwn b/open_issues/m4_vs_stack.mdwn new file mode 100644 index 00000000..c92cfb00 --- /dev/null +++ b/open_issues/m4_vs_stack.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + m4 (1.4.13-1+hurd.2) unreleased; urgency=low + + * Drop stack overflow (checks/stackovf) check, test-c-stack and + test-c-stack2 checks, and /dev/null/ (test-open and test-fopen) checks. + + -- Samuel Thibault <samuel.thibault@ens-lyon.org> Tue, 18 Aug 2009 20:54:30 +0000 + + <youpi> that was a quick fix (as not having m4 makes autoconf uninstallable, which is quite a problem) + <youpi> there's probably something wrong in the stack management of the Hurd, I haven't investigated diff --git a/open_issues/mach-defpager_debugging.mdwn b/open_issues/mach-defpager_debugging.mdwn new file mode 100644 index 00000000..33e717d9 --- /dev/null +++ b/open_issues/mach-defpager_debugging.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gdb]] + +IRC, freenode, #hurd, 2011-11-10: + + <mcsim> hello. Is there any way to debug mach-defpager? When I set + breakpoint to any function in it, pager never breaks. + +IRC, freenode, #hurd, 2011-11-11: + + <mcsim> hello. I've read that hde tried to debug defpager and wrote some + patches for debugging defpager, but I couldn't find them. Does anybody + know are these patches in public? diff --git a/open_issues/mach-defpager_malloc_hook.mdwn b/open_issues/mach-defpager_malloc_hook.mdwn new file mode 100644 index 00000000..2bbff75a --- /dev/null +++ b/open_issues/mach-defpager_malloc_hook.mdwn @@ -0,0 +1,14 @@ +[[!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_hurd]] + +*malloc hooks* are used in `[hurd]/mach-defpager/kalloc.c`. But their use is +deprecated (glibc 7d17596c198f11fa85cbcf9587443f262e63b616). diff --git a/open_issues/mach-defpager_swap.mdwn b/open_issues/mach-defpager_swap.mdwn new file mode 100644 index 00000000..7d3b001c --- /dev/null +++ b/open_issues/mach-defpager_swap.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +[[!toc]] + + +# IRC, OFTC, #debian-hurd, 2012-06-16 + + <lifeng> I allocated a 5GB partition as swap, but hurd only found 1GB + <youpi> use 2GiB swaps only, >2Gib are not supported + <youpi> (and apparently it just truncates the size, to be investigated) diff --git a/open_issues/mach-defpager_vs_defpager.mdwn b/open_issues/mach-defpager_vs_defpager.mdwn new file mode 100644 index 00000000..f03bc67f --- /dev/null +++ b/open_issues/mach-defpager_vs_defpager.mdwn @@ -0,0 +1,33 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +IRC, freenode, #hurd, end of May/beginning of June 2010 + + <cfhammar> whats the difference between mach-defpager and defpager? + <cfhammar> i'm guessing defpager is a hurdish version that uses libstore + but was never finished or something + <cfhammar> found an interesting thread about it: + http://mirror.libre.fm/hurd/list/msg01232.html + <slpz> antrik: an interesting thread, indeed :-) + <pochu> slpz: btw is mach-defpager linked statically but not called + mach-defpager.static on purpose? + <slpz> antrik: also, I can confirm that mach-defpager needs a complete + rewrite ;-) + <slpz> pochu: I think the original defpager was launched by serverboot + <slpz> pochu: that could be the reason to have it static, like ext2fs + <slpz> and since there's no need to execute it again during the normal + operation of the system, they probably decided to not create a + dynamically linked version + <slpz> (but I'm just guessing) + <slpz> of perhaps they wanted to prevent mach-defpager from the need of + reading libraries, since it's used when memory is really scarce (guessing + again) diff --git a/open_issues/mach_migrating_threads.mdwn b/open_issues/mach_migrating_threads.mdwn new file mode 100644 index 00000000..c14ce95a --- /dev/null +++ b/open_issues/mach_migrating_threads.mdwn @@ -0,0 +1,17 @@ +[[!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]] + +<http://www.brynosaurus.com/pub/os/thread-migrate.pdf> + + * [[microkernel/mach/memory_object/discussion]] + + * [[resource_management_problems]] diff --git a/open_issues/mach_on_top_of_posix.mdwn b/open_issues/mach_on_top_of_posix.mdwn new file mode 100644 index 00000000..7574feb0 --- /dev/null +++ b/open_issues/mach_on_top_of_posix.mdwn @@ -0,0 +1,16 @@ +[[!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="Mach on Top of POSIX"]] + +[[!tag open_issue_gnumach]] + +At the beginning of the 2000s, there was a *Mach on Top of POSIX* port started +by John Edwin Tobey. Status unknown. Ask [[tschwinge]] for the source code. diff --git a/open_issues/mach_tasks_memory_usage.mdwn b/open_issues/mach_tasks_memory_usage.mdwn new file mode 100644 index 00000000..9abb7639 --- /dev/null +++ b/open_issues/mach_tasks_memory_usage.mdwn @@ -0,0 +1,147 @@ +[[!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-01-06 + + <antrik> hm, odd... vmstat tells me that ~500 MiB of RAM are in use; but + the sum of all RSS is <300 MiB... what's the rest? + <braunr> kernel memory ? + <braunr> the zone allocator maybe + <braunr> or the page cache simply + <antrik> braunr: which page cache? AIUI, caches are implemented by the + individual filesystem servers -- in which case any memory used by them + should show up in RSS + <antrik> also, gnumach is listed among other tasks, so I'd assume the + kernel memery also to be accounted for + <braunr> antrik: no, the kernel maintains a page cache, very similar to + what is done in Linux, and almost the same as in FreeBSD + <braunr> the file system servers are just backing stores + <braunr> the RSS for the gnumach tasks only includes kernel memory + <braunr> I don't think the page cache is accounted for + <braunr> because it's not really kernel memory, it's a cache of user space + memory + <antrik> apparently my understanding of Mach paging is still (or again?) + rather incomplete :-( + <antrik> BTW, is there any way to find out how much anonymous memory a + process is using? the "virtual" includes discardable mappings, and is + thus not very helpful... + <antrik> (that applies to Linux as well though) + <braunr> can you provide an example of the output of vmstat please ? + <braunr> I don't have a Hurd VM near me + <antrik> olaf@alien:~$ vmstat + <antrik> pagesize: 4K + <antrik> size: 501M + <antrik> free: 6.39M + <antrik> active: 155M + <antrik> inactive: 310M + <antrik> wired: 29.4M + <antrik> zero filled: 15.3G + <antrik> reactivated: 708M + <antrik> pageins: 3.43G + <antrik> pageouts: 1.55G + <antrik> page faults: 26844574 + <antrik> cow faults: 3736174 + <antrik> memobj hit ratio: 92% + <antrik> swap size: 733M + <antrik> swap free: 432M + <antrik> interesting... closing a single screen window temporarily raises + the "free" value by almost 10 MB + <antrik> I guess bash is rather hungry nowadays ;-) + <braunr> antrik: I guess the only way is using pmap or looking into + /proc/<pid>/maps + <braunr> but it won't give you the amount of physical memory used by + anonymous mappings + <antrik> nah, I don't even want that... just like to know how much memory + (RAM+swap) a process is really using + <braunr> antrik: then the RSS field is what you want + <antrik> OTOH, anonymous doesn't include program code or other actively + used mappings... so not very useful either + <antrik> nah, RSS doesn't count anything that is in swap + <braunr> well + <braunr> don't you have a SWAP column ? + <braunr> hm + <braunr> i guess not + <braunr> antrik: why do you say it doesn't include other actively used + mappings ? + <braunr> antrik: and the inclusion of program code also depends on the + implementation of the ELF handler + <braunr> I don't know how the hurd does that, but some ELF loaders use + anonymous memory for the execution view + <antrik> well, if a program maps a data file, and regularily accesses parts + of the file, they won't occupy physical RAM all the time (and show up in + RSS), but they are not anonymous mappings. similar to program code + <braunr> then this anonymous memory is shared by all processes using that + code + <antrik> oh, interesting + <antrik> is it really a completely distinct mapping, rather than just COW? + <braunr> the first is + <braunr> others are COW + <antrik> so if a program loads 200 MB of libraries, they are all read in on + startup, and occupy RAM or swap subsequently, even if most of the code is + never actually run?... + <kilobug> library code should be backed by the library file on disk, not be + swap + <braunr> depends on the implementation + <braunr> I guess most use the file system backend + <braunr> but in the Hurd, ext2fs.static and ld.so.1 use anonymous memory + <braunr> (that's the case for another reason, still, I don't think the + report in top/ps clearly indicates that fact) + <kilobug> braunr: yeah for bootstrapping issues, makes sense + <braunr> it may also depends on the pic/pie options used when building + libraries + + +IRC, freenode, #hurd, 2011-07-24 + + < braunr> the panic is probably due to memory shortage + < braunr> so as antrik suggested, use more swap + < antrik> gg0: you could run "vmstat 1" in another terminal to watch memory + usage + < antrik> that way we will know for sure whether it's related + < braunr> antrik: it's trickier than that + < braunr> it depends if the zones used are pageable + < antrik> braunr: well, if it's a zone map exhaustion, then the swap size + won't change anything?... + < braunr> antrik: in this case no, but if the zone is pageable and the + pager (backing anonymous memory) refuses to create memory because it + estimates it's full (all swap space is reserved), it will fail to + < braunr> too + < braunr> but i don't think there are much pageable zones in the kernel + < antrik> yes, but in that case we can see the exhaustion in vmstat :-) + < braunr> many* + < braunr> i'm not sure + < braunr> reserved swap space doesn't mean it's used + < braunr> that's one of the major changes in freebsd 4 or 5 i was + mentioning + < antrik> if it's reserved, it wouldn't show up as "free", would it?... + < braunr> (btw, it's also what makes anonymous memory merging so hard) + < braunr> yes it would + < braunr> well, it could, i'm not sure + < braunr> anonymous memory is considered as a file + < braunr> one big file filled with zeroes, which is the swap partition + < braunr> when you allocate pageable anonymous memory, a part of this + "file" is reserved + < braunr> but i don't know if the reported number if the reserved + (allocated) space, or used (actually containing data) + < braunr> is* + < braunr> i also suspect wired allocations can fail because of a full swap + (because the kernel is unable to make free pages) + < braunr> in this case vmstat will show it + < antrik> what does it matter whether there is data there or not? if it's + reserved, it's not free. if it behaves differently, I'd consider that a + serious bug + < braunr> maybe the original developers intended to monitor its actual + usage + < braunr> antrik: i've just checked how the free count gets updated, and it + looks like it is on both seqnos_memory_object_data_initialize and + seqnos_memory_object_data_write + < braunr> antrik: so i guess reserved memory is accounted for diff --git a/open_issues/mach_vm_pageout.mdwn b/open_issues/mach_vm_pageout.mdwn new file mode 100644 index 00000000..dac7fe28 --- /dev/null +++ b/open_issues/mach_vm_pageout.mdwn @@ -0,0 +1,19 @@ +[[!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-09-09 + + <slpz> It's amazing how broken some parts of Mach's VM are + <slpz> currently, it doesn't even keep track of the number of external + pages in the lists + <slpz> and vm_pageout_scan produces a hang if want_pages == FALSE (which + never is, because vm_page_external_count is always 0) diff --git a/open_issues/magic_translator_machtype.mdwn b/open_issues/magic_translator_machtype.mdwn new file mode 100644 index 00000000..1c62b762 --- /dev/null +++ b/open_issues/magic_translator_machtype.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="/hurd/magic machtype"]] + +[[!tag open_issue_hurd open_issue_glibc]] + + tschwinge@clubber:~ $ settrans -ca machtype /hurd/magic machtype + tschwinge@clubber:~ $ l mach<TAB>Connection to clubber.bddebian.com closed. + thomas@dirichlet:~ $ ssh clubber + Warning: Permanently added '[clubber.bddebian.com]:2251' (RSA) to the list of known hosts. + Last login: Tue Dec 30 08:52:58 2008 from dslb-084-057-196-016.pools.arcor-ip.net + tschwinge@clubber:~ $ cat machtype + Segmentation fault + tschwinge@clubber:~ $ l machtype + Segmentation fault + tschwinge@clubber:~ $ l mach<TAB>Connection to clubber.bddebian.com closed. diff --git a/open_issues/memory_object_model_vs_block-level_cache.mdwn b/open_issues/memory_object_model_vs_block-level_cache.mdwn new file mode 100644 index 00000000..7da5dea4 --- /dev/null +++ b/open_issues/memory_object_model_vs_block-level_cache.mdwn @@ -0,0 +1,273 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation open_issue_hurd open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-02-14 + + <slpz> Open question: what do you think about dropping the memory object + model and implementing a simple block-level cache? + +[[microkernel/mach/memory_object]]. + + <kilobug> slpz: AFAIK the memory object has more purpose than just cache, + it's allow used for passing chunk of data between processes, handling + swap (which similar to cache, but still slightly different), ... + <slpz> kilobug: user processes usually make their way to data with POSIX + operations, so memory objects are only needed for mmap'ed files + <slpz> kilobug: and swap can be replaced for an in-kernel system or even + could still use the memory object + <braunr> slpz: memory objects are used for the page cache + <kilobug> slpz: translators (especially diskfs based) make heavy use of + memory objects, and if "user processes" use POSIX semantics, Hurd process + (translators, pagers, ...) shouldn't be bound to POSIX + <slpz> braunr: and page cache could be moved to a lower level, near to the + devices + <braunr> not likely + <braunr> well, it could, but then you'd still have the file system overhead + <slpz> kilobug: but the use of memory objects it's not compulsory, you can + easily write a fs translator without implementing memory objects at all + (except to mmap) + <braunr> a unified buffer/VM cache as all modern systems have is probably + the most efficient approach + <slpz> braunr: I agree. I want to look at *BSD/Linux vfs systems to seem + how much cache policy depends on the filesystem + <slpz> braunr: Are you aware of any good papers on this matter? + <braunr> netbsd UVM, the linux virtual memory system + <braunr> both a bit old bit still relevant + <slpz> braunr: Thanks. + <slpz> the problem in our case is that having FS and cache information at + different contexts (kernel vs. translator), I find hard to coordinate + them. + <slpz> that's why I though about a block-level cache that GNU Mach could + manage by itself + <slpz> I wonder how QNX deals with this + <braunr> the point of having a simple page cache is explicitely about not + caring if those pages are blocks or files or whatever + <braunr> the kernel (at least, mach) normally has all the accounting + information it needs to implement its cache policy + <braunr> file system translators shouldn't cache much + <braunr> the pager interface could be refined, but it looks ok to me as it + is + <slpz> Mach has the accounting info, but it's not able to purge the cache + without coordination with translators + <braunr> which is normal + <slpz> And this is a big problem when memory pressure increases, as it + doesn't know for sure when memory is going to be freed + <braunr> Mach flushes its cache when it decides to, and sends back dirty + pages if needed by the pager + <braunr> that's the case with every paging implementation + <braunr> the main difference is security with untrusted pagers + <braunr> but that's another issue + <slpz> but in a monolithic implementation, the kernel is able for force a + chunk of cache memory to be freed without hoping for other process to do + the job + <braunr> that's not true + <braunr> they're not process, they're threads, but the timing issue is the + same + <braunr> see pdflush on linux + <slpz> no, it isn't. + <braunr> when memory is scarce, threads that request memory can either wait + or immediately fail, and if they wait, they're usually woken by one of + the vm threads once flushing is done + <slpz> a kernel thread can access all the information in the kernel, and + synchronization is pretty easy. + <braunr> on mach, synchronization is done with messages, that's even easier + than shared kernel locks + <slpz> with processes in different spaces, resource coordination becomes + really difficult + <braunr> and what kind of info would an external pager need when simply + asked to take back its dirty pages + <braunr> what resources ? + <slpz> just take a look at the thread storm problem when GNU Mach needs to + clean a bunch of pages + <braunr> Mach is big enough to correctly account memory + <braunr> there can be thread storms on monolithic systems + <braunr> that's a Mach issue, not a microkernel issue + <braunr> that's why linux limits the number of pdflush thread instances + <slpz> Mach can account memory, but can't assure when be freed by any + means, in a lesser degree than a monolithic system + <braunr> again i disagree + <braunr> no system can guarantee when memory will be freed with paging + <slpz> a block level cache can, for most situations + <braunr> slpz: why ? + <braunr> slpz: or how i mean ? + <slpz> braunr: with a block-level page cache, GNU Mach should be able to + flush dirty pages directly to the underlaying device without all the + complexity and resource cost involved in a m_o_data_return message. It + can also throttle the rate at which pages are being cleaned, and do all + this while blocking new page allocations to deal with memory exhaustion + cases. + <slpz> braunr: in the current state, when cleaning dirty pages, GNU Mach + sends a bunch on m_o_data_return to the corresponding pagers, hoping they + will do their job as soon and as fast as possible. + <slpz> memory is not really freed, but transformed from page cache to + anonymous memory pertaining to the corresponding translator + <slpz> and GNU Mach never knows for sure when this memory is released, if + it ever is. + <slpz> not being able to flush dirty pages synchronously is a big problem + when you need to throttle memory usage + <slpz> and needing allocating more memory when you're trying to free (which + is the case for the m_o_data_return mechanism) makes the problem even + worse + <braunr> your idea of a block level cache means in kernel block drivers + <braunr> that's not the direction we're taking + <braunr> i agree flushing should be a synchronous process, which was one of + the proposed improvements in the thread migration papers + <braunr> (they didn't achieve it but thought about it for future works, so + that the thread at the origin of the fault would handle it itself) + <braunr> but it should be possible to have kernel threads similar to + pdflush and throttle flush requests too + <braunr> again, i really think it's a mach bug, and having a buffer cache + would be stepping backward + <braunr> the real design issue is allocating memory while trying to free + it, yes + <slpz> braunr: thread migration doesn't apply to asynchronous IPC, and the + entire paging mechanism is implemented this way + <slpz> in fact, trying to do a synchronous m_o_data_return will trigger a + deadlock for sure + <slpz> to achieve synchronous flushing with translators, the entire paging + model must be redesigned + <slpz> It's true that I'm not very confident of the viability of user space + drivers + <slpz> at least, not for every device + <slpz> I know this is against the current ideas for most ukernel designs, + but if we want to achieve real work functionality, I think some + sacrifices must be done. Or at least a reasonable compromise. + <braunr> slpz: thread migration for paging requests implies synchronous + RPC, we don't care much about the IPC layer there + <braunr> and it requires large changes of the VM code in addition, yes + <braunr> let's not talk about this, we don't have thread migration anyway + :p + <braunr> except the allocation-on-free-path issue, i really don't see how + the current pager interface or the page cache creates problems wrt + flushing .. + <braunr> monolithic systems also have that problem, with lower impacts + though, but still + <slpz> braunr: because as it doesn't know when memory is really freed, 1) + it just blindly sends a bunch of m_o_data_return to the pagers, usually + overloading them (causing thread storms), and 2) it can't properly + throttle new page requests to deal with resource exhaustion + <braunr> it does know when memory is really freed + <braunr> and yes, it blindly sends a bunch of requests, they can and should + be trottled + <slpz> but dirty pages freed become indistinguishable from common anonymous + chunks released, so it doesn't really know if page flushes are really + working or not (i.e. doesn't know how fast a device is processing write + requests) + <braunr> memory is freed when the pager deallocates it + <braunr> the speed of the operation is irrelevant + <braunr> no system can rely on disk speed to guarantee correct page flushes + <braunr> disk or anything else + <slpz> requests can't be throttled if Mach doesn't know when they are being + processed + <braunr> it can easily know it + <braunr> they are processed as soon as the request is sent from the kernel + <braunr> and processing is done when the pager acknowledges the end of the + flush + <braunr> memory backing the flushed pages should be released before + acknowleding that to avoid starting new requests too soon + <slpz> AFAIK pagers doesn't acknowledge the end of the flush + <braunr> well that's where the interface should be refined + <slpz> Mach just sends the m_o_data_return and continues on its own + <braunr> that's why flushing should be synrhconous + <braunr> are you sure about that however ? + <slpz> so the entire paging system needs a new design... :) + <slpz> pretty sure + <braunr> not a new design .. + <braunr> there is m_o_supply_completed, i don't see how difficult it would + be to add m_o_data_return_completed + <braunr> it's not a small change, but not a difficult one either + <braunr> i'm more worried about the allocation problem + <braunr> the default pager should probably be wired in memory + <braunr> maybe others + <slpz> let's suppose a case in which Mach needs to free memory due to an + increase in its pressure. vm_pageout_daemon starts running, clean pages + are freed easily, but for each dirty one a m_o_data_return in sent. 1) + when should this daemon stop sending m_o_data_return and start waiting + for m_o_data_return_completed? 2) what happens if the translator needs to + read new blocks to fulfill a write request (pretty common in ext2fs)? + <braunr> it should stop after an arbitrary limit is reached + <braunr> a reasonable one + <braunr> linux limits the number of pdflush threads for that reason as i + mentioned (to 8 iirc) + <braunr> the problem of reading blocks while flushing is what i'm worried + about too, hence the need to wire that code + <braunr> well, i'm nto sure it's needed + <braunr> again, a reasonable about of free memory should be reserved for + that at all times + <slpz> but the work for pdflush seems to be a lot easier, as it only deals + directly with block devices (if I understood it correctly, I just started + looking at it). + <braunr> i don't know how other systems compute that, but this is how they + seem to do as well + <braunr> no, i don't think so + <slpz> well, I'll try to invest a few days understanding how pdflush work, + to see if some ideas can be borrowed for Hurd + <braunr> iirc, freebsd has thresholds in percent for each part of its cache + (active, inactive, free, dirty) + <slpz> but I still think simple solutions work better, and using the memory + object for page cache is tremendously complex. + <braunr> the amount of free cache pages is generally sufficient to + guarantee much memory can be released at once if needed, without flushing + anything + <braunr> yes but that's the whole point of the Mach VM + <braunr> and its greatest advance .. + <slpz> what, memory objects? + <braunr> yes + <braunr> using physical memory as a cache for anything, not just block + buffers + <slpz> memory objects work great as a way to provide a shared image of + objects between processes, but as page cache they are an overkill (IMHO). + <slpz> or, at least, in the way we're using them + <braunr> probably + <braunr> http://lwn.net/Articles/326552/ + <braunr> this can help udnerstand the problems we may have without better + knowledge of the underlying devices, yes + <braunr> (e.g. not being able to send multiple requests to pagers that + don't share the same disk) + <braunr> slpz: actually i'm not sure it's that overkill + <braunr> the linux vm uses struct vm_file to represent memory objects iirc + <braunr> there are many links between that structure and some vfs related + subsystems + <braunr> when a system very actively uses the page cache, the kernel has to + maintain a lot of objects to accurately describe the cache content + <braunr> you could consider this overkill at first too + <braunr> the mach way of doing it just implies some ipc messages instead of + function calls, it's not that overkill for me + <braunr> the main problems are recursion (allocation while freeing, + handling page faults in order to handle flushes, that sort of things) + <braunr> struct file and struct address_space actually + <braunr> slpz: see struct address_space, it contains a set of function + pointers that can help understanding the linux pager interface + <braunr> they probably sufferred from similar caveats and worked around + them, adjusting that interface on the way + <slpz> but their strategy makes them able to treat the relationship between + the page cache and the block devices in a really simple way, almost as a + traditional storage cache. + <slpz> meanwhile on Mach+pager scenario, the relationship between a block + in a file and its underlying storage becomes really blurry + <slpz> this is a huge advantage when flusing out data, specially when + resources are scarce + <slpz> I think the idea of using abstract objects for page cache, loses a + bit the point that we just want to avoid accessing constantly to a slow + device + <slpz> and breaking the tight relationship between the device and its + cache, makes things a lot harder + <slpz> this also manifest itself when flushing clean pages, as things like + having an static maximum for cached memory objects + <slpz> we shouldn't care about the number of objects, we just need to + control the number of pages + <slpz> but as we need the pager to flush pages, we need to keep alive a lot + of control ports to them + <mcsim> slpz: When mo_data_return is called, once the memory manager no + longer needs supplied data, it should be deallocated using + vm_deallocate. So this way pagers acknowledges the end of flush. diff --git a/open_issues/metadata_caching.mdwn b/open_issues/metadata_caching.mdwn new file mode 100644 index 00000000..f7f4cb53 --- /dev/null +++ b/open_issues/metadata_caching.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2012-07-08 + + <braunr> youpi: there is still quite a lot of I/O even for cached objects + <braunr> youpi: i strongly suspect these are for the metadata + <braunr> i.e. we don't have a "buffer cache", only a file cache + <braunr> (gnu is really not unix lol) + <youpi> doesn't ext2fs cache these? + <youpi> (as long as the corresponding object is cached + <youpi> ) + <braunr> i didn't look too much, but if it does, it does a bad job + <braunr> i would guess it does, but possibly only writethrough + <youpi> iirc it does writeback + <youpi> there's a sorta "node needs written" flag somewhere iirc + <braunr> but that's for the files, not the metadata + <youpi> I mean the metadata of the node + <braunr> then i have no idea what happens diff --git a/open_issues/mig_error_reply.mdwn b/open_issues/mig_error_reply.mdwn new file mode 100644 index 00000000..21a5b217 --- /dev/null +++ b/open_issues/mig_error_reply.mdwn @@ -0,0 +1,68 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_mig]] + +\#hurd, freenode, 2010-05-19 + + <cfhammar> ugh, mig server stubs generated from *_reply.defs don't call the server functions when the reply is an error, since the message size is too small... + <cfhammar> term seems to get around it by turning of type checking + <cfhammar> s/of/off + <cfhammar> but streamio doesn't + <cfhammar> luckily the only other program that makes use of a *_reply.defs is crash, and crash_reply.defs' routines only return an error code so it isn't affected + <slpz> cfhammar: could you point me to a stub with that problem? + <cfhammar> slpz: trans/device_replyServer.c:_Xdevice_open_reply (in build dir) + <slpz> cfhammar: So, if I understand it correctly, the problem is that GNU Mach generated stub doesn't properly set the size of the message if there's an error in the function, thus the type checking in user generated stub discards the reply + <cfhammar> slpz: the size is correct, error messages contain just a return value + <cfhammar> slpz: it is the type checking that is at fault imho + <slpz> cfhammar: even when a server wants to return an error, the size of the message should be the same as the reply structure previously defined + <slpz> cfhammar: on the other hand, I can't understand why streamio is using device_open_request (async RPC) instead of device_open (sync RPC)... + <cfhammar> slpz: the server does not always know the proper size, e.g. when it doesn't understand the message + <slpz> cfhammar: what do you mean by "doesn't understand the message"? + <cfhammar> slpz: if it doesn't implement that interface or is the wrong type, etc. + <cfhammar> slpz: in that case the mig stub needs to send out a generic error reply + <cfhammar> slpz: i don't know why streamio uses it either + <slpz> cfhammar: OK, now I see your point. If the server answers with a generic error code (as MIG_*), device_open_reply will not be called, and device_open_request doesn't get an error. + <slpz> cfhammar: good catch :-) + <cfhammar> slpz: all errors are handled the same way, MIG_* is just an example of why it does so + <slpz> cfhammar: on an unrealted note, I think we should get rid of all asynchronous messages sent from the user to the kernel, since they aren't asynchronous except for sending the reply to a different port (the process is really done by the thread calling mach_msg) + <cfhammar> slpz: i'm not not all that familiar with the low-level parts of message passing so i can't really comment + <slpz> cfhammar: in that point I disagree. If the server function can understand the message (so there isn't a MIG_* error), it can send a reply message with the proper size + <cfhammar> slpz: it could, but what is the advantage if we still need to handle generic errors? + <cfhammar> slpz: "sending the reply to a different port", different from what? + <slpz> cfhammar: to differentiate between message marshalling errors and errors generated by the called function + <slpz> cfhammar: in a synchronous RPC, the same call to mach_msg will send the request and receive the reply by providing a mig generated reply port + <slpz> cfhammar: but in an asynchronous, the reply is received by a port previously generated by the function requesting the message + <cfhammar> slpz: ah, that's a clever optimization + <slpz> cfhammar: if the "asynchronous" message is sent to the kernel, the thread calling for mach_msg will execute the server's function, but the reply will be sent to one of these previously generated ports + <slpz> cfhammar: actually you have a synchronous operation replying to a different port. That doesn't make much sense to me :-) + <antrik> slpz: note that most kernel functions can be implemented by userspace servers, in which case they could be really async... + <cfhammar> slpz: not sure how differentiating mig errors from server errors is useful... + <slpz> antrik: define "most kernel functions" ;-) + <cfhammar> slpz: if nothing else kernel rpcs can be proxied, e.g. rpctrace + <slpz> cfhammar: well, think of device_open_request. If the result is not a mig error, you can still device_open_reply an expect it to properly process the return code from the message + <cfhammar> slpz: it should be able to handle all kinds of errors anyway, the result should be the same as with syncronous rpcs + <slpz> cfhammar: yes, you're right. User generated stub should be able to fill the reply with the error code and call to the reply function. + <slpz> cfhammar: Then someone needs to introduce some changes in MiG's magic... + <cfhammar> slpz: yes, a flag to generate reply side of an interface would be ideal + <cfhammar> slpz: then we could toss out *_reply.defs altogether + <slpz> cfhammar: well, that's a different change from what I was thinking + <cfhammar> slpz: how would you change it? + <slpz> cfhammar: just generating stubs which, in case of error, will properly call to the reply function with the error code in its arguments + <cfhammar> slpz: ah yes, i considered that as well, but i don't think mig can actually distinguish the error code from any other int argument + <cfhammar> slpz: i should double check it though + <slpz> cfhammar: I tag can be used to point to argument of this nature + <slpz> cfhammar: s/I/A/ + <cfhammar> slpz: oh, it already is tagged with retcode, intresting + <slpz> cfhammar: OMG, I'm thinking like MiG! ;-P + <cfhammar> slpz: is that a good or bad ; + <cfhammar> slpz: ;-) + <slpz> cfhammar: I don't know, but it's somewhat scary ;-) + <cfhammar> slpz: apparently retcode is only there for comatibility, mig just ignores it... diff --git a/open_issues/mig_portable_rpc_declarations.mdwn b/open_issues/mig_portable_rpc_declarations.mdwn new file mode 100644 index 00000000..084d7454 --- /dev/null +++ b/open_issues/mig_portable_rpc_declarations.mdwn @@ -0,0 +1,58 @@ +[[!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_mig]] + + +# IRC, freenode, #hurd, 2011-11-14 + + <braunr> also, what's the best way to deal with types such as + <braunr> type cache_info_t = struct[23] of integer_t; + <braunr> whereas cache_info_t contains longs, which are obviously not + integer-wide on 64-bits processors + <braunr> ? + <youpi> you mean, to port mach to 64bit? + <braunr> no, to make the RPC declaration portable + <braunr> just in case :) + <youpi> refine integer_t into something more precise + <youpi> such as size_t, off_t, etc. + <braunr> i can't use a single line then + <braunr> struct cache_info contains ints, vm_size_t, longs + <braunr> should i just use the maximum size it can get ? + <braunr> or declare two sizes depending on the word size ? + <youpi> well, I'd say three + <braunr> youpi: three ? + <youpi> the ints, the vm_size_ts, and the longs + <braunr> youpi: i don't get it + <braunr> youpi: how would i write it in mig language ? + <youpi> I don't know the mig language + <braunr> me neither :) + <youpi> but I'd say don't lie + <braunr> i just see struct[23] of smething + <braunr> the original zone_info struct includes both integer_t and + vm_size_t, and declares it as + <braunr> type zone_info_t = struct[9] of integer_t; + <braunr> in its mig defs file + <braunr> i don't have a good example to reuse + <youpi> which is lying + <braunr> yes + <braunr> which is why i was wondering if mach architects themselves + actually solved that problem :) + <braunr> "There is no way to specify the fields of a + <braunr> C structure to MIG. The size and type-desc are just used to + give the size of + <braunr> the structure. + <braunr> " + <braunr> well, this sucks :/ + <braunr> well, i'll do what the rest of the code seems to do, and let it + rot until a viable solution is available + <antrik> braunr: we discussed the problem of expressing structs with MIG in + the libburn thread + <antrik> (which I still need to follow up on... [sigh]) diff --git a/open_issues/mission_statement.mdwn b/open_issues/mission_statement.mdwn new file mode 100644 index 00000000..17f148a9 --- /dev/null +++ b/open_issues/mission_statement.mdwn @@ -0,0 +1,660 @@ +[[!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]] + +[[!toc]] + + +# 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 + + +# IRC, freenode, #hurd, 2011-11-25 + + <antrik> heh, nice: http://telepathy.freedesktop.org/wiki/Rationale + <antrik> most of this could be read as a rationale for the Hurd just as + well ;-) + + +# IRC, freenode, #hurd, 2012-04-06 + + <braunr> LibreMan: the real feature of the hurd is its extensibility + +[[/Extensibility]], [[/advantages]]. + + <braunr> LibreMan: (though it could be improved even further) + <LibreMan> braunr: yeah, I keep reading that ... but that sounds too + abstract, I can not imagine what useful could that provide to the actual + users + <braunr> LibreMan: say fuse, but improved + <braunr> LibreMan: do you see how useful fuse is ? + <braunr> if so, you shouldn't have trouble imagining the gap between linux + without fuse and linux with fuse is about the same as linux with fuse and + the hurd + <braunr> and yes, it's abstract + <braunr> translators are not only about file systems + <LibreMan> braunr: well, its main advantage is that it's running in + user-space and therefore doesn't need root priviledges to mount whatever + fs you want? + <braunr> no + <braunr> you don't need to change the kernel, or implement weird tricks to + get what you want working + <LibreMan> braunr: okay, but there is fuse for Linux ... so the + difference/advantages need to be between Linux WITH fuse and Hurd + <braunr> that's what i'm saying + <LibreMan> the issue I have is that I do not see why anyone would have any + incentive to switch to Hurd + <braunr> there isn't much, which is why we stick with unix instead of, + e.g. plan9 or other advanced systems + <pinotree> try to use fuse on a server where there is no fuse installed + <LibreMan> if I want fuse-like functionallity I just install FUSE, no need + for Hurd ... so the reson to use it is not there + <braunr> LibreMan: read what i wrote + <braunr> using the hurd compared to using linux with fuse is about the same + as using linux with fuse compared to using linux without fuse + <LibreMan> braunr: ah, sorry ... I see + <braunr> it's a step further + <braunr> in theory, developers can add/remove the components they want, + making system development faster and more reliable + <braunr> where with unix, you need stuff like user mode linux or a virtual + machine + <LibreMan> braunr: but in practice it was the opposite so far :) + <braunr> not really + <braunr> it's a lack of manpower + <braunr> not a problem of partice versus theory + <braunr> practice* + <LibreMan> braunr: what do you think are the reasons why Hurd developement + is so slow if it should be faster in theory? + +[[faq/how_many_developers]]. + + <braunr> 17:30 < braunr> it's a lack of manpower + <braunr> pay someone to do the job + <braunr> :p + <LibreMan> braunr: then why does Linux get the manpower but Hurd doesn't? + <braunr> $$ + <LibreMan> braunr: ?? + <braunr> linux developers are paid + <LibreMan> because companies are using it :) + <braunr> yes + <LibreMan> why are they not using Hurd then? + <braunr> because it wasn't reliable enough + <LibreMan> Linux wasn't either at some point + <braunr> sure + <braunr> but when it became, the switch towards its use began + <braunr> now that they have something free and already working, there is no + point switching again + <LibreMan> paid devs join only AFTER volunteers got it to the stage that it + was useful to companies + <braunr> well linux was easier to develop at the beginning (and is still + today because of several kernel hacking features) + <braunr> it followed the traditional unix model, nothing was really new + about it + <LibreMan> braunr: exactly! that's why I think that Hurd needs to have very + compelling technical advantages to overcome that barrier + <braunr> few people/companies really care about such technical advantages + <braunr> they don't care if there are ugly tricks to overcome some problems + <LibreMan> you mean about such that Hurd can provide, right? + <braunr> it's not elegant, but most of the time they're not even aware of + it + <braunr> yes + <LibreMan> that's eaxctly my point ... most people do not care if it's + "elegant" from a programmers POV, they care whether it WORKS + <braunr> well yes + <braunr> what's your point ? + <LibreMan> all I see about Hurd is how "elegant" it is ... but that doesn't + matter if it doesn't provide any practical advantages + <braunr> you want us to expose a killer feature amazing enough to make the + world use our code ? + <LibreMan> well, I want Hurd to succeed and try to identify the resons it + doesn't + <braunr> it does, but not to the point of making people use it + <braunr> unix *is* good enough + <braunr> same reason plan9 "failed" really + <LibreMan> define your idea of Hurd succeeding then, I thought it was to + make it useful to the point that people use it :) + <braunr> there are many other attempts to make better system architectures + <braunr> it is + <braunr> people are still using windows you know, and i really don't see + why, but it does the work for them + <LibreMan> <braunr> you want us to expose a killer feature amazing enough + to make the world use our code ? --- YES ;) + <braunr> other people can think about the same between unix and the hurd + <braunr> LibreMan: well too bad, there is none, because, again, unix isn't + that bad + <braunr> it doesn't prevent us from making a better system that is usable + <LibreMan> to explain my take on this - there are two kind of people, those + who care about philosophy behind software (and its consequences, FSF + etc.) and those who don't + <LibreMan> it's the job of those who do care to make the sw so good that + those who do not care switch to it = victory :) + <LibreMan> as I said the reasons I want Hurd to succeed are more + "political" than technical ... I do not know how many Hurd devs agree + with that kind of sentiment but I'd rather want a GNU project to be in + the forefront than that of a "benevolent dictator" that doesnt' really + care about user freedom + <LibreMan> from thechnical POV I agree that Linux isn't that bad ... it's + quite good, it's the "behind the scenes" stuff I do not like about it + <LibreMan> I'm kind of confused right now ... what exactly is to point of + Hurd then? I thought it was to make it good enough or better than Linux + so users start using it (privatly or corporate) + <LibreMan> is this just a research project that isn't intended to be used + by "general population"? + <braunr> LibreMan: it's an operating system project + <braunr> some people try to make it as good as it can be, but it's not easy + <braunr> it's not a pet or research only system + <LibreMan> braunr: I see what it is ... I'm struggling to see what is the + point of it being an "OS project", what's its intended purpose + <braunr> but it doesn't suit all the needs for a general OS yet + <braunr> LibreMan: a general purpose OS like most free unices + <LibreMan> what are the motivations behind making it as good as it can be + <braunr> for us developers ? + <LibreMan> yes + <braunr> for me, the architecture + <LibreMan> whe you say that linux is goos enough then what's the point? + <braunr> we can do better + <LibreMan> for you it's just a hobby that doesn't have any real goal except + challenging yourself to do it? + <braunr> because of lack of time, you could say that + <LibreMan> so you want Hurd to challenge Linux one day, right? + <braunr> challenging isn't the point + <braunr> i'd like to be able to use it for my needs + <LibreMan> well, that wasn't the right choise of word but to be better than + Linux + <braunr> again, you miss the point + <braunr> i don't care much about hurd vs linux + <LibreMan> your own needs, so you do not want others to use it? + <braunr> i care about the hurd and what i do + <braunr> others would think the same + <braunr> they would want it to work for their needs + <LibreMan> I'm asking about you, do YOU want others to use it? is that one + of your goals? + <braunr> not really + <braunr> i let them do what they want + <LibreMan> ah I see, so it is kind of a hobby project for you - you're + doing to for yourself and your own needs + <LibreMan> and don't care if anyone else uses it or not + <braunr> yes, i don't care much about the politics around such projects tb + <braunr> tbh + <LibreMan> is this kind of sentiment prevalent is the Hurd dev community? + <braunr> i don't work on software to break any benevolent dictator or + anyone in particular + <braunr> i don't know + <braunr> i'd say so, yes + <braunr> but not sure + <braunr> i'm not saying they don't care about freedom, don't get me wrong + <braunr> i'd say we sure prefer free software over open source + <braunr> but i don't think people work on the hurd specifically for these + reasons, rather than the technical ones + <LibreMan> interesting ... from the presentation of the project by + outsiders I got the impression that it is significantly about freedom, + GNU - that those are the main drivers + <braunr> if it really was so, we would have grabbed a bsd variant, + relicenced it with GPLv3, and call it FreeGNU or NetGNU + <LibreMan> and that's how I approached the project ... maybe I was wrong, + I'm kind of disappointed if that's so :) I care about those things a + great deal, in fact that's the only reason I care about Hurd really + + <lcc> the hurd is designed to offer more freedom, in various ways, to the + user. freedom from the admin. + <lcc> right? + <braunr> lcc: that's embedded in the term "extensibility", yes + <braunr> lcc: but there are technical solutions for that on other systems + as well now + + <antrik> as for the Hurd, people who said they are interested in it only + because of freedom aspects *never* contributed anything significant + <antrik> *all* serious contributors are motivated at least equally by the + technical merits; often more + <antrik> (though the fact that it's a GNU project is what has brought many + developers here in the first place...) + <LibreMan> antrik: I would phrase it the other way - why do people who have + contributed significantly not care about freedom that much? or ... how do + you know they don't? + <antrik> most of us *do* care about freedem. but it's not our primary + motivation. the freedom aspects are just not strong enough to motivate + anyone alone + <antrik> as braunr already pointed out, if the sole purpose was creating a + GNU kernel, there would be *much* more promising venues for that + <LibreMan> I do not think so ... if you someone where to just take BSD and + rebrand it as AWSOMEnewGNUkernel it wouldn't be looked upon too favorably + <LibreMan> there is an honor aspect to it, to have something developed by + the community that stands by it + <LibreMan> so I do not think it would work + <antrik> BSD has forked countless times, and several of these forks became + very popular. I don't see why a GNU one shouldn't do well enough + <antrik> bat that's beside the point. writing a new boring monolithic + UNIX-like kernel from scratch is not that hard + <antrik> (as Linus has proven, amonst others...) + <antrik> if the sole purpose would be having a GNU kernel, I'd be strongly + advocating writing a new monolithic kernel from scratch + <LibreMan> antrik: ah, snap! not that hard you say? with all the features + Linux has? sure, it's not hard to make a kernel that barely boots but + that's not the point, is it? :) + <antrik> (yes, even now, with the Hurd being almost usable, I still think + it would be easier to get a new monolithic kernel to production quality) + <LibreMan> antrik: and here is was braunr who was pitching extensibility + and faster developement of Hurd as its advantage - and here you come + saying that it would be easier to write monolithic kernel from scratch + <LibreMan> get your story striaght guys ;) + <antrik> the Hurd makes it easier to develop new features. it's not easier + to get it production-ready in the first place + <LibreMan> antrik: what's the difference of developing a feature that makes + it "production ready" and another one that make it "production ready" for + a different use? + <antrik> features don't make a system production ready + <LibreMan> what makes a system production ready? + <LibreMan> what do you consider a "production"? + <antrik> supporting enough use cases that a non-trivial number of users + have their needs covered; and being stable enough that it's not annoying + to use + <LibreMan> either it is easier to develop or it isn't ... either it is + modular from it's core or it isn't + <antrik> well, not only stable enough, but also performant, secure etc. + <antrik> wrong + <LibreMan> are you saying that the fruits of its modularity will show only + after enough modules have been written? + <antrik> a modular system with strong isolation is inherently more + complicated to get right + <LibreMan> that sure is a weird argument to make ... + <LibreMan> right ... but when you get it right, the further development is + much easier? + <antrik> depends. making fundamental changes to how the system works will + always be tricky. but adding new stuff that doesn't require fundamental + changes, building on the existing foundations, is way easier + <antrik> we believe that once we have the fundamentals mostly right, most + things people will be adding will fall into the latter catogory + <antrik> category + <LibreMan> o what's missing to Hurd before it "got it right" and the fast + pace development kicks in? + <antrik> but so far most of the work is in the former category, meaning + progress is slow + <LibreMan> because from readin the site it seems the core is pretty much + done ... what it needs are all the translators, drivers, user-space tools + to make use of that core - is that impression wrong? + <antrik> you are missing the point. there is no unified "development pace" + measurement. it is easier to add certain things right now. but to get the + system production ready, it still requires considerable work on the hard + parts + <antrik> well, it's not as simple ;-) + <LibreMan> are you sure the work on "the hard parts" is ever going to be + done? :) + <antrik> the core is working, but it is still missing some features, and + it's missing lots of performance optimisation and bug fixing + <LibreMan> it seems more hard parts pop up every time you think it is + almost production ready + <antrik> also, we know today that the core could work much better in some + regards if we make some major changes. not a priority right now, but + something that will have to be addressed in the long run to seriously + compete with other systems + <antrik> well, no software is ever done :-) + <antrik> but I hope we will get to a point where the hard parts work well + enough for most people + <LibreMan> in fact I remember the design of Hurd was specifically chose by + RMS because he thought it would be easier to implement modular system - + that was 20 yeras ago? :) + <antrik> yes, and he admitted later that he was totally wrong on that :-) + <LibreMan> yeah, that was one unlucky choice for GNU ... + <antrik> who knows. it's hard to estimate what would have happened it GNU + chose a different route back then + <LibreMan> so ... Hurd is a hobby project for you too? + <LibreMan> or ... what do you hope to achieve by working on Hurd? + <LibreMan> I'm really interested in the motivations of people behind Hurd + as I'm kind of surprised it's not that much freedom and GNU ... + <antrik> it's a hobby project for everyone -- nobody gets paid for working + on it + <antrik> in the long run, I hope the Hurd to be a good platform for my + higher-level ideas. I have a vision of a desktop environment working + quite differently from what exists today; and I believe the extensible + architecture of the Hurd makes it easier to implement these ideas + <LibreMan> that's not what I meant as you may have guessed from my line of + reasoning so far + <LibreMan> yeah, that's my definition of a hobby project :) not whether one + gets payed to do it or not but whether one does it to satisfy their own + curiosity + <antrik> well, curiosity is clearly too narrow + <LibreMan> as far as I'm concerned I'd have a more "political" goal of + influencing the wider world to move toward more freedom + <antrik> but hackers never work on volunteer projects except to scratch + their own itch, or to work on something they are genuinely interested + in. nobody hacks free software just to save the world + <LibreMan> I find some technical aspects very interesting and fun but if + they wouldn't further the goal of more freedom they'd be without purpose + to me + <antrik> just think of the GNU high priority projects list -- it has zery + effect + <antrik> zero + <LibreMan> yeah ... and I think that is a real shame + <LibreMan> I keep thinking that it's because most hackers do not realize + the importance of freedom and the consequences of not having it + <antrik> it's a shame that some people at the FSF seem to believe they can + tell hackers what to work on :-P + <LibreMan> I do not think anybody at FSF actually believes that + <LibreMan> they believe as I do that we can persuade hackers to work on + things after they themselves recognise the significance of it + <antrik> no. there are many many hackers who genuinely believe in + supporting software freedom (both in the Hurd and in other GNU projects) + -- but there are none who would work on projects they are not personally + interested in because of that + <LibreMan> well, how does one become "personally interested" in a project? + surely it's not something you;re born with ... after recognising a + significance of some project some may become personally interested in it + - and that's the point ;) + <antrik> well, if I you mean nobody realises that software freedom is so + important they should work on it instead of doing things they actually + enjoy... they yes, I guess you are right :-P + <antrik> significance is subjective. just because something may be + important to the general public, doesn't mean I personally care about it + <LibreMan> you keep projecting your own concerns into it + <LibreMan> just because you're not interested in something doesn't mean + someone else isn't + <LibreMan> you approach it from the POV that omebody is telling YOU what + you should do ... + <LibreMan> that is not the case + <antrik> LibreMan: well, but there are obviously things no hackers care + about -- or otherwise there would be no need for the high priority + projects list... it's a list of things that would be important for + software freedom, but nobody is interested in working on. and having a + list of them won't change that fact + <LibreMan> antrik: why do you feel entitled to speak for all hackers? the + projects are high priority exactly because there isn;t enough people + working on them, if they were they wouldn't be high priority :) + <LibreMan> so maybe you have cause and effect mixed up ... + <LibreMan> there is no need to list office suite as hight priority because + there is LibreOffice, if there wasn't I'm sure it would be right there on + the priority list + <antrik> LibreMan: err... how is that different from what I said? + <antrik> these projects are there because there are not enough people + working on them -- i.e. hackers are not interested in them + <LibreMan> you said it in a way the implied that hackers are not interested + in working on projects that are required for providing freedom - but + mostly there are, it's just a few project where aren't - and those are + listed as high priority to bring attention to them + <LibreMan> well, maybe after seeing them on a high priority list some + hackes become interested in them - that is the point :) + <antrik> yes, that's what I implied. the fact that there are projects + hackers aren't working on, although they would be important for software + freedom, proves that this is not sufficient motivation for volunteers + <antrik> if software freedom alone would motivate hackers, there would be + enough people working on important projects + <LibreMan> who ever claimed that freedom alone motivated hackers? :) + <antrik> but there aren't. we have the list, and people are *still* not + working on these projects -- q.e.d. + <LibreMan> I do not get what you're trying to prove + <antrik> the track record so far clearly shows that hackers do *not* become + interested in working on these projects just because they are on the list + <antrik> err... you pretty much claimed that Hurd hackers should be + motivated by freedom alone + <antrik> and expressed great disappointment that we aren't + <braunr> LibreMan: you expected the hurd developers to share the common + goal of freedom mainly, and now you're saying you don't think hackers + would work for freedom alone ? + <LibreMan> freedom mainly == freedom alone? + <braunr> antrik: would you see an objection to using netbsd as a code base + for a mach clone ? + <braunr> LibreMan: you said share the common goal of freedom + <LibreMan> you're twisting my word to suit your own line of reasoning + <braunr> implying we all agree this is the priority + <LibreMan> being a priority doesn't mean it is there "alone", does it? + <braunr> it means it's the only one + <LibreMan> in another words, do you reject the possibility of enjoying + working on a project and doing it for freedom? because it seems you + somehow do not allow for that possibility + <braunr> if we agree on it, we can't have multiple priorities per people + <braunr> yes, that's what we're saying + <braunr> freedom isn't a goal + <braunr> it's a constraint + <braunr> the project *has* to be free + <LibreMan> so if you;re doing something to achieve freedom you can not BY + DEFINITION enjoy it? :D + <braunr> LibreMan: more or less, yes + <braunr> i enjoy the technical aspect, i advocate freedom + <LibreMan> then I've just disproven you :) I do things for freedom and + enjoy them + <braunr> no, not for freedom + <LibreMan> yes, for freedom + <braunr> i'm telling you it's not what motivates me to write code + <LibreMan> if I did not believe in freedom I wouldn't do them + <LibreMan> and I'm not talking about you + <braunr> i believe in freedom, my job consists of developing mostly + proprietary software + <braunr> how can you disprove me if you're not talking about me on this ? + <LibreMan> you said it's not possible IN PRINCIPLE, well antrik did and you + agreed - if you did not follow his line of argument then do not try to + continue where he left off ;) + <braunr> what project have you worked on ? + <LibreMan> my personal ones, nothing big + <braunr> so you're not a hacker, you're excluded from the group considered + <LibreMan> I'll tell you when it cathes on :) + <braunr> (bam) + <LibreMan> so now you decide who is and is not a hacker, well ... :) + <braunr> :) + <LibreMan> but ok, let's not talk about me I concede that I'm a lousy one + if any :) + <LibreMan> what about RMS, do you consider him a hacker? + <braunr> i think he became a hacker for other reasons than freedom + <LibreMan> would you say he is not motivated by freedom (if that can be + even concieved of)? :) + <braunr> and sees freedom as necessary too + <braunr> i can't say, i don't know him + <antrik> braunr: nope. in fact we discussed this in the past. someone even + worked on GSoC project bringing Hurd/Mach features to NetBSD -- but AFAIK + nothing came out of it + <braunr> antrik: ok + <LibreMan> well, he is pretty vocal with plenty of writings ... on the + other hand you seemed to know me well enough to proclaim me a non-hacker + <braunr> i don't know why he worked on emacs and gcc rather than the hurd + :p + <braunr> but something other than freedom must have motivated such choices + <antrik> I'm uncertain though whether NetBSD is a more useful base than + Linux. it would offer advantages on the licensing front, but it would not + offer the advantage that people could just run it on their existing + systems... + <LibreMan> gcc seems pretty significant for Linux lol + <braunr> antrik: true + <LibreMan> or GNU + <braunr> antrik: there are already system call stubs, and the VM is very, + very similar + <braunr> LibreMan: the hurd was too, at the time + <LibreMan> he can not work on everything + <braunr> so he ahd to choose, and based his choice on something else than + freedom (since all these projects are free) + <braunr> i guess he enjoyed emacs more + <antrik> LibreMan: RMS is not much of a practicing hacker anymore + nowadays... + <antrik> braunr: yeah, that's another advantage of using NetBSD as a + base... it might be easier to do + <braunr> LibreMan: what was your original question again ? + <braunr> i've been somewhat ironic since that trademark stuff, i'm serious + again now + <antrik> LibreMan: again, freedom is a factor for many of us; but not the + primary motivation + <antrik> (as braunr put, being free software is mandatory for us; but that + doesn't mean the main reason for working on the Hurd is some indirect + benefit for the free software movement...) + <LibreMan> braunr: the original goal was to understand the strong points of + Hurd to I can help communicate them to other hackers who might be + interested in Hurd + <LibreMan> because I wanted it to succeed to advance freedom more + <antrik> LibreMan: well, practice what you preach ;-) + <LibreMan> but now that I've founf that not even devs themselves are that + much interested in freedom I do not have that desire anymore + <antrik> you will hardly motivate other hackers to work on something you do + not even work on yourself... + <LibreMan> and focus my attention somewhere else + <antrik> [sigh] + <braunr> well, you can now state that the hurd has an elegant architecture + allowing many ugly hacks to disappear, and that it doesn't yet handle + sata drives or usb keys or advandced multicast routing or ... + <antrik> LibreMan: how about you listen to what we are saying? + <LibreMan> antrik: so I should work on everything in the world that + advances freedom or shut up? + <antrik> LibreMan: we *are* interested in freedom. we would work on nothing + else than a free software system. it's just not the primary motivation + for working on the Hurd + <antrik> if you primary motivation is advancing free software, the Hurd is + probably indeed not the right project to work on. other projects are more + important for that + <antrik> and that's got nothing to do with our priorities + <antrik> it's simply a matter of what areas free software is most lacking + in. the kernel is not one of them. + <braunr> antrik: my primary concern with netbsd are drivers + <LibreMan> I naively assumed that people working on a GNU project will + share GNU vlaues, instead I find that some of them poke fun at its high + priority projects + <braunr> i poke fun at you + <braunr> because you think trademark has any real value on the free + software community + <LibreMan> braunr: I see, congratulations ... I hope you enjoy it + <antrik> if there were no suitable free software kernels around, many + people might work on the Hurd mostly to advance free software. but as it + stands, having a GNU kernel is secondary + <braunr> yes, freedom is a primary goal when there are no free alternatives + <antrik> LibreMan: you are accusing us of not sharing GNU values, which is + quite outrageous I must say + <braunr> LibreMan: actually no, i'd prefer converstation with someone who + understands what i'm saying + <braunr> even if he contradicts me, like antrik often does + <braunr> (but he's usually right) + <braunr> LibreMan: you just don't want to accept some (many) of us are here + more for technical reasons than ethical ones + <LibreMan> antrik: well, some of your reasoning and tone would seem to + suggest so ... + <braunr> i didn't see antrik being particularly aggressive, but personally, + i react badly to stupidity + <LibreMan> braunr: WHAT? I've never said anything about what you should or + should not do or believe + <braunr> you clearly expected something when you first arrived + <LibreMan> I said I personally expected more enhusiastic people concerning + GNU and freedom but that was my personal expectaion and my personal + disappointment + <antrik> what makes you think we are not enthusiastic about GNU and + software freedom? + <braunr> more enthusiastic is vague, you expected us to be some sort of + freedom fighters + <antrik> just for the record, I'm part of the German core team of the FSFE + <braunr> i even stated early that we're mostly part of the free software + rather than open source movement, and you still find our point of view + disappointing + <antrik> still, it's not my major motivation for working on the Hurd + <antrik> I don't see any contradiction in that + <LibreMan> I don;t know maybe I misunderstand you, I do not mean any + disrespect + <braunr> me neither + <LibreMan> maybe "hackers" truly do think differently than I expected them + to in general and it's not specific to Hurd + <braunr> well the very word hacker describe someone interested by "hacking" + down something to get to understand it + <braunr> it's strongly technical + <LibreMan> antrik: why are you a core team member of th FSFE? what do you + do there and why? is that not motivated by the desire for more freedom? + <braunr> and we're lucky, many of them aren't deeply concerned with money + and secrecy, and prefer being open about their work + <braunr> you still don't get it ... + <antrik> LibreMan: of course it is + <antrik> and hacking free software in general also is (partly) motivated by + that + <antrik> but hacking on the Hurd specifically not so much + <braunr> 20:23 < antrik> LibreMan: we *are* interested in freedom. we would + work on nothing else than a free software system. it's just not the + primary motivation for working on the Hurd + <braunr> he already answered your question there + <antrik> (as I already said, it *is* in fact part of the motivation in my + case... just not the major part) + <LibreMan> antrik: but if it ever achieved wide success and you would be + asy on a "board" to decide future direction would you choose for exacmple + to prevent TiVO-ization over wider adpotion? + <braunr> we already answered that too + <antrik> LibreMan: that's actually not even for us to decide, as long as we + are an official GNU project + <antrik> but of course we are a GNU project because we *do* believe in + software freedom, and obviously wouldn't accept Tivoisation + <braunr> (and our discussion about using netbsd as a code base is a + relevant example of license concerns) + <LibreMan> I'm really trying to get to the core of "not motivated by + freedom" but being "interested in freedom" ... I really do not get that, + if you are interested in freedom wouldn't you want a project you work on + being used to advance it as much as possible and therefore be also + motivated to do it the best while enjoying it to achieve the goal of more + freedom since you value it that much? + <braunr> LibreMan: except for the GPLv2 vs GPLv3 debate, i don't see where + there can be a conflict between freedom and technical interest + <LibreMan> braunr: the issues around freedom are mainly not technical + ... GPLv2 and GPLv3 is also not about technical interests + <braunr> that's my problem with you, i fail to see where the problem you + think of is + <LibreMan> it tends to be about the possibility to extract money and impose + your will on the users which turns out to be highly profitable and + politicaly desirable in some instances + <LibreMan> of course it's technically the best to open-source but how are + you going to sell a product like that? that is the main question + troubling most corporations + <LibreMan> ok, I'm not going to bore you any more ;) I found out what I + needed to know ... now I'm going to try to forget about Hurd and focus on + something else where my help can be more effective at achieving what I + want ;) good luck with your endavours + <antrik> LibreMan: of course we hope for the Hurd to advance the cause of + freedom, just like any free software we would work on... still, it's not + the primary reason why we work on the Hurd, instead of the myriads of + other free software projects out there + + +# IRC, freenode, #hurd, 2012-04-09 + + <antono> what is the most impressive thing about hurd you wold like to + promote? + <antono> killing feature + <antono> i've created some simple hurd screencasts here + http://shelr.tv/records/search?utf8=%E2%9C%93&q=hurd + <antono> but probably i could share something more interesting :) + <antrik> antono: if we had such an obvious killer feature, we wouldn't have + to struggle ;-) + <antrik> the problem is that the advantages of the Hurd architecture are + too abstract for the vast majority of people to take them seriously + <antrik> IMHO the most interesting part of the Hurd is the fully + decentralised (and thus infinitely extensible) VFS mechanism + <antrik> but even that is very abstract... + <antono> antrik: cand i do somenthing relly fundamental with hurd + translator? + <antono> for example i hate old school unix FHS + <antono> I would like to have only /Users/me and /System/GNU + <antono> and i would like to only see it, but behinde the scenes it should + be Debian with FHS layout + <antono> is it possible? + <antrik> antono: of course. not sure translators offer much advantage over + FUSE in this case though... it doesn't really change the functionality of + the VFS; only rearranges the tree a bit + <antrik> (might even be doable with standard Linux features) diff --git a/open_issues/mmap_crash_etc.mdwn b/open_issues/mmap_crash_etc.mdwn new file mode 100644 index 00000000..4946a5a0 --- /dev/null +++ b/open_issues/mmap_crash_etc.mdwn @@ -0,0 +1,95 @@ +[[!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]]."]]"""]] + +Several issues here: + + * [[!tag open_issue_glibc open_issue_gnumach]] Even invalid `mmap` shoudn't + crash the process. + + * [[!tag open_issue_documentation]] The memory layout example should be + documented. + + * [[!tag open_issue_gnumach]] New `vm_map` allocation strategy may be + desirable; see also [[placement_of_virtual_memory_regions]]. + + * [[!tag open_issue_glibc]] *task X deallocating an invalid port Y, most + probably a bug*. + +IRC, freenode, #hurd, 2011-08-11 + + < zyg> oh, mmap sigsegvs, strange. + < braunr> hwo do you see that ? + < zyg> braunr: I'll try to paste a minimal case + < braunr> zyg: make sure you have a sane memory setup + < braunr> 512 RAM / 1G swap seems good + < braunr> have more swap than RAM + < zyg> I have those. Still it shouldn't sigsegv. + < braunr> gnumach is picky about that + < braunr> and yes, the hurd shouldn't have bugs + < zyg> braunr: ready to crash? #include <stdio.h> #include <sys/mman.h> int + main (int argc, char **argv) { mmap(0x10000, 0x8000, PROT_READ, MAP_ANON + | MAP_FIXED, -1, 0); return 0; } + < braunr> a fixed mapping at such an address is likely to fail, yes + < braunr> but a crash, hm + < zyg> why should it fail? + < braunr> because the hurd doesn't have a common text data bss heap stack + layout + < braunr> e.g. there are mappings below text, as show by vminfo : + < braunr> $ vminfo $$ + < braunr> 0[0x1000] (prot=0) + < braunr> 0x1000[0x21000] (prot=RX, max_prot=RWX, mem_obj=105) + < braunr> 0x22000[0x1000] (prot=R, max_prot=RWX, mem_obj=105) + < braunr> 0x23000[0x1000] (prot=RW, max_prot=RWX, mem_obj=105) + < braunr> 0x24000[0x1000] (prot=0, max_prot=RWX) + < braunr> 0x25000[0xfff000] (prot=RWX, mem_obj=106) + < braunr> 0x1024000[0x1000] (prot=RWX, mem_obj=107) + < braunr> 0x1025000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108) + < braunr> 0x1026000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108, + offs=0x1000) + < braunr> 0x1027000[0x1000] (prot=RW, max_prot=RWX, mem_obj=109) + < braunr> 0x1028000[0x2000] (prot=RW, max_prot=RWX, mem_obj=110, + offs=0x1000) + < braunr> 0x102a000[0x1000] (prot=RW, max_prot=RWX, mem_obj=111) + < braunr> (sorry for the long paste) + < zyg> oh.. my mmap falls into an occupied range? + < braunr> seems so + < zyg> thanks, that was really useful. + < braunr> MAP_FIXED isn't portable, this is clearly stated in most man + pages + < zyg> yes, implementation specific it says + < braunr> well the behaviour isn't specific, it's well defined, but the + memory layout isn't + < braunr> i personally think vm_map() should be slightly changed to include + a new flag for top-down allocations + < braunr> so that our stack and libraries are at high addresses, below the + kernel + < braunr> zyg: what kind of error do you get ? i don't get sigsegv + < zyg> I get both sigsegv and sigill depending on addr + < braunr> ok + < braunr> i get sigill with your example + < braunr> the error is the same (wrong memory access) but the behaviour + changes because of the special memory configuration + < zyg> yes.. I guess the usecase is too uncommon. Else mmap would have an + guard + < braunr> some accesses cause invalid page faults (which are sent as + segmentation faults) while other cause general protection faults (which + are sent as illegal instructions) + < braunr> (this is quite weird since the GP fault is likely because the + access targets something out of the data or code segment eh) + < zyg> braunr: that's very os-specific. Do you mean hurd behaves that way? + < braunr> gnumach + < braunr> on i386 + < braunr> the segmant configuration isn't completely flat + < braunr> segment* + < braunr> hm nice + < braunr> your small program triggers the "task X deallocating an invalid + port Y, most probably a bug." message + < zyg> where do you see that? + < braunr> on the mach console diff --git a/open_issues/mmap_write-only.mdwn b/open_issues/mmap_write-only.mdwn new file mode 100644 index 00000000..467274c5 --- /dev/null +++ b/open_issues/mmap_write-only.mdwn @@ -0,0 +1,56 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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-12-14 + + <pinotree> hm, interesting mmap bug + <youpi> ? + <pinotree> youpi: http://paste.debian.net/149252/ + #include <sys/types.h> + #include <sys/mman.h> + #include <fcntl.h> + #include <stdio.h> + #include <errno.h> + #include <stdlib.h> + #include <string.h> + #include <unistd.h> + + void die(int x, const char *s) + { + perror(s); + exit(x); + } + + static const char s_file[] = "foo-mmaptest"; + + int main() + { + int fd; + void *p; + + fd = creat(s_file, 0777); + if (fd < 0) die(1, "creat"); + errno = 0; + p = mmap(NULL, 1, PROT_READ, MAP_SHARED, fd, 0); + printf("> %p vs %p, %d (%s)\n", p, MAP_FAILED, errno, strerror(errno)); + unlink(s_file); + return (p != MAP_FAILED); + } + <pinotree> on linux it returns 0 and fails with EACCESS (as it seems it + should, by reading the mmap posix docs), on hurd it returns 1 and the + mmap succeeds + <pinotree> (taken from llvm's configure) + <youpi> why should it? file size extension ? + <pinotree> creat creates a o_wronly file, while the mmap specifies only + read protection + <youpi> oh, craet is always wo + <youpi> I didn't know that diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn new file mode 100644 index 00000000..562ccd83 --- /dev/null +++ b/open_issues/multiprocessing.mdwn @@ -0,0 +1,82 @@ +[[!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 +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 open_issue_hurd]] + +We would expect that fine-grained, compartmentalized systems, that is, +microkernel-based multi-server systems in particular, would be ideal candidates +for applying multiprocessing. That is, however, only true from a first and +inexperienced point of view: there are many difficulties. + + +IRC, freenode, #hurd, August / September 2010 + + <marcusb> silver_hook: because multi-server systems depend on inter-process + communication, and inter-process communication is many times more + expensive across cpus + <marcusb> silver_hook: so you either force interrelated work on the same + cpu, or suffer heavy penalties. and in a typical fine-grained object + system, all objects are interconnected! + <marcusb> silver_hook: resources in today's systems, even in a single node + with one cpu, but more so in a network, are very non-uniform. scheduling + these resources efficiently is a huge problem. restricting the resource + distribution policies in the way microkernel systems tend to do is posing + serious research challenges + + +IRC, freenode, #hurd, 2011-07-26 + + < braunr> 12:03 < CTKArcher> and does the hurd take more advantages in a + multicore architecture than linux ? + < braunr> CTKArcher: short answer: no + < CTKArcher> it's easier to imagine one server pro core than the linux + kernel divided to be executed on multiple cores + < braunr> CTKArcher: this approach is less efficient + < braunr> CTKArcher: threads carry state, both explicit and implicit (like + cache data) + < braunr> CTKArcher: switching to another core means resetting and + refetching this state + < braunr> it's expensive and there is no gain obtained by doing this + < braunr> thread migration (having a thread from a client also run in + servers when making synchronous RPC, even handling its own page faults) + was implemented in mach4 and is imo a very good thing we should have + < braunr> CTKArcher: and concerning linux, it's actually very scalable + < braunr> it's already like if all client threads run in servers (the + kernel is the servers there) + < braunr> rcu is used a lot + < braunr> thread migration already takes into account smt, cores, and numa + < braunr> it's hard to do something better + < braunr> (here, thread migration means being dispatched on another cpu) + < braunr> some systems like dragonflybsd go as far as to pin threads on one + processor for their entire lifetime + < braunr> in order to have rcu-like locking almost everywhere + < braunr> (you could argue it's less efficient since in the worst case + everything runs on the same cpu, but it's very unlikely, and in practice + most patterns are well balanced) + + +debian-hurd list + +On Thu, Jan 02, 2003 at 05:40:00PM -0800, Thomas Bushnell, BSG wrote: +> Georg Lehner writes: +> +> > - One promise of the microkernel architecture is better performance on +> > multiprocessor systems, or multicomputer systems. What is the status +> > of Gnu Mach with respect to these. +> +> This may or may not be true. The Hurd is built around a microkernel +> architecture because of its conceptual elegance and flexibility. +> Other touted advantages may be more illusory than real, at least, they +> aren't something *we* are proclaiming is our motivation. + + +--- + +See also: [[multithreading]]. diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn new file mode 100644 index 00000000..5924d3f9 --- /dev/null +++ b/open_issues/multithreading.mdwn @@ -0,0 +1,72 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +Hurd servers / VFS libraries are multithreaded. + + +# Implementation + + * well-known threading libraries + + * [[hurd/libthreads]] + + * [[hurd/libpthread]] + + +# Design + +See [[hurd/libports]]: roughly using one thread per +incoming request. This is not the best approach: it doesn't really make sense +to scale the number of worker threads with the number of incoming requests, but +instead they should be scaled according to the backends' characteristics. + +The [[hurd/Critique]] should have some more on this. + +[*Event-based Concurrency +Control*](http://soft.vub.ac.be/~tvcutsem/talks/presentations/T37_nobackground.pdf), +Tom Van Cutsem, 2009. + + +## IRC, freenode, #hurd, 2012-07-08 + + <youpi> braunr: about limiting number of threads, IIRC the problem is that + for some threads, completing their work means triggering some action in + the server itself, and waiting for it (with, unfortunately, some lock + held), which never terminates when we can't create new threads any more + <braunr> youpi: the number of threads should be limited, but not globally + by libports + <braunr> pagers should throttle their writeback requests + <youpi> right + + +# Alternative approaches: + + * <http://www.concurrencykit.org/> + + * Continuation-passing style + + * [[microkernel/Mach]] internally [[uses + continuations|microkernel/mach/continuation]], too. + + * [[Erlang-style_parallelism]] + + * [[!wikipedia Actor_model]]; also see overlap with + {{$capability#wikipedia_object-capability_model}}. + + * [libtcr - Threaded Coroutine Library](http://oss.linbit.com/libtcr/) + + * <http://monkey.org/~provos/libevent/> + +--- + +See also: [[multiprocessing]]. diff --git a/open_issues/multithreading/erlang-style_parallelism.mdwn b/open_issues/multithreading/erlang-style_parallelism.mdwn new file mode 100644 index 00000000..75539848 --- /dev/null +++ b/open_issues/multithreading/erlang-style_parallelism.mdwn @@ -0,0 +1,201 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, #hurd, 2010-10-05 + + <sdschulze> antrik: Erlang-style parallelism might actually be interesting + for Hurd translators. + <sdschulze> There are certain similarities between Erlang's message boxes + and Mach ports. + <sdschulze> The problem is that all languages that implement the Erlang + actor model are VM-based. + <antrik> sdschulze: I guess that's because most systems don't offer this + kind of message passing functionality out of the box... perhaps on Hurd + it would be possible to implement an Erlang-like language natively? + <sdschulze> That would be quite attractive -- having the same API for + in-process parallelism and IPC. + <sdschulze> But I don't see why Erlang needs a VM... It could also be + implemented in a library. + [...] + <sdschulze> BTW, Scala doesn't require a VM by design. Its Erlang + implementation is a binary-compatible abstraction to Java. + [...] + <sdschulze> My point was that Erlang employs some ideas that might be + usable in the Hurd libraries. + <sdschulze> concerning multithreading stuff + <sdschulze> Unfortunately, it will not contribute to readability if done in + C. + <antrik> perhaps it's worth a look :-) + <sdschulze> Actually, a Mach port is pretty close to an Erlang actor. + <sdschulze> Currently, your I/O callbacks have to block when they're + waiting for something. + <sdschulze> What they should do is save the Mach port and respond as soon + as they can. + <sdschulze> So there should be a return status for "call me later, when I + tell you to" in the callbacks. + <sdschulze> Then the translator associates the Mach port with the summary + of the request in some data structure. + <sdschulze> As soon as the data is there, it tells the callback function to + appear again and fulfills the request. + <sdschulze> That's -- very roughly -- my idea. + <sdschulze> Actually, this eliminates the need for multithreading + completely. + <antrik> sdschulze: not sure whether you are talking about RPC level or + libc level here... + <sdschulze> It should be transparent to libc. + <sdschulze> If the client does a read() that cannot be answered immediatly, + it blocks. + <sdschulze> The difference is that there is no corresponding blocking + thread in the translator. + <antrik> ah, so you are talking about the server side only + <sdschulze> yes + <antrik> you mean the callback functions provided by the translator + implementation should return ASAP, and then the dispatcher would call + them again somehow + <sdschulze> allowing the server to be single-threaded, if desired + <sdschulze> exactly + <sdschulze> like: call_again (mach_port); + <antrik> but if the functions give up control, how does the dispatcher know + when they are ready to be activated again? or does it just poll? + <sdschulze> The translator knows this. + <sdschulze> hm... + <antrik> well, we are talking about the internal design of the translator, + right? + <antrik> I'm not saying it's impossible... but it's a bit tricky + <antrik> essentially, the callbacks would have to tell the dispatcher, + "call me again when there is an incoming message on this port" + <sdschulze> Say we have a filesystem translator. + <antrik> (or rather, it probably should actually call a *different* + callback when this happens) + <sdschulze> The client does a "read(...)". + <sdschulze> => A callback is called in the translator. + <antrik> let's call it disfs_S_io_read() ;-) + <antrik> err... diskfs + <sdschulze> The callback returns: SPECIAL_CALL_ME_LATER. + <sdschulze> yes, exactly that :) + <sdschulze> But before, it saves the position to be read in its internal + data structure. + <sdschulze> (a sorted tree, whatever) + <sdschulze> The main loop steps through the data structure, doing a read() + on the underlying translator (might be the disk partition). + <sdschulze> "Ah, gotcha, this is what the client with Mach port number 1234 + wanted! Call his callback again!" + <sdschulze> Then we're back in diskfs_S_io_read() and supply the data. + <antrik> so you want to move part of the handling into the main loop? while + I'm not fundamentally opposed to that, I'm not sure whether the + dispatcher/callback approach used by MIG makes much sense at all in this + case... + <antrik> my point is that this probably can be generalised. blocking + operations (I/O or other) usually wait for a reply message on a port -- + in this case the port for the underlying store + <antrik> so the main loop would just need to wait for a reply message on + the port, without really knowing what it means + <sdschulze> on what port? + <antrik> so disfs_S_io_read() would send a request message to the store; + then it would return to the dispatcher, informing it to call + diskfs_S_io_read_finish() or something like that when there is a message + on the reply port + <antrik> main loop would add the reply port to the listening port bucket + <antrik> and as soon as the store provides the reply message, the + dispatcher would then call diskfs_S_io_read_finish() with the reply + message + <sdschulze> yes + <antrik> this might actually be doable without changes to MIG, and with + fairly small changes to libports... though libdiskfs etc. would probably + need major rewrites + <sdschulze> What made me think about it is that Mach port communication + doesn't block per se. + <antrik> all this is however ignoring the problem I mentioned yesterdays: + we need to handle page faults as well... + <sdschulze> It's MIG and POSIX that block. + <sdschulze> What about page faults? + <antrik> when the translator has some data mapped, instead of doing + explicit I/O, blocking can occur on normal memory access + <sdschulze> antrik: Well, I've only been talking about the server side so + far. + <antrik> sdschulze: this *is* the server side + <antrik> sdschulze: a filesystem translator can map the underlying store + for example + <antrik> (in fact that's what the ext2 translator does... which is why we + had this 2G partition limit) + <sdschulze> antrik: Ah, OK, so in other words, there are requests that it + can answer immediatly and others that it can't? + <antrik> that's not the issue. the issue is the the ext2 translator doesn't + issue explicit blocking io_read() operations on the underlying + store. instead, it just copies some of it's own address space from or to + the client; and if the page is not in physical memory, blocking occurs + during the copy + <antrik> so essentially we would need a way to return control to the + dispatcher when a page fault occurs + <sdschulze> antrik: Ah, so MIG will find the translator unresponsive? (and + then do what?) + <antrik> sdschulze: again, this is not really a MIG thing. the main loop is + *not* in MIG -- it's provided by the tranlator, usually through libports + <sdschulze> OK, but as Mach IPC is asynchronous, a temporarily unresponsive + translator won't cause any severe harm? + <sdschulze> antrik: "Easy" solution: use a defined number of worker + threads. + <antrik> sdschulze: well, for most translators it doesn't do any harm if + they block. but if we want to accept that, there is no point in doing + this continuation stuff at all -- we could just use a single-threaded + implementation :-) + <sdschulze> Hard solution: do use explicit I/O and invent a + read_no_pagefault() call. + <antrik> not sure what you mean exactly. what I would consider is something + like an exception handler around the copy code + <antrik> so if an exception occurs during the copy, control is returned to + the dispatcher; and once the pager informs us that the memory is + available, the copy is restarted. but this is not exacly simple... + <sdschulze> antrik: Ah, right. If the read() blocks, you haven't gained + anything over blocking callbacks. + * sdschulze adopted an ML coding style for his C coding... + <sdschulze> antrik: Regarding it on the Mach level, all you want to do is + some communication on some ports. + <sdschulze> antrik: Only Unix's blocking I/O makes you want to use threads. + <sdschulze> Unless you have a multicore CPU, there's no good reason why you + would *ever* want multithreading. + <sdschulze> (except poor software design) + <sdschulze> antrik: Is there a reason why not to use io_read? + <antrik> sdschulze: I totally agree about multithreading... + <antrik> as for not using io_read(): some things are easier and/or more + efficient with mapping + <antrik> the Mach VM is really the most central part of Mach, and it's + greatest innovation... + <sdschulze> antrik: If you used explicit I/O, it would at least shift the + problem somewhere else... + <antrik> sure... but that's a workaround, not a solution + <sdschulze> I'm not sure how to deal with page faults then -- I know too + little about the Hurd's internal design. + <sdschulze> Non-blocking io_read only works if we address the client side, + too, BTW. + <sdschulze> which would be quite ugly in C IMHO + <sdschulze> announce_read (what, to, read, when_ready_callback); + <antrik> sdschulze: POSIX knows non-blocking I/O + <antrik> never checked how it works though + <sdschulze> Yes, but I doubt it does what we want. + <antrik> anyways, it's not too hard to do non-blocking io_read(). the + problem is that then you have to use MIG stubs directly, not the libc + function + <sdschulze> And you somehow need to get the answer. + <sdschulze> resp. get to know when it's ready + <antrik> the Hurd actually comes with a io_request.defs and io_reply.defs + by default. you just need to use them. + <sdschulze> oh, ok + <antrik> (instead of the usual io.defs, which does a blocking send/receive + in one step) + <sdschulze> I'd be interested how this works in Linux... + <antrik> what exactly? + <sdschulze> simultaneous requests on one FS + <antrik> ah, you mean the internal threading model of Linux? no idea + <sdschulze> if it uses threading at all + <antrik> youpi probably knows... and some others might as well + <sdschulze> Callbacks are still ugly... diff --git a/open_issues/neals_hurd-misc_papers.mdwn b/open_issues/neals_hurd-misc_papers.mdwn new file mode 100644 index 00000000..7f4e1e3b --- /dev/null +++ b/open_issues/neals_hurd-misc_papers.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +<http://walfield.org/pub/people/neal/papers/hurd-misc/> + + <tschwinge> neal: We could put that into the wiki some day, I think. + <neal> sure diff --git a/open_issues/network_file_system_by_just_forwarding_rpcs.mdwn b/open_issues/network_file_system_by_just_forwarding_rpcs.mdwn new file mode 100644 index 00000000..de1d63a3 --- /dev/null +++ b/open_issues/network_file_system_by_just_forwarding_rpcs.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, #hurd, August / September 2010 + + <jkoenig> btw, it should be possible to implement a network "filesystem" by + just forwarding RPCs over the network, right? + <jkoenig> (of course auth would be an additional concern) + <jkoenig> that would open all kinds of possibilities, possibly. + <LarstiQ> jkoenig: plan9? + <jkoenig> I don't know much about plan9 yet. I seem to remember some mach + extension for network transparency being mentionned somewhere.. diff --git a/open_issues/nfs_trailing_slash.mdwn b/open_issues/nfs_trailing_slash.mdwn new file mode 100644 index 00000000..90f138e3 --- /dev/null +++ b/open_issues/nfs_trailing_slash.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-05-27 + + <gg0> ok, on nfs "mkdir dir0" succeeds, "mkdir dir0/" fails. RPC struct is bad + + +## IRC, freenode, #hurd, 2012-05-27 + + <gg0> 150->dir_mkdir ("foo1/" 493) = 0x40000048 (RPC struct is bad) + <gg0> task2876->mach_port_deallocate (pn{ 18}) = 0 + <gg0> mkdir: 136->io_write_request ("mkdir: " -1) = 0 7 + <gg0> cannot create directory `/nfsroot/foo1/' 136->io_write_request + ("cannot create directory `/nfsroot/foo1/'" -1) = 0 40 + <gg0> : RPC struct is bad 136->io_write_request (": RPC struct is bad" -1) + = 0 19 + <gg0> 136->io_write_request (" + <gg0> " -1) = 0 1 + <tschwinge> gg0: Yes, I think we knew about this before. Nobody felt like + working on it yet. Might be a nfs, libnetfs, glibc issue. + <tschwinge> gg0: If you want to work on it, please ask here or on bug-hurd + if you need some guidance. + <gg0> yeah found this thread + http://lists.gnu.org/archive/html/bug-hurd/2008-04/msg00069.html I don't + think I'll work on it diff --git a/open_issues/nice_changes_priority_of_parent_shell.mdwn b/open_issues/nice_changes_priority_of_parent_shell.mdwn new file mode 100644 index 00000000..d731ef82 --- /dev/null +++ b/open_issues/nice_changes_priority_of_parent_shell.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_glibc]] + + * <http://bugs.debian.org/44039> + + * Also see [[nice_vs_mach_thread_priorities]]. diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn new file mode 100644 index 00000000..e6b68134 --- /dev/null +++ b/open_issues/nice_vs_mach_thread_priorities.mdwn @@ -0,0 +1,197 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_glibc]] + +This issue has been known for some time, due to coreutils' testsuite choking +when testing *nice*: <http://bugs.debian.org/190581>. + +There has been older discussion about this, too, but this is not yet captured +here. + +IRC, #hurd, August 2010 + + <pochu> I'm reading Mach and POSIX documentation to understand the priorities/nice problems + <pochu> antrik said it would be better to reimplement everything instead of fixing the current Mach interfaces, though I'm not sure about that yet + <youpi> uh, so he changed his mind? + <pochu> it seems POSIX doesn't say nice values should be -20..20, but 0..(2*NZERO - 1) + <youpi> he said we could just change the max priority value and be done with it :) + <pochu> so we can probably define NZERO to 16 to match the Mach range of 0..31 + <youpi> s/said/had said previously/ + <antrik> youpi: POSIX is actually fucked up regarding the definition of nice values + <antrik> or at least the version I checked was + <pochu> antrik: why? this says the range is [0,{NZERO}*2-1], so we can just set NZERO to 16 AFAICS: http://www.opengroup.org/onlinepubs/9699919799/functions/getpriority.html + <antrik> it talkes about NZERO and all; making it *look* like this could be defined arbitrarily... but in other places, it's clear that the standard 40 level range is always assumed + <antrik> anyways, I totally see no point in deviating from other systems in this regard. it can only cause problems, and gives us no benefits + <cfhammar> it says NZERO should be at least 20 iirc + <youpi> agreed + <antrik> I don't remember the details; it's been a while since I looked at this + <antrik> youpi: changing the number of levels is only part of the issue. I'm not sure why I didn't mention it initially when we discussed this + <antrik> youpi: I already concluded years ago that it's not possible to implement nice levels correctly with the current Mach interfaces in a sane fashion + <antrik> (it's probably possible, but only with a stupid hack like setting all the thread priorities one by one) + <antrik> youpi: also, last time we discussed this, I checked how the nice stuff works currently on Hurd; and concluded that it's so utterly broken, that there is no point in trying to preserve *any* compatibility. I think we can safely throw away any handling that is alread there, and do it over from scratch in the most straightforward fashion + <pochu> antrik: I've thought about setting NZERO to 16 and doing exactly what you've just said to be a hack (setting all the thread priorities one by one) + <pochu> but there seems to be consensus that that's undesirable... + <pochu> indeed, POSIX says NZERO should be at least 20 + <antrik> pochu: BTW, I forgot to say: I'm not sure you appreciate the complexity of setting the thread max priorities individually + <pochu> antrik: I don't. would it be too complex? I imagined it would be a simple loop :) + <antrik> pochu: in order to prevent race conditions, you have to stop all other threads before obtaining the list of threads, and continue them after setting the priority for each + <antrik> I don't even know whether it can be done without interfering with other thread handling... in which case it gets really really ugly + <pochu> antrik: btw I'm looking at [gnumach]/kern/thread.[ch], removing the priority stuff as appropriate, and will change the tasks code later + <antrik> it seems to me that using a more suitable kernel interface will not only be more elegant, but quite possibly actually easier to implement... + <pochu> antrik: apparently it's not that hard to change the priority for all threads in a task, see task_priority() in gnumach/kern/task.c + <pochu> it looks like the nice test failures are mostly because of the not 1:1 mapping between nice values and Mach priorities + <marcusb> "Set priority of task; used only for newly created threads." + <marcusb> there is a reason I didn't fix nice 8 years ago + <marcusb> ah there is a change_threads option + <pochu> marcusb: I'm not sure that comment is correct. that syscall is used by setpriority() + <marcusb> yeah + <marcusb> I didn't read further, where it explains the change_threads options + <marcusb> I was shooting before asking questions :) + <marcusb> pochu: although there are some bad interactions if max_priorities are set per thread + <antrik> pochu: maybe we are talking past each other. my point was not that it's hard to do in the kernel. I was just saying that it would be painful to do from userspace with the current kernel interface + <pochu> antrik: you could still use that interface in user space, couldn't you? or maybe I'm misunderstanding... + <pochu> cfhammar, antrik: current patch: http://emilio.pozuelo.org/~deb/gnumach.patch, main issue is probably what to do with high-priority threads. are there cases where there should be a thread with a high priority but the task's priority shouldn't be high? e.g. what to do with kernel_thread() in [gnumach]/kern/thread.c + <pochu> i.e. if tasks have a max_priority, then threads shouldn't have a higher priority, but then either we raise the task's max_priority if we need a high-prio thread, or we treat them specially (e.g. new field in struct thread), or maybe it's a non-issue because in such cases, all the task is high-prio? + <pochu> also I wonder whether I can kill the processor set's max_priority. It seems totally unused (I've checked gnumach, hurd and glibc) + <pochu> (that would simplify the priority handling) + <cfhammar> pochu: btw what does your patch do? i can't remember what was decided + <pochu> cfhammar: it moves the max_priority from the thread to the task, so raising/lowering it has effect on all of its threads + <pochu> it also increases the number of run queues (and thus that of priority levels) from 32 to 40 so we can have a 1:1 mapping with nice values + <pochu> cfhammar: btw don't do a full review yet, just a quick look would be fine for now + <neal> why not do priorities from 0 to 159 + <neal> then both ranges can be scaled + <neal> without loss of precision + <pochu> neal: there would be from Mach to nice priorities, e.g. a task with a priority of 2 another with 3 would have the same niceness, though their priority isn't really the same + <neal> pochu: sure + <neal> pochu: but any posix priority would map to a current mach priority and back + <neal> sorry, that's not true + <neal> a posix priority would map to a new mach priority and bach + <neal> and a current mach priority would map to a new mach priority and back + <neal> which is I think more desirable than changing to 40 priority levels + <pochu> neal> and a current mach priority would map to a new mach priority and back <- why should we care about this? + <neal> to be compatible with existing mach code + <neal> why gratutiously break existing interfaces? + <pochu> they would break anyway, wouldn't them? i.e. if you do task_set_priority(..., 20), you can't know if the caller is assuming old or new priorities (to leave it as 20 or as 100) + <neal> you add a new interface + <neal> you should avoid changing the semantics of existing interfaces as much as possible + <pochu> ok, and deprecate the old ones I guess + <neal> following that rule, priorities only break if someone does task_set_priority_new(..., X) and task_get_priority () + <neal> there are other users of Mach + <neal> I'd add a configure check for the new interface + <neal> alternatively, you can check at run time + <pochu> well if you _set_priority_new(), you should _get_priority_new() :) + <neal> it's not always possible + <pochu> other users of GNU Mach? + <neal> you are assuming you have complete control of all the code + <neal> this is usually not the case + <neal> no, other users of Mach + <neal> even apple didn't gratuitously break Mach + <neal> in fact, it may make sense to see how apple handles this problem + <pochu> hmm, I hadn't thought about that + <pochu> the other thing I don't understand is: "I'd add a configure check for the new interface". a configure check where? in Mach's configure? that doesn't make sense to me + <neal> any users of the interface + <pochu> ok so in clients, e.g. glibc & hurd + <neal> yes. + <antrik> neal: I'm not sure we are winning anything by keeping compatibility with other users of Mach... + <antrik> neal: we *know* that to make Hurd work really well, we have to do major changes sooner or later. we can just as well start now IMHO + <antrik> keeping compatibility just seems like extra effort without any benefit for us + <guillem> just OOC have all other Mach forks, preserved full compatibility? + <neal> guillem: Darwin is pretty compatible, as I understand it + <antrik> pochu: the fundamental approach of changing the task_priority interface to serve as a max priority, and to drop the notion of max priorities from threads, looks fine + <antrik> pochu: I'm not sure about the thread priority handling + <antrik> I don't know how thread priorities are supposed to work in chreads and/or pthread + <antrik> I can only *guess* that they assume a two-stage scheduling process, where the kernel first decides what process to run; and only later which thread in a process... + <antrik> if that's indeed the case, I don't think it's even possible to implement with the current Mach scheduler + <antrik> I guess we could work with relative thread priorities if we really want: always have the highest-priority thread run with the task's max priority, and lower the priorities of the other threads accordingly + <antrik> however, before engaging into this, I think you should better check whether any of the code in Hurd or glibc actually uses thread priorities at all. my guess is that it doesn't + <antrik> I think we could get away with stubbing out thread priority handling alltogether for now, and just use the task priority for all threads + <antrik> I agree BTW that it would be useful to check how Darwin handles this + <pochu> btw do you know where to download the OS X kernel source? I found something called xnu, but I?m not sure that's it + <antrik> pochu: yeah, that's it + <antrik> Darwin is the UNIX core of OS X, and Xnu is the actual kernel... + <pochu> hmm, so they have both a task.priority and a task.max_priority + <neal> pochu: thoughts? + <pochu> neal: they have a priority and a max_priority in the task and in the threads, new threads inherit it from its parent task + <pochu> then they have a task_priority(task, priority, max_priority) that can change a task's priorities, and it also changes it for all its threads + <neal> how does the global run queue work? + <pochu> and they have 128 run queues, no idea if there's a special reason for that number + <pochu> neal: sorry, what do you mean? + <neal> I don't understand the point of the max_priority parameter + <pochu> neal: and I don't understand the point of the (base) priority ;) + <pochu> the max_priority is just that, the maximum priority of a thread, which can be lowered, but can't exceed the max one + <pochu> the (base) priority, I don't understand what it does, though I haven't looked too hard. maybe it's the one a thread starts at, and must be <= max_priority + <antrik> pochu: it's clearly documented in the manual, as well as in the code your initial patch changes... + <antrik> or do you mean the meaning is different in Darwin?... + <pochu> I was speaking of Darwin, though maybe it's the same as you say + <antrik> I would assume it's the same. I don't think there would be any point in having the base vs. max priority distinction at all, except to stay in line with standard Mach... + <antrik> at least I can't see a point in the base priority semantics for use in POSIX systems... + <pochu> right, it would make sense to always have priority == max_priority ... + <pochu> neal: so max_priority is that maximum priority, and priority is the one used to calculate the scheduled priority, and can be raised and lowered by the user without giving special permissions as long as he doesn't raise it above max_priority + <pochu> well this would allow a user to lower a process' priority, and raise it again later, though that may not be allowed by POSIX, so then we would want to have max_priority == priority (or get rid of one of them if possible and backwards compatible) + <antrik> pochu: right, that's what I think too + <antrik> BTW, did I bring up handling of thread priorities? I know that I meant to, but I don't remember whether I actually did... + <pochu> antrik: you told me it'd be ok to just get rid of them for now + <pochu> so I'm more thinking of fixing max_priority and (base) priority and leaving thread's scheduling priority as it currently is + <pochu> s/so/though/ + <antrik> pochu: well, my fear is that keeping the thread priority handling as ist while changing task priority handling would complicate the changes, while giving us no real benefit... + <antrik> though looking at what Darwin did there should give you an idea what it involves exactly... + <pochu> antrik: what would you propose, keeping sched_priority == max_priority ? + <pochu> s/keeping/making/ + <antrik> yes, if that means what I think it does ;-) + <antrik> and keeping the priority of all threads equal to the task priority for now + <antrik> of course this only makes sense if changing it like this is actually simpler than extending the current handling... + <antrik> again, I can't judge this without actually knowing the code in question. looking at Darwin should give you an idea... + <pochu> I think leaving it as is, making it work with the task's max_priority changes would be easier + <antrik> perhaps I'm totally overestimating the amount of changes required to do what Darwin does + <antrik> OTOH, carrying around dead code isn't exactly helping the maintainability and efficiency of gnumach... + <antrik> so I'm a bit ambivalent on this + <antrik> should we go for minimal changes here, or use this occasion to simplify things?... + <antrik> I guess it would be good to bring this up on the ML + <cfhammar> in the context of gsoc i'd say minimal changes + <pochu> there's also neal's point on keeping backwards compatibility as much as possible + <neal> my point was not backwards compatibility at all costs + <antrik> I'm still not convinced this is a valid point :-) + <neal> but to not gratutiously break things + <antrik> neal: well, I never suggested breaking things just because we can... I only suggested breaking things to make the code and interface simpler :-) + <antrik> I do not insist on it though + <neal> at that time, we did not know how Mac did it + <antrik> I only think it would be good to get into a habit that Mach interfaces are not sacred... + <neal> and, I also had a proposal, which I think is not difficult to implement given the existing patch + <antrik> but as I said, I do not feel strongly about this. if people feel more confident about a minimal change, I'm fine with that :-) + <antrik> neal: err... IIRC your proposal was only about the number of nice levels? we are discussing the interface change necessary to implement POSIX semantics properly + <antrik> or am I misremembering? + <pochu> antrik: he argues that with that number of nice levels, we could keep backwards compatibility for the 0..31 levels, and for 0..39 for POSIX compatibility + <antrik> pochu: yes, I remember that part + <neal> antrik : My suggestion was: raise the number of nice levels to 160 and introduce a new interface which uses those. Adjust the old interface to space by 160/32 + <antrik> neal: I think I said it before: the problem is not *only* in the number of priority levels. the semantics are also wrong. which is why Darwin added a max_priority for tasks + <neal> what do you mean the semantics are wrong? + <neal> I apologize if you already explained this. + <antrik> hm... I explained it at some point, but I guess you were not present at that conversation + <neal> I got disconnected recently so I likely don't have it in backlog. + <antrik> in POSIX, any process can lower its priority; while only privileged processes can raise it + <antrik> Mach distinguishes between "current" and "max" priority for threads: "max" behaves like POSIX; while "current" can be raised or lowered at will, as long as it stays below "max" + <antrik> for tasks, there is only a "current" priority + <antrik> (which applies to newly created threads, and optionally can be set for all current threads while changing the task priority) + <antrik> glibc currently uses the existing task priorities, which leads to *completely* broken semantics + <antrik> instead, we need something like a max task priority -- which is exactly what Darwin added + <neal> yes + <antrik> (the "current" task priority is useless for POSIX semantics as far as I can tell; and regarding thread priorities, I doubt we actually use them at all?...) + <cfhammar> where does a new thread get its initial max_priority from? + <antrik> cfhammar: from the creator thread IIRC + <pochu> yes + +2010-08-12 + + <pochu> my plan is to change the number of priority levels and the threads/tasks priority handling, then add new RPCs to play with them and make the old ones stay compatible, then make glibc use the new RPCs + +--- + +Another nice issue: [[nice_changes_priority_of_parent_shell]]. diff --git a/open_issues/nightly_builds.mdwn b/open_issues/nightly_builds.mdwn new file mode 100644 index 00000000..167e7375 --- /dev/null +++ b/open_issues/nightly_builds.mdwn @@ -0,0 +1,32 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +We'd like to have nightly builds for the whole [[toolchain]], and then do some +automatic [[unit_testing]] on them. + +Resources: + + * [[hurd/running/Nix]] + + * [[toolchain/cross-gnu]] + + * [[Debian_Cross_Toolchain]] + + * As reported in the [[news/2010-05-31]] news, there's Hydra doing nightly + builds / Nix packages. + + * <http://hudson-ci.org/>, <http://jenkins-ci.org/> + + * <http://buildbot.net/> + +--- + +See also [[nightly_builds_deb_packages]]. diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn new file mode 100644 index 00000000..11fc4c79 --- /dev/null +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -0,0 +1,31 @@ +[[!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 +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'd be quite helpful to have nightly builds in form of Debian `.deb` +packages. + + * <http://noone.org/talks/vcs-buildd/> (german) + + * Need to have an automation to get from Hurd upstream Git branches to + a branch usable in Debian. + +--- + +There is infrastructure available to test whole OS installations. + + * <http://www.os-autoinst.org/> + +--- + +[[Debian_Cross_Toolchain]] for cross-building? + +--- + +See also [[nightly_builds]]. diff --git a/open_issues/notmuch_n_gmane.mdwn b/open_issues/notmuch_n_gmane.mdwn new file mode 100644 index 00000000..664c9876 --- /dev/null +++ b/open_issues/notmuch_n_gmane.mdwn @@ -0,0 +1,18 @@ +[[!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="Notmuch'n'Gmane"]] + +[[!taglink open_issue_documentation]]; [[ikiwiki]] issue. + +In `\[[!message-id +"AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]]`, underscores +are replaced with spaces in the rendered output: [[!message-id +"AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]]. diff --git a/open_issues/nptl.mdwn b/open_issues/nptl.mdwn new file mode 100644 index 00000000..9ff5fb51 --- /dev/null +++ b/open_issues/nptl.mdwn @@ -0,0 +1,37 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_libpthread open_issue_glibc]] + +IRC, #hurd, 2010-07-31 + + <tschwinge> Other question: how difficult is a NPTL port? Futexes and some kernel interfaces for scheduling stuff etc. -- what else? + <youpi> actually NPTL doesn't _require_ futexes + <youpi> it just requires low-level locks + <youpi> Mmm, it seems to be so only in principle + <youpi> I can see futex names here and there in the generic code + <youpi> looks like Drepper isn't disciplined enough in that area either + <tschwinge> (well, why would he...) + <youpi> I'm not sure we really want to port NPTL + <tschwinge> OK. + <youpi> Drepper will keep finding things to add + <youpi> while the interface between glibc and libpthread isn't increasing _so_ much + <tschwinge> ... and even less so the interfavce that actual applications are using. + <tschwinge> We'd need to evaluate which benefits NPTL would bring. + +--- + +# Resources + + * <http://www.akkadia.org/drepper/nptl-design.pdf> + + * <http://nptltracetool.sourceforge.net/> + + * <http://posixtest.sourceforge.net/> diff --git a/open_issues/o_exec.mdwn b/open_issues/o_exec.mdwn new file mode 100644 index 00000000..3f77a0f2 --- /dev/null +++ b/open_issues/o_exec.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="O_EXEC"]] + +[[!tag open_issue_glibc open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-04-24 + + <pinotree> interesting, glibc on every OS except hurd (so including linux + too) does not define O_EXEC + <pinotree> can somebody please help me understand a POSIX behaviour? + <pinotree> it's about fexecve: + http://pubs.opengroup.org/onlinepubs/9699919799/functions/fexecve.html + <pinotree> basically, it seems to me (reading the "errors" and "application + usage" sections) that O_EXEC for open() the fd is not mandatory, and if + not used fexecve will check for file permission at call time? + <pinotree> because currently libdiskfs and libnetfs require the fd to be + open with O_EXEC + <braunr> "Since execute permission is checked by fexecve(), the file + description fd need not have been opened with the O_EXEC flag" + <braunr> this one makes it clear checking for O_EXEC is wrong + <braunr> it looks like O_EXEC is only needed when you want to have files + for which only the execution permission is set + <braunr> but not the read one + <braunr> (i don't understand the "and write" part though) + <braunr> "exec will fail if the mode of the file associated with fd does + not grant execute permission to the calling process at the time fexecve() + is called." + <braunr> this one strengthens the impression you have, that fexecve indeed + checks file permissions at the time it's called + <braunr> pinotree: hope it helps + <pinotree> so it implies the following: + <pinotree> O_RDONLY → exec works if the file is readable + <braunr> exec works if the file is readable and/or executable (although + without read permissions you can't check it) + <braunr> (well, fexecve) + <pinotree> O_EXEC → exec requires that the permission of the file at + fexecve() time have +x + <braunr> i'd say ye so far + <braunr> yes + <pinotree> so we need to fix lib{disk,net}fs then + <braunr> seems so + <pinotree> enlighting, merci braunr + <braunr> de rien + <pinotree> :) diff --git a/open_issues/ogi.mdwn b/open_issues/ogi.mdwn new file mode 100644 index 00000000..e4372dc0 --- /dev/null +++ b/open_issues/ogi.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Go through Ognyan Kulev's (ogi) pages, and archive / hunt down what's still +interesting. + + * <http://debian.fmi.uni-sofia.bg/~ogi/hurd/links/> + + * <http://debian.fmi.uni-sofia.bg/~ogi/hurd/ext3fs/> + + * SVN ext2fs (ext2fs / large stores doc) + + done + + * ext3fs et al. + + checking copyright situation, also for thesis / w.r.t. university + project diff --git a/open_issues/open_posix_test_suite.mdwn b/open_issues/open_posix_test_suite.mdwn new file mode 100644 index 00000000..089ea1b1 --- /dev/null +++ b/open_issues/open_posix_test_suite.mdwn @@ -0,0 +1,2715 @@ +[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Open POSIX Test Suite"]] + +Here's a log of a [Open POSIX Test Suite](http://posixtest.sourceforge.net/) +run (get sources, `make`, inspect `logfile`); this is from 2009-07-27 HEAD +sources on a 2009-07-27 Debian GNU/Hurd system. + +The `logfile` has been post-processed with: + + $ sed ↩ + -e '/build: PASS$/d' ↩ + -e '/link: PASS$/d' ↩ + -e '/link: SKIP$/d' ↩ + -e '/execution: PASS$/d' + +The tests that failed as *INTERRUPTED* were hanging and have manually been +interrupted using `kill [PID]`. + + conformance/definitions/signal_h/16-1: build: FAILED: Compiler output: + conformance/definitions/signal_h/16-1.c:14: error: ‘SA_SIGINFO’ undeclared here (not in a function) + conformance/definitions/signal_h/16-1.c:15: error: ‘SA_NOCLDWAIT’ undeclared here (not in a function) + conformance/definitions/signal_h/26-1: build: FAILED: Compiler output: + conformance/definitions/signal_h/26-1.c:9: error: expected ‘)’ before ‘int’ + conformance/definitions/signal_h/26-1.c: In function ‘dummyfcn’: + conformance/definitions/signal_h/26-1.c:13: error: ‘pthread_kill_test’ undeclared (first use in this function) + conformance/definitions/signal_h/26-1.c:13: error: (Each undeclared identifier is reported only once + conformance/definitions/signal_h/26-1.c:13: error: for each function it appears in.) + conformance/definitions/signal_h/26-1.c:13: error: expected ‘;’ before ‘dummyvar’ + conformance/definitions/signal_h/26-1.c:14: error: ‘dummyvar’ undeclared (first use in this function) + conformance/definitions/signal_h/26-1.c:14: error: ‘pthread_kill’ undeclared (first use in this function) + conformance/interfaces/aio_cancel/3-1: build: FAILED: Compiler output: + conformance/interfaces/aio_cancel/3-1.c: In function ‘main’: + conformance/interfaces/aio_cancel/3-1.c:96: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_cancel/3-1.c:96: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_cancel/3-1.c:96: error: for each function it appears in.) + conformance/interfaces/aio_cancel/3-1.c:97: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_fsync/1-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/1-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/1-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/1-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/10-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/10-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/10-1.c:33: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/10-1.c:33: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/11-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/11-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/11-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/11-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/13-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/13-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/13-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/13-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/6-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/6-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/6-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/6-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/7-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/7-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/7-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/7-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/12-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/12-1.c: In function ‘main’: + conformance/interfaces/aio_read/12-1.c:34: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/12-1.c:34: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/13-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/13-1.c: In function ‘main’: + conformance/interfaces/aio_read/13-1.c:33: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/13-1.c:33: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/14-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/14-1.c: In function ‘main’: + conformance/interfaces/aio_read/14-1.c:34: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/14-1.c:34: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/15-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/15-1.c: In function ‘main’: + conformance/interfaces/aio_read/15-1.c:30: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/15-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/6-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/6-1.c: In function ‘main’: + conformance/interfaces/aio_read/6-1.c:30: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/6-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_suspend/1-1: build: FAILED: Compiler output: + conformance/interfaces/aio_suspend/1-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/1-1.c:120: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/1-1.c:120: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_suspend/1-1.c:120: error: for each function it appears in.) + conformance/interfaces/aio_suspend/1-1.c:126: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/2-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_suspend/2-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/2-1.c:31: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_suspend/2-1.c:31: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_suspend/6-1: build: FAILED: Compiler output: + conformance/interfaces/aio_suspend/6-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/6-1.c:116: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/6-1.c:116: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_suspend/6-1.c:116: error: for each function it appears in.) + conformance/interfaces/aio_suspend/6-1.c:122: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/7-1: build: FAILED: Compiler output: + conformance/interfaces/aio_suspend/7-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/7-1.c:118: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/7-1.c:118: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_suspend/7-1.c:118: error: for each function it appears in.) + conformance/interfaces/aio_suspend/7-1.c:124: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/8-1: build: FAILED: Compiler output: + conformance/interfaces/aio_suspend/8-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/8-1.c:121: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/8-1.c:121: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_suspend/8-1.c:121: error: for each function it appears in.) + conformance/interfaces/aio_suspend/8-1.c:127: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_write/10-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/10-1.c: In function ‘main’: + conformance/interfaces/aio_write/10-1.c:32: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/10-1.c:32: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_write/11-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/11-1.c: In function ‘main’: + conformance/interfaces/aio_write/11-1.c:32: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/11-1.c:32: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_write/12-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/12-1.c: In function ‘main’: + conformance/interfaces/aio_write/12-1.c:31: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/12-1.c:31: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_write/13-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/13-1.c: In function ‘main’: + conformance/interfaces/aio_write/13-1.c:30: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/13-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_write/4-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/4-1.c: In function ‘main’: + conformance/interfaces/aio_write/4-1.c:30: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/4-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/fork/2-1: build: FAILED: Compiler output: + conformance/interfaces/fork/2-1.c: In function ‘main’: + conformance/interfaces/fork/2-1.c:240: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/fork/2-1.c:240: error: (Each undeclared identifier is reported only once + conformance/interfaces/fork/2-1.c:240: error: for each function it appears in.) + conformance/interfaces/fork/2-1.c:241: error: ‘SA_NOCLDWAIT’ undeclared (first use in this function) + conformance/interfaces/lio_listio/1-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/1-1.c: In function ‘main’: + conformance/interfaces/lio_listio/1-1.c:110: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/1-1.c:110: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/1-1.c:110: error: for each function it appears in.) + conformance/interfaces/lio_listio/1-1.c:122: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/10-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/10-1.c: In function ‘main’: + conformance/interfaces/lio_listio/10-1.c:107: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/10-1.c:107: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/10-1.c:107: error: for each function it appears in.) + conformance/interfaces/lio_listio/10-1.c:119: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/11-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/11-1.c: In function ‘main’: + conformance/interfaces/lio_listio/11-1.c:111: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/11-1.c:111: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/11-1.c:111: error: for each function it appears in.) + conformance/interfaces/lio_listio/11-1.c:123: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/14-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/14-1.c: In function ‘main’: + conformance/interfaces/lio_listio/14-1.c:111: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/14-1.c:111: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/14-1.c:111: error: for each function it appears in.) + conformance/interfaces/lio_listio/14-1.c:123: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/15-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/15-1.c: In function ‘main’: + conformance/interfaces/lio_listio/15-1.c:111: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/15-1.c:111: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/15-1.c:111: error: for each function it appears in.) + conformance/interfaces/lio_listio/15-1.c:123: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/16-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/16-1.c: In function ‘main’: + conformance/interfaces/lio_listio/16-1.c:32: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/16-1.c:32: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/17-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/17-1.c: In function ‘main’: + conformance/interfaces/lio_listio/17-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/17-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/19-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/19-1.c: In function ‘main’: + conformance/interfaces/lio_listio/19-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/19-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/2-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/2-1.c: In function ‘main’: + conformance/interfaces/lio_listio/2-1.c:106: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/2-1.c:106: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/2-1.c:106: error: for each function it appears in.) + conformance/interfaces/lio_listio/2-1.c:118: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/20-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/20-1.c: In function ‘main’: + conformance/interfaces/lio_listio/20-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/20-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/21-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/21-1.c: In function ‘main’: + conformance/interfaces/lio_listio/21-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/21-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/22-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/22-1.c: In function ‘main’: + conformance/interfaces/lio_listio/22-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/22-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/23-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/23-1.c: In function ‘main’: + conformance/interfaces/lio_listio/23-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/23-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/24-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/24-1.c: In function ‘main’: + conformance/interfaces/lio_listio/24-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/24-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/25-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/25-1.c: In function ‘main’: + conformance/interfaces/lio_listio/25-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/25-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/3-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/3-1.c: In function ‘main’: + conformance/interfaces/lio_listio/3-1.c:107: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/3-1.c:107: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/3-1.c:107: error: for each function it appears in.) + conformance/interfaces/lio_listio/3-1.c:119: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/4-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/4-1.c: In function ‘main’: + conformance/interfaces/lio_listio/4-1.c:114: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/4-1.c:114: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/4-1.c:114: error: for each function it appears in.) + conformance/interfaces/lio_listio/4-1.c:126: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/7-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/7-1.c: In function ‘main’: + conformance/interfaces/lio_listio/7-1.c:113: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/7-1.c:113: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/7-1.c:113: error: for each function it appears in.) + conformance/interfaces/lio_listio/7-1.c:125: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/mq_open/27-1: build: FAILED: Compiler output: + conformance/interfaces/mq_open/27-1.c: In function ‘main’: + conformance/interfaces/mq_open/27-1.c:27: error: ‘PATH_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_open/27-1.c:27: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_open/27-1.c:27: error: for each function it appears in.) + cc1: warnings being treated as errors + conformance/interfaces/mq_open/27-1.c:27: error: unused variable ‘qname’ + conformance/interfaces/mq_send/13-1: build: FAILED: Compiler output: + conformance/interfaces/mq_send/13-1.c:30: error: ‘MQ_PRIO_MAX’ undeclared here (not in a function) + conformance/interfaces/mq_send/4-1: build: FAILED: Compiler output: + conformance/interfaces/mq_send/4-1.c: In function ‘main’: + conformance/interfaces/mq_send/4-1.c:41: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_send/4-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_send/4-1.c:41: error: for each function it appears in.) + conformance/interfaces/mq_send/4-2: build: FAILED: Compiler output: + conformance/interfaces/mq_send/4-2.c: In function ‘main’: + conformance/interfaces/mq_send/4-2.c:41: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_send/4-2.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_send/4-2.c:41: error: for each function it appears in.) + conformance/interfaces/mq_send/4-3: build: FAILED: Compiler output: + conformance/interfaces/mq_send/4-3.c: In function ‘main’: + conformance/interfaces/mq_send/4-3.c:51: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_send/4-3.c:51: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_send/4-3.c:51: error: for each function it appears in.) + conformance/interfaces/mq_send/7-1: build: FAILED: Compiler output: + conformance/interfaces/mq_send/7-1.c: In function ‘main’: + conformance/interfaces/mq_send/7-1.c:60: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_send/7-1.c:60: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_send/7-1.c:60: error: for each function it appears in.) + conformance/interfaces/mq_timedsend/13-1: build: FAILED: Compiler output: + conformance/interfaces/mq_timedsend/13-1.c:31: error: ‘MQ_PRIO_MAX’ undeclared here (not in a function) + conformance/interfaces/mq_timedsend/4-1: build: FAILED: Compiler output: + conformance/interfaces/mq_timedsend/4-1.c: In function ‘main’: + conformance/interfaces/mq_timedsend/4-1.c:45: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_timedsend/4-1.c:45: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_timedsend/4-1.c:45: error: for each function it appears in.) + conformance/interfaces/mq_timedsend/4-2: build: FAILED: Compiler output: + conformance/interfaces/mq_timedsend/4-2.c: In function ‘main’: + conformance/interfaces/mq_timedsend/4-2.c:45: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_timedsend/4-2.c:45: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_timedsend/4-2.c:45: error: for each function it appears in.) + conformance/interfaces/mq_timedsend/4-3: build: FAILED: Compiler output: + conformance/interfaces/mq_timedsend/4-3.c: In function ‘main’: + conformance/interfaces/mq_timedsend/4-3.c:55: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_timedsend/4-3.c:55: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_timedsend/4-3.c:55: error: for each function it appears in.) + conformance/interfaces/pthread_attr_getstack/1-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_getstack/1-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_getstack/1-1.c:54: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_getstack/1-1.c:54: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_getstack/1-1.c:54: error: for each function it appears in.) + conformance/interfaces/pthread_attr_getstacksize/1-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_getstacksize/1-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_getstacksize/1-1.c:53: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_getstacksize/1-1.c:53: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_getstacksize/1-1.c:53: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/1-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/1-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/1-1.c:63: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/1-1.c:63: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/1-1.c:63: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/2-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/2-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/2-1.c:90: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/2-1.c:90: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/2-1.c:90: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/4-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/4-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/4-1.c:73: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/4-1.c:73: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/4-1.c:73: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/6-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/6-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/6-1.c:59: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/6-1.c:59: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/6-1.c:59: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/7-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/7-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/7-1.c:60: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/7-1.c:60: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/7-1.c:60: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstacksize/1-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstacksize/1-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstacksize/1-1.c:41: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstacksize/1-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstacksize/1-1.c:41: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstacksize/2-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstacksize/2-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstacksize/2-1.c:79: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstacksize/2-1.c:79: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstacksize/2-1.c:79: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstacksize/4-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstacksize/4-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstacksize/4-1.c:50: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstacksize/4-1.c:50: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstacksize/4-1.c:50: error: for each function it appears in.) + conformance/interfaces/pthread_key_create/speculative/5-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_key_create/speculative/5-1.c:37: error: ‘PTHREAD_KEYS_MAX’ undeclared here (not in a function) + conformance/interfaces/pthread_once/3-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_once/3-1.c: In function ‘main’: + conformance/interfaces/pthread_once/3-1.c:71: error: expected expression before ‘{’ token + conformance/interfaces/pthread_once/6-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_once/6-1.c: In function ‘test’: + conformance/interfaces/pthread_once/6-1.c:199: error: expected expression before ‘{’ token + conformance/interfaces/sched_yield/1-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/sched_yield/1-1.c: In function ‘set_process_affinity’: + conformance/interfaces/sched_yield/1-1.c:87: error: implicit declaration of function ‘__CPU_ZERO_S’ + conformance/interfaces/sched_yield/1-1.c:89: error: implicit declaration of function ‘__CPU_SET_S’ + conformance/interfaces/sched_yield/1-1.c: In function ‘set_thread_affinity’: + conformance/interfaces/sched_yield/1-1.c:119: error: implicit declaration of function ‘pthread_setaffinity_np’ + conformance/interfaces/sched_yield/1-1.c: In function ‘runner’: + conformance/interfaces/sched_yield/1-1.c:136: error: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘pthread_t’ + conformance/interfaces/sched_yield/1-1.c: In function ‘busy_thread’: + conformance/interfaces/sched_yield/1-1.c:159: error: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘pthread_t’ + conformance/interfaces/sem_init/6-1: build: FAILED: Compiler output: + conformance/interfaces/sem_init/6-1.c: In function ‘main’: + conformance/interfaces/sem_init/6-1.c:29: error: ‘SEM_VALUE_MAX’ undeclared (first use in this function) + conformance/interfaces/sem_init/6-1.c:29: error: (Each undeclared identifier is reported only once + conformance/interfaces/sem_init/6-1.c:29: error: for each function it appears in.) + conformance/interfaces/sem_open/5-1: build: FAILED: Compiler output: + conformance/interfaces/sem_open/5-1.c: In function ‘main’: + conformance/interfaces/sem_open/5-1.c:32: error: ‘SEM_VALUE_MAX’ undeclared (first use in this function) + conformance/interfaces/sem_open/5-1.c:32: error: (Each undeclared identifier is reported only once + conformance/interfaces/sem_open/5-1.c:32: error: for each function it appears in.) + conformance/interfaces/sigaction/10-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/10-1.c: In function ‘main’: + conformance/interfaces/sigaction/10-1.c:41: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/10-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/10-1.c:41: error: for each function it appears in.) + conformance/interfaces/sigaction/11-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/11-1.c: In function ‘main’: + conformance/interfaces/sigaction/11-1.c:50: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/11-1.c:50: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/11-1.c:50: error: for each function it appears in.) + conformance/interfaces/sigaction/19-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-1.c: In function ‘main’: + conformance/interfaces/sigaction/19-1.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-1.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-1.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-10: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-10.c: In function ‘main’: + conformance/interfaces/sigaction/19-10.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-10.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-10.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-11: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-11.c: In function ‘main’: + conformance/interfaces/sigaction/19-11.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-11.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-11.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-12: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-12.c: In function ‘main’: + conformance/interfaces/sigaction/19-12.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-12.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-12.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-13: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-13.c: In function ‘main’: + conformance/interfaces/sigaction/19-13.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-13.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-13.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-14: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-14.c: In function ‘main’: + conformance/interfaces/sigaction/19-14.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-14.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-14.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-15: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-15.c: In function ‘main’: + conformance/interfaces/sigaction/19-15.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-15.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-15.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-16: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-16.c: In function ‘main’: + conformance/interfaces/sigaction/19-16.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-16.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-16.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-17: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-17.c: In function ‘main’: + conformance/interfaces/sigaction/19-17.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-17.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-17.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-18: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-18.c: In function ‘main’: + conformance/interfaces/sigaction/19-18.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-18.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-18.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-19: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-19.c: In function ‘main’: + conformance/interfaces/sigaction/19-19.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-19.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-19.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-2: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-2.c: In function ‘main’: + conformance/interfaces/sigaction/19-2.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-2.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-2.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-20: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-20.c: In function ‘main’: + conformance/interfaces/sigaction/19-20.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-20.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-20.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-21: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-21.c: In function ‘main’: + conformance/interfaces/sigaction/19-21.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-21.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-21.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-22: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-22.c: In function ‘main’: + conformance/interfaces/sigaction/19-22.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-22.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-22.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-23: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-23.c: In function ‘main’: + conformance/interfaces/sigaction/19-23.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-23.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-23.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-24: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-24.c: In function ‘main’: + conformance/interfaces/sigaction/19-24.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-24.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-24.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-25: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-25.c: In function ‘main’: + conformance/interfaces/sigaction/19-25.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-25.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-25.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-26: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-26.c: In function ‘main’: + conformance/interfaces/sigaction/19-26.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-26.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-26.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-3: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-3.c: In function ‘main’: + conformance/interfaces/sigaction/19-3.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-3.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-3.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-4: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-4.c: In function ‘main’: + conformance/interfaces/sigaction/19-4.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-4.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-4.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-5: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-5.c: In function ‘main’: + conformance/interfaces/sigaction/19-5.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-5.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-5.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-6: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-6.c: In function ‘main’: + conformance/interfaces/sigaction/19-6.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-6.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-6.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-7: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-7.c: In function ‘main’: + conformance/interfaces/sigaction/19-7.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-7.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-7.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-8: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-8.c: In function ‘main’: + conformance/interfaces/sigaction/19-8.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-8.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-8.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-9: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-9.c: In function ‘main’: + conformance/interfaces/sigaction/19-9.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-9.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-9.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/21-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/21-1.c: In function ‘main’: + conformance/interfaces/sigaction/21-1.c:36: error: ‘SA_NOCLDWAIT’ undeclared (first use in this function) + conformance/interfaces/sigaction/21-1.c:36: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/21-1.c:36: error: for each function it appears in.) + conformance/interfaces/sigaction/29-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/29-1.c: In function ‘handler’: + conformance/interfaces/sigaction/29-1.c:95: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigaction/29-1.c:95: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/29-1.c:95: error: for each function it appears in.) + conformance/interfaces/sigaction/29-1.c: In function ‘main’: + conformance/interfaces/sigaction/29-1.c:133: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/29-1.c:145: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigaction/30-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/30-1.c: In function ‘main’: + conformance/interfaces/sigaction/30-1.c:117: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigaction/30-1.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/30-1.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/6-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-1.c: In function ‘main’: + conformance/interfaces/sigaction/6-1.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-1.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-1.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-10: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-10.c: In function ‘main’: + conformance/interfaces/sigaction/6-10.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-10.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-10.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-11: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-11.c: In function ‘main’: + conformance/interfaces/sigaction/6-11.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-11.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-11.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-12: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-12.c: In function ‘main’: + conformance/interfaces/sigaction/6-12.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-12.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-12.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-13: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-13.c: In function ‘main’: + conformance/interfaces/sigaction/6-13.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-13.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-13.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-14: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-14.c: In function ‘main’: + conformance/interfaces/sigaction/6-14.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-14.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-14.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-15: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-15.c: In function ‘main’: + conformance/interfaces/sigaction/6-15.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-15.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-15.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-16: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-16.c: In function ‘main’: + conformance/interfaces/sigaction/6-16.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-16.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-16.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-17: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-17.c: In function ‘main’: + conformance/interfaces/sigaction/6-17.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-17.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-17.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-18: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-18.c: In function ‘main’: + conformance/interfaces/sigaction/6-18.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-18.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-18.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-19: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-19.c: In function ‘main’: + conformance/interfaces/sigaction/6-19.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-19.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-19.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-2: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-2.c: In function ‘main’: + conformance/interfaces/sigaction/6-2.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-2.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-2.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-20: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-20.c: In function ‘main’: + conformance/interfaces/sigaction/6-20.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-20.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-20.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-21: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-21.c: In function ‘main’: + conformance/interfaces/sigaction/6-21.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-21.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-21.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-22: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-22.c: In function ‘main’: + conformance/interfaces/sigaction/6-22.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-22.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-22.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-23: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-23.c: In function ‘main’: + conformance/interfaces/sigaction/6-23.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-23.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-23.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-24: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-24.c: In function ‘main’: + conformance/interfaces/sigaction/6-24.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-24.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-24.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-25: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-25.c: In function ‘main’: + conformance/interfaces/sigaction/6-25.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-25.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-25.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-26: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-26.c: In function ‘main’: + conformance/interfaces/sigaction/6-26.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-26.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-26.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-3: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-3.c: In function ‘main’: + conformance/interfaces/sigaction/6-3.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-3.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-3.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-4: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-4.c: In function ‘main’: + conformance/interfaces/sigaction/6-4.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-4.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-4.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-5: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-5.c: In function ‘main’: + conformance/interfaces/sigaction/6-5.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-5.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-5.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-6: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-6.c: In function ‘main’: + conformance/interfaces/sigaction/6-6.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-6.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-6.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-7: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-7.c: In function ‘main’: + conformance/interfaces/sigaction/6-7.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-7.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-7.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-8: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-8.c: In function ‘main’: + conformance/interfaces/sigaction/6-8.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-8.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-8.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-9: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-9.c: In function ‘main’: + conformance/interfaces/sigaction/6-9.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-9.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-9.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/9-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/9-1.c: In function ‘main’: + conformance/interfaces/sigaction/9-1.c:49: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/9-1.c:49: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/9-1.c:49: error: for each function it appears in.) + conformance/interfaces/sigqueue/1-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/1-1.c: In function ‘myhandler’: + conformance/interfaces/sigqueue/1-1.c:33: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/1-1.c:33: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/1-1.c:33: error: for each function it appears in.) + conformance/interfaces/sigqueue/1-1.c: In function ‘main’: + conformance/interfaces/sigqueue/1-1.c:46: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/1-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/4-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/4-1.c: In function ‘main’: + conformance/interfaces/sigqueue/4-1.c:45: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/4-1.c:45: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/4-1.c:45: error: for each function it appears in.) + conformance/interfaces/sigqueue/4-1.c:48: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/5-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/5-1.c: In function ‘main’: + conformance/interfaces/sigqueue/5-1.c:48: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/5-1.c:48: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/5-1.c:48: error: for each function it appears in.) + conformance/interfaces/sigqueue/6-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/6-1.c: In function ‘main’: + conformance/interfaces/sigqueue/6-1.c:55: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/6-1.c:55: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/6-1.c:55: error: for each function it appears in.) + conformance/interfaces/sigqueue/6-1.c:58: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/7-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/7-1.c: In function ‘main’: + conformance/interfaces/sigqueue/7-1.c:52: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/7-1.c:52: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/7-1.c:52: error: for each function it appears in.) + conformance/interfaces/sigqueue/7-1.c:58: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigqueue/7-1.c:58: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/8-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/8-1.c: In function ‘main’: + conformance/interfaces/sigqueue/8-1.c:46: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/8-1.c:46: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/8-1.c:46: error: for each function it appears in.) + conformance/interfaces/sigqueue/8-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/9-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/9-1.c: In function ‘main’: + conformance/interfaces/sigqueue/9-1.c:46: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/9-1.c:46: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/9-1.c:46: error: for each function it appears in.) + conformance/interfaces/sigqueue/9-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwait/2-1: build: FAILED: Compiler output: + conformance/interfaces/sigwait/2-1.c: In function ‘main’: + conformance/interfaces/sigwait/2-1.c:45: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwait/2-1.c:45: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwait/2-1.c:45: error: for each function it appears in.) + conformance/interfaces/sigwait/7-1: build: FAILED: Compiler output: + conformance/interfaces/sigwait/7-1.c: In function ‘main’: + conformance/interfaces/sigwait/7-1.c:114: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwait/7-1.c:114: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwait/7-1.c:114: error: for each function it appears in.) + conformance/interfaces/sigwait/7-1.c:114: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/2-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/2-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/2-1.c:44: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/2-1.c:44: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/2-1.c:44: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/2-1.c:49: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/2-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/5-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/5-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/5-1.c:41: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/5-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/5-1.c:41: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/6-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/6-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/6-1.c:41: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/6-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/6-1.c:41: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/7-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/7-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/7-1.c:48: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/7-1.c:48: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/7-1.c:48: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/7-1.c:51: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/8-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/8-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/8-1.c:47: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/8-1.c:47: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/8-1.c:47: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/8-1.c:50: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/definitions/mqueue_h/1-1: execution: UNTESTED: Output: + Not Implemented! + conformance/definitions/mqueue_h/10-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/11-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/2-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/3-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/4-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/5-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/6-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/7-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/8-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/9-1: execution: UNTESTED: Output: + Test not implemented! + conformance/interfaces/aio_cancel/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/10-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/2-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/6-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/7-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_error/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_error/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_error/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/12-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/14-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/4-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/8-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/8-3: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/8-4: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/10-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/11-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/11-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/3-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/7-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/3-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_suspend/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_suspend/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_suspend/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_suspend/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/1-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/6-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/7-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/8-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/9-2: execution: UNSUPPORTED: Output: + conformance/interfaces/clock_getcpuclockid/1-1: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME unsupported + conformance/interfaces/clock_getcpuclockid/2-1: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME unsupported + conformance/interfaces/clock_getres/3-1: execution: FAILED: Output: + clock_getres() failed + Test FAILED + conformance/interfaces/clock_getres/7-1: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME not supported + conformance/interfaces/clock_getres/8-1: execution: UNSUPPORTED: Output: + _POSIX_THREAD_CPUTIME not supported + conformance/interfaces/clock_gettime/3-1: execution: UNSUPPORTED: Output: + CLOCK_MONOTONIC unsupported + conformance/interfaces/clock_gettime/4-1: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME unsupported + conformance/interfaces/clock_nanosleep/10-1: execution: FAILED: Output: + In handler + errno != EINTR + Test FAILED + conformance/interfaces/clock_nanosleep/9-1: execution: FAILED: Output: + In handler + clock_nanosleep() did not return EINTR + Child did not exit normally. + Test FAILED + conformance/interfaces/clock_settime/1-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/19-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/4-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/4-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/clock_settime/5-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/5-2: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/7-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/7-2: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/8-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/speculative/4-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/clock_settime/speculative/4-4: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/fork/1-1: execution: UNRESOLVED: Output: + [02:46:23]Test conformance/interfaces/fork/1-1.c unresolved: got 1073741869 (Operation not supported) on line 115 (Failed to open the semaphore) + [02:46:23]Test conformance/interfaces/fork/1-1.c unresolved: got 1073741869 (Operation not supported) on line 115 (Failed to open the semaphore) + conformance/interfaces/fork/11-1: execution: INTERRUPTED: Output: + conformance/interfaces/fork/12-1: execution: FAILED: Output: + [09:57:13]SIGUSR1 and SIGUSR2 are pending, we can fork + [09:57:13]SIGUSR1 and SIGUSR2 are blocked in child + [09:57:13]Test conformance/interfaces/fork/12-1.c FAILED: The new process was created with SIGUSR1 pending + [09:57:13]SIGUSR1 and SIGUSR2 are pending, we can fork + [09:57:13]Test conformance/interfaces/fork/12-1.c FAILED: Child exited abnormally + conformance/interfaces/fork/13-1: execution: UNRESOLVED: Output: + [09:57:14]Test conformance/interfaces/fork/13-1.c unresolved: got 1073741902 (Function not implemented) on line 117 (Failed to set interval timer for ITIMER_VIRTUAL) + conformance/interfaces/fork/14-1: execution: UNRESOLVED: Output: + [09:57:14]Test conformance/interfaces/fork/14-1.c unresolved: got 1073741869 (Operation not supported) on line 100 (Failed to create the named semaphore) + conformance/interfaces/fork/17-1: execution: UNRESOLVED: Output: + [09:57:15]Test conformance/interfaces/fork/17-1.c unresolved: got 1073741902 (Function not implemented) on line 103 (Failed to get max priority value) + conformance/interfaces/fork/17-2: execution: UNRESOLVED: Output: + [09:57:15]Test conformance/interfaces/fork/17-2.c unresolved: got 1073741902 (Function not implemented) on line 103 (Failed to get max priority value) + conformance/interfaces/fork/18-1: execution: UNRESOLVED: Output: + [09:57:16]Test conformance/interfaces/fork/18-1.c unresolved: got 1073741902 (Function not implemented) on line 128 (Failed to create a timer) + conformance/interfaces/fork/19-1: execution: UNRESOLVED: Output: + [09:57:16]Test conformance/interfaces/fork/19-1.c unresolved: got 1073741902 (Function not implemented) on line 114 (Failed to create the message queue descriptor) + conformance/interfaces/fork/21-1: execution: UNRESOLVED: Output: + [09:57:17]Test conformance/interfaces/fork/21-1.c unresolved: got 1073741869 (Operation not supported) on line 128 (Failed to open the semaphore) + conformance/interfaces/fork/22-1: execution: UNTESTED: Output: + [09:57:17]File conformance/interfaces/fork/22-1.c cannot test: The testcase needs CPUTIME or THREAD_CPUTIME support + conformance/interfaces/fork/8-1: execution: FAILED: Output: + [09:57:20]Test conformance/interfaces/fork/8-1.c FAILED: The process is created with non-zero tms_cutime or tms_cstime + conformance/interfaces/fsync/7-1: execution: FAILED: Output: + fsync/7-1.c Test Fail: Expect EINVAL, get: (ipc/mig) bad request message ID + conformance/interfaces/lio_listio/12-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/13-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/18-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/6-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/mlock/10-1: execution: UNRESOLVED: Output: + You don't have permission to lock your address space. + Try to rerun this test as root. + conformance/interfaces/mlock/5-1: execution: UNRESOLVED: Output: + You don't have permission to lock your address space. + Try to rerun this test as root. + conformance/interfaces/mlock/8-1: execution: UNRESOLVED: Output: + You don't have permission to lock your address space. + Try to rerun this test as root. + conformance/interfaces/mlockall/13-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/mlockall/13-2: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/mlockall/3-6: execution: UNRESOLVED: Output: + An error occurs when calling mlockall(): Function not implemented + conformance/interfaces/mlockall/3-7: execution: UNRESOLVED: Output: + An error occurs when calling mlockall(): Function not implemented + conformance/interfaces/mlockall/8-1: execution: UNRESOLVED: Output: + Unexpected error: Function not implemented + conformance/interfaces/mlockall/speculative/15-1: execution: UNRESOLVED: Output: + Unexpected error: Function not implemented + conformance/interfaces/mmap/11-4: execution: FAILED: Output: + pa: 0x28000 + pa_2: 0x29000 + Test Fail: mmap/11-4.c Modification of the partial page at the end of an object is written out + conformance/interfaces/mmap/11-5: execution: FAILED: Output: + Test Fail: mmap/11-5.c Modification of the partial page at the end of an object is written out + conformance/interfaces/mmap/13-1: execution: FAILED: Output: + Time before write(): 1248767904 + Time before mmap(): 1248767905 + Time before munmap(): 1248767906 + atime1: 1248767904, atime2: 1248767904, atime3: 1248767904 + Test Fail mmap/13-1.c st_atime did not update properly + conformance/interfaces/mmap/14-1: execution: FAILED: Output: + Time before write(): 1248767907 + Time before mmap(): 1248767908 + Time before write reference: 1248767909 + Time before msync(): 1248767910 + ctime1: 1248767909, ctime2: 1248767909 + mtime1: 1248767909, mtime2: 1248767909 + Test Fail mmap/14-1.c st_ctime and st_mtime were not updated properly + conformance/interfaces/mmap/18-1: execution: UNRESOLVED: Output: + mmap/18-1.c Error at mlockall(): Function not implemented + conformance/interfaces/mmap/21-1: execution: FAILED: Output: + Test FAIL + +Kernel panic [[!tag open_issue_gnumach]] (at conformance/interfaces/mmap/24-1): + + Assertion `(object == VM_OBJECT_NULL) || (object->ref_count > 0) || ((object->paging_in_progress != 0) && internal)' failed in file "../gnumach-1-branch-Xen-branch/vm/vm_object.c", line 2087 + Kernel Breakpoint trap, eip 0x20020a77 + Stopped at 0x20020a76: int $3 + db> trace + 0x20020a76(2006abc1,20067354,2006708c,827,2e4e5514) + 0x20020ace(20067354,2006708c,827,2001c900,2e3b54f4) + 0x20035ef2(2e4e5514,1000,0,200194c0,2e3b54f4) + 0x2003929f(2e3b4d64,2fc6ff9c,400,0,1) + 0x200577ea(1,15ff998,400,0,1) + 0x20006838(1,15ff998,400,0,1) + >>>>> user space <<<<< + + $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020ace 0x20035ef2 0x2003929f 0x200577ea 0x20006838 + Debugger + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105 + Assert + ??:0 + vm_object_enter + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/vm/vm_object.c:2109 + vm_map + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/vm/vm_user.c:326 + syscall_vm_map + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_mig.c:657 + mach_call_call + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/i386/i386/locore.S:1083 + +Disable the panic-causing test (conformance/interfaces/mmap/24-1) and restart: + + [...] + conformance/interfaces/mmap/24-2: execution: INTERRUPTED: Output: + conformance/interfaces/mmap/27-1: execution: UNTESTED: Output: + Test Untested: MAP_FIXED defined + conformance/interfaces/mmap/28-1: execution: FAILED: Output: + Test Fail: mmap/28-1.c Got no error at mmap() + conformance/interfaces/mmap/31-1: execution: FAILED: Output: + Test FAIL: expect EOVERFLOW but get other error: Cannot allocate memory + off: fffff000, len: fffff000 + conformance/interfaces/mmap/6-4: execution: FAILED: Output: + Test Fail: Did not get EACCES as expected + conformance/interfaces/mmap/6-6: execution: FAILED: Output: + Test Fail: Did not get EACCES as expected + conformance/interfaces/mmap/7-1: execution: UNRESOLVED: Output: + mmap/7-1.c Error at msync(): Error in unknown error system: FFFFFFFF + conformance/interfaces/mmap/7-2: execution: UNRESOLVED: Output: + mmap/7-2.c Error at msync(): Error in unknown error system: FFFFFFFF + conformance/interfaces/mq_close/1-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_close/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_close 2-1: mq_open: Function not implemented + unexpected error: mq_close 2-1: read: EOF + conformance/interfaces/mq_close/3-1: execution: UNRESOLVED: Output: + unexpected error: mq_close 3-1: mq_open: Function not implemented + conformance/interfaces/mq_close/3-2: execution: FAILED: Output: + errno != EBADF on invalid descriptor + Test FAILED + conformance/interfaces/mq_close/3-3: execution: FAILED: Output: + errno != EBADF on invalid descriptor + Test FAILED + conformance/interfaces/mq_close/4-1: execution: UNRESOLVED: Output: + unexpected error: mq_close 4-1: mq_open: Function not implemented + conformance/interfaces/mq_close/5-1: execution: UNTESTED: Output: + Functionality of using mqdes after mq_close() and before + mq_open() will not be tested as POSIX says this is undefined. + conformance/interfaces/mq_getattr/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 2-1: mq_open(): Function not implemented + conformance/interfaces/mq_getattr/2-2: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 2-2: mq_open(): Function not implemented + conformance/interfaces/mq_getattr/3-1: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 3-1: mq_open(): Function not implemented + conformance/interfaces/mq_getattr/4-1: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 4-1: mq_open(): Function not implemented + conformance/interfaces/mq_getattr/speculative/7-1: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 7-1: mq_open(): Function not implemented + conformance/interfaces/mq_notify/1-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 1-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 2-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/3-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 3-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/4-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 4-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/5-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 5-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/8-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 8-1: mq_open(): Function not implemented + conformance/interfaces/mq_notify/9-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 9-1: mq_open: Function not implemented + conformance/interfaces/mq_open/1-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/10-1: execution: UNTESTED: Output: + Will not test the user ID and group ID of a created + message queue as we would need multiple users and + groups on the system to test. + Will not test the file permissions as testing would + be implementation defined. + conformance/interfaces/mq_open/11-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/12-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/13-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/14-1: execution: UNTESTED: Output: + Will not test calling process privileges on name + as POSIX does not define when this error occurs. + conformance/interfaces/mq_open/15-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/16-1: execution: FAILED: Output: + Test FAILED - mq_open() never succeeded + conformance/interfaces/mq_open/17-1: execution: UNTESTED: Output: + Will not test setting O_EXCL without O_CREAT because + results are undefined. + conformance/interfaces/mq_open/18-1: execution: FAILED: Output: + mq_open() did not return success w/O_NONBLOCK set: Function not implemented + Test FAILED + conformance/interfaces/mq_open/19-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/2-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/20-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/22-1: execution: UNTESTED: Output: + Will not test returning EACCESS when privileges are denied + as POSIX does not define when this error occurs. + conformance/interfaces/mq_open/23-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/24-1: execution: UNTESTED: Output: + Will not test mq_open() being interrupted as it is + not possible to predictably interrupt an mq_open(). + conformance/interfaces/mq_open/25-1: execution: UNTESTED: Output: + Will not test mq_open() failing with EINVAL if mq_open() + is not supported for the name parameter as + unsupported names are implementation defined. + conformance/interfaces/mq_open/25-2: execution: FAILED: Output: + errno != EINVAL for mq_maxmsg 0 + errno != EINVAL for mq_maxmsg -1 + errno != EINVAL for mq_maxmsg -2147483648 + errno != EINVAL for mq_msgsize 0 + errno != EINVAL for mq_msgsize -1 + errno != EINVAL for mq_msgsize -2147483648 + Test FAILED + conformance/interfaces/mq_open/27-2: execution: FAILED: Output: + errno != ENAMETOOLONG + Test FAILED + conformance/interfaces/mq_open/28-1: execution: UNTESTED: Output: + Will not test returning with ENFILE if the system has + too many message queues as this is beyond this + test's domain. + conformance/interfaces/mq_open/29-1: execution: FAILED: Output: + errno != ENOENT + Test FAILED + conformance/interfaces/mq_open/30-1: execution: UNTESTED: Output: + Will not test mq_open() failing with ENOSPC when there + is not enough space to create the message queue + as system space cannot be controlled from this test. + conformance/interfaces/mq_open/4-1: execution: UNTESTED: Output: + Will not test that {OPEN_MAX} file and message queues can + be opened as we cannot determine at run-time if a given + implementation is implemented with a file descriptor. + conformance/interfaces/mq_open/7-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/7-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/7-3: execution: FAILED: Output: + mq_open() for read-only queue did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/8-1: execution: UNRESOLVED: Output: + mq_open() for write-only queue did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/8-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/9-1: execution: UNRESOLVED: Output: + mq_open() did not return success on read-write queue: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/9-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/speculative/26-1: execution: FAILED: Output: + mq_open() failed before expected + errno != EMFILE on > _POSIX_OPEN_MAX or _POSIX_MQ_OPEN_MAX queues + Test FAILED + conformance/interfaces/mq_receive/1-1: execution: FAILED: Output: + unexpected error: mq_receive 1-1: mq_open: Function not implemented + unexpected error: mq_receive 1-1: mq_send: Function not implemented + unexpected error: mq_receive 1-1: mq_send: Function not implemented + unexpected error: mq_receive 1-1: mq_receive: Function not implemented + unexpected error: mq_receive 1-1: mq_receive: Function not implemented + unexpected error: mq_receive 1-1: mq_close: Function not implemented + unexpected error: mq_receive 1-1: mq_unlink: Function not implemented + FAIL: mq_receive didn't receive the highest priority message + FAIL: receive priority 134520252 != send priority 2 + FAIL: mq_receive didn't receive the correct message + FAIL: receive priority 134520252 != send priority 1 + Test FAILED + conformance/interfaces/mq_receive/10-1: execution: FAILED: Output: + unexpected error: mq_receive 10-1: mq_open: Function not implemented + unexpected error: mq_receive 10-1: mq_close: Function not implemented + unexpected error: mq_receive 10-1: mq_unlink: Function not implemented + errno != EAGAIN + Test FAILED + conformance/interfaces/mq_receive/11-1: execution: FAILED: Output: + unexpected error: mq_receive 11-1: mq_open(): Function not implemented + unexpected error: mq_receive 11-1: mq_close(): Function not implemented + unexpected error: mq_receive 11-1: mq_unlink(): Function not implemented + errno != EBADF + Test FAILED + conformance/interfaces/mq_receive/11-2: execution: FAILED: Output: + unexpected error: mq_receive 11-2: mq_open(): Function not implemented + unexpected error: mq_receive 11-2: mq_close: Function not implemented + unexpected error: mq_receive 11-2: mq_unlink(): Function not implemented + errno != EBADF + Test FAILED + conformance/interfaces/mq_receive/12-1: execution: FAILED: Output: + unexpected error: mq_receive 12-1: mq_open: Function not implemented + unexpected error: mq_receive 12-1: mq_send: Function not implemented + unexpected error: mq_receive 12-1: mq_close: Function not implemented + unexpected error: mq_receive 12-1: mq_unlink: Function not implemented + errno != EMSGSIZE + Test FAILED + conformance/interfaces/mq_receive/13-1: execution: UNRESOLVED: Output: + unexpected error: mq_receive 13-1: mq_open: Function not implemented + mq_close() did not return success: Function not implemented + mq_unlink() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_receive/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_receive 2-1: mq_open: Function not implemented + unexpected error: mq_receive 2-1: mq_send: Function not implemented + unexpected error: mq_receive 2-1: mq_close: Function not implemented + unexpected error: mq_receive 2-1: mq_unlink: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_receive/5-1: execution: FAILED: Output: + unexpected error: mq_receive 5-1: mq_open: Function not implemented + unexpected error: mq_receive 5-1: mq_send: Function not implemented + unexpected error: mq_receive 5-1: mq_receive: Function not implemented + unexpected error: mq_receive 5-1: mq_close: Function not implemented + unexpected error: mq_receive 5-1: mq_unlink: Function not implemented + Test FAILED + conformance/interfaces/mq_receive/7-1: execution: UNRESOLVED: Output: + unexpected error: mq_receive 7-1: mq_open: Function not implemented + unexpected error: mq_receive 7-1: mq_close: Function not implemented + unexpected error: mq_receive 7-1: mq_unlink: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_receive/8-1: execution: FAILED: Output: + unexpected error: mq_receive 8-1: mq_open: Function not implemented + unexpected error: mq_receive 8-1: mq_send: Function not implemented + unexpected error: mq_receive 8-1: mq_send: Function not implemented + unexpected error: mq_receive 8-1: mq_close: Function not implemented + unexpected error: mq_receive 8-1: mq_unlink: Function not implemented + FAIL: mq_receive didn't return the selected message size correctly + FAIL: mq_receive didn't return the selected message size correctly + Test FAILED + conformance/interfaces/mq_send/1-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/10-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/11-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/11-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/12-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/14-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/2-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/3-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/3-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/5-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/5-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/6-1: execution: UNTESTED: Output: + Priority Scheduling needed to make a reliable test case + for this instance. Will not be tested. + conformance/interfaces/mq_send/8-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/9-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_setattr/1-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_setattr/1-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_setattr/2-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_setattr/5-1: execution: UNRESOLVED: Output: + unexpected error: mq_setattr 5-1: mq_open(): Function not implemented + conformance/interfaces/mq_timedreceive/1-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 1-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_timedreceive: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_timedreceive: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_unlink: Function not implemented + FAIL: mq_timedreceive didn't receive the highest priority message + FAIL: receive priority 134520424 != send priority 2 + FAIL: mq_timedreceive didn't receive the correct message + FAIL: receive priority 134520424 != send priority 1 + Test FAILED + conformance/interfaces/mq_timedreceive/10-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 10-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_send: Function not implemented + FAIL: mq_receive fails unexpectly + : Function not implemented + unexpected error: mq_timedreceive 10-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_unlink: Function not implemented + Test FAILED + conformance/interfaces/mq_timedreceive/10-2: execution: FAILED: Output: + unexpected error: mq_timedreceive 10-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_send: Function not implemented + Unexpected error at mq_timedreceive: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_unlink: Function not implemented + Test FAILED + conformance/interfaces/mq_timedreceive/11-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 11-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 11-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 11-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 11-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 11-1: mq_unlink: Function not implemented + FAIL: mq_timedreceive didn't return the selected message size correctly + FAIL: mq_timedreceive didn't return the selected message size correctly + Test FAILED + conformance/interfaces/mq_timedreceive/13-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 13-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 13-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 13-1: mq_unlink: Function not implemented + errno != EAGAIN + Test FAILED + conformance/interfaces/mq_timedreceive/14-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 14-1: mq_open(): Function not implemented + unexpected error: mq_timedreceive 14-1: mq_close(): Function not implemented + unexpected error: mq_timedreceive 14-1: mq_unlink(): Function not implemented + errno != EBADF + Test FAILED + conformance/interfaces/mq_timedreceive/15-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 15-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 15-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 15-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 15-1: mq_unlink: Function not implemented + errno != EMSGSIZE + Test FAILED + conformance/interfaces/mq_timedreceive/17-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 17-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 17-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 17-1: mq_unlink: Function not implemented + errno != EINVAL + Test FAILED + conformance/interfaces/mq_timedreceive/17-2: execution: FAILED: Output: + unexpected error: mq_timedreceive 17-2: mq_open: Function not implemented + unexpected error: mq_timedreceive 17-2: mq_close: Function not implemented + unexpected error: mq_timedreceive 17-2: mq_unlink: Function not implemented + errno != EINVAL + Test FAILED + conformance/interfaces/mq_timedreceive/17-3: execution: FAILED: Output: + unexpected error: mq_timedreceive 17-3: mq_open: Function not implemented + unexpected error: mq_timedreceive 17-3: mq_close: Function not implemented + unexpected error: mq_timedreceive 17-3: mq_unlink: Function not implemented + errno != EINVAL + Test FAILED + conformance/interfaces/mq_timedreceive/18-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 18-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 18-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 18-1: mq_unlink: Function not implemented + errno != ETIMEDOUT + Test FAILED + conformance/interfaces/mq_timedreceive/18-2: execution: FAILED: Output: + unexpected error: mq_timedreceive 18-2: mq_open: Function not implemented + unexpected error: mq_timedreceive 18-2: mq_close: Function not implemented + unexpected error: mq_timedreceive 18-2: mq_unlink: Function not implemented + errno != ETIMEDOUT + Test FAILED + conformance/interfaces/mq_timedreceive/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_timedreceive 2-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 2-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 2-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 2-1: mq_unlink: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedreceive/5-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 5-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 5-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 5-1: mq_timedreceive: Function not implemented + unexpected error: mq_timedreceive 5-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 5-1: mq_unlink: Function not implemented + mq_timedreceive didn't block on waiting + Test FAILED + conformance/interfaces/mq_timedreceive/5-2: execution: FAILED: Output: + unexpected error: mq_timedreceive 5-2: mq_open: Function not implemented + unexpected error: mq_timedreceive 5-2: mq_close: Function not implemented + unexpected error: mq_timedreceive 5-2: mq_unlink: Function not implemented + FAIL: mq_timedreceive didn't block until timout expires + Test FAILED + conformance/interfaces/mq_timedreceive/5-3: execution: UNRESOLVED: Output: + unexpected error: mq_timedreceive 5-3: mq_open: Function not implemented + mq_close() did not return success: Function not implemented + mq_unlink() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedreceive/7-1: execution: UNRESOLVED: Output: + unexpected error: mq_timedreceive 7-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 7-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 7-1: mq_unlink: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedreceive/8-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 8-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 8-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 8-1: mq_unlink: Function not implemented + Using CLOCK_REALTIME + FAIL: mq_timedreceive didn't block until timout expires + Test FAILED + conformance/interfaces/mq_timedreceive/speculative/10-2: execution: UNRESOLVED: Output: + unexpected error: mq_timedreceive 10-2: mq_open: Function not implemented + unexpected error: mq_timedreceive 10-2: mq_send: Function not implemented + unexpected error: mq_timedreceive 10-2: mq_close: Function not implemented + unexpected error: mq_timedreceive 10-2: mq_unlink: Function not implemented + mq_timedreceive() did fail on invalid abs_time + Test UNRESOLVED + conformance/interfaces/mq_timedsend/1-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/10-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/11-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/11-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/12-1: execution: INTERRUPTED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/14-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/15-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedsend/16-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/17-1: execution: UNTESTED: Output: + Will not test timeout resolution. + conformance/interfaces/mq_timedsend/18-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedsend/19-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedsend/2-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/20-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedsend/3-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/3-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/5-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/5-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/5-3: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/6-1: execution: UNTESTED: Output: + Priority Scheduling needed to make a reliable test case + for this instance. Will not be tested. + conformance/interfaces/mq_timedsend/7-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/8-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/9-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/speculative/18-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_unlink/1-1: execution: UNRESOLVED: Output: + unexpected error: mq_unlink 1-1: mq_open: Function not implemented + conformance/interfaces/mq_unlink/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_unlink 2-1: mq_open: Function not implemented + unexpected error: mq_unlink 2-1: read: EOF + conformance/interfaces/mq_unlink/2-2: execution: UNRESOLVED: Output: + unexpected error: mq_unlink 2-2: mq_open: Function not implemented + unexpected error: mq_unlink 2-2: read: EOF + conformance/interfaces/mq_unlink/2-3: execution: UNTESTED: Output: + Difficult to detect whether mq_unlink will block until all the reference have been closed + for this instance. Will not be tested. + conformance/interfaces/mq_unlink/7-1: execution: FAILED: Output: + Test FAILED + conformance/interfaces/mq_unlink/speculative/7-2: execution: FAILED: Output: + Test FAILED, error is Function not implemented + conformance/interfaces/munlock/10-1: execution: UNRESOLVED: Output: + Unexpected error: Operation not permitted + conformance/interfaces/munlock/11-1: execution: UNRESOLVED: Output: + Unexpected error: Operation not permitted + conformance/interfaces/munlock/7-1: execution: UNRESOLVED: Output: + You don't have permission to lock your address space. + Try to rerun this test as root. + conformance/interfaces/munmap/3-1: execution: FAILED: Output: + Test FAILED: munmap/3-1.c munmap returns: No such file or directory + conformance/interfaces/munmap/4-1: execution: UNRESOLVED: Output: + munmap/4-1.c Error at msync(): Error in unknown error system: FFFFFFFF + conformance/interfaces/munmap/8-1: execution: FAILED: Output: + Test FAILED: Expect EINVAL but get: (os/kern) successful + conformance/interfaces/munmap/9-1: execution: FAILED: Output: + Test Fail: Expect EINVAL while get No such file or directory + conformance/interfaces/nanosleep/10000-1: execution: INTERRUPTED: Output: + conformance/interfaces/nanosleep/5-1: execution: FAILED: Output: + nanosleep() did not return -1 on failure + conformance/interfaces/nanosleep/5-2: execution: FAILED: Output: + In handler + Child did not exit normally. + Test FAILED + conformance/interfaces/nanosleep/6-1: execution: UNRESOLVED: Output: + sleep -1 + nanosleep() did not return -1 on failure + conformance/interfaces/nanosleep/7-1: execution: FAILED: Output: + In handler + nanosleep did not return -1 + Child did not exit normally. + Test FAILED + conformance/interfaces/nanosleep/7-2: execution: FAILED: Output: + In handler + nanosleep() was not interrupted + Child did not exit normally. + Test FAILED + conformance/interfaces/pthread_atfork/1-1: execution: UNRESOLVED: Output: + Error in pthread_atfork + conformance/interfaces/pthread_atfork/1-2: execution: UNRESOLVED: Output: + [11:58:02]Test conformance/interfaces/pthread_atfork/1-2.c unresolved: got 1073741902 (Function not implemented) on line 216 (Failed to register the atfork handlers) + conformance/interfaces/pthread_atfork/2-1: execution: FAILED: Output: + Test FAILED: Expected return value success, instead received 1073741902 + conformance/interfaces/pthread_atfork/2-2: execution: UNRESOLVED: Output: + [11:58:03]Test conformance/interfaces/pthread_atfork/2-2.c unresolved: got 1073741902 (Function not implemented) on line 244 (Failed to register the atfork handlers(N,N,N)) + conformance/interfaces/pthread_atfork/3-2: execution: UNRESOLVED: Output: + [11:58:03]Test conformance/interfaces/pthread_atfork/3-2.c unresolved: got 1073741902 (Function not implemented) on line 213 (Failed to register the atfork handlers) + conformance/interfaces/pthread_atfork/3-3: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_atfork/4-1: execution: UNRESOLVED: Output: + [12:10:53]Test conformance/interfaces/pthread_atfork/4-1.c unresolved: got 1073741902 (Function not implemented) on line 244 (Failed to register the atfork handlers) + conformance/interfaces/pthread_attr_getschedparam/1-1: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_getschedparam 1-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_getschedpolicy/2-1: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_getschedpolicy 1-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setinheritsched/2-1: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_setinheritsched 2-1: pthread_attr_setschedpolicy: (os/kern) successful + conformance/interfaces/pthread_attr_setinheritsched/2-2: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_setinheritsched 2-2: pthread_attr_setschedpolicyconformance/interfaces/pthread_attr_setinheritsched/2-3: execution: UNRESOLVED: Output: + unexpected error: scheduler 4-1: pthread_setschedparam + conformance/interfaces/pthread_attr_setinheritsched/2-4: execution: UNRESOLVED: Output: + unexpected error: scheduler 4-2: pthread_setschedparam + conformance/interfaces/pthread_attr_setschedparam/1-1: execution: FAILED: Output: + unexpected error: pthread_attr_setschedparam 1-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/1-2: execution: FAILED: Output: + unexpected error: pthread_attr_setschedparam 1-2: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/1-3: execution: UNRESOLVED: Output: + unexpected error: scheduler 3-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/1-4: execution: UNRESOLVED: Output: + unexpected error: scheduler 3-2: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/speculative/3-1: execution: FAILED: Output: + unexpected error: pthread_attr_setschedparam 3-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/speculative/3-2: execution: FAILED: Output: + unexpected error: pthread_attr_setschedpaarm 3-2: pthread_attr_setschedpolicyconformance/interfaces/pthread_attr_setschedpolicy/1-1: execution: FAILED: Output: + Error on pthread_attr_setschedpolicy() rc=1073741942 + conformance/interfaces/pthread_attr_setschedpolicy/speculative/5-1: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_setschedpolicy 5-1: pthread_attr_setinheritsched + conformance/interfaces/pthread_attr_setscope/5-1: execution: UNTESTED: Output: + Untested for now, cannot find a unsupported inheritsched value + conformance/interfaces/pthread_barrierattr_getpshared/2-1: execution: UNRESOLVED: Output: + Error at pthread_barrierattr_setpshared() + conformance/interfaces/pthread_barrierattr_setpshared/1-1: execution: FAILED: Output: + Test FAILED: Error at pthread_barrierattr_setpshared() + conformance/interfaces/pthread_cancel/3-1: execution: UNRESOLVED: Output: + unexpected error: pthread_cancel 3-1: pthread_setschedparam + conformance/interfaces/pthread_cancel/5-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_broadcast/1-2: execution: UNRESOLVED: Output: + [12:42:33]Test starting + [12:42:33]System abilities: + [12:42:33] TPS : -1 + [12:42:33] CS : 200112 + [12:42:33] MON : -1 + [12:42:33] MF : 200112 + [12:42:33]Process-shared attributes won't be tested + [12:42:33]Alternative clock won't be tested + [12:42:33]Test conformance/interfaces/pthread_cond_broadcast/1-2.c unresolved: got 1073741846 (Invalid argument) on line 393 ([parent] Failed to set thread stack size) + conformance/interfaces/pthread_cond_broadcast/2-3: execution: UNRESOLVED: Output: + [12:42:36]Test starting + [12:42:36]System abilities: + [12:42:36] TPS : -1 + [12:42:36] CS : 200112 + [12:42:36] MON : -1 + [12:42:36] MF : 200112 + [12:42:36]Process-shared attributes won't be tested + [12:42:36]Alternative clock won't be tested + [12:42:36]Test conformance/interfaces/pthread_cond_broadcast/2-3.c unresolved: got 1073741846 (Invalid argument) on line 384 ([parent] Failed to set thread stack size) + conformance/interfaces/pthread_cond_broadcast/4-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_destroy/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_init/1-2: execution: UNTESTED: Output: + File conformance/interfaces/pthread_cond_init/1-2.c cannot test: This test requires unsupported features + conformance/interfaces/pthread_cond_init/1-3: execution: UNTESTED: Output: + File conformance/interfaces/pthread_cond_init/1-3.c cannot test: This test requires unsupported features + conformance/interfaces/pthread_cond_init/2-2: execution: UNTESTED: Output: + File conformance/interfaces/pthread_cond_init/2-2.c cannot test: This test requires unsupported features + conformance/interfaces/pthread_cond_init/4-1: execution: UNRESOLVED: Output: + Test conformance/interfaces/pthread_cond_init/4-1.c unresolved: got 1073741942 (Not supported) on line 145 (Cond attribute PSHARED failed) + conformance/interfaces/pthread_cond_init/4-2: execution: INTERRUPTED: Output: + Test conformance/interfaces/pthread_cond_init/4-2.c unresolved: got 1073741942 (Not supported) on line 171 (Cond attribute PSHARED failed) + conformance/interfaces/pthread_cond_signal/1-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_signal/4-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_timedwait/4-3: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_wait/4-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_condattr_getpshared/1-2: execution: UNRESOLVED: Output: + Error in pthread_condattr_setpshared(), error: 1073741942 + conformance/interfaces/pthread_condattr_setclock/1-2: execution: UNSUPPORTED: Output: + UNSUPPORTED: CLOCK_MONOTONIC is unsupported + conformance/interfaces/pthread_condattr_setclock/1-3: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME unsupported + conformance/interfaces/pthread_condattr_setpshared/1-2: execution: FAILED: Output: + Test FAILED: Could not set pshared to PTHREAD_PROCESS_SHARED, error: 1073741942 + conformance/interfaces/pthread_create/1-4: execution: UNTESTED: Output: + [13:44:56]System abilities: + [13:44:56] TSA: -1 + [13:44:56] TSS: -1 + [13:44:56] TPS: -1 + [13:44:56] pagesize: 4096 + [13:44:56] min stack size: -1 + [13:44:56]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/1-5: execution: UNTESTED: Output: + [13:44:56]System abilities: + [13:44:56] TSA: -1 + [13:44:56] TSS: -1 + [13:44:56] TPS: -1 + [13:44:56] pagesize: 4096 + [13:44:56] min stack size: -1 + [13:44:56]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/1-6: execution: UNTESTED: Output: + [13:44:57]System abilities: + [13:44:57] TSA: -1 + [13:44:57] TSS: -1 + [13:44:57] TPS: -1 + [13:44:57] pagesize: 4096 + [13:44:57] min stack size: -1 + [13:44:57]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/11-1: execution: UNSUPPORTED: Output: + _POSIX_THREAD_CPUTIME not supported + conformance/interfaces/pthread_create/14-1: execution: UNTESTED: Output: + [13:45:08]System abilities: + [13:45:08] TSA: -1 + [13:45:08] TSS: -1 + [13:45:08] TPS: -1 + [13:45:08] pagesize: 4096 + [13:45:08] min stack size: -1 + [13:45:08]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/15-1: execution: UNTESTED: Output: + [13:45:09]System abilities: + [13:45:09] TSA: -1 + [13:45:09] TSS: -1 + [13:45:09] TPS: -1 + [13:45:09] pagesize: 4096 + [13:45:09] min stack size: -1 + [13:45:09]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/3-2: execution: UNTESTED: Output: + [13:45:11]Growing down stack started upon 0x19fffa0 and we are currently down to 0x19fff60 + [13:45:11]Test starting + Stack tests will be executed. + Sched tests won't be executed. + [13:45:11]System abilities: + [13:45:11] TSA: -1 + [13:45:11] TSS: -1 + [13:45:11] TPS: -1 + [13:45:11] pagesize: 4096 + [13:45:11] min stack size: -1 + [13:45:11]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/8-2: execution: UNTESTED: Output: + [13:45:13]System abilities: + [13:45:13] TSA: -1 + [13:45:13] TSS: -1 + [13:45:13] TPS: -1 + [13:45:13] pagesize: 4096 + [13:45:13] min stack size: -1 + [13:45:13]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_detach/1-2: execution: UNTESTED: Output: + [13:45:13]System abilities: + [13:45:13] TSA: -1 + [13:45:13] TSS: -1 + [13:45:13] TPS: -1 + [13:45:13] pagesize: 4096 + [13:45:13] min stack size: -1 + [13:45:13]File conformance/interfaces/pthread_detach/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_detach/2-2: execution: UNTESTED: Output: + [13:45:14]System abilities: + [13:45:14] TSA: -1 + [13:45:14] TSS: -1 + [13:45:14] TPS: -1 + [13:45:14] pagesize: 4096 + [13:45:14] min stack size: -1 + [13:45:14]File conformance/interfaces/pthread_detach/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_detach/4-3: execution: UNTESTED: Output: + [13:45:15]System abilities: + [13:45:16] TSA: -1 + [13:45:16] TSS: -1 + [13:45:16] TPS: -1 + [13:45:16] pagesize: 4096 + [13:45:16] min stack size: -1 + [13:45:16]File conformance/interfaces/pthread_detach/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_equal/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_exit/1-2: execution: UNTESTED: Output: + [15:01:43]System abilities: + [15:01:43] TSA: -1 + [15:01:43] TSS: -1 + [15:01:43] TPS: -1 + [15:01:43] pagesize: 4096 + [15:01:43] min stack size: -1 + [15:01:43]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/2-2: execution: UNTESTED: Output: + [15:01:44]System abilities: + [15:01:44] TSA: -1 + [15:01:44] TSS: -1 + [15:01:44] TPS: -1 + [15:01:44] pagesize: 4096 + [15:01:44] min stack size: -1 + [15:01:44]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/3-2: execution: UNTESTED: Output: + [15:01:45]System abilities: + [15:01:45] TSA: -1 + [15:01:45] TSS: -1 + [15:01:45] TPS: -1 + [15:01:45] pagesize: 4096 + [15:01:45] min stack size: -1 + [15:01:45]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/4-1: execution: UNTESTED: Output: + [15:01:45]System abilities: + [15:01:45] TSA: -1 + [15:01:45] TSS: -1 + [15:01:45] TPS: -1 + [15:01:45] pagesize: 4096 + [15:01:45] min stack size: -1 + [15:01:45]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/5-1: execution: UNTESTED: Output: + [15:01:46]System abilities: + [15:01:46] TSA: -1 + [15:01:46] TSS: -1 + [15:01:46] TPS: -1 + [15:01:46] pagesize: 4096 + [15:01:46] min stack size: -1 + [15:01:46]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/6-1: execution: UNTESTED: Output: + [15:01:46]System abilities: + [15:01:46] TSA: -1 + [15:01:46] TSS: -1 + [15:01:46] TPS: -1 + [15:01:46] pagesize: 4096 + [15:01:46] min stack size: -1 + [15:01:46]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/6-2: execution: UNTESTED: Output: + [15:01:46]System abilities: + [15:01:46] TSA: -1 + [15:01:46] TSS: -1 + [15:01:46] TPS: -1 + [15:01:46] pagesize: 4096 + [15:01:46] min stack size: -1 + [15:01:46]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_getschedparam/1-1: execution: FAILED: Output: + Error at pthread_getschedparam: rc=1073741902 + conformance/interfaces/pthread_getschedparam/1-2: execution: UNRESOLVED: Output: + Error at pthread_setschedparam: rc=1073741902 + conformance/interfaces/pthread_getschedparam/1-3: execution: UNRESOLVED: Output: + [15:01:49]Test conformance/interfaces/pthread_getschedparam/1-3.c unresolved: got 1073741902 (Function not implemented) on line 223 (Failed to get min priority) + conformance/interfaces/pthread_getschedparam/4-1: execution: UNRESOLVED: Output: + [15:01:49]Test conformance/interfaces/pthread_getschedparam/4-1.c unresolved: got 1073741902 (Function not implemented) on line 200 (Unexpected error returned) + conformance/interfaces/pthread_join/1-2: execution: UNTESTED: Output: + [15:01:54]System abilities: + [15:01:54] TSA: -1 + [15:01:54] TSS: -1 + [15:01:54] TPS: -1 + [15:01:54] pagesize: 4096 + [15:01:54] min stack size: -1 + [15:01:54]File conformance/interfaces/pthread_join/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_join/3-1: execution: UNRESOLVED: Output: + Error in pthread_testcancel(). Cancel request timed out. + : (os/kern) successful + conformance/interfaces/pthread_join/4-1: execution: UNTESTED: Output: + [15:02:06]System abilities: + [15:02:06] TSA: -1 + [15:02:06] TSS: -1 + [15:02:06] TPS: -1 + [15:02:06] pagesize: 4096 + [15:02:06] min stack size: -1 + [15:02:06]File conformance/interfaces/pthread_join/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_join/6-3: execution: UNTESTED: Output: + [15:02:07]System abilities: + [15:02:07] TSA: -1 + [15:02:07] TSS: -1 + [15:02:07] TPS: -1 + [15:02:07] pagesize: 4096 + [15:02:07] min stack size: -1 + [15:02:07]File conformance/interfaces/pthread_join/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_key_create/2-1: execution: INTERRUPTED: Output: + 2-1.test: /var/tmp/hurd-20090404/./libpthread/sysdeps/hurd/pt-getspecific.c:30: pthread_getspecific: Assertion `key < __pthread_key_count' failed. + conformance/interfaces/pthread_kill/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_kill/3-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_kill/7-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_kill/8-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_mutex_getprioceiling/1-1: execution: FAILED: Output: + Test FAILED: Error obtaining the priority ceiling + +Another system crash, due to conformance/interfaces/pthread_mutex_init/5-1: + + (default pager): dropping data_request because of previous paging errors + (default pager): dropping data_request because of previous paging errors + (default pager): dropping data_request because of previous paging errors + (default pager): dropping data_request because of previous paging errors + +Disable the panic-causing test (conformance/interfaces/pthread_mutex_init/5-1) +and restart: + + conformance/interfaces/pthread_mutex_init/speculative/5-2: execution: UNTESTED: Output: + Implementation is: + GNU + 0.3 + GNU-Mach 1.3.99/Hurd-0.3 + This implementation is not tested yet + conformance/interfaces/pthread_mutex_timedlock/5-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_mutex_timedlock/5-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_mutex_trylock/4-3: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_mutexattr_getprioceiling/1-1: execution: UNRESOLVED: Output: + Error obtaining the attribute process-shared + conformance/interfaces/pthread_mutexattr_getprioceiling/1-2: execution: UNRESOLVED: Output: + Error setting prioceiling to -1 + conformance/interfaces/pthread_mutexattr_getprioceiling/3-1: execution: FAILED: Output: + Test FAILED: Invalid return code 1073741902. Expected EINVAL or 0. + conformance/interfaces/pthread_mutexattr_getprotocol/1-2: execution: UNRESOLVED: Output: + Error setting protocol to 1 + conformance/interfaces/pthread_mutexattr_getpshared/1-2: execution: UNRESOLVED: Output: + Error in pthread_mutexattr_setpshared(), error: 1073741942 + conformance/interfaces/pthread_mutexattr_gettype/speculative/3-1: execution: FAILED: Output: + Test FAILED: Incorrect return code. Expected EINVAL, but got: 0 + conformance/interfaces/pthread_mutexattr_setprioceiling/1-1: execution: FAILED: Output: + Test FAILED: Error setting prioceiling to -1 + conformance/interfaces/pthread_mutexattr_setprioceiling/3-1: execution: FAILED: Output: + Test FAILED: Invalid return code 1073741902. Expected EINVAL or 0. + conformance/interfaces/pthread_mutexattr_setprioceiling/3-2: execution: FAILED: Output: + Test FAILED: Invalid return code 1073741902. Expected EINVAL or 0. + conformance/interfaces/pthread_mutexattr_setprotocol/1-1: execution: UNRESOLVED: Output: + Error setting protocol to 1 + conformance/interfaces/pthread_mutexattr_setpshared/1-1: execution: FAILED: Output: + Test FAILED: Cannot set pshared attribute to PTHREAD_PROCESS_SHARED. Error code: 1073741942 + conformance/interfaces/pthread_mutexattr_setpshared/2-2: execution: FAILED: Output: + Test FAILED: Expected return code 0, got: 1073741942 + conformance/interfaces/pthread_rwlock_rdlock/2-1: execution: FAILED: Output: + main: has priority: 1 + main: attempt read lock + main: acquired read lock + main: create wr_thread, with priority: 0 + wr_thread: attempt write lock + main: create rd_thread, with priority: -1 + rd_thread: attempt read lock + rd_thread: acquired read lock + rd_thread: unlock read lock + Test FAILED: rd_thread did not block on read lock, when a reader owns the lock, and a higher priority writer is waiting for the lock + conformance/interfaces/pthread_rwlock_rdlock/2-2: execution: FAILED: Output: + main: attempt read lock + main: acquired read lock + main: create wr_thread, with priority: 0 + wr_thread: attempt write lock + main: create rd_thread, with priority: 0 + rd_thread: attempt read lock + rd_thread: acquired read lock + rd_thread: unlock read lock + Test FAILED: rd_thread did not block on read lock, when a reader owns the lock, and an equal priority writer is waiting for the lock + conformance/interfaces/pthread_rwlock_unlock/3-1: execution: FAILED: Output: + main: write lock + main: create writer1, with priority: 1 + writer1: attempt write lock + main: create reader, with priority: 1 + reader: attempt read lock + main: create writer2, with priority: -1 + writer2: attempt write lock + main: release write lock + writer2: acquired writer lock + Test fail: writer did not get write lock, when main release the lock + conformance/interfaces/pthread_rwlock_unlock/4-1: execution: INTERRUPTED: Output: + 4-1.test: /var/tmp/hurd-20090404/./libpthread/sysdeps/generic/pt-rwlock-unlock.c:34: pthread_rwlock_unlock: Assertion `__pthread_spin_trylock (&rwlock->__held) == ((0x10 << 26) | ((16) & 0x3fff))' failed. + conformance/interfaces/pthread_rwlock_unlock/4-2: execution: INTERRUPTED: Output: + 4-2.test: /var/tmp/hurd-20090404/./libpthread/sysdeps/generic/pt-rwlock-unlock.c:34: pthread_rwlock_unlock: Assertion `__pthread_spin_trylock (&rwlock->__held) == ((0x10 << 26) | ((16) & 0x3fff))' failed. + main: attempt read lock + main: acquired read lock + main: create un_thread + un_thread: unlock read lock + conformance/interfaces/pthread_rwlock_wrlock/3-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_rwlockattr_getpshared/2-1: execution: UNRESOLVED: Output: + Error at pthread_rwlockattr_setpshared() + conformance/interfaces/pthread_rwlockattr_setpshared/1-1: execution: FAILED: Output: + Test FAILED: Error at pthread_rwlockattr_setpshared(), return error: 1073741942 + conformance/interfaces/pthread_setschedparam/1-1: execution: FAILED: Output: + Error at pthread_setschedparam: rc=1073741902 + conformance/interfaces/pthread_setschedparam/1-2: execution: UNTESTED: Output: + [08:51:19]File conformance/interfaces/pthread_setschedparam/1-2.c cannot test: Failed to get min SCHED_RR range + conformance/interfaces/pthread_setschedparam/4-1: execution: UNRESOLVED: Output: + [08:51:20]Test conformance/interfaces/pthread_setschedparam/4-1.c unresolved: got 1073741902 (Function not implemented) on line 132 (Failed to set thread policy -- need to be root?) + conformance/interfaces/pthread_setschedparam/5-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_setschedprio/1-1: execution: UNRESOLVED: Output: + Error at pthread_setschedparam: rc=1073741902 + conformance/interfaces/pthread_sigmask/10-1: execution: FAILED: Output: + FAIL: SIGKILL was added to the signal mask + Test FAILED + conformance/interfaces/pthread_sigmask/18-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_sigmask/4-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_sigmask/5-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_sigmask/6-1: execution: HUNG: Output: + conformance/interfaces/pthread_sigmask/9-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_spin_lock/1-1: execution: INTERRUPTED: Output: + conformance/interfaces/sched_get_priority_max/1-1: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_max/1-2: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_max/1-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_get_priority_max/1-4: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_max/2-1: execution: FAILED: Output: + error is not EINVAL: Function not implemented + conformance/interfaces/sched_get_priority_min/1-1: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_min/1-2: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_min/1-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_get_priority_min/1-4: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_min/2-1: execution: FAILED: Output: + error is not EINVAL: Function not implemented + conformance/interfaces/sched_getparam/1-1: execution: FAILED: Output: + Return code is not zero. + conformance/interfaces/sched_getparam/2-1: execution: FAILED: Output: + Different results between pid == 0 and pid == getpid(). + conformance/interfaces/sched_getparam/3-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/sched_getparam/4-1: execution: FAILED: Output: + errno is not ESRCH: Function not implemented + conformance/interfaces/sched_getparam/6-1: execution: UNRESOLVED: Output: + errno is not EPERM: The system allows a non-rootuser to use sched_getparam(): Function not implemented + conformance/interfaces/sched_getparam/speculative/7-1: execution: UNRESOLVED: Output: + sched_getparam() return -1 and sets errno == 1073741902. + conformance/interfaces/sched_getscheduler/1-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/sched_getscheduler/2-1: execution: UNTESTED: Output: + Will not test the behavior of sched_getscheduler() when pid is negative + because it is unspecified. + conformance/interfaces/sched_getscheduler/3-1: execution: FAILED: Output: + Returned code is -1. + conformance/interfaces/sched_getscheduler/4-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/sched_getscheduler/7-1: execution: FAILED: Output: + errno is not EPERM: Function not implemented + conformance/interfaces/sched_rr_get_interval/1-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/sched_rr_get_interval/2-1: execution: FAILED: Output: + interval.tv_sec not updated. + conformance/interfaces/sched_rr_get_interval/3-1: execution: FAILED: Output: + Returned error is not ESRCH: Function not implemented + conformance/interfaces/sched_rr_get_interval/speculative/5-1: execution: UNRESOLVED: Output: + sched_rr_get_interval() return -1 and sets errno == 1073741902. + conformance/interfaces/sched_setparam/1-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/10-1: execution: UNRESOLVED: Output: + An error occurs when calling shmget(): Invalid argument + conformance/interfaces/sched_setparam/12-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setparam/13-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setparam/14-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setparam/15-1: execution: UNTESTED: Output: + Will not test the effects of the sched_ss_low_priority, + sched_ss_repl_period, and sched_ss_init_budget members when the scheduling + policy of the target process is not SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC. + It is implementation-defined. + conformance/interfaces/sched_setparam/16-1: execution: UNTESTED: Output: + Will not test the result of sched_setparam when the scheduling policy of the + target process is not SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC. + It is implementation-defined. + conformance/interfaces/sched_setparam/17-1: execution: UNTESTED: Output: + Will not test that sched_setparam have no effect on the scheduling of threads + with system scheduling contention scope. + conformance/interfaces/sched_setparam/18-1: execution: UNTESTED: Output: + Will not test that the threads scheduling policy and associated parameters + are not affected. + conformance/interfaces/sched_setparam/19-1: execution: UNTESTED: Output: + Will not test that the underlying kernel-scheduled entities for the system + contention scope threads are not be affected by this sched_setparam(). + conformance/interfaces/sched_setparam/2-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_setscheduler(): Function not implemented + conformance/interfaces/sched_setparam/2-2: execution: UNRESOLVED: Output: + An error occurs when calling sched_setscheduler(): Function not implemented + conformance/interfaces/sched_setparam/22-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/23-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/23-2: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/23-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/23-4: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/23-5: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/23-6: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/23-7: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/25-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getscheduler(): Function not implemented + conformance/interfaces/sched_setparam/25-2: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/26-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/27-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/3-1: execution: UNTESTED: Output: + Will not test the behavior of sched_setparam() when pid is negative because + it is unspecified. + conformance/interfaces/sched_setparam/5-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/6-1: execution: UNTESTED: Output: + Will not test the conditions under which one process has permission to + change the scheduling parameters of another process, because they are + implementation-defined. + conformance/interfaces/sched_setparam/7-1: execution: UNTESTED: Output: + Will not test that implementations may require the requesting process to + have the appropriate privilege to set its own scheduling parameters or those + of another process. + conformance/interfaces/sched_setparam/8-1: execution: UNTESTED: Output: + Will not test that the target process is moved to the tail of the thread + list for its priority when it is running. + conformance/interfaces/sched_setparam/9-1: execution: UNRESOLVED: Output: + An error occurs when calling shmget(): Invalid argument + conformance/interfaces/sched_setscheduler/1-1: execution: UNRESOLVED: Output: + Policy: SCHED_FIFO + Error calling sched_setscheduler() for SCHED_FIFO policy + Policy: SCHED_RR + Error calling sched_setscheduler() for SCHED_RR policy + Policy: SCHED_OTHER + Error calling sched_setscheduler() for SCHED_OTHER policy + conformance/interfaces/sched_setscheduler/10-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setscheduler/11-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setscheduler/12-1: execution: UNTESTED: Output: + Will not test that sched_setscheduler have no effect on the scheduling of + threads with system scheduling contention scope. + conformance/interfaces/sched_setscheduler/13-1: execution: UNTESTED: Output: + Will not test that the threads scheduling policy and associated parameters + are not affected. + conformance/interfaces/sched_setscheduler/14-1: execution: UNTESTED: Output: + Will not test that the underlying kernel-scheduled entities for the system + contention scope threads are not be affected by sched_setscheduler(). + conformance/interfaces/sched_setscheduler/15-1: execution: UNSUPPORTED: Output: + Process contention scope threads are not supported. + conformance/interfaces/sched_setscheduler/16-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getscheduler(): Function not implemented + conformance/interfaces/sched_setscheduler/17-1: execution: UNRESOLVED: Output: + Policy: SCHED_FIFO + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/17-2: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/17-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/17-4: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/17-5: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/17-6: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/17-7: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/19-1: execution: UNRESOLVED: Output: + Policy: SCHED_FIFO + An error occurs when calling sched_get_priority_max(): Function not implemented + conformance/interfaces/sched_setscheduler/19-2: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/19-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/19-4: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/19-5: execution: FAILED: Output: + Unknow error: Function not implemented + conformance/interfaces/sched_setscheduler/2-1: execution: UNTESTED: Output: + Will not test the behavior of sched_setscheduler() when pid is negative + because it is unspecified. + conformance/interfaces/sched_setscheduler/20-1: execution: FAILED: Output: + errno is not EPERM: Function not implemented + conformance/interfaces/sched_setscheduler/21-1: execution: FAILED: Output: + errno is not ESRCH: Function not implemented + conformance/interfaces/sched_setscheduler/4-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/5-1: execution: UNTESTED: Output: + Will not test the condition under which one process has the appropriate + privilege to change the scheduling parameters of another process because + they are implementation-defined. + conformance/interfaces/sched_setscheduler/6-1: execution: UNTESTED: Output: + Will not test that implementations may require that the requesting process + have permission to set its own scheduling parameters or those of another + process. + conformance/interfaces/sched_setscheduler/7-1: execution: UNTESTED: Output: + Will not test if implementation-defined restrictions apply as to the + appropriate privileges required to set a process' own scheduling policy, or + another process' scheduling policy, to a particular value. + conformance/interfaces/sched_setscheduler/9-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sem_close/1-1: execution: INTERRUPTED: Output: + unexpected error: sem_close 1-1: sem_open: Operation not supported + conformance/interfaces/sem_close/2-1: execution: INTERRUPTED: Output: + unexpected error: sem_close 2-1: sem_open: Operation not supported + conformance/interfaces/sem_close/3-1: execution: INTERRUPTED: Output: + unexpected error: sem_close 3-1: sem_open: Operation not supported + conformance/interfaces/sem_close/3-2: execution: UNRESOLVED: Output: + [08:56:54]Test conformance/interfaces/sem_close/3-2.c unresolved: got 1073741869 (Operation not supported) on line 113 (Failed to create the semaphore) + conformance/interfaces/sem_getvalue/1-1: execution: UNRESOLVED: Output: + unexpected error: sem_getvalue 1-1: sem_open: Operation not supported + conformance/interfaces/sem_getvalue/2-1: execution: UNRESOLVED: Output: + unexpected error: sem_getvalue 2-1: sem_open: Operation not supported + conformance/interfaces/sem_getvalue/4-1: execution: UNRESOLVED: Output: + unexpected error: sem_getvalue 4-1: sem_open: Operation not supported + conformance/interfaces/sem_getvalue/5-1: execution: UNRESOLVED: Output: + unexpected error: sem_getvalue 5-1: sem_open: Operation not supported + conformance/interfaces/sem_init/3-2: execution: UNRESOLVED: Output: + [08:56:59]Test conformance/interfaces/sem_init/3-2.c unresolved: got 1073741869 (Operation not supported) on line 135 (Failed to init the semaphore) + conformance/interfaces/sem_init/3-3: execution: UNRESOLVED: Output: + [08:57:00]Test conformance/interfaces/sem_init/3-3.c unresolved: got 1073741869 (Operation not supported) on line 134 (Failed to init the semaphore) + conformance/interfaces/sem_init/7-1: execution: UNTESTED: Output: + [08:57:01]sysconf( _SC_SEM_NSEMS_MAX ) = -1 + [08:57:01]File conformance/interfaces/sem_init/7-1.c cannot test: There is no constraint on SEM_NSEMS_MAX + conformance/interfaces/sem_open/1-1: execution: FAILED: Output: + TEST FAILED + conformance/interfaces/sem_open/1-3: execution: UNRESOLVED: Output: + unexpected error: sem_open 1-3: sem_open: Operation not supported + conformance/interfaces/sem_open/1-4: execution: UNRESOLVED: Output: + unexpected error: sem_open 1-4: sem_open: Operation not supported + conformance/interfaces/sem_open/10-1: execution: UNRESOLVED: Output: + unexpected error: sem_open 10-1: sem_open: Operation not supported + conformance/interfaces/sem_open/15-1: execution: UNRESOLVED: Output: + [08:57:03]Test conformance/interfaces/sem_open/15-1.c unresolved: got 1073741869 (Operation not supported) on line 106 (Failed to sem_open) + conformance/interfaces/sem_open/2-1: execution: UNRESOLVED: Output: + unexpected error: sem_open 2-1: sem_open: Operation not supported + conformance/interfaces/sem_open/2-2: execution: UNRESOLVED: Output: + unexpected error: sem_open 2-2: sem_open: Operation not supported + conformance/interfaces/sem_open/3-1: execution: FAILED: Output: + TEST FAILED + conformance/interfaces/sem_open/4-1: execution: FAILED: Output: + TEST FAILED + conformance/interfaces/sem_open/6-1: execution: FAILED: Output: + TEST FAILED + conformance/interfaces/sem_post/1-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 1-1: sem_open: Operation not supported + conformance/interfaces/sem_post/1-2: execution: UNRESOLVED: Output: + unexpected error: sem_post 1-2: sem_open: Operation not supported + conformance/interfaces/sem_post/2-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 2-1: sem_open: Operation not supported + conformance/interfaces/sem_post/4-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 4-1: sem_open: Operation not supported + conformance/interfaces/sem_post/5-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 5-1: sem_open: Operation not supported + conformance/interfaces/sem_post/6-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 6-1: sem_open: Operation not supported + conformance/interfaces/sem_post/8-1: execution: UNTESTED: Output: + _POSIX_PRIORITY_SCHEDULING not defined + conformance/interfaces/sem_timedwait/9-1: execution: FAILED: Output: + In handler + TEST FAILED: errno != EINTR + conformance/interfaces/sem_unlink/1-1: execution: INTERRUPTED: Output: + unexpected error: sem_unlink 1-1: sem_open: Operation not supported + conformance/interfaces/sem_unlink/2-1: execution: INTERRUPTED: Output: + unexpected error: sem_unlink 2-1: sem_open: Operation not supported + conformance/interfaces/sem_unlink/2-2: execution: UNRESOLVED: Output: + [08:57:23]Test conformance/interfaces/sem_unlink/2-2.c unresolved: got 1073741869 (Operation not supported) on line 158 (Failed to create the semaphore) + conformance/interfaces/sem_unlink/3-1: execution: UNRESOLVED: Output: + [08:57:23]Test conformance/interfaces/sem_unlink/3-1.c unresolved: got 1073741869 (Operation not supported) on line 156 (Failed to create the semaphore) + conformance/interfaces/sem_unlink/4-1: execution: FAILED: Output: + TEST FAILED: semaphore does exist + conformance/interfaces/sem_unlink/4-2: execution: FAILED: Output: + [08:57:24]Error 1073741869: Operation not supported + [08:57:24]Test conformance/interfaces/sem_unlink/4-2.c FAILED: The error was not ENOENT + conformance/interfaces/sem_unlink/6-1: execution: UNRESOLVED: Output: + [08:57:25]Test conformance/interfaces/sem_unlink/6-1.c unresolved: got 1073741869 (Operation not supported) on line 107 (Failed to create the semaphore) + conformance/interfaces/sem_unlink/7-1: execution: UNRESOLVED: Output: + [08:57:25]Test conformance/interfaces/sem_unlink/7-1.c unresolved: got 1073741869 (Operation not supported) on line 126 (Failed to create the semaphore) + conformance/interfaces/sem_unlink/9-1: execution: UNRESOLVED: Output: + [08:57:25]Test conformance/interfaces/sem_unlink/9-1.c unresolved: got 1073741869 (Operation not supported) on line 133 (Failed to create the semaphore) + conformance/interfaces/sem_wait/1-1: execution: UNRESOLVED: Output: + unexpected error: sem_wait 1-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/1-2: execution: UNRESOLVED: Output: + unexpected error: sem_wait 2-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/11-1: execution: UNRESOLVED: Output: + unexpected error: sem_trywait 11-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/12-1: execution: INTERRUPTED: Output: + unexpected error: sem_trywait 12-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/3-1: execution: UNRESOLVED: Output: + unexpected error: sem_wait 3-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/5-1: execution: INTERRUPTED: Output: + unexpected errno: sem_trywait 5-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/7-1: execution: UNRESOLVED: Output: + unexpected error: sem_wait 7-1: sem_open: Operation not supported + conformance/interfaces/shm_open/1-1: execution: INTERRUPTED: Output: + conformance/interfaces/shm_open/10-1: execution: UNTESTED: Output: + Will not test whether the file offset is set because it is unspecified. + conformance/interfaces/shm_open/12-1: execution: UNTESTED: Output: + Will not test the behavior of implementation when an application does not + specify exactly one of two values: O_RDONLY and O_RDWR. + conformance/interfaces/shm_open/14-2: execution: INTERRUPTED: Output: + conformance/interfaces/shm_open/19-1: execution: UNTESTED: Output: + Will not test the effect of calling shm_open() when the shared memory object + does not exists, the O_CREAT flags is set, and bits in mode other than the + file permission bits are set. It is unspecified. + conformance/interfaces/shm_open/2-1: execution: UNTESTED: Output: + Will not test that the shm_open() function create an open file description + that refers to the shared memory object and a file descriptor that refers to + conformance/interfaces/shm_open/23-1: execution: UNRESOLVED: Output: + error at sem_open: Operation not supported + conformance/interfaces/shm_open/24-1: execution: UNTESTED: Output: + Will not test the result of shm_open() when O_EXCL is set and O_CREAT is not + set because it is undefined. + conformance/interfaces/shm_open/26-2: execution: UNRESOLVED: Output: + You don't have permission to change your UID. + Try to rerun this test as root. + conformance/interfaces/shm_open/27-1: execution: UNTESTED: Output: + Will not test the result of shm_open() when using O_TRUNC with O_RDONLY. + It is undefined. + conformance/interfaces/shm_open/28-1: execution: INTERRUPTED: Output: + conformance/interfaces/shm_open/28-3: execution: INTERRUPTED: Output: + conformance/interfaces/shm_open/29-1: execution: UNTESTED: Output: + Will not test whether the name and shared memory object state remain valid + after a system reboot. It is unspecified. + conformance/interfaces/shm_open/3-1: execution: UNTESTED: Output: + Will not test whether the name appears in the file system and is visible to + other functions that take pathnames as arguments because it is unspecified. + conformance/interfaces/shm_open/36-1: execution: UNTESTED: Output: + It is very difficult to test that the shm_open() function sets errno = EINTR + when it is interrupted by a signal. + conformance/interfaces/shm_open/37-1: execution: FAILED: Output: + Name: '[GARBAGE]' + OK: open with success. + Name: '[GARBAGE]' + OK: open with success. + Name: '..' + Unexpected error: Is a directory + Name: '/' + OK: errno == EINVAL + Name: '//' + OK: errno == EINVAL + Name: '/abc' + OK: open with success. + Test FAILED + conformance/interfaces/shm_open/39-2: execution: UNRESOLVED: Output: + An error occurs when calling pathconf(): Invalid argument + conformance/interfaces/shm_open/42-1: execution: UNTESTED: Output: + Will not test that the shm_open() function sets errno to ENOSPC if there is + insufficient space for the creation of the new shared memory object. + conformance/interfaces/shm_open/5-1: execution: FAILED: Output: + Test FAILED + conformance/interfaces/shm_open/6-1: execution: UNTESTED: Output: + Will not test the effect of a name which does not begin with the slash + character because it is implementation-defined. + conformance/interfaces/shm_open/7-1: execution: UNTESTED: Output: + Will not test the interpretation of slash characters other than the leading + slash character in name because it is implementation-defined. + conformance/interfaces/shm_open/9-1: execution: UNTESTED: Output: + Will not test that the open file description is new. + conformance/interfaces/shm_unlink/10-2: execution: UNRESOLVED: Output: + An error occurs when calling pathconf(): Invalid argument + conformance/interfaces/shm_unlink/8-1: execution: UNRESOLVED: Output: + You don't have permission to change your UID. + Try to rerun this test as root. + conformance/interfaces/shm_unlink/9-1: execution: UNRESOLVED: Output: + You don't have permission to change your UID. + Try to rerun this test as root. + conformance/interfaces/sigaction/4-37: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-23: execution: FAILED: Output: + Caught SIGURG + Test FAILED + conformance/interfaces/sigaction/12-41: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-4: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-28: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-26: execution: FAILED: Output: + Caught SIGXFSZ + Test FAILED + conformance/interfaces/sigaction/12-49: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-8: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-45: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-18: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-42: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-15: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-25: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-7: execution: FAILED: Output: + Caught SIGHUP + Test FAILED + conformance/interfaces/sigaction/4-48: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-23: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-34: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-24: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-43: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-22: execution: FAILED: Output: + Caught SIGTRAP + Test FAILED + conformance/interfaces/sigaction/12-31: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-35: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-46: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-7: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-34: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-3: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-52: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/4-30: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/4-51: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-13: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-36: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-21: execution: FAILED: Output: + Caught SIGSYS + Test FAILED + conformance/interfaces/sigaction/17-11: execution: FAILED: Output: + Caught SIGQUIT + Test FAILED + conformance/interfaces/sigaction/4-38: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-47: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-30: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-44: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-50: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-27: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-20: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-40: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-19: execution: FAILED: Output: + Caught SIGPOLL + Test FAILED + conformance/interfaces/sigaction/12-16: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-51: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-21: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-1: execution: FAILED: Output: + Caught SIGABRT + Test FAILED + conformance/interfaces/sigaction/4-32: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-12: execution: FAILED: Output: + Caught SIGSEGV + Test FAILED + conformance/interfaces/sigaction/12-52: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-10: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-36: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-9: execution: FAILED: Output: + Caught SIGINT + Test FAILED + conformance/interfaces/sigaction/4-47: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-11: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-10: execution: FAILED: Output: + Caught SIGPIPE + Test FAILED + conformance/interfaces/sigaction/12-5: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-48: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-19: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-46: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-17: execution: FAILED: Output: + Caught SIGUSR1 + Test FAILED + conformance/interfaces/sigaction/12-14: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-14: execution: FAILED: Output: + Caught SIGTSTP + Test FAILED + conformance/interfaces/sigaction/17-18: execution: FAILED: Output: + Caught SIGUSR2 + Test FAILED + conformance/interfaces/sigaction/4-41: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-43: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-28: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-6: execution: FAILED: Output: + Caught SIGFPE + Test FAILED + conformance/interfaces/sigaction/4-45: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/4-35: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-6: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-29: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-16: execution: FAILED: Output: + Caught SIGTTOU + Test FAILED + conformance/interfaces/sigaction/4-39: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-29: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-9: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-25: execution: FAILED: Output: + Caught SIGXCPU + Test FAILED + conformance/interfaces/sigaction/17-4: execution: FAILED: Output: + Caught SIGCHLD + Test FAILED + conformance/interfaces/sigaction/12-22: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-13: execution: FAILED: Output: + Caught SIGTERM + Test FAILED + conformance/interfaces/sigaction/4-31: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-38: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-12: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-44: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/4-49: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-40: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-42: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-15: execution: FAILED: Output: + Caught SIGTTIN + Test FAILED + conformance/interfaces/sigaction/17-3: execution: FAILED: Output: + Caught SIGBUS + Test FAILED + conformance/interfaces/sigaction/12-2: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-5: execution: FAILED: Output: + Caught SIGCONT + Test FAILED + conformance/interfaces/sigaction/12-33: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-17: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-2: execution: FAILED: Output: + Caught SIGALRM + Test FAILED + conformance/interfaces/sigaction/12-37: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-20: execution: FAILED: Output: + Caught SIGPROF + Test FAILED + conformance/interfaces/sigaction/17-8: execution: FAILED: Output: + Caught SIGILL + Test FAILED + conformance/interfaces/sigaction/4-33: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-39: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-50: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-32: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-27: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-24: execution: FAILED: Output: + Caught SIGVTALRM + Test FAILED + conformance/interfaces/sigaction/12-26: execution: INTERRUPTED: Output: + conformance/interfaces/sigaltstack/1-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigaltstack/11-1: execution: FAILED: Output: + Test FAILED: Expected return value of -1. + conformance/interfaces/sigaltstack/12-1: execution: FAILED: Output: + Test FAILED: Expected return value of -1. + conformance/interfaces/sigaltstack/2-1: execution: FAILED: Output: + Test FAILED: ss_sp of the handler's stack changed even though SS_DISABLE was set + conformance/interfaces/sigaltstack/3-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigaltstack/6-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigaltstack/7-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigpause/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigpending/1-2: execution: INTERRUPTED: Output: + Not all pending signals found + conformance/interfaces/sigpending/1-3: execution: INTERRUPTED: Output: + Error with send signals + Test FAILED + conformance/interfaces/sigqueue/10-1: execution: FAILED: Output: + sigqueue() failed on EINVAL but errno not set correctly + conformance/interfaces/sigqueue/11-1: execution: FAILED: Output: + sigqueue() failed on ESRCH but errno not set correctly + conformance/interfaces/sigqueue/12-1: execution: FAILED: Output: + sigqueue() failed but errno not set correctly + conformance/interfaces/sigqueue/2-1: execution: FAILED: Output: + Could not call sigqueue with sig = 0 + conformance/interfaces/sigqueue/2-2: execution: FAILED: Output: + sigqueue() failed on ESRCH but errno not set correctly + At least one test FAILED -- see output for status + conformance/interfaces/sigqueue/3-1: execution: FAILED: Output: + Test FAILED: EPERM error not received + conformance/interfaces/sigset/6-1: execution: UNRESOLVED: Output: + Unexpected error while using sigset(): (os/kern) successful + conformance/interfaces/sigset/7-1: execution: UNRESOLVED: Output: + Unexpected error while using sigset(): (os/kern) successful + conformance/interfaces/sigset/8-1: execution: FAILED: Output: + Test FAILED: sigset() didn't return SIG_HOLD + conformance/interfaces/sigsuspend/1-1: execution: UNRESOLVED: Output: + suspending child + SIGUSR2 called. Inside handler + parent sending child a SIGUSR2 signal + parent sending child a SIGUSR1 signal + Exit status from child is 1 + Test UNRESOLVED: Either sigsuspend did not successfully block SIGUSR2, OR sigsuspend returned before handling the signal SIGUSR1 + conformance/interfaces/sigtimedwait/1-1: execution: FAILED: Output: + Test FAILED: sigtimedwait() did not return in the required time + conformance/interfaces/sigtimedwait/4-1: execution: FAILED: Output: + Call to sigtimedwait() failed + : Function not implemented + conformance/interfaces/sigtimedwait/6-1: execution: FAILED: Output: + Test FAILED: sigtimedwait() did set errno to EAGAIN + conformance/interfaces/sigwait/1-1: execution: FAILED: Output: + Signal SIGALRM is not pending! + conformance/interfaces/sigwait/3-1: execution: FAILED: Output: + Test FAILED + conformance/interfaces/sigwait/6-1: execution: FAILED: Output: + [09:04:10]0 threads were awaken + [09:04:10]Test conformance/interfaces/sigwait/6-1.c FAILED: Unexpected number of threads awaken + conformance/interfaces/sigwaitinfo/1-1: execution: UNRESOLVED: Output: + Call to sigwaitinfo() failed + : Function not implemented + conformance/interfaces/sigwaitinfo/3-1: execution: FAILED: Output: + Call to sigwaitinfo() failed + : Function not implemented + Child calling sigwaitinfo() + parent sending child a SIGUSR1 signal + Exit status from child is 2 + Test FAILED + conformance/interfaces/sigwaitinfo/9-1: execution: FAILED: Output: + Call to sigwaitinfo() failed + : Function not implemented + conformance/interfaces/strftime/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/timer_create/1-1: execution: FAILED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/10-1: execution: UNRESOLVED: Output: + sysconf(_SC_CPUTIME) returns: -1 + conformance/interfaces/timer_create/11-1: execution: UNSUPPORTED: Output: + rc = -1 + _POSIX_THREAD_CPUTIME unsupported + conformance/interfaces/timer_create/16-1: execution: FAILED: Output: + errno != EINVAL + Test FAILED + conformance/interfaces/timer_create/3-1: execution: FAILED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/7-1: execution: UNSUPPORTED: Output: + CLOCK_MONOTONIC unsupported + conformance/interfaces/timer_create/8-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/9-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/speculative/2-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/speculative/5-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_delete/1-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_delete/1-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_delete/speculative/5-1: execution: FAILED: Output: + timer_delete() returned -1, but didn't set errno!=EINVAL + conformance/interfaces/timer_delete/speculative/5-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/1-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/2-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/2-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/2-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/3-1: execution: UNTESTED: Output: + Cannot be tested as DELAYTIMER_MAX is too large. + DELAYTIMER_MAX is ffffffff + conformance/interfaces/timer_getoverrun/speculative/6-1: execution: FAILED: Output: + fcn returned -1, but errno!=EINVAL + Test FAILED + conformance/interfaces/timer_getoverrun/speculative/6-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/speculative/6-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/1-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/1-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/1-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/1-4: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/2-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/2-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/3-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/speculative/6-1: execution: FAILED: Output: + fcn returned -1 but errno!=EINVAL + Test FAILED + conformance/interfaces/timer_gettime/speculative/6-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/speculative/6-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/1-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/1-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/13-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/2-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/3-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/3-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/3-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/5-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/5-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/5-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/6-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/8-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/8-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/8-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/8-4: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/9-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/9-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/speculative/12-1: execution: FAILED: Output: + fcn returned -1, but errno!=EINVAL + Test FAILED + conformance/interfaces/timer_settime/speculative/12-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/speculative/12-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + functional/threads/schedule/1-1: execution: UNRESOLVED: Output: + unexpected error: scheduler 5-4: pthread_attr_setschedpolicy + functional/threads/schedule/1-2: execution: UNRESOLVED: Output: + unexpected error: scheduler 5-5: pthread_setschedparam diff --git a/open_issues/open_symlink.mdwn b/open_issues/open_symlink.mdwn new file mode 100644 index 00000000..20e4a4fe --- /dev/null +++ b/open_issues/open_symlink.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +# IRC, freenode, #hurd, 2012-01-02 + + <pinotree> hm, is it a known issue that open("somesymlink", O_RDONLY | + O_NOFOLLOW) does not fail with ELOOP? + <youpi> pinotree: iirc there is code for it, maybe not the same behavior as + on linux diff --git a/open_issues/osf_mach.mdwn b/open_issues/osf_mach.mdwn new file mode 100644 index 00000000..d689bfcb --- /dev/null +++ b/open_issues/osf_mach.mdwn @@ -0,0 +1,237 @@ +[[!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_gnumach open_issue_hurd]] + +IRC, freenode, #hurd, 2011-09-07 + + <slpz> tschwinge: do you think that should be possible/convenient to + maintain hurd and glibc versions for OSF Mach as branches in the offical + git repo? + <tschwinge> Is OSF Mach the MkLinux one? + <slpz> Yes, it is + <tschwinge> slpz: If there's a suitable license, then yes, of course! + <tschwinge> Unless there is a proper upstream, of course. + <tschwinge> But I don't assume there is? + <tschwinge> slpz: What is interesting for us about OSF Mach? + <slpz> tschwinge: Peter Bruin and Jose Marchesi did a gnuified version some + time ago (gnu-osfmach), so I suppose the license is not a problem. But + I'm going to check it, though + <slpz> OSF Mach has a number of interesting features + <slpz> like migrating threads, advisory pageout, clustered pageout, kernel + loaded tasks, short circuited RPC... + <tschwinge> Oh! + <tschwinge> Good. + <slpz> right now I'm testing if it's really worth the effort + <tschwinge> Yes. + <tschwinge> But if the core codebase is the same (is it?) it may be + possible to merge some things? + <tschwinge> If the changes can be identified reasonably... + <slpz> comparing performance of the specialized RPC of OSF Mach with + generic IPC + <slpz> That was my first intention, but I think that porting all those + features will be much more work than porting Hurd/glibc to it + <braunr> slpz: ipc performance currently matters less than clustered + pageouts + <braunr> slpz: i'm really not sure .. + <braunr> i'd personnally adapt the kernel + <slpz> braunr: well, clustered pageouts is one of the changes that can be + easily ported + <slpz> braunr: We can consider OSF Mach code as reasonably stable, and + porting its features to GNU Mach will take us to the point of having to + debug all that code again + <slpz> probably, the hardest feature to be ported is migrating threads + <braunr> isn't that what was tried for gnu mach 2 ? or was it only about + oskit ? + <slpz> IIRC only oskit + <tschwinge> slpz: But there have been some advancements in GNU Mach, too. + For example the Xen port. + <tschwinge> But wen can experiment with it, of course. + <slpz> tschwinge: I find easier to move the Xen support from GNU Mach to + OSF Mach, than porting MT in the other direction + <tschwinge> slpz: And I think MkLinux is a single-server, so I don't this + they used IPC as much as we did? + <tschwinge> slpz: OK, I see. + <braunr> slpz: MT aren't as needed as clustered pageouts :p + <braunr> gnumach already has ipc handoff, so MT would just consume less + stack space, and only slightly improve raw ipc performance + <tschwinge> slpz: But we will surely accept patches that get the Hurd/glibc + ported to OSF Mach, no question. + <braunr> (it's required for other issues we discussed already, but not a + priority imo) + <slpz> tschwinge: MkLinux makes heavy use of IPC, but it tries to + "short-circuit" it when running as a kernel loaded task + <tschwinge> And it's obviously best to keep it in one place. Luckily it's + not CVS branches anymore... :-) + <slpz> braunr: well, I'm a bit obsessed with IPC peformance, if the RPC on + OSF Mach really makes a difference, I want it for Hurd right now + <slpz> braunr: clustered pages can be implemented at any time :-) + <slpz> tschwinge: great! + <tschwinge> slpz: In fact, haven'T there already been some Savannah + repositories created, several (five?) years ago? + <braunr> slpz: the biggest performance issue on the hurd is I/O + <braunr> and the easiest way to improve that is better VM transfers + <slpz> tschwinge: yes, the HARD project, but I think it wasn't too well + received... + <tschwinge> slpz: Quite some things changed since then, I'd say. + <slpz> braunr: I agree, but IPC is the hardest part to optimize + <slpz> braunr: If we have a fast IPC, the rest of improvements are way + easier + <braunr> slpz: i don't see how faster IPC makes I/O faster :( + <braunr> slpz: read + http://www.sceen.net/~rbraun/the_increasing_irrelevance_of_ipc_performance_for_microkernel_based_operating_systems.pdf + again :) + <slpz> braunr: IPC puts the upper limit of how fast I/O could be + <braunr> the abstract for my thesis on x15 mach was that the ipc code was + the most focused part of the kernel + <braunr> so my approach was to optimize everything *else* + <braunr> the improvements in UVM (and most notably clustered page + transfers) show global system improvements up to 30% in netbsd + <braunr> we should really focus on the VM first (which btw, is a pain in + the ass with the crappy panicking swap code in place) + <braunr> and then complete the I/O system + <slpz> braunr: If a system can't transfer data between translators faster + than 100 MB/s, faster devices doesn't make much sense + <guillem> has anyone considered switching the syscalls to use + sysenter/syscall instead of soft interrupts? + <slpz> braunr: but I agree on the VM part + <braunr> guillem: it's in my thesis .. but only there :) + <braunr> slpz: let's reach 100 MiB/s first, then improve IPC + <slpz> guillem: that's a must do, also moving to 64 bits :-) + <braunr> guillem: there are many tiny observations in it, like the use of + global page table entries, which was added by youpi around that time + <guillem> slpz: I wanted to fix all warnings first before sending my first + batch of 64 bit fixes, but I think I'll just send them after checking + they don't introduce regressions on i386 + <guillem> braunr: interesting I think I might have skimmed over your + thesis, maybe I should read it properly some time :) + <slpz> braunr: I see exactly as the opposite. First push IPC to its limit, + then improve devices/VM + <slpz> guillem: that's great :-) + <braunr> slpz: improving ipc now will bring *nothing*, whereas improving + vm/io now will make the system considerably more useable + <guillem> but then fixing 64-bit issues in the Linux code is pretty + annoying given that the latest code from upstream has that already fixed, + and we are “supposed” to drop the linux code from gnumach at some point + :) + <braunr> slpz: that's a basic principle in profiling, improve what brings + the best gains + <slpz> braunr: I'm not thinking about today, I'm thinking about how fast + Hurd could be when running on Mach. And, as I said, IPC is the absolute + upper limit. + <braunr> i'm really not convinced + <braunr> there are that many tasks making extensive use of IPCs + <braunr> most are cpu/IO bound + <slpz> but I have to acknowledge that this concern has been really + aliviated by the EPT improvement discovery + <braunr> there aren't* that many tasks + <slpz> braunr: create a ramdisk an write some files on it + <slpz> braunr: there's no I/O in that case, an performance it's really low + too + <braunr> well, ramdisks don't even work correctly iirc + <slpz> I must say that I consider improvements in OOL data moving as if it + were in IPC itself + <slpz> braunr: you can simulate one with storeio + <braunr> slpz: then measure what's slow + <braunr> slpz: it couldn't simply be the vm layer + <slpz> braunr: + http://www.gnu.org/s/hurd/hurd/libstore/examples/ramdisk.html + <braunr> ok, it's not a true ramdisk + <braunr> it's a stack of a ramdisk and extfs servers + <braunr> ext2fs* + <braunr> i was thinking about tmpfs + <slpz> True, but one of Hurd main advantages is the ability of doing that + kind of things + <slpz> so they must work with a reasonable performance + <braunr> other systems can too .. + <braunr> anyway + <braunr> i get your point, you want faster IPCs, like everyone does + <slpz> braunr: yes, and I also want to know how fast could be, to have a + reference when profiling complex services + <antrik> slpz: really improving IPC performance probably requires changing + the semantics... but we don't know which semantics we want until we have + actually tried fixing the existing bottlenecks + <antrik> well, not only bottlenecks... also other issues such as resource + management + <slpz> antrik: I think fixing bottlenecks would probably require changes in + some Mach interfaces, not in the IPC subsystem + <slpz> antrik: I mean, IPC semantics just provide the basis for messaging, + I don't think we will need to change them further + <antrik> slpz: right, but only once we have addressed the bottlenecks (and + other major shortcomings), we will know how the IPC mechanisms needs to + change to get further improvements... + <antrik> of course improving Mach IPC performance is interesting too -- if + nothing else, then to see how much of a difference it really makes... I + just don't think it should be considered an overriding priority :-) + <youpi> slpz: I agree with braunr, I don't think improving IPC will bring + much on the short term + <youpi> the buildds are slow mostly because of bad VM + <youpi> like lack of read-ahead, the randomness of object cache pageout, + etc. + <youpi> that doesn't mean IPC shouldn't be improved of course + <youpi> but we have a big margin for iow + <youpi> s/iow/now + <slpz> youpi: I agree with you and with braunr in that regard. I'm not + looking for an inmediate improvement, I just want to see how fast the IPC + (specially, OOL data transfers) could be. + <slpz> also, migrating threads will help to fix some problems related with + resource management + <antrik> slpz: BTW, what about Apple's Mach? isn't it essentialy OSF Mach + with some further improvements?... + <slpz> antrik: IPC is an area with very little room for improvement, so I + don't we will fix that bottlenecks by applying some changes there + <antrik> well, for large OOL transfers, the limiting facter is certainly + also VM rather than the thread model?... + <slpz> antrik: yes, but I think is encumbered with the APPLv2 license + <antrik> ugh + <slpz> antrik: for OOL transfers, VM plays a big role, but IPC also has + great deal of responsibility + <antrik> as for resource management, migrating threads do not really help + much IMHO, as they only affect CPU scheduling. memory usage is a much + more pressing issue + <antrik> BTW, I have thought about passive objects in the past, but didn't + reach any conclusion... so I'm a bit ambivalent about migrating threads + :-) + <slpz> As an example, in Hurd on GNU Mach, an io_read can't take advantage + from copy-on-write, as buffers from the translator always arrive outside + user's buffer + <slpz> antrik: well, I think cpu scheduling is a big deal ;-) + <slpz> antrik: and for memory management, until a better design is + implemented, some fixes could be applied to get us to the same level as a + monolithic kernel + <antrik> to get even close to monolithic systems, we need either a way to + account server resources used on client's behalf, or to make servers use + client-provided resources. both require changes in the IPC mechanism I + think... + <antrik> (though *if* we go for the latter option, the CPU scheduling + changes of migrating threads would of course be necessary, in addition to + any changes regarding memory management...) + <antrik> slpz: BTW, I didn't get the point about io_read and COW... + <slpz> antrik: AFAIK, the FS cache (which is our primary concern) in most + monolithic system is agnostic with respect the users, and only deals with + absolute numbers. In our case we can do almost the same by combining Mach + and pagers knowledege. + <antrik> slpz: my primary concern is that anything program having a hiccup + crashes the system... and I'm not sure this can be properly fixed without + working memory accounting + <antrik> (I guess in can be worked around to some extent by introducing + various static limits on processes... but I'm not sure how well) + <antrik> it can + <slpz> antrik: monolithic system also suffer that problem (remember fork + bombs) and it's "solved" by imposing static limits to user processes + (ulimit). + <slpz> antrik: we do have more problems due to port management, but I think + some degree of control can be archieved with a reasonably amount of + changes. + <antrik> slpz: in a client-server architecture static limits are much less + effective... that problem exists on traditional systems too, but only in + some specific cases (such as X server); while on a microkernel system + it's ubiquitous... that's why we need a *better* solution to this problem + to get anywhere close to monolithic systems diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn new file mode 100644 index 00000000..d243aaaa --- /dev/null +++ b/open_issues/packaging_libpthread.mdwn @@ -0,0 +1,139 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_libpthread open_issue_glibc]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2010-07-31 + + <tschwinge> My idea was to have a separate libpthread package. What do you + think about that? + <youpi> in the long term, that can't work with glibc + <youpi> because of the thread stub stuff + +[[libpthread_dlopen]], for example. + + <youpi> it's not really possible to keep synchronized + <youpi> because you have to decide which package you unpack first + <youpi> (when upgrading) + <tschwinge> Hmm, how is that different if two shared libraries are in one + package vs. two packages? It isn't atomic either way? Aren't sonames / + versioned library packages solving that? + <tschwinge> ... for incompatible forward changes? + <youpi> that'd be a mess to maintain + <youpi> Drepper doesn't have this constraint and thus adds members of + private fields at will + <tschwinge> OK, but how is it different then if the libpthread is in the + Hurd package? + <youpi> I'm not saying it's better to have libpthread in the Hurd package + <tschwinge> OK. + <youpi> I'm saying it's useless to package it separately when Drepper makes + everything to have us put it along glibc + <tschwinge> Then, to goal is to have it in glibc? + <tschwinge> OK. :-) + <tschwinge> OK, I can accommodate to that. Isn't not that we'd want to + switch libpthread to something else so quickly. + <tschwinge> So our official goal is to have libpthread in glibc, at least + for Debian purposese? + <youpi> for any port purpose + <tschwinge> Ack. + <youpi> provided you're using glibc, you're deemed to ship libpthread with + it + <youpi> because of the strong relations Drepper puts between them + <youpi> (just to remind: we already have bugs just because our current + libpthread isn't bound enough to glibc: dlopen()ing a library depending + on libpthread doesn't work, for instance) + <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread + isn't used + <pinotree> (would be nice to not have those issues anymore...) + <tschwinge> So -- what do we need to put it into glibc? We can make + libpthread a Git submodule (or move the code; but it's shared also for + Neal's viengoos, so perhaps the submodule is better?), plus some glibc + make foo, plus some other adaptions (stubs, etc.) + <tschwinge> Does that sound about right, or am I missing something + fundamental? + <youpi> I actually don't know what a git submodule permits :) + <youpi> looks like a good thing for this, yes + <tschwinge> Unfortunately I can't allocate much time at the moment to work + on this. :-/ + <youpi> well, as long as I know where we're going, I can know how to + package stuff in Debian + <tschwinge> That sounds like a plan to me. libpthread -> glibc as + submodule. + <youpi> (note: actually, the interface between glibc and the libpthread is + the responsibility of the libpthread: it gives a couple of .c files to be + shipped in libc.so) + + +# IRC, freenode, #hurd, 2012-04-21 + + <youpi> had you tried to build libpthread as a glibc addon? + <tschwinge> youpi: No, I only know about libpthread in Hurd build system, + and libpthread stand-alone (with the Auto* stuff that I added), but not + yet as a glibc add-on. + <youpi> k + <youpi> I'm trying it atm + <tschwinge> Oh, OK. + <youpi> that should fix the no-add-needed issue in gcc/binutils, as well as + the pthread_threads assertion errors in threaded plugins + <youpi> (once I add forward.c, but that part should not be hard) + <pinotree> that means also less use of pthread-stubs^ + <pinotree> ? + <youpi> tschwinge: do you remember whether sysdeps/mach/bits/spin* are used + by anybody? + <youpi> they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and + come in the way when building in glibc + <youpi> also, any reason for using ia32 and not i386? glibc uses the latter + <youpi> pinotree: rid of pthread-stubs yes + <pinotree> \o/ + <tschwinge> youpi: You mean sysdeps/mach/i386/machine-lock.h? No idea + about that one, sorry. + <youpi> I'm talking about libpthread + <youpi> not glibc + <tschwinge> Oh. + <tschwinge> sysdeps/ia32/bits/spin-lock.h:# define + __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0) + <tschwinge> Anyway, no idea about that either. + <youpi> that one is meant to be used with the spin-lock.h just below + <youpi> +-inline + <youpi> also, I guess signal/ was for the l4 port? + <tschwinge> youpi: I guess so. + <youpi> tschwinge: I have an issue with sysdeps pt files: + sysdeps/hurd/pt-getspecific.c is not looked for by libc ; symlinking into + sysdeps/mach/hurd/pt-getspecific.c works + <youpi> we don't have a non-mach sysdeps directory? + <pinotree> youpi: if you add sysdeps/mach/hurd/Implies containing only + "hurd", does sysdeps/hurd work? + <youpi> ah, right + <pinotree> youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or + in libpthread/sysdeps/mach/hurd?) + <youpi> pinotree: it worked, it was for libpthread + <youpi> good: I got libpthread built and forward working + + +## IRC, freenode, #hurd, 2012-04-23 + + <youpi> phew + <youpi> confirmed that moving libpthread to glibc fixes the gcc/binutils + no-add-needed issue + + +## IRC, freenode, #hurd, 2012-04-27 + + <pinotree> youpi: wouldn't be the case to rename ia32 subdirs to i386 in + libpthread? + <pinotree> after all, Makefile hardcodes it, Makefile.am sets the variable + for it, and glibc expects i386 + <youpi> I know, I've asked tschwinge about it + <youpi> it's not urging anyway + <pinotree> right diff --git a/open_issues/page_cache.mdwn b/open_issues/page_cache.mdwn new file mode 100644 index 00000000..fd503fdc --- /dev/null +++ b/open_issues/page_cache.mdwn @@ -0,0 +1,79 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-11-28 + + <braunr> youpi: would you find it reasonable to completely disable the page + cache in gnumach ? + <braunr> i'm wondering if it wouldn't help make the system more stable + under memory pressure + <youpi> assuming cache=writeback in gnumach? + <youpi> because disabling the page cache will horribly hit performance + <braunr> no, it doesn't have anything to do with the host + <braunr> i'm not so sure + <braunr> while observing the slab allocator, i noticed our page cache is + not used that often + <youpi> eeh? + <youpi> apart from the damn 4000 limitation, I've seen it used + <youpi> (and I don't why it wouldn't be used) + <youpi> (e.g. for all parts of libc) + <youpi> ah, no, libc would be kept open by ext2fs + <braunr> taht's precisely because of the 4k limit + <youpi> but e.g. .o file emitted during make + <braunr> well, no + <youpi> well, see the summary I had posted some time ago, the 4k limit + makes it completely randomized + <youpi> and thus you lose locality + <braunr> yes + <youpi> but dropping the limit would just fix it + <braunr> that's my point + <youpi> which I had tried to do, and there were issues, you mentioned why + <youpi> and (as usual), I haven't had anyu time to have a look at the issue + again + <braunr> i'm just trying to figure out the pros and cons for having teh + current page cache implementation + <braunr> but are you saying you tried with a strict limit of 0 ? + <youpi> non, I'm saying I tried with no limit + <youpi> but then memory fills up + <braunr> yes + <youpi> so trying to garbage collect + <braunr> i tried that too, the system became unstable very quickly + <youpi> but refs don't falldown to 0, you said + <braunr> did i ? + <youpi> or maybe somebody else + <youpi> see the list archives + <braunr> that's possible + <braunr> i'd imagine someone like sergio lopez + <youpi> possibly + <youpi> somebody that knows memory stuff way better than me in any case + <braunr> youpi: i'm just wondering how much we'd loose by disabling the + page cache, and if we actually gain more stability (and ofc, if it's + worth it) + <youpi> no idea, measures will tell + <youpi> fixing the page cache shouldn't be too hard I believe, however + <youpi> you just need to know what you are doing, which I don't + <youpi> I do believe the cache is still at least a bit useful + <youpi> even if dumb because of randomness + <youpi> e.g. running make lib in the glibc tree gets faster on second time + <youpi> because the cache wouldbe filled at least randomly with glibc tree + stuff + <braunr> yes, i agree on that + <youpi> braunr: btw, the current stability is fine for the buildds + <youpi> restarting them every few days is ok + <youpi> so I'd rather keep the performance :) + <braunr> ok + + +# [[gnumach_page_cache_policy]] diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn new file mode 100644 index 00000000..8dbe1160 --- /dev/null +++ b/open_issues/performance.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]]."]]"""]] + +*Performance analysis* ([[!wikipedia Performance_analysis desc="Wikipedia +article"]]) deals with analyzing how computing resources are used for +completing a specified task. + +[[Profiling]] is one relevant tool. + +In [[microkernel]]-based systems, there is generally a considerable [[RPC]] +overhead. + +In a multi-server system, it is non-trivial to implement a high-performance +[[I/O System|community/gsoc/project_ideas/disk_io_performance]]. + +When providing [[faq/POSIX_compatibility]] (and similar interfaces) in an +environemnt that doesn't natively implement these interfaces, there may be a +severe performance degradation. For example, in this [[`fork` system +call|/glibc/fork]]'s case. + +[[Unit_testing]] can be used for tracking performance regressions. + +--- + + * [[Degradation]] + + * [[fork]] + + * [[IPC_virtual_copy]] + + * [[microbenchmarks]] + + * [[microkernel_multi-server]] + + * [[gnumach_page_cache_policy]] + + * [[metadata_caching]] + +--- + + +# IRC, freenode, #hurd, 2012-07-05 + + <braunr> the more i study the code, the more i think a lot of time is + wasted on cpu, unlike the common belief of the lack of performance being + only due to I/O diff --git a/open_issues/performance/degradation.mdwn b/open_issues/performance/degradation.mdwn new file mode 100644 index 00000000..1aaae4d2 --- /dev/null +++ b/open_issues/performance/degradation.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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="Degradation of GNU/Hurd ``system performance''"]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +[[!toc]] + + +# Email, [[!message-id "87mxg2ahh8.fsf@kepler.schwinge.homeip.net"]] (bug-hurd, 2011-07-25, Thomas Schwinge) + +> Building a certain GCC configuration on a freshly booted system: 11 h. +> Remove build tree, build it again (2nd): 12 h 50 min. Huh. Remove build +> tree, reboot, build it again (1st): back to 11 h. Remove build tree, build +> it again (2nd): 12 h 40 min. Remove build tree, build it again (3rd): 15 h. + +IRC, freenode, #hurd, 2011-07-23: + + < antrik> tschwinge: yes, the system definitely gets slower with + time. after running for a couple of weeks, it needs at least twice as + long to open a new shell for example + < antrik> I don't know whether this is only related to swap usage, or there + are some serious fragmentation issues + < braunr> antrik: both could be induced by fragmentation + + +# During [[IPC_virtual_copy]] testing + +IRC, freenode, #hurd, 2011-09-02: + + <manuel> interestingly, running it several times has made the performance + drop quite much (i'm getting 400-500MB/s with 1M now, compared to nearly + 800 fifteen minutes ago) + <braunr> manuel: i observed the same behaviour + [...] + + +# IRC, freenode, #hurd, 2011-09-22 + +See [[/open_issues/resource_management_problems/pagers]], IRC, freenode, #hurd, +2011-09-22. + + +# [[ext2fs_page_cache_swapping_leak]] diff --git a/open_issues/performance/fork.mdwn b/open_issues/performance/fork.mdwn new file mode 100644 index 00000000..5ceb6455 --- /dev/null +++ b/open_issues/performance/fork.mdwn @@ -0,0 +1,37 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_hurd]] + +Our [[`fork` implementation|glibc/fork]] is nontrivial. + +To do: hard numbers. +[[Microbenchmarks]]? + + +# Windows / Cygwin + + * <http://www.google.com/search?q=cygwin+fork> + + * <http://www.redhat.com/support/wpapers/cygnus/cygnus_cygwin/architecture.html> + + In particular, *5.6. Process Creation*. + + * <http://archive.gamedev.net/community/forums/topic.asp?topic_id=360290> + + * <http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/how-cygheap-works.txt?cvsroot=src> + + > Cygwin has recently adopted something called the "cygwin heap". This is + > an internal heap that is inherited by forked/execed children. It + > consists of process specific information that should be inherited. So + > things like the file descriptor table, the current working directory, and + > the chroot value live there. + + * <http://www.perlmonks.org/?node_id=588994> diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn new file mode 100644 index 00000000..931fd0ee --- /dev/null +++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn @@ -0,0 +1,39 @@ +[[!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 +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]] + +This one may be considered as a testcase for [[I/O system +optimization|community/gsoc/project_ideas/disk_io_performance]]. + +It is taken from the [[binutils testsuite|binutils]], +`ld/ld-elf/sec64k.exp`, where this +test may occasionally [[trigger a timeout|binutils#64ksec]]. It is +extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24. + + $ wget -O - http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz | xz -d | tar -x + $ cd test/ + $ \time ./ld-new.stripped -o dump dump?.o dump??.o + 0.00user 0.00system 2:46.11elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + +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. + +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 +`io_read` is being processed. Running the testee on GNU/Linux with strace +shows the equivalent thing (`_llseek`, `read`) -- but Linux' I/O system isn't +as slow as the Hurd's. + +As Samuel figured out later, this slowness may in fact be due to a Xen-specific +issue, see [[Xen_lseek]]. After the latter has been addressed, we can +re-evaluate this issue here. diff --git a/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz b/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz Binary files differnew file mode 100644 index 00000000..6d7c606c --- /dev/null +++ b/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz diff --git a/open_issues/performance/io_system/clustered_page_faults.mdwn b/open_issues/performance/io_system/clustered_page_faults.mdwn new file mode 100644 index 00000000..a3baf30d --- /dev/null +++ b/open_issues/performance/io_system/clustered_page_faults.mdwn @@ -0,0 +1,162 @@ +[[!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_hurd]] + +[[community/gsoc/project_ideas/disk_io_performance]]. + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-02-16 + + <braunr> exceptfor the kernel, everything in an address space is + represented with a VM object + <braunr> those objects can represent anonymous memory (from malloc() or + because of a copy-on-write) + <braunr> or files + <braunr> on classic Unix systems, these are files + <braunr> on the Hurd, these are memory objects, backed by external pagers + (like ext2fs) + <braunr> so when you read a file + <braunr> the kernel maps it from ext2fs in your address space + <braunr> and when you access the memory, a fault occurs + <braunr> the kernel determines it's a region backed by ext2fs + <braunr> so it asks ext2fs to provide the data + <braunr> when the fault is resolved, your process goes on + <etenil> does the faul occur because Mach doesn't know how to access the + memory? + <braunr> it occurs because Mach intentionnaly didn't back the region with + physical memory + <braunr> the MMU is programmed not to know what is present in the memory + region + <braunr> or because it's read only + <braunr> (which is the case for COW faults) + <etenil> so that means this bit of memory is a buffer that ext2fs loads the + file into and then it is remapped to the application that asked for it + <braunr> more or less, yes + <braunr> ideally, it's directly written into the right pages + <braunr> there is no intermediate buffer + <etenil> I see + <etenil> and as you told me before, currently the page faults are handled + one at a time + <etenil> which wastes a lot of time + <braunr> a certain amount of time + <etenil> enough to bother the user :) + <etenil> I've seen pages have a fixed size + <braunr> yes + <braunr> use the PAGE_SIZE macro + <etenil> and when allocating memory, the size that's asked for is rounded + up to the page size + <etenil> so if I have this correctly, it means that a file ext2fs provides + could be split into a lot of pages + <braunr> yes + <braunr> once in memory, it is managed by the page cache + <braunr> so that pages more actively used are kept longer than others + <braunr> in order to minimize I/O + <etenil> ok + <braunr> so a better page cache code would also improve overall performance + <braunr> and more RAM would help a lot, since we are strongly limited by + the 768 MiB limit + <braunr> which reduces the page cache size a lot + <etenil> but the problem is that reading a whole file in means trigerring + many page faults just for one file + <braunr> if you want to stick to the page clustering thing, yes + <braunr> you want less page faults, so that there are less IPC between the + kernel and the pager + <etenil> so either I make pages bigger + <etenil> or I modify Mach so it can check up on a range of pages for faults + before actually processing + <braunr> you *don't* change the page size + <etenil> ah + <etenil> that's hardware isn't it? + <braunr> in Mach, yes + <etenil> ok + <braunr> and usually, you want the page size to be the CPU page size + <etenil> I see + <braunr> current CPU can support multiple page sizes, but it becomes quite + hard to correctly handle + <braunr> and bigger page sizes mean more fragmentation, so it only suits + machines with large amounts of RAM, which isn't the case for us + <etenil> ok + <etenil> so I'll try the second approach then + <braunr> that's what i'd recommand + <braunr> recommend* + <etenil> ok + + +# IRC, freenode, #hurd, 2011-02-16 + + <antrik> etenil: OSF Mach does have clustered paging BTW; so that's one + place to start looking... + <antrik> (KAM ported the OSF code to gnumach IIRC) + <antrik> there is also an existing patch for clustered paging in libpager, + which needs some adaptation + <antrik> the biggest part of the task is probably modifying the Hurd + servers to use the new interface + <antrik> but as I said, KAM's code should be available through google, and + can serve as a starting point + +<http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html> + + +# IRC, freenode, #hurd, 2011-07-22 + + <braunr> but concerning clustered pagins/outs, i'm not sure it's a mach + interface limitation + <braunr> the external memory pager interface does allow multiple pages to + be transfered + <braunr> isn't it an internal Mach VM problem ? + <braunr> isn't it simply the page fault handler ? + <antrik> braunr: are you sure? I was under the impression that changing the + pager interface was among the requirements... + <antrik> hm... I wonder whether for pageins, it could actually be handled + in the pages instead of Mach... though this wouldn't work for pageouts, + so probably not very helpful + <antrik> err... in the pagers + <braunr> antrik: i'm almost sure + <braunr> but i've be proven wrong many times, so .. + <braunr> there are two main facts that lead me to think this + <braunr> 1/ + http://www.gnu.org/software/hurd/gnumach-doc/Memory-Objects-and-Data.html#Memory-Objects-and-Data + says lengths are provided and doesn't mention the limitation + <braunr> 2/ when reading about UVM, one of the major improvements (between + 10 and 30% of global performance depending on the benchmarks) was + implementing the madvise semantics + <braunr> and this didn't involve a new pager interface, but rather a new + page fault handler + <antrik> braunr: hm... the interface indeed looks like it can handle + multiple pages in both directions... perhaps it was at the Hurd level + where the pager interface needs to be modified, not the Mach one?... + <braunr> antrik: would be nice wouldn't it ? :) + <braunr> antrik: more probably the page fault handler + + +# IRC, freenode, #hurd, 2011-09-28 + + <slpz> antrik: I've just recovered part of my old multipage I/O work + <slpz> antrik: I intend to clean and submit it after finishing the changes + to the pageout system. + <antrik> slpz: oh, great! + <antrik> didn't know you worked on multipage I/O + <antrik> slpz: BTW, have you checked whether any of the work done for GSoC + last year is any good?... + <antrik> (apart from missing copyright assignments, which would be a + serious problem for the Hurd parts...) + <slpz> antrik: It was seven years ago, but I did: + http://www.mail-archive.com/bug-hurd@gnu.org/msg10285.html :-) + <slpz> antrik: Sincerely, I don't think the quality of that code is good + enough to be considered... but I think it was my fault as his mentor for + not correcting him soon enough... + <antrik> slpz: I see + <antrik> TBH, I feel guilty myself, for not asking about the situation + immediately when he stopped attending meetings... + <antrik> slpz: oh, you even already looked into vm_pageout_scan() back then + :-) diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn new file mode 100644 index 00000000..710c746b --- /dev/null +++ b/open_issues/performance/io_system/read-ahead.mdwn @@ -0,0 +1,1567 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +[[!toc]] + + +# [[community/gsoc/project_ideas/disk_io_performance]] + + +# [[gnumach_page_cache_policy]] + + +# 2011-02 + +[[Etenil]] has been working in this area. + + +## IRC, freenode, #hurd, 2011-02-13 + + <etenil> youpi: Would libdiskfs/diskfs.h be in the right place to make + readahead functions? + <youpi> etenil: no, it'd rather be at the memory management layer, + i.e. mach, unfortunately + <youpi> because that's where you see the page faults + <etenil> youpi: Linux also provides a readahead() function for higher level + applications. I'll probably have to add the same thing in a place that's + higher level than mach + <youpi> well, that should just be hooked to the same common implementation + <etenil> the man page for readahead() also states that portable + applications should avoid it, but it could be benefic to have it for + portability + <youpi> it's not in posix indeed + + +## IRC, freenode, #hurd, 2011-02-14 + + <etenil> youpi: I've investigated prefetching (readahead) techniques. One + called DiskSeen seems really efficient. I can't tell yet if it's patented + etc. but I'll keep you informed + <youpi> don't bother with complicated techniques, even the most simple ones + will be plenty :) + <etenil> it's not complicated really + <youpi> the matter is more about how to plug it into mach + <etenil> ok + <youpi> then don't bother with potential pattents + <antrik> etenil: please take a look at the work KAM did for last year's + GSoC + <youpi> just use a trivial technique :) + <etenil> ok, i'll just go the easy way then + + <braunr> antrik: what was etenil referring to when talking about + prefetching ? + <braunr> oh, madvise() stuff + <braunr> i could help him with that + + +## IRC, freenode, #hurd, 2011-02-15 + + <etenil> oh, I'm looking into prefetching/readahead to improve I/O + performance + <braunr> etenil: ok + <braunr> etenil: that's actually a VM improvement, like samuel told you + <etenil> yes + <braunr> a true I/O improvement would be I/O scheduling + <braunr> and how to implement it in a hurdish way + <braunr> (or if it makes sense to have it in the kernel) + <etenil> that's what I've been wondering too lately + <braunr> concerning the VM, you should look at madvise() + <etenil> my understanding is that Mach considers devices without really + knowing what they are + <braunr> that's roughly the interface used both at the syscall() and the + kernel levels in BSD, which made it in many other unix systems + <etenil> whereas I/O optimisations are often hard disk drives specific + <braunr> that's true for almost any kernel + <braunr> the device knowledge is at the driver level + <etenil> yes + <braunr> (here, I separate kernels from their drivers ofc) + <etenil> but Mach also contains some drivers, so I'm going through the code + to find the apropriate place for these improvements + <braunr> you shouldn't tough the drivers at all + <braunr> touch + <etenil> true, but I need to understand how it works before fiddling around + <braunr> hm + <braunr> not at all + <braunr> the VM improvement is about pagein clustering + <braunr> you don't need to know how pages are fetched + <braunr> well, not at the device level + <braunr> you need to know about the protocol between the kernel and + external pagers + <etenil> ok + <braunr> you could also implement pageout clustering + <etenil> if I understand you well, you say that what I'd need to do is a + queuing system for the paging in the VM? + <braunr> no + <braunr> i'm saying that, when a page fault occurs, the kernel should + (depending on what was configured through madvise()) transfer pages in + multiple blocks rather than one at a time + <braunr> communication with external pagers is already async, made through + regular ports + <braunr> which already implement message queuing + <braunr> you would just need to make the mapped regions larger + <braunr> and maybe change the interface so that this size is passed + <etenil> mmh + <braunr> (also don't forget that page clustering can include pages *before* + the page which caused the fault, so you may have to pass the start of + that region too) + <etenil> I'm not sure I understand the page fault thing + <etenil> is it like a segmentation error? + <etenil> I can't find a clear definition in Mach's manual + <braunr> ah + <braunr> it's a fundamental operating system concept + <braunr> http://en.wikipedia.org/wiki/Page_fault + <etenil> ah ok + <etenil> I understand now + <etenil> so what's currently happening is that when a page fault occurs, + Mach is transfering pages one at a time and wastes time + <braunr> sometimes, transferring just one page is what you want + <braunr> it depends on the application, which is why there is madvise() + <braunr> our rootfs, on the other hand, would benefit much from such an + improvement + <braunr> in UVM, this optimization is account for around 10% global + performance improvement + <braunr> accounted* + <etenil> not bad + <braunr> well, with an improved page cache, I'm sure I/O would matter less + on systems with more RAM + <braunr> (and another improvement would make mach support more RAM in the + first place !) + <braunr> an I/O scheduler outside the kernel would be a very good project + IMO + <braunr> in e.g. libstore/storeio + <etenil> yes + <braunr> but as i stated in my thesis, a resource scheduler should be as + close to its resource as it can + <braunr> and since mach can host several operating systems, I/O schedulers + should reside near device drivers + <braunr> and since current drivers are in the kernel, it makes sens to have + it in the kernel too + <braunr> so there must be some discussion about this + <etenil> doesn't this mean that we'll have to get some optimizations in + Mach and have the same outside of Mach for translators that access the + hardware directly? + <braunr> etenil: why ? + <etenil> well as you said Mach contains some drivers, but in principle, it + shouldn't, translators should do disk access etc, yes? + <braunr> etenil: ok + <braunr> etenil: so ? + <etenil> well, let's say if one were to introduce SATA support in Hurd, + nothing would stop him/her to do so with a translator rather than in Mach + <braunr> you should avoid the term translator here + <braunr> it's really hurd specific + <braunr> let's just say a user space task would be responsible for that + job, maybe multiple instances of it, yes + <etenil> ok, so in this case, let's say we have some I/O optimization + techniques like readahead and I/O scheduling within Mach, would these + also apply to the user-space task, or would they need to be + reimplemented? + <braunr> if you have user space drivers, there is no point having I/O + scheduling in the kernel + <etenil> but we also have drivers within the kernel + <braunr> what you call readahead, and I call pagein/out clustering, is + really tied to the VM, so it must be in Mach in any case + <braunr> well + <braunr> you either have one or the other + <braunr> currently we have them in the kernel + <braunr> if we switch to DDE, we should have all of them outside + <braunr> that's why such things must be discussed + <etenil> ok so if I follow you, then future I/O device drivers will need to + be implemented for Mach + <braunr> currently, yes + <braunr> but preferrably, someone should continue the work that has been + done on DDe so that drivers are outside the kernel + <etenil> so for the time being, I will try and improve I/O in Mach, and if + drivers ever get out, then some of the I/O optimizations will need to be + moved out of Mach + <braunr> let me remind you one of the things i said + <braunr> i said I/O scheduling should be close to their resource, because + we can host several operating systems + <braunr> now, the Hurd is the only system running on top of Mach + <braunr> so we could just have I/O scheduling outside too + <braunr> then you should consider neighbor hurds + <braunr> which can use different partitions, but on the same device + <braunr> currently, partitions are managed in the kernel, so file systems + (and storeio) can't make good scheduling decisions if it remains that way + <braunr> but that can change too + <braunr> a single storeio representing a whole disk could be shared by + several hurd instances, just as if it were a high level driver + <braunr> then you could implement I/O scheduling in storeio, which would be + an improvement for the current implementation, and reusable for future + work + <etenil> yes, that was my first instinct + <braunr> and you would be mostly free of the kernel internals that make it + a nightmare + <etenil> but youpi said that it would be better to modify Mach instead + <braunr> he mentioned the page clustering thing + <braunr> not I/O scheduling + <braunr> theseare really two different things + <etenil> ok + <braunr> you *can't* implement page clustering outside Mach because Mach + implements virtual memory + <braunr> both policies and mechanisms + <etenil> well, I'd rather think of one thing at a time if that's alright + <etenil> so what I'm busy with right now is setting up clustered page-in + <etenil> which need to be done within Mach + <braunr> keep clustered page-outs in mind too + <braunr> although there are more constraints on those + <etenil> yes + <etenil> I've looked up madvise(). There's a lot of documentation about it + in Linux but I couldn't find references to it in Mach (nor Hurd), does it + exist? + <braunr> well, if it did, you wouldn't be caring about clustered page + transfers, would you ? + <braunr> be careful about linux specific stuff + <etenil> I suppose not + <braunr> you should implement at least posix options, and if there are + more, consider the bsd variants + <braunr> (the Mach VM is the ancestor of all modern BSD VMs) + <etenil> madvise() seems to be posix + <braunr> there are system specific extensions + <braunr> be careful + <braunr> CONFORMING TO POSIX.1b. POSIX.1-2001 describes posix_madvise(3) + with constants POSIX_MADV_NORMAL, etc., with a behav‐ ior close to that + described here. There is a similar posix_fadvise(2) for file access. + <braunr> MADV_REMOVE, MADV_DONTFORK, MADV_DOFORK, MADV_HWPOISON, + MADV_MERGEABLE, and MADV_UNMERGEABLE are Linux- specific. + <etenil> I was about to post these + <etenil> ok, so basically madvise() allows tasks etc. to specify a usage + type for a chunk of memory, then I could apply the relevant I/O + optimization based on this + <braunr> that's it + <etenil> cool, then I don't need to worry about knowing what the I/O is + operating on, I just need to apply the optimizations as advised + <etenil> that's convenient + <etenil> ok I'll start working on this tonight + <etenil> making a basic readahead shouldn't be too hard + <braunr> readahead is a misleading name + <etenil> is pagein better? + <braunr> applies to too many things, doesn't include the case where + previous elements could be prefetched + <braunr> clustered page transfers is what i would use + <braunr> page prefetching maybe + <etenil> ok + <braunr> you should stick to something that's already used in the + literature since you're not inventing something new + <etenil> yes I've read a paper about prefetching + <etenil> ok + <etenil> thanks for your help braunr + <braunr> sure + <braunr> you're welcome + <antrik> braunr: madvise() is really the least important part of the + picture... + <antrik> very few applications actually use it. but pretty much all + applications will profit from clustered paging + <antrik> I would consider madvise() an optional goody, not an integral part + of the implementation + <antrik> etenil: you can find some stuff about KAM's work on + http://www.gnu.org/software/hurd/user/kam.html + <antrik> not much specific though + <etenil> thanks + <antrik> I don't remember exactly, but I guess there is also some + information on the mailing list. check the archives for last summer + <antrik> look for Karim Allah Ahmed + <etenil> antrik: I disagree, madvise gives me a good starting point, even + if eventually the optimisations should run even without it + <antrik> the code he wrote should be available from Google's summer of code + page somewhere... + <braunr> antrik: right, i was mentioning madvise() because the kernel (VM) + interface is pretty similar to the syscall + <braunr> but even a default policy would be nice + <antrik> etenil: I fear that many bits were discussed only on IRC... so + you'd better look through the IRC logs from last April onwards... + <etenil> ok + + <etenil> at the beginning I thought I could put that into libstore + <etenil> which would have been fine + + <antrik> BTW, I remembered now that KAM's GSoC application should have a + pretty good description of the necessary changes... unfortunately, these + are not publicly visible IIRC :-( + + +## IRC, freenode, #hurd, 2011-02-16 + + <etenil> braunr: I've looked in the kernel to see where prefetching would + fit best. We talked of the VM yesterday, but I'm not sure about it. It + seems to me that the device part of the kernel makes more sense since + it's logically what manages devices, am I wrong? + <braunr> etenil: you are + <braunr> etenil: well + <braunr> etenil: drivers should already support clustered sector + read/writes + <etenil> ah + <braunr> but yes, there must be support in the drivers too + <braunr> what would really benefit the Hurd mostly concerns page faults, so + the right place is the VM subsystem + +[[clustered_page_faults]] + + +# 2012-03 + + +## IRC, freenode, #hurd, 2012-03-21 + + <mcsim> I thought that readahead should have some heuristics, like + accounting size of object and last access time, but i didn't find any in + kam's patch. Are heuristics needed or it will be overhead for + microkernel? + <youpi> size of object and last access time are not necessarily useful to + take into account + <youpi> what would usually typically be kept is the amount of contiguous + data that has been read lately + <youpi> to know whether it's random or sequential, and how much is read + <youpi> (the whole size of the object does not necessarily give any + indication of how much of it will be read) + <mcsim> if big object is accessed often, performance could be increased if + frame that will be read ahead will be increased too. + <youpi> yes, but the size of the object really does not matter + <youpi> you can just observe how much data is read and realize that it's + read a lot + <youpi> all the more so with userland fs translators + <youpi> it's not because you mount a CD image that you need to read it all + <mcsim> youpi: indeed. this will be better. But on other hand there is + principle about policy and mechanism. And kernel should implement + mechanism, but heuristics seems to be policy. Or in this case moving + readahead policy to user level would be overhead? + <antrik> mcsim: paging policy is all in kernel anyways; so it makes perfect + sense to put the readahead policy there as well + <antrik> (of course it can be argued -- probably rightly -- that all of + this should go into userspace instead...) + <mcsim> antrik: probably defpager partly could do that. AFAIR, it is + possible for defpager to return more memory than was asked. + <mcsim> antrik: I want to outline what should be done during gsoc. First, + kernel should support simple readahead for specified number of pages + (regarding direction of access) + simple heuristic for changing frame + size. Also default pager could make some analysis, for instance if it has + many data located consequentially it could return more data then was + asked. For other pagers I won't do anything. Is it suitable? + <antrik> mcsim: I think we actually had the same discussion already with + KAM ;-) + <antrik> for clustered pageout, the kernel *has* to make the decision. I'm + really not convinced it makes sense to leave the decision for clustered + pagein to the individual pagers + <antrik> especially as this will actually complicate matters because a) it + will require work in *every* pager, and b) it will probably make handling + of MADVISE & friends more complex + <antrik> implementing readahead only for the default pager would actually + be rather unrewarding. I'm pretty sure it's the one giving the *least* + benefit + <antrik> it's much, much more important for ext2 + <youpi> mcsim: maybe try to dig in the irc logs, we discussed about it with + neal. the current natural place would be the kernel, because it's the + piece that gets the traps and thus knows what happens with each + projection, while the backend just provides the pages without knowing + which projection wants it. Moving to userland would not only be overhead, + but quite difficult + <mcsim> antrik: OK, but I'm not sure that I could do it for ext2. + <mcsim> OK, I'll dig. + + +## IRC, freenode, #hurd, 2012-04-01 + + <mcsim> as part of implementing of readahead project I have to add + interface for setting appropriate behaviour for memory range. This + interface than should be compatible with madvise call, that has a lot of + possible advises, but most part of them are specific for Linux (according + to man page). Should mach also support these Linux-specific values? + <mcsim> p.s. these Linux-specific values shouldn't affect readahead + algorithm. + <youpi> the interface shouldn't prevent from adding them some day + <youpi> so that we don't have to add them yet + <mcsim> ok. And what behaviour with value MADV_NORMAL should be look like? + Seems that it should be synonym to MADV_SEQUENTIAL, isn't it? + <youpi> no, it just means "no idea what it is" + <youpi> in the linux implementation, that means some given readahead value + <youpi> while SEQUENTIAL means twice as much + <youpi> and RANDOM means zero + <mcsim> youpi: thank you. + <mcsim> youpi: Than, it seems to be better that kernel interface for + setting behaviour will accept readahead value, without hiding it behind + such constants, like VM_BEHAVIOR_DEFAULT (like it was in kam's + patch). And than implementation of madvise will call vm_behaviour_set + with appropriate frame size. Is that right? + <youpi> question of taste, better ask on the list + <mcsim> ok + + +## IRC, freenode, #hurd, 2012-06-09 + + <mcsim> hello. What fictitious pages in gnumach are needed for? + <mcsim> I mean why real page couldn't be grabbed straight, but in sometimes + fictitious page is grabbed first and than converted to real? + <braunr> mcsim: iirc, fictitious pages are needed by device pagers which + must comply with the vm pager interface + <braunr> mcsim: specifically, they must return a vm_page structure, but + this vm_page describes device memory + <braunr> mcsim: and then, it must not be treated like normal vm_page, which + can be added to page queues (e.g. page cache) + + +## IRC, freenode, #hurd, 2012-06-22 + + <mcsim> braunr: Ah. Patch for large storages introduced new callback + pager_notify_evict. User had to define this callback on his own as + pager_dropweak, for instance. But neal's patch change this. Now all + callbacks could have any name, but user defines structure with pager ops + and supplies it in pager_create. + <mcsim> So, I just changed notify_evict to confirm it to new style. + <mcsim> braunr: I want to changed interface of mo_change_attributes and + test my changes with real partitions. For both these I have to update + ext2fs translator, but both partitions I have are bigger than 2Gb, that's + why I need apply this patch.z + <mcsim> But what to do with mo_change_attributes? I need somehow inform + kernel about page fault policy. + <mcsim> When I change mo_ interface in kernel I have to update all programs + that use this interface and ext2fs is one of them. + + <mcsim> braunr: Who do you think better to inform kernel about fault + policy? At the moment I've added fault_strategy parameter that accepts + following strategies: randow, sequential with single page cluster, + sequential with double page cluster and sequential with quad page + cluster. OSF/mach has completely another interface of + mo_change_attributes. In OSF/mach mo_change_attributes accepts structure + of parameter. This structure could have different formats depending o + <mcsim> This rpc could be useful because it is not very handy to update + mo_change_attributes for kernel, for hurd libs and for glibc. Instead of + this kernel will accept just one more structure format. + <braunr> well, like i wrote on the mailing list several weeks ago, i don't + think the policy selection is of concern currently + <braunr> you should focus on the implementation of page clustering and + readahead + <braunr> concerning the interface, i don't think it's very important + <braunr> also, i really don't like the fact that the policy is per object + <braunr> it should be per map entry + <braunr> i think it mentioned that in my mail too + <braunr> i really think you're wasting time on this + <braunr> http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00064.html + <braunr> http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00029.html + <braunr> mcsim: any reason you completely ignored those ? + <mcsim> braunr: Ok. I'll do clustering for map entries. + <braunr> no it's not about that either :/ + <braunr> clustering is grouping several pages in the same transfer between + kernel and pager + <braunr> the *policy* is held in map entries + <antrik> mcsim: I'm not sure I properly understand your question about the + policy interface... but if I do, it's IMHO usually better to expose + individual parameters as RPC arguments explicitly, rather than hiding + them in an opaque structure... + <antrik> (there was quite some discussion about that with libburn guy) + <mcsim> antrik: Following will be ok? kern_return_t vm_advice(map, address, + length, advice, cluster_size) + <mcsim> Where advice will be either random or sequential + <antrik> looks fine to me... but then, I'm not an expert on this stuff :-) + <antrik> perhaps "policy" would be clearer than "advice"? + <mcsim> madvise has following prototype: int madvise(void *addr, size_t + len, int advice); + <mcsim> hmm... looks like I made a typo. Or advi_c_e is ok too? + <antrik> advise is a verb; advice a noun... there is a reason why both + forms show up in the madvise prototype :-) + <mcsim> so final variant should be kern_return_t vm_advise(map, address, + length, policy, cluster_size)? + <antrik> mcsim: nah, you are probably right that its better to keep + consistency with madvise, even if the name of the "advice" parameter + there might not be ideal... + <antrik> BTW, where does cluster_size come from? from the filesystem? + <antrik> I see merits both to naming the parameter "policy" (clearer) or + "advice" (more consistent) -- you decide :-) + <mcsim> antrik: also there is variant strategy, like with inheritance :) + I'll choose advice for now. + <mcsim> What do you mean under "where does cluster_size come from"? + <antrik> well, madvise doesn't have this parameter; so the value must come + from a different source? + <mcsim> in madvise implementation it could fixed value or somehow + calculated basing on size of memory range. In OSF/mach cluster size is + supplied too (via mo_change_attributes). + <antrik> ah, so you don't really know either :-) + <antrik> well, my guess is that it is derived from the cluster size used by + the filesystem in question + <antrik> so for us it would always be 4k for now + <antrik> (and thus you can probably leave it out alltogether...) + <antrik> well, fatfs can use larger clusters + <antrik> I would say, implement it only if it's very easy to do... if it's + extra effort, it's probably not worth it + <mcsim> There is sense to make cluster size bigger for ext2 too, since most + likely consecutive clusters will be within same group. + <mcsim> But anyway I'll handle this later. + <antrik> well, I don't know what cluster_size does exactly; but by the + sound of it, I'd guess it makes an assumption that it's *always* better + to read in this cluster size, even for random access -- which would be + simply wrong for 4k filesystem clusters... + <antrik> BTW, I agree with braunr that madvice() is optional -- it is way + way more important to get readahead working as a default policy first + + +## IRC, freenode, #hurd, 2012-07-01 + + <mcsim> youpi: Do you think you could review my code? + <youpi> sure, just post it to the list + <youpi> make sure to break it down into logical pieces + <mcsim> youpi: I pushed it my branch at gnumach repository + <mcsim> youpi: or it is still better to post changes to list? + <youpi> posting to the list would permit feedback from other people too + <youpi> mcsim: posix distinguishes normal, sequential and random + <youpi> we should probably too + <youpi> the system call should probably be named "vm_advise", to be a verb + like allocate etc. + <mcsim> youpi: ok. A have a talk with antrik regarding naming, I'll change + this later because compiling of glibc take a lot of time. + <youpi> mcsim: I find it odd that vm_for_every_page allocates non-existing + pages + <youpi> there should probably be at least a flag to request it or not + <mcsim> youpi: normal policy is synonym to default. And this could be + treated as either random or sequential, isn't it? + <braunr> mcsim: normally, no + <youpi> yes, the normal policy would be the default + <youpi> it doesn't mean random or sequential + <youpi> it's just to be a compromise between both + <youpi> random is meant to make no read-ahead, since that'd be spurious + anyway + <youpi> while by default we should make readahead + <braunr> and sequential makes even more aggressive readahead, which usually + implies a greater number of pages to fetch + <braunr> that's all + <youpi> yes + <youpi> well, that part is handled by the cluster_size parameter actually + <braunr> what about reading pages preceding the faulted paged ? + <mcsim> Shouldn't sequential clean some pages (if they, for example, are + not precious) that are placed before fault page? + <braunr> ? + <youpi> that could make sense, yes + <braunr> you lost me + <youpi> and something that you wouldn't to with the normal policy + <youpi> braunr: clear what has been read previously + <braunr> ? + <youpi> since the access is supposed to be sequential + <braunr> oh + <youpi> the application will proabably not re-read what was already read + <braunr> you mean to avoid caching it ? + <youpi> yes + <braunr> inactive memory is there for that + <youpi> while with the normal policy you'd assume that the application + might want to go back etc. + <youpi> yes, but you can help it + <braunr> yes + <youpi> instead of making other pages compete with it + <braunr> but then, it's for precious pages + <youpi> I have to say I don't know what a precious page it + <youpi> s + <youpi> does it mean dirty pages? + <braunr> no + <braunr> precious means cached pages + <braunr> "If precious is FALSE, the kernel treats the data as a temporary + and may throw it away if it hasn't been changed. If the precious value is + TRUE, the kernel treats its copy as a data repository and promises to + return it to the manager; the manager may tell the kernel to throw it + away instead by flushing and not cleaning the data" + <braunr> hm no + <braunr> precious means the kernel must keep it + <mcsim> youpi: According to vm_for_every_page. What kind of flag do you + suppose? If object is internal, I suppose not to cross the bound of + object, setting in_end appropriately in vm_calculate_clusters. + <mcsim> If object is external we don't know its actual size, so we should + make mo request first. And for this we should create fictitious pages. + <braunr> mcsim: but how would you implement this "cleaning" with sequential + ? + <youpi> mcsim: ah, ok, I thought you were allocating memory, but it's just + fictitious pages + <youpi> comment "Allocate a new page" should be fixed :) + <mcsim> braunr: I don't now how I will implement this specifically (haven't + tried yet), but I don't think that this is impossible + <youpi> braunr: anyway it's useful as an example where normal and + sequential would be different + <braunr> if it can be done simply + <braunr> because i can see more trouble than gains in there :) + <mcsim> braunr: ok :) + <braunr> mcsim: hm also, why fictitious pages ? + <braunr> fictitious pages should normally be used only when dealing with + memory mapped physically which is not real physical memory, e.g. device + memory + <mcsim> but vm_fault could occur when object represent some device memory. + <braunr> that's exactly why there are fictitious pages + <mcsim> at the moment of allocating of fictitious page it is not know what + backing store of object is. + <braunr> really ? + <braunr> damn, i've got used to UVM too much :/ + <mcsim> braunr: I said something wrong? + <braunr> no no + <braunr> it's just that sometimes, i'm confusing details about the various + BSD implementations i've studied + <braunr> out-of-gsoc-topic question: besides network drivers, do you think + we'll have other drivers that will run in userspace and have to implement + memory mapping ? like framebuffers ? + <braunr> or will there be a translation layer such as storeio that will + handle mapping ? + <youpi> framebuffers typically will, yes + <youpi> that'd be antrik's work on drm + <braunr> hmm + <braunr> ok + <youpi> mcsim: so does the implementation work, and do you see performance + improvement? + <mcsim> youpi: I haven't tested it yet with large ext2 :/ + <mcsim> youpi: I'm going to finish now moving of ext2 to new interface, + than other translators in hurd repository and than finish memory policies + in gnumach. Is it ok? + <youpi> which new interface? + <mcsim> Written by neal. I wrote some temporary code to make ext2 work with + it, but I'm going to change this now. + <youpi> you mean the old unapplied patch? + <mcsim> yes + <youpi> did you have a look at Karim's work? + <youpi> (I have to say I never found the time to check how it related with + neal's patch) + <mcsim> I found only his work in kernel. I didn't see his work in applying + of neal's patch. + <youpi> ok + <youpi> how do they relate with each other? + <youpi> (I have never actually looked at either of them :/) + <mcsim> his work in kernel and neal's patch? + <youpi> yes + <mcsim> They do not correlate with each other. + <youpi> ah, I must be misremembering what each of them do + <mcsim> in kam's patch was changes to support sequential reading in reverse + order (as in OSF/Mach), but posix does not support such behavior, so I + didn't implement this either. + <youpi> I can't find the pointer to neal's patch, do you have it off-hand? + <mcsim> http://comments.gmane.org/gmane.os.hurd.bugs/351 + <youpi> thx + <youpi> I think we are not talking about the same patch from Karim + <youpi> I mean lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html + <mcsim> I mean this patch: + http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00024.html + <mcsim> Oh. + <youpi> ok + <mcsim> seems, this is just the same + <youpi> yes + <youpi> from a non-expert view, I would have thought these patches play + hand in hand, do they really? + <mcsim> this patch is completely for kernel and neal's one is completely + for libpager. + <youpi> i.e. neal's fixes libpager, and karim's fixes the kernel + <mcsim> yes + <youpi> ending up with fixing the whole path? + <youpi> AIUI, karim's patch will be needed so that your increased readahead + will end up with clustered page request? + <mcsim> I will not use kam's patch + <youpi> is it not needed to actually get pages in together? + <youpi> how do you tell libpager to fetch pages together? + <youpi> about the cluster size, I'd say it shouldn't be specified at + vm_advise() level + <youpi> in other OSes, it is usually automatically tuned + <youpi> by ramping it up to a maximum readahead size (which, however, could + be specified) + <youpi> that's important for the normal policy, where there are typically + successive periods of sequential reads, but you don't know in advance for + how long + <mcsim> braunr said that there are legal issues with his code, so I cannot + use it. + <braunr> did i ? + <braunr> mcsim: can you give me a link to the code again please ? + <youpi> see above :) + <braunr> which one ? + <youpi> both + <youpi> they only differ by a typo + <braunr> mcsim: i don't remember saying that, do you have any link ? + <braunr> or log ? + <mcsim> sorry, can you rephrase "ending up with fixing the whole path"? + <mcsim> cluster_size in vm_advise also could be considered as advise + <braunr> no + <braunr> it must be the third time we're talking about this + <youpi> mcsim: I mean both parts would be needed to actually achieve + clustered i/o + <braunr> again, why make cluster_size a per object attribute ? :( + <youpi> wouldn't some objects benefit from bigger cluster sizes, while + others wouldn't? + <youpi> but again, I believe it should rather be autotuned + <youpi> (for each object) + <braunr> if we merely want posix compatibility (and for a first attempt, + it's quite enough), vm_advise is good, and the kernel selects the + implementation (and thus the cluster sizes) + <braunr> if we want finer grained control, perhaps a per pager cluster_size + would be good, although its efficiency depends on several parameters + <braunr> (e.g. where the page is in this cluster) + <braunr> but a per object cluster size is a large waste of memory + considering very few applications (if not none) would use the "feature" + .. + <braunr> (if any*) + <youpi> there must be a misunderstanding + <youpi> why would it be a waste of memory? + <braunr> "per object" + <youpi> so? + <braunr> there can be many memory objects in the kernel + <youpi> so? + <braunr> so such an overhead must be useful to accept it + <youpi> in my understanding, a cluster size per object is just a mere + integer for each object + <youpi> what overhead? + <braunr> yes + <youpi> don't we have just thousands of objects? + <braunr> for now + <braunr> remember we're trying to remove the page cache limit :) + <youpi> that still won't be more than tens of thousands of objects + <youpi> times an integer + <youpi> that's completely neglectible + <mcsim> braunr: Strange, Can't find in logs. Weird things are happening in + my memory :/ Sorry. + <braunr> mcsim: i'm almost sure i never said that :/ + <braunr> but i don't trust my memory too much either + <braunr> youpi: depends + <youpi> mcsim: I mean both parts would be needed to actually achieve + clustered i/o + <mcsim> braunr: I made I call vm_advise that applies policy to memory range + (vm_map_entry to be specific) + <braunr> mcsim: good + <youpi> actually the cluster size should even be per memory range + <mcsim> youpi: In this sense, yes + <youpi> k + <mcsim> sorry, Internet connection lags + <braunr> when changing a structure used to create many objects, keep in + mind one thing + <braunr> if its size gets larger than a threshold (currently, powers of + two), the cache used by the slab allocator will allocate twice the + necessary amount + <youpi> sure + <braunr> this is the case with most object caching allocators, although + some can have specific caches for common sizes such as 96k which aren't + powers of two + <braunr> anyway, an integer is negligible, but the final structure size + must be checked + <braunr> (for both 32 and 64 bits) + <mcsim> braunr: ok. + <mcsim> But I didn't understand what should be done with cluster size in + vm_advise? Should I delete it? + <braunr> to me, the cluster size is a pager property + <youpi> to me, the cluster size is a map property + <braunr> whereas vm_advise indicates what applications want + <youpi> you could have several process accessing the same file in different + ways + <braunr> youpi: that's why there is a policy + <youpi> isn't cluster_size part of the policy? + <braunr> but if the pager abilities are limited, it won't change much + <braunr> i'm not sure + <youpi> cluster_size is the amount of readahead, isn't it? + <braunr> no, it's the amount of data in a single transfer + <mcsim> Yes, it is. + <braunr> ok, i'll have to check your code + <youpi> shouldn't transfers permit unbound amounts of data? + <mcsim> braunr: than I misunderstand what readahead is + <braunr> well then cluster size is per policy :) + <braunr> e.g. random => 0, normal => 3, sequential => 15 + <braunr> why make it per map entry ? + <youpi> because it depends on what the application doezs + <braunr> let me check the code + <youpi> if it's accessing randomly, no need for big transfers + <youpi> just page transfers will be fine + <youpi> if accessing sequentially, rather use whole MiB of transfers + <youpi> and these behavior can be for the same file + <braunr> mcsim: the call is vm_advi*s*e + <braunr> mcsim: the call is vm_advi_s_e + <braunr> not advice + <youpi> yes, he agreed earlier + <braunr> ok + <mcsim> cluster_size is the amount of data that I try to read at one time. + <mcsim> at singe mo_data_request + <mcsim> *single + <youpi> which, to me, will depend on the actual map + <braunr> ok so it is the transfer size + <youpi> and should be autotuned, especially for normal behavior + <braunr> youpi: it makes no sense to have both the advice and the actual + size per map entry + <youpi> to get big readahead with all apps + <youpi> braunr: the size is not only dependent on the advice, but also on + the application behavior + <braunr> youpi: how does this application tell this ? + <youpi> even for sequential, you shouldn't necessarily use very big amounts + of transfers + <braunr> there is no need for the advice if there is a cluster size + <youpi> there can be, in the case of sequential, as we said, to clear + previous pages + <youpi> but otherwise, indeed + <youpi> but for me it's the converse + <youpi> the cluster size should be tuned anyway + <braunr> and i'm against giving the cluster size in the advise call, as we + may want to prefetch previous data as well + <youpi> I don't see how that collides + <braunr> well, if you consider it's the transfer size, it doesn't + <youpi> to me cluster size is just the size of a window + <braunr> if you consider it's the amount of pages following a faulted page, + it will + <braunr> also, if your policy says e.g. "3 pages before, 10 after", and + your cluster size is 2, what happens ? + <braunr> i would find it much simpler to do what other VM variants do: + compute the I/O sizes directly from the policy + <youpi> don't they autotune, and use the policy as a maximum ? + <braunr> depends on the implementations + <youpi> ok, but yes I agree + <youpi> although casting the size into stone in the policy looks bogus to + me + <braunr> but making cluster_size part of the kernel interface looks way too + messy + <braunr> it is + <braunr> that's why i would have thought it as part of the pager properties + <braunr> the pager is the true component besides the kernel that is + actually involved in paging ... + <youpi> well, for me the flexibility should still be per application + <youpi> by pager you mean the whole pager, not each file, right? + <braunr> if a pager can page more because e.g. it's a file system with big + block sizes, why not fetch more ? + <braunr> yes + <braunr> it could be each file + <braunr> but only if we have use for it + <braunr> and i don't see that currently + <youpi> well, posix currently doesn't provide a way to set it + <youpi> so it would be useless atm + <braunr> i was thinking about our hurd pagers + <youpi> could we perhaps say that the policy maximum could be a fraction of + available memory? + <braunr> why would we want that ? + <youpi> (total memory, I mean) + <youpi> to make it not completely cast into stone + <youpi> as have been in the past in gnumach + <braunr> i fail to understand :/ + <youpi> there must be a misunderstanding then + <youpi> (pun not intended) + <braunr> why do you want to limit the policy maximum ? + <youpi> how to decide it? + <braunr> the pager sets it + <youpi> actually I don't see how a pager could decide it + <youpi> on what ground does it make the decision? + <youpi> readahead should ideally be as much as 1MiB + <braunr> 02:02 < braunr> if a pager can page more because e.g. it's a file + system with big block sizes, why not fetch more ? + <braunr> is the example i have in mind + <braunr> otherwise some default values + <youpi> that's way smaller than 1MiB, isn't it? + <braunr> yes + <braunr> and 1 MiB seems a lot to me :) + <youpi> for readahead, not really + <braunr> maybe for sequential + <youpi> that's what we care about! + <braunr> ah, i thought we cared about normal + <youpi> "as much as 1MiB", I said + <youpi> I don't mean normal :) + <braunr> right + <braunr> but again, why limit ? + <braunr> we could have 2 or more ? + <youpi> at some point you don't get more efficiency + <youpi> but eat more memory + <braunr> having the pager set the amount allows us to easily adjust it over + time + <mcsim> braunr: Do you think that readahead should be implemented in + libpager? + <youpi> than needed + <braunr> mcsim: no + <braunr> mcsim: err + <braunr> mcsim: can't answer + <youpi> mcsim: do you read the log of what you have missed during + disconnection? + <braunr> i'm not sure about what libpager does actually + <mcsim> yes + <braunr> for me it's just mutualisation of code used by pagers + <braunr> i don't know the details + <braunr> youpi: yes + <braunr> youpi: that's why we want these values not hardcoded in the kernel + <braunr> youpi: so that they can be adjusted by our shiny user space OS + <youpi> (btw apparently linux uses minimum 16k, maximum 128 or 256k) + <braunr> that's more reasonable + <youpi> that's just 4 times less :) + <mcsim> braunr: You say that pager should decide how much data should be + read ahead, but each pager can't implement it on it's own as there will + be too much overhead. So the only way is to implement this in libpager. + <braunr> mcsim: gni ? + <braunr> why couldn't they ? + <youpi> mcsim: he means the size, not the actual implementation + <youpi> the maximum size, actually + <braunr> actually, i would imagine it as the pager giving per policy + parameters + <youpi> right + <braunr> like how many before and after + <youpi> I agree, then + <braunr> the kernel could limit, sure, to avoid letting pagers use + completely insane values + <youpi> (and that's just a max, the kernel autotunes below that) + <braunr> why not + <youpi> that kernel limit could be a fraction of memory, then? + <braunr> it could, yes + <braunr> i see what you mean now + <youpi> mcsim: did you understand our discussion? + <youpi> don't hesitate to ask for clarification + <mcsim> I supposed cluster_size to be such parameter. And advice will help + to interpret this parameter (whether data should be read after fault page + or some data should be cleaned before) + <youpi> mcsim: we however believe that it's rather the pager than the + application that would tell that + <youpi> at least for the default values + <youpi> posix doesn't have a way to specify it, and I don't think it will + in the future + <braunr> and i don't think our own hurd-specific programs will need more + than that + <braunr> if they do, we can slightly change the interface to make it a per + object property + <braunr> i've checked the slab properties, and it seems we can safely add + it per object + <braunr> cf http://www.sceen.net/~rbraun/slabinfo.out + <braunr> so it would still be set by the pager, but if depending on the + object, the pager could set different values + <braunr> youpi: do you think the pager should just provide one maximum size + ? or per policy sizes ? + <youpi> I'd say per policy size + <youpi> so people can increase sequential size like crazy when they know + their sequential applications need it, without disturbing the normal + behavior + <braunr> right + <braunr> so the last decision is per pager or per object + <braunr> mcsim: i'd say whatever makes your implementation simpler :) + <mcsim> braunr: how kernel knows that object are created by specific pager? + <braunr> that's the kind of things i'm referring to with "whatever makes + your implementation simpler" + <braunr> but usually, vm_objects have an ipc port and some properties + relatedto their pagers + <braunr> -usually + <braunr> the problem i had in mind was the locking protocol but our spin + locks are noops, so it will be difficult to detect deadlocks + <mcsim> braunr: and for every policy there should be variable in vm_object + structure with appropriate cluster_size? + <braunr> if you want it per object, yes + <braunr> although i really don't think we want it + <youpi> better keep it per pager for now + <braunr> let's imagine youpi finishes his 64-bits support, and i can + successfully remove the page cache limit + <braunr> we'd jump from 1.8 GiB at most to potentially dozens of GiB of RAM + <braunr> and 1.8, mostly unused + <braunr> to dozens almost completely used, almost all the times for the + most interesting use cases + <braunr> we may have lots and lots of objects to keep around + <braunr> so if noone really uses the feature ... there is no point + <youpi> but also lots and lots of memory to spend on it :) + <youpi> a lot of objects are just one page, but a lof of them are not + <braunr> sure + <braunr> we wouldn't be doing that otherwise :) + <braunr> i'm just saying there is no reason to add the overhead of several + integers for each object if they're simply not used at all + <braunr> hmm, 64-bits, better page cache, clustered paging I/O :> + <braunr> (and readahead included in the last ofc) + <braunr> good night ! + <mcsim> than, probably, make system-global max-cluster_size? This will save + some memory. Also there is usually no sense in reading really huge chunks + at once. + <youpi> but that'd be tedious to set + <youpi> there are only a few pagers, that's no wasted memory + <youpi> the user being able to set it for his own pager is however a very + nice feature, which can be very useful for databases, image processing, + etc. + <mcsim> In conclusion I have to implement following: 3 memory policies per + object and per vm_map_entry. Max cluster size for every policy should be + set per pager. + <mcsim> So, there should be 2 system calls for setting memory policy and + one for setting cluster sizes. + <mcsim> Also amount of data to transfer should be tuned automatically by + every page fault. + <mcsim> youpi: Correct me, please, if I'm wrong. + <youpi> I believe that's what we ended up to decide, yes + + +## IRC, freenode, #hurd, 2012-07-02 + + <braunr> is it safe to say that all memory objects implemented by external + pagers have "file" semantics ? + <braunr> i wonder if the current memory manager interface is suitable for + device pagers + <mcsim> braunr: What does "file" semantics mean? + <braunr> mcsim: anonymous memory doesn't have the same semantics as a file + for example + <braunr> anonymous memory that is discontiguous in physical memory can be + contiguous in swap + <braunr> and its location can change with time + <braunr> whereas with a memory object, the data exchanged with pagers is + identified with its offset + <braunr> in (probably) all other systems, this way of specifying data is + common to all files, whatever the file system + <braunr> linux uses the struct vm_file name, while in BSD/Solaris they are + called vnodes (the link between a file system inode and virtual memory) + <braunr> my question is : can we implement external device pagers with the + current interface, or is this interface really meant for files ? + <braunr> also + <braunr> mcsim: something about what you said yesterday + <braunr> 02:39 < mcsim> In conclusion I have to implement following: 3 + memory policies per object and per vm_map_entry. Max cluster size for + every policy should be set per pager. + <braunr> not per object + <braunr> one policy per map entry + <braunr> transfer parameters (pages before and after the faulted page) per + policy, defined by pagers + <braunr> 02:39 < mcsim> So, there should be 2 system calls for setting + memory policy and one for setting cluster sizes. + <braunr> adding one call for vm_advise is good because it mirrors the posix + call + <braunr> but for the parameters, i'd suggest changing an already existing + call + <braunr> not sure which one though + <mcsim> braunr: do you know how mo_change_attributes implemented in + OSF/Mach? + <braunr> after a quick reading of the reference manual, i think i + understand why they made it per object + <braunr> mcsim: no + <braunr> did they change the call to include those paging parameters ? + <mcsim> it accept two parameters: flavor and pointer to structure with + parameters. + <mcsim> flavor determines semantics of structure with parameters. + <mcsim> + http://www.darwin-development.org/cgi-bin/cvsweb/osfmk/src/mach_kernel/vm/memory_object.c?rev=1.1 + <mcsim> structure can have 3 different views and what exect view will be is + determined by value of flavor + <mcsim> So, I thought about implementing similar call that could be used + for various purposes. + <mcsim> like ioctl + <braunr> "pointer to structure with parameters" <= which one ? + <braunr> mcsim: don't model anything anywhere like ioctl please + <mcsim> memory_object_info_t attributes + <braunr> ioctl is the very thing we want NOT to have on the hurd + <braunr> ok attributes + <braunr> and what are the possible values of flavour, and what kinds of + attributes ? + <mcsim> and then appears something like this on each case: behave = + (old_memory_object_behave_info_t) attributes; + <braunr> ok i see + <mcsim> flavor could be OLD_MEMORY_OBJECT_BEHAVIOR_INFO, + MEMORY_OBJECT_BEHAVIOR_INFO, MEMORY_OBJECT_PERFORMANCE_INFO etc + <braunr> i don't really see the point of flavour here, other than + compatibility + <braunr> having attributes is nice, but you should probably add it as a + call parameter, not inside a structure + <braunr> as a general rule, we don't like passing structures too much + to/from the kernel, because handling them with mig isn't very clean + <mcsim> ok + <mcsim> What policy parameters should be defined by pager? + <braunr> i'd say number of pages to page-in before and after the faulted + page + <mcsim> Only pages before and after the faulted page? + <braunr> for me yes + <braunr> youpi might have different things in mind + <braunr> the page cleaning in sequential mode is something i wouldn't do + <braunr> 1/ applications might want data read sequentially to remain in the + cache, for other sequential accesses + <braunr> 2/ applications that really don't want to cache anything should + use O_DIRECT + <braunr> 3/ it's complicated, and we're in july + <braunr> i'd rather have a correct and stable result than too many unused + features + <mcsim> braunr: MADV_SEQUENTIAL Expect page references in sequential order. + (Hence, pages in the given range can be aggressively read ahead, and may + be freed soon after they are accessed.) + <mcsim> this is from linux man + <mcsim> braunr: Can I at least make keeping in mind that it could be + implemented? + <mcsim> I mean future rpc interface + <mcsim> braunr: From behalf of kernel pager is just a port. + <mcsim> That's why it is not clear for me how I can make in kernel + per-pager policy + <braunr> mcsim: you can't + <braunr> 15:19 < braunr> after a quick reading of the reference manual, i + think i understand why they made it per object + <braunr> + http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_madvise.html + <braunr> POSIX_MADV_SEQUENTIAL + <braunr> Specifies that the application expects to access the specified + range sequentially from lower addresses to higher addresses. + <braunr> linux might free pages after their access, why not, but this is + entirely up to the implementation + <mcsim> I know, when but applications might want data read sequentially to + remain in the cache, for other sequential accesses this kind of access + could be treated rather normal or random + <braunr> we can do differently + <braunr> mcsim: no + <braunr> sequential means the access will be sequential + <braunr> so aggressive readahead (e.g. 0 pages before, many after), should + be used + <braunr> for better performance + <braunr> from my pov, it has nothing to do with caching + <braunr> i actually sometimes expect data to remain in cache + <braunr> e.g. before playing a movie from sshfs, i sometimes prefetch it + using dd + <braunr> then i use mplayer + <braunr> i'd be very disappointed if my data didn't remain in the cache :) + <mcsim> At least these pages could be placed into inactive list to be first + candidates for pageout. + <braunr> that's what will happen by default + <braunr> mcsim: if we need more properties for memory objects, we'll adjust + the call later, when we actually implement them + <mcsim> so, first call is vm_advise and second is changed + mo_change_attributes? + <braunr> yes + <mcsim> there will appear 3 new parameters in mo_c_a: policy, pages before + and pages after? + <mcsim> braunr: With vm_advise I didn't understand one thing. This call is + defined in defs file, so that should mean that vm_advise is ordinal rpc + call. But on the same time it is defined as syscall in mach internals (in + mach_trap_table). + <braunr> mcsim: what ? + <braunr> were is it "defined" ? (it doesn't exit in gnumach currently) + <mcsim> Ok, let consider vm_map + <mcsim> I define it both in mach_trap_table and in defs file. + <mcsim> But why? + <braunr> uh ? + <braunr> let me see + <mcsim> Why defining in defs file is not enough? + <mcsim> and previous question: there will appear 3 new parameters in + mo_c_a: policy, pages before and pages after? + <braunr> mcsim: give me the exact file paths please + <braunr> mcsim: we'll discuss the new parameters after + <mcsim> kern/syscall_sw.c + <braunr> right i see + <mcsim> here mach_trap_table in defined + <braunr> i think they're not used + <braunr> they were probably introduced for performance + <mcsim> and ./include/mach/mach.defs + <braunr> don't bother adding vm_advise as a syscall + <braunr> about the parameters, it's a bit more complicated + <braunr> you should add 6 parameters + <braunr> before and after, for the 3 policies + <braunr> but + <braunr> as seen in the posix page, there could be more policies .. + <braunr> ok forget what i said, it's stupid + <braunr> yes, the 3 parameters you had in mind are correct + <braunr> don't forget a "don't change" value for the policy though, so the + kernel ignores the before/after values if we don't want to change that + <mcsim> ok + <braunr> mcsim: another reason i asked about "file semantics" is the way we + handle the cache + <braunr> mcsim: file semantics imply data is cached, whereas anonymous and + device memory usually isn't + <braunr> (although having the cache at the vm layer instead of the pager + layer allows nice things like the swap cache) + <mcsim> But this shouldn't affect possibility of implementing of device + pager. + <braunr> yes it may + <braunr> consider how a fault is actually handled by a device + <braunr> mach must use weird fictitious pages for that + <braunr> whereas it would be better to simply let the pager handle the + fault as it sees fit + <mcsim> setting may_cache to false should resolve the issue + <braunr> for the caching problem, yes + <braunr> which is why i still think it's better to handle the cache at the + vm layer, unlike UVM which lets the vnode pager handle its own cache, and + removes the vm cache completely + <mcsim> The only issue with pager interface I see is implementing of + scatter-gather DMA (as current interface does not support non-consecutive + access) + <braunr> right + <braunr> but that's a performance issue + <braunr> my problem with device pagers is correctness + <braunr> currently, i think the kernel just asks pagers for "data" + <braunr> whereas a device pager should really map its device memory where + the fault happen + <mcsim> braunr: You mean that every access to memory should cause page + fault? + <mcsim> I mean mapping of device memory + <braunr> no + <braunr> i mean a fault on device mapped memory should directly access a + shared region + <braunr> whereas file pagers only implement backing store + <braunr> let me explain a bit more + <braunr> here is what happens with file mapped memory + <braunr> you map it, access it (some I/O is done to get the page content in + physical memory), then later it's flushed back + <braunr> whereas with device memory, there shouldn't be any I/O, the device + memory should directly be mapped (well, some devices need the same + caching behaviour, while others provide direct access) + <braunr> one of the obvious consequences is that, when you map device + memory (e.g. a framebuffer), you expect changes in your mapped memory to + be effective right away + <braunr> while with file mapped memory, you need to msync() it + <braunr> (some framebuffers also need to be synced, which suggests greater + control is needed for external pagers) + <mcsim> Seems that I understand you. But how it is implemented in other + OS'es? Do they set something in mmu? + <braunr> mcsim: in netbsd, pagers have a fault operatin in addition to get + and put + <braunr> the device pager sets get and put to null and implements fault + only + <braunr> the fault callback then calls the d_mmap callback of the specific + driver + <braunr> which usually results in the mmu being programmed directly + <braunr> (e.g. pmap_enter or similar) + <braunr> in linux, i think raw device drivers, being implemented as + character device files, must provide raw read/write/mmap/etc.. functions + <braunr> so it looks pretty much similar + <braunr> i'd say our current external pager interface is insufficient for + device pagers + <braunr> but antrik may know more since he worked on ggi + <braunr> antrik: ^ + <mcsim> braunr: Seems he used io_map + <braunr> mcsim: where ar eyou looking at ? the incubator ? + <mcsim> his master's thesis + <braunr> ah the thesis + <braunr> but where ? :) + <mcsim> I'll give you a link + <mcsim> http://dl.dropbox.com/u/36519904/kgi_on_hurd.pdf + <braunr> thanks + <mcsim> see p 158 + <braunr> arg, more than 200 pages, and he says he's lazy :/ + <braunr> mcsim: btw, have a look at m_o_ready + <mcsim> braunr: This is old form of mo_change attributes + <mcsim> I'm not going to change it + <braunr> mcsim: these are actually the default object parameters right ? + <braunr> mcsim: if you don't change it, it means the kernel must set + default values until the pager changes them, if it does + <mcsim> yes. + <antrik> mcsim: madvise() on Linux has a separate flag to indicate that + pages won't be reused. thus I think it would *not* be a good idea to + imply it in SEQUENTIAL + <antrik> braunr: yes, my KMS code relies on mapping memory objects for the + framebuffer + <antrik> (it should be noted though that on "modern" hardware, mapping + graphics memory directly usually gives very poor performance, and drivers + tend to avoid it...) + <antrik> mcsim: BTW, it was most likely me who warned about legal issues + with KAM's work. AFAIK he never managed to get the copyright assignment + done :-( + <antrik> (that's not really mandatory for the gnumach work though... only + for the Hurd userspace parts) + <antrik> also I'd like to point out again that the cluster_size argument + from OSF Mach was probably *not* meant for advice from application + programs, but rather was supposed to reflect the cluster size of the + filesystem in question. at least that sounds much more plausible to me... + <antrik> braunr: I have no idea whay you mean by "device pager". device + memory is mapped once when the VM mapping is established; there is no + need for any fault handling... + <antrik> mcsim: to be clear, I think the cluster_size parameter is mostly + orthogonal to policy... and probably not very useful at all, as ext2 + almost always uses page-sized clusters. I'm strongly advise against + bothering with it in the initial implementation + <antrik> mcsim: to avoid confusion, better use a completely different name + for the policy-decided readahead size + <mcsim> antrik: ok + <antrik> braunr: well, yes, the thesis report turned out HUGE; but the + actual work I did on the KGI port is fairly tiny (not more than a few + weeks of actual hacking... everything else was just brooding) + <antrik> braunr: more importantly, it's pretty much the last (and only + non-trivial) work I did on the Hurd :-( + <antrik> (also, I don't think I used the word "lazy"... my problem is not + laziness per se; but rather inability to motivate myself to do anything + not providing near-instant gratification...) + <braunr> antrik: right + <braunr> antrik: i shouldn't consider myself lazy either + <braunr> mcsim: i agree with antrik, as i told you weeks ago + <braunr> about + <braunr> 21:45 < antrik> mcsim: to be clear, I think the cluster_size + parameter is mostly orthogonal to policy... and probably not very useful + at all, as ext2 almost always uses page-sized clusters. I'm strongly + advise against bothering with it + <braunr> in the initial implementation + <braunr> antrik: but how do you actually map device memory ? + <braunr> also, strangely enough, here is the comment in dragonflys + madvise(2) + <braunr> 21:45 < antrik> mcsim: to be clear, I think the cluster_size + parameter is mostly orthogonal to policy... and probably not very useful + at all, as ext2 almost always uses page-sized clusters. I'm strongly + advise against bothering with it + <braunr> in the initial implementation + <braunr> arg + <braunr> MADV_SEQUENTIAL Causes the VM system to depress the priority of + pages immediately preceding a given page when it is faulted in. + <antrik> braunr: interesting... + <antrik> (about SEQUENTIAL on dragonfly) + <antrik> as for mapping device memory, I just use to device_map() on the + mem device to map the physical address space into a memory object, and + then through vm_map into the driver (and sometimes application) address + space + <antrik> formally, there *is* a pager involved of course (implemented + in-kernel by the mem device), but it doesn't really do anything + interesting + <antrik> thinking about it, there *might* actually be page faults involved + when the address ranges are first accessed... but even then, the handling + is really trivial and not terribly interesting + <braunr> antrik: it does the most interesting part, create the physical + mapping + <braunr> and as trivial as it is, it requires a special interface + <braunr> i'll read about device_map again + <braunr> but yes, the fact that it's in-kernel is what solves the problem + here + <braunr> what i'm interested in is to do it outside the kernel :) + <antrik> why would you want to do that? + <antrik> there is no policy involved in doing an MMIO mapping + <antrik> you ask for the pysical memory region you are interested in, and + that's it + <antrik> whether the kernel adds the page table entries immediately or on + faults is really an implementation detail + <antrik> braunr: ^ + <braunr> yes it's a detail + <braunr> but do we currently have the interface to make such mappings from + userspace ? + <braunr> and i want to do that because i'd like as many drivers as possible + outside the kernel of course + <antrik> again, the userspace driver asks the kernel to establish the + mapping (through device_map() and then vm_map() on the resulting memory + object) + <braunr> hm i'm missing something + <braunr> + http://www.gnu.org/software/hurd/gnumach-doc/Device-Map.html#Device-Map + <= this one ? + <antrik> yes, this one + <braunr> but this implies the device is implemented by the kernel + <antrik> the mem device is, yes + <antrik> but that's not a driver + <braunr> ah + <antrik> it's just the interface for doing MMIO + <antrik> (well, any physical mapping... but MMIO is probably the only real + use case for that) + <braunr> ok + <braunr> i was thinking about completely removing the device interface from + the kernel actually + <braunr> but it makes sense to have such devices there + <antrik> well, in theory, specific kernel drivers can expose their own + device_map() -- but IIRC the only one that does (besides mem of course) + is maptime -- which is not a real driver either... + <braunr> oh btw, i didn't know you had a blog :) + <antrik> well, it would be possible to replace the device interface by + specific interfaces for the generic pseudo devices... I'm not sure how + useful that would be + <braunr> there are lots of interesting stuff there + <antrik> hehe... another failure ;-) + <braunr> failure ? + <antrik> well, when I realized that I'm speding a lot of time pondering + things, and never can get myself to actually impelemnt any of them, I had + the idea that if I write them down, there might at least be *some* good + from it... + <antrik> unfortunately it turned out that I need so much effort to write + things down, that most of the time I can't get myself to do that either + :-( + <braunr> i see + <braunr> well it's still nice to have it + <antrik> (notice that the latest entry is two years old... and I haven't + even started describing most of my central ideas :-( ) + <braunr> antrik: i tried to create a blog once, and found what i wrote so + stupid i immediately removed it + <antrik> hehe + <antrik> actually some of my entries seem silly in retrospect as well... + <antrik> but I guess that's just the way it is ;-) + <braunr> :) + <braunr> i'm almost sure other people would be interested in what i had to + say + <antrik> BTW, I'm actually not sure whether the Mach interfaces are + sufficient to implement GEM/TTM... we would certainly need kernel support + for GART (as for any other kind IOMMU in fact); but beyond that it's not + clear to me + <braunr> GEM ? TTM ? GART ? + <antrik> GEM = Graphics Execution Manager. part of the "new" DRM interface, + closely tied with KMS + <antrik> TTM = Translation Table Manager. does part of the background work + for most of the GEM drivers + <braunr> "The Graphics Execution Manager (GEM) is a computer software + system developed by Intel to do memory management for device drivers for + graphics chipsets." hmm + <antrik> (in fact it was originally meant to provide the actual interface; + but the Inter folks decided that it's not useful for their UMA graphics) + <antrik> GART = Graphics Aperture + <antrik> kind of an IOMMU for graphics cards + <antrik> allowing the graphics card to work with virtual mappings of main + memory + <antrik> (i.e. allowing safe DMA) + <braunr> ok + <braunr> all this graphics stuff looks so complex :/ + <antrik> it is + <antrik> I have a whole big chapter on that in my thesis... and I'm not + even sure I got everything right + <braunr> what is nvidia using/doing (except for getting the finger) ? + <antrik> flushing out all the details for KMS, GEM etc. took the developers + like two years (even longer if counting the history of TTM) + <antrik> Nvidia's proprietary stuff uses a completely own kernel interface, + which is of course not exposed or docuemented in any way... but I guess + it's actually similar in what it does) + <braunr> ok + <antrik> (you could ask the nouveau guys if you are truly + interested... they are doing most of their reverse engineering at the + kernel interface level) + <braunr> it seems graphics have very special needs, and a lot of them + <braunr> and the interfaces are changing often + <braunr> so it's not that much interesting currently + <braunr> it just means we'll probably have to change the mach interface too + <braunr> like you said + <braunr> so the answer to my question, which was something like "do mach + external pagers only implement files ?", is likely yes + <antrik> well, KMS/GEM had reached some stability; but now there are + further changes ahead with the embedded folks coming in with all their + dedicated hardware, calling for unified buffer management across the + whole pipeline (from capture to output) + <antrik> and yes: graphics hardware tends to be much more complex regarding + the interface than any other hardware. that's because it's a combination + of actual I/O (like most other devices) with a very powerful coprocessor + <antrik> and the coprocessor part is pretty much unique amongst peripherial + devices + <antrik> (actually, the I/O part is also much more complex than most other + hardware... but that alone would only require a more complex driver, not + special interfaces) + <antrik> embedded hardware makes it more interesting in that the I/O + part(s) are separate from the coprocessor ones; and that there are often + several separate specialised ones of each... the DRM/KMS stuff is not + prepared to deal with this + <antrik> v4l over time has evolved to cover such things; but it's not + really the right place to implement graphics drivers... which is why + there are not efforts to unify these frameworks. funny times... + + +## IRC, freenode, #hurd, 2012-07-03 + + <braunr> mcsim: vm_for_every_page should be static + <mcsim> braunr: ok + <braunr> mcsim: see http://gcc.gnu.org/onlinedocs/gcc/Inline.html + <braunr> and it looks big enough that you shouldn't make it inline + <braunr> let the compiler decide for you (which is possible only if the + function is static) + <braunr> (otherwise a global symbol needs to exist) + <braunr> mcsim: i don't know where you copied that comment from, but you + should review the description of the vm_advice call in mach.Defs + <mcsim> braunr: I see + <mcsim> braunr: It was vm_inherit :) + <braunr> mcsim: why isn't NORMAL defined in vm_advise.h ? + <braunr> mcsim: i figured actually ;) + <mcsim> braunr: I was going to do it later when. + <braunr> mcsim: for more info on inline, see + http://www.kernel.org/doc/Documentation/CodingStyle + <braunr> arg that's an old one + <mcsim> braunr: I know that I do not follow coding style + <braunr> mcsim: this one is about linux :p + <braunr> mcsim: http://lxr.linux.no/linux/Documentation/CodingStyle should + have it + <braunr> mcsim: "Chapter 15: The inline disease" + <mcsim> I was going to fix it later during refactoring when I'll merge + mplaneta/gsoc12/working to mplaneta/gsoc12/master + <braunr> be sure not to forget :p + <braunr> and the best not to forget is to do it asap + <braunr> +way + <mcsim> As to inline. I thought that even if I specify function as inline + gcc makes final decision about it. + <mcsim> There was a specifier that made function always inline, AFAIR. + <braunr> gcc can force a function not to be inline, yes + <braunr> but inline is still considered as a strong hint + + +## IRC, freenode, #hurd, 2012-07-05 + + <mcsim1> braunr: hello. You've said that pager has to supply 2 values to + kernel to give it an advice how execute page fault. These two values + should be number of pages before and after the page where fault + occurred. But for sequential policy number of pager before makes no + sense. For random policy too. For normal policy it would be sane to make + readahead symmetric. Probably it would be sane to make pager supply + cluster_size (if it is necessary to supply any) that w + <mcsim1> *that will be advice for kernel of least sane value? And maximal + value will be f(free_memory, map_entry_size)? + <antrik> mcsim1: I doubt symmetric readahead would be a good default + policy... while it's hard to estimate an optimum over all typical use + cases, I'm pretty sure most situtations will benefit almost exclusively + from reading following pages, not preceeding ones + <antrik> I'm not even sure it's useful to read preceding pages at all in + the default policy -- the use cases are probably so rare that the penalty + in all other use cases is not justified. I might be wrong on that + though... + <antrik> I wonder how other systems handle that + <LarstiQ> antrik: if there is a mismatch between pages and the underlying + store, like why changing small bits of data on an ssd is slow? + <braunr> mcsim1: i don't see why not + <braunr> antrik: netbsd reads a few pages before too + <braunr> actually, what netbsd does vary on the version, some only mapped + in resident pages, later versions started asynchronous transfers in the + hope those pages would be there + <antrik> LarstiQ: not sure what you are trying to say + <braunr> in linux : + <braunr> 321 * MADV_NORMAL - the default behavior is to read clusters. + This + <braunr> 322 * results in some read-ahead and read-behind. + <braunr> not sure if it's actually what the implementation does + <antrik> well, right -- it's probably always useful to read whole clusters + at a time, especially if they are the same size as pages... that doesn't + mean it always reads preceding pages; only if the read is in the middle + of the cluster AIUI + <LarstiQ> antrik: basically what braunr just pasted + <antrik> and in most cases, we will want to read some *following* clusters + as well, but probably not preceding ones + * LarstiQ nods + <braunr> antrik: the default policy is usually rather sequential + <braunr> here are the numbers for netbsd + <braunr> 166 static struct uvm_advice uvmadvice[] = { + <braunr> 167 { MADV_NORMAL, 3, 4 }, + <braunr> 168 { MADV_RANDOM, 0, 0 }, + <braunr> 169 { MADV_SEQUENTIAL, 8, 7}, + <braunr> 170 }; + <braunr> struct uvm_advice { + <braunr> int advice; + <braunr> int nback; + <braunr> int nforw; + <braunr> }; + <braunr> surprising isn't it ? + <braunr> they may suggest sequential may be backwards too + <braunr> makes sense + <antrik> braunr: what are these numbers? pages? + <braunr> yes + <antrik> braunr: I suspect the idea behind SEQUENTIAL is that with typical + sequential access patterns, you will start at one end of the file, and + then go towards the other end -- so the extra clusters in the "wrong" + direction do not actually come into play + <antrik> only situation where some extra clusters are actually read is when + you start in the middle of a file, and thus do not know yet in which + direction the sequential read will go... + <braunr> yes, there are similar comments in the linux code + <braunr> mcsim1: so having before and after numbers seems both + straightforward and in par with other implementations + <antrik> I'm still surprised about the almost symmetrical policy for NORMAL + though + <antrik> BTW, is it common to use heuristics for automatically recognizing + random and sequential patterns in the absence of explicit madise? + <braunr> i don't know + <braunr> netbsd doesn't use any, linux seems to have different behaviours + for anonymous and file memory + <antrik> when KAM was working on this stuff, someone suggested that... + <braunr> there is a file_ra_state struct in linux, for per file read-ahead + policy + <braunr> now the structure is of course per file system, since they all use + the same address + <braunr> (which is why i wanted it to be per pager in the first place) + <antrik> mcsim1: as I said before, it might be useful for the pager to + supply cluster size, if it's different than page size. but right now I + don't think this is something worth bothering with... + <antrik> I seriously doubt it would be useful for the pager to supply any + other kind of policy + <antrik> braunr: I don't understand your remark about using the same + address... + <antrik> braunr: pre-mapping seems the obvious way to implement readahead + policy + <antrik> err... per-mapping + <braunr> the ra_state (read ahead state) isn't the policy + <braunr> the policy is per mapping, parts of the implementation of the + policy is per file system + <mcsim1> braunr: How do you look at following implementation of NORMAL + policy: We have fault page that is current. Than we have maximal size of + readahead block. First we find first absent pages before and after + current. Than we try to fit block that will be readahead into this + range. Here could be following situations: in range RBS/2 (RBS -- size of + readahead block) there is no any page, so readahead will be symmetric; if + current page is first absent page than all + <mcsim1> RBS block will consist of pages that are after current; on the + contrary if current page is last absent than readahead will go backwards. + <mcsim1> Additionally if current page is approximately in the middle of the + range we can decrease RBS, supposing that access is random. + <braunr> mcsim1: i think your gsoc project is about readahead, we're in + july, and you need to get the job done + <braunr> mcsim1: grab one policy that works, pages before and after are + good enough + <braunr> use sane default values, let the pagers decide if they want + something else + <braunr> and concentrate on the real work now + <antrik> braunr: I still don't see why pagers should mess with that... only + complicates matters IMHO + <braunr> antrik: probably, since they almost all use the default + implementation + <braunr> mcsim1: just use sane values inside the kernel :p + <braunr> this simplifies things by only adding the new vm_advise call and + not change the existing external pager interface diff --git a/open_issues/performance/ipc_virtual_copy.mdwn b/open_issues/performance/ipc_virtual_copy.mdwn new file mode 100644 index 00000000..9708ab96 --- /dev/null +++ b/open_issues/performance/ipc_virtual_copy.mdwn @@ -0,0 +1,395 @@ +[[!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]]."]]"""]] + +IRC, freenode, #hurd, 2011-09-02: + + <slpz> what's the usual throughput for I/O operations (like "dd + if=/dev/zero of=/dev/null") in one of those Xen based Hurd machines + (*bber)? + <braunr> good question + <braunr> slpz: but don't use /dev/zero and /dev/null, as they don't have + anything to do with true I/O operations + <slpz> braunr: in fact, I want to test the performance of IPC's virtual + copy operations + <braunr> ok + <slpz> braunr: sorry, the "I/O" was misleading + <braunr> use bs=4096 then i guess + <slpz> bs > 2k + <braunr> ? + <slpz> braunr: everything about 2k is copied by vm_map_copyin/copyout + <slpz> s/about/above/ + <slpz> braunr: MiG's stubs check for that value and generate complex (with + out_of_line memory) messages if datalen is above 2k, IIRC + <braunr> ok + <braunr> slpz: found it, thanks + <tschwinge> tschwinge@strauss:~ $ dd if=/dev/zero of=/dev/null bs=4k & p=$! + && sleep 10 && kill -s INFO $p && sleep 1 && kill $p + <tschwinge> [1] 13469 + <tschwinge> 17091+0 records in + <tschwinge> 17090+0 records out + <tschwinge> 70000640 bytes (70 MB) copied, 17.1436 s, 4.1 MB/s + <tschwinge> Note, however 10 s vs. 17 s! + <tschwinge> And this is slow compared to heal hardware: + <tschwinge> thomas@coulomb:~ $ dd if=/dev/zero of=/dev/null bs=4k & p=$! && + sleep 10 && kill -s INFO $p && sleep 1 && kill $p + <tschwinge> [1] 28290 + <tschwinge> 93611+0 records in + <tschwinge> 93610+0 records out + <tschwinge> 383426560 bytes (383 MB) copied, 9.99 s, 38.4 MB/s + <braunr> tschwinge: is the first result on xen vm ? + <tschwinge> I think so. + <braunr> :/ + <slpz> tschwinge: Thanks! Could you please try with a higher block size, + something like 128k or 256k? + <tschwinge> strauss is on a machine that also hosts a buildd, I think. + <braunr> oh ok + <pinotree> yes, aside either rossini or mozart + <tschwinge> And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k + running, a parallel sleep 10 takes about 20 s (on strauss). + +[[open_issues/time]] + + <braunr> slpz: i'll set up xen hosts soon and can try those tests while + nothing else runs to have more accurate results + <tschwinge> tschwinge@strauss:~ $ dd if=/dev/zero of=/dev/null bs=256k & + p=$! && sleep 10 && kill -s INFO $p && sleep 1 && kill $p + <tschwinge> [1] 13482 + <tschwinge> 4566+0 records in + <tschwinge> 4565+0 records out + <tschwinge> 1196687360 bytes (1.2 GB) copied, 13.6751 s, 87.5 MB/s + <braunr> slpz: gains are logarithmic beyond the page size + <tschwinge> thomas@coulomb:~ $ dd if=/dev/zero of=/dev/null bs=256k & p=$! + && sleep 10 && kill -s INFO $p && sleep 1 && kill $p + <tschwinge> [1] 28295 + <tschwinge> 6335+0 records in + <tschwinge> 6334+0 records out + <tschwinge> 1660420096 bytes (1.7 GB) copied, 9.99 s, 166 MB/s + <tschwinge> This time a the sleep 10 decided to take 13.6 s. + ``Interesting.'' + <slpz> tschwinge: Thanks again. The results for the Xen machine are not bad + though. I can't obtain a throughput over 50MB/s with KVM. + <tschwinge> slpz: Want more data (bs)? Just tell. + <braunr> slpz: i easily get more than that + <braunr> slpz: what buffer size do you use ? + <slpz> tschwinge: no, I just wanted to see if Xen has an upper limit beyond + KVM's. Thank you. + <slpz> braunr: I try with different sizes until I find the maximum + throughput for a certain amount of requests (count) + <slpz> braunr: are you working with KVM? + <braunr> yes + <braunr> slpz: my processor is a model name : Intel(R) Core(TM)2 Duo + CPU E7500 @ 2.93GHz + <braunr> Linux silvermoon 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC + 2011 x86_64 GNU/Linux + <braunr> (standard amd64 squeeze kernel) + <slpz> braunr: and KVM's version? + <braunr> squeeze (0.12.5) + <braunr> bbl + <gnu_srs> 212467712 bytes (212 MB) copied, 9.95 s, 21.4 MB/s on kvm for me! + <slpz> gnu_srs: which block size? + <gnu_srs> 4k, and 61.7 MB/s with 256k + <slpz> gnu_srs: could you try with 512k and 1M? + <gnu_srs> 512k: 56.0 MB/s, 1024k: 40.2 MB/s Looks like the peak is around a + few 100k + <slpz> gnu_srs: thanks! + <slpz> I've just obtained 1.3GB/s with bs=512k on other (newer) machine + <braunr> on which hw/vm ? + <slpz> I knew this is a cpu-bound test, but I couldn't imagine faster + processors could make this difference + <slpz> braunr: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz + <slpz> braunr: KVM + <braunr> ok + <braunr> how much time did you wait before reading the result ? + <slpz> that was 20x times better than the same test on my Intel(R) + Core(TM)2 Duo CPU T7500 @ 2.20GHz + <slpz> braunr: I've repeated the test with a fixed "count" + <gnu_srs> My box is: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz: Max + is 67 MB/s around 140k block size + <braunr> yes but how much time did dd run ? + <gnu_srs> 10 s plus/minus a few fractions of a second, + <braunr> try waiting 30s + <slpz> braunr: didn't check, let me try again + <braunr> my kvm peaks at 130 MiB/s with bs 512k / 1M + <gnu_srs> 2029690880 bytes (2.0 GB) copied, 30.02 s, 67.6 MB/s, bs=140k + <braunr> gnu_srs: i'm very surprised with slpz's result of 1.3 GiB/s + <slpz> braunr: over 60 s running, same performance + <braunr> nice + <braunr> i wonder what makes it so fast + <braunr> how much cache ? + <gnu_srs> Me too, I cannot get better values than around 67 MB/s + <braunr> gnu_srs: same questions + <slpz> braunr: 4096KB, same as my laptop + <braunr> slpz: l2 ? l3 ? + <gnu_srs> kvm: cache=writeback, CPU: 4096 KB + <braunr> gnu_srs: this has nothing to do with the qemu option, it's about + the cpu + <slpz> braunr: no idea, it's the first time I touch this machine. I going + to see if I find the model in processorfinder + <braunr> under my host linux system, i get a similar plot, that is, + performance drops beyond bs=1M + <gnu_srs> braunr: OK, bu I gave you the cache size too, same as slpz. + <braunr> i wonder what dd actually does + <braunr> read() and writes i guess + <slpz> braunr: read/write repeatedly, nothing fancy + <braunr> slpz: i don't think it's a good test for virtual copy + <braunr> io_read_request, vm_deallocate, io_write_request, right + <braunr> slpz: i really wonder what it is about i5 that improves speed so + much + <slpz> braunr: me too + <slpz> braunr: L2: 2x256KB, L3: 4MB + <slpz> and something calling "SmartCache" + <gnu_srs> slpz: where did you find these values? + <slpz> gnu_srs: ark.intel.com and wikipedia + <gnu_srs> aha, cpuinfo just gives cache size. + <slpz> that "SmartCache" thing seems to be just L2 cache sharing between + cores. Shouldn't make a different since we're using only one core, and I + don't see KVM hooping between them. + <manuel> with bs=256k: 7004487680 bytes (7.0 GB) copied, 10 s, 700 MB/s + <manuel> (qemu/kvm, 3 * Intel(R) Xeon(R) E5504 2GHz, cache size 4096 KB) + <slpz> manuel: did you try with 512k/1M? + <manuel> bs=512k: 7730626560 bytes (7.7 GB) copied, 10 s, 773 MB/s + <manuel> bs=1M: 7896825856 bytes (7.9 GB) copied, 10 s, 790 MB/s + <slpz> manuel: those are pretty good numbers too + <braunr> xeon processor + <gnu_srs> lshw gave me: L1 Cache 256KiB, L2 cache 4MiB + <slpz> sincerely, I've never seen Hurd running this fast. Just checked + "uname -a" to make sure I didn't take the wrong image :-) + <manuel> for bs=256k, 60s: 40582250496 bytes (41 GB) copied, 60 s, 676 MB/s + <braunr> slpz: i think you can assume processor differences alter raw + copies too much to get any valuable results about virtual copy operations + <braunr> you need a specialized test program + <manuel> and bs=512k, 60s, 753 MB/s + <slpz> braunr: I'm using the mach_perf suite from OSFMach to do the + "serious" testing. I just wanted a non-synthetic test to confirm the + readings. + +[[!taglink open_issue_gnumach]] -- have a look at *mach_perf*. + + <braunr> manuel: how much cache ? 2M ? + <braunr> slpz: ok + <braunr> manuel: hmno, more i guess + <manuel> braunr: /proc/cpuinfo says cache size : 4096 KB + <braunr> ok + <braunr> manuel: performance should drop beyond bs=2M + <braunr> but that's not relevant anyway + <gnu_srs> Linux: bs=1M, 10.8 GB/s + <slpz> I think this difference is too big to be only due to a bigger amount + of CPU cycles... + <braunr> slpz: clearly + <slpz> gnu_srs: your host system has 64 or 32 bits? + <slpz> braunr: I'm going to investigate a bit + <slpz> but this accidental discovery just made my day. We're able to run + Hurd at decent speeds on newer hardware! + <braunr> slpz: what result do you get with the same test on your host + system ? + <manuel> interestingly, running it several times has made the performance + drop quite much (i'm getting 400-500MB/s with 1M now, compared to nearly + 800 fifteen minutes ago) + +[[Degradataion]]. + + <slpz> braunr: probably an almost infinite throughput, but I don't consider + that a valid test, since in Linux, the write operation to "/dev/null" + doesn't involve memory copying/moving + <braunr> manuel: i observed the same behaviour + <gnu_srs> slpz: Host system is 64 bit + <braunr> slpz: it doesn't on the hurd either + <braunr> slpz: (under 2k, that is) + <braunr> over* + <slpz> braunr: humm, you're right, as the null translator doesn't "touch" + the memory, CoW rules apply + <braunr> slpz: the only thing which actually copies things around is dd + <braunr> probably by simply calling read() + <braunr> which gets its result from a VM copy operation, but copies the + content to the caller provided buffer + <braunr> then vm_deallocate() the data from the storeio (zero) translator + <braunr> if storeio isn't too dumb, it doesn't even touch the transfered + buffer (as anonymous vm_map()ped memory is already cleared) + +[[!taglink open_issue_documentation]] + + <braunr> so this is a good test for measuring (profiling?) our ipc overhead + <braunr> and possibly the vm mapping operations (which could partly explain + why the results get worse over time) + <braunr> manuel: can you run vminfo | wc -l on your gnumach process ? + <slpz> braunr: Yes, unless some special situation apply, like the source + address/offset being unaligned, or if the translator decides to return + the result in a different buffer (which I assume is not the case for + storeio/zero) + <manuel> braunr: 35 + <braunr> slpz: they can't be unaligned, the vm code asserts that + <braunr> manuel: ok, this is normal + <slpz> braunr: address/offset from read() + <braunr> slpz: the caller provided buffer you mean ? + <slpz> braunr: yes, and the offset of the memory_object, if it's a pager + based translator + <braunr> slpz: highly unlikely, the compiler chooses appropriate alignments + for such buffers + <slpz> braunr: in those cases, memcpy is used over vm_copy + <braunr> slpz: and the glibc memcpy() optimized versions can usually deal + with that + <braunr> slpz: i don't get your point about memory objects + <braunr> slpz: requests on memory objects always have aligned values too + <slpz> braunr: sure, but can't deal with the user requesting non + page-aligned sizes + <braunr> slpz: we're considering our dd tests, for which we made sure sizes + were page aligned + <slpz> braunr: oh, I was talking in a general sense, not just in this dd + tests, sorry + <slpz> by the way, dd on the host tops at 12 GB/s with bs=2M + <braunr> that's consistent with our other results + <braunr> slpz: you mean, even on your i5 processor with 1.3 GiB/s on your + hurd kvm ? + <slpz> braunr: yes, on the GNU/Linux which is running as host + <braunr> slpz: well that's not consistent + <slpz> braunr: consistent with what? + <braunr> slpz: i get roughly the same result on my host, but ten times less + on my hurd kvm + <braunr> slpz: what's your kernel/kvm versions ? + <slpz> 2.6.32-5-amd64 (debian's build) 0.12.5 + <braunr> same here + <braunr> i'm a bit clueless + <braunr> why do i only get 130 MiB/s where you get 1.3 .. ? :) + <slpz> well, on my laptop, where Hurd on KVM tops on 50 MB/s, Linux gets a + bit more than 10 GB/s + <braunr> see + <braunr> slpz: reduce bs to 256k and test again if you have time please + <slpz> braunr: on which system? + <braunr> slpz: the fast one + <braunr> (linux host) + <slpz> braunr: Hurd? + <slpz> ok + <slpz> 12 GB/s + <braunr> i get 13.3 + <slpz> same for 128k, only at 64k starts dropping + <slpz> maybe, on linux we're being limited by memory speed, while on Hurd's + this test is (much) more CPU-bound? + <braunr> slpz: maybe + <braunr> too bad processor stalls aren't easy to measure + <slpz> braunr: that's very true. It's funny when you read a paper which + measures performance by cycles on an old RISC processor. That's almost + impossible to do (with reliability) nowadays :-/ + <slpz> I wonder which throughput can achieve Hurd running bare-metal on + this machine... + <antrik> both the Xeon and the i5 use cores based on the Nehalem + architecture + <antrik> apparently Nehalem is where Intel first introduces nested page + tables + <antrik> which pretty much explains the considerably lower overhead of VM + magic + <cjuner> antrik, what are nested page tables? (sounds like the 4-level page + tables we already have on amd64, or 2-level or 3-level on x86 pae) + <antrik> page tables were always 2-level on x86 + <antrik> that's unrelated + <antrik> nested page tables means there is another layer of address + translation, so the VMM can do it's own translation and doesn't care what + the guest system does => no longer has to intercept all page table + manipulations + <braunr> antrik: do you imply it only applies to virtualized systems ? + <antrik> braunr: yes + <slpz> antrik: Good guess. Looks like Intel's EPT are doing the trick by + allowing the guest OS deal with its own page faults + <slpz> antrik: next monday, I'll try disabling EPT support in KVM on that + machine (the fast one). That should confirm your theory empirically. + <slpz> this also means that there're too many page faults, as we should be + doing virtual copies of memory that is not being accessed + <slpz> and looking at how the value of "page faults" in "vmstat" increases, + shows that page faults are directly proportional to the number of pages + we are asking from the translator + <slpz> I've also tried doing a long read() directly, to be sure that "dd" + is not doing something weird, and it shows the same behaviour. + <braunr> slpz: dd does copy buffers + <braunr> slpz: i told you, it's not a good test case for pure virtual copy + evaluation + <braunr> antrik: do you know if xen benefits from nested page tables ? + <antrik> no idea + +[[!taglink open_issue_xen]] + + <slpz> braunr: but my small program doesn't, and still provokes a lot of + page faults + <braunr> slpz: are you certain it doesn't ? + <slpz> braunr: looking at google, it looks like recent Xen > 3.4 supports + EPT + <braunr> ok + <braunr> i'm ordering my new server right now, core i5 :) + <slpz> braunr: at least not explicitily. I need to look at MiG stubs again, + I don't remember if they do something weird. + <antrik> braunr: sandybridge or nehalem? :-) + <braunr> antrik: no idea + <antrik> does it tell a model number? + <braunr> not yet + <braunr> but i don't have a choice for that, so i'll order it first, check + after + <antrik> hehe + <antrik> I'm not sure it makes all that much difference anyways for a + server... unless you are running it at 100% load ;-) + <braunr> antrik: i'm planning on running xen guests suchs as new buildd + <antrik> hm... note though that some of the nehalem-generation i5s were + dual-core, while all the new ones are quad + <braunr> it's a quad + <antrik> the newer generation has better performance per GHz and per + Watt... but considering that we are rather I/O-limited in most cases, it + probably won't make much difference + <antrik> not sure whether there are further virtualisation improvements + that could be relevant... + <braunr> buildds spend much time running gcc, so even such improvements + should help + <braunr> there, server ordered :) + <braunr> antrik: model name : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz + +IRC, freenode, #hurd, 2011-09-06: + + <slpz> youpi: what machines are being used for buildd? Do you know if they + have EPT/RVI? + <youpi> we use PV Xen there + <slpz> I think Xen could also take advantage of those technologies. Not + sure if only in HVM or with PV too. + <youpi> only in HVM + <youpi> in PV it does not make sense: the guest already provides the + translated page table + <youpi> which is just faster than anything else + +IRC, freenode, #hurd, 2011-09-09: + + <antrik> oh BTW, for another data point: dd zero->null gets around 225 MB/s + on my lowly 1 GHz Pentium3, with a blocksize of 32k + <antrik> (but only half of that with 256k blocksize, and even less with 1M) + <antrik> the system has been up for a while... don't know whether it's + faster on a freshly booted one + +IRC, freenode, #hurd, 2011-09-15: + + <sudoman> + http://www.reddit.com/r/gnu/comments/k68mb/how_intelamd_inadvertently_fixed_gnu_hurd/ + <sudoman> so is the dd command pointed to by that article a measure of io + performance? + <antrik> sudoman: no, not really + <antrik> it's basically the baseline of what is possible -- but the actual + slowness we experience is more due to very unoptimal disk access patterns + <antrik> though using KVM with writeback caching does actually help with + that... + <antrik> also note that the title of this post really makes no + sense... nested page tables should provide similar improvements for *any* + guest system doing VM manipulation -- it's not Hurd-specific at all + <sudoman> ok, that makes sense. thanks :) + +IRC, freenode, #hurd, 2011-09-16: + + <slpz> antrik: I wrote that article (the one about How AMD/Intel fixed...) + <slpz> antrik: It's obviously a bit of an exaggeration, but it's true that + nested pages supposes a great improvement in the performance of Hurd + running on virtual machines + <slpz> antrik: and it's Hurd specific, as this system is more affected by + the cost of page faults + <slpz> antrik: and as the impact of virtualization on the performance is + much higher than (almost) any other OS. + <slpz> antrik: also, dd from /dev/zero to /dev/null it's a measure on how + fast OOL IPC is. diff --git a/open_issues/performance/microbenchmarks.mdwn b/open_issues/performance/microbenchmarks.mdwn new file mode 100644 index 00000000..de3a54b7 --- /dev/null +++ b/open_issues/performance/microbenchmarks.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Microbenchmarks may give useful hints, or they may not. + +<http://www.ibm.com/developerworks/java/library/j-jtp02225.html> diff --git a/open_issues/performance/microkernel_multi-server.mdwn b/open_issues/performance/microkernel_multi-server.mdwn new file mode 100644 index 00000000..111d2b88 --- /dev/null +++ b/open_issues/performance/microkernel_multi-server.mdwn @@ -0,0 +1,47 @@ +[[!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]] + +Performance issues due to the microkernel/multi-server system architecture? + +IRC, freenode, #hurd, 2011-07-26 + + < CTKArcher> I read that, because of its microkernel+servers design, the + hurd was slower than a monolithic kernel, is that confirmed ? + < youpi> the hurd is currently slower than current monolithic kernels, but + it's not due to the microkernel + servers design + < youpi> the microkernel+servers design makes the system call path longer + < youpi> but you're bound by disk and network speed + < youpi> so the extra overhead will not hurt so much + < youpi> except dumb applications keeping doing system calls all the time + of course, but they are usually considered bogus + < braunr> there may be some patterns (like applications using pipes + extensively, e.g. git-svn) which may suffer from the design, but still in + an acceptable range + < CTKArcher> so, you are saying that disk and network are more slowing the + system than the longer system call path and because of that, it wont + really matter ? + < youpi> braunr: they should sitll be fixed because they'll suffer (even if + less) on monolithic kernels + < youpi> CTKArcher: yes + < braunr> yes + < CTKArcher> mmh + < youpi> CTKArcher: you might want to listen to AST's talk at fosdem 10 + iirc, about minix + < youpi> they even go as far as using an IPC for each low-level in/out + < youpi> for security + < braunr> this has been expected for a long time + < braunr> which is what motivated research in microkernels + < CTKArcher> I've already downloaded the video :) + < youpi> and it has been more and more true with faster and faster cpus + < braunr> but in 95, processors weren't that fast compared to other + components as they are now + < youpi> while disk/mem haven't evovled so fast diff --git a/open_issues/perl.mdwn b/open_issues/perl.mdwn new file mode 100644 index 00000000..48343e3e --- /dev/null +++ b/open_issues/perl.mdwn @@ -0,0 +1,101 @@ +[[!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="Foster Perl programming"]] + +[[!template id=note text="""**2011-08**. A dependency loop in Debian GNU/Hurd +currently leads to: *Could not perform immediate configuration on 'perl'*. +Easy workaround: + + # apt-get install perl perl-base -o APT::Immediate-Configure=false + +"""]] + + +Resolve issues uncovered by Perl's test suite, and enable Hurd-specific +features. + +There is a [[!FF_project 264]][[!tag bounty]] on this task. + +--- + + +# Part I + +First, make the language functional, have its test suite pass without errors. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/perl_python feeds=no]] + + +## IRC, OFTC, #debian-hurd, 2011-11-08 + + <Dom> pinotree: so, with your three fixes applied to 5.14.2, there are + still 9 tests failing. They don't seem to be regressions in perl, since + they also fail when I build 5.14.0 (even though the buildd managed it). + <Dom> What do you suggest as the way forward? + <Dom> (incidentally I'm trying on strauss's sid chroot to see how that + compares) + <pinotree> Dom: samuel makes buildds build perl with nocheck (otherwise + we'd have no perl at all) + <pinotree> which tests still fail? + <Dom> ../cpan/Sys-Syslog/t/syslog.t ../cpan/Time-HiRes/t/HiRes.t + ../cpan/autodie/t/recv.t ../dist/IO/t/io_pipe.t ../dist/threads/t/libc.t + ../dist/threads/t/stack.t ../ext/Socket/t/socketpair.t io/pipe.t + op/sigdispatch.t + <Dom> buildds> I see + <pinotree> ah ok, those that are failing for me even with my patches + <Dom> I hadn't spotted that the builds were done with nocheck. + <Dom> (but only sometimes...) + <Dom> Explains a lot + <pinotree> syslog is kind of non-working on hurd, and syslog.t succeeds in + buildds (as opposted to crash the machine...) because there's no /var/log + in chroots + <pinotree> libc.t appears to succeed too in buildds + * Dom notices how little memory strauss has, and cancels the build, now + that he *knows* that running out of memory caused the crahses + <pinotree> iirc HiRes.t, io_pipe.t , pipe.t and sigdispatch.t fails because + of trobules we have with posix signals + <pinotree> socketpair.t is kind of curious, it seems to block on + socketpair()... + * Dom wonders if a wiki page tracking this would be worthwhile + <pinotree> stack.t fails because we cannot set a different size for pthread + stacks, yet (similar failing test cases are also in the python test + suite) + <Dom> if there are problems which aren't going to get resolved any time + soon, it may be worth a few SKIPs conditional on architecture, depending + on how serious the issue is + <Dom> then we'd get better visibility of other/new issues + <Dom> (problems which aren't bugs in perl, that is) + <pinotree> understandable, yes + <pinotree> i think nobody digged much deeper in the failing ones yet, to + actually classify them as due to glibc/hurd/mach + <pinotree> (eg unlike the pipe behaviour in sysconf.t i reported) + +### 2011-11-26 + + <pinotree> cool, my recvfrom() fix also makes the perl test recv.t pass + + +--- + + +# Part II + +Next, Hurd-specific features can be added. Add an interface to the +language/environment for being able to do [[RPC]] calls, in order to program +[[hurd/translator]]s natively in Perl. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]] diff --git a/open_issues/perlmagick.mdwn b/open_issues/perlmagick.mdwn new file mode 100644 index 00000000..8a57a8fd --- /dev/null +++ b/open_issues/perlmagick.mdwn @@ -0,0 +1,107 @@ +[[!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 +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]]."]]"""]] + +[[!debbug 557771]] + +# Bisecting + + * Good + + * 7:6.4.0.9.dfsg1-1 (2008-04-22) built from + <http://snapshot.debian.net/package/imagemagick> + * 6.4.0-11 + * 6.4.1-0 + * 6.4.1-1 + + * Bad + + * 6.4.1-2 + * 6.4.1-5 + * 6.4.1-10 + * 6.4.2-10 + * 6.4.5-9 + * 6.4.8-0 / Debian 6.4.8.0-1 + * 6.5.5-3 / Debian 6.5.5.3-1 + * 6.5.8.3-1 from Debian unstable (also in testing) + * Svn trunk (r848) + + +# 6.4.1-1 -> 6.4.1-2 + + -CFLAGS = -g -O2 -Wall -W -pthread + +CFLAGS = -fopenmp -g -O2 -Wall -W -pthread + -GOMP_LIBS = + +GOMP_LIBS = -lgomp + -LDFLAGS = -lfreetype -lz + +LDFLAGS = -fopenmp -lfreetype -lz + +Etc. + + +/usr/include/pthread.h: + + + +/usr/include/pthread/pthread.h: + + + +/usr/include/bits/spin-lock-inline.h: + + + +/usr/include/bits/cancelation.h: + + + +/usr/include/bits/pthread-np.h: + + + +/usr/lib/gcc/i486-gnu/4.4.2/include/omp.h: + + +# State as of 2011-03-06 + +freenode, #hurd channel, 2011-03-06: + + <pinotree> tschwinge: (speaking on working perl, how did it en with that + "(glibc) double free" crash with perl?) + <pinotree> *end + <tschwinge> I think I remember I suspected it's a libgomp (!) issue in the + end. I have not yet continued working on that. + <pinotree> libogmp? looks like you know more than me, then :) + <youpi> tschwinge: oh, I'm interested + <youpi> I know a bit about libgomp :) + <tschwinge> I bisected this down to where Imagemagick added -fgomp (or + whatever it is). And then the perl library (Imagemagick.pm?) which loads + the imagemagick.so segfaulted. + <tschwinge> ImageMagick did this change in the middle of a x.x.x.something + release.. + <tschwinge> My next step would have been to test whether libgomp works at + all for us. + <youpi> ./usr/sbin/debootstrap:DEBOOTSTRAP_CHECKSUM_FIELD="SHA$SHA_SIZE" + <youpi> erf + <youpi> so they switched to another checksum + <youpi> but we don't have that one on all of our packages :) + <youpi> tschwinge: + <youpi> buildd@bach:~$ OMP_NUM_THREADS=2 ./test + <youpi> I'm 0x1 + <youpi> I'm 0x3 + <youpi> libgomp works at least a bit + <tschwinge> OK. + <pinotree> i guess we should hope the working bits don't stop at that point + ;) + <tschwinge> If open_issues/perlmagick is to be believed a diff of 6.4.1-1 + and 6.4.1-2 should tell what exactly was changed. + <tschwinge> Oh! + <tschwinge> I even have it on the page already! ;-) + <tschwinge> -fopenmp + <youpi> I've tried the pragmas that imagemagick uses + <youpi> they work + <tschwinge> Might be the issue fixed itself? + <youpi> I don't know, it's the latest libc here + <youpi> (and latest hurd, to be uploaded) + + +# Other + +[[!debbug 551017]] + +Code in Svn: `+ 1` missing to account for both `/` and `\0`. diff --git a/open_issues/pfinet.mdwn b/open_issues/pfinet.mdwn new file mode 100644 index 00000000..7aadd736 --- /dev/null +++ b/open_issues/pfinet.mdwn @@ -0,0 +1,27 @@ +[[!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]] + +In certain situations, pfinet spawns more and more threads, +apparently without any bounds. + +The thread creation happens in bursts rather than continuously. +According to a backtrace in GDB, +all the threads are functional and waiting for client requests. +(The bursts are getting smaller as the number of threads rises, +but probably only because the enormous number of existing threads +slows down processing in general.) + +This can be triggered quite reliably by X clients running on the Hurd system, +connected to an X server on another machine over TCP, +and transferring fairly large amounts of data. +The easiest way to reproduce it I found is launching freeciv-gtk2, +pressing the "new game" button, and then simply waiting for a while. diff --git a/open_issues/pfinet_vs_system_time_changes.mdwn b/open_issues/pfinet_vs_system_time_changes.mdwn new file mode 100644 index 00000000..46705047 --- /dev/null +++ b/open_issues/pfinet_vs_system_time_changes.mdwn @@ -0,0 +1,82 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <grey_gandalf> I did a sudo date... + <grey_gandalf> and the machine hangs + +This was very likely a misdiagnosis: + +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? + <antrik> tschwinge: BTW, pfinet doesn't actually die I think -- it just + drops open connections... + <antrik> perhaps it thinks they timed out + <tschwinge> antrik: Isn't the translator restarted instead? + <antrik> don't think so + <antrik> when pfinet actually dies, I also loose the NFS mounts, which + doesn't happen in this case + <antrik> hehe "... and the machine hangs" + <antrik> he didn't bother to check that the machine is perfectly fine, only + the SSH connection got dropped + <tschwinge> Ah, I see. So it'S perhaps indeed simply closes TCP + connections that have been without data for ``too long''? + <antrik> yeah, that's my guess + <antrik> my clock is speeding, so ntpdate sets it in the past + <antrik> perhaps there is some math that concludes the connection have been + inactive for -200 seconds, which (unsigned) is more than any timeout :-) + <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 + +IRC, freenode, #hurd, 2012-06-28: + + <bddebian> great, now setting the date/time fucked my machine + <pinotree> yes, we lack a monotonic clock + <pinotree> there are select() loops that use gettimeofday to determine how + much time to wait + <pinotree> thus if the time changes (eg goes back), the calculation goes + crazy + <antrik> pinotree: didn't you implement a monotonic clock?... + <pinotree> started to + <antrik> bddebian: did it really fuck the machine? normally it only resets + TCP connections... + <pinotree> yeah, i remember such gettimeofay-based select-loops at least in + pfinet + <antrik> I don't think it's a loop. it just drops the connections, + believing they have timed out + <bddebian> antrik: Well in this case I don't know because I am at work but + it fucked me because I now cannot get to it.. :) + <antrik> bddebian: that's odd... you should be able to just log in again + IIRC diff --git a/open_issues/pflocal_reauth.mdwn b/open_issues/pflocal_reauth.mdwn new file mode 100644 index 00000000..839e383d --- /dev/null +++ b/open_issues/pflocal_reauth.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_glibc open_issue_hurd]] + +IRC, freenode, #hurd, 2011-04-02 + + <pinotree> youpi: i'm playing with pflocal, and noticing that a simple C + executable doesn't trigger reauthenticate + <pinotree> youpi: i've put a debug output (to file) in S_io_reauthenticate, + and with a simple C test (which uses unix sockets) it isn't called + <youpi> pinotree: it seems pflocal should return FS_RETRY_REAUTH in + retry_type + <youpi> to make glibc call reauthentication + <pinotree> pflocal? + <youpi> yes, in the dir_lookup handler + <pinotree> isn't that ext2fs? + <youpi> libtrivfs had dir_lookup() too + <youpi> trivfs_check_open_hook can be used to tweak its behavior + <pinotree> ah, missed that pflocal was using libtrivfs, sorry + <youpi> there are probably very few translators which don't use one of the + lib*fs :) + <antrik> pinotree: what are you trying to do with pflocal? + <pinotree> local socket scredentials (SCM_CREDS) + <antrik> ah + <antrik> don't really know what that is, but I remember reading some + mention of it ;-) + +--- + +See also [[pflocal_socket_credentials_for_local_sockets]] and +[[sendmsg_scm_creds]]. diff --git a/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn new file mode 100644 index 00000000..dfdc213c --- /dev/null +++ b/open_issues/pflocal_socket_credentials_for_local_sockets.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]]."]]"""]] + +IRC, freenode, #hurd, 2011-03-28 + +[[!tag open_issue_hurd]] + + <pinotree> basically, i'm trying to implement socket credentials for local + sockets, and i guessed doing it in pflocal would be the appropriate place + <pinotree> what i thought was filling the cmsg data for MSG_CRED at + S_socket_recv() call + <pinotree> in case i missed it, would there be a way to "identify" the + other side of the port associated to the sock_user of that call? + <pochu> pinotree: that's needed by dbus right? cool! (and I don't know) + <pinotree> (yes, and gamin) + <youpi> pinotree: you have them already, they're just not stored + <youpi> see S_io_reauthenticate + <youpi> Throw away the ids we went through all that trouble to get... + <youpi> (comment) + * pinotree looks + <pinotree> hm, and who calls that rpc? + <youpi> everybody + <youpi> since that's how ext2fs knows the permission to apply, for instance + <pinotree> ah, i was referring to the reauthenticate of pflocal, not + auth_server_authenticate() + <youpi> that's what I'm saying + <youpi> see __hurd_file_name_lookup_retry, which is the very internal part + of open() + <youpi> it calls io_reauthenticate() + <youpi> to authenticate itself to the underlying translator of the opened + node + <pinotree> youpi: so, hm, could be an option make the result of pflocal's + S_io_reauthenticate cached in the sock_user struct? + <youpi> yes + <pinotree> nice thanks, i will try that change first + +--- + +See also [[pflocal_reauth]] and [[sendmsg_scm_creds]]. diff --git a/open_issues/pflocal_x_slowness.mdwn b/open_issues/pflocal_x_slowness.mdwn new file mode 100644 index 00000000..9bc18128 --- /dev/null +++ b/open_issues/pflocal_x_slowness.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, #hurd, 2010-08-10 + + <antrik> m1k11e: I think the X slowness is a problem in pflocal, i.e. the translator handling UNIX domain sockets + <antrik> (X clients communicate with a local X server using domain sockets) diff --git a/open_issues/phython.mdwn b/open_issues/phython.mdwn new file mode 100644 index 00000000..62f70be0 --- /dev/null +++ b/open_issues/phython.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Go through James Morrison's (phython) pages, <http://hurd.dyndns.org/>, (via +Intrernet Archive Wayback Machine), and archive / hunt down what's still +interesting. diff --git a/open_issues/placement_of_virtual_memory_regions.mdwn b/open_issues/placement_of_virtual_memory_regions.mdwn new file mode 100644 index 00000000..39478f20 --- /dev/null +++ b/open_issues/placement_of_virtual_memory_regions.mdwn @@ -0,0 +1,103 @@ +[[!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-07-13 + + <braunr> does anyone know if posix (or mach) has requirements or a policy + about the placement of allocations of virtual space ? + <braunr> a policy such as bottom-up ? + <braunr> or "find lowest vailable space" ? + <jkoenig> braunr, you mean for vm_allocate ? You may want to check mmap() + but I can't remember ever coming across such a thing (except maybe + wrt. alignment) + <braunr> i was wondering how e.g. libraries are linked near the stack + (possibly at slightly random addresses) + <braunr> does the linker walk the address space entries top-down ? + <braunr> jkoenig: i didn't see anything either in the mach interface, but i + may have missed something + <braunr> jkoenig: most systems i've been studying mark the vm regions for + the heap and the stack + <braunr> but for mach, the stack is just allocated virtual memory at the + top of the space + <braunr> so the "placement policy" is either completely outside the kernel, + or relies on its interface + <jkoenig> braunr, actually I'm surprised Mach would even dictate where the + (one?) stack should be, I would have expected it to be the job of + whatever creates a thread to make this kind of choice + <braunr> jkoenig: threads have their own stacks, under the responsibility + of the user trhead implementation + <braunr> but a program usually needs a stack even before it runs + <braunr> i had to set one to bootstrap modules in v0.1 + <braunr> but i wonder if it's just for bootstrapping (and then propagated + by fork()) or part of the interface + <braunr> but this doesn't matter much actually, the allocation mechanism i + have in mind can actually support multiple policies + <jkoenig> I would guess the former (just for bootstrapping), since a new + task has no thread, and a new thread has no state. (but I'm no expert) + <braunr> i think so + <braunr> i'll have a look at the exec server + <braunr> jkoenig: did the previous implementation of procfs show task maps + ? + <jkoenig> braunr, I don't think so, I would probably have felt compelled to + include them in the new one if it did :-) + <braunr> hmmm + <braunr> we definitely need that + <jkoenig> is there a compelling use case you think about in particular? + <braunr> yes + <braunr> i failed to understand how gnumach behaved wrt ipc right spaces + +[[rework_gnumach_ipc_spaces]] + + <braunr> and when i did, i found out my work was impossible to integrate + <jkoenig> "ipc right spaces" ? + <braunr> each task have an ipc space, which contains righs + <braunr> rights + <braunr> the ipc translation layer converts space/name and space/port + tuples to rights + <braunr> i wanted to replace the splay tree with a radix tree but didn't + get how the ipc table made the splay tree almost unused + <braunr> i don't want to make this kind of mistake again, so i'd like a + clear and detailed view of the vm spaces + <braunr> (it's only compelling for myself, all right) + <braunr> but + <braunr> we have vminfo + <braunr> rbraun@nordrassil:~$ vminfo $$ | wc -l + <braunr> 1046 + <braunr> oh my + <braunr> in comparison, a firefox instance has less than 500 on linux + <jkoenig> you mean there's some kind of port name table (or functional + equivalent) which actually resides in the task's memory? (and that's what + shows up at the beginning of the address space with prot=0?) + <braunr> jkoenig: sorry for being confusing, it's not that at all + <jkoenig> (btw feel free to tell me to just go read the source or whatever) + <braunr> jkoenig: don't worry + <jkoenig> braunr, no problem + <braunr> jkoenig: i just compared a previous attempt to improve gnumach + which failed because i didn't have enough insight of the inner workings + of the kernel + <braunr> jkoenig: i really want to miss as little as possible on the vm + part, so having detailed information about what actually happens on + running hurd systems is something i need + + +# IRC, freenode, #hurd, 2011-07-24 + + <braunr> oh btw, i noticed there are many mappings below the program text + <braunr> most notably, the stack + <braunr> except for special applications like wine, could this break + anything ? + <braunr> i also wonder how libraries are mapped, because there is nothing + to perform top-down allocations + <braunr> which means if the region below the program text is exhausted, + libraries could be mapped right after the heap + <youpi> it shouldn't break anything except things like wine & libgc, yes + <braunr> which could make malloc() fail :/ diff --git a/open_issues/populate_hurd_git_with_submodules_etc.mdwn b/open_issues/populate_hurd_git_with_submodules_etc.mdwn new file mode 100644 index 00000000..c89b95e9 --- /dev/null +++ b/open_issues/populate_hurd_git_with_submodules_etc.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="populate hurd.git with submodules, etc."]] + +Populate the top-level *[Savannah]/hurd.git* with a bunch of submodules +(various translators; everything that's intersting), have it serve as sort of a +tested distribution (because the submodules are versioned), plus adding build +machinery / cross-compilation support, etc. diff --git a/open_issues/posix_fadv_volatile.mdwn b/open_issues/posix_fadv_volatile.mdwn new file mode 100644 index 00000000..6bd25e3e --- /dev/null +++ b/open_issues/posix_fadv_volatile.mdwn @@ -0,0 +1,16 @@ +[[!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="POSIX_FADV_VOLATILE"]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +May be interesting to watch what happens: LWN, Jonathan Corbet, +[`POSIX_FADV_VOLATILE`](http://lwn.net/Articles/468896/), 2011-11-22. diff --git a/open_issues/prelink.mdwn b/open_issues/prelink.mdwn new file mode 100644 index 00000000..ad85b9e2 --- /dev/null +++ b/open_issues/prelink.mdwn @@ -0,0 +1,27 @@ +[[!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_porting]] + +The *prelink* package, as distributed via Debian unstable, does build on +GNU/Hurd. After installing the satisfiable dependencies, use +`dpkg-buildpackage -b -uc -d` to ignore SELinux and libc6-dev dependencies. + +It is unclear whether it also does work. The testsuite (run manually) does +*FAIL* on all tests, which is due to the prelinker doing something to the +copied `ld.so.1` so that it faults on every invocation. This does not happen +on GNU/Linux. + +Not much in the prelinker is Linux-specific. `src/get.c`'s `is_ldso_soname` +should already cover our `ld.so.1` case (and what about `ld.so`?). At the end +of `src/arch-i386.c`, `.dynamic_linker` has to be set properly. And, in that +file there are some Linux process VM constants, of which `REG2S` and `REG2E` +are the only relevant in the `!exec_shield` case. Probably these need to be +adjusted. What else? diff --git a/open_issues/proc_server_proc_exception_raise.mdwn b/open_issues/proc_server_proc_exception_raise.mdwn new file mode 100644 index 00000000..1d0e92a3 --- /dev/null +++ b/open_issues/proc_server_proc_exception_raise.mdwn @@ -0,0 +1,37 @@ +[[!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-08-11 + + < youpi> in which error cases a reply port will actually have been consumed + by mach_msg ? + < youpi> it seems at least MACH_SEND_NOTIFY_IN_PROGRESS do? + < braunr> + http://www.gnu.org/software/hurd/gnumach-doc/Message-Send.html#Message-Send + < braunr> "These return codes imply that the message was returned to the + caller with a pseudo-receive operation: " + < braunr> isn't it what you're looking for ? + < youpi> well, it's hard to tell from the name + < youpi> I don't know what "pseudo-receiv operation" means + < braunr> it's described below + < youpi> ew + < braunr> it looks close enough to a normal receive to assume it consumes + the reply port + < youpi> so it's even more complex than what I thought + < youpi> well, no, it returns the right + < youpi> actually the error I'm getting is MACH_RCV_INVALID_NAME + < youpi> which I guess means the sending part succeeded + < youpi> the case at stake is proc/mgt.c: S_proc_exception_raise() + < youpi> when the proc_exception_raise() forward fails + < youpi> currently we always return 0, but if proc_exception_raise() + actually managed to send the message, the reply port was consumed and + MIG_NO_REPLY should be returned instead diff --git a/open_issues/profiling.mdwn b/open_issues/profiling.mdwn new file mode 100644 index 00000000..7e3c7350 --- /dev/null +++ b/open_issues/profiling.mdwn @@ -0,0 +1,28 @@ +[[!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 +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]]."]]"""]] + +*Profiling* ([[!wikipedia Profiling_(computer_programming) desc="Wikipedia +article"]]) is a tool for tracing where CPU time is spent. This is usually +done for [[performance analysis|performance]] reasons. + + * [[gprof]] + + Should be working, but some issues have been reported, regarding GCC spec + files. Should be possible to fix (if not yet done) easily. + + * [[community/gsoc/project_ideas/dtrace]] + + Have a look at this, integrate it into the main trees. + + * [[LTTng]] + + * [[SystemTap]] + + * ... or some other Linux thing. diff --git a/open_issues/pth.mdwn b/open_issues/pth.mdwn index bf9c70d7..12bf5098 100644 --- a/open_issues/pth.mdwn +++ b/open_issues/pth.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,8 +11,18 @@ is included in the section entitled [[!tag open_issue_porting]] +IRC, unknown channel, unknown date. + <azeem> seems pth still doesn't work <bddebian> Doesn't build or doesn't work? <azeem> both <azeem> some configure test keep grinding the CPU, same for the test suite <azeem> which apparently runs pth_init() and never returns + + <azeem> actually, pth fails to build right now + <azeem> pth_mctx.c:477: error: request for member '__pc' in something not a structure or union + + <azeem> I know the pth test suite fails (it locks up the machine) or used to fail, so I guess porting work for pth would be needed + <azeem> < marcusb> from reading the pth/PORTING document, porting libpth shouldn't be too hard... + + <youpi> dropped pth [from the channel's topic], as we think we know why it fails (sigaltstack is bogus) diff --git a/open_issues/pthread_atfork.mdwn b/open_issues/pthread_atfork.mdwn new file mode 100644 index 00000000..ac724cf0 --- /dev/null +++ b/open_issues/pthread_atfork.mdwn @@ -0,0 +1,13 @@ +[[!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_libpthread]] + +pthread_atfork is not actually implemented, making some programs fail. Code can probably be borrowed from nptl/sysdeps/unix/sysv/linux/register-atfork.c diff --git a/open_issues/python.mdwn b/open_issues/python.mdwn new file mode 100644 index 00000000..403ff8aa --- /dev/null +++ b/open_issues/python.mdwn @@ -0,0 +1,47 @@ +[[!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="Foster Python programming"]] + +Resolve issues uncovered by Python's test suite, and enable Hurd-specific +features. + +There is a [[!FF_project 260]][[!tag bounty]] on this task. + +--- + + +# Part I + +First, make the language functional, have its test suite pass without errors. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/perl_python feeds=no]] + + +## Analysis + + * [[select_bogus_fd]] + +--- + + +# Part II + +Next, Hurd-specific features can be added. Add an interface to the +language/environment for being able to do [[RPC]] calls, in order to program +[[hurd/translator]]s natively in Python. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]] diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn index 57c6bdbf..8f752d61 100644 --- a/open_issues/resource_management_problems.mdwn +++ b/open_issues/resource_management_problems.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_gnumach open_issue_hurd open_issue_viengoos]] @@ -19,3 +20,67 @@ discardable, for example. These issues are what Neal Walfield is working on with his new kernel [[microkernel/viengoos]]. + + +# Kernel + +Inside the [[kernel]], there is commonly a need to allocate resources according +to externally induced demand, dynamically. For example, for memory-management +data structures (page tables), process table entries, thread control blocks, +[[capability]] tables, incoming network packages, blocks that are read in from +disk, the keyboard type-ahead buffer for a in-kernel keyboard driver. Some of +these are due to actions driven by user-space requests, others are due to +actions internal to the the kernel itself. Some of these buffers can be sized +statically (keyboard type-ahead buffer), and are thus unproblematic. Others +are not, and should thus be attributed to their user space entities. In the +latter (ideal) case, all resources -- that is, including those needed inside +the kernel -- that a user space task needs for execution are provided by itself +(and, in turn, provided by its parent / principal), and the kernel itself does +not need to allocate any resources dynamically out of an its own memory pool. +This avoids issues like [[microkernel/Mach]]'s [[zalloc_panics]] upon user +space processes allocating too many [[microkernel/mach/port]]s, for example. + +[[!toggleable id=fof_plos09 text="""[[!template id=note +text="*[[fof\_plos09|microkernel/barrelfish]]*: +{{$microkernel/barrelfish#fof_plos09}}"]]"""]] + +[[!toggleable id=sel4 text="""[[!template id=note +text="[[*sel4*|microkernel/l4]]: {{$microkernel/l4#sel4}}"]]"""]] + +In [[!toggle id=fof_plos09 text="[fof\_plos09]"]], the authors describe in +section 3 how they model their [[capability]] system according to [[!toggle +id=sel4 text="[sel4]"]] using a *retype* operation that *takes an existing +capability and produces one or more derived capabilities [...] used to create +new kernel-level memory objects (such as page tables or execution contexts) +from capabilities to raw regions of RAM*. + +This is, of course, non-trivial to implement, and also requires changing the +[[RPC]] interfaces, for example, but it is a valid approach, a research topic. + +([[!taglink open_issue_documentation]]: compare this to Linux [`vmsplice`'s +SPLICE_F_GIFT +flag](http://www.kernel.org/doc/man-pages/online/pages/man2/vmsplice.2.html#DESCRIPTION).) + +IRC, freenode, #hurd, 2011-07-31 + + < braunr> one of the biggest problems on the hurd is that, when a client + makes a call, kernel (and other) resources are allocated on behalf of the + server performaing the requested action + < braunr> performing* + < braunr> this makes implementing scheduling and limits difficult + < CTKArcher> And could changing the kernel change anything to that ? + < braunr> yes but you'd probably need to change its interface as well + < braunr> iirc, the critique describes resource containers + < braunr> but no work has been done on the current hurd (hence the hurdng + attempts) + + +# Further Examples + + * [[hurd/critique]] + + * [[IO_accounting]] + + * [[translators_set_up_by_untrusted_users]], and [[pagers]] + + * [[configure max command line length]] diff --git a/open_issues/grub2.mdwn b/open_issues/resource_management_problems/configure_max_command_line_length.mdwn index 235950a4..6c0a0d99 100644 --- a/open_issues/grub2.mdwn +++ b/open_issues/resource_management_problems/configure_max_command_line_length.mdwn @@ -5,17 +5,13 @@ 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="GRUB2"]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_porting]] -Just like [[GRUB (legacy)|grub_legacy]], GRUB2 needs to be ported for being -installable when attempted to be installed *from* GNU/Hurd systems: - - $ sudo grub-probe --target=device /boot/grub - grub-probe: error: cannot find a device for /boot/grub. - -Etc. + <terpstra> do the buildds also crash? + <youpi> sometimes + <youpi> usually when a configure scripts tries to find out how large a + command line can be + <youpi> (thus eating all memory) diff --git a/open_issues/resource_management_problems/io_accounting.mdwn b/open_issues/resource_management_problems/io_accounting.mdwn new file mode 100644 index 00000000..113b965a --- /dev/null +++ b/open_issues/resource_management_problems/io_accounting.mdwn @@ -0,0 +1,49 @@ +[[!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]]."]]"""]] + +IRC, freenode, #hurd, 2011-07-22 + + <braunr> an interesting question i've had in mind for a few weeks now is + I/O accounting + <braunr> what *is* I/O on a microkernel based system ? + <braunr> can any cross address space transfer be classified as I/O ? + +IRC, freenode, #hurd, 2011-07-29 + + < braunr> how does the hurd account I/O ? + < youpi> I don't think it does + < youpi> not an easy task, actually + < youpi> since gnumach has no idea about it + < braunr> yes + < braunr> another centralization issue + < braunr> does network access count as I/O on linux ? + < youpi> no + < braunr> not even nfs ? + < youpi> else you'd get 100% for servers :) + < braunr> right + < youpi> nfs goes through vfs first + < braunr> i'll rephrase my question + < youpi> I'd need to check but I believe it can check nfs + < braunr> does I/O accounting occur at the vfs level or block layer ? + < youpi> I don't know, but I beleive vfs + < youpi> (at least that's how I'd do it) + < braunr> i don't have any more nfs box to test that :/ + < braunr> personally i'd do it at the block layer :) + < youpi> well, both + < youpi> so e2fsck can show up too + < braunr> yes + < youpi> it's just a matter of ref counting + < youpi> apparently nfs doesn't account + < youpi> find . -printf "" doesn't show up in waitio + < braunr> good + < youpi> well, depends on the point of view + < youpi> as a user, you'd like to know whether your processes are stuck on + i/o (be it disk or net) + < braunr> this implies clearly defining what io is diff --git a/open_issues/resource_management_problems/pagers.mdwn b/open_issues/resource_management_problems/pagers.mdwn new file mode 100644 index 00000000..4c36703c --- /dev/null +++ b/open_issues/resource_management_problems/pagers.mdwn @@ -0,0 +1,322 @@ +[[!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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-09-14 + +Coming from [[translators_set_up_by_untrusted_users]], 2011-09-14 discussion: + + <slpz> antrik: I think a tunable option for preventing non-root users from + creating pagers and attaching translators could also be desirable + <antrik> slpz: why would you want to prevent creating pagers and attaching + translators? + <tschwinge> Preventing resource exhaustion, I guess. + <slpz> antrik: security and (as tschwinge says) for prevent a rouge pager + from exhausting the system. + <slpz> antrik: without the ability to use translators for non-root users, + Hurd can provide (almost) the same level of resource protection than + other *nixes + +See also: [[translators_set_up_by_untrusted_users]], +[[hurd/translator/tmpfs/tmpfs_vs_defpager]]. + + <braunr> the hurd is about that though + <slpz> there should be also a limit on the number of outstanding requests + that a task can have, and some other easily traceable values + <braunr> port messages queues have limits + <antrik> slpz: anything can exhaust the system. there are much more basic + limits that are missing... and I don't see how translators or pagers are + special in that regard + <slpz> braunr: that's what I said tunable. If I don't share my computer + with untrusted users, I want full functionality. Otherwise, I can enable + that limitation + <slpz> braunr: but I think those limits are on reception + <braunr> that's a wrong solution + <slpz> antrik: because pagers are external memory objects, and those are + treated differently + <braunr> compared to what ? + <braunr> and yes, the limit is on the message queue, on reception + <braunr> why is that a problem ? + <slpz> antrik: forbidding the use of translator was for security, to avoid + the problem of traversing an untrusted FS + <slpz> braunr: compared to anonymous memory + <slpz> braunr: because if the limit is on reception, a task can easily do a + DoS against a server + <braunr> hm actually, the problems we have with swap handling is that + anonymous memory is handled in a very similar way as other objects + <slpz> braunr: I want to limit the number of outstanding (unprocessed + messages in queues) requests + <braunr> slpz: the solution isn't about forbidding the use of translators, + but changing common code (libc i guess) not to use them, they can still + run beside + <slpz> braunr: that's because, currently, the external page limit is not + enforced + <braunr> i'm also not sure about DoS attacks + <braunr> if i'm right, there is often one port for each managed object, + which usually exist per client + <slpz> braunr: yes, that could an option too (for translators, not for + pagers) + <braunr> i don't see how pagers wouldn't be translators on the hurd + <slpz> braunr: all pagers are translators, but not all translators are + pagers ;-) + <braunr> so if it works for translators, it also works for pagers + <slpz> braunr: it would fix the security issue, but not the resource + exhaustion problem, with only affects to pagers + <braunr> i just don't see a point in implementing resource limits before + even fixing other fundamental issues + <braunr> the only way to avoid resource exhaustion is resource limits + <antrik> slpz: just not following untrusted translators is much more useful + than forbidding them alltogether + <braunr> and the main problem of mach is resource accounting + <braunr> so first, fix that, using the critique as a starting point + +[[hurd/critique]]. + + <slpz> braunr: i'm not saying that this should be implemented right now, + i'm just pointing out this possibility + <braunr> i think we're all mostly aware of it + <slpz> braunr: resource accounting, as it's expressed in the critique, + would be wonderful, but it's just too complex IMHO + <braunr> it requires carefully designed changes to the interface yes + <slpz> to the interface, to the internals, to user space tasks... + <braunr> the internals wouldn't be impacted that much + <braunr> user space tasks would mostly include hurd servers + <braunr> if the changes are centralized in libraries, it should be easy to + provide to the servers + + +# IRC, freenode, #hurd, 2011-09-22 + + <slpz> antrik: I've also implemented a simple resource control on dirty + pages and changed pageout_scan to free external pages, and only touch + anonymous memory if it's really needed + <slpz> antrik: those combined make the system work better under heavy load + <slpz> antrik: 1.5 GB of RAM and another 1.5 GB of swap helps a lot, too + :-) + <antrik> hm... I'm not sure what these things mean exactly TBH... but I + wonder whether some of these could fix the performance degradation (and + ultimate crash) I described recently... + +[[/open_issues/default_pager]], [[system performance degradation +(?)|performance/degradation]]. + + <antrik> care to explain them to a noob like me? + <slpz> probably not. During my tests, I've noticed that, at some points, + the system performance starts to degrade, and this doesn't change until + it's restarted + <slpz> but I wasn't able to create a test case to reproduce the bug... + <slpz> antrik: Sure. First, I've changed GNU Mach to: + <slpz> - Classify all pages from data_supply as external, and count them + in vm_page_external_count (previously, this variable was always zero) + +[[/open_issues/mach_vm_pageout]] + + <slpz> - Count all pages for which a data_unlock has been requested as + potentially dirty pages + <antrik> there is one important bit I forgot to mention in my recent + report: one "reliable" way to cause growing swap usage is simply + installing a lot of debian packages (e.g. running an apt-get upgrade) + <antrik> some other kinds of I/O also seem to have such an effect, but I + wasn't able to pinpoint specific situations + <slpz> - Establish a limit on how many potentially dirty pages are + allowed. If it's reached, a notification (right now it's just a bogus + m_o_data_unlock, to avoid implementing a new RPC) it's sent to the pager + which has generated the page fault + <slpz> - Establish a hard limit on those dirt pages. If it's reached, + threads asking for a data_unlock are blocked until someone cleans some + pages. This should be improved with a forced pageout, if needed. + <slpz> - And finally, in vm_pageout_scan, run over the inactive queue + searching for clean, external pages, freeing them. If it's not possible + to free enough pages, or if vm_page_external_count is less than 10% of + system's memory, the "normal" pageout is used. + <slpz> I need to clean up things a little, but I want to send a preliminary + patch to bug-hurd ASAP, to have more people testing it. + <slpz> antrik: Do you thing that performance degradation can be related + with the number of threads of your ext2fs translators? + <antrik> slpz: hm... I didn't watch that recently; but in the past, I + observe that the thread count is pretty constant after it reaches + something like 14000 on heavy load... + <antrik> err... wait, 14000 was ports :-) + <antrik> I doubt my system would survive 14000 threads ;-) + <antrik> don't remember thread count... I guess I should start watching + this again + <slpz> antrik: I was thinking that 14000 threads sound like a lot :-) + <slpz> what I know for sure, is that when operating with large files, the + deactivation of all pages of the memory object which is done after every + operation really hurts to performance + <antrik> right now my root FS has 5100 ports and a mere 71 thread... but + then, it's almost freshly booted :-) + <slpz> that's why I've just commented that operation in my code, since it's + not really needed anymore :-) + <slpz> anyway, after submitting all my pending mails to bug-hurd, I'll try + to hunt that bug. Sounds funny. + <antrik> regarding your explanation, I'm still trying to wrap my head + around some of the details. I must admit that I don't remember what + data_unlock does... or maybe I never fully understood it + <antrik> the limit on dirty pages is global? + <slpz> yes, right now it's global + <marcusb> I try to find the old discussion of the thread storm stuff + <marcusb> there was some concern about deadlocks + <slpz> marcusb: yes, because we were talking about putting an static limit + for the server threads of a translators + <slpz> marcusb: and that was wrong (my fault, I was even dumber back then + :-P) + <marcusb> oh boy digging in old mail is no fun. first I see mistakes in my + english. then I see quite complicated pager stuff I don't ever remember + touching. but there is a patch, and it has my name on it + <marcusb> I think I lost a couple of the early years of my hurd hacking :) + <antrik> hm... I reread the chapter on locking, and it's still above me :-( + <marcusb> not sure what you are talking about, but if there are any + specific questions... + <antrik> marcusb: external pager interface + +[[microkernel/mach/external_pager_mechanism]]. + + <marcusb> uuuuh ;) + <antrik> memory_object_lock_request(), memory_object_lock_completed(), + memory_object_data_unlock() + <marcusb> is that from the mach manual? + <antrik> yes + <antrik> I didn't really understand that part when I first read it a couple + of years ago, and I still don't understand it now :-( + <marcusb> I am sure I didn't understand it either + <marcusb> and maybe I missed my window :) + <marcusb> let's see + <antrik> hehe + <antrik> slpz: what exactly do you mean by "the pager which has generated + the page fault"? + <antrik> marcusb: essentially I'm trying to understand the explanation of + the changes slpz did, but there are several bits totally obscure to me + :-( + <slpz> antrik: when a I/O operation is requested to ext2fs, it maps the + object in question to it's own space, and then memcpy's from/to there + <slpz> antrik: so the translator (which is also a pager) is the one who + generates the page fault + <marcusb> yeah + <marcusb> antrik: it's important to understand which messages are sent by + the kernel to the manager and which are sent the other way + <marcusb> if the dest port is memory_object_t, that indicates a msg from + kernel to manager. if it is memory_object_control_t, it's a msg from + manager to kernel + <slpz> antrik: m_o_lock_request it's used by the pager to "settle" the + status of a memory object, m_o_lock_completed is the answer from the + kernel when the lock has been completed (only if the client has requested + to be notified), and m_o_data_unlock is a request from the kernel to + change the level of protection for a page (it's called from vm_fault.c) + <marcusb> slpz: but it's not pagers generating page faults, but users of + the memory object on the other side + <antrik> marcusb: well, I think the direction is clear to me... but the + purpose not really :-) + <marcusb> ie a client that mapped a file + <slpz> antrik: in ext2fs, all pages are initially provided to the kernel + (via data_supply) write protected. When a write operation is done over + one of those pages, a page fault it's generated, which sends a + m_o_data_unlock to the pager, which answers (if convenient) which a + page_lock decreasing the protection level + <marcusb> antrik: one use of lock_request is when you want to shut down + cleanly and want to get the dirty pages written back to you from the + kernel. + <marcusb> antrik: the other thing may be COW strategies + <slpz> marcusb: well, pagers and clients are in the same task for most + translators, like ext2fs + <marcusb> slpz: oh. + <slpz> marcusb: but yes, a read operation in a mmap'ed file would trigger + the fault in a client user task + <marcusb> slpz: I think I forgot everything about pagers :) + <slpz> marcusb: pager-memcpy.c is the key :-) + <marcusb> slpz: what becomes of the fault then? the kernel sees it's a + mapped memory object. will it then talk to the manager or to a pager? + <antrik> slpz: the translator causes the faults itself when it handles + io_read()/io_write() requests I suppose, as opposed to clients accessing + mmap()ed objects which then generate the faults?... + <antrik> ah, that's actually what you already said above :-) + <slpz> marcusb: I'm not sure what do you mean by "manager"... + <marcusb> manager == memory object + <marcusb> mh + <slpz> marcusb: for all external objects, it will ask to their current + pager + <marcusb> slpz: I think I am missing a couple of details, so nevermind. + It's starting to come back to me, but I am a bit afraid of that ;) + <marcusb> what I love about the Hurd is how damn readable the code is + <marcusb> considering it's an object system, it's so much nicer to read + than gtk stuff + <slpz> when you get the big picture, it's actually somewhat fun to see how + data moves around just to fulfill a simple read() + <marcusb> you should make a diagram! + <marcusb> bonus point for animated video ;) + +[[hurd/IO_path]]. + + <slpz> marcusb: heh, take a look at the hurd specific parts of glibc... I + cry in pain every time a do that... + <marcusb> slpz: oh yeah, rdwr-internal. + <marcusb> oh man + <marcusb> slpz: funny thing, I just looked at them the other day because of + the security issue + <slpz> marcusb: I think there was one, maybe a slice from someone's + presentation... + <marcusb> I think I was always confused about the pager/memobj/kernel + interactions + <slpz> marcusb: I'm barely able to read Roland's glibc code. I think it's + out of my reach. + <antrik> marcusb: I think part of the problem is confusing terminology + <marcusb> it's good that you are instrumenting the mach kernel to see + what's actually going on in there. it was a black book for me, but neal + too a peek and got a much better understanding of the performance issues + than I ever did + <antrik> when talking about "pager", we usually mean the process doing the + paging; but in mach terminology this actually seems to be the "manager", + while a "pager" is an individual object in the manager process... or + something like that ;-) + <marcusb> antrik: I just never took a look at the big picture. I look at + the parts + <marcusb> I knew the tail, ears, and legs of the elephant. + <marcusb> it's a lot of code for a beginner + <antrik> I never understood the distinction between "pager" and "memory + object" though... + <antrik> maybe "pager" refers to the object in the external pager, while + "memory object" is the part managed in Mach itself?... + <marcusb> memory object is a real object, to which you can send messages. + it's implemented in the server + <antrik> hm... maybe it's the other way around then ;-) + <marcusb> there is also the default pager + <marcusb> I think the pager is just another name for the process that + serves the memory object (default pager == memory object for anonymous + memory == swap) + <marcusb> but! + <marcusb> there is also libpager + +[[hurd/libpager]] + + <marcusb> and that's a more complicated beast + <antrik> actually, the correct term seems to be "default memory manager"... + <marcusb> yeah + <marcusb> from mach's pov + <marcusb> we always called it default pager in the Hurd + <antrik> marcusb: problem is that "pager" is sometimes used in the Mach + documentation to refer to memory object ports IIRC + <marcusb> isn't it defpager executable? + <marcusb> could be + <marcusb> it's the same thing, really + <antrik> indeed, the program implementing the default memory manager is + called "default pager"... so the terminology is really inconsistent + <marcusb> the hurd's pager library is a high level abstraction for mach's + external memory object interface. + <marcusb> i wouldn't worry about it too much + <antrik> I never looked at libpager + <marcusb> you should! + <marcusb> it's an important beast + <antrik> never seemed relevant to anything I did so far... + <antrik> though maybe it would help understanding + <marcusb> it's related to what you are looking now :) diff --git a/unsorted/ZallocPanics.mdwn b/open_issues/resource_management_problems/zalloc_panics.mdwn index 0b00d7ec..9c29b07c 100644 --- a/unsorted/ZallocPanics.mdwn +++ b/open_issues/resource_management_problems/zalloc_panics.mdwn @@ -1,3 +1,18 @@ +[[!meta copyright="Copyright © 2005, 2007, 2008, 2010, 2012 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +Written by antrik / Olaf Buddenhagen, last updated: 12 Apr 2007. + The Hurd sometimes crashes with a kernel panic saying someting like: "Panic: zalloc failed: zone map exhausted". These panics are generally caused by some kind of kernel resource exhaustion, but there are several differnt reasons for that. @@ -40,4 +55,45 @@ I started various other experiments with creating child processes (fork bombs), While most of these Observations clearly show an exhaustion of kernel memory which is not surprising, some of the oddities seem to indicate problems that might deserve further investigation. --- antrik (Last update: 12 Apr 2007) + +# IRC, freenode, #hurd, 2012-04-01 + + <mel__> antrik: i just found + http://www.gnu.org/software/hurd/open_issues/resource_management_problems/zalloc_panics.html + -- that is from 2007. is this still the current status? + <youpi> mel__: probably + <mcsim> mel__: gnumach has no more zalloc allocator, so I doubt if it could + be a problem. + +[[gnumach_memory_management]]. + + <youpi> mcsim: but it still has an allocator + <youpi> which can run out of resources + <mcsim> AFAIR, now there is no such limit. + <youpi> err, there is + <youpi> the size of your RAM :) + <mcsim> In zalloc appearing of this message didn't depend of available size + of free ram. + <youpi> then update the description, but I'm still getting allocation + errors, when userland makes crazy things like creating millions of tasks + <mcsim> At least it could appear when there still was free memory + <youpi> and that's not surprising + <youpi> sure, I know that *some* limits have been removed, but there + weren't so many, and I have seen cases where it's simply mach running out + of memory + <youpi> also, we have a limited amount of virtual addressing space + <antrik> mel__: this writeup is outdated in several regards. *some* of the + observations might still be relevant, but nothing that seems + particularily important + <antrik> the zalloc panics have pretty much disappeared after the default + zalloc zone size has been considerably extended (which was not possible + before because of some bug) + <mel__> i see + <antrik> but as mcsim pointed out, with the new allocator not relying on a + fixed-sized zalloc zone at all, they are even less likely, and should + happen only if all memory is exhausted + <antrik> I guess this outdated report can just be dropped + <mcsim> I think, that now it is problem rather of absence of OOM-killer or + resource manager + <antrik> mcsim: right :-) + <antrik> (and we have separate articles about that) diff --git a/open_issues/rework_gnumach_ipc_spaces.mdwn b/open_issues/rework_gnumach_ipc_spaces.mdwn new file mode 100644 index 00000000..7c66776b --- /dev/null +++ b/open_issues/rework_gnumach_ipc_spaces.mdwn @@ -0,0 +1,723 @@ +[[!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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-05-07 + + <braunr> things that are referred to as "system calls" in glibc are + actually RPCs to the kernel or other tasks, those RPCs have too lookup + port rights + <braunr> the main services have tens of thousands of ports, looking up one + is slow + +There is a [[!FF_project 268]][[!tag bounty]] on this task. + + +# IRC, freenode, #hurd, 2011-04-23 + + <braunr> youpi: is there any use of the port renaming facility ? + <youpi> I don't know + <braunr> at least, did you see such use ? + <braunr> i wonder why mach mach_port_insert_right() lets the caller specify + the port name + <youpi> ../hurd-debian/hurd/serverboot/default_pager.c: kr = + mach_port_rename( default_pager_self, + <braunr> mach_port_rename() is used only once, in the default pager + <braunr> so it's not that important + <braunr> but mach_port_insert_right() lets userspace task decide the port + name value + <youpi> just to repeat myself again, I don't know port stuff very much :) + <braunr> well you know that a port denotes a right, which denotes a port + <youpi> yes, but I don't have any real experience with it + <braunr> err + <braunr> port name + <braunr> the only reason I see is that the caller, say /hurd/exec running a + fork() + <braunr> hm + <braunr> no, i don't even see the reason here + <braunr> port names should be allocated by the kernel only, like file + descriptors + <youpi> you can choose file descriptor values too + <braunr> really ? + <youpi> with dup2, yes + <braunr> oh + <braunr> hm + <braunr> what's the data structure in current unices to store file + descriptors ? + <braunr> a hash table ? + <youpi> I don't know + <braunr> i'll have to look at that + <braunr> FYI, i'm asking these questions because i'm thinking of reworking + ipc spaces + <braunr> i believe the use of splay trees completely destroys performance + of tasks with many many port names such as the root file system + <youpi> that can be a problem yes + <youpi> since there are 3 ports per opened file, and like 3 per thread too + <braunr> + the page cache + <youpi> with a few thousand opened files and threads, that makes a lot + <youpi> by "opened file" I meant page cache actually + <braunr> i saw numbers up to 30k + <braunr> ok + <youpi> on buildds I easily see 100k ports + <braunr> for a single task ? + <braunr> wow + <youpi> yes + <youpi> the page cache is 4k files + <braunr> so that's definitely worth the try + <youpi> so that already makes 12k ports + <youpi> and 4k is not so big + <braunr> it's limited to 4K ? + <youpi> I haven't been able to check where the 100k come from yet + <youpi> braunr: yas + <braunr> could be leaks :/ + <youpi> yes + <braunr> omg, a hard limit on the page cache .. + <youpi> vm/vm_object.c:int vm_object_cached_max = 4000; /* may + be patched*/ + <braunr> mach is really old :( + <youpi> I've raised it + <youpi> before it was 200 + <youpi> ... + <braunr> oO + <youpi> I tried to dro pthe limit, but then I was lacking memory + <youpi> which I believe have fixed the other day, but I have to test again + <braunr> that implementation doesn't know how to deal with memory pressure + <youpi> yes + <braunr> i saw your recent changes about adding warnings in such cases + <braunr> so, back to ipc spaces + <braunr> i think splay trees 1/ can get very unbalanced easily + <braunr> which isn't hard to imagine + <braunr> and 2/ make poor usage of the cpu caches because they're BST and + write a lot to memory + <youpi> maybe you could write a patch which would dump statistics on that? + <braunr> that's part of the job i'm assigning to myself + <youpi> ok + <braunr> i'd like to try replacing splay trees with radix trees + <youpi> I can run it on the buildds + <youpi> buildds are very good stress-tests :) + <braunr> :) + <youpi> 22h building -> 77k ports + <youpi> 26h building -> 97k ports + <youpi> the problem is that when I add leak debugging (backtraces), I'm + getting out of memory :) + <braunr> that will be a small summer of code outside the gsoc :p + <braunr> :/ + <braunr> backtraces are very consuming + <youpi> but that's only because of hardcoded limits + <youpi> I'll have to test again with bigger limits + <braunr> again .. + <braunr> evil hard limits + <youpi> well, actually we could as well just drop them + <youpi> but we'd also need to easily get statistics on zone/vm_maps usage + <youpi> because else we don't see leaks + <youpi> (except that the machine eventually crashes) + <braunr> hm + <braunr> i haven't explained why i was asking my questions actually + <braunr> so, i want radix trees, because they're nice + <braunr> they reduce the paths lengths + <braunr> they don't get too unbalanced (they're invariant wrt the order of + operations) + <braunr> they don't need to write to memory on lookups + <braunr> the only drawback is that they can create much overhead if their + usage pattern isn't appropriate + <braunr> elements in such a structure should be close, so that they share + common nodes + <youpi> the common usage pattern in ext2fs is a big bunch of ever-open + ports :) + <braunr> if there is one entry per node, it's a big waste + <braunr> yes + <youpi> there are 3, actually + <braunr> but the port names have low values + <braunr> they're allocated sequentially, beginning at 0 + <braunr> (or 1 actually) + <braunr> which is perfect for radix trees + <youpi> yes + <youpi> 97989: send + <braunr> but if anyone can rename + <braunr> this introduces a new potential weakness + <youpi> ah, if it's just a weakness it's probably not a problem + <youpi> I thought it was even a no-go + <braunr> i think so + <youpi> I guess port rename is very seldom + <braunr> but in a future version, it would be nice not to allow port + renaming + <braunr> unless there are similar issues in current unix kernels + <braunr> in which case i'd say it's acceptable + <youpi> there are + <braunr> of that order ? + <youpi> and it'd be useful for e.g. processing + tracing/debugging/tweaking/whatever + <youpi> it's also used to hide fds from a process + <braunr> port renaming you mean ? + <youpi> you allocate them very high + <youpi> yes + <braunr> ok + <youpi> choosing your port name, generally + <youpi> to match what the process expects for instance + <braunr> then it would be a matter of resource limiting (which we totally + lack afaik) + <braunr> along the number of maximum open files, you would have a number of + maximum rights + <braunr> does that seem fine to you ? + <youpi> if done throught rlimits, sure + <braunr> something similar yes + <youpi> (_no_ PORTS_MAX ;) ) + <braunr> oh and, in addition, i remember gnumach has a special + configuration of the processor in which caching is limited + <braunr> like write-through only + <youpi> didn't I fix that recently ? + <braunr> i don't know :) + <braunr> CR0=e001003b + <braunr> i don't think it's fixed + <youpi> I mean, in the git + <braunr> ah + <youpi> not in the debian package + <braunr> didn't tried the git version yet + <braunr> last time i tried (which was a long time ago), it made the kernel + crash + <braunr> have you figured why ? + <youpi> I'm not aware of that + <braunr> anyway, splay trees write a lot, and most trees write a lot even + at insertion/removal to rebalance + <youpi> braunr: Mmm, there's no clearance of CD in the kernel actually + <braunr> with radix trees, even if caching can't be fully enabled, it would + make much better use of it + <braunr> so if port renaming isn't a true issue, i'll choose that data + structure + <youpi> that'd probably be better yes + <youpi> I'm surprised by the CD, I do remember fixing something like this + lately + <braunr> there are several levels where CD can be set + <braunr> the processors ORs all those if i'm right + <braunr> to determine if caching is enabled + <youpi> I know + <braunr> ok + <youpi> but in my memory that was at the CR* level, precisely + <braunr> maybe for xen only ? + <youpi> no + <braunr> well good luck if you hunt that one, i'm off, see you :) + <youpi> braunr: ah, no, it was the PGE flag that I had fixed + + <antrik> braunr: explicit port naming is used for example to pass some + initial ports to a new task at well-known places IIRC + <antrik> braunr: but these tend to be low numbers, so I don't see a problem + there + <antrik> (I'm not familiar with radix trees... why would high numbers be a + problem?) + + <youpi> braunr: iirc the ipc space is limited to ~192k ports + + <braunr> antrik: in most cases i've seen, the insert_right() call is used + on task_self() + <braunr> and if there really are special ports (like the bootstrap or + device ports), they should have special names + <braunr> IIRC, these ports are given through command line expansion by the + kernel at boot time + <braunr> but it seems reasonable to think of port renaming as a potentially + useful feature + <braunr> antrik: the problem with radix trees isn't them being high, it's + them being sparse + <braunr> you get the most efficient trees when entries have keys that are + close to each other + <braunr> because radix trees are a type of tries (the path in the tree is + based on the elements composing the key) + <braunr> so the more common prefixes you have, the less external nodes you + need + <braunr> here, keys are port names, but they can be memory addresses or + offsets in memory objects (like in the page cache) + <braunr> the radix algorithm takes a few bits, say 4 or 6, at a time from a + key, and uses that as an index in a node + <braunr> if keys are sparse, there can be as little as one entry per node + <braunr> IIRC, the worst case (on entry per node with the maximum possible + number of nodes for a 32-bits key) is 2% entries + <braunr> the reste being null entries and almost-empty nodes containing + them + <braunr> so if you leave the ability to give port rights the names you + want, you can create such worst case trees + <braunr> which may consume several MiB of memory per tree + <braunr> tens of MiB i'd say + <braunr> on the other hand, in the current state, almost all hurd + applications use sequentially allocated port names, close to 0 (which + allows a nice optimization) + <braunr> so a radix ree would be the most efficient + <antrik> well, if some processes really feel they must use random numbers + for port names, they *ought* to be penalized ;-) + + +# IRC, freenode, #hurd, 2011-04-27 + + <braunr> antrik: remember when you asked why high numbers would be a + problem with radix trees ? + <braunr> here is a radix tree with one entry, which key is around 5000 + <braunr> [ 656.296412] tree height: 3 + <braunr> [ 656.296412] index: 0, level: 0, height: 3, count: 1, + bitmap: 0000000000000002 + <braunr> [ 656.296412] index: 1, level: 1, height: 2, count: 1, + bitmap: 0000000000004000 + <braunr> [ 656.296412] index: 14, level: 2, height: 1, count: 1, + bitmap: 0000000000000080 + <braunr> three levels, each with an external node (dynamically allocated), + for one entry + <braunr> so in the worst case of entries with keys close to the highest + values, the could be many external nodes with higher paths lengths than + when keys are close to 0 + <braunr> which also brings the problem of port name allocation + <braunr> can someone with access to a buildd which has an uptime of at + least a few days (and did at least one build) show me the output of + portinfo 3 | tail ? + <braunr> port names are allocated linearly IIRC, like PIDs, and some parts + of the kernel may rely on them not being reused often + <braunr> but for maximum effifiency, they should be + <braunr> efficiency* + <braunr> 00:00 < braunr> can someone with access to a buildd which has an + uptime of at least a few days (and did at least one build) show me the + output of portinfo 3 | tail ? + <braunr> :) + <youpi> it's almost like wc -l + <youpi> 4905: receive + <youpi> vs 4647 + <youpi> for / + <youpi> 52902: receive + <youpi> vs 52207 + <youpi> for the chroot + <braunr> even after several builds ? + <braunr> and several days ? + <youpi> that's after 2 days + <youpi> it's not so many builds + <youpi> rossini is not so old + <youpi> (7h) + <youpi> but many builds + <youpi> 70927: send + <youpi> vs 70938 + <braunr> ok + <braunr> so it seems port names are reused + <braunr> good + <youpi> yes they are clearly + <braunr> i think i remember a comment about why the same port name + shouldn't be reused too soon + <youpi> well, it could help catching programming errors + <braunr> that it helped catch bugs in applications that could + deallocate/reallote quickly + <braunr> reallocate* + <braunr> without carefuly synchronization + <braunr> careful + <braunr> damn, i'm tired :/ + <youpi> but that's about debugging + <youpi> so we don't care about performance there + <braunr> yes + <braunr> i'll try to improve allocation performance too + <braunr> using e.g. bitmaps in each external node back to the root so that + unused slots are quickly found + <braunr> i thknk that's what idr does in linux + <antrik> braunr: idr? + <braunr> antrik: a data structure used to map integers to pointers + <braunr> http://fxr.watson.org/fxr/source/lib/idr.c?v=linux-2.6 + + +# IRC, freenode, #hurd, 2011-06-08 + + <braunr> hm, reverse space/port to name lookups also suck + <braunr> having separate types for simple ipc entries and splay tree + entries really makes many parts of the ipc code complicated + <braunr> and a global hash table for these operations is scary + + +# IRC, freenode, #hurd, 2011-06-09 + + <braunr> hm nice, my radix tree code runs inside gnumach, along with the + original splay tree code and assertions making sure results are the same + <braunr> there is this "collision" thing i'm not sure to understand but + once this is solved, replacing the splay trees should be easy + + <braunr> youpi: is there a way to easily know the number of send rights + associated to a port ? + <youpi> portinfo ? + <braunr> portinfo gives information in a space + <braunr> but this is specific to a port + <braunr> is there an option for that ? + <youpi> -v + <braunr> hm ok + <youpi> 25: send (refs: 550) + <braunr> nice + <braunr> youpi: if you have time, could you give me the min/max/avg numbers + of send rights referring to the same port on buildds ? + <braunr> i'm trying to estimate if it's better to have space->list_of_ports + or port->list_of_spaces to replace the global ipc hash table + <braunr> the latter seems better but there could be unexpected cases on + machines using large amounts of resources like the buildds + <youpi> max is 64k + <youpi> min is 1 of course :) + <braunr> 64k + <braunr> then it's not what i'm looking for + <youpi> avg is 55 + <braunr> isn't this the number of urefs ? + <youpi> I don't know + <braunr> hmm + <braunr> what i'm looking for is the number of *pure send rights* for the + same port + <braunr> i don't think portinfo can give it + <braunr> there can only be one such send right per task for the same port + <braunr> 64k would mean there are 64k tasks + <youpi> ok, so it's more difficult + <youpi> it means using -t + <braunr> ahh + <youpi> and run n^2 portinfo over the n processes + <braunr> i see + <youpi> Mmm, that will however still show any duplicate send right + <youpi> but then by min/max/avg, you mean, over time ? + <braunr> i'll change the source code, simpler + <youpi> e.g. min would be right after boot? + <braunr> min is 1 + <youpi> 1 what ? + <braunr> 1 send right to a port + <youpi> ah, 1 for a given port + <braunr> yes + <youpi> ok, it becomes really hairy to compute, I don't hav ethe time :) + <braunr> avg and max are more interesting :) + <braunr> no worries + <youpi> braunr: I wouldn't be surprised that max is the number of tasks + <youpi> e.g. for a send port to the proc server for instance + <braunr> youpi: it is, but i'm not looking for potential numbers + <youpi> I'm not talking about a potential number, but an actual number + that's almost always true + <braunr> for one port, yes + <braunr> but yes, ok for max + <braunr> this makes choosing an appropriate data structure difficult + + <antrik> braunr: actually, min number of send rights to a port is 0... but + I'm sure you know that already :-) + + <antrik> youpi: normally each client gets a separate port. I'm not sure + there are any ports with send rights distributed over many tasks... + + <jkoenig> antrik, what about / ? + + <youpi> antrik: not necessarily + + <antrik> jkoenig: not sure... isn't the "/" port authenticated to the + specific user? + + <jkoenig> antrik, I guess so, but a single user could still have many + tasks. + <jkoenig> (wrt /) + <antrik> jkoenig: well, in theory the tasks having exactly the same UIDs + and GITs could probably share an auth token... but that's not how things + are handled in general + <antrik> at least I don't think so + <antrik> tasks are authenticated, not users + <antrik> err... GIDs :-) + <jkoenig> antrik, still, my quick glance to the fork() code seemed to + indicate the port is inherited as-is, maybe authentication happens only + when something is actually looked up? + <jkoenig> hmm "rpctrace ls -d /" does not show any authentication calls, + only a lookup("") on the root which returns a different port + <jkoenig> so I guess the root port is "deauthenticated" or something when + the uid of a process is changed. + <antrik> too bad cfhammer isn't around, he digged into all this stuff... + <antrik> I know that there is a mechanism which reauths all FDs when the + IDs of a process change + <antrik> but I'm not sure the "/" port uses this mechanism + + <braunr> antrik: but the radix tree codee is really used as is, which means + no locking, no preloading before locking, all of this because simple + locks don't exist on UP, and because the kernel isn't preemptible + + <braunr> antrik: and yes, min number is 0, but in that case you don't need + (space, port) -> right lookups :) + <braunr> antrik: or put in another way, whichever reasonable structure you + use, when it's empty, you don't care much + <braunr> which also means that the min number has actually no value here + <braunr> because the same applies to 1 + + <braunr> then what seems to take most time is forks + <braunr> and i hope my upcoming kernel changes will help the situation a + bit + <pinotree> what are your incoming gnumach changes about? + <braunr> the ipc translation layer speed + <braunr> which basically means operating on port names (looking them up, + inserting, removing, renaming, looking up send rights to a specific + ports) will be faster + <braunr> and i believe forks are (one of) the most demanding use cases wrt + ipc space manipulation + <braunr> i'm really surprised how badly the splay trees are used + <braunr> the worst case for this data structure is traversal + <braunr> and this is done in many situations + <braunr> leaving the tree in its worst case shape + <braunr> and i didn't mentioned the bunch of memory writes occurring, event + for things like lookups or traversals + <braunr> this is slow and can disrupt many cpu cache lines + <braunr> and when there are 10k to 100+k (e.g. in some ext2fs instances on + buildds), just imagine the number of operations involved in those + operations + <braunr> a simple traversal_next involves a rotation *gasp* + <braunr> this means potentially writing on 3 different cache lines, for + *one* next operation + <pinotree> what are you replacing that splay tree with? + <braunr> radix trees + <braunr> much shorter paths + <braunr> extremely few memory writes + <braunr> locality of reference when traversing + <braunr> good cache usage (as many of the top nodes are reused) + <braunr> the two drawbacks are 1/ memory allocation for external nodes, + which means the tree must be preloaded before locking + <braunr> and 2/ high memory overhead if the keys are sparse + <braunr> but this isn't the case with port names, unless someone messes it + up by assigning random names to many rights + + <antrik> braunr: so, when will we see the first performance comparision? + :-) + <braunr> antrik: that's a topic of itself, how to compare ? + <braunr> antrik: the thing is, my current gnumach patches only makes + assertions + <braunr> this is the best way i found to test my tree in real life + conditions + <braunr> much cleanup is needed + <braunr> and what i'd like to do is to completely replace all teh + translation layer structures with it + <braunr> which means removing much code, making sure it still works as + expected + <braunr> this is tedious + <braunr> so one month at least + <antrik> braunr: comparing shouldn't be too hard... the average configure + script does a lot of forking, which should be a good benchmark according + to your observations + <braunr> rough estimates are easy, yes + <braunr> but my observations my be wrong :p + <antrik> braunr: well, we don't really need precise numbers... + <antrik> unless you need to do some kind of fine-tuning? + <braunr> i don't know yet + + +# IRC, freenode, #hurd, 2011-06-18 + + < braunr> hmm, i'm having a problem with integrating my radix tree code in + gnumach + < braunr> inserting into such a tree can trigger memory allocation + < braunr> so commonly, the tree i loaded with nodes before insertion, + usually if it requires strong locking + < braunr> ipc spaces are locked using "simple locks" (which are spin locks) + < braunr> but spin locks are noops on UP, and gnumach is always UP .. + < braunr> so, should i still include preloading code, even if it'll end up + dead code ? + < antrik> hm... I think we discussed this before; but isn't gnumach + supposed to be SMP-capable, minus bugs?... + < braunr> it is + < braunr> but ofc, if i choose not to include preloading, i'll write + #errors so that the day gnumach is built for SMP again, such support will + be included + < antrik> oh, sorry, I think I misread. what is UP? + < braunr> uniprocessor + < antrik> well, if it's just bugs forcing the current UP state, I think + saying that gnumach is always UP is a stretch... + < braunr> sure, but it's a practical consideration + < antrik> does the locking complicate stuff? or is it just performance + considerations? + < braunr> no it's about correctness and completeness + < braunr> if you don't preload a tree before locking + < braunr> and memory allocation occurs while you're holding a simple lock + < braunr> and memory allocation requires the kernel to sleep + < braunr> you're screwed + < braunr> but i hate the idea of including code that won't be used and + which won't be easy to test + < braunr> so i'm wondering if it's ok for now to just put this in a TODO + comment and write it when the time is right + < braunr> or if i should spens the week adding this and tweaking the + userspace implementation to "emulate" spin locks + < antrik> well, it's tricky situation. on one hand, it seems stupid to + include handling for something that presently isn't used, and it's not + clear when it will. on the other hand, I'd rather not see additional + problems introduced that will make fixing SMP even harder... + < braunr> that's why i'm asking here + < antrik> of course, you could resolve this question by fixing SMP + first... ;-) + < braunr> ew + < antrik> well, I guess it would be best first to make the code work... and + we can still decide about the locking thing before it goes mainline I'd + say? + < braunr> "make the code work" ? + < antrik> I mean make gnumach work with your radix tree code + < braunr> without preloading then + < antrik> yeah... as a first step... I guess adding it later won't be any + harder than adding it right now? + < braunr> not much + < braunr> testing is what requires time really + + +# IRC, freenode, #hurd, 2011-06-27 + + < braunr> ok, here is the radix tree code: + http://git.sceen.net/rbraun/libbraunr.git/ + < braunr> the preloading stuff will be added in the kernel only, as it's + really pointless and not easily doable in userspace + < youpi> preloading? + < braunr> youpi: yes, preloading + < braunr> radix trees allocate external nodes + < youpi> well, providing a url at some random time of some random day is + not a great way to get eyes on it :) + < braunr> and ipc spaces are locked when inserting/allocating names + < braunr> we normally don't need preloading in gnumach + < braunr> since there is no preemption nor SMP + < braunr> but in case someone changes that, i'd like the code to be mostly + ready + < braunr> and correctly handle those ugly simple locks + < braunr> youpi: is what i say clear enough or do you need more background + on what is done ? + < youpi> about preloading? + < braunr> yes + < youpi> I guess it means allocating nodes in advance? + < braunr> yes + < youpi> k + < braunr> before locking the ipc spaces + + +# IRC, freenode, #hurd, 2011-06-28 + + < braunr> antrik: i think i won't write the code for the preloading stuff + actually + < braunr> antrik: it's not very difficult, but i really hate the idea of + not being able to reliably test it + < braunr> antrik: and i'd rather concentrate on integrating the radix tree + code in gnu mach now + < braunr> (i've already removed much code, even some files which weren't + actually used before my changes !) + < braunr> hmm, i won't be able not to write the preloading code after all + < antrik> braunr: not able not to write? how's that? + < braunr> antrik: it's actually required + < braunr> there are three functions, ipc_entry_get, ipc_entry_alloc, and + ipc_entry_grow_table + < braunr> ipc_entry_get cannot allocate memory + < braunr> if it fails, ipc_entry_grow_table is called, which will allocate + memory + < braunr> ipc_entry_alloc calls both of them depending on the result of + ipc_entry_get + < braunr> this is the equivalent of the preloading thing i had in mind + < braunr> not a bad thing after all + < braunr> the only thing i'm afraid of are the "optimized" version of those + ipc functions in te so-called fast paths + < braunr> i'm afraid if i don't deal right with those, the kernel may end + up using mostly slow paths + < braunr> but considering the purpose of those fast paths was merely to + avoid the overhead of function calls and some locking functions, it + shouldn't be that bad + < braunr> this is such a mess eh + < antrik> hurray microoptimisations ;-) + < braunr> there, the preload functions are done, easy :) + < antrik> braunr: seems you spent less time implementing it than pondering + whether you should implement it ;-) + < braunr> well, i couldn't implement it correctly before knowing what + should have been done exactly + < braunr> and there are still other problems :/ + < braunr> and the other problems make me reconsider if this was useful at + all eh + < braunr> youpi: i'm unable to find where ipc tree entries are released + except in ipc_entry_alloc_name(), which could mean they're leaked ... + < braunr> youpi: would you have time to take a look ? + < youpi> they aren't in ipc_entry_dealloc() ? + < braunr> no ..... + < youpi> it's not so unprobable that they're only freed when the task quits + < braunr> i don't see that either + < braunr> i only see them released in ipc_entry_alloc_name() + < braunr> so maybe they're reused + < braunr> but i'm not sure about that when reading the code + < braunr> oh wait, yes, they are :/ + < braunr> my bad + < youpi> in the ipc_splay_tree_* fucntions I guess? + < braunr> yes + < braunr> it's just surprsing to see them allocated outside the tree code + only + < braunr> but released in both the entry and the splay tree code ... + + +# IRC, freenode, #hurd, 2011-06-29 + + < braunr> hmm i missed an important thing :/ + < braunr> and it's scary + < braunr> it looks like the splay tree is mainly used when names are + provided + < braunr> whereas the entry table is used when names are allocated + < braunr> which means the table is the main ipc data structure, even for + tasks with lots of rights + < braunr> i can make my root ext2fs have more than 10k rights, and i see + the ipc table table grow along that number ... + < braunr> now thetable has 15k+ entries + < braunr> IOW there is no point to put the radix tree code in gnumach :( + < antrik> braunr: what do you mean by "provided" and "allocated"? + < antrik> and what is that table you are talking about? + < braunr> antrik: provided means the user space tasks gives the name of the + new right + < braunr> antrik: allocated means the kernel generates it + < braunr> antrik: the table i'm talking about is is_table in struct + ipc_space + < braunr> 55 * Every space has a non-NULL is_table with + is_table_size entries. + < braunr> 56 * A space may have a NULL is_tree. is_tree_small + records the + < braunr> 57 * number of entries in the tree that, if the table were + to grow + < braunr> 58 * to the next larger size, would move from the tree to + the table. + < braunr> here is the description which mislead me (in addition of the + obscure code) + < braunr> 50 * Spaces hold capabilities for ipc_object_t's (ports + and port sets). + < braunr> 51 * Each ipc_entry_t records a capability. Most + capabilities have + < braunr> 52 * small names, and the entries are elements of a table. + < braunr> 53 * Capabilities can have large names, and a splay tree + holds + < braunr> 54 * those entries. The cutoff point between the table + and the tree + < braunr> 55 * is adjusted dynamically to minimize memory + consumption. + < antrik> ah, so the rights with a low name are in a linear table, and only + those with "random" high names are stored in the splay tree instead? + < antrik> seems a rather complex design... I guess though there isn't much + room for further optimisation there :-( + < antrik> (well, except for code size optimisation -- which could in fact + make a considerable difference...) + < braunr> well there are problems with this approach, but most don't + concern performance + < braunr> when the table gets big (close to the page size or more), it gets + remapped when reallocated + < braunr> which will incur some penalty because of the tlb + < braunr> but it's annoying even for small tables + < braunr> the initial table size is 4 entries, and from what i can see, + most tables are 128 entries wide when tasks are destroyed + < braunr> an obvious simple optimization is to set a larger default size + < braunr> the same applies for the dead name tables + < braunr> those reallocations are a pain, and they're due to this design + < braunr> they can also fail because of fragmentation + < braunr> there would be a point to radix trees if they would replace all + that, and not just the splay tree + < braunr> but this would cause a lot of changes in a lot of places, and in + particular the "optimized" fast paths i mentioned yesterday + < braunr> we'll see how they perform in x15 :> + < braunr> there is a slight noticeable improvement when increasing the + initial size of the entry table + < antrik> braunr: well, if you use them in a completely different + implementation, there will be no way of telling whether they make a + difference + < antrik> how did you test the improvement? + < braunr> antrik: no actually it's completely negligeable + < braunr> hm + < braunr> is that a valid word ? :) + < braunr> negligible + < braunr> youpi: did you see my comments about the ipc stuff this earlier + today ? + < braunr> youpi: well to make things short, when port names are allocated, + the right they refer to is allocated from the ipc table + < braunr> youpi: the splay tree is only used for user provided names + < braunr> youpi: i had tables as large as the number of rights in a space + (i could easily reach 20k) + < braunr> youpi: whereas the splay trees had at most ~40 entries .. diff --git a/open_issues/rm_fr.mdwn b/open_issues/rm_fr.mdwn new file mode 100644 index 00000000..aab52d97 --- /dev/null +++ b/open_issues/rm_fr.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_hurd]] + +From: Samuel Thibault <samuel.thibault@gnu.org> +Subject: rm -fr slowness + +I have always been surprised by the slowness of a mere rm -fr. Looking a +bit inside, I see that diskfs_dirremove_hard() calls diskfs_file_update +(dp, 1) (as does diskfs_truncate, diskfs_direnter_hard, and +diskfs_dirrewrite_hard). diskfs_file_update then calls pager_sync on +the pager, which thus writes back the whole ext2fs pager! + +This sounds a bit excessive to me, an unlink could just record it in +memory and actually sync later. Also, the wait flag is set, so we +really waits for all I/Os, which basically means strictly serializing +file removals: remove one file, wait for the disk to have done it +(~10ms), remove the next one, etc. I guess this is for safety reasons +against crashes, but isn't the sync option there for such kind of + + +# IRC, freenode, #hurd, 2011-07-23 + + <antrik> youpi: hm... async deletion does have one downside: I just removed + something to make space, and retried the other command immediately + afterwards, and it still said "no space left on device"... a few seconds + later (after the next regular sync I suppose?) it worked + <youpi> well, that's sorta expected, yes + <youpi> we get the same on Linux + <youpi> Mmm, on second thought, I'm not sure how that can happen + <youpi> the asynchronous thing is for disk writes, not cache writes diff --git a/open_issues/robustness.mdwn b/open_issues/robustness.mdwn new file mode 100644 index 00000000..d32bd509 --- /dev/null +++ b/open_issues/robustness.mdwn @@ -0,0 +1,64 @@ +[[!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 open_issue_hurd]] + + +# IRC, freenode, #hurd, 2011-11-18 + + <nocturnal> I'm learning about GNU Hurd and was speculating with a friend + who is also a computer enthusiast. I would like to know if Hurds + microkernel can recover services should they crash? and if it can, does + that recovery code exist in multiple services or just one core kernel + service? + <braunr> nocturnal: you should read about passive translators + <braunr> basically, there is no dedicated service to restore crashed + servers + <etenil> Hi everyone! + <braunr> services can crash and be restarted, but persistence support is + limited, and rather per serivce + <braunr> actually persistence is more a side effect than a designed thing + <braunr> etenil: hello + <etenil> braunr: translators can also be spawned on an ad-hoc basis, for + instance when accessing a particular file, no? + <braunr> that's what being passive, for a translator, means + <etenil> ah yeah I thought so :) + + +# IRC, freenode, #hurd, 2011-11-19 + + <chromaticwt> will hurd ever have the equivalent of a rs server?, is that + even possible with hurd? + <youpi> chromaticwt: what is an rs server ? + <chromaticwt> a reincarnation server + <youpi> ah, like minix. Well, the main ground issue is restoring existing + information, such as pids of processes, etc. + <youpi> I don't know how minix manages it + <antrik> chromaticwt: I have a vision of a session manager that could also + take care of reincarnation... but then, knowing myself, I'll probably + never imlement it + <youpi> we do get proc crashes from times to times + <youpi> it'd be cool to see the system heal itself :) + <braunr> i need a better description of reincarnation + <braunr> i didn't think it would make core servers like proc able to get + resurrected in a safe way + <antrik> depends on how it is implemented + <antrik> I don't know much about Minix, but I suspect they can recover most + core servers + <antrik> essentially, the condition is to make all precious state be + constantly serialised, and held by some third party, so the reincarnated + server could restore it + <braunr> should it work across reboots ? + <antrik> I haven't thought about the details of implementing it for each + core server; but proc should be doable I guess... it's not necessary for + the system to operate, just for various UNIX mechanisms + <antrik> well, I'm not aware of the Minix implementation working across + reboots. the one I have in mind based on a generic session management + infrastructure should though :-) diff --git a/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn b/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn new file mode 100644 index 00000000..9db92250 --- /dev/null +++ b/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn @@ -0,0 +1,163 @@ +[[!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]] + +[RPC to self with rendez-vous leading to duplicate port +destroy](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00045.html) + +IRC, freenode, #hurd, 2011-03-14 + + <antrik> youpi: I wonder, why does the root FS call diskfs_S_dir_lookup() + at all?... + <youpi> errr, because a client asked for it? + <youpi> (problem with RPCs is you can't easily know where they come from :) + ) + <youpi> (especially when it's the root fs...) + <antrik> ah, it's about a client request... didn't see that + <youpi> well, I just said "is called", yes + <antrik> I do not really understand though why it tries to reauthenticate + against itself... + <antrik> I fear my memory of the lookup mechanism grew a bit dim + <youpi> see the source + <youpi> it's about a translated entry + <antrik> (and I never fully understood some aspects anyways...) + <youpi> it needs to start the translated entry as another user, possibly + <antrik> yes, but a translated entry normally would be served by *another* + process?... + <youpi> sure, but ext2fs has to prepare it + <youpi> thus reauthenticate to prepare the correct set of rights + <antrik> prepare what? + <youpi> rights + <youpi> so the process is not root, doesn't have / opened as root, etc. + <antrik> rights for what? + <youpi> err, about everything + <antrik> IIRC the reauthentication is done by the parent FS on the port to + the *translated* node + <antrik> and the translated node should be a different process?... + <youpi> that's not what I read in the source + <youpi> fshelp_fetch_root + <youpi> ports[INIT_PORT_CRDIR] = reauth (getcrdir ()); + <youpi> here, getcrdir() returns ext2fs itself + <antrik> well, perhaps the issue is that I have no idea what + fshelp_fetch_root() does, nor why it is called here... + <youpi> it notably starts the translator that dir_lookup is looking at, if + needed + <youpi> possibly as a different user, thus reauthentication of CRDIR + <antrik> so this is about a port that is passed to the translator being + started? + <youpi> no + <youpi> well, depends on what you mean by "port" + <youpi> it's about reauthenticating a port to be passed to the translator + being started + <youpi> and for that a rendez-vous port is needed for the reauthentication + <youpi> and that's the one at stake + <antrik> yeah, I meant the port that is reauthenticated + <antrik> what is CRDIR? + <youpi> current root dir ... + <antrik> so the parent translator passes it's own root dir to the child + translator; and the issue is that for the root FS the root dir points to + the root FS itself... + <youpi> yes + <antrik> OK, that makes sense + <youpi> (but that's only one example, rgrep mach_port_destroy hurd/ show + other potential issues) + <antrik> well, that's actually what I wanted to mention next... why is the + rendez-vous port destroyed, instead of just deallocating the port right + and letting reference counting to it's thing?... + <antrik> do its thing + <youpi> "just to make sure" I guess + <antrik> it's pretty obvious that this will cause trouble for any RPC + referencing itself... + <youpi> well, follow-up with that on the list + <youpi> with roland/tb in CC + <youpi> only they would know any real reason for destroy + <youpi> btw, if you knew how we could make _hurd_select()'s raw __mach_msg + call be interruptible by signals, that'll permit to fix sudo + <youpi> (damn, I need sleep, my tenses are all wrong) + <antrik> BTW, does this cause any actual trouble?... + <antrik> I don't know much about interruption... cfhammer might have a + better idea, he look into that stuff quite a bit AIUI + <antrik> looked + <antrik> (hehe, it's not only your tenses... guess there's something in the + ether ;-) ) + <youpi> it makes sudo, mailq, etc. fail sometimes + <antrik> I mean the rendez-vous thing + <youpi> that's it, yes + <youpi> sudo etc. fail at least due to this + <antrik> so these are two different problems that both affect sudo? + <antrik> (rendez-vous and interruption I mean) + <youpi> yes + <youpi> with my patch the buildds have much fewer issues, but still some + <youpi> (my interrupt-related patch) + <youpi> I'm installing a s/destroy/deallocate/ version of ext2fs on the + buildds, we'll see how it behaves + <youpi> (it fixes my testcase at least) + <antrik> interrupt-related patch? + <antrik> only thing interrupt-related I remember was the reauthentication + race... + <youpi> that's what I mean + <antrik> well, cfhammer investigated this is quite some depth, explaining + quite well why the race is only mitigated but still exists... problem is + that we didn't know how to fix it properly + <antrik> because nobody seems to understand the cancellation code, except + perhaps for Roland and Thomas + <antrik> (and I'm not even entirely sure about them :-) ) + <antrik> I think his findings and our conclusions are documented on the + ML... + <youpi> by "much fewer issues", I mean that some of the symptoms have + disappeared, others haven't + <antrik> BTW, couldn't the rendez-vous thing be worked around by simply + ignoring the errors from the failing deallocate?... + <youpi> no, failing deallocate are actually dangerous + <antrik> why? + <youpi> since the name might have been reused for something else in the + meanwhile + <youpi> that's the whole point of the warning I had added in the kernel + itself + <antrik> I see + <youpi> such things really deserve tracking, since they can have any kind + of consequence + <antrik> does Mach try to reuse names quickly, rather than only after + wrapping around?... + <youpi> it seems to + <antrik> OK, then this is a serious problem indeed + <youpi> (note: I rarely divine issues when there aren't actual frequent + symptoms :) ) + <antrik> well, the problem with the warning is that it only shows in the + cases that do *not* cause a problem... so it's hard to associate them + with any specific issues + <youpi> well, most of the time the port is not reused quickly enough + <youpi> so in most case it shows up more often than causing problem + +IRC, freenode, #hurd, 2011-03-14 + + <youpi> ok, mach_port_deallocate actually can't be used + <youpi> since mach_reply_port() returns a receive right, not a send right + * youpi guesses he will really have to manage to understand all that port + stuff completely + <antrik> oh, right + <antrik> youpi: hm... now I'm confused though. if one client holds a + receive right, the other client (or in this case the same process) should + have a send or send-once right -- these should *not* share the same name + in my understanding + <antrik> destroying the receive right should turn the send right into a + dead name + <antrik> so unless I'm missing something, the destroy shouldn't be a + problem, and there must be something else going wrong + <antrik> hm... actually I'm probably wrong + <antrik> yeah, definitely wrong. receive rights and "ordinary" send rights + share the name. only send-once rights are special + <antrik> I wonder whether the problem could be worked around by using a + send-once right... + <antrik> mach_port_mod_refs(mach_task_self(), name, + MACH_PORT_RIGHT_RECEIVE, -1) can be used to deallocate only the receive + right + <antrik> oh, you already figured that out :-) diff --git a/open_issues/runit.mdwn b/open_issues/runit.mdwn index c7a0962c..659b81ea 100644 --- a/open_issues/runit.mdwn +++ b/open_issues/runit.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_porting]] @@ -17,3 +18,33 @@ report is just from his memory, and his memory is dim... The problem *might* either be a time stamping issue (which might be fixed by now) or it *might* be the `select` call failing issue we're seeing from time to time. Or something else. + +[[Harish Badrinath|harishbadrinath]] +Originally answered by Samuel Thibault: +> 120->proc_dostop_request ( 138) = 0 +> +> </snip> + +Usual issue with rpctrace: it does not support fork(). + + I've checked a backtrace in gdb, got this: + + 0x0105af6c in mach_msg_trap () + at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140, + timeout=1000020, notify=0) at msg.c:110 + 2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0, + timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324 + 3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48 + 4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29 + 5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543 + + and main() shows up as: + + sig_unblock(sig_term); + sig_unblock(sig_child); + -> iopause(x, 2 +haslog, &deadline, &now); + sig_block(sig_term); + sig_block(sig_child); + +So it simply looks like the known "signals don't interrupt select" bug. diff --git a/open_issues/sa_siginfo_sa_sigaction.mdwn b/open_issues/sa_siginfo_sa_sigaction.mdwn new file mode 100644 index 00000000..4e1fa849 --- /dev/null +++ b/open_issues/sa_siginfo_sa_sigaction.mdwn @@ -0,0 +1,96 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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="SA_SIGINFO, SA_SIGACTION"]] + +[[!tag open_issue_glibc]] + +Note: SA_SIGINFO has now been implemented by Jérémie Koenig. It will be +uploaded in Debian eglibc 2.13-19. + +IRC, #hurd, August / September 2010: + + <giselher> Hy, I came across SA_SIGINFO in cherokee, I have the void sighandler(int num) prototype but how do I add the sa_handler field? + <pinotree> if SA_SIGACTION is not defined, then you use sa_handler instead of sa_sigaction, and not add SA_SIGINFO in the sa_flags + <giselher> SA_SIGINFO is not defined + <pinotree> s/SA_SIGACTION/SA_SIGINFO/ above, yes + <giselher> K + <giselher> I am not sure if I fully understand this, there is the line "act.sa_flags = SA_SIGINFO" and how do I have to change that >_> + <pinotree> can you paste the source in a pastebin? + <giselher> k + <giselher> http://archhurd.pastebin.com/N8BCnG6g at line 790 + <pinotree> something along the lines of http://www.archhurd.pastebin.com/tdpcFD5G + <pinotree> note that in the handler the siginfo_t parameter is used, which cannot be done if SA_SIGINFO is not defined + <pinotree> (that code still won't compile, yet) + <giselher> btw: is there a reason why SA_SIGINFO is not implemented? + <giselher> the guildlines only say "It's not implemented" + <azeem> 09:43 < azeem> signal stuff is tricky :-/ + <azeem> basically it was pending on a complete rewrite by Roland, which never occured + <youpi> I have an almost complete implementation, just not finished yet + <youpi> (only the siginfo part) + <azeem> nobody really groked that code for years until youpi showed up, but he added partial support AFAIK, not having much time on his hand + <azeem> ah, he's here + <azeem> :) + <giselher> oh, should I just wait ? + <youpi> no + <giselher> k + <youpi> there are OSes which don't have SA_SIGINFO + <youpi> just cope with them: use sa_handler instead of sa_sigaction, and don't set SA_SIGINFO + <youpi> (i.e. replace with 0 in your example) + <giselher> ok + <youpi> when SA_SIGINFO becomes available, it'll just be used + +IRC, freenode, #hurd, 2011-08-20: + + < youpi> erf, tcpwrappers will need si_pid + < jkoenig> I could implement it not too far away in the future, we just + need a version of msg_sig_post() with a siginfo argument or something. + < youpi> I can also see a lot of packages using SA_SIGINFO for no reason... + < youpi> (probably copy/pasty code) + < youpi> sa.sa_flags = SA_SIGINFO; + < youpi> sa.sa_handler = parse_config; + < youpi> void parse_config(int) + < youpi> yay + < youpi> if(siginf->si_signo == SIGXCPU) + < youpi> fprintf(stderr, "Exceeded CPU usage.\n"); + < youpi> ... + < youpi> jkoenig: actually most package don't actually use the SA_SIGINFO + they request... + < youpi> jkoenig: si_pid should get us almost all actually used coverage + < youpi> I've seen only one example using si_errno + < jkoenig> ok + < youpi> oh, it's actually supported by your patch + < youpi> (errno) + < jkoenig> but I guess since implementing si_pid will require a new RPC, we + might as well plan for the rest + < youpi> jkoenig: indeed + < jkoenig> youpi, hmm I doubt it's properly filled in in all circumstances? + < youpi> ok, well, we'll see + < pinotree> jkoenig: if it can be of help, boost::unit_test queries various + fields of siginfo_t depending on the signal + < pinotree> jkoenig: also, pulseaudio uses siginfo_t for remapping faulting + memory on SIGBUS + < jkoenig> pinotree, oh ok good to know + < pinotree> *faulty + < youpi> jkoenig: well, I guess you had checked that the si_addr field is + correct in a few simple testcase :) + < jkoenig> hmm I think so, yes + < jkoenig> I ran like, "* (char *) 0x12345678;" or something IIRC + < youpi> ok + < jkoenig> I seem to remember mach generated SIGBUS instead of SIGSEGV + depending on the upper bit, or something (I can't quite remember) + < jkoenig> but when sigsegv was generated si_addr was right. + < pinotree> jkoenig: (see boost/test/impl/execution_monitor.ipp in boost + sources) + < pinotree> maybe you can try the unit tests for boost::unit_tests, if any + :) + < pinotree> (while src/pulsecore/memtrap.c in PA) + * pinotree stops doing MrObvious™ diff --git a/open_issues/sbcl.mdwn b/open_issues/sbcl.mdwn new file mode 100644 index 00000000..4bbf92ef --- /dev/null +++ b/open_issues/sbcl.mdwn @@ -0,0 +1,31 @@ +[[!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_porting]] + +IRC, freenode, #hurd, 2011-08-12 + + < zyg> did the segment registers had any purpose? I see fs is set equal to + others, but on linux fs is 0 (atleast on this x86 box). + < braunr> zyg: it can be used by special applications like wine, yes + < zyg> braunr: thanks.. I'm reading up on linux actually. It seems gs can + be used for TLS, fs in syscall to pass userspace. + < braunr> zyg: why are you interested in that ? + < zyg> a native compiler under linux places assumptions on fs register. So + I'm trying to find out what it should do under gnumach/hurd. + < braunr> what compiler ? + < zyg> braunr: it's sbcl + < braunr> ok + < youpi> zyg: the same, basically + < zyg> ok.. looking at the code, I've remarked where it sets up FS, because + /usr/include/asm/ldt.h:struct user_desc is missing. I must search for the + equiv. + < youpi> zyg: mach/i386/mach_i386.h + < youpi> the descriptor structure diff --git a/open_issues/screen.mdwn b/open_issues/screen.mdwn new file mode 100644 index 00000000..e0394f0d --- /dev/null +++ b/open_issues/screen.mdwn @@ -0,0 +1,120 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +Typing `C-c` (*SIGINT*) in a *screen* session (Debian package 4.0.3-14; -11 is +fine): + + * shell prompt: no reaction (nothing printed) + * `sleep 10` running: `^C` printed, but SIGINT is not sent. + +[[!debbug 522689#38]]. + +--- + +Revisit this issue: [[!debbug 97343]] -- special handling of `TIOCSCTTY` +depending on `__GNU__`. + +--- + +`#ifdef linux` and friends are used in quite a number of places. + +--- + +All diffs are GNU/Linux vs. GNU/Hurd. + + /* + * If your system supports BSD4.4's seteuid() and setegid(), define + * HAVE_SETEUID. + */ + -/* #undef HAVE_SETEUID */ + +#define HAVE_SETEUID 1 + +TODO: check. + +--- + + /* + * define HAVE_SVR4_PTYS if you have a /dev/ptmx character special + * device and support the ptsname(), grantpt(), unlockpt() functions. + */ + -#define HAVE_SVR4_PTYS 1 + +/* #undef HAVE_SVR4_PTYS */ + + /* + * define HAVE_GETPT if you have the getpt() function. + */ + #define HAVE_GETPT 1 + + /* + * define HAVE_OPENPTY if your system has the openpty() call. + */ + -/* #undef HAVE_OPENPTY */ + +#define HAVE_OPENPTY 1 + + /* + * define PTYRANGE0 and or PTYRANGE1 if you want to adapt screen + * to unusual environments. E.g. For SunOs the defaults are "qpr" and + * "0123456789abcdef". For SunOs 4.1.2 + * #define PTYRANGE0 "pqrstuvwxyzPQRST" + * is recommended by Dan Jacobson. + */ + -/* #undef PTYRANGE0 */ + -/* #undef PTYRANGE1 */ + +#define PTYRANGE0 "pq" + +#define PTYRANGE1 "0123456789abcdefghijklmnopqrstuv" + +TODO: check: `HAVE_SVR4_PTYS` is due to `configure.in` doing `test -c +/dev/ptmx`. But: even if we don't have that file, we still have `ptsname`, +`grantpt`, `unlockpt`. + +--- + + gcc -c -I. -I. -g -O2 -O2 -g -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers pty.c + +pty.c: In function 'OpenPTY': + +pty.c:323: warning: implicit declaration of function 'openpty' + +pty.c: At top level: + +pty.c:75: warning: 'PtyName' defined but not used + +pty.c:86: warning: 'PtyProto' defined but not used + +pty.c:87: warning: 'TtyProto' defined but not used + +TODO: check. + +--- + + --- linux/osdef.h 2009-10-06 18:43:53.000000000 +0200 + +++ screen-4.0.3/osdef.h 2009-10-06 18:49:49.000000000 +0200 + @@ -42,13 +42,19 @@ + #endif + + #ifdef SYSV + +extern char *strchr __P((char *, int)); + +extern char *strrchr __P((char *, int)); + +extern char *memset __P((char *, int, int)); + +extern int memcmp __P((char *, char *, int)); + #else + #endif + + #ifndef USEBCOPY + # ifdef USEMEMCPY + +extern void memcpy __P((char *, char *, int)); + # else + # ifdef USEMEMMOVE + +extern void memmove __P((char *, char *, int)); + # else + # endif + # endif + +TODO: check. + +--- + + * [[screen_dead_session]] diff --git a/open_issues/screen_dead_session.mdwn b/open_issues/screen_dead_session.mdwn new file mode 100644 index 00000000..fe51523b --- /dev/null +++ b/open_issues/screen_dead_session.mdwn @@ -0,0 +1,69 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +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. + +[[!toc]] + + +# One reproducible scenario goes like this + + * `ssh [somewhere]`, + + * start a *screen* session, and some long-running process *P* in there, + + * at some point the link is forcefully terminated (also known as disconnect + after 24 hours with consumer DSL), + + * *P* will continue to execute, + + * 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 + + * `ssh [somewhere]`, + + * start a *screen* session, and some long-running process *P* in there, + + * at some point the link is forcefully terminated (also known as disconnect + after 24 hours with consumer DSL), + + * `ssh [somewhere]`, + + * `screen -x`, and notice that *P* will *immediatelly* terminate / hang + (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/secure_file_descriptor_handling.mdwn b/open_issues/secure_file_descriptor_handling.mdwn new file mode 100644 index 00000000..45e983a7 --- /dev/null +++ b/open_issues/secure_file_descriptor_handling.mdwn @@ -0,0 +1,24 @@ +[[!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 +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]] + +`O_CLOEXEC`, `dup3` et al.; see +<http://udrepper.livejournal.com/20407.html>. [[tschwinge]] once worked +on this, posted patches to [[mailing_lists/libc-alpha]]. This works needs to +be resumed +and finished. + +--- + +In <http://lwn.net/Articles/417421/> an interesting point is made: *you [may] +want some [[unix/file_descriptor]] to still be open if 'exec' fails, but you +don't want it to be open after the exec succeeds*. [[I|tschwinge]]'m not sure +whether our current `O_CLOEXEC` implementation adheres to that. diff --git a/open_issues/security.mdwn b/open_issues/security.mdwn new file mode 100644 index 00000000..055c8bdc --- /dev/null +++ b/open_issues/security.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +There are [[several aspects to security|/security]] that are (mainly) relevant +to the design space. + +There are also security issues in the implemenation space, for example using +the correct coding paradigms. + +Large parts of our code base have not beed audited, either manually or in an +automated fashion. + +[[Unit testing]] is one aspect: testing for reliably failing for invalid input. + +[[Code analysis]] is another aspect. + +All publically usable interfaces provide attacking targets. This includes all +[[system call]]s and [[RPC]] interfaces. + +Fuzzing techniques can be use for locating possible issues. + + * <http://lwn.net/Articles/414273/> + + * Has already been used in the 70s / 80s (?) for testing [[UNIX]] command + line tools. + + * <http://www.ece.cmu.edu/~koopman/ballista/> diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn new file mode 100644 index 00000000..abec304d --- /dev/null +++ b/open_issues/select.mdwn @@ -0,0 +1,220 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +There are a lot of reports about this issue, but no thorough analysis. + + +# Short Timeouts + +## `elinks` + +IRC, unknown channel, unknown date: + + <paakku> This is related to ELinks... I've looked at the select() + implementation for the Hurd in glibc and it seems that giving it a short + timeout could cause it not to report that file descriptors are ready. + <paakku> It sends a request to the Mach port of each file descriptor and + then waits for responses from the servers. + <paakku> Even if the file descriptors have data for reading or are ready + for writing, the server processes might not respond immediately. + <paakku> So if I want ELinks to check which file descriptors are ready, how + long should the timeout be in order to ensure that all servers can + respond in time? + <paakku> Or do I just imagine this problem? + + +## [[dbus]] + + +## IRC + +### IRC, freenode, #hurd, 2012-01-31 + + <braunr> don't you find vim extremely slow lately ? + <braunr> (and not because of cpu usage but rather unnecessary sleeps) + <jkoenig> yes. + <braunr> wasn't there a discussion to add a minimum timeout to mach_msg for + select() or something like that during the past months ? + <youpi> there was, and it was added + <youpi> that could be it + <youpi> I don't want to drop it though, some app really need it + <braunr> as a debian patch only iirc ? + <youpi> yes + <braunr> ok + <braunr> if i'm right, the proper solution was to fix remote servers + instead of client calls + <youpi> (no drop, unless the actual bug gets fixed of course) + <braunr> so i'm guessing it's just a hack in between + <youpi> not only + <youpi> with a timeout of zero, mach will just give *no* time for the + servers to give an answer + <braunr> that's because the timeout is part of the client call + <youpi> so the protocol has to be rethought, both server/client side + <braunr> a suggested solution was to make it a parameter + <braunr> i mean, part of the message + <braunr> not a mach_msg parameter + <jkoenig> OTOH the servers should probably not be trusted to enforce the + timeout. + <braunr> why ? + <jkoenig> they're not necessarily trusted. (but then again, that's not the + only circumstances where that's a problem) + <braunr> there is a proposed solution for that too (trust root and self + servers only by default) + <jkoenig> I'm not sure they're particularily easy to identify in the + general case + <braunr> "they" ? the solutions you mean ? + <braunr> or the servers ? + <youpi> jkoenig: you can't trust the servers in general to provide an + answer, timeout or not + <jkoenig> yes the root/self servers. + <braunr> ah + <youpi> jkoenig: you can stat the actual node before dereferencing the + translator + <jkoenig> could they not report FD activity asynchronously to the message + port? libc would cache the state + <youpi> I don't understand what you mean + <youpi> anyway, really making the timeout part of the message is not a + problem + <braunr> 10:10 < youpi> jkoenig: you can't trust the servers in general to + provide an answer, timeout or not + <youpi> we already trust everything (e.g. read() ) into providing an answer + immediately + <braunr> i don't see why + <youpi> braunr: put sleep(1) in S_io_read() + <youpi> it'll not give you an immediate answer, O_NODELAY being set or not + <braunr> well sleep is evil, but let's just say the server thread blocks + <braunr> ok + <braunr> well fix the server + <youpi> so we agree + <braunr> ? + <youpi> in the current security model, we trust the server into achieve the + timeout + <braunr> yes + <youpi> and jkoenig's remark is more global than just select() + <braunr> taht's why we must make sure we're contacting trusted servers by + default + <youpi> it affects read() too + <braunr> sure + <youpi> so there's no reason not to fix select() + <youpi> that's the important point + <braunr> but this doesn't mean we shouldn't pass the timeout to the server + and expect it to handle it correctly + <youpi> we keep raising issues with things, and not achieve anything, in + the Hurd + <braunr> if it doesn't, then it's a bug, like in any other kernel type + <youpi> I'm not the one to convince :) + <braunr> eh, some would say it's one of the goals :) + <braunr> who's to be convinced then ? + <youpi> jkoenig: + <youpi> who raised the issue + <braunr> ah + <youpi> well, see the irc log :) + <jkoenig> not that I'm objecting to any patch, mind you :-) + <braunr> i didn't understand it that way + <braunr> if you can't trust the servers to act properly, it's similar to + not trusting linux fs code + <youpi> no, the difference is that servers can be non-root + <youpi> while on linux they can't + <braunr> again, trust root and self + <youpi> non-root fuse mounts are not followed by default + <braunr> as with fuse + <youpi> that's still to be written + <braunr> yes + <youpi> and as I said, you can stat the actual node and then dereference + the translator afterwards + <braunr> but before writing anything, we'd better agree on the solution :) + <youpi> which, again, "just" needs to be written + <antrik> err... adding a timeout to mach_msg()? that's just wrong + <antrik> (unless I completely misunderstood what this discussion was + about...) + + +#### IRC, freenode, #hurd, 2012-02-04 + + <youpi> this is confirmed: the select hack patch hurts vim performance a + lot + <youpi> I'll use program_invocation_short_name to make the patch even more + ugly + <youpi> (of course, we really need to fix select somehow) + <pinotree> could it (also) be that vim uses select() somehow "badly"? + <youpi> fsvo "badly", possibly, but still + <gnu_srs1> Could that the select() stuff be the reason for a ten times + slower ethernet too, e.g. scp and apt-get? + <pinotree> i didn't find myself neither scp nor apt-get slower, unlike vim + <youpi> see strace: scp does not use select + <youpi> (I haven't checked apt yet) + + +### IRC, freenode, #hurd, 2012-02-14 + + <braunr> on another subject, I'm wondering how to correctly implement + select/poll with a timeout on a multiserver system :/ + <braunr> i guess a timeout of 0 should imply a non blocking round-trip to + servers only + <braunr> oh good, the timeout is already part of the io_select call + + +### IRC, freenode, #hurdfr, 2012-02-22 + + <braunr> le gros souci de notre implé, c'est que le timeout de select est + un paramètre client + <braunr> un paramètre passé directement à mach_msg + <braunr> donc si tu mets un timeout à 0, y a de fortes chances que mach_msg + retourne avant même qu'un RPC puisse se faire entièrement (round-trip + client-serveur donc) + <braunr> et donc quand le timeout est à 0 pour du non bloquant, ben tu + bloques pas, mais t'as pas tes évènements .. + <abique|work> peut-être que passer le timeout de 10ms à 10 us améliorerait + la situation. + <abique|work> car 10ms c'est un peut beaucoup :) + <braunr> c'est l'interval timer système historique unix + <braunr> et mach n'est pas préemptible + <braunr> donc c'est pas envisageable en l'état + <braunr> ceci dit c'est pas complètement lié + <braunr> enfin si, il nous faudrait qqchose de similaire aux high res + timers de linux + <braunr> enfin soit des timer haute résolution, soit un timer programmable + facilement + <braunr> actuellement il n'y a que le 8254 qui est programmé, et pour + assurer un scheduling à peu près correct, il est programmé une fois, à + 10ms, et basta + <braunr> donc oui, préciser 1ms ou 1us, ça changera rien à l'interval + nécessaire pour déterminer que le timer a expiré + + +### IRC, freenode, #hurd, 2012-02-27 + + <youpi> braunr: extremely dirty hack + <youpi> I don't even want to detail :) + <braunr> oh + <braunr> does it affect vim only ? + <braunr> or all select users ? + <youpi> we've mostly seen it with vim + <youpi> but possibly fakeroot has some issues too + <youpi> it's very little probable that only vim has the issue :) + <braunr> i mean, is it that dirty to switch behaviour depending on the + calling program ? + <youpi> not all select users + <braunr> ew :) + <youpi> just those which do select({0,0}) + <braunr> well sure + <youpi> braunr: you guessed right :) + <braunr> thanks anyway + <braunr> it's probably a good thing to do currently + <braunr> vim was getting me so mad i was using sshfs lately + <youpi> it's better than nothing yes + + +# See Also + +See also [[select_bogus_fd]] and [[select_vs_signals]]. diff --git a/open_issues/select_bogus_fd.mdwn b/open_issues/select_bogus_fd.mdwn new file mode 100644 index 00000000..17aced4a --- /dev/null +++ b/open_issues/select_bogus_fd.mdwn @@ -0,0 +1,55 @@ +[[!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]] + + +# Python + +IRC, freenode, #hurd, 2011-04-13 + + <abeaumont> ok, cause of first python testsuite failure located, now the + hard part, how to best fix it :) + <abeaumont> how to redesign the code to avoid the problem... that's the + hard part, mostly cause i lack contextual info + <abeaumont> tschwinge: the problem is pretty much summarized by this + comment in _hurd_select (in glibc): /* If one descriptor is bogus, we + fail completely. */ + <pochu> does POSIX say anything about what to do if one fd is invalid? + <pochu> and the other question is why python is calling select() with an + invalid fd + <abeaumont> pochu: yep, it says it should not fail completelly + <pochu> then that's our bug :) + <pinotree> abeaumont: just note that (at least on debian) some tests may + hang forever or cause hurd/mach to die + <pinotree> abeaumont: see in the debian/rules of the packaging of each + pythonX.Y source + <pinotree> ... there's a list of the tests excluded from the test suite run + <abeaumont> well, to be precise, python has a configure check for + 'broken_poll' which hurd fails, and therefore python's select module is + not built, and anything depending on it fails + <abeaumont> broken_poll checks exactly for that posix requirement + <abeaumont> the reason for python using a non-existant + descriptor... unknown :D + <pochu> we should fix select to not fail miserably in that case + <pinotree> abeaumont: we have a patch to fix the broken poll check to + actually disable the poll module + <pochu> pinotree: but the proper fix is to fix select(), which is what + abeaumont is looking at + <abeaumont> pinotree: i'd say that's exactly what python's configure check + does itself -- disable building the select module + <pochu> abeaumont: what pinotree means is that the check is broken, see + http://patch-tracker.debian.org/patch/series/view/python2.6/2.6.6-8/hurd-broken-poll.diff + <pinotree> yes, the configure check for poll does the check, but not + everything of the poll module gets disabled (and you get a build failure) + +--- + +See also [[select]] and [[select_vs_signals]]. diff --git a/open_issues/select_vs_signals.mdwn b/open_issues/select_vs_signals.mdwn new file mode 100644 index 00000000..bbd69d00 --- /dev/null +++ b/open_issues/select_vs_signals.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]] + + +# `sudo` + +`sudo [task]` hands after finishing `[task]`. + +IRC, freenode, #hurd, 2011-04-02 + + <youpi> the sudo bug is select() not being able to get interrupted by + signals + +--- + +See also [[select]] and [[select_bogus_fd]]. diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn new file mode 100644 index 00000000..cf0103df --- /dev/null +++ b/open_issues/sendmsg_scm_creds.mdwn @@ -0,0 +1,101 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <pinotree> Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2722 + <pinotree> 2722: Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2724 + <pinotree> \o/ + <youpi> \o/ + <pinotree> the patch is even short, after all: http://paste.debian.net/54795/ + --- a/sysdeps/mach/hurd/sendmsg.c + +++ b/sysdeps/mach/hurd/sendmsg.c + @@ -18,6 +18,7 @@ + + #include <errno.h> + #include <string.h> + +#include <unistd.h> + #include <sys/socket.h> + #include <sys/un.h> + + @@ -45,6 +46,7 @@ + mach_msg_type_number_t amount; + int dealloc = 0; + int i; + + struct sockaddr_storage sa; + + /* Find the total number of bytes to be written. */ + len = 0; + @@ -122,6 +124,34 @@ + err = EIEIO; + } + + + memset (&sa, 0, sizeof (struct sockaddr_storage)); + + if (addr) + + { + + memcpy (&sa, addr, addr_len); + + } + + else + + { + + getsockname (fd, (struct sockaddr *) &sa, &addr_len); + + } + + addr = (struct sockaddr_un *) &sa; + + if (message && (addr->sun_family == AF_LOCAL)) + + { + + struct cmsghdr *cm; + + struct msghdr *m = (struct msghdr *) message; + + for (cm = CMSG_FIRSTHDR (m); cm; cm = CMSG_NXTHDR (m, cm)) + + { + + if (cm->cmsg_level == SOL_SOCKET && cm->cmsg_type == SCM_CREDS) + + { + + struct cmsgcred *cred = (struct cmsgcred *) CMSG_DATA (cm); + + cred->cmcred_pid = __getpid (); + + cred->cmcred_uid = __getuid (); + + cred->cmcred_euid = __geteuid (); + + cred->cmcred_gid = __getgid (); + + cred->cmcred_ngroups = getgroups (sizeof (cred->cmcred_groups) / sizeof (gid_t), cred->cmcred_groups); + + } + + } + + } + + + err = HURD_DPORT_USE (fd, + ({ + if (err) + <youpi> what checks that the pid is correct? + <youpi> and uid, etc. + <pinotree> hm? + <youpi> credential is not only about one claiming to the other his uid & such + <youpi> it's about the kernel or whatever authority tell to an end the identity of the other end + <pinotree> yep + <pinotree> but given that the data is then send to pflocal, this code is the last part that runs on the application side + <youpi> pflocal could as well just request the info from proc + <youpi> it will have to anyway, to check that it's true + <pinotree> hm + <pinotree> yeah, though about that, chose this approach as "quicker" (of course not definitive) + <youpi> well at least it shows we're able to transmit something :) + <pinotree> well it just manipulates the data which gets send nicely already ;) + <youpi> but really, it's most probably up to pflocal to check authentication from proc and give it to the other end + <youpi> the application sender part would be just the RPC authentication calls + <youpi> Mmm, just realizing: so receiver part already exists actually, right? + <youpi> (since it's just about letting the application reading from the message structure) + <pinotree> yep + <youpi> ok, good :) + +/!\ IRC, freenode, #hurd, 2011-08-11 + + < pinotree> (but that patch is lame) + +--- + +See also [[dbus]], [[pflocal_socket_credentials_for_local_sockets]] and +[[pflocal_reauth]]. diff --git a/open_issues/serial_console.mdwn b/open_issues/serial_console.mdwn new file mode 100644 index 00000000..ed6358a2 --- /dev/null +++ b/open_issues/serial_console.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +IRC, #hurdfr, 2010-09-20 + + <youpi> tu peux compiler ton gnumach pour qu'il utilise la console série, et tu + mets le port série sur la console qemu + <youpi> -AC_DEFINE([RCLINE], [-1], [com port for the remote console]) + <youpi> +AC_DEFINE([RCLINE], [0], [com port for the remote console]) + <youpi> dans i386/configfrag.ac + <manuel> grumpf, peu pratique :) + <youpi> ben après t'auras accès vraiment à ton gnumach + <youpi> messages de noyau etc. + <manuel> oui c'est sûr, mais j'ai aucune idée de comment je configure qemu & + co, ça va être sportif encore + <youpi> -serial vc + <manuel> je lance pas moi-même le qemu, donc j'imagine qqch comme -serial + tcp::qqch,server + <youpi> ben t'as pas accès à la console alors ? + <youpi> mais sinon via tcp ça devrait aller oui + <manuel> si, via telnet + <manuel> youpi: et après, tu fais comment pour envoyer le c-a-D toi ? + <manuel> (question sans doute bête) + <youpi> c'est un code différent via com1 iirc + <manuel> mmmmmmmmmhhhhhh + <youpi> (c'est pas bête: c-a-d c'est pas vraiment défini pour un port série) + <manuel> tu sais où je peux le trouver ? + <youpi> ah tiens non yena pas + <youpi> mais bon spa dur à ajouter + <manuel> bcp trop compliqué pour moi + <youpi> dans i386/i386at/com.c, à la première ligne ttyinput() + <youpi> tu compares c à ce que tu veux + <youpi> et dans ce cas tu appelles kdb_kintr + <youpi> (sans paramètre) + <youpi> mais sinon ya pas vraiment besoin d'appeller explicitement le + débuggueur hein + <manuel> ah ? + <youpi> dès que tu mets debug_all_traps à 1 dans traps.c, il sera invoqué lors + du segv + <manuel> ok + <youpi> pour xen j'ai mis £ comme raccourcis + <manuel> ça me paraît plus simple dans ce cas + <youpi> clin d'œil à la société anglaise :) diff --git a/open_issues/servers_default-pager_permissions.mdwn b/open_issues/servers_default-pager_permissions.mdwn new file mode 100644 index 00000000..58dba1cb --- /dev/null +++ b/open_issues/servers_default-pager_permissions.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="/servers/default-pager permissions"]] + +[[!tag open_issue_hurd]] + +IRC, freenode, #hurd, 2012-01-14: + + <youpi> antrik: what are the permissions that are supposed to be given to + /servers/default-pager ? + <antrik> olaf@alien:~$ ls -l /servers/default-pager + <antrik> crw-rw-rw- 1 root root 0, 0 Sep 17 2004 /servers/default-pager + <antrik> oh, interesting... in the other system it's different + <antrik> olaf@alien:~$ ls -l /sub/servers/default-pager + <antrik> crw-r--r-- 1 root root 0, 0 Jul 10 2006 + /sub/servers/default-pager + <antrik> both are Debian, the latter installed with crosshurd + <antrik> (and native-install run in a chroot or subhurd, don't remember + which...) diff --git a/open_issues/settrans_directory_symlink.mdwn b/open_issues/settrans_directory_symlink.mdwn new file mode 100644 index 00000000..86148a52 --- /dev/null +++ b/open_issues/settrans_directory_symlink.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +This works: + + $ touch a && settrans a /hurd/symlink b + +This doesn't: + + $ mkdir a && settrans a /hurd/symlink b + settrans: a: Is a directory + +It's the same `file_set_translator` RPC both times, and it's [[translator +short-circuiting|hurd/translator/short-circuiting]] which makes the latter one +fail: + +`libdiskfs/file-set-trans.c`: + + [...] + /* Set passive translator */ + if (passive_flags & FS_TRANS_SET) + { + if (!(passive_flags & FS_TRANS_FORCE)) + { + /* Handle the short-circuited translators */ + mode_t newmode = 0; + + if (diskfs_shortcut_symlink && !strcmp (passive, _HURD_SYMLINK)) + newmode = S_IFLNK; + [...] + + if (newmode) + { + if (S_ISDIR (np->dn_stat.st_mode)) + { + /* We can't allow this, because if the mode of the directory + changes, the links will be lost. Perhaps it might be + allowed for empty directories, but that's too much of a + pain. */ + mutex_unlock (&np->lock); + return EISDIR; + } + [...] diff --git a/open_issues/sigpipe.mdwn b/open_issues/sigpipe.mdwn new file mode 100644 index 00000000..0df3560e --- /dev/null +++ b/open_issues/sigpipe.mdwn @@ -0,0 +1,345 @@ +[[!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_hurd]] + +[[!GNU_Savannah_bug 461]] + +IRC, freenode, #hurd, 2011-04-20 + + <svante_> I found a problem from 2002 by Marcus Brinkmann that I think is + related to my problems: http://savannah.gnu.org/bugs/?461. He has a test + file called pipetest.c that shows that SIGPIPE is not triggered reliably. + <svante_> Cited from the bug report: The attached test program does not + trigger SIGPIPE reliably, because closing the read end of the pipe + happens asynchronously. The write can succeed because the read end might + not have been closed yet. + <svante_> I have debugged this program on both Hurd and Linux, and the + problem in Hurd remains:-( + <svante_> Anybody looked into the almost ten year old + bug:http://savannah.gnu.org/bugs/?461 this one is definitely related to + the build problems of e.g. ghc6 and ruby1.9.1. Should I mention this on + the ML? + <youpi> that could be it indeed + <youpi> does th bug still happen? + <azeem> depends on: new interface io_close + <azeem> which depends on: POSIX record locking + <svante_> youpi: Yes it does, I've tested the pipetest.c file submitted by + Marcus B on both Linux and Hurd + <azeem> that would've maybe been a nice GSOC task + <youpi> azeem: err, the contrary for posix record locking, non ? + <azeem> argh + <azeem> why would POSIX record locking depend on this? + <azeem> well anyway, then have POSIX record locking be a GSOC task :) + <azeem> I wasn't aware that would also fix ruby and ghc building :) + <youpi> http://permalink.gmane.org/gmane.os.hurd.devel.readers/265 + <youpi> (for io_close stuff) + <youpi> http://comments.gmane.org/gmane.os.hurd.devel.readers/63 actually + <azeem> I guess if they didn't implement it/agreed on something back then + it'd be quite hard to do it now + <svante_> azeem: marcus recently showed up here. Maybe he can help out/has + ideas? + <azeem> well yeah + <azeem> but marcus was the junior guy back then + <azeem> <marcus> but it's a very hurdish solution (ie, complex, buggy, and + not implemented) + <azeem> maybe we can go for something simpler + <youpi> azeem: what is this quote about? + <azeem> don't remember + <azeem> not io_close I'd say + +2011-04-21 + + <antrik> svante_: why do you think the problem you see in ruby and ghc is + related to async close() ? + +2011-04-22 + + <svante_> Well: the test case I'm running on ruby is giving me an EBADF + after 8 successful loops, and tracing within eglibc points towards + __mutex_lock_solid or __spin_lock, __spin_lock_solid from + mach/lock-intern.h from cthreads. + +2011-04-23 + + <antrik> srs1: yeah, I saw it... but I still wonder what makes you think + this is related to async FD closing? + <srs1> antrik: Every test case showing the problems are related to fd.h and + the functions there, especially the ones used in the function: + _HURD_FD_H_EXTERN_INLINE struct hurd_fd *_hurd_fd_get (int fd) and so is + the pipetest from Marcus too. + <srs1> I have not yet been able to trace further with gdb since most + variables are optimized out and adding print statements does not work, at + least not yet. Now I'm trying to build eglibc with -O1 to see if the + optimized out variables are there or not. + <youpi> srs1: he means the ghc6 issue + <youpi> (and the ruby issue) + <srs1> youpi: Yes, the ghc6 and ruby ends at the functions I mentioned in + fd,h + <srs1> Both ghc6 and ruby programs are writing to a file when the error + happens. If they are using a pipeline or not I don't know yet, I think it + is a regular file write. + <srs1> I can send your the ruby program if you like: It is a c-file so + debugging is possible. ghc6 is worse, since that program cannot be + debugged directly with gdb. + <antrik> pipetest also results in the program hanging in locking stuff?... + <srs1> pipetest does not hang, but gives no output as it should. Running it + in gdb with single stepping shows the correct behavior, but then gdb + hangs if I try to single stepping further, continue at the right place + works! + <antrik> I haven't looked at the pipetest program. do you have the link + handy? + <antrik> never mind, got it + <antrik> srs1: that sounds like a GDB problem... + <youpi> most probably, yes + <youpi> (and I've always seen issues like this in gdb on hurd) + <antrik> actually I think it's expected... the RPC handling code has some + explicit GDB hooks AIUI; trying to single-step into this code is probably + expected to wreck havoc... + <youpi> well, it should have some sane behavior + <youpi> even if it's "skip to next point where it's debuggable" + <antrik> srs1: note that there is no BADF involved in the pipetest AIUI... + +2011-04-28 + + <antrik> what is the actual problem you are seeing BTW? + <gnu_srs1> antrik: in ruby the problem is: Exception `IOError' at + tool/mkconfig.rb:12 - closed stream + <gnu_srs1> Triggered by ruby:io.c:internal_read_func() calling + sysdeps/mach/hurd/read.c returning a negative number of bytes read. + <abeaumont> gnu_srs1: why do you think that error is locking related? + <gnu_srs1> This happens after 8 iterations of the read loop with 8192 bytes + read each time. + <abeaumont> but that doesn't involve locking at all, does it? + <gnu_srs1> I think it is, if there is a pipepline set up?? + <gnu_srs1> Also the ghc6 hang ends up in hangs in sysdeps/mach/hurd/read.c + traced into fd.h where all things happen (including setting locks and + mutexes) + <braunr> what locking ? + <braunr> stdio locking is different from file locking + <braunr> and a pipe doesn't imply file locking at all + <abeaumont> read may block on pipes, but it's unrelated to flock + <gnu_srs1> Look into the file fd.h, maybe you can describe things + better. I'm not fluent in this stuff. + <gnu_srs1> Has a pipe has a file descriptor associated to it? What about a + file read/write? + <abeaumont> a pipe provides 2 file descriptors, one for reading and another + one for writting + <abeaumont> i may give a look at that if i manage to build glibc + succesfully... + <gnu_srs1> Take a look at the realevant code from fd.h: + http://pastebin.com/kesBpjy4 + <abeaumont> the ruby error happens just trying to build ruby1.9? + <abeaumont> gnu_srs1: from what you said, the error occurs while reading, + so i don't see how it can be related to that code + <abeaumont> you already got a descriptor if you're reading from it + <gnu_srs1> I have not tried anything else than ruby1.9.1. I can send you + the ruby debug setup and files if you are interested. + <abeaumont> gnu_srs1: ok, i'll try to build ruby1.9.1 later... let's see if + i can build glibc first + <gnu_srs1> abeaumont: well, the read suddenly returns -1 bytes read, + resulting in a file descriptor of -1 (instead of +3). + <abeaumont> gnu_srs1: i see + <antrik> gnu_srs1: are you sure the hang really happens in _hurd_fd_get()? + could you give us a backtrace? + <antrik> gnu_srs1: there are many reasons why read() can return -1; errno + should indicate the reason. unfortunately, I can't make much out of + ruby's "translation" of the error :-) + <gnu_srs1> antrik: In the ruby case there is no hang: The steam is closed + by read() giving an error code !=0. This triggers things in the ruby + code: A negative number of bytes read and a negative fd results, and an + error error is triggered in the ruby code. + <gnu_srs1> antrik: See http://pastebin.com/eZmaZQJr + <antrik> gnu_srs1: yes, this all sounds perfectly right. the question is + *why* read() returns an error code. we'd need to know what error it is + exactly, and in what situation it occurs. tracing the libc code is not at + all useful here + <antrik> uhm... 1073741833 is errno?... + <gnu_srs1> BTW: I think the error code is EBADF (badfile descriptor?). The + integer version of it is 1073741833, see the pastebin i linked to. + <antrik> you could use perror() to get something more readable :-) + <antrik> or error() with the right arguments + <gnu_srs1> I used integer when printing, but looking into fd.h I think it + is EBADF (I did get this result once in gdb) + <antrik> fd.h won't tell you anything. most error codes are generated by + the server, not by libc + <antrik> BADF might be generated in libc when ruby tries to read on FD -1 + <antrik> (no idea why it tries to do that... perhaps there is actually + something wrong/stupid in ruby's error handling) + <gnu_srs1> Well I single-stepped in fd.h using gdb and printing err gave + EBADf. err is declared as: error_t err in read.c + <antrik> at which point did you single-step? while fd was still 3? + <gnu_srs1> I don't think the problem is in ruby, it is in mach/hurd! + Similar problems with ghc, python-apt, etc + <gnu_srs1> Yes, fd=3 was not changed. I cannot trace into fd.h from + read.c. That is the problem with all cases! Need to leave for a while + now. + <antrik> sorry, I don't see *anything* similar in the ghc failure. + <antrik> I don't know about python-apt + <antrik> for the ghc case, I'd like to see a GDB backtrace from the point + where it is hanging + <antrik> just to be clear: anything I/O-related will involve fd.h + somewhere. that doesn't in any way indicate the problems are related. in + fact the symptoms you described are very different, and I'm pretty + certain these are completely different issues + <gnu_srs1> antrik: Here is a backtrace, + http://pastebin.com/wvCiXFjB. Numbers 6,7,8 are from the calling Haskell + functions. They cannot be debugged by gdb. Nice to see that somebody is + showing interest at last:-/ + <antrik> hm... I wonder whether the _hurd_intr_rpc_msg_in_trap is a result + of the ^C? + <antrik> if so, it seems to be a "normal" bloking read() operation. so + again probably not related to libc code at all + <gnu_srs1> Where is this blocking read() code located mach/hurd? + <antrik> io_read() is implemented by whatever server handles the FD in + question + <antrik> I guess rpctrace will be more helpful here than GDB... to see what + the program is trying to do here + <gnu_srs1> Why don't I get there with gdb? + <antrik> err... the server is a different process + <antrik> you are only tracing the client code + <gnu_srs1> OK, here is a rpctrace for ruby: + http://pastebin.com/sdPiKGBW.Nice programs you have, no manual pages, and + the program hang + <gnu_srs1> s/http://pastebin.com/sdPiKGBW.Nice + /http://pastebin.com/sdPiKGBW. BTW: Nice/ + <gnu_srs1> antrik: Do you want the rpctrace of the ghc hang too? If that is + the case, do you need the whole file. From the ruby case the last part + looked most interesting: + libpthread/sysdeps/generic/pt-mutex-timedlock.c: assert (mutex->owner != + self); + <antrik> gnu_srs1: hm... you get that assertion only with rpctrace? guess + it doesn't work properly then :-( + <gnu_srs1> Is it visible on the client side? + <antrik> gnu_srs1: that assertion *is* from the client side. I'm just + surprised that apparently it's only triggered when you run it in rpctrace + <antrik> how did you invoke rpctrace? + <gnu_srs1> rpctrace "command with options" > rpctrace.out 2>&1 + <antrik> well, I'd like to know the "command with options" part :-) + <gnu_srs1> OK: for ruby: ./miniruby ./ tool/mkconfig.rb as before. + <antrik> OK, so it just runs the ruby interpreter and no other processes + <gnu_srs1> No other processes involved! + <abeaumont> gnu_srs1: i can reproduce the ruby error, no let's dig in it :D + <antrik> gnu_srs1: rpctrace for ghc could be useful too... but if it's too + long, pasting only the last bit might suffice + <gnu_srs1> antrik: OK, will do that. Do you find anything interesting? + <gnu_srs1> abeaumont: Using gdb: gdb ./miniruby; (gdb) break io.c:569; c8; + break fd.h:72 or break read.c:27 and you are there. Beware of gdb + hanging, so you need another terminal to kill -9 gdb (sometimes a reboot + is needed :-( + <antrik> gnu_srs1: no, the ruby rpctrace is useless; apparently rpctrace + makes it break before reaching the relevant part :-( + <abeaumont> thanks gnu_srs1 + <gnu_srs1> antrik: Hope for better luck with ghc: + http://pastebin.com/dgcrA05t + <antrik> hm... it hangs at proc_dostop() again... whatever that means + +2011-05-07 + + <gnu_srs> One question about ruby: I know where the problems occur in ruby + code. Can I switch to the kernel thread just before in gdb to single step + from there? + <youpi> you can put a breakpoint, can't you? + <antrik> gnu_srs: kernel thread? + <gnu_srs> Yes, but will single stepping from there lead me to the Hurd + code. I have not succeeded to do that yet! + <youpi> you mean the translator code? + <gnu_srs> Well, Roland did call it the signal thread, there are at least + two threads per process, a signal thread and a main (user) thread. + <youpi> then it's a thread in gdb + <youpi> just use the thread gdb commands to access it + <gnu_srs> I do find two threads in gdb, yes. But following only the user + thread does not lead me to the cause of the problems. + <gnu_srs> And following the other (signal thread) has not been successful + so far. + <youpi> multithreading debugging in gdb is painful yes + <youpi> single-step isn't really an option in it + <antrik> gnu_srs: well, as I said before, the cause is probably not in the + libc code anyways. it would be much more relevant to find out what the FD + in question is, and what "special" thing Ruby does to it to trigger the + problematic behaviour... + <youpi> it's simpler to put printfs etc. + <antrik> youpi: well, printf doesn't work in the FD code :-) + <youpi> you can make it work + <youpi> open /dev/mem, write to 0xb8000 + <youpi> I'm not even joking + <gnu_srs> I have printfs in the ruby code. And at some parts in eglibc (but + it is not possible to put them at all places I want, as mentioned before) + <antrik> sure, there are ways to debug this code too... but I don't think + it's useful. so far there is no indication that this will help finding + the actual issue + <gnu_srs> The problem is not file descriptors. It is that an ongoing read + suddenly returns -1 bytes read. And then the ruby code assigns a negative + file descriptor in the exception handling. + <youpi> a *read* ? + <youpi> with errno == 0 ? + <gnu_srs> Yes, a read! + <youpi> how ruby comes to assigning a negative fd from that? + <youpi> does it somehow close the fd? + <gnu_srs> The errno reported from the read is EBADF! + <youpi> did you try to rpctrace it? + <gnu_srs> I don't bother too much about ruby exception handling. The error + has already happened in the read operation. And that lead me to eglibc + code.... and so on... + <youpi> do you know what kind of file this fd was supposed to be on? + <youpi> sure, that's debugging + <gnu_srs> Yes I did rpctrace, but that was not successful. rpctrace just + hang! Buggy code? + <antrik> youpi: I assume that's Ruby's way to indicate that the FD is not + valid anymore, after the previous error + <youpi> does the program fork? + <youpi> antrik: possibly + <youpi> rpctrace has known issues, yes + <youpi> gnu_srs: did you trace close()s by hand with printfs? + <gnu_srs> Ho w to find out if it forks? + <youpi> what does rpctrace stop on ? + <gnu_srs> Well, I don't remember. Antrik? + <antrik> proc_dostop() IIRC + <antrik> or something like that + <gnu_srs> I did not find any close() statements in the code I debugged. + <youpi> ok, proc_dostop() is typically a sign of fork() + <youpi> gnu_srs: that doesn't necessarily mean it's not called + <antrik> gnu_srs: I think his point is that something else might close the + FD, causing the error you see + <youpi> anything can happen in the wild :) + <antrik> gnu_srs: as I said before, the next step is to find out what this + FD is, and what happens to it... + <gnu_srs> antrik: Any ideas how to find out? + <youpi> what is the backtrace? + <gnu_srs> Well I know the fd number, it is either 3 or 5 in my tests. Does + the number matter? + <youpi> yes, it's not std{in,out,err} + <gnu_srs> How to get a backtrace of a program that does not hang? + <youpi> make it hang at the point of failure + <youpi> when read returns -1 + <youpi> so you know who did the read + <gnu_srs> I have to run the loop several times before the number of bytes + read is -1. + <youpi> you mean running the program several times ? + <youpi> or just let the loop continue for some time? + <pinotree> if it's the latter, you can add breakpoints with conditions + <gnu_srs> No the read loop runs for 7 iterations, and fails the 8th time! + <youpi> then make it hang when read() returns -1 + <Mr_Spock> could you paste your code somewhere? + <youpi> when debugging, you're allowed to do all kinds of ugly things, you + know ;) + <gnu_srs> OK, I'll try that. + <gnu_srs> MR_Spock: The easiest way would be to try to build + ruby1.9.1. Then I can help you from where it fails. + <gnu_srs> pinotree: How to give a breakpoint with a condition? + <pinotree> break where if condition + <youpi> see help break + <youpi> oh, there's even a thread condition nowadays, good + <gnu_srs> Thanks for the discussion. I have to get into the real world for + a while now. To be continued. + <antrik> gnu_srs: well, if you already know that the loop runs several + times before the error occurs, you apparently already looked at the + higher-level code that is relevant here... + <youpi> but it may be generic code, and not tell what calls it diff --git a/open_issues/some_todo_list.mdwn b/open_issues/some_todo_list.mdwn index 5f8470b7..1f6f5002 100644 --- a/open_issues/some_todo_list.mdwn +++ b/open_issues/some_todo_list.mdwn @@ -51,7 +51,6 @@ From Marcus, 2002: * Are all inode numbers and link counts correct? * We also should have a "make check" test suite. We can add this once Jeff finished his automake patches * pick up the other things - * pthread, definitely. Now that we are so close * new console is basically done * needs integration of course * X switching support diff --git a/open_issues/strict_aliasing.mdwn b/open_issues/strict_aliasing.mdwn new file mode 100644 index 00000000..01019372 --- /dev/null +++ b/open_issues/strict_aliasing.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_gnumach open_issue_hurd open_issue_mig]] + + +# IRC, freenode, #hurd, 2012-07-04 + + <braunr> we should perhaps build the hurd with -fno-strict-aliasing, + considering the number of warnings i can see during the build :/ + <pinotree> braunr: wouldn't be better to "just" fix the mig-generated stubs + instead? + <braunr> pinotree: if we can rely on gcc for the warnings, yes + <braunr> but i suspect there might be other silent issues in very old code diff --git a/open_issues/subhurd_error_messages.mdwn b/open_issues/subhurd_error_messages.mdwn new file mode 100644 index 00000000..46b58fa4 --- /dev/null +++ b/open_issues/subhurd_error_messages.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date: + + <antrik> BTW, many things in a subhurd print various error messages that are never visible on a normal Hurd... diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn new file mode 100644 index 00000000..c8a37169 --- /dev/null +++ b/open_issues/sync_but_still_unclean_filesystem.mdwn @@ -0,0 +1,37 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +Also filed as [[!GNU_Savannah_bug 29292]]. + +\#hurd, 2010, end of May / beginning of June + + [runnign sync, but sill unclean filesystem at next boot] + <slpz> guillem: when libpager syncs an object, it sends an m_o_lock_request + and waits (if the synchronous argument was specified) for a + m_o_lock_completed. But m_o_lock_completed only means that dirty pages + have been sent to the translator, and this one still needs to write them + to the backing storage + <slpz> guillem: there's no problem if sync() returns before actually + writting the changes to disk, but this also happens when shutting down + the translator + <slpz> guillem: in theory, locking mechanisms in libpager should prevent + this from happening by keeping track of write operations, but this seems + to fail in some situations + +It helps a lot to run [[`syncfs --synchronous /`|hurd/syncfs]] before issuing +the `halt` or `reboot` command. This will prevent most of the uncleanliness. +Of course, [[hurd/translator/ext2fs]] is meant to be doing this to-disk +synchronization internally upon translator shutdown, but evidently it doesn't +in all cases. + +Apparently diskfs simply does not set filesystems as read-only: +<http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00024.html>. diff --git a/open_issues/syslog.mdwn b/open_issues/syslog.mdwn new file mode 100644 index 00000000..19cba82e --- /dev/null +++ b/open_issues/syslog.mdwn @@ -0,0 +1,107 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +[[!toc]] + +# IRC, unknown channel, unknown date + + <tschwinge> scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725 + I see that you intend(ed) to use syslog for logging debug messages. I + thought I'd point you to + http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html -- no + idea if that's still an issue or what went wrong at that time. Perhaps + you can have a look? + <scolobb> tschwinge: Thanks for information! Currently I'm logging some + debug messages to a simple file, but I'll now check whether the issue + you've pointed out is still present. + <scolobb> tschwinge: I am getting absolutely abnormal results: when I call + syslog() from a simple C program for the first time, the message goes to + the system log. However, any further calls to syslog() do just + nothing... I am able to send something to syslog only after reboot (it + doesn't help if I restart syslogd). + + +# IRC, freenode, #hurd, 2011-08-08 + + < pinotree> wow, `logger` + a simple C udp server can cause havoc + < pinotree> youpi: ever seen something like + http://paste.debian.net/hidden/72cf4b77/ ? + < pinotree> and then also other servers (like pflocal, pfinet, few more) + start becoming crazy (using 100% cpu) + < youpi> nope + < pinotree> iirc in one of the few tries i got the message "Resource lost." + from the closed ssh connection + < pinotree> i was trying to see why syslog doesn't work, but this basically + surprised me... + < pinotree> oh, i found an apparently working syslog daemon + < pinotree> dsyslog + < gg0> have you tried syslog-ng? IIRC it writes in /var/log/messages by + default. + < pinotree> yeah, it seems to stop receiving messages are few + < pinotree> gg0: are you using syslog-ng? + < gg0> pinotree: I should fire hurd vm up. I seem I kept dirty-patched + busybox syslog, I don't even know if it works, at least it starts + http://bugs.debian.org/636162 + < pinotree> maintainer said "not really" + < gg0> well, if all other syslogs use shm and sems, they won't work too, + right? + < youpi> shm should work with the latest libc + < youpi> what won't is sysv sem + < youpi> (i.e. semget) + + +IRC, OFTC, #debian-hurd, 2011-11-02: + + * pinotree sighs at #645790 :/ + <tschwinge> pinotree: W.r.t. 645790 -- yeah, ``someone'' should finally + figure out what's going on with syslog. + http://lists.gnu.org/archive/html/bug-hurd/2008-07/msg00152.html + <tschwinge> pinotree: And this... + http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html + <pinotree> tschwinge: i did that 20 invocations tests recently, and + basically none of them has been logged + <pinotree> tschwinge: when i started playing with logger more, as result i + had some server that started taking all the cpu, followed by other + servers and in the end my ssh connection were dropped and i had nothing + to do (not even login from console) + <tschwinge> pinotree: Sounds like ``fun''. Hopefully we can manage to + understand (and fix the underlying issue) why a simple syslog() + invocation can make the whole system instable. + <pinotree> tschwinge: to be honest, i got havoc in the system when i told + syslog to manually look for /dev/log (-u /dev/log), possibly alao when + telling to use a datagram socket (-d) + <pinotree> but even if a normal syslog() invocation does not cause havoc, + there's still the "lost messages" issue + <tschwinge> Yep. What I've been doing ever since, is deinstall all + *syslog* packages. + <tschwinge> This ``fixed'' all syslog() hangs. + + +# IRC, freenode, #hurd, 2012-03-28 + + <braunr> i can see lots of CRON processes hanging around + <braunr> pinotree: crontab -l was hanging too when trying to quickly see + what went wrong + <braunr> so it may be an unreleased lock of some kind + <antrik> braunr: do you have syslog installed by any chance?... + <antrik> IIRC that bug has never been fixed :-( + <braunr> yes syslogd is running + <antrik> that's probably the culprit then + <braunr> ok + <braunr> i'll just disable it for now then + <antrik> the error has existed for years + <antrik> was similar for me though: for a long time I have been hearing + about this issue, and only suddenly I started experiencing it myself... + <antrik> it depends on how many things are actually logged. IIRC the hang + happens when some client sends 128 messages to syslog or something like + that diff --git a/open_issues/system_call_mechanism.mdwn b/open_issues/system_call_mechanism.mdwn new file mode 100644 index 00000000..68418097 --- /dev/null +++ b/open_issues/system_call_mechanism.mdwn @@ -0,0 +1,56 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-05-07 + + <braunr> very simple examples: system calls use old call gates, which are + the slowest path to kernel space + <braunr> modern processors have dedicated instructions now + + +# IRC, freenode, #hurd, 2012-04-22 + + <braunr> rah: basically, system calls are slower on mach because they use + call gates instead of newer sysenter/sysexit + <youpi> braunr: sysenter/exit is a x86_64 thing + <braunr> rah: apart from that, the code can't get much simpler, and *I* + know, for i have studied it, and wrote a compatible version in a clone + attempt + <youpi> braunr: on a x86_64 port we'd probably use sysenter/exit + <braunr> youpi: no there are 32-bits instructions, i don't remember if + they're called sysenter, it's in my thesis though so i'm sure of it :) + <youpi> braunr: ah, the other part + <youpi> is linux-x86 using them? + <braunr> youpi: yes, glibc uses them + <youpi> and does it really change much nowadays? + <youpi> what is the actual difference between int 80 and sysenter? + <braunr> less checking + <youpi> checking what? + <youpi> the idt? + <braunr> ring levels for example + <youpi> well, checking a ring is fast :) + <braunr> depending on the original and requested levels, there are lookups + in tables + <braunr> sysenter always assume 3 to 0 and 0 to 3 for sysexit + <youpi> ah, also it assumes things about segments + <youpi> so that indeed makes context things simpler + <braunr> right + <braunr> but mach doesn't uses int 0x80 + <braunr> it uses an lcall + <braunr> which is a bit slower from what I could read some time ago + <braunr> (not sure if it's still relevant) + <youpi> actually in 64bit mode I had to catch lcall from the invalid + instruction trap + <youpi> perhaps it got dropped in 64bit mode diff --git a/open_issues/system_crash_nmap.mdwn b/open_issues/system_crash_nmap.mdwn new file mode 100644 index 00000000..25d9a1c6 --- /dev/null +++ b/open_issues/system_crash_nmap.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date: + + <Casper_> Hmm, `nmap hurd -p 1-` seems to reliably make a hurd machine reboot. diff --git a/open_issues/system_crash_pflocal_fifo.mdwn b/open_issues/system_crash_pflocal_fifo.mdwn new file mode 100644 index 00000000..1dddc44e --- /dev/null +++ b/open_issues/system_crash_pflocal_fifo.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date: + +`cat < /dev/zero | cat > /dev/null` will eventually make the system crash, +likewise when using a FIFO. + + <antrik> hm... VM activity seems much higher when running fifo than pfinet... may be the cause + <antrik> "zero filled" and "page faults" are serveral times higher with pipe than with pfinet + <antrik> (cow faults however are about the same...) + <antrik> pflocal is about the same as fifo + + <antrik> no, because it usually takes like 20 minutes until it crashes, sometimes much longer + + <antrik> not sure, but the longest so far was in the range of hours IIRC + + <antrik> I think I never tested what happens on "cat /dev/zero >/dev/null"... another thing yet to try + + <antrik> Linux BTW seems to employ some major VM trickery in this case -- dd shows a transfer rate of 10 GB/s... + + <antrik> no, no anomalies in vmstat + <antrik> the only observation I made is that number of page faults and some other number rise pretty quickly with pflocal and fifo, but not with pfinet + <antrik> I guess that's somehow related to the fact that pfinet doesn't crash -- though I guess the difference is simply that pfinet is way slower... + <antrik> (haven't checked that, though) + + <antrik> BTW, I'm not sure you got it right: the test case is "cat /dev/zero|cat >/dev/null", *not* "cat /dev/zero >/dev/null" + + <antrik> OK, "cat /dev/zero|tail -c 1" also crashes, so it's definitely not related to /dev/null + <antrik> "dd if=/dev/zero|tail -c 1" crashes as well + <antrik> but "tail -c 1 /dev/zero" doesn't seem to + <antrik> cool... running multiple instances of the pipe test also considerably speeds up the crash diff --git a/open_issues/system_initialization.mdwn b/open_issues/system_initialization.mdwn new file mode 100644 index 00000000..9048b615 --- /dev/null +++ b/open_issues/system_initialization.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_hurd]] + +IRC, freenode, #hurd, 2011-03-30 + + <kilobug> init=/bin/sh hack doesn't work for GNU/Hurd ? + <antrik> kilobug: I don't think you can override init on Hurd. the init + server is actually involved in bootstrapping part of the system core + <antrik> at some point we discussed the possibility to reduce the Hurd init + server to *only* do that, and then pass on to standard sysv init... with + that it could actually work + +--- + + * [[systemd]], etc. diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn new file mode 100644 index 00000000..1d774307 --- /dev/null +++ b/open_issues/systemd.mdwn @@ -0,0 +1,150 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + * <http://www.freedesktop.org/wiki/Software/systemd> + + * <http://0pointer.de/blog/projects/systemd.html>, + <http://0pointer.de/blog/projects/systemd-update.html> + + * <http://lwn.net/Articles/389149/> + +Will need to have something like Linux' +[*cgroups*](http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/cgroups.txt;hb=HEAD). +Introduction: [*Ressourcen-Verwaltung mit Control Groups (cgroups)* +(german)](http://www.pro-linux.de/artikel/2/1464/ressourcen-verwaltung-mit-control-groups-cgroups.html), +Daniel Gollub, Stefan Seyfried, 2010-10-14. + +Likely there's also some other porting needed. + + +# IRC, OFTC, #debian-hurd, 2011-05-19 + + <pinotree> pochu: http://news.gmane.org/gmane.comp.gnome.desktop - the + "systemd as dependency" and all the messages in it don't give me a bright + future for gnome on hurd... + <pochu> yeah, I've read the thread + <pochu> it's only a proposal so far... hopefully it'll be rejected, or they + will only accept the interfaces that other OSes can implement... + <pochu> we'll see + <pinotree> you can always help me with kde on hurd, would be nice ;) + <pochu> hehe + <pinotree> pochu: well, even if the depenency is rejected, the whole «don't + give a damn about non-linux and only bless linux for the "gnome os"» is a + bit... worrying attitude + <pochu> yeah... it doesn't come from all the community though + <pochu> I'm sure some people have always thought that way + <tschwinge> Or we could get systemd going? :-) + <pochu> good luck with that :p + <guillem> tschwinge: haha!? :) + <tschwinge> That bad? + <guillem> tschwinge: if you mean by that forking indefinitely then maybe + <guillem> tschwinge: upstream has expressely stated multiple times, no + interest whatsoever in any kind of portability to anything non-Linux + <guillem> or even older Linux versions! + <guillem> to the point of rejecting patches, because they "clutter" the + source code... + <tschwinge> Well, then let's ``just'' implement the Linux interfaces. :-) + <guillem> tschwinge: then you'll be always playing catch up + <guillem> tschwinge: for example several of the Linux-only things upstream + makes heavy use of, are pretty recent Linux-only additions to the kernel, + but equivalents have been present on FreeBSD for years + <tschwinge> Yeah. I'm half-serious, half-joking. + <tschwinge> I haven't looked at the systemd code at all. + <guillem> + https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html + for a list of its dependencies + <guillem> some are just glibc extensions though + <guillem> and some are IMO optional and should be conditionalized, but... + <guillem> pochu: I don't think that attitude is that old, there was a time + when Linux was not used widely, or even that functional, I think it has + been taking strength since the Linux Plumbers Cartel started :) + <guillem> as in one thing is not caring about anything non-Linux, the other + is outright rejecting portability fixes + <guillem> tschwinge: in any case, these "recent" events are "pissing me + off" to the point of having considered several times implementing + portable replacements for some of those Utopia projects, the problem as + always is time though :) + <guillem> tschwinge: and the issue is not only with systemd, upstart's + upstream has the same approach to portability, if you want to port it, + you'll have to maintain a fork + <pochu> let's create our own init system, make it better than anyone else, + and when people start switching to it, let's start using hurd-only APIs + :) + <tschwinge> We already had someone work on that. Like ten years ago. DMD. + Daemon Managing Daemons. <http://directory.fsf.org/project/DMD/> + <guillem> the real problem with that attitude is not the lack of care for + portabilty, the real problem is that these people are pushing for their + stuff all over the stack, and most of the time deprecating their own + stuff after a while when they have rewritten it from scratch, leaving the + burden of maintaining the old stuff to the other ports + <guillem> witness HAL, ConsoleKit, etc etc + <guillem> (anyway enough ranting I guess :) + <tschwinge> Yeah, it's true, though. + <pochu> agreed + + +# Requires Interfaces + +In the thread starting +[here](http://lists.debian.org/debian-devel/2011/07/threads.html#00269), a +[message](http://lists.debian.org/debian-devel/2011/07/msg00281.html) has been +posted that contains the following list (no claim for completeness) of +interfaces that are used in (two source code files of) systemd: + + * cgroups + * namespaces + * selinux + * autofs4 + * capabilities + * udev + * oom score adjust + * RLIMIT_RTTIME + * RLIMIT_RTPRIO + * ionice + * SCHED_RESET_ON_FORK + * /proc/$PID/stat + * fanotify + * inotify + * TIOCVHANGUP + * IP_TRANSPORT + * audit + * F_SETPIPE_SZ + * CLONE_xxx + * BTRFS_IOC_DEFRAG + * PR_SET_NAME + * PR_CAPBSET_DROP + * PR_SET_PDEATHSIG + * PR_GET_SECUREBITS + * /proc/$PID/comm + * /proc/$PID/cmdline + * /proc/cmdline + * numerous GNU APIs like asprintf + * SOCK_CLOEXEC, O_CLOEXEC + * /proc/$PID/fd + * /dev/tty0 + * TIOCLINUX + * VT_ACTIVATE + * TIOCNXCL + * KDSKBMODE + * /dev/random + * /dev/char/ + * openat() and friends + * /proc/$PID/root + * waitid() + * /dev/disk/by-label/ + * /dev/disk/by-uuid/ + * /sys/class/tty/console/active + * /sys/class/dmi/id + * /proc/$PID/cgroup + * \033[3J + * /dev/rtc + * settimeofday() and its semantics diff --git a/open_issues/term_blocking.mdwn b/open_issues/term_blocking.mdwn new file mode 100644 index 00000000..19d18d0e --- /dev/null +++ b/open_issues/term_blocking.mdwn @@ -0,0 +1,128 @@ +[[!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 +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]] + +There must be some blocking / dead-locking (?) problem in `term`. + +[[!toc]] + + +# Original Findings + + # w | grep [t]sch + tschwing p1 192.168.10.60: Tue 8PM 0:03 2172 /bin/bash + tschwing p2 192.168.10.60: Tue 4PM 40hrs 689 emacs + tschwing p3 192.168.10.60: 8:52PM 11:37 15307 /bin/bash + tschwing p0 192.168.10.60: 6:42PM 11:47 8104 /bin/bash + tschwing p8 192.168.10.60: 8:27AM 0:02 16510 /bin/bash + +Now open a new screen window, or login shell, or... + + # ps -Af | tail + [...] + tschwinge 16538 676 p6 0:00.08 /bin/bash + root 16554 128 co 0:00.09 ps -Af + root 16555 128 co 0:00.01 tail + +`bash` is started (on `p6`), but newer makes it to the shell promt; doesn't +even start to execute `.bash_profile` / `.bashrc`. The next shell started, on +the next available pseudoterminal, will work without problems. + +The `term` on `p6` has already been running before: + + # ps -Af | grep [t]typ6 + root 6871 3 - 5:45.86 /hurd/term /dev/ptyp6 pty-master /dev/ttyp6 + +In this situation, `w` will sometimes report erroneous values for *IDLE* +for the process using that terminal. + +Killed that `term` instance, and things were fine again. + + +All this reproducible happens while running the [[GDB testsuite|gdb]]. + +--- + +Have a freshly started shell blocking on such a `term` instance. + + $ ps -F hurd-long -p 1766 -T -Q + PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 1766 0 3 1 1 6 131M 1.14M 0.0 0:28.85 5:40.91 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3 + 0 0.0 0:05.76 1:08.48 + 1 0.0 0:00.00 0:00.01 + 2 0.0 0:06.40 1:11.52 + 3 0.0 0:05.76 1:09.89 + 4 0.0 0:05.42 1:06.74 + 5 0.0 0:05.50 1:04.25 + +... and after 5:45 h: + + $ ps -F hurd-long -p 21987 -T -Q + PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 21987 1001 676 21987 21987 2 148M 2.03M 0.0 0:00.02 0:00.07 /bin/bash + 0 0.0 0:00.02 0:00.07 + 1 0.0 0:00.00 0:00.00 + + $ ps -F hurd-long -p 1766 -T -Q + PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 1766 0 3 1 1 6 131M 1.14M 0.0 0:29.04 5:42.38 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3 + 0 0.0 0:05.76 1:08.48 + 1 0.0 0:00.00 0:00.01 + 2 0.0 0:06.41 1:11.90 + 3 0.0 0:05.82 1:10.28 + 4 0.0 0:05.52 1:07.06 + 5 0.0 0:05.52 1:04.63 + + $ sudo gdb /hurd/term 1766 + [sudo] password for tschwinge: + GNU gdb (GDB) 7.0-debian + Copyright (C) 2009 Free Software Foundation, Inc. + License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> + This is free software: you are free to change and redistribute it. + There is NO WARRANTY, to the extent permitted by law. Type "show copying" + and "show warranty" for details. + This GDB was configured as "i486-gnu". + For bug reporting instructions, please see: + <http://www.gnu.org/software/gdb/bugs/>... + Reading symbols from /hurd/term...Reading symbols from /usr/lib/debug/hurd/term...done. + (no debugging symbols found)...done. + Attaching to program `/hurd/term', pid 1766 + [New Thread 1766.1] + [New Thread 1766.2] + [New Thread 1766.3] + [New Thread 1766.4] + [New Thread 1766.5] + [New Thread 1766.6] + Reading symbols from /lib/libhurdbugaddr.so.0.3...Reading symbols from /usr/lib/debug/lib/libhurdbugaddr.so.0.3... + [System doesn't respond anymore, but no kernel crash.] + +--- + +The very same behavior is still observable as of 2011-03-24. + +Next: rebooted; on console started root shell, screen, a few spare windows; as +user started GDB test suite, noticed the PTY it's using; in a root shell +started GDB (the system one, for `.debug` stuff) on `/hurd/term`, `set +noninvasive on`, attach to the *term* that GDB is using. + + +[[2011-07-04]]. + + +# Formal Verification + +This issue may be a simple programming error, or it may be more complicated. + +Methods of [[formal_verification]] should be applied to confirm that there is +no error in `/hurd/term`'s logic itself. There are tools for formal +verification/[[code_analysis]] that can likely help here. + +There is a [[!FF_project 277]][[!tag bounty]] on this task. diff --git a/open_issues/term_blocking/2011-07-04.mdwn b/open_issues/term_blocking/2011-07-04.mdwn new file mode 100644 index 00000000..0f302409 --- /dev/null +++ b/open_issues/term_blocking/2011-07-04.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]]."]]"""]] + +GDB testsuite makes a term process go bonkers. The testsuite is terminated. +The term process remanins. Next, a new shell (bash) is started that connects +to this term process -- and hangs. + +Hung bash process (27834), term (22634). + + # portinfo -t 22634 27834 + 5 => 58: receive + 11 => 18: receive + 21 => 53: receive + 26 => 51: receive + 27 => 56: receive + 28 => 48: receive + 30 => 54: receive + +GDB on bash: + + #0 0x010ab12c in _hurd_intr_rpc_msg_in_trap (msg=0x102383c, option=3, send_size=44, rcv_size=2092, rcv_name=9, timeout=0, notify=0) at intr-msg.c:134 + err = <value optimized out> + err = <value optimized out> + user_option = 3 + user_timeout = 0 + m = 0x102383c + msgh_bits = 5395 + remote_port = 27 + msgid = 21001 + __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg" + #1 0x01235195 in __io_read (io_object=27, data=0x1024148, dataCnt=0x102414c, offset=-1, amount=1) at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_io_read.c:138 + Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 1768, msgh_remote_port = 27, msgh_local_port = 9, msgh_seqno = 0, msgh_id = 21001}, offsetType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, + msgt_unused = 0}, offset = -1, amountType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, amount = 1}, Out = {Head = {msgh_bits = 5395, msgh_size = 1768, msgh_remote_port = 27, + msgh_local_port = 9, msgh_seqno = 0, msgh_id = 21001}, RetCodeType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, dataType = {msgtl_header = {msgt_name = 255, + msgt_size = 255, msgt_number = 4095, msgt_inline = 1, msgt_longform = 1, msgt_deallocate = 1, msgt_unused = 1}, msgtl_name = 8194, msgtl_size = 4097, msgtl_number = 1}, + data = "# /etc/inputrc - global inputrc for libreadline\n# See readline(3readline) and `info rluserman' for more information.\n\n# Be 8 bit clean.\nset input-meta on\nset output-meta on\n\n# To allow the use of 8bit"...}} + msg_result = <value optimized out> + msgh_size = <value optimized out> + #2 0x010afbb1 in readfd (port=27) at fd-read.c:34 + nbytes = 0x9 + nread = 40 + data = 0x44 <Address 0x44 out of bounds> + offset = 12884901897 + #3 0x010b5de5 in _hurd_ctty_input (port=26, ctty=27, rpc=0x1024154) at ctty-input.c:36 + err = 19156808 + #4 0x010af53e in _hurd_fd_read (fd=0x1244f48, buf=0x102420f, offset=-1) at fd-read.c:39 + __ulink = {resource = {next = 0x0, prevp = 0x1244f4c}, thread = {next = 0x1024160, prevp = 0x1246c5c}, cleanup = 0x10b75a0 <_hurd_port_cleanup>, cleanup_data = 0x1a} + __ctty_ulink = {resource = {next = 0x0, prevp = 0x1244f5c}, thread = {next = 0x0, prevp = 0x1024180}, cleanup = 0x10b75a0 <_hurd_port_cleanup>, cleanup_data = 0x1b} + ctty = 27 + crit = 0x1246808 + __result = 16925048 + port = <value optimized out> + err = <value optimized out> + data = 0x102420f "" + nbytes = 0x10241f8 + nread = 1 + #5 0x0116c080 in __libc_read (fd=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece. + ) at ../sysdeps/mach/hurd/read.c:27 + descriptor = <error reading variable descriptor (DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece.)> + err = <value optimized out> + #6 0x080cdaac in ?? () + No symbol table info available. + #7 0x080cdf88 in ?? () + No symbol table info available. + #8 0x080baff7 in ?? () + No symbol table info available. + #9 0x080bb435 in ?? () + No symbol table info available. + #10 0x080507e7 in ?? () + No symbol table info available. + #11 0x0804fc36 in ?? () + No symbol table info available. + #12 0x08052f22 in ?? () + No symbol table info available. + #13 0x08055dab in ?? () + No symbol table info available. + #14 0x0804d960 in ?? () + No symbol table info available. + #15 0x0804da1f in ?? () + No symbol table info available. + #16 0x0804dc65 in ?? () + No symbol table info available. + #17 0x0804d215 in ?? () + No symbol table info available. + #18 0x010b906b in __libc_start_main (main=0x804c450, argc=1, ubp_av=0x1024dd4, init=0x80d7ff0, fini=0x80d7fe0, rtld_fini=0xf330, stack_end=0x1024dcc) at libc-start.c:257 + result = <value optimized out> + #19 0x0804b281 in ?? () + No symbol table info available. + +GDB on term: + + 5 Thread 22634.5 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 4 Thread 22634.4 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 3 Thread 22634.3 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 2 Thread 22634.2 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + * 1 Thread 22634.1 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + + Thread 5 (Thread 22634.5): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x129bf10, option=2050, send_size=0, rcv_size=8192, rcv_name=16, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x0108ae24 in __mach_msg_server_timeout (demux=0x125fd1c, max_size=8192, rcv_name=16, option=2048, timeout=0) at msgserver.c:101 + request = 0x129bf10 + reply = 0x129df20 + mr = <value optimized out> + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #3 0x01058e45 in thread_function (master=0) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:136 + timeout = 0 + err = <value optimized out> + hook = 0 + global_timeout = 0 + thread_timeout = 0 + bucket = 0x805e1f0 + lock = 0 + totalthreads = 4 + nreqthreads = 3 + #4 0x01052b91 in cthread_body (self=0x8061460) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300 + t = 0x80619a8 + #5 0x00000000 in ?? () + No symbol table info available. + + Thread 4 (Thread 22634.4): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x128df20, option=2050, send_size=0, rcv_size=8192, rcv_name=16, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x0108ae24 in __mach_msg_server_timeout (demux=0x125fd1c, max_size=8192, rcv_name=16, option=2048, timeout=0) at msgserver.c:101 + request = 0x128df20 + reply = 0x128bf10 + mr = <value optimized out> + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #3 0x01058e45 in thread_function (master=0) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:136 + timeout = 0 + err = <value optimized out> + hook = 0 + global_timeout = 0 + thread_timeout = 0 + bucket = 0x805e1f0 + lock = 0 + totalthreads = 4 + nreqthreads = 3 + #4 0x01052b91 in cthread_body (self=0x805f800) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300 + t = 0x805f788 + #5 0x00000000 in ?? () + No symbol table info available. + + Thread 3 (Thread 22634.3): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x127df20, option=2050, send_size=0, rcv_size=8192, rcv_name=16, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x0108ae24 in __mach_msg_server_timeout (demux=0x125fd1c, max_size=8192, rcv_name=16, option=2048, timeout=0) at msgserver.c:101 + request = 0x127df20 + reply = 0x127bf10 + mr = <value optimized out> + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #3 0x01058e45 in thread_function (master=0) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:136 + timeout = 0 + err = <value optimized out> + hook = 0 + global_timeout = 0 + thread_timeout = 0 + bucket = 0x805e1f0 + lock = 0 + totalthreads = 4 + nreqthreads = 3 + #4 0x01052b91 in cthread_body (self=0x805ec30) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300 + t = 0x805ebb8 + #5 0x00000000 in ?? () + No symbol table info available. + + Thread 2 (Thread 22634.2): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x126df20, option=3, send_size=32, rcv_size=4096, rcv_name=12, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x0108ae99 in __mach_msg_server_timeout (demux=0x109b9d0 <msgport_server>, max_size=4096, rcv_name=12, option=0, timeout=0) at msgserver.c:151 + request = 0x126ef30 + reply = 0x126df20 + mr = <value optimized out> + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #3 0x0108af6b in __mach_msg_server (demux=0x109b9d0 <msgport_server>, max_size=4096, rcv_name=12) at msgserver.c:196 + No locals. + #4 0x0109b99f in _hurd_msgport_receive () at msgportdemux.c:68 + No locals. + #5 0x01052b91 in cthread_body (self=0x805da48) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300 + t = 0x805d9d0 + #6 0x00000000 in ?? () + No symbol table info available. + + Thread 1 (Thread 22634.1): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x125ba2c, option=2, send_size=0, rcv_size=24, rcv_name=10, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x010516b8 in cproc_block () at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cprocs.c:638 + msg = {msgh_bits = 17345214, msgh_size = 18972660, msgh_remote_port = 17163428, msgh_local_port = 134764952, msgh_seqno = 19249824, msgh_id = 18935134} + waiter = 0x1240808 + new = <value optimized out> + p = 0x805d988 + #3 0x01053589 in hurd_condition_wait (m=0x805d89c) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cancel-cond.c:86 + p = 0x805d988 + cancel = <value optimized out> + __PRETTY_FUNCTION__ = "hurd_condition_wait" + c = 0x805e498 + #4 0x08052abf in trivfs_S_io_read (cred=0x8084b78, reply=32, replytype=18, data=0x125bb44, datalen=0x125bb40, offset=-1, amount=1) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./term/users.c:695 + cancel = <value optimized out> + i = <value optimized out> + max = <value optimized out> + cp = <value optimized out> + avail = <value optimized out> + #5 0x0104053b in _Xio_read (InHeadP=0x125dc70, OutHeadP=0x125bc60) at ioServer.c:234 + dataCnt = 2048 + msgh_simple = <value optimized out> + io_object = 0x8084b78 + dataP = 0x125bc8c "\350\003" + #6 _Xio_read (InHeadP=0x125dc70, OutHeadP=0x125bc60) at ioServer.c:148 + In0P = 0x125dc70 + OutP = 0x125bc60 + offsetCheck = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0} + amountCheck = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0} + #7 0x0104065e in trivfs_io_server (InHeadP=0x125dc70, OutHeadP=0x125bc60) at ioServer.c:2005 + InP = 0x125dc70 + OutP = 0x125bc60 + routine = <value optimized out> + #8 0x01038f17 in trivfs_demuxer (inp=0x125dc70, outp=0x125bc60) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libtrivfs/demuxer.c:32 + No locals. + #9 0x080537a8 in demuxer (inp=0x125dc70, outp=0x125bc60) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./term/main.c:68 + No locals. + #10 0x01059045 in internal_demuxer (inp=0x125dc70, outheadp=0x125bc60) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:101 + err = <value optimized out> + spawn = <value optimized out> + status = <value optimized out> + pi = <value optimized out> + link = {thread = 3, next = 0x0, prevp = 0x8084b94, notifies = 0x0, interrupted_next = 0x0} + outp = 0x125bc60 + __PRETTY_FUNCTION__ = "internal_demuxer" + [System crashed.] diff --git a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn new file mode 100644 index 00000000..72af3f35 --- /dev/null +++ b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)'"]] + +[[!tag open_issue_hurd]] + +<http://bugs.debian.org/46859>, <http://bugs.debian.org/195360> + +IRC, unknown channel, unknown date: + + <youpi> azeem, marcus: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)' failed + <youpi> I actually don't understand this assertion + <youpi> it's just before __spin_lock (&ss->critical_section_lock); + <youpi> why should one check that a lock is free before taking it ? + <youpi> just the same in hurdexec.c + <youpi> (no, ss is not our own sigstate, so it's not safe to assume no other path can take it) + <youpi> there's another one in sysdeps/mach/hurd/spawni.c + <youpi> and jmp-unwind.c + <antrik> youpi: why do you think it's nonsense?... the fact that we take the lock (so we can't be interrupted) doesn't mean we are willing to wait for others to release the lock... maybe the code path should never be reached while others have a lock, or something + <youpi> then it's useless to take the lock + <youpi> "we take the lock (so we can't be interrupted)": no, it's not _our_ lock here, it's the lock of the thread we want to cancel + <antrik> what exactly is cancelling a thread?... (sorry, I don't really have experience with thread programming) + <youpi> ~= killing it + <antrik> well, we take the lock so nobody can mess with the thread while we are cancelling it, no?... + <youpi> yes + <youpi> that is fine + <youpi> but checking that the lock is free before taking it doesn't make sense + <youpi> why nobody should be able to take the lock ? + <youpi> and if nobody is, why do we take it ? (since nobody would be able to take it) + <antrik> well, maybe after taking the lock, we do some action that might result in others trying to take it... + <youpi> nope: look at the code :) + <youpi> or maybe the cancel_hook, but I really doubt it + diff --git a/open_issues/thread_numbering_of_ps_and_gdb.mdwn b/open_issues/thread_numbering_of_ps_and_gdb.mdwn new file mode 100644 index 00000000..7058cfe2 --- /dev/null +++ b/open_issues/thread_numbering_of_ps_and_gdb.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +It appears to [[me|tschwinge]] that `ps -T` enumerates thread IDs starting with +zero, and GDB starting with one. This should be unified. + +Or instead of manually allocating numbers, some other handle should be used, +that has a global meaning for the running GNU Mach kernel, or a process-wide +meaning, for example a port number. + +[[!tag open_issue_hurd open_issue_gdb]] + + +Also see [[GDB thread IDs]]. diff --git a/open_issues/threads_issues.mdwn b/open_issues/threads_issues.mdwn new file mode 100644 index 00000000..aec216e0 --- /dev/null +++ b/open_issues/threads_issues.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +List of issues w.r.t. the Hurd's many-threads paradigm. + +[[!tag open_issue_hurd]] + + * [[fsync]] diff --git a/open_issues/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/time.mdwn b/open_issues/time.mdwn new file mode 100644 index 00000000..ab239aef --- /dev/null +++ b/open_issues/time.mdwn @@ -0,0 +1,69 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +Neither the `time` executable from the GNU time package work completely +correctly, nor does the GNU Bash built-in one. + + tschwinge@flubber:~ $ \time sleep 2 + 0.00user 0.00system 9:38:00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + tschwinge@flubber:~ $ \time sleep 4 + 0.00user 0.00system 18:50:25elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + tschwinge@flubber:~ $ \time sleep 6 + 0.00user 0.00system 28:00:53elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + tschwinge@flubber:~ $ time sleep 2 + + real 0m2.093s + user 0m0.000s + sys 0m0.011s + tschwinge@flubber:~ $ time sleep 4 + + real 0m4.083s + user 0m0.000s + sys 0m0.010s + tschwinge@flubber:~ $ time sleep 6 + + real 0m6.164s + user 0m0.000s + sys 0m0.010s + +GNU time's *elapsed* value is off by some factor. + + $ \time factor 1111111111111111111 + 1111111111111111111: 1111111111111111111 + 0.00user 0.00system 52:39:24elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + $ time factor 1111111111111111111 + 1111111111111111111: 1111111111111111111 + + real 0m11.424s + user 0m0.000s + sys 0m0.010s + +As above; also here all the running time should be attriuted to *user* time. +This is probably a [[!taglink open_issue_gnumach]]. + + +# 2011-09-02 + +Might want to revisit this, and take Xen [[!tag open_issue_xen]] into account +-- I believe flubber has already been Xenified at that time. + + +## IRC, freenode, #hurd, 2011-09-02 + +While testing some [[performance/IPC_virtual_copy]] performance issues: + + <tschwinge> And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k + running, a parallel sleep 10 takes about 20 s (on strauss). diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn new file mode 100644 index 00000000..bd9abcf9 --- /dev/null +++ b/open_issues/translate_fd_or_port_to_file_name.mdwn @@ -0,0 +1,87 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_hurd]] + +[[!toc]] + + +# IRC, freenode, #hurd, June (?) 2010 + + <pochu> is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port? + <marcusb> there is a way + <pochu> marcusb: which one would that be? + <marcusb> I forgot + <marcusb> there is an implementation in libc + <marcusb> realpath has a similar job + <marcusb> but that's not what I mean + <marcusb> pochu: maybe I am misremembering. But it was something where you keep looking up .. and list that directory, looking for the node with the ID of the node you had .. for + <marcusb> maybe it works only for directories + <marcusb> yeah + <marcusb> pochu: check the getcwd() implementation of libc + <marcusb> sysdeps/mach/hurd/getcwd.c + <marcusb> _hurd_canonicalize_directory_name_internal + * pochu looks + <pochu> marcusb: interesting + <pochu> though that is for dirs, and doesn't seem to be extensible to files, as you cannot lookup for ".." under a file + <marcusb> right + <pochu> oh you already said that :) + <marcusb> actually, I am not sure that's correct + <marcusb> it's probably correct, but there is no reason why looking .. up on a file couldn't return the directory it's contianed in + <pochu> I don't know the interfaces or the Hurd internals very well yet, but it would look strange to me if you could do that + <marcusb> the hurd is strange + <pochu> it sounds like if you could `ls getcwd.c/..` to get sysdeps/mach/hurd/ :-) + <marcusb> yep + <pochu> ok. interesting + <marcusb> you wouldn't find "ls foo.zip/.." very strange, wouldn't you? + <pochu> I guess not if `ls foo.zip` listed the contents of foo.zip + <marcusb> there you go + <marcusb> or the other way round: would you be surprised if "cat somedir" would work? + <pochu> I think so. if it did, what would it do? + <marcusb> originally, cat dir would list the directory content! + <marcusb> in the old unix times + <pochu> I was surprised the first time I typed `vi somedir` by accident + <marcusb> and some early BSDs + * pochu feels young :-) + <marcusb> he don't worry, I didn't see those times either + <marcusb> technically, files and directories are implemented in the same way in the hurd, they both are objects implementing the fs.defs interface + <marcusb> which combines file and directory operations + <marcusb> of course, files and directories implement those functions differently + <antrik> marcusb: do you know why this behavior (cat on directories) was changed? + + +# IRC, freenode, #hurd, 2011-07-13 + +A related issue: + + <braunr> rbraun@nordrassil:~$ vminfo $$ | wc -l + <braunr> 1039 + <braunr> any idea why a shell would consume more than 1039 map entries ? + <braunr> (well, not more actually) + <braunr> even the kernel and ext2fs have around 100 + <braunr> (the kernel has actually only 23, which is very good and expected) + <tschwinge> braunr: I agree that having some sort of debugging information + for memory objects et al. would be quite hand. To see where they're + coming from, etc. + <braunr> tschwinge: this would require naming objects at the mach level + <braunr> e.g. when creating an object + <braunr> giving it the path of a file for example + <tschwinge> braunr: I have recently seen something (due to youpi fixing a + bug) that bash is doing its own memory management. Perhaps all these are + such regions? + <tschwinge> braunr: For example, yes. + <braunr> what ? + <braunr> ?! + <tschwinge> braunr: + http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00097.html + <braunr> i see + +Also see email thread starting at [[!message-id +"20110714082216.GA8335@sceen.net"]]. diff --git a/open_issues/translator_environment_variables.mdwn b/open_issues/translator_environment_variables.mdwn new file mode 100644 index 00000000..cae5a494 --- /dev/null +++ b/open_issues/translator_environment_variables.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <cfhammar> BTW, is settrans -a supposed to clear all env variables? + <cfhammar> or can I consider it a bug ;-) + <cfhammar> scolobb: yeah, seems the problem is in libfshelp + <scolobb> cfhammar: Are you talking about fshelp_start_translator_long? + <scolobb> (I can remember that it does something to the environment indeed) + <cfhammar> scolobb: yes, I think it's the culprit + <cfhammar> clearing the environment makes sense for passive translators I guess, but not active ones + <scolobb> Hm, searching ``env'' in hurd/libfshelp/start-translator-long.c gives me nothing :-( + <scolobb> I think the problem might be in the fact that fshelp_start_translator_long just doesn't copy the environment, but I may be wrong. + <cfhammar> scolobb: yeah, that's my guess also + <scolobb> Well, I don't know proc, but there might be a way to copy the environment to a task when you know its ID, what do you think? + <scolobb> I can see proc_set_arg_locations in process.defs, which sees to set something connected with environment, but I'm not sure whether it suits your needs. + <cfhammar> scolobb: it seems that the env isn't passed to file_exec in fshelp_start_translator_long + <scolobb> cfhammar: Yeah, that's right + <scolobb> I wonder what could the motivation for not passing the environment to a child process + <cfhammar> hmm... fshelp_start_translator_long parameterizes everything except env... + <cfhammar> perhaps there needs to be a fshelp_start_translator_longer ;-) diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn new file mode 100644 index 00000000..14ea1c6d --- /dev/null +++ b/open_issues/translator_stdout_stderr.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2008, 2009, 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 +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]] + +There have been several discussions and proposals already, about adding a +suitable logging mechanism to translators, for example. + + +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. + + +IRC, freenode, #hurd, 2011-11-06 + + <youpi> about CLI_DEBUG, you can use #define CLI_DEBUG(fmt, ...) { + fprintf(stderr, fmt, ## __VA_ARGS__); fflush(stderr); } + <tschwinge> Isn't stderr in auto-flush mode by default? + <tschwinge> man setbuf: The standard error stream stderr is always + unbuffered by default. + <youpi> tschwinge: "by default" is the important thing here + <youpi> in the case of translators iirc stderr is buffered + <tschwinge> youpi: Oh! + <tschwinge> That sounds wrong. + + +IRC, freenode, #hurd, 2011-11-23 + + <braunr> we'd need a special logging task for hurd servers + <pinotree> if syslog would work, that could be used optionally + <braunr> no, it relies on services provided by the hurd + <braunr> i'm thinking of something using merely the mach interface + <braunr> e.g. using mach_msg to send log messages to a special port used to + reference the logging service + <braunr> which would then store the messages in a circular buffer in ram + <braunr> maybe sending to syslog if the service is available + <braunr> the hurd system buffer if you want diff --git a/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn b/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn new file mode 100644 index 00000000..5d3c3aab --- /dev/null +++ b/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn @@ -0,0 +1,148 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd open_issue_glibc]] + +bug-hurd email from 2010-07-28: *O_NOTRANS & O_NOFOLLOW* + +2010-07-29, #hurd + + <antrik> cfhammar: I think that touches on a rather fundamental problem... it's always hard to decide how to handle translators, as the most useful approach depends a lot on context + <antrik> this was actually part of the idea behind namespace-based translator selection + <cfhammar> or perhaps we should just drop the whole O_NOFOLLOW == O_NOTRANS and only apply it for link like translators + <pochu> cfhammar: from what I read in [glibc]/hurd/lookup-retry.c, the problem is that some translators can lie about that + <antrik> cfhammar: at some point I considered the possibility of adding a couple of special flags describing translators ("link" and "device" being some, but also introducing a few new ones) to decide standard behaviour in various situations + <pochu> so you can't really know whether they are links without O_NOTRANS + <cfhammar> pochu: yeah, this would have to be considered carefully + <pochu> antrik: care to explain what namespace based translator selection means? :) + <antrik> pochu: the basic idea is that you add special suffixes to the file name during a lookup, which change the behaviour of lookups + <antrik> the most basic use would be adding a suffix that automatically runs an annonymous translator on the file + <cfhammar> antrik: doesn't stat cover most of those flags (except for firmlink i guess) + <antrik> (scolobb mostly implemented that part) + <antrik> but the idea was also to selectively activate/deactivate static translators based on patterns + <antrik> (this is implemented partially, but recursion is completely missing so far) + <antrik> cfhammar: some of them, yes. but I think there are some cases where the standard stat information is not enough to decide on useful handling + <antrik> let's take the example of a translator that mangles the underlying file -- like xmlfs, mboxfs etc. + <antrik> these aren't device file nor links, but should not really be handled like "normal" (store) filesystems either + <antrik> hm... is there any information in the stat that indicates mount points? + <antrik> I guess that would be good enough to flag "normal" filesystems + <pochu> I'm not sure I understand. you add a suffix during a lookup, based on what? whatever, including e.g. flags? + <antrik> pochu: well, an exmple would be "cat foo.gz,,u" + <antrik> where "u" would be a shorthand for "unzip" + <antrik> and it would launch a translator that uncompresses the underlying file + <pochu> what if there are a foo.gz and a foo.gz,,u files? + <antrik> (I think storeio with gzip store can do that... though some more generic translator might be useful, to cover other compression/archieve types as well) + <antrik> pochu: than you are SOL ;-) + <antrik> pochu: I chose ",," as the suffix after some careful examination that this is *extremely* unlikely to occur in normal use + <antrik> pochu: actually, we introduced an escaping scheme too, so it is still possible to access files with ",," in the name... but that's of limited use, as programs not aware of this will still break + <cfhammar> hmm i wonder why glibc handles O_NOFOLLOW to begin with, since the test it does presumes trust in the containing directory the fs could do it just as securely + <antrik> cfhammar: the FS could do what? + <pochu> another problem I've found is that an open(symlink, O_RDONLY | O_NOFOLLOW, 0) should fail with ELOOP according to POSIX, but it doesn't fail on Hurd + <antrik> pochu: yeah, saw that + <antrik> shouldn't be too hard to fix I hope?... + <cfhammar> antrik: libc test whether the node is a symlink or a (trusted) root owned translator, which it would follow + <pochu> antrik: probably not, though I haven't looked at it closely + <antrik> cfhammar: in what situation would the filesystem do the test? + <antrik> cfhammar: and what advantage would it have over the current approach? + <antrik> pochu: OK + <cfhammar> antrik: the point of the test is to approximate symlink vs. mount point but the fs seems to be in a better position to answer this + <antrik> cfhammar: why? I think this information should be fully available to glibc... if it's not, I'd consider this a bug, or at least a major omission + <cfhammar> antrik: well take fifos for instance, they should be considered part of the containing filesystem but would not by glibc + <cfhammar> antrik: we could make an exception in glibc for fifos but not for other future situations in new translators + <cfhammar> antrik: i mean, we could but this leaves control at the translators hand and let different translators handle things their own way + <cfhammar> generally, it seems more flexible to leave policy to servers rather than to bake it into the (implicit) protocol (which glibc implements) + <antrik> cfhammar: I don't see though why handling it in the filesystem would help here... if the filesystem has the information about how the translator should be handled, it can pass it to the clients + <antrik> hm... that's actually a tricky point. we have many situations where we have to choose between handling things in the client library or server-side... I'm haven't really formed an opinion yet which is preferable in general + <pochu> with cfhammar's proposal, you wouldn't need O_NOTRANS when you specify O_NOFOLLOW, right? + <cfhammar> pochu: i don't think my proposal would even work with O_NOTRANS + <antrik> cfhammar: hm, perhaps we are talking past each other. do you want the handling to be in the filesystem containing the underlying node, or in the actual translator implementing the node? + <antrik> hrm + <cfhammar> antrik: the containing filesystem + <cfhammar> (since this is a security issue) + <pochu> yeah, otherwise the trust issue would still be there + <antrik> then why wouldn't it work with O_NOTRANS? + <antrik> BTW, what security issue are you talking about? do you mean the fact that a translator can redirect the lookups to another file, but hide the fact that it's a link? + <pochu> antrik: I mean the O_NOTRANS & O_NOFOLLOW comment in [glibc]/hurd/lookup-retry.c + <cfhammar> antrik: because O_NOTRANS means don't follow translators (including symlinks) and O_NOFOLLOW means don't follow (any) link but do follow translators + <antrik> pochu: I must admit that I never fully understood what that one is about :-) + <cfhammar> antrik: i imagine O_NOTRANS|O_NOFOLLOW == O_NOTRANS + <antrik> cfhammar: I see + <antrik> cfhammar: but I guess that's totally orthogonal from handling in glibc vs. handling in the FS?... + <pochu> AFAIU, it's that if you do an open(translator, O_NOFOLLOW, 0), the translator can lie about it being a symlink. So you need to do an O_NOTRANS lookup + <pochu> hence hurd/hurdlookup.c adds O_NOTRANS if O_NOFOLLOW is present in flags + <antrik> ah, OK + <antrik> so the idea here is that instead of doing that, glibc would only pass on O_NOFOLLOW, and the filesystem would handle the O_NOTRANS part itself + <cfhammar> antrik: if you have O_NOTRANS the filesystem will never follow any translators including non-link ones, so it can't really handle O_NOFOLLOW to exclude link translators + <cfhammar> antrik: yeah + <antrik> AIUI the problem is that with the current scheme, using O_NOFOLLOW will also ignore non-link translators? + <cfhammar> antrik: exactly, including fifos + <cfhammar> antrik: of course, there's still the problem of determining that it is a non-link translator + <antrik> cfhammar: but why can't this be fixed keeping the current scheme? wouldn't it suffice for glibc to ask the filesystem whether there is a link (with O_NOTRANS), and if not, do the actual lookup without O_NOTRANS?... + <pochu> antrik: there's still the problem of translators lying about them being symlinks or not, right? so instead of a blacklist (is it a symlink?) you would need a whitelist + <antrik> pochu: sure. I just don't see how an implementation in the filesystem would do any better on that score than one in glibc + <cfhammar> antrik: the fs is better at maintaining the whitelist, e.g. you could have different whitelist for different translators + <cfhammar> antrik: the fs also knows who own the fs, so it could make exeptions for the owner's translators + <cfhammar> like glibc does for the root user, currently + <antrik> I'm not really convinced so far that having these policies in the filesystem is really preferable to having them in the client-side library... + <cfhammar> antrik: we want to put /hurd/fifo in the whitelist for all users but we can't determine whether an active translator on the underlying node is /hurd/fifo or not, but the FS can if it started the translator itself + <cfhammar> antrik: of course, this can also be done by hiding the /hurd/fifo translator so that glibc doesn't do the test in the first place + <cfhammar> antrik: but this isn't pretty, you'd have to proxy it afaics :-/ + <antrik> cfhammar: TBH, I don't like the whole whilelisting idea + <antrik> seems to me this is really just another manifestation of the infamous firmlink problem + <antrik> as I said in past discussions, I tend to think that the only way to fix it *properly* is changing the way authentification is handled + <antrik> we actually discussed this at some point... when crossing translator boundries, the client shouldn't use it's full permissions on the new translator, but rather the intersection of it's own permissions and that of the parent translator + <antrik> this way, "secret" links should cease to be dangerous... + <cfhammar> yeah, but that'll take way too long for poor pochu ;-) + <antrik> cfhammar: true... but I'm not convinced that a whitelisting hack in the meantime is really worthwhile + <cfhammar> antrik: we already have a whitelisting hack (root user's translators), we're just moving it to the filesystem and adding /hurd/fifo + <antrik> cfhammar: nope, allowing all root translators is a general policy, not a whitelisting hack + <antrik> not elegant either, but a very different class + <cfhammar> antrik: i don't remember the details but fixing firmlink problem seemed to require some fundamental changes, it might even turn out to be unfeasible + <antrik> BTW, it's still not clear to my why the filesystem is supposed to have a better idea which translators to whitelist than glibc?... + <cfhammar> antrik: huh, i don't think i've seen that policy elsewhere, only for root clients not servers + <cfhammar> antrik: for one it can keep track of if the current active translator is the current passive one, and thus know which program it runs + <antrik> do I get it right that in the case of fifo, the client can't generally trust the user running the translator, and thus the idea is instead to trust the translator program?... + <cfhammar> O_NOFOLLOW implies that the client does not trust the file not to redirect it anywhere and we know /hurd/fifo will not do this + <antrik> cfhammar: was that a "yes"?... + <cfhammar> antrik: yes + <antrik> hm... I think I already said it in the context of object migration: I really don't like the idea of trust based on the program being executed... + <antrik> this workaround also has other shortcomings: what if the transaltor is started actively? + <cfhammar> hmm the owner of the translator could hijack it and the fs wouldn't know + <antrik> I must admit though that I don't see another short-term solution either :-( + <antrik> oh, right, that's another problem + <cfhammar> seems like the fs must implement the fifo itself (or atleast hide the /hurd/fifo translator behind a proxy) + <antrik> BTW, what is the specific manifestation of the problem with fifos being ignored on NOFOLLOW? + <pochu> there are two problems + <pochu> one is that with O_NOFOLLOW, it's ext2fs who checks the file permissions, and denies it (dunno the reason for that) + <pochu> the other one is that if you stat the fifo with O_NOFOLLOW and without it, the device will look different (and thus cp believes the file has changed and fails) + <pochu> that's because an stat on the fifo will return the fifo translator's PID as the device + <antrik> ah + <pochu> while one with O_NOFOLLOW will return the partition device + <antrik> so the specific problem here is that the stat info is differenet with the fifo translator than without + <pochu> I'm not sure whether it would be correct & possible to return the device of the parent translator in libtrivfs, instead of the PID + <pochu> yes + <pochu> that, and the permission one (they are different) + <pochu> though both would be solved if O_NOFOLLOW didn't imply O_NOTRANS :) + <antrik> what exactly do you mean by "device" here? + <pochu> I mean st_dev in struct stat + <antrik> well, I wonder whether the permission problem shouldn't actually be considered a bug in fifo. i sthere a good reason why the permissions are not propagated to the underlying node, as with most other translators? + <pochu> I don't think that's the problem + <antrik> what else? + <pochu> it's rather that if you open the fifo with O_NOTRANS, you don't get the underlying node, and then it's ext2fs (and so libdiskfs) who checks the permissions, and it denies them for whatever reason + <pochu> antrik: libdiskfs/dir-lookup.c has this: + <pochu> if (((type == S_IFSOCK || type == S_IFBLK || type == S_IFCHR) + <pochu> >------- && (flags & (O_READ|O_WRITE|O_EXEC))) + <pochu> >------- || (type == S_IFLNK && (flags & (O_WRITE|O_EXEC)))) + <pochu> >-------error = EACCES; + <pochu> so it returns EACCES for the fifo + <pochu> I wonder whether there's a good reason (that I'm missing) for that + <cfhammar> pochu: i think the reason might be that ext2fs denies access because it does not implement those file types itself + <cfhammar> i.e. ext2fs expects them to be opened without O_NOTRANS + <cfhammar> (or opened exclusively for non rwx reasons such as stat or settrans) diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn new file mode 100644 index 00000000..1dac130c --- /dev/null +++ b/open_issues/translators_set_up_by_untrusted_users.mdwn @@ -0,0 +1,352 @@ +[[!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-07-17 + + <antrik> Reventlov: this is the so-called "firmlink issue" -- though AFAIK + it doesn't actually apply to firmlinks ;-) + <antrik> the problem is that any user can in theory create and set up a + special translator, which will redirect to another directory, without any + indication that it's a link + <braunr> but this doesn't supersede the file system permissions, does it ? + <antrik> as a result, if someone runs rm -r on the directory containing + that translator (which could be a world-writable one such as tmp), the rm + -r will descend into the directory, and thus remove it with the + permissions of the user who ran the rm -- not the one who set up the + translator + <braunr> oh i see, when tmp gets cleared by a script run as root, your home + is deleted ? + <antrik> right + <antrik> of course, the workaround is trivial: just don't follow + translators set up by untrusted users + <antrik> (which is precisely the default policy for FUSE BTW) + <braunr> which is the general policy around memory managers in general + <antrik> it's just nobody cared to implement this change + <youpi> antrik: does rm use O_NOTRANS ? + <antrik> youpi: I'm pretty sure it doesn't + <youpi> so it's still an issue for now + <antrik> yes, it's still an issue. it's just not a really fundamental + problem as macrus claimed it to be... [sigh] + <youpi> well, fix rm and then you can say it's not an issue any more + <braunr> does it only concern rm ? + <antrik> youpi: rm is just an example. the problem is much more generic: a + malicious translator can do all kinds of harm + <youpi> sure + <youpi> it's just about tools not blindly following things + <antrik> the only simple and effective answer is not to follow translators + from untrusted users by default + <youpi> antrik: but then /dev/null can't be non-root + <braunr> depends how "untrusted users" are identified + <antrik> we discussed a more sophisticated solution with cfhammer, that + would change the way reauthentication works in lookups, and should + prevent these kinds of permission escalation without preventing desirable + uses... but it still wouldn't address DOS issues, so it would be only a + partial solution + <antrik> youpi: why should it? + <manuel> (http://lists.gnu.org/archive/html/bug-hurd/2009-11/msg00231.html + for the most sophisticated solution) + <antrik> braunr: well, currently the permission system generally trusts + root and the own user. implementing something else might be tricky... not + sure + <antrik> manuel: yes, that's precisely the discussion I was referring + to... thanks for the link :-) + <youpi> antrik: depends what you mean by "follow" + <youpi> what DOS are you thinking of? + <antrik> youpi: a translator can generate endless amounts of "data"; a + translator can generate endless recursive directory tress; or it can just + never return from RPCs... all things that can do pretty much harm + depending on the situation + <antrik> filesystem clients generally trust filesystem operations to be + safe -- and that's just not true anymore with filesystems run by + untrusted users + <antrik> (be it Hurd translators or FUSE modules) + <antrik> this is a fundamental problem as marcus and neal rightly observed + <antrik> I just don't agree about the seriousness of the consequences + <antrik> I don't think not following untrusted translators really looses us + much + <youpi> EDOOMANYNEGATIONS + <youpi> s/D/T + <youpi> again, what do you mean by "following" ? + <youpi> always use O_NOTRANS ? + <tschwinge> Yes, I think. + <youpi> or never accept a REAUTH ? + <youpi> O_NOTRANS would mean ftpfs running as root, brrr + <youpi> it's not really true that clients always trust filesystem + operations + <youpi> the "not returning" case for instance, also appears with nfs mounts + <antrik> no, not always use O_NOTRANS. just be more selective about what + translators to follow. specifically, don't follow translators set up by + untrusted users. (unless explicitly requested) + <antrik> you can think of it as O_NO_UNTRUSTED_TRANS + <antrik> note that if you run ftpfs under a special user, who is not root + but trusted by root, this would still be fine. I hope it shouldn't be too + hard to implement that... + <antrik> as for NFS: clients generally do *not* try to catch possible + failures. if the NFS server doesn't return, the clients hang forever. but + the NFS server is generally trusted, so this is not much of a problem + <antrik> BTW, I guess not accepting reauth from untrusted translators would + also fix the privilege escalations (similar to the proposed modified + reauth mechanism, only more invasive); but it wouldn't fix the DoS issues + <ArneBab> antrik: would that also be an issue for a run translator, which + runs a command on read? + <ArneBab> youpi: couldn’t ftpfs have root drop priviledges? + <ArneBab> like a runas trans + <ArneBab> essertially su for translators to drop privs + <antrik> ArneBab: hm... if we can make sure that the translator was started + as root, and dropped privileges later, I guess that would be fine... not + sure how hard that is + <antrik> ArneBab: but I think it would be more elegant to start the + translators as trusted non-root users in the first place + <ArneBab> then i ph.avme to trust them + <ArneBab> deper hierarchy + <ArneBab> deeper + <ArneBab> but essertially the same + <ArneBab> if then someone mounted his home himself, would I be able to read + it? + <ArneBab> /home/user + <ArneBab> antrik: if not, that would be really non-nice + <antrik> ArneBab: sorry, but we simply *can't* trust a translator set up by + an untrusted user. if he controls it, he can make it behave maliciously + <antrik> we could in theory try to come up with a proxy that catches + problematic semantics, and presents a "safe" variant to the actual + clients... but that would be not-trivial, and I'm not sure how safe it + can be made + <antrik> ArneBab: of course you should always have the option to explicitly + say that you want to trust the translator, if you think the user doesn't + have malicious intentions :-) + <antrik> (I think nsmux would be a good way to achieve this...) + <braunr> unless it's really really necessary (and i don't see why it would + be), no design should force a process to start with privileges and drop + them + <braunr> having a set of trusted users (e.g. uid < 100) is a nice solution + to the problem imho + <braunr> or part of a group, 100 is a non-hurdish static limit + <ArneBab> What user is running a passive translator? + <braunr> passive translators are a pain for such things :/ + <braunr> a command line and attach point are not enough to persistently + encode the execution context of the tranlator + <ArneBab> What user is running a passive translator? + <ArneBab> sorry + <braunr> the one owning the inode if i'm right + <ArneBab> so actually the orly problem are recursive commands, which also + are a problem with plain symlinks? + <braunr> i'm not sure + <ArneBab> Is thene any havoc a translator can wreak that a symlink can’t? + <braunr> well, as symlinks are translators, if a translator can damage + something, a symlink may too + <ArneBab> but not in Linux? + <braunr> err + <braunr> there are no translator in linux + <ArneBab> → commands could just treat translators as symlinks + <ArneBab> jepp, but it has symlinks + <braunr> no, this would defeat the purpose of translators :p + <braunr> and it's just no doable + <braunr> you would have recursion everywhere + <ArneBab> why? + <braunr> because every file access is sent to a translator + <ArneBab> hm, yes + <braunr> and we don't want to change commands + <braunr> we want to fix the design + <ArneBab> → only untrusted trans + <braunr> rather than considering them as symlinks, just consider them as + untrusted translators + <braunr> this doesn't change the semantics, only the action of accessing a + node or not + <braunr> but as antrik said, this has to be done :) + <braunr> the real problem would simplify to "how do you know if a + translator can be trusted", which is a matter of selecting the righ + identification strategy + <braunr> one strong strategy would be to have a port right copied to each + trusted task + <braunr> i wonder if one of the special ports could be used for that + <braunr> or if we have to add a new one + <ArneBab> so when I login, I would give port rights to trusted uids? + <braunr> no + <braunr> when a trusted translator starts a passive translator attached on + a node owned by root, it would copy its trusted right to the new task + <braunr> much like the device master port is passed to root tasks + <braunr> but i'm not sure this mechanism can be safely used to know if the + translator can be trusted + <braunr> the translator would be able to actively call services requiring + this capability + <braunr> but i guess client tasks would have to ask for the translator to + prove it's trusted + <braunr> which is a problem because the issue is to know if it can be + trusted before asking it anything + <braunr> another way is to register trusted tasks in another server, and + ask this server if the target translator is trusted + <braunr> i"m pretty sure these strategies already exist in some form on the + hurd + <ArneBab> hm + <braunr> does someone here have an idea why BSD-derived VMs account wiring + information at the high level vm_map instead of storing it in lower level + vm_page ? + <ArneBab> braunr: a translator anywhene in the FS can only be there, if the + creator had sufficient rights to the node, right? + <ArneBab> so wouldn’t it suffice to check the access rights? + <braunr> no + <braunr> ismple example: /dev/null is owned by root, but you have read + access to it + <braunr> hm that may not answer your question actually + <braunr> what access right would you check ? + <braunr> if someone creates a node with rights 777, do you still want to + access it ? + <ArneBab> no + <braunr> simple enough i hope :) + <ArneBab> arg… + <ArneBab> if I can write to it, I can give it a translaton + <ArneBab> translator + <braunr> but this doesn't tell you it can be trusted + <ArneBab> well, actually: yes, access, but not recurse + <braunr> the owner sets his own rights, and you can't trust the owner + <braunr> unless it's root, but you don't want all your translators to run + as root + <ArneBab> it can act as its owner? + <ArneBab> yes + <braunr> well, as i told you, a passive translator is started by its parent + translator (the one managing the file systeme node it's attached to) + <braunr> the new translator runs as the user owning the node + <braunr> (if i'm right) + <ArneBab> …and so on, till noot starts the first + <ArneBab> root + <braunr> ? + <ArneBab> root starts /, right? + <braunr> no + <braunr> gnumach starts / + <ArneBab> ah, right + <braunr> gnumach starts somefs.static + <braunr> which attaches at / + <braunr> and runs with root privileges + <braunr> keep in mind that unix permissions are implemented as capabilities + on the hurd + <ArneBab> → root has it / it’s root + <braunr> the rights you have aren't limited to those permissions + <ArneBab> jepp + <braunr> and it's not "until" + <ArneBab> so why should I not access a translator run by someone else? I + just don’t want to do any active command (recurse)… hm… can a translator + turn a read request into a write? + <braunr> that's the only problem + <ArneBab> program with my rights wants to read, but the translator makes it + write instead? + <braunr> no + <braunr> a translator can do pretty much anything with your request + <ArneBab> with my rights? + <braunr> no + <braunr> the most obvious example of DoS is simply not answering + <braunr> your process hangs + <braunr> considering some file system accesses, a translator could return + inconsistent data + <ArneBab> so if the translator tries to make me write instead of read, it + can do so only when the owner of the translaton can write to the file in + question? + <braunr> a well written application shouldn't have too much trouble dealing + with it but some aren't that well written + <braunr> this has *nothing* to do with read/write permissions + <braunr> you should read the critique :p + +[[hurd/critique]] + + <ArneBab> ln -s /home/you /home/me → “why don’t you look into my home?” + <ArneBab> read it again, that is :) + <ArneBab> (has been some time since I read it) + <antrik> braunr: you just described the auth mechanism ;-) + <antrik> ArneBab: symlinks can do considerably less than translators; and + even these caused a lot of trouble when introduced (and still cause + sometimes) + <antrik> we can't make every application aware of translators + <antrik> indeed I believe we can a avoid many problems by presenting + various translators as symlinks -- but this is not approriate for all + translators + <antrik> it is something the translator itself decides, so it's not helpful + to solve security issues at all + <antrik> and as braunr already pointed out, this wouldn't help with DoS + problems + + +# Linux kernel, Symlink/Hardlink Attack + +Even though not directly comparable, the issues described at [Symlink +Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protection) +and [Hardlink +Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Hardlink_Protection) +do bear some similarity with the issue we're discussing here. + +Likewise, Kees Cook, [fs: symlink restrictions on sticky +directories](http://lwn.net/Articles/468215/), 2011-11-18. [2011-12-06 +update](http://lwn.net/Articles/470891/). Jake Edge, [Fixing the symlink race +problem](http://lwn.net/Articles/472071/), 2011-12-14. + + +# IRC, freenode, #hurd, 2011-08-31 + + <antrik> I don't see any problems with following only translators of + trusted users + <youpi> where to store the list of trusted users? + <youpi> is there a way to access the underlying node, which for /dev + entries belongs to root? + <ArneBab> youpi: why a list of trusted users? Does it not suffice to + require /hurd/trust set by root or ourselves? + <youpi> ArneBab: just because that's what antrik suggests, so I ask him for + more details + <ArneBab> ah, ok + <antrik> youpi: probably make them members of a group + <antrik> of course that doesn't allow normal users to add their own trusted + users... but that's not the only limitation of the user-based + authentication mechanism, so I wouldn't consider that an extra problem + <antrik> ArneBab: we can't set a translator on top of another user's + translator in general + <antrik> root could, but that's not very flexible... + <antrik> the group-based solution seems more useful to me + <ArneBab> antrik: why can’t we? + <antrik> also note that you can't set passive translators on top of other + translators + <antrik> ArneBab: because we can only set translators on our own nodes + <ArneBab> active ones, too? + <antrik> yes + <ArneBab> antrik: I always thought I could… + <ArneBab> but did not test it + <ArneBab> antrik: so I need a subhurd to change nodes which do not belong + to me? + * ArneBab in that case finally understands why you like subhurds so much: + That should be my normal right + <antrik> it should be your normal right to change stuff not belonging to + you? that's an odd world view :-) + <antrik> subhurds don't really have anything to do with it + <ArneBab> change it in a way that only I see the changes + <antrik> you need local namespaces to allow making local modifications to + global resources + <youpi> it should be one's normal right to change the view one has of it + <antrik> we discussed that once actually I believe... + <antrik> err... private namespaces I mean + +IRC, freenode, #hurd, 2011-09-10: + + <cjuner_> I am rereading Neal Walfield's and Marcus Brinkman's critique of + the hurd on mach. One of the arguments is that a file system may be + malicious (by DoS its clients with infinitely deep directory + hierarchies). Is there an answer to that that does not require programs + to be programmed defensively against such possibilities? + +IRC, freenode, #hurd, 2011-09-14: + + <antrik> cjuner: regarding malicious filesystems: the answer is to do + exactly the same as FUSE on Linux: don't follow translators set up by + untrusted users by default + <cjuner> antrik, but are legacy programs somehow protected? What about + executing `find`? Or is GNU's find somehow protected from that? + <antrik> cjuner: I'm talking about a global policy + <cjuner> antrik, and who would implement that policy? + <antrik> cjuner: either glibc or the parent translators + +Continued discussion about [[resource_management_problems/pagers]]. diff --git a/open_issues/trust_the_behavior_of_translators.mdwn b/open_issues/trust_the_behavior_of_translators.mdwn new file mode 100644 index 00000000..454c638b --- /dev/null +++ b/open_issues/trust_the_behavior_of_translators.mdwn @@ -0,0 +1,181 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +Apart from the issue of [[translators_set_up_by_untrusted_users]], here is +another problem described. + + +# IRC, freenode, #hurd, 2012-02-17 + +(Preceded by the [[memory_object_model_vs_block-level_cache]] discussion.) + + <slpz> what should do Mach with a translator that doesn't clean pages in a + reasonable amount of time? + <slpz> (I'm talking about pages flushed to a pager by the pageout daemon) + <braunr> slpz: i don't know what it should do, but currently, it uses the + default pager + +[[default_pager]]. + + <slpz> braunr: I know, but I was thinking about an alternative, for the + case in which a translator in not behaving properly + <slpz> perhaps freeing the page, removing the map, and letting it die in a + segmentation fault could be an option + <braunr> slpz: what if the translator can't do it properly because of + system resource exhaustion ? + <braunr> (i.e. it doesn't have enough cpu time) + <slpz> braunr: that's the biggest question + <slpz> let's suppose that Mach selects a page, sends it to the pager for + cleaning it up, reinjects the page into the active queue, and later it + founds the page again and it's still dirty + <slpz> but it needs to free some pages because memory it's really, really + scarce + <slpz> Linux just sits there waiting for I/O completion for that page + (trusts its own drivers) + <slpz> but we could be dealing with rogue translator... + <braunr> yes + <braunr> we may need some sort of "authentication" mechanism for pagers + <braunr> so that "system pagers" are trusted and others not + <braunr> using something like the device master port but for pagers + <braunr> a special port passed to trusted pagers only + <slpz> hum... that could be used to workaround the untrusted translator + crossing problem while walking a directory tree + +[[translators_set_up_by_untrusted_users]]. + + <slpz> but I think differentiating between trusted and untrusted + translators was rejected for philosophical reasons + <slpz> (but I'm not sure) + <mcsim> slpz: probably there should be something like oom killer? + <mcsim> braunr: even if translator is trusted it could have a bug which + make it ask more and more memory, so system have something to do with + it. Also, this way TCB is increased, so providing port for trusted + translators may hurt security. + <mcsim> I've read that Genode has "guarded allocators" which help resource + accounting by limiting of memory that could be used. Probably something + like this could be used in Hurd to limit translators. + <antrik> I don't remember how Viengoos deals with this :-( + +[[microkernel/Viengoos]]. + + <braunr> mcsim: the main feature lacking in mach is resource accounting :p + +[[resource_management_problems]]. + + <slpz> mcsim: yes, I think there should be a Hurdish oom killer, paying + special attention to external pagers + +[[microkernel/mach/external_pager_mechanism]]. + + <braunr> the oom killer selects untrusted processes by definition (since + pagers are in kernel) + <mcsim> slpz: and what is better: oom killer or resource accounting? + <mcsim> Under resource accounting I mean mechanism when process can't get + more resources than it is allowed. + <braunr> resource accounting of course + <braunr> but it's not just about that + <braunr> really, how does the kernel deal when a pager refuses to honor a + paging request ? + <braunr> whether it is buggy or malicious + <braunr> is it really possible to keep all pagers out of the TCB ? + <antrik> mcsim: we definitely want proper resource accounting in the long + run. the question is how to deal with the situation that resources are + reallocated to other tasks, so some pages have to be freed + <antrik> I really don't remember how Neal proposed to deal with this + <slpz> mcsim: Better: resource accounting (in which resources are accounted + to the user tasks which are requesting them, as in the Viengoos + model). Good enough an realistic: oom killer + <antrik> I'm not sure an OOM killer for non-system pagers is terribly + helpful. in typical use, the vast majority of paging is done by trusted + pagers... + <antrik> and without proper client resource accounting, there are enough + other ways a rogue/broken process can eat system resources -- I'm not + convinced that untrusted pagers have a major impact on the overall + situation + <mcsim> If pager can't free resources because of lack, for example, of cpu + time it's priority could be increased to give it second chance to free + the page. But if it doesn't manage to free resources it could be killed. + <antrik> I think the current approach with default pager taking over is + good enough for dealing with untrusted pagers. the real problem are even + trusted pager frequently failing to deal with the requests + <braunr> i agree with antrik + <braunr> and i'm opposed to an oom killer + <braunr> it's really not a proper fix for our problems + <braunr> mcsim: what if needs 3 attempts before succeeding ? + <braunr> +it + <braunr> and increasing priority without a good reason (e.g. no priority + inversion) leads to unfairness + <braunr> we don't want to deal with tricky problems like malicious pagers + using that to starve other tasks + <mcsim> braunr: this is just temporary decision (for example for half of + second of user time), to increase probability that task was killed not + because of it lacked resources. + <braunr> mcsim: tunables should only affect the efficiency of an operation, + not its success + + +## IRC, freenode, #hurd, 2012-02-19 + + <antrik> neal: the specific question is how to ensure processes free memory + fast enough when their allocation becomes lower due to resource pressure + <neal> antrik: you can't really. + <neal> antrik: the memory manager can act on the application's behalf if + the application marks pages as discardable or pagable. + <neal> antrik: if the memory manager makes an upcall to the application to + free some memory and it doesn't, you have to penalize it. + <neal> antrik: You shouldn't the process like exokernel + <neal> antrik: It's the developers fault, not the user's + <neal> antrik: What you need are controls that ensure that the user stays + in control + <neal> ...shouldn't *kill* the process... + <antrik> neal: well, how can I penalize a process that eats to much + physical memory? + <neal> in the future, you don't give it as much slack memory + <antrik> marking as pagable means a system pager will push them to the swap + partition? + <antrik> ah, OK + <neal> yes + <neal> and you page it more aggressively, i.e., you don't give it a chance + to free memory + <neal> The situation is: + <neal> you have memory pressure + <neal> you choose a victim process and ask it to free memory + <neal> now, you need to wait + <neal> if you wait and it doesn't free memory, you give it bad karma + <neal> if you wait and it frees memory, you're good + <neal> but during that window, a bad process can delay recovery + <neal> so, in the future, we give bad processes less time + <neal> but, we still send a message asking it to free memory + <neal> we just hope it was a bug + <antrik> so the major difference to the approach we have in Mach is that + instead of just redeclaring some pages as anonymous memory that will be + paged to swap by the default pager eventually if the pager in question + fails to handle them properly, we wait some time for the process to free + (any) memory, and only then start paging out some of it's pages to swap + <neal> there's also discardable memory + <antrik> hm... there is some notion of "precious" pages in Mach... I wonder + whether that is also used to decide about discarding pages instead of + pushing them to swap? + <neal> antrik: A precious page is ro data that shouldn't be dropped + <antrik> ah + <antrik> but I guess that means non-precious RO data (such as a cache) can + be dropped without asking the pager, right? + <neal> yes + <antrik> I wonder whether such a karma system can be introduced in Mach as + well to deal with problematic pagers + + +## IRC, freenode, #hurd, 2012-02-21 + + <neal> antrik: One of the main differences between Mach and Viengoos is + that in Mach servers are responsible for managing memory whereas in + Viengoos applications are primarily responsible for managing memory. diff --git a/open_issues/tty_activitiy_vs_disk_io.mdwn b/open_issues/tty_activitiy_vs_disk_io.mdwn new file mode 100644 index 00000000..26382d56 --- /dev/null +++ b/open_issues/tty_activitiy_vs_disk_io.mdwn @@ -0,0 +1,81 @@ +[[!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-07-25 + + < youpi> Mmm, typing something on the mach console triggers a write on the + disk + < youpi> because the /dev/console node gets updated + < youpi> I don't really see why + < youpi> (yes, just typing at the bash prompt, not even running something) + < youpi> typing during the sleep command (i.e. mere tty echo) doesn't + trigger it, however + < youpi> running bash's echo does trigger it + < braunr> during sleep, the glibc stream functions handle I/O, while with + bash, its readline takes care of it, right ? + < youpi> /bin/echo too + < youpi> during sleep it's the tty process which handles I/O + < braunr> the write may be due to a write time update on the inode + < braunr> modification* time + < youpi> probably yes, but how so? + < youpi> ext2fs is only supposed to pass the thing to the console + translator + < braunr> not sure + < youpi> actually, ext2fs even isn't supposed to come into play when it's + about typing at the bash prompt + < youpi> once it's opened, isn't the port for /dev/console supposed to be + directly to the translator there? + < braunr> i think so + < youpi> (s/tty/term/ in what I said) + < braunr> well, it's certain + < youpi> so I don't see how ext2fs can be triggered to write an atime or + mtime + < braunr> what does rpctrace say ? + < youpi> io_read_request and io_write_request + < youpi> braunr: it doesn't happen at the login prompt + < youpi> interestingly, atime is always 3-4 secs earlier than ctime & mtime + < youpi> doesn't happen with dash + < braunr> we should implement relatime and experiment with it + < braunr> it shouldn't be hard + < youpi> well, there's noatime already + < youpi> but my point is that this update shouldn't happen + < youpi> and I believe it's the source of the i_file_acl e2fsck warning + < braunr> i wasn't saying that concerning this problem, it was just a + separate idea (noatime is more problematic than relatime) + < braunr> and i agree, it shouldn't happen :) + < youpi> ok, it's set_node_times which gets called + +IRC, freenode, #hurd, 2011-07-27 + + < antrik> BTW, I'm not sure it's still relevant; but the reason accessing + translators such as the console modifies the underlying node is that most + stat information is generally passed through + < antrik> (in some cases it might be unintentional though, simply using the + default implementation from trivfs carelessly...) + < youpi> I know + < youpi> I've seen that in the code + < antrik> OK + < youpi> it is still relevant: I still find it useless to write it on the + disk + < youpi> though w uses it to show idle time over reboot + < braunr> is it useful to keep the information across reboots ? + < youpi> for some value of "useful" for w + < braunr> i wonder what would break if this was entierly kept in memory + < youpi> nothing, probably + < youpi> note that it doesn't overload ext2fs so much, it just adds a write + every ~5s + < youpi> (at worse, i.e. when keeping showing text, for instance) + < braunr> indeed, the behaviour seems the same on linux + < antrik> ah... that explains why the disk doesn't spin down while IRC is + active... always wondered about that :-) + < youpi> that's not very power-saving, yes + < youpi> well, we might want to put /dev on ram someday diff --git a/open_issues/unit_testing.mdwn b/open_issues/unit_testing.mdwn new file mode 100644 index 00000000..dd1e465c --- /dev/null +++ b/open_issues/unit_testing.mdwn @@ -0,0 +1,94 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +This task may be suitable for [[community/GSoC]]: +[[community/gsoc/project_ideas/testing_framework]] + +--- + +A collection of thoughts with respect to unit testing. + +We definitely want to add unit test suites to our code base. + +We should select a tool that we like to use, and that is supported (not +abandoned). + + * [SC + Test](http://web.archive.org/web/20021204193607/sc-archive.codesourcery.com/sc_test) + + * [DejaGnu](http://www.gnu.org/software/dejagnu/) / + [Expect](http://expect.nist.gov/) + + * used by the [[GCC testsuite|gcc]], [[GDB testsuite|gdb]], + [[binutils testsuite|binutils]], etc. + + * The [[glibc testsuite|glibc]] has a home-grown system (Makefile-based), + likewise does the [[Open_POSIX_Test_Suite]]. + + * [Kyua](http://code.google.com/p/kyua/) (and its predecessor [ATF](http://www.NetBSD.org/~jmmv/atf/)). + + * Primarily used by NetBSD as its testing framework; FreeBSD is in the process of adopting it. + + * Provides bindings to write tests in C, C++ and POSIX shell. Lua is planned. + + * Builds and runs on many different Unix-based operating systems. + + * [check](http://check.sourceforge.net/) + + * used by some GNU packages, for example GNU PDF (Jose E. Marchesi) + + * CodeSourcery's [QMTest](http://www.codesourcery.com/qmtest) + + * useb by? + + * documentation: + + * <http://www.codesourcery.com/public/qmtest/whitepaper.pdf> + + * <http://www.python.org/workshops/2002-02/papers/01/index.htm> + + * <http://gcc.gnu.org/ml/gcc/2002-05/msg01978.html> + + * <http://www.codesourcery.com/public/qmtest/qmtest-snapshot/share/doc/qmtest/html/tutorial/index.html> + + * <http://www.codesourcery.com/public/qmtest/qmtest-snapshot/share/doc/qmtest/html/manual/index.html> + + * [Git](http://git-scm.com/) has an elaborate unit testsuite, which is also + used in [Notmuch](http://notmuchmail.org/). + + * [*[ANNOUNCE] ktest.pl: Easy and flexible testing script for Linux Kernel + Developers*](http://lwn.net/Articles/412302/) by Steven Rostedt, + 2010-10-28. [v2](http://lwn.net/Articles/414064/), 2010-11-08. + + * <http://autotest.kernel.org/wiki/WhitePaper> + + +# Related + + * [[nightly_builds]] + + * [[nightly_builds_deb_packages]] + + * <http://www.phoronix-test-suite.com/> -- ``comprehensive testing and + benchmarking platform''. This one might be useful for [[performance]] + testing, too? + + * <http://ltp.sourceforge.net/> + + * [LaBrea](https://github.com/dustin/labrea/wiki), or similar tools can be + used for modelling certain aspects of system behavior (long response times, + for example). + + +# Discussion + +See the [[GSoC project idea|community/gsoc/project_ideas/testing_framework]]'s +[[discussion +subpage|community/gsoc/project_ideas/testing_framework/discussion]]. diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn new file mode 100644 index 00000000..25168fce --- /dev/null +++ b/open_issues/user-space_device_drivers.mdwn @@ -0,0 +1,208 @@ +[[!meta copyright="Copyright © 2009, 2011, 2012 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +This is a collection of resources concerning *user-space device drivers*. + +Also see [[device drivers and IO systems]]. +[[community/gsoc/project ideas/driver glue code]]. + +[[!toc levels=2]] + + +# Issues + +## IRQs + + * Can be modeled using [[RPC]]s. + + * Security considerations: IRQ sharing. + + * *Omega0* paper defines an interface. + + * As is can be read in the *Mach 3 Kernel Principles*, there is an *event + object* facility in Mach that can be used for having user-space tasks react + to IRQs. However, at least in GNU Mach, that code (`kern/eventcount.c`) + doesn't seem functional at all and isn't integrated properly in the kernel. + + * IRC, freenode, #hurd, 2011-07-29 + + < antrik> regarding performance of userspace drivers, there is one + thing that really adds considerable overhead: interrupt + handling. whether this is relevant very much depends on the hardware + in question. when sending many small packets over gigabit ethernet, + it might be noticable; in most other cases it's irrelevant + < youpi> some cards support interrupt coalescin + < youpi> could be supported by DDE too + +## DMA + + * Security considerations. + + * I/O MMU. + +## I/O Ports + + * Security considerations. + +## PCI and other buses + + * Security considerations: sharing. + +## Latency of doing RPCs + + * [[GNU Mach|microkernel/mach/gnumach]] is said to have a high overhead when + doing RPC calls. + +## System Boot + +### IRC, freenode, #hurd, 2011-07-27 + + < braunr> btw, was there any formulation of the modifications required to + have disk drivers in userspace ? + < braunr> (which would obviously need something like + initrd/initramfs/whatever and may also need the root file system not to + be the first task started) + < braunr> hm actually, we may not need initrd + < braunr> the boot loader could just load more modules + < antrik> braunr: I have described all that in my thesis report... in + German :-( + < braunr> and the boot scripts could be adjusted to pass around the right + ports + < Tekk_> braunr: yeah, we could probably load a module that kciks us into + userspace and starts the disk driver + < braunr> modules are actualy userspace executables + < Tekk_> ah + < Tekk_> so what's the issue? + < Tekk_> oh! I'm thinking the ext2fs server, which is already in userspce + < braunr> change the file systems to tell them which underlying disk driver + to use + < Tekk_> mhm + < braunr> s/disk/storage/ + +### IRC, freenode, #hurd, 2012-04-25 + + <youpi> btw, remember the initrd thing? + <youpi> I just came across task.c in libstore/ :) + + +# Plan + + * Examine what other systems are doing. + + * L4 + + * Hurd on L4: deva, fabrica + + * [[/DDE]] + + * Minix 3 + + * Start with a simple driver and implement the needed infrastructure (see + *Issues* above) as needed. + + * <http://savannah.nongnu.org/projects/user-drivers/> + + Some (unfinished?) code written by Robert Millan in 2003: PC keyboard + and parallel port drivers, using `libtrivfs`. + + +# Documentation + + * [An Architecture for Device Drivers Executing as User-Level + Tasks](http://portal.acm.org/citation.cfm?id=665603), 1993, David B. Golub, + Guy G. Sotomayor, Freeman L. Rawson, III + + * [Performance Measurements of the Multimedia Testbed on Mach 3.0: Experience + Writing Real-Time Device Drivers, Servers, and + Applications](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.8685), + 1993, Roger B. Dannenberg, David B. Anderson, Tom Neuendorffer, Dean + Rubine, Jim Zelenka + + * [User Level IPC and Device Management in the Raven + Kernel](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.3733), + 1993, D. Stuart Ritchie, Gerald W. Neufeld + + * [Creating User-Mode Device Drivers with a + Proxy](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.3055), + 1997, Galen C. Hunt + + * [The APIC Approach to High Performance Network Interface Design: Protected + DMA and Other + Techniques](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.1198), + 1997, Zubin D. Dittia, Guru M. Parulkar, Jerome R. Cox, Jr. + + * [The Fluke Device Driver + Framework](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.4.7927), + 1999, Kevin Thomas Van Maren + + * [Omega0: A portable interface to interrupt hardware for L4 + system](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.21.5958), + 2000, Jork Löser, Michael Hohmuth + + * [Userdev: A Framework For User Level Device Drivers In + Linux](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.4461), + 2000, Hari Krishna Vemuri + + * [User Mode Drivers](http://www.linuxjournal.com/article/5442), 2002, Bryce + Nakatani + + * [Towards Untrusted Device + Drivers](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.1725), + 2003, Ben Leslie, Gernot Heiser + + * [Encapsulated User-Level Device Drivers in the Mungi Operating + System](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.1531), + 2004, Ben Leslie Nicholas, Nicholas FitzRoy-Dale, Gernot Heiser + + * [Linux Kernel Infrastructure for User-Level Device + Drivers](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.1408), + 2004, Peter Chubb + + * [Get More Device Drivers out of the + Kernel!](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.6333), + 2004, Peter Chubb + + * <http://gelato.unsw.edu.au/IA64wiki/UserLevelDrivers> + + * [Initial Evaluation of a User-Level Device + Driver](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.4531), + 2004, Kevin Elphinstone, Stefan Götz + + * [User-level Device Drivers: Achieved + Performance](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.6766), + 2005, Ben Leslie, Peter Chubb, Nicholas FitzRoy-Dale, Stefan Götz, Charles + Gray, Luke Macpherson, Daniel Potts, Yueting Shen, Kevin Elphinstone, + Gernot Heiser + + * [Virtualising + PCI](http://www.ice.gelato.org/about/oct06_presentations.php#pres14), 2006, + Myrto Zehnder, Peter Chubb + + * [Microdrivers: A New Architecture for Device + Drivers](http://www.cs.rutgers.edu/~vinodg/papers/hotos2007/), 2007, Vinod + Ganapathy, Arini Balakrishnan, Michael M. Swift, Somesh Jha + + * <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.109.2623> + [[!tag open_issue_documentation]] + + * <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.146.2170> + [[!tag open_issue_documentation]] + + +# External Projects + + * [[/DDE]] + + * <http://ertos.nicta.com.au/research/drivers/uldd/> + + * <http://gelato.unsw.edu.au/IA64wiki/UserLevelDrivers> diff --git a/open_issues/viengoos_make_clean.mdwn b/open_issues/viengoos_make_clean.mdwn new file mode 100644 index 00000000..af2920e7 --- /dev/null +++ b/open_issues/viengoos_make_clean.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_viengoos]] + +IRC, unknown channel, unknown date. + + <neal> tschwinge: If I do a make clean n the root directory, follow that with a configure, configure fails with: configure: error: C compiler cannot create executables + <neal> this is in config.log: /home/neal/src/hurd-l4/build/lib/gcc/i686-pc-viengoos-gnu/4.2.2/../../../../i686-pc-viengoos-gnu/bin/ld: cannot find -lc + <neal> rt + <tschwinge> neal: Should make clean also remove srcdir/gcc/gcc and binutils, as you do it with newlib? + <neal> I'd prefer it not to + <neal> as I use make clean to prep the tree for new configure changes + <neal> and build gcc takes a long time + <neal> (as does newlib, but newlib in this case needs to be rebuilt) diff --git a/open_issues/viengoos_tls_gcc.mdwn b/open_issues/viengoos_tls_gcc.mdwn new file mode 100644 index 00000000..92499903 --- /dev/null +++ b/open_issues/viengoos_tls_gcc.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_viengoos]] + +IRC, unknown channel, unknown date. + + <neal> tschwinge : I'm trying to enable tls for viengoos. This requires compiling gcc with --enable-tls, which enables threading, which pulls in libpthread, which requires newlib headers. + <neal> tschwinge : Unfortunately, I don't see how to install the newlib headers without having gcc + <neal> tschwinge : Have you got any ideas? diff --git a/open_issues/virtual_square_view-os.mdwn b/open_issues/virtual_square_view-os.mdwn new file mode 100644 index 00000000..dcc98785 --- /dev/null +++ b/open_issues/virtual_square_view-os.mdwn @@ -0,0 +1,55 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +All the following is based only on a first, and quick glance only. + +We may want to have a look at Virtual Square / View-OS, and evaluate in which +ways this is related / implemented / implementable / usable / useful in a Hurd +environment, and even ;-) strive to collaborate with them. + +[[I|tschwinge]] found this project very much by chance: on LinkedIn, they +posted a proposal for [DevRoom on Virtualization +Technologies](http://www.linkedin.com/groupItem?view=&gid=27213&type=member&item=31720076) +for [[community/meetings/FOSDEM_2011]]. LinkedIn sends out such posts in very +opaque emails from time to time (probably they'd look less opaque with a HTML +mail user agent), and I even bothered to have a look at it, and follow the link +to the web page, and not delete it straightway. + +So, I had a quick look at the project: + +This seems to be an amalgamation / combination of various virtualization +mechanisms / projects / ideas. Virtualization is here meant in a broad sense, +including file system namespaces: our `chroot` / `settrans --chroot`; +networking configurations: our pfinet override stuff; system configuration: +subhurds?; current time, devices: likewise?; executable interpreter: our exec +server override stuff; "stat" virtualization: fakeroot; etc. -- They seem to +do a lot of stuff that we also try to do / could do / can do. + +In fact, this looks a bit like they're trying to bring some more of the Hurd's +[[hurd/concepts]] over to Unix / Linux, more than only the *usual VFS stuff* +(translators / FUSE). + +Perhaps start reading with the *slides* linked below. + + * <http://virtualsquare.org/> + + * <http://wiki.virtualsquare.org/> + + * <http://sourceforge.net/projects/view-os/> + + * Renzo Davoli, [*Virtual + Square*](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.9106), + 2005 + + * Renzo Davoli, Michael Goldweber, [*View-OS: Change your View on + Virtualization*](http://www.cs.unibo.it/~renzo/view-os-lk2009.pdf), + Proc. of Linux Kongress, 2009 + + * [slides](http://www.cs.unibo.it/~renzo/view-os-lk2009-slides.pdf) diff --git a/open_issues/virtualbox.mdwn b/open_issues/virtualbox.mdwn new file mode 100644 index 00000000..9440284f --- /dev/null +++ b/open_issues/virtualbox.mdwn @@ -0,0 +1,99 @@ +[[!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]] + +Running GNU Mach in VirtualBox crashes during initialization. + +IRC, freenode, #hurd, 2011-08-15 + + <BlueT_> HowTo Reproduce: 1) Use `reboot` to reboot the system. 2) Once + you see the Grub menu, turn off the debian hurd box. 3) Let the box boot + normally, and wait for the error/crash/reboot. 4) The error/crash will + happen twice and it's reboot automatically. The 3rd boot will success. + + <BlueT_> root@dhurd:/boot# addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x106c93 0x1556a5 0x152c54 + <BlueT_> copyoutmsg + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../i386/i386/locore.S:1289 + <BlueT_> exec_load + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/elf-load.c:80 + <BlueT_> user_bootstrap + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/bootstrap.c:756 + + i386/i386/locore.S:1289 is + + movl $USER_DS,%eax /* use user data segment for accesses */ + => mov %ax,%es + + State is + + cs: 0x8 + ds: 0x10 + es: 0x10 + fs: 0 + gs: 0 + ss: 0x10 + eax: 0x1f + ecx: 0x8048000 + edx: 0x15fb7f + ebx: 0x1001000 + esp: 0x75e47e08 + ebp: 0x75e47e6c + esi: 0x1002000 + edi: 0x8048000 + eip: 0x106c93 + efl: 0x10206 + + <youpi> oh, wait, it's not even the data access which poses problem + <youpi> but the use of $USER_DS + <youpi> ew + <youpi> looks like a gdt initialization emulation issue in virtualbox... + + + <BlueT_> just found that at the second crash, the address is different + <BlueT_> 2nd time: + <BlueT_> addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x1068bd 0x152c74 + <BlueT_> _kret_popl_es + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../i386/i386/locore.S:527 + <BlueT_> user_bootstrap + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/bootstrap.c:765 + + i386/i386/locore.S:527 is: + + _return_from_kernel: + _kret_popl_gs: + popl %gs /* restore segment registers */ + _kret_popl_fs: + popl %fs + _kret_popl_es: + => popl %es + _kret_popl_ds: + + cs: 0x8 + ds: 0x10 + es: 0x10 + fs: 0 + gs: 0 + ss: 0x10 + eax: 0x106c95 + ecx: 0x6aab096c + edx: 0x106cec + ebx: 0x75e47f04 + esp: 0x75e47f0c + ebp: 0x75e47fac + esi: 0x75e47f8c + edi: 0x7fffff3c + eip: 0x1068bd + efl: 0x10216 + + <youpi> looks again like a $USER_DS issue + <youpi> what's interesting is that that one means that $USER_DS did load in + %es fine at least once + <youpi> and it's the reload that fails diff --git a/open_issues/virtualization.mdwn b/open_issues/virtualization.mdwn new file mode 100644 index 00000000..343f624a --- /dev/null +++ b/open_issues/virtualization.mdwn @@ -0,0 +1,46 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +An index of things to work on w.r.t. virtualization. + + * [[/virtualization]] + + * [[hurd/virtualization|hurd/virtualization]] + + * [[GSoC project proposal|community/gsoc/project_ideas/virtualization]] + + * [[hurd/subhurd]] / [[hurd/neighborhurd]] + +<!-- + + * There's talking about *collectives* in the Hurd RM, on [[/advantages]] and + [[unsorted/hurd-migr]] ([[!taglink open_issue_documentation]]). + +--> + + * [[Implementing_Hurd_On_Top_of_Another_System]] + + * Unix / Linux + + * [[Capsicum]] + + * [[Virtual_Square_View-OS]] + + * [Namespace file descriptors](http://lwn.net/Articles/407495/), + 2010-09-29 + + * [Divorcing namespaces from + processes](http://lwn.net/Articles/377109/), 2010-03-03 + + * [[File_Systems]] + + * [[Networking]] diff --git a/open_issues/virtualization/capsicum.mdwn b/open_issues/virtualization/capsicum.mdwn new file mode 100644 index 00000000..44503e34 --- /dev/null +++ b/open_issues/virtualization/capsicum.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +*Capsicum - practical capabilities for UNIX* + +<http://www.cl.cam.ac.uk/research/security/capsicum/> + +<http://www.lightbluetouchpaper.org/2010/08/12/capsicum-practical-capabilities-for-unix/> +(server disappeared; [Google +cache](http://webcache.googleusercontent.com/search?q=cache:cCAqjWOhhksJ:www.lightbluetouchpaper.org/2010/08/12/capsicum-practical-capabilities-for-unix/)) + +<http://lackingrhoticity.blogspot.com/2010/10/process-descriptors-in-freebsd-capsicum.html> + +<http://www.cl.cam.ac.uk/research/security/capsicum/slides/20100811-usenix-capsicum.pdf> +/ <http://www.youtube.com/watch?v=raNx9L4VH2k> diff --git a/open_issues/virtualization/file_systems.mdwn b/open_issues/virtualization/file_systems.mdwn new file mode 100644 index 00000000..a12ea10d --- /dev/null +++ b/open_issues/virtualization/file_systems.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +Of course, it is possible to use commodity file systems on [[virtualized +systems|virtualization]], like [[hurd/translator/ext2fs]] or +[[hurd/translator/nfs]], but there are also other possibilities which ought to +be explored. + + * [[network_file_system_by_just_forwarding_RPCs]] + + * Linux saw a patch for [*generic name to handle and open by handle + syscalls*](http://thread.gmane.org/gmane.linux.file-systems/46648) posted, + which in turn can be beneficial for a [[QEMU]] emulation of a 9P file + system. LWN's Jonathan Corbet covered this [*open by + handle*](http://lwn.net/Articles/375888/) functionality on 2010-02-23. diff --git a/open_issues/virtualization/networking.mdwn b/open_issues/virtualization/networking.mdwn new file mode 100644 index 00000000..7a6474a1 --- /dev/null +++ b/open_issues/virtualization/networking.mdwn @@ -0,0 +1,30 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +Collection about stuff that is relevant for *virtualization* and *networking*. + + * [[Virtual_Square_View-OS]] + + * [*Virtual Networks*](http://virtualsquare.org/vn.html) + + * [User Level Networking](http://uln.sourceforge.net/) + + * [Virtual Distributed Ethernet](http://vde.sourceforge.net/) + + * [Application Level + Environment4Networking](http://sourceforge.net/projects/ale4net/) + + *Ale4NET used dyn library call diversion to define networking at process + level.* -- what we're doing with our approach for overriding the default + [[hurd/translator/pfinet]] by setting environment variables. + + Project is now part of [[Virtual_Square_View-OS]]. diff --git a/open_issues/wayland.mdwn b/open_issues/wayland.mdwn new file mode 100644 index 00000000..67f78b1d --- /dev/null +++ b/open_issues/wayland.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +IRC, freenode, #hurd, 2012-03-18: + + <antrik> Wayland should be very portable. all the system dependencies are + in the infrastructure, such as DRI + <antrik> we have had a DRI task (for X.Org) for years + <antrik> (in fact I would be the right person to implement this, + considering my background -- by quite frankly, I doubt I'll ever do it) + <tschwinge> http://xorg.freedesktop.org/wiki/Hurd_Porting + +IRC, freenode, #hurd, 2012-03-20: + + <youlysses> Is wayland something that will be semi-easy to port to the + hurd? I saw GNOME is heading in this direction. + <pinotree> wayland at the moment is linux only + <tschwinge> youlysses: A DRI implementation will be needed. + <pinotree> that, and libdrm compiling + <youlysses> So it will take some work ... but theres no *HUGE* design + decison that would inhibit it? + <pinotree> i know it uses epoll, for instance + <tschwinge> youlysses: I cannot judge how complex a DRI system is, and how + much needs to be designed vs. implemented. diff --git a/open_issues/wine.mdwn b/open_issues/wine.mdwn new file mode 100644 index 00000000..65e6c584 --- /dev/null +++ b/open_issues/wine.mdwn @@ -0,0 +1,69 @@ +[[!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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +On 2010-11-28, Austin English contacted us, stating that he's working on +porting [Wine](http://winehq.org/) to the GNU/Hurd. + +It is not yet clear how difficult this is going to be, what sort of +requirements Wine has: only libc / POSIX / etc., or if there are +*advanced* things like [[system_call]] trapping involved, too. + +[[Samuel|samuelthibault]] suspects that *there's some need for LDT table +allocation. There is kernel support for this,* however. + + +IRC, freenode, #hurd, 2011-08-11 + + < arethusa> I've been trying to make Wine work inside a Debian GNU/Hurd VM, + and to that end, I've successfully compiled the latest sources from Git + after installing the libc (devel) packages from experimental and + personally patching Wine with http://pastebin.com/rg6dx09G + +[[rg6dx09G.patch]] + + < arethusa> my question is, when trying to launch Wine, I'm seeing "wine + client error:0: sendmsg: (os/kern) invalid address" from the client side, + whereas the wineserver seems to be starting and running correctly, how + could I debug this issue further? using rpctrace doesn't seem to help, as + the trace just hangs when run on the Wine loader instead of yielding + insight + < kilobug> arethusa: isn't there a wine debuguer that can start a gdb when + wine encounters an error or something like that ? + < arethusa> it's too early for that + < kilobug> or least give you a full traceback of the wine code where the + error occur ? + < arethusa> the error is happening during initial connect to the + wineserver, in dlls/ntdll/server.c + < arethusa> but that doesn't help me figure out why sendmsg would error out + in this way + < arethusa> + http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/server.c#l361 + < azeem_> arethusa: probably some of the msghdr entries are not supported + by the Hurd's glib + < azeem_> c + < pinotree> haha, socket credentials, which we don't support yet + < azeem_> yep + < pinotree> youpi: ↑ another case ;) + < azeem_> arethusa: just implement those and it should work + < kilobug> in pflocal ? or glibc ? + < pinotree> pflocal + < arethusa> azeem_: hmm, okay, thanks + < pinotree> arethusa: their lack is a known issue, and makes things like + dbus and gamin not work + < arethusa> it's + https://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html and + related links I assume? + +[[sendmsg_scm_creds]] + + < youpi> yes + < pinotree> (but that patch is lame) diff --git a/open_issues/wine/rg6dx09G.patch b/open_issues/wine/rg6dx09G.patch new file mode 100644 index 00000000..510ff23f --- /dev/null +++ b/open_issues/wine/rg6dx09G.patch @@ -0,0 +1,116 @@ +diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c
+index 42b3639..7484608 100644
+--- a/dlls/ntdll/directory.c
++++ b/dlls/ntdll/directory.c
+@@ -3145,14 +3145,14 @@ static void WINAPI read_changes_user_apc( void *arg, IO_STATUS_BLOCK *io, ULONG
+ static NTSTATUS read_changes_apc( void *user, PIO_STATUS_BLOCK iosb, NTSTATUS status, void **apc )
+ {
+ struct read_changes_info *info = user;
+- char data[PATH_MAX];
++ char data[4096];
+ NTSTATUS ret;
+ int size;
+
+ SERVER_START_REQ( read_change )
+ {
+ req->handle = wine_server_obj_handle( info->FileHandle );
+- wine_server_set_reply( req, data, PATH_MAX );
++ wine_server_set_reply( req, data, 4096 );
+ ret = wine_server_call( req );
+ size = wine_server_reply_size( reply );
+ }
+diff --git a/dlls/ntdll/signal_i386.c b/dlls/ntdll/signal_i386.c
+index 6c8e8e2..e949227 100644
+--- a/dlls/ntdll/signal_i386.c
++++ b/dlls/ntdll/signal_i386.c
+@@ -180,6 +180,36 @@ __ASM_GLOBAL_FUNC(vm86_enter,
+
+ #endif /* linux */
+
++#ifdef __GNU__
++
++typedef ucontext_t SIGCONTEXT;
++
++#define EAX_sig(context) ((context)->uc_mcontext.gregs[REG_EAX])
++#define EBX_sig(context) ((context)->uc_mcontext.gregs[REG_EBX])
++#define ECX_sig(context) ((context)->uc_mcontext.gregs[REG_ECX])
++#define EDX_sig(context) ((context)->uc_mcontext.gregs[REG_EDX])
++#define ESI_sig(context) ((context)->uc_mcontext.gregs[REG_ESI])
++#define EDI_sig(context) ((context)->uc_mcontext.gregs[REG_EDI])
++#define EBP_sig(context) ((context)->uc_mcontext.gregs[REG_EBP])
++#define ESP_sig(context) ((context)->uc_mcontext.gregs[REG_ESP])
++
++#define CS_sig(context) ((context)->uc_mcontext.gregs[REG_CS])
++#define DS_sig(context) ((context)->uc_mcontext.gregs[REG_DS])
++#define ES_sig(context) ((context)->uc_mcontext.gregs[REG_ES])
++#define SS_sig(context) ((context)->uc_mcontext.gregs[REG_SS])
++#define FS_sig(context) ((context)->uc_mcontext.gregs[REG_FS])
++#define GS_sig(context) ((context)->uc_mcontext.gregs[REG_GS])
++
++#define EFL_sig(context) ((context)->uc_mcontext.gregs[REG_EFL])
++#define EIP_sig(context) ((context)->uc_mcontext.gregs[REG_EIP])
++#define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO])
++#define ERROR_sig(context) ((context)->uc_mcontext.gregs[REG_ERR])
++
++#define FPU_sig(context) ((FLOATING_SAVE_AREA *)&(context)->uc_mcontext.fpregs.fp_reg_set.fpchip_state)
++#define FPUX_sig(context) NULL
++
++#endif /* __GNU__ */
++
+ #ifdef BSDI
+
+ #include <machine/frame.h>
+diff --git a/dlls/shell32/shfldr_unixfs.c b/dlls/shell32/shfldr_unixfs.c
+index 9649df8..cdd1798 100644
+--- a/dlls/shell32/shfldr_unixfs.c
++++ b/dlls/shell32/shfldr_unixfs.c
+@@ -369,7 +369,7 @@ static inline BOOL UNIXFS_is_pidl_of_type(LPCITEMIDLIST pIDL, SHCONTF fFilter) {
+ static BOOL UNIXFS_get_unix_path(LPCWSTR pszDosPath, char *pszCanonicalPath)
+ {
+ char *pPathTail, *pElement, *pCanonicalTail, szPath[FILENAME_MAX], *pszUnixPath, has_failed = 0, mb_path[FILENAME_MAX];
+- WCHAR wszDrive[] = { '?', ':', '\\', 0 }, dospath[PATH_MAX], *dospath_end;
++ WCHAR wszDrive[] = { '?', ':', '\\', 0 }, dospath[MAX_PATH], *dospath_end;
+ int cDriveSymlinkLen;
+ void *redir;
+
+diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c
+index ad8e08b..a8d6329 100644
+--- a/dlls/winex11.drv/xrender.c
++++ b/dlls/winex11.drv/xrender.c
+@@ -2440,8 +2440,8 @@ void X11DRV_XRender_UpdateDrawable(X11DRV_PDEVICE *physDev)
+ return;
+ }
+
+-BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, X11DRV_PDEVICE *devSrc,
+- struct bitblt_coords *dst, struct bitblt_coords *src, BLENDFUNCTION blendfn )
++BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, struct bitblt_coords *dst,
++ X11DRV_PDEVICE *devSrc, struct bitblt_coords *src, BLENDFUNCTION blendfn )
+ {
+ FIXME("not supported - XRENDER headers were missing at compile time\n");
+ return FALSE;
+diff --git a/libs/wine/ldt.c b/libs/wine/ldt.c
+index 3098061..b3fee13 100644
+--- a/libs/wine/ldt.c
++++ b/libs/wine/ldt.c
+@@ -96,6 +96,11 @@ static inline int set_thread_area( struct modify_ldt_s *ptr )
+ #include <i386/user_ldt.h>
+ #endif
+
++#ifdef __GNU__
++#include <mach/i386/mach_i386.h>
++#include <mach/mach_traps.h>
++#endif
++
+ /* local copy of the LDT */
+ #ifdef __APPLE__
+ struct __wine_ldt_copy wine_ldt_copy = { { 0, 0, 0 } };
+@@ -203,6 +208,9 @@ static int internal_set_entry( unsigned short sel, const LDT_ENTRY *entry )
+ #elif defined(__APPLE__)
+ if ((ret = i386_set_ldt(index, (union ldt_entry *)entry, 1)) < 0)
+ perror("i386_set_ldt");
++#elif defined(__GNU__)
++ if ((ret = i386_set_ldt(mach_thread_self(), sel, (descriptor_list_t)entry, 1)) != KERN_SUCCESS)
++ perror("i386_set_ldt");
+ #else
+ fprintf( stderr, "No LDT support on this platform\n" );
+ exit(1);
\ No newline at end of file diff --git a/open_issues/xattr.mdwn b/open_issues/xattr.mdwn new file mode 100644 index 00000000..558c93b7 --- /dev/null +++ b/open_issues/xattr.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +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="xattr: extended attributes"]] + +[[!tag open_issue_glibc open_issue_hurd]] + +This task is listed as a [[Google Summer of Code project +idea|community/gsoc/project_ideas/xattr]]. + +IRC, freenode, #hurd, 2011-06-01: + + <gnu_srs> Another thing: the lsattr and chattr programs seems to be bogus + on Hurd. Are they present since they are part of e2fsprogs? + <youpi> I don't think the Hurd has an interface for it + <tschwinge> gnu_srs, youpi: lsattr/chattr are extended attributes, right? + We do have some patches from years ago for adding some support in glibc, + but they're not yet integrated. And also we do have a plan for using + these instead of our Hurd-specific passive translator information in + inodes. + +If interested in working on this, talk to [[tschwinge]], and see these resources: + + * [[!GNU_Savannah_task 5503]], [[!GNU_Savannah_patch 5126]] + + * <http://lists.gnu.org/archive/html/bug-hurd/2006-02/threads.html#00115>, + <http://lists.gnu.org/archive/html/bug-hurd/2006-01/threads.html#00180>, + <http://lists.gnu.org/archive/html/bug-hurd/2006-05/threads.html#00042> + + * <http://www.spinics.net/lists/linux-ext4/msg07260.html>, + <http://www.spinics.net/lists/linux-ext4/msg07259.html>, + <http://www.spinics.net/lists/linux-ext4/msg07261.html> + + +IRC, OFTC, #debian-hurd, 2012-03-18: + + <pinotree> notes to self: it seems our ext2 driver comes from linux 2.3.42 + or so, and in linux 2.5.46 ext2/ext3 get xattr and acl support diff --git a/open_issues/xen_crash_copy-size_le_page_size.mdwn b/open_issues/xen_crash_copy-size_le_page_size.mdwn new file mode 100644 index 00000000..f2d8081e --- /dev/null +++ b/open_issues/xen_crash_copy-size_le_page_size.mdwn @@ -0,0 +1,104 @@ +[[!meta copyright="Copyright © 2009 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]] + +`/dev/hd2` is 2 GiB in size (backed by LVM), unformatted. + + # mkfs.ext2 -o hurd /dev/hd2 + mke2fs 1.41.7 (29-June-2009) + hd2 count 1 + re-open, hd2 count 2 + ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/hd2 is mounted. + re-open, hd2 count 3 + re-open, hd2 count 4 + re-open, hd2 count 5 + Filesystem label= + OS type: Hurd + Block size=4096 (log=2) + Fragment size=4096 (log=2) + 131072 inodes, 524288 blocks + 26214 blocks (5.00%) reserved for the super user + First data block=0 + Maximum filesystem blocks=536870912 + 16 block groups + 32768 blocks per group, 32768 fragments per group + 8192 inodes per group + Superblock backups stored on blocks: + 32768, 98304, 163840, 229376, 294912 + + Assertion `copy->size <= PAGE_SIZE' failed in file "../gnumach-1-branch-Xen-branch/xen/block.c", line 536 + Kernel Breakpoint trap, eip 0x20020a77 + Stopped at 0x20020a76: int $3 + db> trace + 0x20020a76(2006abc1,2006ba03,2006782c,218,2e2be8d4) + 0x20020ace(2006ba03,2006782c,218,2e3629a0,32000) + 0x2003e9d5(2de04764,2e2be0b8,12,0,3fff80) + 0x200476e6(2de5ad54,2e2db010,2e30a9a0,2de3a854,2de5ad44) + 0x20021ed4(2de5ad44,2e2bb2e0,2e2bb2a0,0,0) + 0x2005309d(129b8f0,3,38,28,e) + 0x20006838(129b8f0,3,38,28,e) + >>>>> user space <<<<< + + + $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020ace 0x2003e9d5 0x200476e6 0x20021ed4 0x2005309d 0x20006838 + Debugger + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105 + Assert + ??:0 + device_write + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/xen/block.c:537 + _Xdevice_write + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/device/device.server.c:253 + ipc_kobject_server + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_kobject.c:201 + mach_msg_trap + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/ipc/mach_msg.c:1367 + mach_call_call + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/i386/i386/locore.S:1083 + +GDB on `mkfs.ext2`: + + raw_write_blk (channel=0x80829d8, data=0x8082a40, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:272 + 272 actual = write(data->dev, buf, size); + (gdb) print size + $4 = 32768 + (gdb) bt + #0 raw_write_blk (channel=0x80829d8, data=0x8082a40, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:272 + #1 0x080635fc in unix_write_blk64 (channel=0x80829d8, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:673 + #2 0x0806373c in unix_write_blk (channel=0x80829d8, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:705 + #3 0x0805e87d in ext2fs_zero_blocks (fs=0x8082940, blk=524272, num=16, ret_blk=0x15ffb1c, ret_count=0x0) + at ../../../git/lib/ext2fs/mkjournal.c:182 + #4 0x0804ec56 in main (argc=131072, argv=0x80000) at ../../git/misc/mke2fs.c:2032 + +Discussion: + + <tschwinge> I had a look at the code, but unfortunately don't really know + how this data transfers between Xen and the domU work. + <tschwinge> Well, I know how it roughly works, but not the implementation + deatils. + <youpi> well here it's not about the xen/domU transfers + <youpi> it's about copying data to align it + <youpi> i.e. when offset is not aligned, I need to copy it + <tschwinge> Yes- + <youpi> I was lazy, just implemented it for things smaller than a page + <youpi> it just needs to be extended into copying several pages + <tschwinge> youpi: Hmm, do we need to copy all the data to shift away the + offset or is there a better way? + <youpi> the blkbackend needs data to be sector-aligned + <youpi> just aligning on a page makes offset computation simpler + <youpi> as it's rare that's not a problem + <tschwinge> And a sector is the usual 512 bytes there, I assume? + <tschwinge> But then we do need to copy all of it? + <youpi> let me check + <youpi> the sector is the granularity you can't go below + <youpi> sector is the sector_size reported by the backend + <youpi> but for sector_number and first/last_sect it's 512 + <youpi> yes, that's weird diff --git a/open_issues/xen_domu_with_ro_hd.mdwn b/open_issues/xen_domu_with_ro_hd.mdwn new file mode 100644 index 00000000..efbd2d18 --- /dev/null +++ b/open_issues/xen_domu_with_ro_hd.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Xen domU with a read-only HD"]] + +[[!tag open_issue_xen]] + +read-only hd3 + + foobar:~# e2fsck /dev/hd3 + e2fsck 1.40.11 (17-June-2008) + re-open, hd3 count 5 + re-open, hd3 count 6 + /dev/hd3 was not cleanly unmounted, check forced. + Pass 1: Checking inodes, blocks, and sizes + Pass 2: Checking directory structure + Pass 3: Checking directory connectivity + Pass 4: Checking reference counts + Pass 5: Checking group summary information + /dev/hd3: 2729/262144 files (0.2% non-contiguous), 34116/524288 blocks + Error writing block 1 (Attempt to write block from filesystem resulted in short write). Ignore error<y>? yes + + foobar:~# e2fsck /dev/hd3 + e2fsck 1.40.11 (17-June-2008) + re-open, hd3 count 7 + re-open, hd3 count 8 + e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/hd3 + Could this be a zero-length partition? diff --git a/open_issues/xen_lseek.mdwn b/open_issues/xen_lseek.mdwn new file mode 100644 index 00000000..756abf5e --- /dev/null +++ b/open_issues/xen_lseek.mdwn @@ -0,0 +1,57 @@ +[[!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-09-01: + + <youpi> hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768 + <youpi> no wonder it's slow + <youpi> unfortunately that's also what it does on linux, the system call is + just less costly + <youpi> apparently gfortran calls io_seek for, like, every token of the + sourced file + <youpi> (fgetpos actually, but that's the same) + <youpi> and it is indeed about 10 times slower under Xen for some reason + +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]]. + +Also see the simple testcases [[test-lseek.c]] and [[test-mach.c]]. + +IRC, freenode, #hurd, 2011-11-05: + + <youpi> [test-mach.c is] mostly as a reference for the trap overhead + <youpi> 0.56µs (xen) vs 0.48µs(kvm) on test-mach + <youpi> 455µs(xen) vs 16µs(kvm) on test-lseek + <youpi> that might simply be an issue in the RPC mechanism, which behaves + badly with the xen memory management + <youpi> yes, about 0.5ms for an lseek, that's quite high :) diff --git a/open_issues/xen_lseek/test-lseek.c b/open_issues/xen_lseek/test-lseek.c new file mode 100644 index 00000000..667dce66 --- /dev/null +++ b/open_issues/xen_lseek/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/xen_lseek/test-mach.c b/open_issues/xen_lseek/test-mach.c new file mode 100644 index 00000000..90337346 --- /dev/null +++ b/open_issues/xen_lseek/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/xorg_porting.mdwn b/open_issues/xorg_porting.mdwn new file mode 100644 index 00000000..5f540e44 --- /dev/null +++ b/open_issues/xorg_porting.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="X.Org Porting"]] + +[[!tag open_issue_porting]] + +See the list of [Hurd-related X.Org project +ideas](http://xorg.freedesktop.org/wiki/Hurd_Porting). diff --git a/persistency.mdwn b/persistency.mdwn index f5347a4e..d45ebacc 100644 --- a/persistency.mdwn +++ b/persistency.mdwn @@ -1,18 +1,42 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] A persistent object is an object that survives reboot. On [[Unix]], files and directories are persistent but -processes and file descriptors are not. [[microkernel/EROS]] is +processes and [[unix/file_descriptor]]s are not. [[microkernel/EROS]] is an example of an orthogonally persistent system: -processes and capabilities also survive reboot. To a +processes and [[capabilities|capability]] also survive reboot. To a process, it generally only looks as if it had not been scheduled for a long time; the rest of its environment remains essentially the indistinguishable. + + +# GNU/Hurd + +The GNU/Hurd is not a persistent system: there are no persistent +[[capabilities|capability]]. All data that is stored in files in the file +system, is serialized. + + +# Further Reading + +[[!toggleable id=shapiro_capintro_1999 text="""[[!template id=note +text="*[[shapiro\_capintro\_1999|capability]]*: +{{$capability#shapiro_capintro_1999}}. +{{$capability#shapiro_capintro_1999_text}}."]]"""]] + + * Section *Writing Things Down* in [[!toggle id=shapiro_capintro_1999 + text="[shapiro\_capintro\_1999]"]]. + + +[[!tag open_issue_documentation]] <!-- +<http://www.eros-os.org/essays/Persistence.html> +--> diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn index f7b264fb..1e60022b 100644 --- a/public_hurd_boxen.mdwn +++ b/public_hurd_boxen.mdwn @@ -1,38 +1,62 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 2009, 2010, 2011, 2012 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -Here are some Hurd boxes that users have made available to the public: +[[!tag stable_URL]] + +There are GNU/Hurd boxes that we're offering shell accounts on. These are +generally available for everyone interested in [[contributing]], or just having +a look at a GNU/Hurd system. + +An alternative to online shell access may be using a [[QEMU +image|hurd/running/qemu]]. [[!table class="table_style_1" data=""" -"Host Name","Operator","Access","Distro","Machine Specs","Comments" -"flubber.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2250","Debian","Celeron; 2.2 GHz; 333 MiB","domU on zenhost" -"clubber.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2251","Debian","PIII 1 GHz; 384 MiB" -"gnubber.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2254","Debian","PII 733 MHz; 384 MiB" -"goober.bddebian.com","[[Barry_de_Freese|bddebian]]","ssh; port 2255","Debian","?" +"Hoster","Name","Distribution","Machine Specs","Comments" +"[[bddebian]]","blubber","Debian GNU/Hurd","Celeron 2.2 GHz; 222 MiB","Xen domU on [[zenhost]]; for experimental stuff; deactivated until needed again (apart from [[tschwinge]], only [[scolobb]] has an account, but is not active at the moment)" +"[[bddebian]]","clubber","Debian GNU/Hurd","PIII 1 GHz; 384 MiB" +"[[bddebian]]","flubber","Debian GNU/Hurd","Celeron 2.2 GHz; 666 MiB","Xen domU on [[zenhost]]" +"[[bddebian]]","snubber","Debian GNU/Hurd","Celeron 2.2 GHz; 243 MiB","Xen domU on [[zenhost]]; web server" +"[[bddebian]]","gnubber","Debian GNU/Hurd","PII 733 MHz; 384 MiB" +"[[bddebian]]","goober","Debian GNU/Hurd","?" +"[[bddebian]]","grubber","Debian GNU/Hurd","Celeron 2.2 GHz; 554 MiB","Xen domU on [[zenhost]]; for experimental stuff" +"[[bddebian]]","[[zenhost]]","Debian GNU/Linux","Celeron 2.2 GHz","Xen dom0 for several hosts" +"[[sceen]]","darnassus","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; public Hurd box" +"[[sceen]]","ironforge","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; Debian buildd" +"[[sceen]]","exodar","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; Debian porterbox, all Debian Developers have access" +"[[sceen]]","shattrath","Debian GNU/Linux","Core i5 3.1 GHz","KVM host" +"Debian","strauss","Debian GNU/Hurd","Sempron 2800+","all Debian Developers have access" """]] -To request an account on the `*.bddebian.com` machines either contact -*bddebian* or *tschwinge* (other people might also be able to help) in [[IRC]] -or send email to <hurd-shell-account@gnu.org>. Also use these contact -addresses for requesting support with respect to software installations, etc. +If you are a Debian Developer, you can log into the exodar or strauss machines +with your DD account, your public ssh keys are already there. To request a +non-DD account on them, please contact admin@{exodar,strauss}.debian.net, with +your Alioth account name and a public ssh key. +To request an account on the *[[bddebian]]* or *[[sceen]]* machines, please +contact <hurd-shell-account@gnu.org> (don't forget to include your desired user +name and public SSH key). Also use that contact address for requesting +support, such as get additional packages installed. -To be able to use just `ssh [machine]`, you should append your public SSH key +For easy access, you should append your public SSH key(s) to `~/.ssh/authorized_keys` on the remote machine. -And if you don't want to worry about the machines's IP addresses changing (due -to dial-up connection) or the host keys changing every now and then (when the -machines are re-installed), put something like the following into -`~/.ssh/config` of the machine you connect from: +Also, add the following stanza to the `~/.ssh/config` file of the machine +you're connecting from. + + # Stanza from <http://www.gnu.org/software/hurd/public_hurd_boxen.html>, + # 2011-11-06. + Host blubber.bddebian.com blubber + HostName blubber.bddebian.com + Host clubber.bddebian.com clubber HostName clubber.bddebian.com Port 2251 @@ -49,8 +73,27 @@ machines are re-installed), put something like the following into HostName goober.bddebian.com Port 2255 - Host *.bddebian.com clubber flubber gnubber goober + Host grubber.bddebian.com grubber + HostName grubber.bddebian.com + + Host snubber.bddebian.com snubber + HostName snubber.bddebian.com + + Host zenhost.bddebian.com zenhost + HostName zenhost.bddebian.com + Port 2260 + + Host blubber.bddebian.com blubber grubber.bddebian.com grubber snubber.bddebian.com snubber + # Tunnel through zenhost. + ProxyCommand ssh zenhost exec socat - TCP4:%h:%p + + Host *.bddebian.com blubber clubber flubber gnubber goober grubber snubber zenhost + # Don't worry about the IP address (dial-up connection). CheckHostIP no - UserKnownHostsFile /dev/null - StrictHostKeyChecking no - User [username] + User [user name] + + Host darnassus.sceen.net darnassus + HostName darnassus.sceen.net + + Host *.sceen.net darnassus + User [user name] diff --git a/public_hurd_boxen/bddebian.mdwn b/public_hurd_boxen/bddebian.mdwn new file mode 100644 index 00000000..82fb0b8c --- /dev/null +++ b/public_hurd_boxen/bddebian.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +# IP addresses + + * [[zenhost]]: 192.168.10.60 + * blubber: 192.168.10.61 + * flubber: 192.168.10.50 + * grubber: 192.168.10.63 + * snubber: 192.168.10.62 + +At least anything in the .60 range can be used. + +Registered in zenhost's `/etc/hosts`. diff --git a/public_hurd_boxen/installation.mdwn b/public_hurd_boxen/installation.mdwn new file mode 100644 index 00000000..4f612a83 --- /dev/null +++ b/public_hurd_boxen/installation.mdwn @@ -0,0 +1,128 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +This page documents how installation of a new machine is being done on +[[zenhost]]. + +This method uses +*[install_crosshurd](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=install_crosshurd)*. + +Another option might be switching to <http://www.informatik.uni-koeln.de/fai/> +or a equivalent system. + +Steps for *install_crosshurd*: + + * Enable loggin with screen (`C-a H`). + + * \# lvcreate ... + + * machines/[MACHINE] + + * \# MACHINE=[MACHINE] TARGET=/dev/zenhost/[MACHINE]-root ./install_crosshurd + + * \# sudo umount /tmp/*/target + + * /etc/xen/[MACHINE] + + * \# xm create -c [MACHINE] + + * \# /install + + * TODO + + Unpacking debconf (from .../debconf_1.5.28_all.deb) ... + + debconf-set-selections + warning: Unknown type error, skipping line 9 + + * TODO + + Unpacking bash (from .../bash_4.1-3_hurd-i386.deb) ... + The bash upgrade discovered that your /bin/sh link points to dash. + As bash for Debian is destined to provide a working /bin/sh (pointing to + /bin/bash) your link will be overwritten by a default link. + + If you don't want further upgrades to overwrite your customization, please + read /usr/share/doc/bash/README.Debian.gz for a more permanent solution. + + [Press RETURN to continue] + + That file doesn't say anything about it. + + * TODO; related to the *debconf-set-selections* thing above + + Setting up libpam-runtime (1.1.1-6) ... + debconf: unable to initialize frontend: Dialog + debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 75.) + debconf: falling back to frontend: Readline + debconf: unable to initialize frontend: Readline + debconf: (Can't locate Term/ReadLine.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.) + debconf: falling back to frontend: Teletype + Configuring libpam-runtime + -------------------------- + + Pluggable Authentication Modules (PAM) determine how authentication, + authorization, and password changing are handled on the system, as well as + allowing configuration of additional actions to take when starting user + sessions. + + Some PAM module packages provide profiles that can be used to automatically + adjust the behavior of all PAM-using applications on the system. Please + indicate which of these behaviors you wish to enable. + + 1. Unix authentication + + (Enter the items you want to select, separated by spaces.) + + PAM profiles to enable: + + * if it's a Xen domU: + + # sudo apt-get --purge install libc0.3-xen libc0.3-i686- + + * As needed: + + # mkfs.ext2 -I 128 -b 4096 /dev/hd2 # TAKE CARE! + # settrans /media/data /hurd/ext2fs /dev/hd2 + # mkdir /media/data/home + # rmdir /home && ln -s media/data/home / + + # mkfs.ext2 -I 128 -b 4096 /dev/hd3 # TAKE CARE! + # settrans /media/var /hurd/ext2fs /dev/hd3 + # mv /var /media/var/ + # ln -s media/var/var / + + * If needed: restore (parts of) some files + + * /etc/{passwd,shadow,group,gshadow} + + * \# adduser ... sudo + + * \# passwd root + + * (`mkdir /etc/ssh`), restore `/etc/ssh/ssh_host_*key*` + + * \# syncfs -s && halt + + * \# xm create -c [MACHINE] + + * \# /install_packages + + * Until [[open_issues/screen]] is fixed: + + * Install `flubber:~tschwinge/screen_4.0.3-11_hurd-i386.deb` instead. + + * \# printf 'screen\thold\n' | dpkg --set-selections + + * add line to zenhost's `/etc/hosts` + + * system-specific: + + * [[flubber]] + * [[snubber]] diff --git a/public_hurd_boxen/installation/flubber.mdwn b/public_hurd_boxen/installation/flubber.mdwn new file mode 100644 index 00000000..5ef0d314 --- /dev/null +++ b/public_hurd_boxen/installation/flubber.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +# additional packages + +ikiwiki + + +# SSH Daemon + +`/etc/ssh/sshd_config` + + Port 2250 + + +# Git Daemon + +`/etc/rc.local` + + # runit doesn't work yet... + LC_ALL=C date >> /var/log/git-daemon + git daemon --verbose --user-path >> /var/log/git-daemon 2>&1 & + +Should [[fix runit|open issues/runit]] and use Debian's `git-daemon-run` +package instead. + + +# *polipo* + +`/etc/polipo/config` + + # local begin + + # TODO: "::0" doesn't work, at least not with a a PF_INET6 translator. + proxyAddress = "0.0.0.0" + + # Size to which on-disk objects are truncated. + #diskCacheTruncateSize integer 1048576 + # Time after which on-disk objects are truncated. + #diskCacheTruncateTime time 4d12h + diskCacheTruncateTime = 50d + # Time after which on-disk objects are removed. + #diskCacheUnlinkTime = 32d + diskCacheUnlinkTime = 100d + + # local end diff --git a/public_hurd_boxen/installation/snubber.mdwn b/public_hurd_boxen/installation/snubber.mdwn new file mode 100644 index 00000000..68e0d619 --- /dev/null +++ b/public_hurd_boxen/installation/snubber.mdwn @@ -0,0 +1,66 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +# Additional Packages + +Before 2010-08-12, we've been using apache2-mpm-worker, but that brought +the system to its knees too often, leading to a un-syncable rootfs, etc. +Let's see how apache2-mpm-prefork behaves. + + apache2-mpm-prefork build-essential git-core gitweb ikiwiki inetutils-inetd + less libtext-csv-perl netcat nullmailer perlmagick screen texinfo + +Yet more: + + * libemail-send-perl (for my *sendmail vs. ikiwiki* patch) + + * libsearch-xapian-perl xapian-omega (for ikiwiki's search plugin) + + * libyaml-perl (for ikiwiki's YAML field plugins) + + +## [[open_issues/syslog]] + + $ find /etc/rc*/ | grep syslog | sudo xargs rm + + +# `~hurd-web/` + + $ mkdir hurd-web && GIT_DIR=hurd-web git init + + +# `~tschwinge/` + + $ mkdir tmp/backup && chmod 0733 tmp/backup + + +# `/var/www/robots.txt` + +This file used to contain: + + User-agent: * + Disallow: /gitweb/ + Disallow: /cgi-bin/ + +... which I've now changed to: + + User-agent: * + Disallow: / + +The goal is that robots rather index the official pages, +<http://www.gnu.org/software/hurd/>, instead of the staging area on +<http://www.bddebian.com:8888/~hurd-web/>. + + +# Restore Backup + +## `/etc/apache2/mods-enabled/` + +`rewrite.load`, `userdir.conf`, `userdir.load` diff --git a/public_hurd_boxen/sceen.mdwn b/public_hurd_boxen/sceen.mdwn new file mode 100644 index 00000000..25416857 --- /dev/null +++ b/public_hurd_boxen/sceen.mdwn @@ -0,0 +1,11 @@ +[[!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]]."]]"""]] + +<http://www.sceen.net/> diff --git a/public_hurd_boxen/xen_handling.mdwn b/public_hurd_boxen/xen_handling.mdwn new file mode 100644 index 00000000..d4e33ce9 --- /dev/null +++ b/public_hurd_boxen/xen_handling.mdwn @@ -0,0 +1,50 @@ +[[!meta copyright="Copyright © 2009, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +# listing running domUs + + $ sudo xm list + + $ sudo xm top + +# handling running domUs + +Forcefully killing a domU (that has crashed or is busy-looping, etc.): + + $ sudo xm destroy [domU] + +As for (re-)starting a domU, read below in *domU consoles*. + +Using `xm shutdown [domU]` to gracefully shut down a running domU does not yet +work -- this is not yet implemented in the [[Xen port of GNU +Mach|microkernel/mach/gnumach/ports/xen]] ([[!taglink open_issue_xen]]). + +# domU consoles + +To avoid any complications with people trying to use the same console at the +same time, please use this command for attaching to a domU's console (this +command line will also start the domU in case that it isn't running already): + + $ host=[domU] && sudo screen -DRRS console-$host sh -c "xm console $host || xm create -c $host" + +Otherwise, if one attaches to the same console twice, the second instance will +in fact forward input to the domU (possibly infering with what the person is +doing on the first instance), but the output won't be sent back to the second +instance. + +After having typed this once, Bash's `reverse-search-history` (`C-r`), followed +by typing in `host=flubber`, for example, will be enough to get access to +that machine's console. + +/!\ TODO: How does one get the environment variables `COLUMNS` and `LINES` set +properly when using `xm console`? According to Samuel, *you don't, the xen +console doesn't have the notion of terminal size*. This is relevant for +everything using `(n)curses` -- for interactive console applications. Using +`export COLUMNS=143 LINES=44` does work, but is a manual process. diff --git a/public_hurd_boxen/zenhost.mdwn b/public_hurd_boxen/zenhost.mdwn new file mode 100644 index 00000000..b828b8e9 --- /dev/null +++ b/public_hurd_boxen/zenhost.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +*zenhost* is a Xen dom0 (hosted by [[bddebian]]) which is hosting several domUs +(see the table on [[public hurd boxen]] for a list). + + +[[!inline pages=public_hurd_boxen/xen_handling feeds=no]] + + +# [[Installation of new machines|installation]] diff --git a/purify_html b/purify_html index a9ead881..9c3a7862 100755 --- a/purify_html +++ b/purify_html @@ -1,11 +1,39 @@ #!/bin/sh +# Mangle the rendered files to cause fewer differences after re-rendering. + +# Written by Thomas Schwinge <thomas@schwinge.name>. + # Un-mangle mailto links: convert HTML character entities to real characters. find ./ -name \*.html -print0 \ - | xargs -0 \ - perl -p -i -l -e \ - 'BEGIN { $replacing = 0; } - # The replacing-toggling logic is a bit rough, but so is life. - $replacing = 1 if /<a href="mailto:/; - s%\&#(x?)([^;]*);%chr(length($1) ? hex($2) : $2)%eg if $replacing; - $replacing = 0 if /<\/a>/;' + | xargs -0 --no-run-if-empty -n 1 \ + perl -e \ + 'BEGIN { + $file = $ARGV[0]; + $discard = 1; + $replacing = 0; + + # TODO: could use a proper temporary file. + open(OUT, ">$file.new") or die "open: $file: $!"; + select(OUT) or die "select: $file: $!"; + } + + while (<>) { + # The replacing-toggling logic is a bit rough, but so is life. + $replacing = 1 if /<a href="mailto:/; + s%\&#(x?)([^;]*);%$discard = 0; chr(length($1) ? hex($2) : $2);%eg if $replacing; + $replacing = 0 if /<\/a>/; + } continue { + print or die "print: $file: $!"; + } + + END { + if ($discard) { + unlink("$file.new") or die "unlink: $file: $!"; + } else { + rename("$file.new", $file) or die "rename: $file: $!"; + } + }' + +# Compared to using ``perl -p -i -l'', this solution maintains the files' +# original timestamps unless they're actually modified. @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2005, 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2005, 2007, 2008, 2009, 2010 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] QEMU is free software written by Fabrice Bellard that implements a fast processor [[emulator|emulation]], allowing a user to run one operating system @@ -19,8 +19,8 @@ reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: * User mode emulation: QEMU can launch Linux processes compiled for one CPU - on another CPU. Linux system calls are converted because of endianness and - 32/64 bit mismatches. Wine and Dosemu are the main targets for QEMU. + on another CPU. Linux [[system call]]s are converted because of endianness + and 32/64 bit mismatches. Wine and Dosemu are the main targets for QEMU. * System mode emulation: QEMU emulates a full system, including a processor and various peripherials. It enables easier testing and debugging of diff --git a/render_locally b/render_locally index ba0dd9d8..ca7856f5 100755 --- a/render_locally +++ b/render_locally @@ -2,30 +2,42 @@ # Render the pages of this repository. -# Written by Thomas Schwinge <tschwinge@gnu.org> +# Written by Thomas Schwinge <tschwinge@gnu.org>. # See `contributing/web_pages' for further information. export ROOT && ROOT=$(readlink -f "$(dirname "$0")") && +# Don't translate. +export LC_MESSAGES && LC_MESSAGES=C && + case $1 in + # Use this for rendering the set of pages which are to be installed under + # <http://www.gnu.org/software/hurd/>. --official) - # Use this for rendering the set of pages which are to be installed under - # <http://www.gnu.org/software/hurd/>. shift && + export TZ && TZ=UTC && export DESTDIR && DESTDIR=$ROOT.rendered.official && + # Use ``--no-usedirs'' here, so that not too many separate directories have # to be created. + # + # Use ``--gettime --plugin update_mtimes'' to reset pages' / files' mtimes + # according to the RCS information when using --refresh mode. set x \ --set wikistatedir="$ROOT"/.ikiwiki-official \ --url http://www.gnu.org/software/hurd \ --no-usedirs \ + --gettime --plugin reset_mtimes \ "$@" && shift;; + --w3m-wrapper) shift && + export NO_MSG && NO_MSG=y && + # Disable the configured VCS, as the CGI wrapper together with using the # anonok plugin inhibits the propagation of authorship information. set x \ @@ -34,21 +46,27 @@ case $1 in --rcs norcs \ "$@" && shift && + exec \ "$0" \ --w3m \ "$@";; + --w3m) shift && + export DESTDIR && DESTDIR=$ROOT.rendered.w3m && + set x \ --set wikistatedir="$ROOT"/.ikiwiki-w3m \ --cgiurl hurd-web.cgi --w3mmode \ "$@" && shift && + exec \ "$0" \ "$@";; + *) # Use ``--no-usedirs'' here, because when browsing local files, the web # browsers don't display `index.html' files by default when a hyperlink @@ -1,11 +1,19 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] RPC stands for remote procedure call. + + +# See Also + + * [[Mach RPC|microkernel/mach/rpc]]s + + * the [[Hurd's rpctrace|hurd/debugging/rpctrace]] diff --git a/rules/savannah_group.mdwn b/rules/savannah_group.mdwn index 4e2cf357..9ade863e 100644 --- a/rules/savannah_group.mdwn +++ b/rules/savannah_group.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] <http://savannah.gnu.org/projects/hurd/> @@ -27,13 +27,3 @@ the [[contributing/questionnaire]]. The list of members can be seen at <http://savannah.gnu.org/project/memberlist.php?group=hurd>. - -<a name="copyright_assignment"> -## Copyright assignment -</a> - -If you have pieces of code or documentation to contribute, then, in order to -install them into our [[source_repositories]], you have to assign the copyright -of your changes to the [Free Software Foundation](http://www.fsf.org/). - -Please [[contact_us]] to request the needed forms. diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index 6240b422..8215af3b 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -9,145 +9,4 @@ 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]]."]]"""]] -Git repositories on Savannah, see <http://git.savannah.gnu.org/cgit/> (search -for *hurd*). - -# Branches - -Members of the [[Hurd_Savannah_group|savannah_group]] are allowed to create -branches without formal permission: - - * named `BASE_BRANCH-SAVANNAH_LOGIN[-TOPIC]` for private general-purpose or - topic branches, respectively, or - * named `BASE_BRANCH-TOPIC` for public topic branches basing on - `BASE_BRANCH`. - -`TOPIC` shall be a suitable tag describing the branch's main concern. These -tags can be applied recursively (`TOPIC-SUBTOPIC-SUBSUBTOPIC`). - -*private* vs. *public* does, of course, in this scenario not mean visibility, -but instead authority: *private* branches are those that the user -`SAVANNAH_LOGIN` has authority over, whereas *public* branches are open for -every committer to install changes on. The private branches are those that you -would typically host on your own machine and publish through your own web -server, but we offer that you can instead do this from the centralized Savannah -repository, as a number of people don't have an always-accessible web server -running on their own machines. - -Examples: - - * GNU Mach - - * `master` -- the mainline branch - * `master-oskit` -- port to OSKit; branched off of `master` at some point - * `master-gdb_stubs` -- add support for GDB stubs; branched off of - `master` at some point - - * libpthread - - * `master` -- the mainline branch - * `master-viengoos` -- port to Viengoos; branched off of `master` at some - point - * `master-viengoos-on-bare-metal` -- port to Viengoos running on bare - metal; branched off of `master-viengoos` at some point - - * unionfs - - * `master` -- the mainline branch - * `master-unionmount` -- develop `unionmount` based on `unionfs`' master - branch - -To give a concrete example, the latter one was created like this: - - $ git clone --no-checkout ssh://git.savannah.gnu.org/srv/git/hurd/unionfs.git - $ cd unionfs/ - $ git checkout -b master-unionmount origin/master - $ ... - $ git push master-unionmount - -## Merging - -Merging between Git branches is trivial, at least as long as no conflicts -arise. - -Due to this, you are encouraged to freely make use of separate branches for -different working topics, as this really faciliates concentrating on one -specific working topic. - -You are encouraged to regularely merge from the respective mainline branches -(`BASE_BRANCH`; should be `master` in most cases) into your working branches, -and ensure that your modifications are still fine in the context of new -mainline changes. - -Merging from working branches into the mainline branches will usually be done -by one of the project administrators, unless negotiated otherwise. For this to -happen, the copyright of your changes has to be assigned to the Free Software -Foundation; read about the -[[copyright_assignment_process|savannah_group#copyright_assignment]]. - -# Tags - -Equivalent rules apply. - -# Behavior - -Try to not introduce spurious, unneeded changes, e.g., whitespace changes. - -Adhere to the coding conventions that are already used. These are usually the -[GNU Coding Standards](http://www.gnu.org/prep/standards/html_node/) for stuff -written by ourselves, including new files, of course. - -GNU Mach code is largely based on external code. Don't GNU-ify it, as this -would make merging external patches unnecessarily difficult. - -## Commit messages - -We no longer maintain parallel `ChangeLog` and commit messages. When needed, -the `ChangeLog` files can be created automatically from the commit messages. - -Commit messages have this mandatory format: - - One-line summary. - Blank line. - ChangeLog-like list of changes, but without leading tabs. - -The header line of each former `ChangeLog` snippet (DATE NAME EMAIL) is no -longer to be included in the commit message, and instead the author and -committer of a change, together with the dates, will be maintained natively by -Git. - -Example: - - commit 3054666a46e0142cacef895c13edb4391435c722 - Author: Some One <someone@example.com> - AuthorDate: Thu Jun 11 15:59:55 2005 +0000 - Commit: Some One <someone@example.com> - CommitDate: Thu Jun 11 15:59:55 2005 +0000 - - Frobnicate the foo. - - * frob.c (foo): Frob it. - * oldfoo.c [OLD] (oldfoo): Likewise. - [OLD_OLD_FOO] (oofoo): Permute every second word with itself, and - beginning with the tenth line, every third one also. Pure - nonsense. - -Read about how to write [GNU-style `ChangeLog` -messages](http://www.gnu.org/prep/standards/html_node/Change-Logs.html). - -Don't waste time writing exhaustive `ChangeLog`-like commit messages for, e.g., -debugging stuff that will be removed again before merging your development -branch into the mainline. Sometimes the one-line summary might already -suffice. But please do write something. - -## Behavior on *private* branches - -Even though you are said to be the owner of branches tagged with your -`SAVANNAH_LOGIN`, it is generally nevertheless good to not do history-rewriting -stuff and the like (`git rebase` and friends), as others may in turn be basing -their work on your private branches. - -We could establish a branch-tagging policy for branches that others should -expect their history possibly to be rewritten. This may be useful for branches -that are only meant for aggregating the changes of (several) development -branches, like an imaginary `master-proposed_for_general_testing` branch. +[[!meta redir=/source_repositories]] diff --git a/sandbox.mdwn b/sandbox.mdwn index def5fae7..b90e8160 100644 --- a/sandbox.mdwn +++ b/sandbox.mdwn @@ -6,7 +6,7 @@ There even is a [[subsandbox]]. Here's a paragraph. -Here's another one with *emphasised* text. +Here's another one with *emphasized* text. # Header diff --git a/security.mdwn b/security.mdwn index 0e22df00..222c4a68 100644 --- a/security.mdwn +++ b/security.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Alan Karp [identifies][1] 11 security questions: @@ -58,3 +59,7 @@ Online non-overt channels (both covert & side) are auditory: Offline non-overt channels are olfactory: * Bob can smell that Kilroy was here, even if Kilroy is asleep or dead. + +--- + +[[Open Issues related to security|open_issues/security]]. diff --git a/set_mtimes b/set_mtimes new file mode 100755 index 00000000..7157e7f5 --- /dev/null +++ b/set_mtimes @@ -0,0 +1,56 @@ +#!/bin/sh + +# Set the checked-out files' mtimes according to their last Git revision. + +# Written by Thomas Schwinge <tschwinge@gnu.org> + +trap ' + if [ x"$tmp_dir" = x ]; then :; else + rm -rf -- "$tmp_dir" + fi +' EXIT && + +# TODO: handle arguments meaning to only process a subset (directories / files) +# of the repository. +if [ x"$#" = x0 ]; then :; else + echo >&2 No command line arguments expected. + exit 1 +fi && + +tmp_dir=$(mktemp -d) && + +tmp_ignore=$tmp_dir/ignore && +# TODO: have to add more flags? +git ls-files \ + > "$tmp_ignore" \ + -d -m && +while read file; do + echo >&2 "*** WARNING: file <$file> locally changed or deleted, not touching" +done < "$tmp_ignore" && + +tmp_known=$tmp_dir/known && +git ls-files \ + > "$tmp_known" \ + -c && + +tmp_consider=$tmp_dir/consider && +grep \ + < "$tmp_known" \ + > "$tmp_consider" \ + -f "$tmp_ignore" -x -v && + +while read file; do + # TODO: use %ci? TODO: can we optimize this to not have to invoke git log + # individually for every single file? + date_git=$(git log -1 --pretty=format:%ai -- "$file") && + date_git=$(date --rfc-3339=ns -d "$date_git") && + date_file=$(date --rfc-3339=ns -r "$file") && + if [ x"$date_git" = x"$date_file" ]; then :; else + echo >&2 "*** INFO: file $file: mtime <$date_file> -> <$date_git>" + touch -m -d "$date_git" "$file" + fi \ + || { + echo >&2 "*** ERROR: file <$file>, date_git <$date_git>, date_file <$date_file>" + exit 1 + } +done < "$tmp_consider" diff --git a/shortcuts.mdwn b/shortcuts.mdwn index 47698bb2..38c7b3c7 100644 --- a/shortcuts.mdwn +++ b/shortcuts.mdwn @@ -7,6 +7,7 @@ Some examples of using shortcuts include: \[[!google foo]] \[[!wikipedia War_of_1812]] \[[!debbug 12345]] + Check the \[[!cia ikiwiki desc="CIA page for %s"]]. This page controls what shortcut links the wiki supports. @@ -14,16 +15,19 @@ This page controls what shortcut links the wiki supports. * [[!shortcut name=archive url="http://web.archive.org/*/%S"]] * [[!shortcut name=gmap url="http://maps.google.com/maps?q=%s"]] * [[!shortcut name=gmsg url="http://groups.google.com/groups?selm=%s"]] -* [[!shortcut name=wikipedia url="http://en.wikipedia.org/wiki/%s"]] +* [[!shortcut name=wikipedia url="http://en.wikipedia.org/wiki/%S"]] * [[!shortcut name=wikitravel url="http://wikitravel.org/en/%s"]] -* [[!shortcut name=debbug url="http://bugs.debian.org/%s" desc="bug #%s"]] +* [[!shortcut name=wiktionary url="http://en.wiktionary.org/wiki/%s"]] +* [[!shortcut name=debbug url="http://bugs.debian.org/%S" desc="Debian bug #%s"]] * [[!shortcut name=deblist url="http://lists.debian.org/debian-%s" desc="debian-%s@lists.debian.org"]] * [[!shortcut name=debpkg url="http://packages.debian.org/%s"]] +* [[!shortcut name=debpkgsid url="http://packages.debian.org/sid/%s"]] * [[!shortcut name=debpts url="http://packages.qa.debian.org/%s"]] * [[!shortcut name=debmsg url="http://lists.debian.org/msgid-search/%s"]] * [[!shortcut name=debrt url="https://rt.debian.org/Ticket/Display.html?id=%s"]] * [[!shortcut name=debss url="http://snapshot.debian.net/package/%s"]] * Usage: `\[[!debss package]]`, `\[[!debss package#version]]`, or `\[[!debss package/version]]`. See http://snapshot.debian.net for details. +* [[!shortcut name=debwiki url="http://wiki.debian.org/%s"]] * [[!shortcut name=fdobug url="https://bugs.freedesktop.org/show_bug.cgi?id=%s" desc="freedesktop.org bug #%s"]] * [[!shortcut name=fdolist url="http://lists.freedesktop.org/mailman/listinfo/%s" desc="%s@lists.freedesktop.org"]] * [[!shortcut name=gnomebug url="http://bugzilla.gnome.org/show_bug.cgi?id=%s" desc="GNOME bug #%s"]] @@ -53,21 +57,24 @@ This page controls what shortcut links the wiki supports. * [[!shortcut name=cia url="http://cia.vc/stats/project/%s"]] * [[!shortcut name=ciauser url="http://cia.vc/stats/user/%s"]] * [[!shortcut name=flickr url="http://www.flickr.com/photos/%s"]] +* [[!shortcut name=man url="http://linux.die.net/man/%s"]] +* [[!shortcut name=ohloh url="http://www.ohloh.net/projects/%s"]] To add a new shortcut, use the `shortcut` -[[ikiwiki/PreprocessorDirective]]. In the url, "%s" is replaced with the -text passed to the named shortcut, after url-encoding it, and '%S' is -replaced with the raw, non-encoded text. The optional `desc` parameter -controls the description of the link. +[[ikiwiki/directive]]. In the url, "%s" is replaced with the +text passed to the named shortcut, after [[!wikipedia url_encoding]] +it, and '%S' is replaced with the raw, non-encoded text. The optional +`desc` parameter controls the description of the link. Remember that the `name` you give the shortcut will become a new -[[ikiwiki/PreprocessorDirective]]. Avoid using a `name` that conflicts -with an existing directive. +[[ikiwiki/directive]]. Avoid using a `name` that conflicts +with an existing directive. These directives also accept a `desc` +parameter that will override the one provided at definition time. If you come up with a shortcut that you think others might find useful, -consider contributing it to the [[!iki shortcuts]] page on the ikiwiki -ikiwiki, so that future versions of ikiwiki will include your shortcut -in the standard underlay. +consider contributing it to the [shortcuts page on the ikiwiki +wiki](http://ikiwiki.info/shortcuts/), so that future versions of +ikiwiki will include your shortcut in the standard underlay. # Local stuff @@ -76,3 +83,28 @@ in the standard underlay. * [[!shortcut name=GNU_Savannah_bug url="http://savannah.gnu.org/bugs/?%s" desc="GNU Savannah bug #%s"]] * [[!shortcut name=GNU_Savannah_patch url="http://savannah.gnu.org/patch/?%s" desc="GNU Savannah patch #%s"]] * [[!shortcut name=GNU_Savannah_task url="http://savannah.gnu.org/task/?%s" desc="GNU Savannah task #%s"]] + +* [[!shortcut name=FF_project url="http://www.fossfactory.org/project/p%s" desc="FOSS Factory bounty (p%s)"]] + + +## Savannah + + * [[!shortcut name=GNU_Savannah_Git_hurd_hurd + url="http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=%s" + desc="hurd/hurd.git commit %s"]] + + +## Notmuch'n'Gmane. + + * [[!shortcut name=message-id url="http://thread.gmane.org/%s" desc="""`id:"%s"`"""]] + + +## sourceware + + * [[!shortcut name=GCC_PR + url="http://gcc.gnu.org/PR%s" + desc=GCC [BZ #%s]"]] + + * [[!shortcut name=sourceware_PR + url="http://sourceware.org/PR%s" + desc="sourceware [BZ #%s]"]] diff --git a/sidebar.mdwn b/sidebar.mdwn index 7d71cd28..7143329d 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -1,33 +1,41 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -Welcome to... [[!img hurd/logo/boxes-redrawn.png link=/hurd/logo]] ... the GNU -Hurd! +Welcome to... [[!img /logo/boxes-redrawn.png link=/logo]] ... the GNU Hurd! + +--- * **[[Home|/index]]** * **[[Community]]** + * [[Contact_Us]] + * **[[Donate]]** + * **[[Contributing]]** + * [[Public_Hurd_Boxen]] + * [[QEMU Images|hurd/running/qemu]] + * [[Getting Help]] + * [[Open Issues]] * **[[Documentation]]** - * **[[Getting Help]]** - * **[[Open Issues]]** + * [[FAQ]] --- - * **[[Hurd]]**[[!if test="destpage(hurd*)" then=" - * *[[Hurd/Documentation]]* - * *[[hurd/Running]]*"]] - * **[[microkernel/Mach]]**[[!if test="destpage(microkernel/mach*)" then=" - * *[[microkernel/mach/Documentation]]* - * *[[GNU Mach|microkernel/mach/gnumach]]*"]] - * *[[microkernel/mach/MIG]]*[[!if test="destpage(microkernel/mach/mig*)" then=" - * [[microkernel/mach/mig/GNU MIG]]"]] + * **[[Hurd]]** + * [[Hurd/Documentation]] + * [[hurd/Running]] + * **[[microkernel/Mach]]** + * [[microkernel/mach/Documentation]] + * [[GNU Mach|microkernel/mach/gnumach]] + * **[[microkernel/mach/MIG]]** + * [[Documentation|microkernel/mach/mig/documentation]] + * [[microkernel/mach/mig/GNU MIG]] --- diff --git a/source_repositories.mdwn b/source_repositories.mdwn new file mode 100644 index 00000000..cd478c70 --- /dev/null +++ b/source_repositories.mdwn @@ -0,0 +1,258 @@ +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +This page is meant to give some guidelines. Please use good sense or ask on +[[mailing_lists/bug-hurd]] if there are any questions. + + +[[!toc levels=3]] + + +# Git repositories on Savannah + +<http://git.savannah.gnu.org/cgit/hurd> + + * hurd.git -- Hurd meta package; no real content yet + * [[hurd/glibc.git|glibc]] -- [[/glibc]] maintenance + * hurd/gnumach.git -- [[GNU Mach|microkernel/mach/gnumach]] + ([[microkernel/mach/gnumach/building]]) + * hurd/hurd.git -- [[/Hurd]] ([[hurd/building]]) + * [[hurd/incubator.git|incubator]] -- the great next stuff + * hurd/libpthread.git -- [[POSIX threading library|libpthread]] + * hurd/mig.git -- [[microkernel/mach/MIG]] + ([[microkernel/mach/mig/gnu_mig/building]]) + * hurd/procfs.git -- [[hurd/translator/procfs]] + * hurd/unionfs.git -- [[hurd/translator/unionfs]] + * hurd/viengoos.git -- [[microkernel/Viengoos]] + ([[microkernel/viengoos/building]]) + * hurd/web.git -- [[contributing/Web_pages]] + + +## Branches + +Members of the [[Hurd Savannah group|rules/savannah group]] are allowed to create +branches without formal permission: + + * named `SAVANNAH_LOGIN/BASE_BRANCH[-TOPIC]` or + `SAVANNAH_LOGIN/TOPIC/BASE_BRANCH` for private general-purpose or + topic branches, respectively, or + * named `BASE_BRANCH-TOPIC` or `TOPIC/BASE_BRANCH` for public topic branches + basing on + `BASE_BRANCH`. + +`TOPIC` shall be a suitable tag describing the branch's main concern. These +tags can be applied recursively (`TOPIC/SUBTOPIC/BASE_BRANCH`, like +`pfinet_rewrite/use_lwIP/master`, for example). + +*private* vs. *public* does, of course, in this scenario not mean visibility +(all branches are externally visible), +but instead authority: *private* branches are those that the user +`SAVANNAH_LOGIN` has authority over, whereas *public* branches are open for +every committer to install changes on. The private branches are those that you +would typically host on your own machine and publish through your own web +server, but we offer that you can instead do this from the centralized Savannah +repository, as a number of people don't have an always-accessible web server +running on their own machines. + + +### Subprojects + +Some repositories hold a bunch of independent subprojects, first and foremost +the [[incubator]] repository. + +Even though we've been doing differently in the past, branches in there shall +be named like this: + + * `SUBPROJECT/master` for the `master` branch; + * `SUBPROJECT/SAVANNAH_LOGIN/BASE_BRANCH[-TOPIC]` or + `SUBPROJECT/SAVANNAH_LOGIN/TOPIC/BASE_BRANCH` for private general-purpose + or topic branches, respectively, or + * `SUBPROJECT/BASE_BRANCH-TOPIC` or `SUBPROJECT/TOPIC/BASE_BRANCH` for public + topic branches basing on `SUBPROJECT/BASE_BRANCH`. + +That is, we introduce a top-level `SUBPROJECT` hierarchy, where distinct +per-subproject Git repositories could have been used instead. + + +### Examples + + * GNU Mach + + * `master` -- the mainline branch + * `master-oskit` -- port to OSKit; branched off of `master` at some point + * `master-gdb_stubs` -- add support for GDB stubs; branched off of + `master` at some point + + * libpthread + + * `master` -- the mainline branch + * `master-viengoos` -- port to Viengoos; branched off of `master` at some + point + * `master-viengoos-on-bare-metal` -- port to Viengoos running on bare + metal; branched off of `master-viengoos` at some point + + * incubator + + * `master` -- not to be used + * `tarfs/master` -- `master` branch of the `tarfs` subproject + + * unionfs + + * `master` -- the mainline branch + * `master-unionmount` -- develop `unionmount` based on `unionfs`' master + branch + +To give a concrete example, the latter one was created like this: + + $ git clone --no-checkout ssh://git.savannah.gnu.org/srv/git/hurd/unionfs.git + $ cd unionfs/ + $ git checkout -b master-unionmount origin/master + $ ... + $ git push master-unionmount + +### Merging + +Merging between Git branches is trivial, at least as long as no conflicts +arise. + +Due to this, you are encouraged to freely make use of separate branches for +different working topics, as this really faciliates concentrating on one +specific working topic. + +You are encouraged to regularely merge from the respective mainline branches +(`BASE_BRANCH`; should be `master` in most cases) into your working branches, +and ensure that your modifications are still fine in the context of new +mainline changes. + +Merging from working branches into the mainline branches will usually be done +by one of the project administrators, unless negotiated otherwise. For this to +happen, the copyright of your changes has to be assigned to the Free Software +Foundation; read about the [[contributing/copyright_assignment]] process. + +It is explicitly encouraged to *merge* changes from working branches into the +mainline branches (as opposed to *rebase* them on top), as the former mode +easily allows to determine the context under which a patch has been developed. + +## Tags + +Equivalent rules apply. + +## Behavior + +Try to not introduce spurious, unneeded changes, e.g., whitespace changes. + +Adhere to the coding conventions that are already used. These are usually the +[GNU Coding Standards](http://www.gnu.org/prep/standards/html_node/) for stuff +written by ourselves, including new files, of course. + +GNU Mach code is largely based on external code. Don't GNU-ify it, as this +would make merging external patches unnecessarily difficult. + +### Commit messages + +We no longer maintain parallel `ChangeLog` and commit messages. When needed, +the `ChangeLog` files can be created automatically from the commit messages. + +Commit messages have this mandatory format: + + One-line summary. + Blank line. + ChangeLog-like list of changes, but without leading tabs. + +The header line of each former `ChangeLog` snippet (DATE NAME EMAIL) is no +longer to be included in the commit message, and instead the author and +committer of a change, together with the dates, will be maintained natively by +Git. + +Example: + + commit 3054666a46e0142cacef895c13edb4391435c722 + Author: Some One <someone@example.com> + AuthorDate: Thu Jun 11 15:59:55 2005 +0000 + Commit: Some One <someone@example.com> + CommitDate: Thu Jun 11 15:59:55 2005 +0000 + + Frobnicate the foo. + + * frob.c (foo): Frob it. + * oldfoo.c [OLD] (oldfoo): Likewise. + [OLD_OLD_FOO] (oofoo): Permute every second word with itself, and + beginning with the tenth line, every third one also. Pure + nonsense. + +Read about how to write [GNU-style `ChangeLog` +messages](http://www.gnu.org/prep/standards/html_node/Change-Logs.html). + +Don't waste time writing exhaustive `ChangeLog`-like commit messages for, e.g., +debugging stuff that will be removed again before merging your development +branch into the mainline. Sometimes the one-line summary might already +suffice. But please do write something. + +### Behavior on *private* branches + +Even though you are said to be the owner of branches tagged with your +`SAVANNAH_LOGIN`, it is generally nevertheless good to not do history-rewriting +stuff and the like (`git rebase` and friends), as others may in turn be basing +their work on your private branches. + +We could establish a branch-tagging policy for branches that others should +expect their history possibly to be rewritten. This may be useful for branches +that are only meant for aggregating the changes of (several) development +branches, like an imaginary +`rewrite_pfinet/for_master_and_proposed_for_general_testing` branch. + + +# Git repositories on flubber + +[[flubber|public hurd boxen]] is +[[configured|public_hurd_boxen/installation/flubber]] in a way so that users +can publish Git repositories from their home directories. The only thing to do +is to put an empty `.git/git-daemon-export-ok` (cf. [*git daemon*'s manual +page](http://www.kernel.org/pub/software/scm/git/docs/git-daemon.html)) into +the repository, or just `git-daemon-export-ok` for +[*bare*](http://www.kernel.org/pub/software/scm/git/docs/git-init.html) +repositories. + +For example, the [[contributing/web pages]] repository is made available like +this: `~hurd-web/hurd-web` is a bare repository; there is an empty +`~hurd-web/hurd-web/git-daemon-export-ok` file. Users can clone the repository +like this: + + $ git clone git://flubber.bddebian.com/~hurd-web/hurd-web + +Another example, [[Thomas Schwinge|tschwinge]] has a checkout of +[[libpthread]] in `~tschwinge/tmp/hurd/libpthread/`, the +`~tschwinge/tmp/hurd/libpthread/.git/git-daemon-export-ok` file exists. If you +really need to, you can clone it like this: + + $ git clone git://flubber.bddebian.com/~tschwinge/tmp/hurd/libpthread + +## List of Interesting Repositories + + * web pages: git://flubber.bddebian.com/~hurd-web/hurd-web + + +# Git repositories on grubber + +## List of Interesting Repositories + + * [[binutils]] + * [[GCC]] + + +# Debian Git repositories + +IRC, #hurd, 2010-07-31 + + <tschwinge> git-buildpackage is to be used to build these new Debian repositories, I guess? + <youpi> well, the Vcs-Git control header is about everything people need to know, I believe :) + <youpi> git-buildpackage is just mostly an easy way to build the .orig.tar.Gz from the tag + <youpi> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html diff --git a/source_repositories/binutils.mdwn b/source_repositories/binutils.mdwn new file mode 100644 index 00000000..52053b97 --- /dev/null +++ b/source_repositories/binutils.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +There is a repository for maintenance of [[/binutils]] for the Hurd's needs: +`grubber:~tschwinge/tmp/binutils/git`. + +This repository uses [[TopGit]] and is based on +<http://sourceware.org/git/?p=binutils.git;a=summary>. 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/source_repositories/gcc.mdwn b/source_repositories/gcc.mdwn new file mode 100644 index 00000000..899adc30 --- /dev/null +++ b/source_repositories/gcc.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +There is a repository for maintenance of [[/GCC]] for the Hurd's needs: +`grubber:~tschwinge/tmp/gcc/git`. + +This repository uses [[TopGit]] and is based on +<http://gcc.gnu.org/wiki/GitMirror>. diff --git a/source_repositories/gdb.mdwn b/source_repositories/gdb.mdwn new file mode 100644 index 00000000..76b82534 --- /dev/null +++ b/source_repositories/gdb.mdwn @@ -0,0 +1,15 @@ +[[!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 +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]]."]]"""]] + +There is a repository for maintenance of [[/GDB]] for the Hurd's needs: +`grubber:~tschwinge/tmp/gdb/git`. + +This repository uses [[TopGit]] and is based on +<http://sourceware.org/git/?p=gdb.git;a=summary>. diff --git a/source_repositories/glibc.mdwn b/source_repositories/glibc.mdwn new file mode 100644 index 00000000..fabd7cab --- /dev/null +++ b/source_repositories/glibc.mdwn @@ -0,0 +1,93 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +There is a repository for maintenance of [[/glibc]] for the Hurd's needs: +<http://git.savannah.gnu.org/cgit/hurd/glibc.git/>. + +This repository uses [[TopGit]]. + +*A plan for the Hurd-specific glibc repository*, thread +[begins](http://lists.gnu.org/archive/html/bug-hurd/2010-01/msg00062.html), +[continues](http://lists.gnu.org/archive/html/bug-hurd/2010-02/msg00021.html). + + +# Usage + +## Clone + + $ git init + $ git remote add savannah git://git.sv.gnu.org/hurd/glibc.git + $ git remote update + $ tg remote --populate savannah + tg: Remote savannah can now follow TopGit topic branches. + tg: Populating local topic branches from remote 'savannah'... + From git://git.sv.gnu.org/hurd/glibc + * [new branch] refs/top-bases/t/_dl_random -> savannah/top-bases/t/_dl_random + * [new branch] refs/top-bases/t/accept4 -> savannah/top-bases/t/accept4 + [...] + * [new branch] refs/top-bases/tschwinge/Roger_Whittaker -> savannah/top-bases/tschwinge/Roger_Whittaker + tg: Adding branch t/_dl_random... + tg: Adding branch t/accept4... + [...] + tg: Adding branch tschwinge/Roger_Whittaker... + tg: The remote 'savannah' is now the default source of topic branches. + +## Use tschwinge's Working Branch + + $ git checkout tschwinge/Roger_Whittaker + +## Integrate a New Branch + +A new (TopGit) branch has been published upstream: + + $ tg remote --populate savannah + tg: Remote savannah can now follow TopGit topic branches. + tg: Populating local topic branches from remote 'savannah'... + remote: Counting objects: 28, done. + remote: Compressing objects: 100% (19/19), done. + remote: Total 20 (delta 13), reused 1 (delta 0) + Unpacking objects: 100% (20/20), done. + From git://git.sv.gnu.org/hurd/glibc + * [new branch] t/unwind-resume.c -> savannah/t/unwind-resume.c + * [new branch] refs/top-bases/t/unwind-resume.c -> savannah/top-bases/t/unwind-resume.c + tg: Skipping branch t/____longjmp_chk: Already exists + [...] + tg: Skipping branch t/tlsdesc.sym: Already exists + tg: Adding branch t/unwind-resume.c... + tg: Skipping branch t/verify.h: Already exists + tg: Skipping branch tschwinge/Roger_Whittaker: Already exists + tg: The remote 'savannah' is now the default source of topic branches. + +Make `tschwinge/Roger_Whittaker` (the current branch) depend on it: + + $ tg depend add t/unwind-resume.c + [tschwinge/Roger_Whittaker 63f11ff] New TopGit dependency: t/unwind-resume.c + 1 files changed, 1 insertions(+), 0 deletions(-) + tg: Updating base with t/unwind-resume.c changes... + Auto-merging .topdeps + Auto-merging .topmsg + Merge made by recursive. + nptl/sysdeps/pthread/Makefile | 12 ++---------- + sysdeps/gnu/Makefile | 18 ++++++++++++++++-- + .../pthread => sysdeps/gnu}/rt-unwind-resume.c | 0 + .../pthread => sysdeps/gnu}/unwind-resume.c | 4 ++-- + 4 files changed, 20 insertions(+), 14 deletions(-) + rename {nptl/sysdeps/pthread => sysdeps/gnu}/rt-unwind-resume.c (100%) + rename {nptl/sysdeps/pthread => sysdeps/gnu}/unwind-resume.c (93%) + tg: The tschwinge/Roger_Whittaker head is up-to-date wrt. its remote branch. + tg: Updating tschwinge/Roger_Whittaker against new base... + Merge made by recursive. + nptl/sysdeps/pthread/Makefile | 12 ++---------- + sysdeps/gnu/Makefile | 18 ++++++++++++++++-- + .../pthread => sysdeps/gnu}/rt-unwind-resume.c | 0 + .../pthread => sysdeps/gnu}/unwind-resume.c | 4 ++-- + 4 files changed, 20 insertions(+), 14 deletions(-) + rename {nptl/sysdeps/pthread => sysdeps/gnu}/rt-unwind-resume.c (100%) + rename {nptl/sysdeps/pthread => sysdeps/gnu}/unwind-resume.c (93%) diff --git a/source_repositories/incubator.mdwn b/source_repositories/incubator.mdwn new file mode 100644 index 00000000..51f64c17 --- /dev/null +++ b/source_repositories/incubator.mdwn @@ -0,0 +1,12 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +There is a repository for *this*, and *that*, and *everything* -- the +*incubator*: <http://git.savannah.gnu.org/cgit/hurd/incubator.git/>. diff --git a/system_call.mdwn b/system_call.mdwn new file mode 100644 index 00000000..197889cb --- /dev/null +++ b/system_call.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +In an [[UNIX]]-like system, a *system call* (*syscall*) is used to request all +kinds of functionality from the operating system kernel. + +A [[microkernel]]-based system typically won't offer a lot of system calls -- +apart from one central one, and that is *send message* -- but instead [[RPC]]s +will be used instead. + +In the [[GNU Hurd|hurd]], a lot of what is traditionlly considered to be a UNIX +system call is implemented (primarily by means of [[RPC]]) inside [[glibc]]. diff --git a/systemtap.mdwn b/systemtap.mdwn new file mode 100644 index 00000000..ba64c0d4 --- /dev/null +++ b/systemtap.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]]."]]"""]] + +[[!meta title="SystemTap"]] + +[[!tag open_issue_hurd open_issue_gnumach]] + +# Overview + + * {{$wielaard_fosdem_2010}} + + +# Related + + * [[community/gsoc/project_ideas/dtrace]] + + * [[LTTng]] + + +[[!ymlfront data=""" + +wielaard_fosdem_2010: + + "[*Interview with Mark + Wielaard*](http://fosdem.org/2010/interview/mark-wielaard) for FOSDEM 2010" + +"""]] diff --git a/tag.mdwn b/tag.mdwn new file mode 100644 index 00000000..7f8f38db --- /dev/null +++ b/tag.mdwn @@ -0,0 +1,75 @@ +[[!meta copyright="Copyright © 2009, 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 +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The following [[!iki ikiwiki/directive/tag desc=tags]] are actively used at the +moment: + +[[!map +pages="tag/* and !tag/*/*" +show=title]] + +Most of them should be self-explanatory, and for the others, here are the +explanations: + + * *bounty* + + {{$bounty}} + + * *fixed_in_debian* + + {{$fixed_in_debian}} + + * *open_issue_documentation* + + {{$open_issue_documentation}} + + * *open_issue_porting* + + {{$open_issue_porting}} + + * *stable_URL* + + {{$stable_URL}} + + +[[!ymlfront data=""" + +bounty: + + There is a *bounty* put on these issues! Typically, these are handled via + [[FOSS Factory|donate#FOSS_Factory]]. + +fixed_in_debian: + + This tag is used to tag items that have been fixed in the [[Debian + GNU/Hurd|hurd/running/debian]] distribution, but not yet in the upstream + sources. + +open_issue_documentation: + + Used for tagging pages / items that need to be handled / improved for + documentation purposes. + +open_issue_porting: + + A list of open issues in porting software to run on GNU/Hurd systems. This + list also includes [[toolchain]]-level items, items that are either already + solved in [[Debian GNU/Hurd|hurd/running/debian]] systems (tagged + *fixed_in_debian*) or being worked around, so if you're out for working on + application-level porting issues, then perusing through the list of [[Debian + packages that need porting|hurd/running/debian/porting]] may be better. + +stable_URL: + + These pages are tagged as having a *stable URL*. That is, they're linked to + from external pages, and their locations should not be changed needlessly. + +"""]] diff --git a/tag/bounty.mdwn b/tag/bounty.mdwn new file mode 100644 index 00000000..ae19814b --- /dev/null +++ b/tag/bounty.mdwn @@ -0,0 +1,23 @@ +[[!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="bounty"]] + +{{$tag#bounty}} + +[[!map +pages="tagged(bounty)" +show=title]] + +We're always looking for donators, for developers who are hunting bounties, and +for new project ideas! + +Please read about how to start [[working on a task and/or suggesting a new +task|donate#FOSS_Factory]]. diff --git a/tag/fixed_in_debian.mdwn b/tag/fixed_in_debian.mdwn index e36e6b84..4d946fd4 100644 --- a/tag/fixed_in_debian.mdwn +++ b/tag/fixed_in_debian.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,16 +8,10 @@ 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=fixed_in_debian]] +[[!meta title="fixed_in_debian"]] -This tag is used to tag items that have been fixed in the [[Debian -GNU/Hurd|hurd/running/debian]] distribution, but not yet in the upstream -sources. +{{$tag#fixed_in_debian}} -[[!map pages="tagged(fixed_in_debian) and !*/discussion" +[[!map +pages="tagged(fixed_in_debian)" show=title]] - -[[!inline -pages="tagged(fixed_in_debian) and !open_issues and !*/discussion" -show=0 -feeds=no]] diff --git a/tag/open_issue_binutils.mdwn b/tag/open_issue_binutils.mdwn new file mode 100644 index 00000000..b0fd7b08 --- /dev/null +++ b/tag/open_issue_binutils.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="open_issue_binutils"]] + +[[!map +pages="tagged(open_issue_binutils)" +show=title]] diff --git a/tag/open_issue_documentation.mdwn b/tag/open_issue_documentation.mdwn new file mode 100644 index 00000000..f0d1cb4c --- /dev/null +++ b/tag/open_issue_documentation.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="open_issue_documentation"]] + +{{$tag#open_issue_documentation}} + +[[!map +pages="tagged(open_issue_documentation)" +show=title]] diff --git a/tag/open_issue_gcc.mdwn b/tag/open_issue_gcc.mdwn index a06a9d70..b880d152 100644 --- a/tag/open_issue_gcc.mdwn +++ b/tag/open_issue_gcc.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,12 +8,8 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title=open_issue_gcc]] +[[!meta title="open_issue_gcc"]] -[[!map pages="tagged(open_issue_gcc) and !open_issues and !*/discussion" +[[!map +pages="tagged(open_issue_gcc)" show=title]] - -[[!inline -pages="tagged(open_issue_gcc) and !open_issues and !*/discussion" -show=0 -feeds=no]] diff --git a/tag/open_issue_gdb.mdwn b/tag/open_issue_gdb.mdwn index 937aafc2..02363dd5 100644 --- a/tag/open_issue_gdb.mdwn +++ b/tag/open_issue_gdb.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,12 +8,8 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title=open_issue_gdb]] +[[!meta title="open_issue_gdb"]] -[[!map pages="tagged(open_issue_gdb) and !open_issues and !*/discussion" +[[!map +pages="tagged(open_issue_gdb)" show=title]] - -[[!inline -pages="tagged(open_issue_gdb) and !open_issues and !*/discussion" -show=0 -feeds=no]] diff --git a/tag/open_issue_glibc.mdwn b/tag/open_issue_glibc.mdwn index e4d22881..5e0a7a39 100644 --- a/tag/open_issue_glibc.mdwn +++ b/tag/open_issue_glibc.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 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,12 +8,10 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title=open_issue_glibc]] +[[!meta title="open_issue_glibc"]] -[[!map pages="tagged(open_issue_glibc) and !open_issues and !*/discussion" -show=title]] +There is a [[!FF_project 269]] on some glibc tasks. -[[!inline -pages="tagged(open_issue_glibc) and !open_issues and !*/discussion" -show=0 -feeds=no]] +[[!map +pages="tagged(open_issue_glibc)" +show=title]] diff --git a/tag/open_issue_gnumach.mdwn b/tag/open_issue_gnumach.mdwn index 5a46840d..e0ea81bc 100644 --- a/tag/open_issue_gnumach.mdwn +++ b/tag/open_issue_gnumach.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 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,12 +8,10 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title=open_issue_gnumach]] +[[!meta title="open_issue_gnumach"]] -[[!map pages="tagged(open_issue_*mach) and !open_issues and !*/discussion" -show=title]] +There is a [[!FF_project 265]] on some GNU Mach tasks. -[[!inline -pages="tagged(open_issue_*mach) and !open_issues and !*/discussion" -show=0 -feeds=no]] +[[!map +pages="tagged(open_issue_gnumach)" +show=title]] diff --git a/tag/open_issue_hurd.mdwn b/tag/open_issue_hurd.mdwn index 2e3c7206..a28b3200 100644 --- a/tag/open_issue_hurd.mdwn +++ b/tag/open_issue_hurd.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 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,12 +8,10 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title=open_issue_hurd]] +[[!meta title="open_issue_hurd"]] -[[!map pages="tagged(open_issue_hurd) and !open_issues and !*/discussion" -show=title]] +There is a [[!FF_project 269]] on some GNU Hurd tasks. -[[!inline -pages="tagged(open_issue_hurd) and !open_issues and !*/discussion" -show=0 -feeds=no]] +[[!map +pages="tagged(open_issue_hurd)" +show=title]] diff --git a/tag/open_issue_libpthread.mdwn b/tag/open_issue_libpthread.mdwn new file mode 100644 index 00000000..b4b7723e --- /dev/null +++ b/tag/open_issue_libpthread.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="open_issue_libpthread"]] + +[[!map +pages="tagged(open_issue_libpthread)" +show=title]] diff --git a/tag/open_issue_llvm.mdwn b/tag/open_issue_llvm.mdwn new file mode 100644 index 00000000..7fb11473 --- /dev/null +++ b/tag/open_issue_llvm.mdwn @@ -0,0 +1,15 @@ +[[!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="open_issue_llvm"]] + +[[!map +pages="tagged(open_issue_llvm)" +show=title]] diff --git a/tag/open_issue_mig.mdwn b/tag/open_issue_mig.mdwn index 8ac476cc..79ef3acb 100644 --- a/tag/open_issue_mig.mdwn +++ b/tag/open_issue_mig.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,12 +8,8 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title=open_issue_mig]] +[[!meta title="open_issue_mig"]] -[[!map pages="tagged(open_issue_mig) and !open_issues and !*/discussion" +[[!map +pages="tagged(open_issue_mig)" show=title]] - -[[!inline -pages="tagged(open_issue_mig) and !open_issues and !*/discussion" -show=0 -feeds=no]] diff --git a/tag/open_issue_porting.mdwn b/tag/open_issue_porting.mdwn index f89badcb..efa488b7 100644 --- a/tag/open_issue_porting.mdwn +++ b/tag/open_issue_porting.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,19 +8,10 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title=open_issue_porting]] +[[!meta title="open_issue_porting"]] -Here is a list of open issues in porting software to run on GNU/Hurd systems. -This list also includes [[hurd/toolchain]]-level items, items that are either -already solved in [[Debian GNU/Hurd|hurd/running/debian]] systems (tagged -*fixed_in_debian*) or being worked around, so if you're out for working on -application-level porting issues, then perusing through the list of [[Debian -packages that need porting|hurd/running/debian/porting]] may be better. +{{$tag#open_issue_porting}} -[[!map pages="tagged(open_issue_porting) and !open_issues and !*/discussion" +[[!map +pages="tagged(open_issue_porting)" show=title]] - -[[!inline -pages="tagged(open_issue_porting) and !open_issues and !*/discussion" -show=0 -feeds=no]] diff --git a/tag/open_issue_viengoos.mdwn b/tag/open_issue_viengoos.mdwn index d9662803..6f564e06 100644 --- a/tag/open_issue_viengoos.mdwn +++ b/tag/open_issue_viengoos.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,12 +8,8 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title=open_issue_viengoos]] +[[!meta title="open_issue_viengoos"]] -[[!map pages="tagged(open_issue_viengoos) and !open_issues and !*/discussion" +[[!map +pages="tagged(open_issue_viengoos)" show=title]] - -[[!inline -pages="tagged(open_issue_viengoos) and !open_issues and !*/discussion" -show=0 -feeds=no]] diff --git a/tag/open_issue_xen.mdwn b/tag/open_issue_xen.mdwn new file mode 100644 index 00000000..fbe40652 --- /dev/null +++ b/tag/open_issue_xen.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="open_issue_xen"]] + +[[!map +pages="tagged(open_issue_xen)" +show=title]] diff --git a/tag/stable_URL.mdwn b/tag/stable_URL.mdwn new file mode 100644 index 00000000..ff4067f6 --- /dev/null +++ b/tag/stable_URL.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="stable_URL"]] + +{{$tag#stable_URL}} + +[[!map +pages="tagged(stable_URL)" +show=title]] diff --git a/templates/highlight.mdwn b/templates/highlight.mdwn new file mode 100644 index 00000000..c8da1377 --- /dev/null +++ b/templates/highlight.mdwn @@ -0,0 +1,3 @@ +<div class="infobox"> +<TMPL_VAR text> +</div> diff --git a/toolchain.mdwn b/toolchain.mdwn new file mode 100644 index 00000000..26144cc3 --- /dev/null +++ b/toolchain.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 2007, 2008, 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 +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]]."]]"""]] + + * [[binutils]] + + * [[GCC]] + + * [[glibc]] + + * [[libpthread]] + + +Before beginning to work on the inner parts of the GNU/Hurd toolchain, it's +always profitable to also know how things are done on other systems. Compare, +for example, how things are done differently for GNU/Hurd than they are done +for GNU/Linux. + + +--- + + * [[ELFOSABI_GNU]] + +--- + + * [[cross-gnu]] diff --git a/toolchain/cross-gnu.mdwn b/toolchain/cross-gnu.mdwn new file mode 100644 index 00000000..451e9d44 --- /dev/null +++ b/toolchain/cross-gnu.mdwn @@ -0,0 +1,218 @@ +[[!meta copyright="Copyright © 2007, 2008, 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 +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 stable_URL]] + +[[Thomas_Schwinge|tschwinge]] has written a shell script for building a +complete cross-build environment for GNU/Hurd systems. + +Find it in the [[source_repositories/incubator]], *cross-gnu/master* branch. + + +# Using + +Read through it. Understand it. Only then use it by following the next steps. + + +# Status + +/!\ Please note that these cross toolchains does not yet encompass all of the +functionality that native toolchains provide. For example, there is only +support for C and C++ so far, but not for other languages. A bunch of fixes / +enhancements of [[glibc]] are missing. We're working towards minimizing these +differences, as well as towards pushing all patches upstream. + + +## Supported Versions of Source Packages + +/!\ This is outdated. Contact [[tschwinge]]. + +The following ones are known to work. Others may work as well, but no +guarantee is given. Always the preferred version is listed first. + + * [[`src/binutils`|binutils]] + + * CVS `binutils-2_20-branch` + + $ mkdir binutils-2_20-branch + $ cd binutils-2_20-branch/ + $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/src ↩ + co -r binutils-2_20-branch binutils + + The sources are rooted in `binutils-2_20-branch/src/`. Also use the above + commands for updating, instead of the usual `cvs update`. + + * Release 2.22 or later from <ftp://ftp.gnu.org/gnu/binutils/> + should also be fine. + + * [[`src/gcc`|gcc]] + + * SVN `gcc-4_5-branch` + + $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch + + Patches: + + * <http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00602.html> + + Prepare: + + $ ( cd gcc-4_5-branch/ && contrib/gcc_update --touch ) + + * SVN `gcc-4_4-branch` + + $ svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch + + Patches: + + * <http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00602.html> + + Prepare: + + $ ( cd gcc-4_4-branch/ && contrib/gcc_update --touch ) + + * Releases of the 4.5 and 4.4 series from <ftp://ftp.gnu.org/gnu/gcc/> + should also be fine, but need the same set of patches as the + `gcc-4_5-branch` needs. + + * [[`src/gnumach`|microkernel/mach/gnumach]] + + * Git `master` branch + + $ git clone ↩ + git://git.sv.gnu.org/hurd/gnumach.git gnumach + + Prepare: + + $ ( cd gnumach/ && autoreconf -vi ) + + * [[`src/mig`|microkernel/mach/mig/gnu_mig]] + + * Git `master` branch + + $ git clone ↩ + git://git.sv.gnu.org/hurd/mig.git mig + + Prepare: + + $ ( cd mig/ && autoreconf -vi ) + + * [[`src/hurd`|hurd]] + + * Git `master` branch + + $ git clone ↩ + git://git.sv.gnu.org/hurd/hurd.git hurd + + * [[`src/libpthread`|libpthread]] + + * Git `tschwinge/Peter_Herbolzheimer` branch + + $ git clone --no-checkout ↩ + git://git.sv.gnu.org/hurd/libpthread.git libpthread + $ cd libpthread/ + $ git checkout origin/tschwinge/Peter_Herbolzheimer + + Prepare: + + $ ( cd libpthread/ && autoreconf -vi ) + + * [[`src/glibc`|glibc]] + + * Git `tschwinge/Roger_Whittaker` branch + + $ git clone --no-checkout ↩ + git://git.sv.gnu.org/hurd/glibc.git glibc + $ cd glibc/ + $ git checkout origin/tschwinge/Roger_Whittaker + +<!-- + + * [[`src/gdb`|gdb]] + + This is optional and will only be compiled if present. + + * CVS `gdb_6_6-branch` + + $ cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/src ↩ + co -r gdb_6_6-branch gdb + $ mv src gdb_6_6-branch + + Also needs some patch because of MIG changes, if I remember correctly. + + * Recent tarballs from <ftp://ftp.gnu.org/gnu/gdb/> should also work. + +--> + + +## Preparation + +The raw source code trees are about 1 GiB. + +Unpack the tarballs if you downloaded any. + +Create a directory where the cross build shall be rooted in, and a `src` +subdirectory in there. Then create symbolic links for every of the above +packages: from `src/PACKAGE` to where you stored or unpacked it. If you don't +intend to build several cross compilers or use the source trees otherwise, you +can also directly store the source trees in `src/`. The source trees can be +shared between multiple cross build trees since the packages' build systems are +supposed not to modify the files in the source trees. Not all packages adhere +to that, but they fail to do so only for pre-processed documentation, etc. + +Either make sure that `cross-gnu-env` and `cross-gnu` are found in `$PATH` +(`~/bin/`, for example) or alternatively remember to use their full paths in +the following. + +The system you're running the script on (the *build* system) needs to have +basic development tools installed, that is, a C compiler with libraries, +`make`, and several more packages. If anything is missing, the *cross-gnu* +build will abort, and you have to install the missing dependencies and resume +the *cross-gnu* build. + + +## Setting Up the Environment + +Do this every time you intend to use the cross compiler: + + $ ROOT=to/the/cross/build/root + $ . cross-gnu-env + +This will set several environment variables, which are later used by (a) the +`cross-gnu` script and (b) by you, the user of the cross compiler. `$TARGET` +will be set by the script, `$PATH` will be adjusted, etc. See the +`cross-gnu-env` file for all environment variables that are set, as well as +their default values. `$ROOT` will be made an absolute path if it isn't +already. + +Later, you'll be able to do things like `../configure --host="$TARGET"`, and the +cross compiler will be found automatically. + + +## Creating the Cross Build Environment + +This will need an additional 2 GiB. + +After setting up the environemt, just run `cross-gnu` and watch the messages +flow by. In the end you should see a message: *[...]/cross-gnu: Everything +should be in place now.* + + +## Staying Up-To-Date + +You can re-run `cross-gnu` to rebuild the parts of the sources that have +changed since the last run. This will save a lot of time compared to starting +from scratch again. Also, it is especially useful if you aren't working with +unpacked tarballs, but on CVS's / SVN's / Git's branches or want to quickly get +a new toolchain +with patches you applied to the source trees. However: do *not* use this +technique when doing major changes to the source trees, like switching from GCC +4.4 to GCC 4.5. diff --git a/toolchain/elfosabi_gnu.mdwn b/toolchain/elfosabi_gnu.mdwn new file mode 100644 index 00000000..16b7d342 --- /dev/null +++ b/toolchain/elfosabi_gnu.mdwn @@ -0,0 +1,40 @@ +[[!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="ELFOSABI_GNU"]] + +GNU/Hurd uses the `ELFOSABI_GNU` value for operating system/ABI identification. +This is shared with GNU/Linux. + + +# Open Issues + +The [[/glibc]] patch is currently to be found in [[Savannah +glibc|source_repositories/glibc]] TopGit branch `t/elfosabi_gnu`. + + +# History + + * [[!debbug 630180]], [[!debbug 632686]] + * [sourceware bug + 12913](http://sourceware.org/bugzilla/show_bug.cgi?id=12913) + * [libc-alpha + thread](http://sourceware.org/ml/libc-alpha/2011-06/threads.html#00087) + ([continues](http://sourceware.org/ml/libc-alpha/2011-07/threads.html#00031)) + * [bug-hurd + thread](http://lists.gnu.org/archive/html/bug-hurd/2011-06/threads.html#00060) + ([continues](http://lists.gnu.org/archive/html/bug-hurd/2011-07/threads.html#00020)) + * [generic-abi + thread](http://groups.google.com/group/generic-abi/browse_frm/thread/194697b94a189063) + * [binutils + thread](http://sourceware.org/ml/binutils/2011-06/threads.html#00218) + ([continues](http://sourceware.org/ml/binutils/2011-07/threads.html#00033)) + * [GDB thread](http://sourceware.org/ml/gdb-patches/2011-07/msg00088.html) + * [GCC thread](http://gcc.gnu.org/ml/gcc-patches/2011-07/threads.html#00252) diff --git a/topgit.mdwn b/topgit.mdwn new file mode 100644 index 00000000..fb374337 --- /dev/null +++ b/topgit.mdwn @@ -0,0 +1,37 @@ +[[!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 +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="TopGit"]] + +<http://repo.or.cz/w/topgit.git> + + * David Bremner: [*A topgit + testimonial*](http://www.cs.unb.ca/~bremner/blog/posts/topgit_testimonial/), + [*So your topgit patch was merged + upstream*](http://www.cs.unb.ca/~bremner/blog/posts/so_your_topgit_patch_was_merged/), + [more](http://www.cs.unb.ca/~bremner/tags/topgit/). + * Pete Hopkins: [*topgit Means Never Having to Wait for + Reviews*](http://blog.grogmaster.com/2008/12/topgit-means-never-having-to-wait-for.html) + * Christoph Egger: [*Git repository's and + topgit*](http://lists.debian.org/debian-devel-games/2008/11/msg00109.html) + +We're using this for some packages, where we're maintaining long-lived +development branches, for example [[source_repositories/binutils]] or +[[source_repositories/glibc]]. The latter one has usage examples, too. + + +# Running it on GNU/Hurd + +Nothing special to that, technically, *only* that our [[I/O system's (non-) +performance|community/gsoc/project_ideas/disk_io_performance]] will render this +unbearably +slow for anything but simple test cases. So don't try to run it on the [[GCC]] +or [[glibc]] repositories. Talk to [[tschwinge]] about how he's using it on a +GNU/Linux machine and push the resulting trees to GNU/Hurd systems. @@ -1,12 +1,28 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="UNIX"]] + +*UNIX* is a [[kernel]] implementation. + + +# Concepts + + * [[file_descriptor]] + + * [[process]] + + * [[signal]] + + * [[system_call]] + # External @@ -15,3 +31,50 @@ is included in the section entitled * [*Standardizing UNIX*](http://www.informit.com/articles/printerfriendly.aspx?p=691503), an article by David Chisnall. + + * The first in the series, {{$2010_brown_ghosts_1}} introduces the concepts + of [[file_descriptor]]s and the single, hierarchical [[namespace]]. + + Next, {{$2010_brown_ghosts_2}} discusses issues with *conflated designs* + such as the `mount` command (a problem we have partly solved / solved + differently with our [[hurd/translator]] approach and the + [[hurd/virtual_file_system]]), and the plethora of flags that can be passed + to the `open` [[system_call]]. + + In {{$2010_brown_ghosts_3}}, he deals with *unfixable designs*, such as + UNIX [[signal]]s and the *UNIX permission model* (which is + clearly inferior to a [[capability]]-based system). + + * [*UNIX File Permissions*](http://www.greenend.org.uk/rjk/2004/perms.html) + (2004) by Richard Kettlewell. ([[!taglink open_issue_documentation]]<!-- + TODO: split out UNIX permission stuff into unix/file_permissions or + something. -->) + + +[[!ymlfront data=""" + +djb_self-pipe: + + D. J. Bernstein's [*self-pipe trick*](http://cr.yp.to/docs/selfpipe.html) + +rjk_fork: + + Richard Kettlewell's suggestions about [*how fork(2) ought to + be*](http://www.greenend.org.uk/rjk/fork.html) + +2010_brown_ghosts_1: + + "Neil Brown's 2010-10-27 article [*Ghosts of Unix Past: a historical search + for design patterns*](http://lwn.net/Articles/411845/)" + +2010_brown_ghosts_2: + + "Neil Brown's 2010-11-04 article [*Ghosts of Unix past, part 2: Conflated + designs*](http://lwn.net/Articles/412131/)" + +2010_brown_ghosts_3: + + "Neil Brown's 2010-11-16 article [*Ghosts of Unix past, part 3: Unfixable + designs*](http://lwn.net/Articles/414618/)" + +"""]] diff --git a/unix/file_descriptor.mdwn b/unix/file_descriptor.mdwn new file mode 100644 index 00000000..b40db67f --- /dev/null +++ b/unix/file_descriptor.mdwn @@ -0,0 +1,18 @@ +[[!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 +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]]."]]"""]] + +A *file descriptor* is a [[concept]] of [[UNIX]], and represents a +non-[[persistent|persistency]] handle to an object (a file, for example). With +respect to specific aspects, it is comparable to a [[capability]]. +This is detailed in {{$capability#wikipedia_capability-based_security}}. + +In a GNU Hurd system, the concept of file descriptors is based on object +handles (through [[Mach ports|microkernel/mach/port]]), and is [[implemented in +glibc|glibc/file_descriptor]]. diff --git a/unix/process.mdwn b/unix/process.mdwn new file mode 100644 index 00000000..21fbfc69 --- /dev/null +++ b/unix/process.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +A *UNIX process* is TODO. + +Generally, especially in [[microkernel]]-based systems, the [[kernel]]'s idea +of a task is not as encompassing as a UNIX process, and will use additional +effort to enhance the kernel's primitive to a full-fledged UNIX model. + +A [[Mach task|microkernel/mach/task]] implements a part of a UNIX process. + +In the GNU/Hurd, processes are based on [[Mach task|microkernel/mach/task]]s, +but are [[enhanced by the glibc|glibc/process]]. diff --git a/unix/signal.mdwn b/unix/signal.mdwn new file mode 100644 index 00000000..084f7f2a --- /dev/null +++ b/unix/signal.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +*[[UNIX]] signals* are a means to asynchronously invoke a specific function +(*signal handler*) in a [[process]]. It's a rather limited form of doing +[[IPC]]. + +Signalling may impact on [[system call]]s that are executing at the same time +in that they may be completely aborted, return incomplete results, scheduled +for restarting, or cause signal delivery to be blocked upon the system call's +completion. + +An explanation can be found in the relevant standards, an overview, including +UNIX signals' deficiencies is given in {{$unix#2010_brown_ghosts_3}}, for +example. + +In a GNU/Hurd system, the signalling system is [[implemented in +glibc|glibc/signal]]. + + +# Further Reading + + * [[!wikipedia Signal_(computing)]] + + * {{$unix#djb_self-pipe}}. + + * {{$unix#rjk_fork}}. diff --git a/unsorted/BochsFAQ.mdwn b/unsorted/BochsFAQ.mdwn index d446f695..474bbed5 100644 --- a/unsorted/BochsFAQ.mdwn +++ b/unsorted/BochsFAQ.mdwn @@ -1,7 +1,5 @@ # <a name="GNU_pre0_3_J2_for_Bochs_mini_FAQ"> </a> GNU pre0.3-J2 for Bochs mini-FAQ -%TOC% - ---- ## <a name="What_do_you_mean_GNU_the_GNU_Hur"> </a> What do you mean "GNU", the GNU Hurd? diff --git a/unsorted/BuildingOskitMach.mdwn b/unsorted/BuildingOskitMach.mdwn index 334b0669..9eee80d3 100644 --- a/unsorted/BuildingOskitMach.mdwn +++ b/unsorted/BuildingOskitMach.mdwn @@ -1,13 +1,6 @@ ## <a name="HowTo_Build_OSKit_Mach"> </a> HowTo Build OSKit-Mach -<table align="center" width="75%"> - <tr> - <td width="50%"> %TOC% </td> - <td width="50%"> - <p><nop></nop></p> <h3><a name="Introduction"> Introduction </a></h3> This is a brief "<nop>HowTO build OSKit-Mach" (a.k.a GNUmach 2.0). It covers everything from getting the latest sources of both the <a href="http://www.cs.utah.edu/flux/oskit/" target="_top">OSKit</a> and the GNUmach kernel, down to building and debugging them. <p> To be able to actually make use of your recently checked out CVS version of the GNUMach kernel &amp; c:o you need a GNU system of <a href="ftp://ftp.funet.fi/pub/gnu/alpha/gnu/hurd/contrib/marcus/gnu-20020816.tar.gz" target="_top">gnu-20020816.tar.gz</a> or later. See [[Distrib/TarballNotesHome]] for more info. </p></nop></td> - </tr> -</table> ## <a name="Getting_your_hands_on_the_source"> Getting your hands on the source </a> diff --git a/unsorted/DebianX.mdwn b/unsorted/DebianX.mdwn index 00692ca8..6d65a140 100644 --- a/unsorted/DebianX.mdwn +++ b/unsorted/DebianX.mdwn @@ -1,9 +1,5 @@ # <a name="Setting_up_X_on_Debian_GNU_Hurd"> </a> Setting up X on Debian GNU/Hurd -#### <a name="Table_Of_Contents"> Table Of Contents </a> - -%TOC% - This is a brief helper on how to setup X-Windows on Debian GNU/Hurd. Obviously this text is taken from the page <http://hurd.gnufans.org/bin/view/Hurd/Xfree86> but I was making such drastic changes, I didn't want to hack up that page. @@ -88,16 +84,6 @@ You may also enable the Emulate3Buttons option, but nothing else will work. **_WARNING:_** I cannot verify as of yet whether it was the "Emulate3Buttons" setting or the "ZAxisMapping" setting but I had to disable both in order to be able to move and resize windows. -### <a name="Dynamic_Linking"> Dynamic Linking </a> - -The Hurd does not use `ld.so.conf`, it is necessary to add the following to `/etc/profile` to be sure that the libraries are found: - - LD_LIBRARY_PATH=/X11R6/lib:$LD_LIBRARY_PATH - -"This is a linker issue. GNU/Hurd expects that \`RPATH' is used, however, Debian takes certain measures to avoid this. Note that this does not cut it for suid binaries because of security implications. We expect to rectify this by using \`RUNPATH', which is specified in the new ELF standard." -- [Why does X not work?](http://www.gnu.org/software/hurd/faq.en.html#q4-8) - -**_CAVEAT 12/28/2004:_** I did not have to do this so can someone verify that this still needs to be done or was it fixed? Thanks! - ### <a name="Starting_X"> Starting X </a> Finally, run `startx` diff --git a/unsorted/DebianXorg.mdwn b/unsorted/DebianXorg.mdwn index 1599c689..a1d77903 100644 --- a/unsorted/DebianXorg.mdwn +++ b/unsorted/DebianXorg.mdwn @@ -1,9 +1,5 @@ # <a name="Setting_up_Xorg_on_Debian_GNU_Hu"> </a> Setting up Xorg on Debian GNU/Hurd -#### <a name="Table_Of_Contents"> Table Of Contents </a> - -%TOC% - This is a brief helper on how to setup Xorg on Debian GNU/Hurd. Obviously this text is taken from the page <http://hurd.gnufans.org/bin/view/Hurd/DebianX> but I was making such drastic changes, I didn't want to hack up that page. 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 diff --git a/unsorted/HurdOnL4.mdwn b/unsorted/HurdOnL4.mdwn deleted file mode 100644 index 79e7a714..00000000 --- a/unsorted/HurdOnL4.mdwn +++ /dev/null @@ -1,173 +0,0 @@ -# <a name="GNU_Hurd_on_L4_wiki"> GNU/Hurd on L4 wiki </a> - -## <a name="Introduction"> Introduction </a> - -This page is a place for information pertaining to the efforts towards realizing the migration and porting of the [[Hurd]] such that it uses the [L4 Microkernel](http://l4ka.org/). The GNU/Hurd Operating System, sometimes just referred to as the _GNU Operating System_ is a rich and robust collection of programs and utilities which enable you to use your computer to do usefull and or entertaining things. The intent is that most any applicable software package available on the [GNU Website](http://www.gnu.org) (and many others also) will be able to be compiled and run under the resultant operating system. - -At this point (06/20/2004) this is not yet possible. Indeed, the preliminary foundations are still being developed. Nevertheless, this is a volunteer created operating system so those with the knowledge, interest, and spare time are encouraged to study and if possible contribute to the project. - -In [CVS module <samp>hurd-l4</samp>](http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd-l4/), there is a [comprehensive list of items that need to be done](http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd-l4/TODO). - -## <a name="Components_of_the_System"> Components of the System </a> - -### <a name="The_L4_Microkernel"> The L4 Microkernel </a> - -The kernel of an operating system is a fundamental program which provides essential resources from the hardware of the computer to other programs. A kernel typically runs all the time and remains resident in main memory. The amount of functionality and resources which it provides vary tremendously. The [L4 Microkernel](http://l4ka.org/) is an attempt to create a very small high performace core which provides basic memory management, task and context switching, and little else. - -### <a name="The_Hurd"> The Hurd </a> - -The [Hurd](http://www.gnu.org/software/hurd/hurd.html) is a conglomeration of servers and programs which add additional functionality to a microkernel such that it is capable of utilizing additional hardware resources of the computer. It also provides a compatibility layer such that compiling higher level programs is essentially transparent; i.e. when you write a C program and compile it, you need only include standard headers and libraries and for all intents and purposes your generic program will build and run and you need never resort to unportable coding or access to hardware specific methods. - -For a typical user, The Hurd is intended to silently work in the background providing the services and infrastructure which are lacking in the microkernel but are required for higher level programs and libraries to operate. - -### <a name="GNU_Programs"> GNU Programs </a> - -For the user, this is what is desired: to run [GNU Software](http://www.gnu.org/). These programs provide a full featured, robust, and extremely effective operating system. A L4/Hurd system should be capable of compiling and executing most any software package available from GNU with little or no modification. - -Some readers may be familiar with GNU/Linux systems. When GNU/L4 is complete it should highly resemble the functionality of such systems as L4 and Hurd effectively replace the Linux kernel. The bulk of the software should be expected to run much as it does presently under the Linux kernel (or gnumach based GNU/Hurd systems). - -## <a name="Preparations"> Preparations </a> - -### <a name="Build_System"> Build System </a> - -There are no precompiled binaries for Hurd on L4 that I am aware of, so you will need to be able to compile the source code packages in order to experiment with it. While L4Ka will likely build on a variety of compilers and systems, the Hurd may prove troublesome unless it is built using recent GNU compilers and tools. - -I recently used [Debian Unstable](http://www.debian.org) (Sarge) with GNU gcc version 3.3, autoconf version 2.50, and automake version 1.8 to build the system with good results, although other similarly equipped systems with a good development environment, such as [Gentoo](http://www.gentoo.org) or [Slackware](http://www.slackware.com) are reported to work fine also. - -Generally, I would recommend building the packages using any very up-to-date GNU development system. I'm not going to say that you can't compile them using more exotic platforms, but I wouldn't be overly hopefull about it. I have no idea if Pistachio can be compiled under current gnuMach/Hurd systems it might be interesting to try it. - -### <a name="Making_a_Home_for_L4_Hurd"> Making a Home for L4/Hurd </a> - -Obviously you want to have a home for this little embryonic operating system. Currently, mine is using about 5M for the binaries and headers. If you want the source to reside with the binaries, then allow perhaps another 50M or so, but this is purely optional. - -At the moment, Hurd on L4 can't even see your hard drive, so all you need is a directory on some partition which is visible to the GRUB bootloader. A `/l4hurd` directory on your existing GNU/Linux system is probably fine for now. - -Howevever, if you have some spare disk space or an unused partition, you could optionally create a small partition for the system. This is totally unnecessary at the moment because L4/Hurd lacks hard disk drivers right now, but it is an option. Assuming that you have made some partition **X** with linux _fdisk_, set it to type 83 - Linux and use the following command to initialize it with the classic Hurd extensions: - - - -As noted, this is purely optional, in fact right now you can use any filesystem that GRUB can understand. You can even use TFTP to netboot the system. My current setup takes about 5M for the full install so obviously you don't need much space for this. - -### <a name="Boot_Loader"> Boot Loader </a> - -Just like regular GNU/Hurd, you need to use [GNU GRUB](http://www.gnu.org/software/grub/), the _GRand Unified Bootloader_ in order to boot the system. Hopefully you already have it installed, in which case adding the commands for L4/Hurd to your `menu.lst` is quite trivial. - -If you don't have GRUB installed, then you should probably take some time to get it set up. A good place to look for help is on the regular [Debian GNU/Hurd Installation Page](http://www.debian.org/ports/hurd/hurd-install) at the **3\. The Boot Loader** section. - -This is probably a bit superfluous, but you can even display a snazzy little graphic of some type on your GRUB boot menu. Here's a snip from the header of my `menu.lst` which demonstrates how to do this. - - # menu for grub - splashimage (hd0,0)/boot/grub/debian.xpm - foreground bfbfe7 - background 3f3f7f - -In the above example, my `debian.xpm` is just a 640x480 graphic in xpm format (which you can easily create with GIMP). It does add a bit of pizazz to your boot screen :-) - -In fact, I will attach a sample copy of my `menu.lst` here. It has lots of examples for booting a variety of operating systems in it. Remember that my hard drive partitions are unique to my system. - -* [[ATTACHURLmenulst]]: Sample GRUB boot menu - -## <a name="Building_Hurd_on_L4"> Building Hurd on L4 </a> - -### <a name="L4Ka_Pistachio"> L4Ka Pistachio </a> - -#### <a name="Getting_the_Sources"> Getting the Sources </a> - -I used the latest version of L4Ka, Pistachio version 0.4. It can be obtained from the following website: - -[L4Ka Pistachio Home](http://l4ka.org/projects/pistachio/) - -#### <a name="Compiling"> Compiling </a> - -Pistachio is designed to be compiled in a build directory which is independant from the source directory, so you need to create your build directory after unpacking the tarball. Furthermore, you need to pass a couple of special parameters to the configure program to set it up for use with Hurd. Here is what I did on my ia32 system: - -Note: I have my installation set up in `/l4hurd` and I am starting from within the Pistachio source top-level directory. - - $ mkdir build - $ cd build - Building and installing user-level libraries and servers/applications - $ ../user/configure --with-s0-linkbase=0x40000 --prefix=/l4hurd - $ make - $ make install - Building and installing the kernel - $ make -C ../kernel BUILDDIR=`pwd`/kernel - $ cd kernel - $ make menuconfig - $ make - $ mkdir /l4hurd/boot - $ cp ia32-kernel /l4hurd/boot - -Hopefully everything worked and there were no problems. As usual, if the build fails then scrutinize the output from `configure` and install any missing libraries or development packages. - -### <a name="CVS_l4hurd"> CVS l4hurd </a> - -#### <a name="Getting_the_sources"> Getting the sources </a> - - You need to pull the L4 Hurd sources from the CVS tree on Savannah. The CVS access page is [The GNU/Hurd - CVS (module hurd-l4)](http://savannah.gnu.org/cvs/?group=hurd). In a nutshell, the following commands should retrieve the sources for you: - - $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co hurd-l4 - -#### <a name="Compiling"> Compiling </a> - -Take a look at the README, compiling should be quite simple on any state of the art GNU development system. As per the README, and for my example, you would: - - $ autoreconf -f -i -s - $ ./configure --enable-maintainer-mode --prefix=/l4hurd - $ make - $ make install - $ strip physmem/physmem - - $ mkdir /l4hurd/boot - $ cp laden/laden /l4hurd/boot - $ cp wortel/wortel /l4hurd/boot - $ cp physmem/physmem /l4hurd/boot - -Currently (2004/08/09), physmem needs to be stripped to to avoid a memory conflict with wortel; this requirement may be fixed in the future. - -In my case it was slightly more complicated as Debian uses a wrapper system to enable the use of multiple versions of the GNU Autotools. In this case, the trick is to utilize some environment variables on the command line as follows: - - $ ACLOCAL=aclocal-1.8 AUTOMAKE=automake-1.8 autoreconf -f -i -s - -As above, hopefully this will compile cleanly; otherwise, scroll up, read any error messages, and correct them by installing required packages of the proper version. Any bad compilation problems are most likely due to you either missing or using a wrong version of something. - -## <a name="Installing"> Installing </a> - -The binaries are now installed into `/l4hurd`. All that remains is to add an entry into GRUB's `menu.lst` in order to test it out. Here's an example from my system where I have `/l4hurd` on `/dev/hda9` in my Linux system: - - title GNU Hurd on L4Ka Pistachio 0.4 - root (hd0,8) - kernel /boot/laden -D - module /boot/ia32-kernel - module /libexec/l4/sigma0 - module /boot/wortel -D - module /boot/physmem -D - module /boot/physmem - module /boot/physmem - module /boot/physmem - module /boot/physmem - -It might strike you a little odd that there are five physmem modules. This is done because wortel currently (2004/08/09) expects exactly five modules and the other modules (like the task server, auth server, etc.) have not been implemented yet. Therefore the physmem module is used as a dummy module. - -## <a name="Booting"> Booting </a> - -For me at least, I got some nifty messages and then it dropped into a simple debugging mode. As far as I know, thats all there is right now. - -Read, build, learn, code... - ---todo: add more here. - -## <a name="Experimenting"> Experimenting </a> - -Well, thats why you did all of this, certainly not to do anything else. Use that debugger and get experimenting. - ---todo: things to do wth the debugger - -## <a name="Conclusion"> Conclusion </a> - -If you followed these steps, you most likely have built and booted the latest version of Hurd on L4. I would encourage you to subscribe to the mailing list at the following URL and help in the efforts to get this nifty system up to speed: - -[l4-hurd mailing list](http://lists.gnu.org/mailman/listinfo/l4-hurd) - -And finally, this is a wiki, meaning that **you** have the ability to edit and modify this page. If you want to fix something, add more information, new sub-pages, whatever, feel free to do so. This is a great way to get a doc base up fast and keep it current, so use it like its supposed to be and have fun with Hurd on L4! - --- [[Main/BDouglasHilton]] - 20 Jun 2004 diff --git a/unsorted/HurdOnL4/menu.lst b/unsorted/HurdOnL4/menu.lst deleted file mode 100644 index 3129ea74..00000000 --- a/unsorted/HurdOnL4/menu.lst +++ /dev/null @@ -1,55 +0,0 @@ -# menu for grub
-splashimage (hd0,0)/boot/grub/debian.xpm
-foreground bfbfe7
-background 3f3f7f
- -timeout 30
-default 0 -
-title Debian Sid with Linux kernel 2.6.5
-root (hd0,1)
-kernel /vmlinuz root=/dev/hda2 vga=0x318
-
-title Debian Sid with old kernel
-root (hd0,1)
-kernel /vmlinuz.old root=/dev/hda2 vga=9
-
-title Microsoft Windows 2000
-rootnoverify (hd0,3)
-chainloader (hd0,3)+1
-
-title FreeDOS BETA 8.0
-root (hd0,0)
-chainloader +1
-
-title GNU Hurd on L4Ka Pistachio 0.4
-root (hd0,8)
-kernel /boot/laden -D
-module /boot/ia32-kernel
-module /libexec/l4/sigma0
-module /boot/wortel -D
-module /boot/physmem
-
-title Debian GNU/Hurd (gnumach)
-root (hd0,7)
-kernel /boot/kernel.gz root=device:hd0s8
-module /hurd/ext2fs.static --readonly \
- --multiboot-command-line=${kernel-command-line} \
- --host-priv-port=${host-port} \
- --device-master-port=${device-port} \
- --exec-server-task=${exec-task} \
- -T typed ${root} $(task-create) $(task-resume)
-module /lib/ld.so.1 /hurd/exec $(exec-task=task-create)
-
-# title Debian GNU/Hurd (oskit-mach)
-# root (hd3,0)
-# kernel /boot/kernel-ide -- root=hd0s1
-# module /hurd/ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T device ${root-device} $(task-create) $(task-resume)
-# module /lib/ld.so.1 /hurd/exec $(exec-task=task-create)
-
-# title Debian GNU/Hurd (oskit-mach w/ remote debugging)
-# root (hd3,0)
-# kernel /boot/kernel-ide -d GDB_COM=1 BAUD=9600 -- root=hd0s1
-# module /hurd/ext2fs.static --multiboot-command-line=${kernel-command-line} --host-priv-port=${host-port} --device-master-port=${device-port} --exec-server-task=${exec-task} -T device ${root-device} $(task-create) $(task-resume)
-# module /lib/ld.so.1 /hurd/exec $(exec-task=task-create)
-
diff --git a/unsorted/InstallNotes.mdwn b/unsorted/InstallNotes.mdwn index 1cdfca9c..f3ac58d1 100644 --- a/unsorted/InstallNotes.mdwn +++ b/unsorted/InstallNotes.mdwn @@ -2,10 +2,6 @@ Items of interest during install not mentioned elsewhere include the following. **_Currently, [Debian's installation instructions](http://www.debian.org/ports/hurd/hurd-install) are the most up-to-date._**<br /> Note the mirrors mentioned on debian.org have no hurd iso's. The iso's can be found [Here](http://ftp.gnuab.org/pub/gnu.iso) -## <a name="Table_of_Contents"> Table of Contents </a> - -%TOC% - ## <a name="1_Overview_Where_we_are_going"> 1. Overview - Where we are going </a> There are currently four methods to install GNU @@ -198,7 +194,6 @@ See [[DebianAfterInstall]] for complete, up to date instructions. * Run `passwd` to give the root user a password. By default, root does not have one. * Run `adduser` to give yourself a user account. _Do not_ use root indiscriminately. * Run `MAKEDEV` to create devices in `/dev` for your hard disk and other required devices. - * Since the Hurd does not use `ld.so.conf`, you will want to specify where the X Window System keeps its libraries. Do this by adding the following line to your `/etc/profile`: <br />`export LD_LIBRARY_PATH='/lib:/usr/X11R6/lib'` * run `/etc/cron.daily/find` to allow `locate` to function. * [[GetNetworkRunning]] diff --git a/unsorted/InstallTips.mdwn b/unsorted/InstallTips.mdwn index c9f5bdc2..262ec741 100644 --- a/unsorted/InstallTips.mdwn +++ b/unsorted/InstallTips.mdwn @@ -1,9 +1,5 @@ Before reading these instructions, be sure you are familiar with the [[InstallNotes]]. -## <a name="Table_of_Contents"> Table of Contents </a> - -%TOC% - ## <a name="1_Setting_up_the_filesystems"> 1. Setting up the filesystems </a> You will need to boot a linux capable of internet access and creating/mounting ext2 partitions. I recommend [tomsrtbt](http://www.toms.net/rb/) linux which fits nicely onto a floppy and although a bit old will work well. diff --git a/unsorted/JoachimNilssonHurdPage.mdwn b/unsorted/JoachimNilssonHurdPage.mdwn index e4dde2b9..163d6845 100644 --- a/unsorted/JoachimNilssonHurdPage.mdwn +++ b/unsorted/JoachimNilssonHurdPage.mdwn @@ -1,15 +1,3 @@ -<table width="100%"> - <tr> - <td> - </td> - <td align="right"><a href="http://hurd.gnufans.orghttp://LOCATIONHurd/JoachimNilssonHurdPage" target="_top">Edit this page</a></td> - </tr> - <tr> - <td align="right"> %ATTACHURL%/patch_kit.jpg </td> - <td align="left"><nop><h2><a name="Table_of_Contents"> Table of Contents </a></h2> %TOC% </nop></td> - </tr> -</table> - ## <a name="Introduction"> Introduction </a> This page serves as a simple project page for me. I use it to list my personal Hurd related projects, currently only OSKit related. If you wish to comment on my work, do so in [[TWiki/GoodStyle]], preferably at the bottom of this page. diff --git a/unsorted/KnownHurdLimits.mdwn b/unsorted/KnownHurdLimits.mdwn index 51d66b50..4e7b7620 100644 --- a/unsorted/KnownHurdLimits.mdwn +++ b/unsorted/KnownHurdLimits.mdwn @@ -9,10 +9,6 @@ There are needed by OpenSSH. * In progress, see [[translator/random]] -* No DHCP client - * promising information [Jan 2005](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html), needs an update - * See [[DhcpClient]] - need to update TCP/IP server. - * Missing bits of POSIX * See [[Distrib/SystemAPILimits]] diff --git a/unsorted/MakeImage.mdwn b/unsorted/MakeImage.mdwn index 95b928c4..ff64ce46 100644 --- a/unsorted/MakeImage.mdwn +++ b/unsorted/MakeImage.mdwn @@ -53,7 +53,7 @@ I use this for testing OSKit... ## <a name="Booting_Qemu"> Booting Qemu </a> - qemu -user-net -isa -boot d -cdrom grub.iso -hda gnu.img + qemu -m 512 -user-net -isa -boot d -cdrom grub.iso -drive cache=writeback,index=0,media=disk,file=gnu.img The switch `-isa` is for current gnumach.gz on hda. diff --git a/unsorted/OskitPatches.mdwn b/unsorted/OskitPatches.mdwn index d189bb6d..b0cb646a 100644 --- a/unsorted/OskitPatches.mdwn +++ b/unsorted/OskitPatches.mdwn @@ -1,7 +1,3 @@ -## <a name="Table_of_Contents"> Table of Contents </a> - -%TOC% - ## <a name="Flux_OS_Toolkit"> Flux OS Toolkit </a> [The OSKit](http://www.cs.utah.edu/flux/oskit/) is a framework and a set of libraries for building and extending operating systems developed by [the Flux Project](http://www.cs.utah.edu/flux/). diff --git a/unsorted/PortToL4.mdwn b/unsorted/PortToL4.mdwn deleted file mode 100644 index fb7f0004..00000000 --- a/unsorted/PortToL4.mdwn +++ /dev/null @@ -1,42 +0,0 @@ -**_The Hurd-L4 port has an [official page](http://www.gnu.org/software/hurd/hurd-l4.html) with more up-to-date information_** -- [[Main/OgnyanKulev]] - 05 Feb 2005 - -A group of one being led by Neal H. Walfield is working on porting the Hurd to the pistachio version of the L4 microkernel. This second generation microkernel provides a significantly different API than the one offered by the Mach microkernel, a first generation microkernel. One of the primary goals of the project, outside of porting the Hurd to L4, is to reevaluate the current Hurd abstractions and consider how they can be modified to be more general. - -I have no web page describing my efforts. There is a mailing list[1]. - -[1] <http://mail.gnu.org/mailman/listinfo/l4-hurd> - --- Neal Walfield, 18 Sep 2002 - -Neal noted [1] that there are licensing issues being worked out so no code is yet released. His work was performed in the summer of 2002 at Karlsruhe. - -[1] <http://mail.gnu.org/pipermail/l4-hurd/2002-September/000673.html> - --- [[Main/GrantBow]] - 21 Sep 2002 - -There are several important pages that are of interest for the L4 & hurd communities. - -* Main L4 home page - <http://www.l4ka.org/> -* Hurd on L4 - <http://www.freesoftware.fsf.org/l4hurd/> -* Hurd on L4 - <http://savannah.gnu.org/projects/l4hurd/> -* <http://www.informatik.uni-freiburg.de/~ganter/comp/l4-hurd.html> - --- [[Main/GrantBow]] - 22 May 2002 - -<http://os.inf.tu-dresden.de/fiasco/> - --- [[Main/GrantBow]] - 24 Oct 2002 - -There was [discussion in October 2002](http://mail.gnu.org/pipermail/l4-hurd/2002-October/000727.html) about the differences between Hurd on Mach and Hurd on L4 with some interesting URLs. In the thread Okuji [responds](http://mail.gnu.org/pipermail/l4-hurd/2002-October/000728.html) confirming his document is two years old and outdated by the directions that Neal is taking in furthering this effort. The URLs in that email might be helpful to those learning more about Hurd and L4 ideas that were considered yet abandoned. - --- [[Main/GrantBow]] - 04 Jan 2003 - -A "Porting GNU Hurd to L4" website: - -* <http://www.gnu.org/software/hurd/l4-hurd.html> - --- [[Main/SebastianGabriel]] - 29 Sep 2003 - -The only valid L4-Hurd link on <http://hurd.gnu.org> is <http://www.freesoftware.fsf.org/l4hurd/> - --- [[Main/JoachimNilsson]] - 29 Sep 2003 diff --git a/unsorted/RemoteDebugOskitMach.mdwn b/unsorted/RemoteDebugOskitMach.mdwn index c260ce25..bb5b9006 100644 --- a/unsorted/RemoteDebugOskitMach.mdwn +++ b/unsorted/RemoteDebugOskitMach.mdwn @@ -1,9 +1,5 @@ # <a name="Remote_Debug_GNUmach"> </a> Remote Debug GNUmach -# <a name="Table_of_Contents"> Table of Contents </a> - -%TOC% - # <a name="Booting_oskit_mach_with_a_serial"> Booting oskit-mach with a serial console </a> **Original Author:** Igor Khavkine **Last Updated:** Mon Jul 30 17:58:55 EDT 2001 diff --git a/unsorted/SeenHurd.mdwn b/unsorted/SeenHurd.mdwn index 8e883d5f..92be4224 100644 --- a/unsorted/SeenHurd.mdwn +++ b/unsorted/SeenHurd.mdwn @@ -1,9 +1,5 @@ # <a name="Hurd_Sightings"> Hurd Sightings </a> -#### <a name="Table_Of_Contents"> Table Of Contents </a> - -%TOC% - ## <a name="Hurd_People_Sightings"> Hurd People Sightings </a> <dl> diff --git a/unsorted/Xfree86.mdwn b/unsorted/Xfree86.mdwn index 617508e5..6fffff81 100644 --- a/unsorted/Xfree86.mdwn +++ b/unsorted/Xfree86.mdwn @@ -1,9 +1,5 @@ # <a name="Setup_XFree86_in_GNU"> </a> Setup XFree86 in GNU -#### <a name="Table_Of_Content"> Table Of Content </a> - -%TOC% - This is a brief helper on how to setup X-Window on GNU. ### <a name="Mouse_amp_Keyboard"> Mouse & Keyboard </a> @@ -70,14 +66,6 @@ You may also enable the Emulate3Buttons option, but nothing else will work. Option "Emulate3Buttons" "true" -### <a name="Dynamic_Linking"> Dynamic Linking </a> - -The Hurd does not use `ld.so.conf`, it is necessary to add the following to `/etc/profile` to be sure that the libraries are found: - - LD_LIBRARY_PATH=/X11R6/lib:$LD_LIBRARY_PATH - -"This is a linker issue. GNU/Hurd expects that \`RPATH' is used, however, Debian takes certain measures to avoid this. Note that this does not cut it for suid binaries because of security implications. We expect to rectify this by using \`RUNPATH', which is specified in the new ELF standard." -- [Why does X not work?](http://www.gnu.org/software/hurd/faq.en.html#q4-8) - ### <a name="Starting_X"> Starting X </a> Finally, run diff --git a/user.mdwn b/user.mdwn new file mode 100644 index 00000000..9c965af2 --- /dev/null +++ b/user.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="User Pages"]] + +[[!inline +pages=none +show=-1 +feeds=no +actions=yes +rootpage="user" postformtext="Add a new user page titled:"]] + +[[!map pages="user/* and !user/*/*" +show=title]] diff --git a/user/El_Dream_Machine.mdwn b/user/El_Dream_Machine.mdwn new file mode 100644 index 00000000..c4855428 --- /dev/null +++ b/user/El_Dream_Machine.mdwn @@ -0,0 +1,46 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +**March 29, 2012** - Last month, I finished the third page (in french for instance). Questions about the internet are beginning to arise in this comic... [http://art9libre.tuxfamily.org/gaetan-03.php](http://art9libre.tuxfamily.org/gaetan-03.php) + +**September 19, 2011** - Two pages of available comics about the Hurd [http://art9libre.tuxfamily.org/gaetan-01-en.php](http://art9libre.tuxfamily.org/gaetan-01-en.php) http://art9libre.tuxfamily.org/gaetan-01-en.php + +**September 9, 2011** - The second page is done ! For instance, it's in french. English version soon as it's possible... Follow this link [http://art9libre.tuxfamily.org/gaetan-02.php](http://art9libre.tuxfamily.org/gaetan-02.php)or have a look on the last message. + +**May 19, 2011** - Very difficult to do my comic on the Hurd I encountered problems of inspiration... I missed the second page but I started again [http://art9libre.tuxfamily.org/gaetan-02.php](http://art9libre.tuxfamily.org/gaetan-02.php) +I project to share the scenario (CC-BY-SA/Licence Art Libre). + +**January 13, 2011** - My story comics on the Hurd continues. I think I can introduce you to page 2 in a month. + +**January 11, 2011** - The goal was to install the Hurd in VirtualBox... +It happened on january,7 2011, a very nice day... Thanks to [http://www.paranoiaque.fr](http://www.paranoiaque.fr) for [the *Hurd.vdi* machine.](http://www.paranoiaque.fr/Hurd.vdi.tar.lzma) + +[A testimony](http://www.sites.google.com/site/hurdexperiences/en-hurd-vdi-tar-lzma) of this install and a video capture [Hurd operating.](http://www.dailymotion.com/video/xgl3nr_hurd-screenscat-ffmpeg-01_webcam) + +**October 14, 2010** - Here's the [french version.](http://art9libre.tuxfamily.org/gaetan-01.php) + +**October 13, 2010** - Page 1 out ! The beginning of the [the comics is here :](http://art9libre.tuxfamily.org/gaetan-01-en.php) +Hope it will pleased for you. + +**October 3, 2010** - I just try to become an end user of The Hurd. In 2004, I was able to install K9 on an old computer. +These times, my goal is to install it on my laptop (maybe with crosshurd or with a lzma image for virtualbox, or any other way...) + +Also, I'm currently working on a comics'The Call Of The Hurd'. It's free licensed cc-by-sa/Copyleft Art Libre. +1st page will be done before the end of the year I think (I look for good quality). + + + + + + + + + + diff --git a/user/El_Dream_Machine/discussion.mdwn b/user/El_Dream_Machine/discussion.mdwn new file mode 100644 index 00000000..e4ae858b --- /dev/null +++ b/user/El_Dream_Machine/discussion.mdwn @@ -0,0 +1,10 @@ +[[!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]]."]]"""]] +J'espère avoir l'énergie de constituer un scénario modifiable sur un wiki par exemple... diff --git a/user/Erkan-Yilmaz.mdwn b/user/Erkan-Yilmaz.mdwn new file mode 100644 index 00000000..aea4e7ff --- /dev/null +++ b/user/Erkan-Yilmaz.mdwn @@ -0,0 +1 @@ +see <http://wiki.archhurd.org/wiki/User:Erkan_Yilmaz> diff --git a/user/Etenil.mdwn b/user/Etenil.mdwn new file mode 100644 index 00000000..a1a3373b --- /dev/null +++ b/user/Etenil.mdwn @@ -0,0 +1,40 @@ +[[!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]] + +## Current task + +Implement clustered paging in GNU Mach + +- - - + +## What the problem is +In Mach, memory access is ensured by the VM, an abstraction in the kernel. The VM is mapped by pages, which size is arbitrary and defined based on hardware specs. A single block of memory can then span over many pages, i.e. a file on a file system can represent a lot of pages. + +When a process attempts to access pages that don't reside in the physical memory (RAM), the MMU detects this and triggers a page fault. Page faults are then handled and the kernel calls down the process associated with the memory pages on a *one by one basis*. + +This is where the problem lies. Hard disks are inherently efficient at sequentially writing large chunks of data whereas they cope badly with random access, plus the kernel wastes time writing/reading a page and handling the next page. All of these make for slow I/O in Mach. + +## Solutions +There are a couple of ways I could think of to solve this problem. Pages could be enlarged, but that would cause a lot more problems. Or pages must be handled by groups instead of one by one. This means the changes will also need to be applied in the way user-space processes talk to Mach. + +## What's already been done +[[user/KAM]] has already made a patch that provides basic page clustering. I have yet to understand it completely, but there are troubling changes in the patch, most notably the removal of continuations in *vm_fault* and *vm_fault_page*. + +So far, what I can tell is that KAM seems to have modified the memory objects in Mach so that they handle clusters of pages. + +## What I intend to do +Starting from KAM's work, I'll try and at least proxy the current behaviour in the kernel so as to keep backwards compatibility, at least until all user-space processes are converted (maybe some sort of deprecation warning would help porting). I'll also need to modify ext2fs to make it use the clustered paging feature, hopefully it'll improve performance quite a bit. + +## Problems +As *braunr* and *antrik* pointed out on IRC, I seriously lack knowledge about kernel programming, and this is quite a big task. I also don't fully understand the inner workings of the kernel yet, even though *braunr* helped me a lot to understand the VM and page handling. + +I'll do what I can and keep maintaining this page so others may pickup where I left if I were to give up. diff --git a/user/Maksym_Planeta.mdwn b/user/Maksym_Planeta.mdwn new file mode 100644 index 00000000..fccf3840 --- /dev/null +++ b/user/Maksym_Planeta.mdwn @@ -0,0 +1,340 @@ +[[!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]] +#GSoC 2012 - Disk I/O Performance Tuning + +15.06.12 + +Explored gnumach code. First I was reimplementing vm_fault_page as coroutine that returns before executing of mo_data_{unlock,request} calls to vm_fault. vm_fault had to analyse state of vm_fault_page for every page in loop and make a decision regarding further behavior (call mo_data_*, go to next page, etc.). But than I've got that this way is much worse, than doing everything in vm_fault_page (like in OSF mach), so I made a back-off and started working on clustered paging from the beginning (at least now I see clearer how things should be). At the moment I review kam's patch one more time and looked through mklinux code attentively. + +8.06.12 + +Applied Neal's patch that reworks libpager, changed libdiskfs, tmpfs and ext2fs according to new interface. ext2fs isn't finished yet and should be reworked, but looks like I brought some bug to existing implementation and i want first to fix it and than finish rest of ext2fs. Also I pushed some code changes to hurd git repository into my branch mplaneta/gsoc12/working. Now I start working on gnumach implementation of clustered page reading. After this I'm going to implement madvise, than finish ext2fs and start porting of other translators. + +14.05.12 + +First of all I'm going to do 2 programs. First will work as server, it will create an object and share it with second. Second will try to access to this object. This will cause page fault and kernel will refer to first program (server). This way I will be able to track how page faults are resolved and this will help me in debugging of readahead. IFR: server probably can use some of hurd's libraries, but it has to handle m_o_* RPC's on it's own. TODO: Find out how supply second program (client) with new object. NB: be sure that client will cause page fault, so that server always will be called (probably any caching should be disabled). + +#Notes on tmpfs + +## Current state + +Finished + +26.01.12 + +Infinite fsx on ext2fs: + +Test 1. After about hour of work ext2fs breaks with such message: ext2fs.static: /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./ext2fs/pager.c:399: file_pager_write_page: Assertion 'block' failed. Fsx ended with Resource lost. There is no 'vmstat 1' log. + +Test 2. Left for night. Finally got this message: ext2fs.static: /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./ext2fs/pager.c:399: file_pager_write_page: Assertion 'block' failed. vm_fault: memory_object_data_unlock failed. Fsx ended with Bus error. + +Test 3. Finally got this message: ext2fs.static: /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./ext2fs/pager.c:399: file_pager_write_page: Assertion 'block' failed. memory_object_data_request(0x0, 0x0, 0x38000, 0x1000, 0x3) failed, 10000003. Fsx ended with Bus error. vmstat didn't show any leek. + +The same test for tmpfs: + +Test 1. The test continued about 5 hours and made 18314766 operations. Then this error message appeared: + + READ BAD DATA: offset = 0x3317, size = 0x7012 + OFFSET GOOD BAD RANGE + 0x 8a93 0x80f8 0x82f8 0x 1 + operation# (mod 256) for the bad data may be 248 + LOG DUMP (18314753 total operations): + 18314754(2 mod 256): WRITE 0x38c1a thru 0x3ffff (0x73e6 bytes) + 18314755(3 mod 256): READ 0x92c3 thru 0x181b3 (0xeef1 bytes) + 18314756(4 mod 256): WRITE 0x138c1 thru 0x1a06b (0x67ab bytes) + 18314757(5 mod 256): MAPWRITE 0x2564 thru 0xbc75 (0x9712 bytes) ******WWWW + 18314758(6 mod 256): MAPREAD 0x3f4e8 thru 0x3ffff (0xb18 bytes) + 18314759(7 mod 256): READ 0x2946a thru 0x30213 (0x6daa bytes) + 18314760(8 mod 256): MAPWRITE 0x31fe6 thru 0x3ffff (0xe01a bytes) + 18314761(9 mod 256): TRUNCATE DOWN from 0x40000 to 0x145e8 + 18314762(10 mod 256): MAPWRITE 0xca89 thru 0x1ba74 (0xefec bytes) + 18314763(11 mod 256): MAPWRITE 0xb421 thru 0x11a37 (0x6617 bytes) + 18314764(12 mod 256): READ 0x9495 thru 0xaa45 (0x15b1 bytes) + 18314765(13 mod 256): TRUNCATE DOWN from 0x1ba75 to 0x66cb ******WWWW + 18314766(14 mod 256): READ 0x5fa5 thru 0x66ca (0x726 bytes) + +vmstat has broken after about 2 hours, so no leak has been detected. + +Test 2. fsx worked about 8 hours, than computer hanged. Log for last 2 hours of vmstat's work has been spoiled. So no vmstat information. + +Test 3. fsx made 7904126 and than data error was occurred. It took about 2 hours, no vmstat was running. + +5.01.12 + +UPD 26.01: All these bugs are fixed. + +There left 2 bugs, I found: + +1. Passive translator doesn't work. UPD: Seems I confused something, but now it works: +$ showtrans foo +/usr/bin/env LD_LIBRARY_PATH=/home/mcsim/git/hurd-build/lib tmpfs/tmpfs 10M + +3. Writing by freed address somewhere. As workaround I set kalloc_max in mach-defpager/kalloc.c to 3, so vm_allocate is always used. UPD: Now I use another workaround (see below). + +4. Fsx still breaks. With 11 from 12 seeds, I tested the problem was in first 4 Kb. In 12th case problem was in range between 4 Kb and 8 Kb. I find this quite odd. Usual amount of operations before fsx breaks passes 100 000. UPD: The problem seems to be fixed. + +## mach-defpager + +[[defpager|http://www.bddebian.com:8888/~hurd-web/user/Maksym_Planeta/#defpager81111]] + +[[http://www.mail-archive.com/bug-hurd@gnu.org/msg18859.html]] + +[[My patch that fixes tmpfs and defpager|http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00086.html]] + +My vision of the problem in short: when user tries to access to the memory backed by tmpfs first time, kernel asks defpager to initialize memory object and sets it's request port to some value. But sometimes user directly accesses to defpager and supplies it own request port. So defpager should handle different request port, what causes errors. + +TODO: pager_extend always frees old pagemap and allocates new. Consider if it is necessary. + +## Steps + +### Find out what causes crashes in tmpfs with defpager + +[[http://www.gnu.org/s/hurd/hurd/translator/tmpfs/notes_various.html]] + +TODO: Consider deleting of parameter "port" in function mach-defpager/default_pager.c:pager_port_list_insert +since this parameter is unused + +Probably pager_request shouldn't be stored because request may arrive from different kernels (or from kernel and translator), so this parameter doesn't have any sense. + +22.11.11 Reading/writing for any size works, [[this|http://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00127.html]] works, but fsx test fails ([[see|http://www.bddebian.com:8888/~hurd-web/user/Maksym_Planeta/#fsx_fail2211]]). + +24.11.11 The problem with fsx. + +Here are follow operations: + +1. Write some data at address 0x100 with size 0x20 +2. Truncate file to size 0x80. First written data should be lost. +3. Write some data at address 0x200 size of 0x20. By this operation file size is increased up to 0x220. +4. Read data at address 0x110. Fsx expects here zeros, but in fact here is data, that was written at step 1. + +When fsx tries to read data kernel calls pager with seqno_memory_object_data_request, and pager returns on step 4 zeros either with memory_object_data_provided or memory_object_data_unavailable. Before this, in default_pager_set_size memory_object_lock_request called to flush any kernel caches, that could hold data to be truncated. When I set offset to 0 and size to limit in memory_object_lock_request it appeared another error ([[see|http://www.bddebian.com:8888/~hurd-web/user/Maksym_Planeta/#fsx_fail2411]]). Both these behaviors appear to be quite strange for me. It is quite late now, so i put these notes to not forget this and went sleep. Continue tomorrow. + +5.12.11 Here is a problem with writing by address, which was freed already. It happens in function dealloc_direct in macros invalidate_block. This function is called from pager_truncate in branch when condition "if (!INDIRECT_PAGEMAP(old_size))" is true. But I didn't find why reference to freed object is kept. As workaround we can reduce kalloc_max in hurd/mach-defpager/kalloc.c to 3 to make allocator use vm_allocate always. The drawback is that allocator will allocate only multiple of vm_page_size, but this is temporary tradeoff. Till now fsx reaches operation number 14277. + +6.12.11 fsx works quite long and doesn't interrupt. I've stopped at 124784. Continued. It broke at 181091. + +4.01.12 I've localized the problem. It is in these lines (starting approx. at hurd/mach-defpager/default_pager.c:1177): + + /* Now reduce the size of the direct map itself. We don't bother + with kalloc/kfree if it's not shrinking enough that kalloc.c + would actually use less. */ + if (PAGEMAP_SIZE (new_size) <= PAGEMAP_SIZE (old_size) / 2) + { + const dp_map_t old_mapptr = pager->map; + pager->map = (dp_map_t) kalloc (PAGEMAP_SIZE (new_size)); + memcpy (pager->map, old_mapptr, PAGEMAP_SIZE (old_size)); + my_tag |= 20; + kfree ((char *) old_mapptr, PAGEMAP_SIZE (old_size)); + } + +I didn't find out yet what is wrong here exactly, but when I exclude this code memory spoiling disappears. Still breaks at 181091. + +### Write own pager + + 6.11.11 Reading/writing for files that fit in vm_page_size works + + 7.11.11 Works for any size. + + TODO: During execution tmpfs hangs in random places. The most possible is variant is deadlocks, + because nothing was undertaken for thread safety. + + TODO: Make tmpfs use not more space than it was allowed. + +### Make links work + +Symlinks behavior: [[links|http://www.bddebian.com:8888/~hurd-web/user/Maksym_Planeta/#links81111]] + +8.11.11 Symlinks work. + +[[Patch by Ben Asselstine.|http://thread.gmane.org/gmane.os.hurd.bugs/11829/focus=12098]] + +### After sometime of inactivity tmpfs exits. + + TODO: Find out why and correct this. + +> This may perhaps be the standard translator +> shutdown-after-a-period-of-inactivity functionality? This is of course not +> valid in the tmpfs case, as all its state (file system content) is not stored +> on any non-volatile backend. Can this auto-shutdown functionality be +> disabled (in [[hurd/libdiskfs]], perhaps? See `libdiskfs/init-first.c`, the +> call to `ports_manage_port_operations_multithread`, the `global_timeout` +> paramenter (see the [[hurd/reference_manual]]) (here: `server_timeout`). +> Probably this should be set to `0` in tmpfs to disable timing out? +> --[[tschwinge]] + +### Passive translator doesn't work + +> Must be some bug: `diskfs_set_translator` is implemented in `node.c`, so this +> is supposed to work. --[[tschwinge]] + +#Challenges + +Translators vs FUSE: + +[[What can a translator do that FUSE can't?|http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00061.html]] + +[[Re: Hurd translators on FUSE|http://lists.gnu.org/archive/html/l4-hurd/2009-09/msg00146.html]] + +[[Example of sane utilization of filesystem stored in RAM|http://habrahabr.ru/blogs/gdev/131043/]] (Russian). Author of this article copied some resources of game "World of Tanks" to RAM-drive and game started load much faster. Although he used Windows in this article, this could be good example of benefits, which filesystem, stored in RAM, could give. + +#Debugging + +To debug tmpfs, using libraries from "$PWD"/lib and trace rpc: + + settrans -ca foo /usr/bin/env LD_LIBRARY_PATH="$PWD"/lib utils/rpctrace -I /usr/share/msgids/ tmpfs/tmpfs 1M + LD_LIBRARY_PATH="$PWD"/lib gdb tmpfs/tmpfs `pidof tmpfs` + +For debugging ext2fs: + + settrans --create --active ramdisk0 /hurd/storeio -T copy zero:32M && \ + /sbin/mkfs.ext2 -F -b 4096 ramdisk0 && \ + settrans --active --orphan ramdisk0 /usr/bin/env LD_LIBRARY_PATH="$PWD"/lib utils/rpctrace -I /usr/share/msgids/ \ + ext2fs/ext2fs.static ramdisk0 + +How to install fsx<a id="fsx_install"/>. Get fsx sources using this link: http://codemonkey.org.uk/projects/fsx/fsx-linux.c Than add following line somewhere in code: + + #define msync(...) 0 + +To compile fsx you may use following line: + + gcc fsx-hurd.c -o fsx -Dlinux -g3 -O0 + +#Questions + +1. What are sequence numbers? What are they used for? + +> See [[microkernel/mach/ipc/sequence_numbering]]. --[[tschwinge]] + +2. Is there any way to debug mach-defpager? When I set breakpoint to any function in it, pager never breaks. + +> Is that still an unresolved problem? If not, what was the problem? --[[tschwinge]] + +3. Is it normal that defpager panics and breaks on any wrong data? + +> No server must ever panic (or reach any other invalid state), whichever input +> data it receives from untrusted sources (which may include every possible +> source). All input data must be checked for validity before use; anything +> else is a bug. --[[tschwinge]] + +#Links + +1. [[Cthreads manuals|http://www.cc.gatech.edu/classes/cs6432_99_winter/threads_man/]] + +#Conversations + +## 8.11.11 + +### links<a id="links81111"/> + (10:29:11) braunr: mcsim: ln -s foo/bar foo/baz means the link name is baz in the foo directory, + and its target (relative to its directory) is foo/bar (which would mean /tmp/foo/foo/bar in canonical form) + (10:29:42) braunr: youpi: tschwinge: what did ludovic achieve ? + (10:30:06) tschwinge: mcsim: As Richard says, symlink targets are always relative to the directory they're contained in. + (10:31:26) braunr: oh ok + (10:31:27) mcsim: so, if I want to create link in cd, first I need to cd there? + (10:31:36) mcsim: in foo* + (10:31:36) braunr: mcsim: just provide the right paths + (10:32:11) braunr: $ touch foo/bar + (10:32:14) braunr: $ ln -s bar foo/baz + (10:32:32) braunr: bar + (10:32:35) braunr: baz -> bar + +### defpager<a id="defpager81111"/> + + earlier: + <tschwinge>: 1. On every system there is a ``default pager'' (mach-defpager). That one is responsible + for all ``anonymous memory''. For example, when you do malloc(10 MiB), and then there is memory pressure, + this 10 MiB memory region is backed by the default pager, whose job then is it to provide the backing store for this. + <tschwinge>: This is what commonly would be known as a swap partition. + <tschwinge>: And this is also the way tmpfs works (as I understand it). + <tschwinge>: malloc(10 MiB) can also be mmap(MAP_ANONYMOUS, 10 MIB); that's the same, essentially. + <tschwinge>: Now, for ext2fs or any other disk-based file system, this is different: + <tschwinge>: The ext2fs translator implements its own backing store, namely it accesses the disk for storing + changed file content, or to read in data from disk if a new file is opened. + + ... + + (10:36:14) mcsim: who else uses defpager besides tmpfs and kernel? + (10:36:27) braunr: normally, nothing directly + (10:37:04) mcsim: than why tmpfs should use defpager? + (10:37:22) braunr: it's its backend + (10:37:28) braunr: backign store rather + (10:37:38) braunr: the backing store of most file systems are partitions + (10:37:44) braunr: tmpfs has none, it uses the swap space + (10:39:31) mcsim: if we allocate memory for tmpfs using vm_allocate, will it be able to use swap partition? + (10:39:56) braunr: it should + (10:40:27) braunr: vm_allocate just maps anonymous memory + (10:41:27) braunr: anonymous memory uses swap space as its backing store too + (10:43:47) braunr: but be aware that this part of the vm system is known to have deficiencies + (10:44:14) braunr: which is why all mach based implementations have rewritten their default pager + (10:45:11) mcsim: what kind of deficiencies? + (10:45:16) braunr: bugs + (10:45:39) braunr: and design issues, making anonymous memory fragmentation horrible + + ... + + (15:23:33) antrik: mcsim: vm_allocate doesn't return a memory object; so it can't be passed to clients for mmap() + (15:50:37) mcsim: antrik: I use vm_allocate in pager_read_page + (15:54:43) antrik: mcsim: well, that means that you have to actually implement a pager yourself + (15:56:10) antrik: also, when the kernel asks the pager to write back some pages, it expects the memory to become free. + if you are "paging" to ordinary anonymous memory, this doesn't happen; so I expect it to have a very bad effect + on system performance + (15:56:54) antrik: both can be avoided by just passing a real anonymous memory object, i.e. one provided by the defpager + (15:57:07) antrik: only problem is that the current defpager implementation can't really handle that... + +#Pastes + +## fsx test on 22.11.11 <a id="fsx_fail2211"/> + $ ~/src/fsx/fsx -W -R -t 4096 -w 4096 -r 4096 bar + mapped writes DISABLED + truncating to largest ever: 0x32000 + truncating to largest ever: 0x39000 + READ BAD DATA: offset = 0x16000, size = 0xd9a0 + OFFSET GOOD BAD RANGE + 0x1f000 0x0000 0x01a0 0x 2d14 + operation# (mod 256) for the bad data may be 1 + LOG DUMP (16 total operations): + 1(1 mod 256): WRITE 0x1f000 thru 0x21d28 (0x2d29 bytes) HOLE ***WWWW + 2(2 mod 256): WRITE 0x10000 thru 0x15bfe (0x5bff bytes) + 3(3 mod 256): READ 0x1d000 thru 0x21668 (0x4669 bytes) + 4(4 mod 256): READ 0xa000 thru 0x16a59 (0xca5a bytes) + 5(5 mod 256): READ 0x8000 thru 0x8f2c (0xf2d bytes) + 6(6 mod 256): READ 0xa000 thru 0x17fe8 (0xdfe9 bytes) + 7(7 mod 256): READ 0x1b000 thru 0x20f33 (0x5f34 bytes) + 8(8 mod 256): READ 0x15000 thru 0x1c05b (0x705c bytes) + 9(9 mod 256): TRUNCATE UP from 0x21d29 to 0x32000 + 10(10 mod 256): READ 0x3000 thru 0x5431 (0x2432 bytes) + 11(11 mod 256): WRITE 0x29000 thru 0x34745 (0xb746 bytes) EXTEND + 12(12 mod 256): TRUNCATE DOWN from 0x34746 to 0x19000 ******WWWW + 13(13 mod 256): READ 0x14000 thru 0x186d8 (0x46d9 bytes) + 14(14 mod 256): TRUNCATE UP from 0x19000 to 0x39000 ******WWWW + 15(15 mod 256): WRITE 0x28000 thru 0x3548c (0xd48d bytes) + 16(16 mod 256): READ 0x16000 thru 0x2399f (0xd9a0 bytes) ***RRRR*** + Correct content saved for comparison + (maybe hexdump "bar" vs "bar.fsxgood") + +## fsx test on 24.11.11 <a id="fsx_fail2411"/> + + $ ~/src/fsx/fsx bar + truncating to largest ever: 0x13e76 + READ BAD DATA: offset = 0x1f62e, size = 0x2152 + OFFSET GOOD BAD RANGE + 0x1f62e 0x0206 0x0000 0x 213e + operation# (mod 256) for the bad data unknown, check HOLE and EXTEND ops + LOG DUMP (6 total operations): + 1(1 mod 256): TRUNCATE UP from 0x0 to 0x13e76 + 2(2 mod 256): WRITE 0x17098 thru 0x26857 (0xf7c0 bytes) HOLE ***WWWW + 3(3 mod 256): READ 0xc73e thru 0x1b801 (0xf0c4 bytes) + 4(4 mod 256): MAPWRITE 0x32e00 thru 0x331fc (0x3fd bytes) + 5(5 mod 256): MAPWRITE 0x7ac1 thru 0x11029 (0x9569 bytes) + 6(6 mod 256): READ 0x1f62e thru 0x2177f (0x2152 bytes) ***RRRR*** + Correct content saved for comparison + (maybe hexdump "bar" vs "bar.fsxgood") diff --git a/user/Sergio_Lopez.mdwn b/user/Sergio_Lopez.mdwn new file mode 100644 index 00000000..b514982e --- /dev/null +++ b/user/Sergio_Lopez.mdwn @@ -0,0 +1,70 @@ +[[!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]]."]]"""]] + +## About Myself +- Name: Sergio Lopez +- Email: <slp@sinrega.org> +- Blog: <http://blogs.nologin.es/slopez> +- Languages: Spanish, English + +## Stuff I'm working on + +### Advisory Pageout + +#### Rationale +This work has two objectives: + +- Put a limit on the number of dirty (or better said, potentially dirty) pages that can be at one given time on Hurd. Having lots of dirty pages stresses the translators when syncing its memory objects, since they could receive a huge amount of m_o_data_return messages in a short amount of time. This is the primary cause for thread explosions. + +- When memory is scarce due to work load, try to avoid flushing anonymous memory. This is done by trying to satisfy the target of free pages releasing clean external pages (which can be considered as cache). + +#### Trying it +I've commited this work to this branch: + +<http://git.savannah.gnu.org/cgit/hurd/gnumach.git/log/?h=k0ro/advisory_pageout/master> + +You'll also need the counterpart for user space: + +<http://blogs.nologin.es/slopez/files/hurd-advisory_pageout.patch> + +If you try it, please let me know your experience with it. + +### Reduce task map fragmentation +After some hours of workload over an ext2fs translator, the number of entries in its memory map (which uses to be something around 60 when clean) is increased up to a few thousand. This increases the cost of each vm_map_lookup_entry, and this is perceived from a user perspective as a significant slowdown on the services provided by that translator. + +The causes for the fragmentation of the task map are: + +#### The problem + +- When a big chunk of memory is reserved, and the protection level is changed in small fractions of it, each of those generates a new entry in the map. This happens in glibc's malloc and sysdeps/mach/hurd/brk.c. + +- Allocating memory for permanent data structures in small chunks, without putting them at an specific address. GNU Mach has the ability of coalescing similar memory entries, but they must be contiguous. As every Hurd server needs to allocate small, temporal buffers for sending and receiving data, these ones will get in the middle of the permanent chunks, preventing them for being coalesced. This is the case of glibc's hurd/hurdmalloc.c, libpager's pagemap and libthread's per thread stack (and possibly some others). + +#### The solution + +- GNU Mach should be able of coalescing entries with similar properties after a call to vm_protect. I'm working in this direction. + +- The use of vm_allocate/mmap in translators should be avoided, except for temporal buffers for IPC operations. + +#### Workaround +While trying to find the causes of the task map fragmentation, I developed some changes which don't provide a complete, clean solution for this problem, but they minimize it (at least, for ext2fs) without significant drawbacks. You can find them here: + +- <http://blogs.nologin.es/slopez/files/glibc-memory_fragmentation.patch> +- <http://blogs.nologin.es/slopez/files/libpager-memory_fragmentation.patch> +- <http://blogs.nologin.es/slopez/files/libthreads-memory_fragmentation.patch> + +### memfs (Memory FS translator) + +### Other miscellaneous changes + +- ext2fs: write multiple pages at once to the backend storage. <http://blogs.nologin.es/slopez/files/ext2fs-multipage_data_return.patch> + +- GNU Mach: avoid calling vm_object_deactivate_pages every time an object enters the cache. <http://blogs.nologin.es/slopez/files/gnumach-optimize_page_deactivation.patch> + diff --git a/user/arnuld.mdwn b/user/arnuld.mdwn index 1f913a2b..d26a543f 100644 --- a/user/arnuld.mdwn +++ b/user/arnuld.mdwn @@ -3,7 +3,7 @@ ## General * Name: arnuld uttre -* Email: arnuld (at) ippimail (dot) com +* Email: arnuld.mizong (at) gmail (dot) com * Country: India * Homepage: <http://www.lispmachine.wordpress.com> diff --git a/user/flaviocruz.mdwn b/user/flaviocruz.mdwn index f3a67afd..c4d3db69 100644 --- a/user/flaviocruz.mdwn +++ b/user/flaviocruz.mdwn @@ -14,9 +14,7 @@ Email: flaviocruz at gmail dot com Some [Hurd stuff](http://opensvn.csie.org/leic/hurd/) -And code: [cl-hurd](http://freehg.org/u/flavioc/cl-hurd/) - -hg clone [http://freehg.org/u/flavioc/cl-hurd/](http://freehg.org/u/flavioc/cl-hurd/) +And code: [cl-hurd](http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=clisp) ## Summer session diff --git a/user/jkoenig.mdwn b/user/jkoenig.mdwn new file mode 100644 index 00000000..dc6edd4e --- /dev/null +++ b/user/jkoenig.mdwn @@ -0,0 +1,32 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +## Jérémie Koenig + +Homepage: [[http://jk.fr.eu.org/]]<br/> +E-mail: [jk@jk.fr.eu.org](mailto:jk@jk.fr.eu.org) + +I am a Hurd enthusiast and occasional contributor, +currently a M.Sc. student at University of Strasbourg. +Among other things I am interested in formal methods, +languages and operating system design. + +Contributions include: + + * Help [[port debian-installer|d-i]], + as a GSoC student for the Debian project during the summer of 2010. + * Rewrite the procfs translator + ([bug-hurd](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00165.html) + [thread](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00001.html)). + * In 2011 I worked as a GSoC student again, + this time for the GNU project, + on [[improving Java support|java]]. + This work is ongoing. + diff --git a/user/jkoenig/d-i.mdwn b/user/jkoenig/d-i.mdwn new file mode 100644 index 00000000..0b9f9f7d --- /dev/null +++ b/user/jkoenig/d-i.mdwn @@ -0,0 +1,358 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +## Hurd Debian-Installer + +My [proposal](http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig) +to work on porting d-i on Hurd +as a [Google Summer of Code](http://code.google.com/soc/) student +has been accepted by the Debian project. + +I will be keeping track of my progress on this page. + +### Links + + * [Modified packages](http://jk.fr.eu.org/debian/unstable) + * [Latest images](http://jk.fr.eu.org/debian/hurd-installer) + * [Debian bugs](http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=jk@jk.fr.eu.org&tag=gsoc2010) + * [BusyBox port](http://lists.debian.org/debian-bsd/2010/05/msg00048.html) + * [GNU Mach initrd](http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00047.html) + +### Roadmap + +* **mach**: initrd support + * (./) preliminary patch posted and self-built (2010-06-12) + * adjustments will be needed (postponed) + * consider the alternatives discussed on bug-hurd (postponed) + +* **glibc**: fix `mkdir("/")` which returned `EINVAL` + * (./) eglibc 2.11.2-1 includes a quick fix by youpi (2010-06-15) + * (./) more complete patch posted to bug-hurd, + since other calls return incorrect errors under some circumstances + (2010-06-16) + * more work on it will be needed to make it fix the whole thing + (postponed) + +* (./) **partman** (2010-06-23) + * (./) add hurd-i386 to + `partman-partitioning/lib/disk-label.sh` + (2010-06-16, commited by youpi on 2010-06-23) + * (./) short-circuit + `partman-basicfilesystems/init.d/kernelmodules_basicfilesystems` + (2010-06-16) + * (./) partman-auto recipes: + make the default filesystem os-dependent + when it has not been preseeded (ie. the *seen* flag is clear) + * (./) force 4k blocks and 128 bytes inodes + * (./) submit patches to bugs.debian.org + ([[!debbug 586870]] and [[!debbug 586871]]) + * (./) rebuild with responsible version numbers and upload to my repository + +* (./) **libparted** (2010-06-23) + * (./) fix device paths ([[!debbug 586696]]) + * (./) fix crash on exit for part:* stores ([[!debbug 586682]]) + +* **hurd-udeb** (2010-06-23) + * (./) rebuild with the hack suggested by youpi for qemu network configuration + * (./) fix mount to accept `-o defaults` + * cleanup, ask youpi to commit + +* reloading the partition table (2010-06-25) + * User-space part stores + * (./) hurd-udeb now uses `part:N:device:X` for partition devices + (2010-06-23) + * (./) it also provides /lib/partman/commit.d/??hurd\_reloadpart, + which basically does `settrans -ag /dev/[hs]d*`. + (2010-06-24) + * Kernel-based partition devices + * (./) Mach's drivers from Linux support reloading partitions. + With help from youpi this has been made available through a + device\_set\_status() call. + * (./) make libparted use it + * Reminder: + I should file a bug against libparted with the patch sometime. + +* (./) The `/servers/exec` issue (2010-06-26) + * Due to /servers being inexistant, + the bootstrap ext2fs could not register the initial exec server, + meaning that non-bootstrap filesystems used a different one + (started from the passive translator), + which for some reason died on shell scripts, making them stall. + * Adding the `/servers` directory to hurd-udeb fixed it, + as well as the /hurd/proc issue + (failed to be run by init the first time around). + * Reminder: report the non-bootstrap exec servers failure on scripts. + +* (./) **base-installer**: (2010-06-26) + * Work around non-existant /proc/mounts. + * Firmlink /servers into /target after debootstrap + to make the network available. + +* (./) **grub-installer** + * (./) add hurd support (2010-06-27) + * /!\ grub-legacy still needs to be tested + * submit changes as a Debian bug + +**Milestone (2010-06-28): +installer kindof works, with documented manual intervention required** + +* (./) Sort out the situation with dev node creation (2010-07-07): + * Devices and servers used to be set up by debootstrap; + the hurd package would add some missing nodes. + * New strategy implemented in hurd and debootstrap: + * debootstrap uses active firmlinks into the host system + for the target system's /dev and /servers. + * the hurd package now include a `setup-translators` script, + which is used to register the passive translators by the installer's + `/libexec/runsystem` and hurd's postinst script. + +* **busybox**: submit upstream and to [[!debbug 323670]] + (waiting for upstream to review) + * (./) I have mentioned my work on the upstream mailing list, + * (./) merge the recent changes from upstream, + notably to the build system. + (2010-06-23) + * (./) ask upstream for review and merge + (2010-06-25) + * (./) sent as patches as requested + (2010-07-08) + * (./) backport any additional changes onto the debian branch + * (./) hijack [[!debbug 323670]] and submit my patches + +* **aptitude**: + * Currently broken on hurd-i386: + [[!debpkg gtest]] fails to build because of a segfault in one of the test + cases, [[!debpkg google-mock]] and hence [[!debpkg aptitude]] are missing + it as a build-dep. + The older package is not installable anymore because it's linked against + an older version of libept, which has been removed. + * (./) I bypassed the tests and uploaded the 3 packages to my repository + (2010-07-08) + * The segfault will have to be sorted out. (postponed) + +* (./) "Fix" the swap situation. (2010-07-08) + * The device\_close() libstore patch + had the unfortunate effect of making swapon fail, + since the device it activates has to be kept open. + * add options for MAKEDEV and setup-devices + to use the libparted stores + * disable youpi's patch + * make partman-basicfilesystems re-create the device + as a kernel partition, which is needed for swapon + +* (./) netcfg-static: port to hurd (2010-07-09) + * There was some amount of hurd support already + (namely, activating the interface by replacing the socket translator) + * However, this code started an active translator with + di\_exec\_shell\_log("settrans -a ...), + which stalled as a consequence of it capturing libdi's pipe + as its standard output. + * Network devices must be probed by trying to open Mach devices + with predetermined names (currently eth%d, wl%d), + because getifaddrs() does not seem to work on Hurd. + * /!\ netcfg, and configuring the installed system, postponed. + +* **procps** 3.2.7-11 (current hurd-i386 version) has [[!debbug 546888]] + * (./) Submit [[!debbug 588677]] and upload the result to my repository. + (2010-07-11) + +* (./) Set up a Debian mirror with modified packages for installation + * the [mirror](http://jk.fr.eu.org/debian/hurd-install/mirror) + is now up and running (2010-07-06) + * hacked the image build script to include its public key in + debian-archive-keyring at image build time (2010-07-08) + * Apparently debootstrap does not handle multiple versions very well. + Fix by using dpkg-scan{package,sources} rather than apt-ftparchive + to create index files. + (2010-07-10) + * Use the override files from ftp.debian.org, + to avoid debootstrap grabbing inappropriate packages. + * Changed them to make [[!debpkg ifupdown]], + [[!debpkg dhcp3-client]] and [[!debpkg dhcp3-client]] priority extra, + because they're uninstallable at the moment. + (2010-07-12) + +* (./) Put together a "jk-archive-keyring" package, + so that the mirror is authenticated in the target system as well. + (2010-07-12) + +* (./) Fix grub for user-space partitions (2010-07-16) + * grub-probe detects the whole device rather than the partition + as the device behind /boot/grub. + Consequently, grub-install fails. + * One approach would be to replace /dev/hd* by kernel devices + for file systems as well as for swap partitions. + > {X} this makes the installer crash, + > possibly due to cache coherency issue between hdX and hdXsY. + + * (./) GRUB2 kern/emu/getroot.c + [patched](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00059.html) + to support part stores. + +* (./) Fix finish-install to skip `finish-install.d/90console` on Hurd + (2010-07-17) + +* (./) Avoid starting unnecessary /dev translators in a burst (2010-07-20) + * Use debootstrap use the extracted /usr/lib/hurd/setup-translators + to create device and server nodes in /target, + then firmlink the whole /target/dev and /target/servers + to the outer system. + * Make hurd.postinst not touch them on initial install. + +* (./) Fix mach-defpager for file and part stores on larger devices + * Use DEVICE\_GET\_RECORDS instead of DEVICE\_GET\_SIZE, which overflows an int + (2010-07-22) + +**Milestone (2010-07-22): +installer works but it's still somewhat ugly and broken** + +* (./) Ship the UTF-8 font for the hurd console + (2010-07-22) + * Upload a version of bogl with youpi's patch for Hurd. + (see [[!debbug 589987]]) + * Fix the hurd console for fonts with 16 pixels wide glyphs + (ie. handle the 8-wide glyph in there correclty) + * Support double-width glyphs (2010-07-24) + * (./) However the reduced font can't be loaded yet, + so make installer/build/Makefile + ship the whole `/usr/src/unifont.bgf` + as `/usr/share/hurd/vga-system.bgf`. + +* (./) Make the installer used the extended capabilities of the Hurd console + (2010-07-23) + * Set an UTF-8 locale in `/lib/debian-installer.d/S41term-hurd`. + * localechooser: set the language display level to 3 + when using the hurd console. + +* (./) **busybox**: cross-platform package uploaded to experimental + (2010-08-03?) + * Aurelien Jarno updated the packaging to busybox 1.17.1, + fixed a whole lot of bugs, + and uploaded a new package with both our changes; + * most patches adopted upstream, and included in the new package; + * (u)mount/swaponoff ported to kFreeBSD; + * per-OS configuration overrides. + +* (./) Update custom packages to the latest versions + and send updated patches to the BTS + (2010-08-11) + * updated partman-base to choose a default filesystem in debian/rules + rather than at runtime, + as suggested by Aurelien Jarno in [[!debbug 586870]] + * patch submitted for debian-installer-utils + ([[!debbug 592684]]). + * patch submitted for locale-chooser + ([[!debbug 592690]]). + * debootstrap, grub-installer and finish-install not yet submitted, + since the details may still change. + +* (./) **partman-target**: fix fstab creation + (2010-08-11) + * See [[!debbug 592671]] + * debian/rules: set `partman/mount_style` to `traditional` on Hurd. + * finish.d/create\_fstab\_header: add a Hurd case. + +* (./) **rootskel**: FTBFS on Hurd and other quirks + (to be fixed very soon) + +* **d-i/installer/build**: (expected soon) + * publish the patch I use + * sort out the changes suitable for inclusion + and ask youpi and/or debian-boot@l.d.o to commit them + +* call for testing and fix the bugs + +* Bug in setup-translators/MAKEDEV: + permissions are broken for nodes re-created through `MAKEDEV -k`, + because MAKEDEV's chmod/chown reaches the pre-existing translator + * Maybe settrans could be made to accept -o/--owner and + -p/--perm, to set the permissions for the underlying node? + +* (./) Silence the "no kernel" warning somehow. + +* Investigate the wget/libc/pfinet/whatever bug which corrupts Packages.gz, + see the IRC log for 2010-07-23, around 1am UTC+0200 + +* Try to resolve problems with udebs which are uninstallable on hurd-i386, + such as installation-locale and partman-whatever. + +* Provide `/proc/cmdline -> 2/cmdline`, or something. + +* Prepare a NMU for genext2fs (which is orphaned), + and ask youpi to sponsor the upload. + +* **busybox**: port + * fix stty/stat/ipcs on kFreeBSD, + * generally port more stuff, + * *ip* is needed (maybe) for network configuration, + * *mount*, *swaponoff* can be from hurd-udeb for now, + though the kFreeBSD people will need them + +* **partman**: further adjustments + * partman-base: handle /dev/hd?s* in lib/base.h + * hide irrelevant mount options? (sync, relatime) + +* Network configuration on the installed system. + This includes porting ifupdown and isc-dhcp-client, + which are currently uninstallable on hurd-i386. +* Also, better DHCP support during and after installation + +* improve the [initrd situation](FIXME: link to bug-hurd post): + ajust the ramdisk support in Mach, + use tmpfs if possible. + +* mklibs{,-copy}: + test library reduction, + make it copy the ld.so -> ld.so.1 symlink. + +* (./) hurd console fonts + +**Milestone (expected 2010-07-19): +it works great and it's beautiful** + +* test, fix, document +* support more types of installation images +* give a shot at the graphical installer if time permits +* integrate wireless drivers with netcfg +* see how [[zhengda]]'s work on DDE could be integrated +* etc.. + +### Mostly done + +#### Week 1 (2010-05-24) + +* genext2fs: patches submitted, [[!debbug 562999]] + which add support for all block sizes and choosing them at runtime. +* busybox: started porting the upstream and Debian package to Hurd and FreeBSD +* rebuilding hurd-udeb from the pkg-hurd version + and adding a ld.so link to the initrd + fixes the exec translator crashing on startup. + (BTW would there be a mean to detect this from the libdiskfs bootstrap code + and report it ?) + +#### Week 2 (2010-05-31 to 2010-06-06) + +* *busybox*: patches [posted](http://lists.debian.org/debian-bsd/2010/05/msg00048.html). +* *libdebian-installer4*: [[!debbug 584538]] +* started working on mach initrd support +* the installation images could boot into the main-menu + with the following changes: + * rebuild hurd-udeb from with the latest pkg-hurd patches + * use busybox from my osports-debian branch (see link above) + * tweak the d-i image build scripts + * the symlink /lib/ld.so -> ld.so.1 needs to be created somehow + (youpi mentionned it being the job of libc0.3-udeb I think) + * fix the poll() issue in libdebian-installer + (patch to be submitted soon), + also there is some hurd doxygen short-circuiting stuff + there which does not apply any more and prevents is to build. + * feed the initrd as a hard drive in qemu + (with some more space added to avoid it from becoming full) + diff --git a/user/jkoenig/gsoc2011_classes.dia b/user/jkoenig/gsoc2011_classes.dia new file mode 100644 index 00000000..1aa3ef6c --- /dev/null +++ b/user/jkoenig/gsoc2011_classes.dia @@ -0,0 +1,2227 @@ +<?xml version="1.0" encoding="UTF-8"?> +<dia:diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/"> + <dia:diagramdata> + <dia:attribute name="background"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="pagebreak"> + <dia:color val="#000099"/> + </dia:attribute> + <dia:attribute name="paper"> + <dia:composite type="paper"> + <dia:attribute name="name"> + <dia:string>#A4#</dia:string> + </dia:attribute> + <dia:attribute name="tmargin"> + <dia:real val="2.8222000598907471"/> + </dia:attribute> + <dia:attribute name="bmargin"> + <dia:real val="2.8222000598907471"/> + </dia:attribute> + <dia:attribute name="lmargin"> + <dia:real val="2.8222000598907471"/> + </dia:attribute> + <dia:attribute name="rmargin"> + <dia:real val="2.8222000598907471"/> + </dia:attribute> + <dia:attribute name="is_portrait"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="scaling"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="fitto"> + <dia:boolean val="false"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="grid"> + <dia:composite type="grid"> + <dia:attribute name="width_x"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="width_y"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="visible_x"> + <dia:int val="1"/> + </dia:attribute> + <dia:attribute name="visible_y"> + <dia:int val="1"/> + </dia:attribute> + <dia:composite type="color"/> + </dia:composite> + </dia:attribute> + <dia:attribute name="color"> + <dia:color val="#d8e5e5"/> + </dia:attribute> + <dia:attribute name="guides"> + <dia:composite type="guides"> + <dia:attribute name="hguides"/> + <dia:attribute name="vguides"/> + </dia:composite> + </dia:attribute> + </dia:diagramdata> + <dia:layer name="Arrière-plan" visible="true" active="true"> + <dia:group> + <dia:object type="UML - LargePackage" version="0" id="O0"> + <dia:attribute name="obj_pos"> + <dia:point val="43.3541,9.67669"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="43.3041,8.62669;62.3869,21.8152"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="43.3541,9.67669"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="18.982784066269787"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="12.08849294970096"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000149011612"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_colour"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#User-defined classes#</dia:string> + </dia:attribute> + </dia:object> + <dia:object type="UML - Class" version="0" id="O1"> + <dia:attribute name="obj_pos"> + <dia:point val="46.0492,12.9799"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="45.9992,12.9299;60.4592,18.4299"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="46.0492,12.9799"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="14.359999999999999"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="5.4000000000000004"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#HelloIo#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>#Implements a file which always contains "Hello, World!\n"#</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_operations"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="visible_comments"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_after_char"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_line_length"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_tagging"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_color"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="normal_font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="abstract_font"> + <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> + </dia:attribute> + <dia:attribute name="polymorphic_font"> + <dia:font family="monospace" style="8" name="Courier-Oblique"/> + </dia:attribute> + <dia:attribute name="classname_font"> + <dia:font family="sans" style="80" name="Helvetica-Bold"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font"> + <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> + </dia:attribute> + <dia:attribute name="comment_font"> + <dia:font family="sans" style="8" name="Helvetica-Oblique"/> + </dia:attribute> + <dia:attribute name="normal_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="polymorphic_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="abstract_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="comment_font_height"> + <dia:real val="0.69999999999999996"/> + </dia:attribute> + <dia:attribute name="attributes"/> + <dia:attribute name="operations"> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#write#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#data#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#char[]#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#read#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#char[]#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#amount#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#seek#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#whence#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="template"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="templates"/> + </dia:object> + </dia:group> + <dia:group> + <dia:object type="UML - LargePackage" version="0" id="O2"> + <dia:attribute name="obj_pos"> + <dia:point val="20.9284,1.19141"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="20.8784,0.141406;41.2223,31.2904"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="20.9284,1.19141"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="20.243864620053902"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="30.049005191839264"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000149011612"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_colour"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#MIG-generated classes#</dia:string> + </dia:attribute> + </dia:object> + <dia:object type="UML - Class" version="0" id="O3"> + <dia:attribute name="obj_pos"> + <dia:point val="24.8976,5.14749"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="24.8476,5.09749;38.1526,9.79749"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="24.8976,5.14749"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="13.205"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="4.5999999999999996"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#IoServer#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>#Implements a message handler using a given IO object as a backend#</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_operations"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="visible_comments"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_after_char"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_line_length"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_tagging"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_color"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="normal_font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="abstract_font"> + <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> + </dia:attribute> + <dia:attribute name="polymorphic_font"> + <dia:font family="monospace" style="8" name="Courier-Oblique"/> + </dia:attribute> + <dia:attribute name="classname_font"> + <dia:font family="sans" style="80" name="Helvetica-Bold"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font"> + <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> + </dia:attribute> + <dia:attribute name="comment_font"> + <dia:font family="sans" style="8" name="Helvetica-Oblique"/> + </dia:attribute> + <dia:attribute name="normal_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="polymorphic_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="abstract_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="comment_font_height"> + <dia:real val="0.69999999999999996"/> + </dia:attribute> + <dia:attribute name="attributes"/> + <dia:attribute name="operations"> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#IoServer#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#back#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Io#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#handle#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Message#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#message#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Message#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="template"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="templates"/> + </dia:object> + <dia:object type="UML - Class" version="0" id="O4"> + <dia:attribute name="obj_pos"> + <dia:point val="24.2494,13.3231"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="24.1994,13.2731;38.6594,18.1731"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="24.2494,13.3231"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="14.359999999999999"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="4.8000000000000007"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#Io#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>#interface#</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="suppress_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_operations"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="visible_comments"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="wrap_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_after_char"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_line_length"> + <dia:int val="17"/> + </dia:attribute> + <dia:attribute name="comment_tagging"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_color"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="normal_font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="abstract_font"> + <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> + </dia:attribute> + <dia:attribute name="polymorphic_font"> + <dia:font family="monospace" style="8" name="Courier-Oblique"/> + </dia:attribute> + <dia:attribute name="classname_font"> + <dia:font family="sans" style="80" name="Helvetica-Bold"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font"> + <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> + </dia:attribute> + <dia:attribute name="comment_font"> + <dia:font family="sans" style="8" name="Helvetica-Oblique"/> + </dia:attribute> + <dia:attribute name="normal_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="polymorphic_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="abstract_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="comment_font_height"> + <dia:real val="0.69999999999999996"/> + </dia:attribute> + <dia:attribute name="attributes"/> + <dia:attribute name="operations"> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#write#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#data#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#char[]#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#read#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#char[]#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#amount#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#seek#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#whence#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="template"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="templates"/> + </dia:object> + <dia:object type="UML - Class" version="0" id="O5"> + <dia:attribute name="obj_pos"> + <dia:point val="24.2494,21.6986"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="24.1994,21.6486;38.6594,27.9486"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="24.2494,21.6986"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="14.359999999999999"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="6.2000000000000002"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#IoUser#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>#Implements the Io interface by performing RPC#</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_operations"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="visible_comments"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_after_char"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_line_length"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_tagging"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_color"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="normal_font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="abstract_font"> + <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> + </dia:attribute> + <dia:attribute name="polymorphic_font"> + <dia:font family="monospace" style="8" name="Courier-Oblique"/> + </dia:attribute> + <dia:attribute name="classname_font"> + <dia:font family="sans" style="80" name="Helvetica-Bold"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font"> + <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> + </dia:attribute> + <dia:attribute name="comment_font"> + <dia:font family="sans" style="8" name="Helvetica-Oblique"/> + </dia:attribute> + <dia:attribute name="normal_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="polymorphic_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="abstract_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="comment_font_height"> + <dia:real val="0.69999999999999996"/> + </dia:attribute> + <dia:attribute name="attributes"/> + <dia:attribute name="operations"> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#IoUser#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#port#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#MachPort#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#write#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#data#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#char[]#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#read#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#char[]#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#amount#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#seek#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#offset#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#whence#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#int#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="template"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="templates"/> + </dia:object> + <dia:object type="UML - Realizes" version="1" id="O6"> + <dia:attribute name="obj_pos"> + <dia:point val="31.4294,18.1734"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="31.3794,18.1734;31.5294,21.719"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="31.4294,18.1734"/> + <dia:point val="31.4294,18.1734"/> + <dia:point val="31.4294,21.6482"/> + <dia:point val="31.4294,21.6482"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O4" connection="14"/> + <dia:connection handle="1" to="O5" connection="16"/> + </dia:connections> + </dia:object> + <dia:object type="UML - Association" version="2" id="O7"> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="direction"> + <dia:enum val="1"/> + </dia:attribute> + <dia:attribute name="show_direction"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="assoc_type"> + <dia:enum val="1"/> + </dia:attribute> + <dia:attribute name="role_a"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="multipicity_a"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility_a"> + <dia:enum val="3"/> + </dia:attribute> + <dia:attribute name="show_arrow_a"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="role_b"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="multipicity_b"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility_b"> + <dia:enum val="3"/> + </dia:attribute> + <dia:attribute name="show_arrow_b"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="obj_pos"> + <dia:point val="24.8976,8.44749"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="22.3132,7.69749;25.6476,16.0231"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="24.8976,8.44749"/> + <dia:point val="22.3632,8.44749"/> + <dia:point val="22.3632,14.4231"/> + <dia:point val="24.2494,14.4231"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O3" connection="8"/> + <dia:connection handle="1" to="O4" connection="3"/> + </dia:connections> + <dia:childnode parent="O2"/> + </dia:object> + </dia:group> + <dia:group> + <dia:object type="UML - Realizes" version="1" id="O8"> + <dia:attribute name="obj_pos"> + <dia:point val="10.6153,8.74801"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="10.5653,8.74801;10.7153,12.32"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="10.6153,8.74801"/> + <dia:point val="10.6153,8.74801"/> + <dia:point val="10.6153,12.2493"/> + <dia:point val="10.6153,12.2493"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O10" connection="10"/> + <dia:connection handle="1" to="O11" connection="12"/> + </dia:connections> + <dia:childnode parent="O9"/> + </dia:object> + <dia:object type="UML - LargePackage" version="0" id="O9"> + <dia:attribute name="obj_pos"> + <dia:point val="0.503207,3.45415"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="0.453207,2.40415;18.7966,24.081"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="0.503207,3.45415"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="18.243354954612922"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="20.576807332528524"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000149011612"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_colour"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#libports-like library#</dia:string> + </dia:attribute> + </dia:object> + <dia:object type="UML - Class" version="0" id="O10"> + <dia:attribute name="obj_pos"> + <dia:point val="4.78285,5.49761"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="4.73285,5.44761;16.4978,8.74761"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="4.78285,5.49761"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="11.664999999999999"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="3.2000000000000002"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#Server#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>#interface#</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_operations"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="visible_comments"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="wrap_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_after_char"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_line_length"> + <dia:int val="17"/> + </dia:attribute> + <dia:attribute name="comment_tagging"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_color"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="normal_font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="abstract_font"> + <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> + </dia:attribute> + <dia:attribute name="polymorphic_font"> + <dia:font family="monospace" style="8" name="Courier-Oblique"/> + </dia:attribute> + <dia:attribute name="classname_font"> + <dia:font family="sans" style="80" name="Helvetica-Bold"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font"> + <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> + </dia:attribute> + <dia:attribute name="comment_font"> + <dia:font family="sans" style="8" name="Helvetica-Oblique"/> + </dia:attribute> + <dia:attribute name="normal_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="polymorphic_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="abstract_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="comment_font_height"> + <dia:real val="0.69999999999999996"/> + </dia:attribute> + <dia:attribute name="attributes"/> + <dia:attribute name="operations"> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#handle#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Message#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#msg#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Message#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="template"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="templates"/> + </dia:object> + <dia:object type="UML - Class" version="0" id="O11"> + <dia:attribute name="obj_pos"> + <dia:point val="4.78285,12.2997"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="4.73285,12.2497;16.4978,15.5497"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="4.78285,12.2997"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="11.664999999999999"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="3.2000000000000002"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#Demux#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="suppress_operations"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_attributes"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="visible_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="visible_comments"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="wrap_operations"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="wrap_after_char"> + <dia:int val="40"/> + </dia:attribute> + <dia:attribute name="comment_line_length"> + <dia:int val="17"/> + </dia:attribute> + <dia:attribute name="comment_tagging"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_color"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text_color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="normal_font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="abstract_font"> + <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> + </dia:attribute> + <dia:attribute name="polymorphic_font"> + <dia:font family="monospace" style="8" name="Courier-Oblique"/> + </dia:attribute> + <dia:attribute name="classname_font"> + <dia:font family="sans" style="80" name="Helvetica-Bold"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font"> + <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> + </dia:attribute> + <dia:attribute name="comment_font"> + <dia:font family="sans" style="8" name="Helvetica-Oblique"/> + </dia:attribute> + <dia:attribute name="normal_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="polymorphic_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="abstract_font_height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="abstract_classname_font_height"> + <dia:real val="1"/> + </dia:attribute> + <dia:attribute name="comment_font_height"> + <dia:real val="0.69999999999999996"/> + </dia:attribute> + <dia:attribute name="attributes"/> + <dia:attribute name="operations"> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#addServer#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#s#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Server#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + <dia:composite type="umloperation"> + <dia:attribute name="name"> + <dia:string>#handle#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Message#</dia:string> + </dia:attribute> + <dia:attribute name="visibility"> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="abstract"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="inheritance_type"> + <dia:enum val="2"/> + </dia:attribute> + <dia:attribute name="query"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="class_scope"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="parameters"> + <dia:composite type="umlparameter"> + <dia:attribute name="name"> + <dia:string>#msg#</dia:string> + </dia:attribute> + <dia:attribute name="type"> + <dia:string>#Message#</dia:string> + </dia:attribute> + <dia:attribute name="value"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="comment"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="kind"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:attribute name="template"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="templates"/> + <dia:childnode parent="O9"/> + </dia:object> + <dia:object type="UML - Association" version="2" id="O12"> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="direction"> + <dia:enum val="1"/> + </dia:attribute> + <dia:attribute name="show_direction"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="assoc_type"> + <dia:enum val="1"/> + </dia:attribute> + <dia:attribute name="role_a"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="multipicity_a"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility_a"> + <dia:enum val="3"/> + </dia:attribute> + <dia:attribute name="show_arrow_a"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="role_b"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="multipicity_b"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="visibility_b"> + <dia:enum val="3"/> + </dia:attribute> + <dia:attribute name="show_arrow_b"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="obj_pos"> + <dia:point val="4.78285,12.9997"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="2.75192,6.54761;5.53285,14.5997"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="4.78285,12.9997"/> + <dia:point val="2.80192,12.9997"/> + <dia:point val="2.80192,6.59761"/> + <dia:point val="4.78285,6.59761"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O11" connection="3"/> + <dia:connection handle="1" to="O10" connection="3"/> + </dia:connections> + <dia:childnode parent="O9"/> + </dia:object> + <dia:object type="UML - Note" version="0" id="O13"> + <dia:attribute name="obj_pos"> + <dia:point val="5.16035,19.1017"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="5.11035,19.0517;16.1203,22.4517"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="5.16035,19.1017"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="10.91"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="3.3000000000000003"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_colour"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text"> + <dia:composite type="text"> + <dia:attribute name="string"> + <dia:string>#Plus some kind of port set +support and a way to start +a server thread.#</dia:string> + </dia:attribute> + <dia:attribute name="font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="pos"> + <dia:point val="5.51035,20.3467"/> + </dia:attribute> + <dia:attribute name="color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="alignment"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + <dia:childnode parent="O9"/> + </dia:object> + <dia:object type="UML - Realizes" version="1" id="O14"> + <dia:attribute name="obj_pos"> + <dia:point val="10.6153,8.74801"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="10.5653,8.74801;10.7153,12.32"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="10.6153,8.74801"/> + <dia:point val="10.6153,8.74801"/> + <dia:point val="10.6153,12.2493"/> + <dia:point val="10.6153,12.2493"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O10" connection="10"/> + <dia:connection handle="1" to="O11" connection="12"/> + </dia:connections> + <dia:childnode parent="O9"/> + </dia:object> + </dia:group> + <dia:object type="UML - Note" version="0" id="O15"> + <dia:attribute name="obj_pos"> + <dia:point val="29.2528,-4.64872"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="29.2028,-4.69872;32.8978,-2.89872"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="elem_corner"> + <dia:point val="29.2528,-4.64872"/> + </dia:attribute> + <dia:attribute name="elem_width"> + <dia:real val="3.5949999999999998"/> + </dia:attribute> + <dia:attribute name="elem_height"> + <dia:real val="1.7"/> + </dia:attribute> + <dia:attribute name="line_width"> + <dia:real val="0.10000000000000001"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="fill_colour"> + <dia:color val="#ffffff"/> + </dia:attribute> + <dia:attribute name="text"> + <dia:composite type="text"> + <dia:attribute name="string"> + <dia:string>#io.defs#</dia:string> + </dia:attribute> + <dia:attribute name="font"> + <dia:font family="monospace" style="0" name="Courier"/> + </dia:attribute> + <dia:attribute name="height"> + <dia:real val="0.80000000000000004"/> + </dia:attribute> + <dia:attribute name="pos"> + <dia:point val="29.6028,-3.40372"/> + </dia:attribute> + <dia:attribute name="color"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="alignment"> + <dia:enum val="0"/> + </dia:attribute> + </dia:composite> + </dia:attribute> + </dia:object> + <dia:object type="UML - Dependency" version="1" id="O16"> + <dia:attribute name="obj_pos"> + <dia:point val="31.0503,-2.94872"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="31.0003,-2.94872;32.3053,1.26212"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="31.0503,-2.94872"/> + <dia:point val="31.0503,-2.94872"/> + <dia:point val="31.0503,1.19141"/> + <dia:point val="31.0503,1.19141"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>#mig#</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="draw_arrow"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O15" connection="6"/> + <dia:connection handle="1" to="O2" connection="1"/> + </dia:connections> + </dia:object> + <dia:object type="UML - Realizes" version="1" id="O17"> + <dia:attribute name="obj_pos"> + <dia:point val="38.6094,14.4231"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="38.5594,13.5731;46.0992,16.0015"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="38.6094,14.4231"/> + <dia:point val="42.3293,14.4231"/> + <dia:point val="42.3293,14.3799"/> + <dia:point val="46.0492,14.3799"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="true"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O4" connection="4"/> + <dia:connection handle="1" to="O1" connection="3"/> + </dia:connections> + </dia:object> + <dia:object type="UML - Realizes" version="1" id="O18"> + <dia:attribute name="obj_pos"> + <dia:point val="16.4478,6.59761"/> + </dia:attribute> + <dia:attribute name="obj_bb"> + <dia:rectangle val="16.3978,5.74761;24.9476,8.17255"/> + </dia:attribute> + <dia:attribute name="meta"> + <dia:composite type="dict"/> + </dia:attribute> + <dia:attribute name="orth_points"> + <dia:point val="16.4478,6.59761"/> + <dia:point val="20.4657,6.59761"/> + <dia:point val="20.4657,6.54749"/> + <dia:point val="24.8976,6.54749"/> + </dia:attribute> + <dia:attribute name="orth_orient"> + <dia:enum val="0"/> + <dia:enum val="1"/> + <dia:enum val="0"/> + </dia:attribute> + <dia:attribute name="orth_autoroute"> + <dia:boolean val="false"/> + </dia:attribute> + <dia:attribute name="line_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="text_colour"> + <dia:color val="#000000"/> + </dia:attribute> + <dia:attribute name="name"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:attribute name="stereotype"> + <dia:string>##</dia:string> + </dia:attribute> + <dia:connections> + <dia:connection handle="0" to="O10" connection="4"/> + <dia:connection handle="1" to="O3" connection="3"/> + </dia:connections> + </dia:object> + </dia:layer> +</dia:diagram> diff --git a/user/jkoenig/gsoc2011_classes.png b/user/jkoenig/gsoc2011_classes.png Binary files differnew file mode 100644 index 00000000..7149b813 --- /dev/null +++ b/user/jkoenig/gsoc2011_classes.png diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn new file mode 100644 index 00000000..9840f14f --- /dev/null +++ b/user/jkoenig/gsoc2011_proposal.mdwn @@ -0,0 +1,12 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +This page has moved [[here|java]]. + diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn new file mode 100644 index 00000000..fd12987e --- /dev/null +++ b/user/jkoenig/java.mdwn @@ -0,0 +1,516 @@ +[[!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 stable_URL]] + + +# Improve Java on Hurd + + +## Description + +The project consists in improving Java support on Hurd. +This includes porting OpenJDK, +creating low-level Java bindings for Mach and Hurd, +as well as creating Java libraries to help with translator development. + +I started working on this as a participant in Google Summer of Code 2011, +for the GNU project. +See my original [[proposal]] and final [[report]]. + + +## Current status + +OpenJDK 7 kindof works, +but there are still imperfections and some integration work remains. + +This page is somewhat out-of-date. +At the moment, +the GSoC [report] is more accurate. + + +### Apt repository + +Modified Debian packages are available in this repository: + + deb http://jk.fr.eu.org/debian experimental/ + deb-src http://jk.fr.eu.org/debian experimental/ + + +### Glibc signal code improvements + +2011-06-29: +Patches were submitted to `libc-alpha` +which implement global signal dispositions and `SA_SIGINFO`. +My latest code is available on +[github](http://github.com/jeremie-koenig/glibc/commits/master-beware-rebase), +and modified Debian packages +are available in my apt repository. + +2011-07-20: +The patches were reviewed by Samuel Thibault. +Samuel pointed out a couple of issues +and I beleive I have addressed all of them (fixes posted). +I'm in the process of publishing updated libc and hurd packages; +provided those work as expected, +the next step would be to get these changes into Debian. + +One question is how the new symbols introduced by my patches +should be handled. +Weak symbols turned out to be impractical, +so I'm currently considering using a Debian-specific +symbol version in the interim period (`GLIBC_2.13_DEBIAN_8` so far). +The ultimate symbol version to be used will depend on +the time at which the patches get integrated upstream +(most likely `GLIBC_2.15`), +at which point we will alias the interim version +to the new one in debian packages. + +I have modified libc0.3 to include a `deb-symbols(5)` file +(alternatively see <http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps>) +so that we get an accurate libc dependency in `hurd` and other packages +when the symbols in question are pulled in. + +[[hurd/libthreads]] (cthreads library) will not be changed. There's no reason +why its behavior should change, whereas for [[libpthread]] it's needed for +conformance. Patches posted on 2011-05-25, but there's a more recent one in +the modified hurd package (adds `_hurd_sigstate_delete` and removes the weak +symbols). + +IRC, freenode, #hurd, 2011-07-27: + + < jkoenig> the glibc patches are pending review and inclusion in Debian (I + think youpi wants to check my latest additions before we go ahead with + that) + < jkoenig> when it's in Debian and the sky does not fall, I intend to + resubmit a full series to libc-alpha for inclusion upstream. + +IRC, freenode, #hurd, 2011-08-24: + + < youpi> jkoenig: I'll probably commit your siginfo/globalsig patches soon + < youpi> I'm building the ant package atm, seems to proceed great + < jkoenig> youpi, great! + +Another issue which came up with OpenJDK is the expansion +by the dynamic linker of `$ORIGIN` in the `RPATH` header, +see below. + +#### Plans + +The patches are pending review and inclusion upstream. +As soon as we reach an agreement wrt. the new interfaces +(in particular wrt. the value of `SA_SIGINFO`), +the patches will be applied to the Debian libc packages +for broader testing. + + +##### Open Items + + * Test patches: in progress, [[jkoenig]], Svante. More volunteers welcome, + of course. + + > There's an issue with gdb, + > namely signals lose their "untracedness" when they go + > through the global sigstate's pending mask, + > so gdb spins intercepting a signal and trying to deliver it. + > [Patch](http://github.com/jeremie-koenig/glibc/commit/3ecb990e9d08d5f75adc40b738b35a1802cc0943). + + * If [[jkoenig]] thinks it's mature enough: should ask + [[Samuel|samuelthibault]] to test these patches on the buildds. + + > There's a risk that a dependency on my patched libc + > might be pulled in while building packages + > (in particular hurd) + > --[[jkoenig]] 2011-06-22 + + * Waiting on ABI finalization ([!] Roland). + + * Which numeric values to use for `SA_SIGINFO` (and `SA_NOCLDWAIT`)? + + > Staying in sync with BSD seems the most logical approach, + > so I have defined it to 0x40. --[[jkoenig]] 2011-06-29 + + * Get patches reviewed (Roland?), and integrated into official sources: [!] + [[tschwinge]]. + + > [[samuelthibault]] reviewed the patches and pointed out a couple of + > issues which I'm currently working on: + > + > * Slight behaviour change with respect to forgetting blocked ignored + > signals. POSIX is flexible in this regard but I guess we could retain + > them instead of the current behaviour. + > * Sigstate accessors could be made extern inline functions. + > I suggest we postpone this. + > * Incorrect changes for `msg_{get,set}_init_int(INIT_SIGMASK)` + > * Some comments which can be improved. + > + > Once these are fixed we can probably test the patches in Debian. + > + > --[[jk]] 2011-07-06 + + * Documentations bits (from here, the initial [[proposal]], and elsewhere) + should probably be + moved either into the appropriate glibc or Hurd documentation + files/reference manuals, or to [[glibc/signal]]. + + * `SA_SIGINFO` patch is based on [[Samuel|samuelthibault]]'s earlier work. + Thus, have him review the new patch? + + * `SA_SIGINFO` patch has a few TODOs w.r.t. protocol changes for missing + information, and for FPU state. Providing even incomplete information is + an improvement on the current status. The question is, whether + applications rely on this information in any hard way if `SA_SIGINFO` is + available? + + * We could possibly rename certain fields in `struct siginfo`, say + `si_pid_not_implemented`, to ensure compilation failures for programs + which use them. Or perhaps a linker warning is possible. + + IRC, freenode, #hurd, 2011-08-20: + + < youpi> jkoenig: I was considering renaming the fields of siginfo + < youpi> to catch applications which need those which we haven't + yet + < jkoenig> youpi, makes sense AFAICT + < youpi> one issue we'll get is some application which previously + built without SA_SIGINFO, and will now want some information + we're not yet able to provide + < youpi> but at least we'll know + < jkoenig> youpi, yes it would still be better than having them + crash at runtime because of it + + IRC, freenode, #hurd, 2011-08-21: + + < youpi> jkoenig: actually we need the fields for waitid + + * The FPU state is not included in the `ucontext_t` passed to the signal + handler. On the other hand, `ucontext_t` is actually being somewhat + deprecated: the functions to restore it are no longer in POSIX. + `thread_get_state`() should return this information, in case we decide + to fill the gap, and there might be existing glibc wrappers, too. + + * Perhaps have a look at `SA_NOCLDWAIT`. + + +### Port OpenJDK + +As suggested by [[tschwinge]], I have targeted OpenJDK 7 at first. +I don't expect it will be too hard to backport my patches to OpenJDK 6. +I have succeeded in building a working JIT-less ("zero") version, +although the dynamic linker issue must be worked around. +Porting Hotspot (the original just-in-time compiler of OpenJDK) +should not be too hard. +If that fails we can fall back on Shark +(a portable alternative JIT which uses LLVM). + +Complexity of porting HotSpot: probably low. The complex things should be +arch- rather than OS-specific. Not many Linux-specific interfaces used. +Garbage collection/memory management, etc. and/or most of other Linux-specific +interfaces are already dealt with for the zero build. + +The dynamic linker issue is as follows. +An executable-specific search path can be provided in the ELF RPATH header. +RPATH directories can include the special string `$ORIGIN`, +which is to be expanded to the directory the executable was loaded from. +OpenJDK's `java` command uses this feature to locate +the right `libjli.so` at runtime. +However, +on Hurd this information is not available to the dynamic linker +and as a consequence RPATH components which include `$ORIGIN` +are silently discarded. + +This can be worked around by defining +the `LD_ORIGIN_PATH` environment variable. +(which have I used to build and test OpenJDK so far.) + +IRC, freenode, #hurd, 2011-07-27: + + < jkoenig> if you have the latest hurd/libc in my repository, you should be + able to run /usr/lib/jvm/java-7-openjdk/bin/java without defining + LD_ORIGIN_PATH manually + < braunr> java: error while loading shared libraries: libjli.so: cannot + open shared object file: No such file or directory + < jkoenig> braunr, this one is expected, it's the symlink problem. + < braunr> oh ok + < jkoenig> (ie. thus far, if java is accessed as /usr/bin/java, the ld + origin ends up as /usr/bin) + + < jkoenig> *sigh*... it seems I'm going to have to reimplement realpath() + in elf/dl-origin.c. + < braunr> why ? + < jkoenig> using it from there results in duplicate symbols when linking + elf/librtld.map.o + < braunr> from where ? + < braunr> dl-origin ? + < jkoenig> apparently this part of the code uses a different allocator + (elf/dl-minimal.c) + < braunr> oh + < braunr> depndency issues ? + < braunr> or bootstrapping ones ? + < jkoenig> http://paste.debian.net/124310/ + < jkoenig> dl-origin is what provides the $ORIGIN value for RPATH (now + sysdeps/mach/hurd/dl-origin.c, in our case) + < braunr> but what's the problem ? + < braunr> what prevents you from using the existing implementation ? + < jkoenig> you mean copy-and-paste the code ? Well I'll end up doing that I + guess... not that it feels right. + < braunr> not really + < braunr> link against what provides it + < braunr> i'm really not familiar with glibc :/ + < jkoenig> also I'd like to understand what's happening precisely before I + resort to such blasphemy :-) + < braunr> :) + < jkoenig> maybe I could make {file,exec,_hurd}_exec_file_name() + canonicalize it instead. + < jkoenig> for some reason it does not feel right, though. + < braunr> why ? + < jkoenig> I'm not sure, loss of information maybe? + < jkoenig> (that I ran /usr/bin/java as opposed to /usr/lib/jvm/...) + < braunr> i guess you should explain the issue more clearly, i feel like + there is something i'm really missing :/ + < braunr> but it can wait + < jkoenig> that ld.so actually needs the canonical file name to substitute + $ORIGIN is its own problem, not that of exec or _hurd_exec_file_name.. + < jkoenig> Ok, so.. Initially the shell (indirectly) runs + _hurd_exec_file_name(..., "/usr/bin/java", ...), which then calls + file_exec_file_name() on the file in question, passing it its own + filename + < jkoenig> which is transmitted to exec_exec_file_name() + < jkoenig> (until now it's all pochu's patch) + < jkoenig> which then makes it available to the newly created process + through exec_startup_get_info_2() (my own addition) + < braunr> oh + < braunr> wasn't it available before oO ? + < jkoenig> no, exec only has access to a port to the executable file. + < braunr> how was argv[0] handled then ? + < jkoenig> argv[0] is handled like any other argument + < braunr> ok, so the file path is duplicated ? + < jkoenig> the shell (or whomever calls _hurd_exec) provide whatever they + want. + < braunr> ok + < jkoenig> well argv[0] is not necessarily the file path (at least not the + full path) + < braunr> right + < jkoenig> so exec() does some guesswork with $PATH but obviously that's + limited. + < braunr> so what you changed is that get_info_2 now receives a canonical + path ? + < jkoenig> right + < jkoenig> (or whatever was specified to _hurd_exec_file_name(), for this + reason and others we shouldn't use it for setuid programs.) + < jkoenig> well, not a canonical path. A path. (hence the problem) + < braunr> ok + < jkoenig> now both the filesystem and exec might run under another root so + they're not an option for canonicalization + < jkoenig> _hurd_exec_file_name (in libc) might be a better spot. + < braunr> resolution from the client, yes + +IRC, freenode, #hurd, 2011-08-03: + + < jkoenig> so my RPATH patches are polished and built, and I'll post them + soon, is the good news + +IRC, freenode, #hurd, 2011-08-17: + + < jkoenig> also fixed a fakeroot-induced deadlock in my dl-origin patches + (namely, under fakeroot, realpath() uses a socket (through stat), so we + need to use it when _hurd_dtable_lock is not held) + < jkoenig> also I'll post my dl-origin patches shortly + < youpi> dl-origin is about the environment variable that java needs, + right? + < jkoenig> about the environment variable it shouldn't need, yes :-) + < youpi> ah :) + < youpi> but ok, I vaguely remember what that refers to + < jkoenig> $LD_ORIGIN_PATH is used as an override (much like + LD_LIBRARY_PATH), but ideally ld.so uses whatever directory the loaded + binary is from. + < youpi> ok + < jkoenig> (as a substitution for $ORIGIN in RPATH) + + +#### Plans + +I intend to fix the RPATH issue +by building on [[pochu]]'s `file_exec_file_name()` +[patches](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00023.html). + +I have succeeded in building a Hotspot-enabled `libjvm.so`, +although the current toolchain issues +([[toolchain/ELFOSABI_GNU]]; 2011-07-03: fix committed in binutils) +have so far prevented me from testing it. + +> It turns out the build fails later on in `hotspot/agent` +> because Hurd lack a `libthread_db.so`. +> Also, a Shark version builds, but the result does not work so far. +> +> In other news, Damien Raude-Morvan is +> [working on a kFreeBSD version](http://lists.debian.org/debian-java/2011/06/msg00124.html), +> so I intend to merge my current patches with his. +> +> --[[jkoenig]] 2011-06-29 + +IRC, freenode, #hurd, 2011-08-03: + + < jkoenig> and I'm battleing to update my OpenJDK patches to b147, and + merge the with the kFreeBSD ones. + < braunr> b147 ? + < jkoenig> but that thing is seriously huge and touches about everything, + so it's taking more time than I'd have hoped + < jkoenig> braunr, the latest release of IcedTea / OpenJDK 7 and the + current Debian version (in experimental of course) + < braunr> ok + < jkoenig> I'm trying to make this clean so that hopefully we can get them + integrated at some level of upstream (probably IcedTea, at least at + first) + +IRC, freenode, #hurd, 2011-08-10: + + < jkoenig> well actually I've finished merging my patches with the freebsd + ones, and updating them to the new openjdk-7, + < jkoenig> but now a new version of both is out :-P + + +##### Upstream Submission + +On 2011-07-15, *gnu_andrew* talked to us in the #hurd channel (freenode IRC), +who is a maintainer of IcedTea. He's supportive of the porting approach, and +is willing to review and integrate small patches for individual issues (rather +than some huge patchset). Send patches to <distro-pkg-dev@openjdk.java.net>. + +##### Open Items + + * [!] [[tschwinge]] to have a look at [[pochu]]'s `file_exec_file_name()` + patches, whether it's generally the right idea. + + * Assuming it is, continue with getting `$ORIGIN` working. + + * `libthread_db.so` issue. Likely, the Serviceability Agent is used by jdb + and the like only, so for now the goal should be to lose some functionality + by removing/avoiding this dependency. + + * [[java-access-bridge]] (not critical; JVM appears to work without) + + * IRC, freenode, #hurd, 2011-07-27: + + < jkoenig> there's a bug with java.nio when running javadoc, you might + run into it. + + * [[`SCM_CREDENTIALS`|open_issues/sendmsg/scm_creds]] + + IRC, freenode, #hurd, 2011-08-03: + + < jkoenig> wrt. peer credentials, openjdk also uses file modes for + security, and my guess is that it's sufficient, at least on Hurd, so + I've reduced my priority for this at least in the meantime + + * They seem to have a rather heavy-weight process for such projects: confer + <http://mail.openjdk.java.net/pipermail/announce/2011-January/000092.html>, + for example. Do we need this, too? + + > Probably not. + > My current approach (and Damien's wrt. the kFreeBSD patches) + > is to add preprocessor directives in the Linux code + > to make it more portable. + > --[[jkoenig]] 2011-06-29 + + * Eclipse + + OK for testing -- but I'd very much hope that it *just works* as soon as we + provide the required Java platform. But it may perhaps have some + Linux-specifics (needlessly?) in its basement. Is it available for Debian + GNU/kFreeBSD already? + + +### Java bindings for Mach + +The code is at <http://github.com/jeremie-koenig/hurd-java>. + +[[tschwinge]]'s notes for building with... + + * GCJ installed (due to the current Debian multilib confusion): + + $ tmp1=/usr/lib/gcc/i486-gnu/4.6 tmp2=/usr/lib/i386-gnu/gcc/i486-gnu/4.6 LIBRARY_PATH=$tmp2 COMPILER_PATH=$tmp1:$tmp2 C_INCLUDE_PATH=$tmp1/include make + + * OpenJDK installed (to have it find the shared library, and the jni.h header + file): + + $ jdk=/usr/lib/jvm/java-7-openjdk LD_LIBRARY_PATH=$jdk/jre/lib/i386/jli C_INCLUDE_PATH=$jdk/include make + +Doxygen-generated documentation is available at +<http://jk.fr.eu.org/hurd-java/doc/html/>; or run `make doc` yourself. + +IRC, freenode, #hurd, 2011-07-27: + + < jkoenig> I need to be able to read/write individual data items from + messages, in order to implement deallocation correctly, so I'm working on + that when I'm waiting for things to build, but it's not my primary focus + right now. + +IRC, freenode, #hurd, 2011-08-17: + + < jkoenig> so, weekly status report: I have made some progress on the java + bindings, I hope to have a safe version mach_msg soon, after which I can + begin experimenting with mig. + + +#### Plans + +(just started.) + + +##### Open Items + + * [[tschwinge]] has to read about RMI and CORBA. + + * MIG + + * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult. + + * (Unless you want to make MIG's own code (that is, not the generated + code, but MIG itself) look a bit more nice, too.) ;-) + + * There are also alternatives to MIG. If there is interest, the following + could be considered: + + * FLICK ([[!GNU_Savannah_task 5723]]). [[tschwinge]] has no idea yet if + there would be any benefits over MIG, like better modularity (for the + backends)? If we feel like it, we could spend a little bit of time on + this. + + * For [[microkernel/Viengoos]], Neal has written a RPC stub generator + entirely in C Preprocessor macros. While this is obviously not + directly applicable, perhaps we can get some ideas from it. + + * Anything else that would be worth having a look at? (What are other + microkernels using?) + + * `mach_msg` + + * Seems like the right approach to [[tschwinge]], but he hasn't digested + all the pecularities yet. Will definitely need more time. + + +## Postponed + +Might get back to these as time/interest permits. + + +### GCJ + + * [[tschwinge]] has the feeling that Java in GCC (that is, GCJ) is mostly + dead? (True?) + + * Thus perhaps not too much effort should be spent with it. + + If the POSIX threads signal semantics makes it going, then great, otherwise + we should get a feeling what else is missing. + + +### Joe-E. diff --git a/user/jkoenig/java/discussion.mdwn b/user/jkoenig/java/discussion.mdwn new file mode 100644 index 00000000..352f6d62 --- /dev/null +++ b/user/jkoenig/java/discussion.mdwn @@ -0,0 +1,559 @@ +[[!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]] + + +# General + +Some [[tschwinge]] comments regarding your proposal. Which is very good, if I +may say so again! :-) + +Of course, everyone is invited to contribute here! + +I want to give the following methodology a try, instead of only having +email/IRC discussions -- for the latter are again and again showing a tendency +to be dumped and deposited into their respective archives, and be forgotten +there. Of course, email/IRC discussions have their usefulness too, so we're +not going to replace them totally. For example, for conducting discussions +with a bunch of people (who may not even be following these pages here), email +(or, as applicable, the even more interactive IRC) will still be the medium of +choice. (And then, the executive summary should be posted here, or +incorporated into your proposal.) + +Also, if you disagree with this suggested procedure right away, or at some +later point begin to feel that this thing doesn't work out, or simply takes too +much time (I don't think so: writing emails takes time, too), just say so, and +we can reconsider. + +Of course, as this wiki is a passive medium rather than an active one as IRC +and email are, it is fine to send notices like: *I have updated the wiki page, +please have a look*. + +One idea is that your proposal evolves alongside with the ongoing work, and +represents (in more or less detail) what has been done and what will be done. +Also, we can hopefully use parts of it for documentation purposes, or as +recipes for similar work (enabling other programming languages on the Hurd, for +example). + +For this, I suggest the following procedure: as applicable, you can either +address any comments in here (for example, if they're wrong :-), or if they +require further discussion; think: *email discussion*), or you can address them +directly in your propoal and remove the comments from here at the same time +(think: *bug fix*). + +Generally, you can assume that for things I didn't comment on (within some +reasonable timeframe/upon asking me again) that I'm fine with them. Otherwise, +I might say: *I don't like this as is, but I'll need more time to think about +it.* + +There is also a possibility that parts of your proposal will be split off; in +cases where we think they're valuable to follow, but not at this time. (As you +know, your proposal is not really a trivial one, so it may just be too much for +one person's summer.) Such bits could be moved to [[open_issues]] pages, +either new ones or existing ones, as applicable. + + +# GSoC Site Discussion + + * Discussion items from + <http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/jkoenig/1> + should be copied here: + + * technical bits (obviously); + + * also the *why do we want Java bindings* reasoning; + + * CLISP findings should also be documented somewhere permanently. + + * We should probaby open up a *languages for Hurd* section on the web + pages ([[!taglink open_issue_documentation]]). + + +# Java Native Interface (JNI) + + * <http://en.wikipedia.org/wiki/Java_Native_Interface> + * <http://download.oracle.com/javase/7/docs/technotes/guides/jni/> + * <http://java.sun.com/products/jdk/faq/jnifaq.html> + * <http://java.sun.com/docs/books/jni/> + + +## Java Native Access (JNA) + + * <http://jna.java.net/> + * <https://github.com/twall/jna#readme> + +This is a different approach, and *while some attention is paid to performance, +correctness and ease of use take priority*. + +As we plan on only having a few native methods (for invoking `mach_msg`, +essentially), JNA is probably the wrong approach: portability and ease of use +is not important, but performance is. + +## Compiled Native Interface (CNI) + + * <http://gcc.gnu.org/onlinedocs/gcj/About-CNI.html> + * <http://per.bothner.com/papers/UsenixJVM01/CNI01.pdf> + +Probably faster than JNI, but only usable with GCJ. + +> Given that we have very few JNI calls, +> it might be interesting to take a "dual" approach +> if CNI actually improves performance +> when compiling to native code. +> --[[jkoenig]] 2011-07-20 + +# IRC, freenode, #hurd, 2011-07-13 + +[[!tag open_issue_documentation]] + + <jkoenig> Yes, I guess so. Maybe start investigating mig because it may + have repercussions on what the best approach would be for some aspects of + the Mach bindings. + <tschwinge> I still think that making MIG emit Java code is not too + difficult, once you have the required Java infrastructure (like what + you're writing at the moment). + <tschwinge> On the other hand, if there's another approach that you'd like + to use, I'm not trying to force using MIG. + <braunr> i still have a problem understanding your approach + <braunr> at which level are your bindings located ? + <jkoenig> I expect mig it will be the easiest route, but of course possibly + it won't. + <tschwinge> jkoenig: Yeah, be give some high-level to low-level overview? + <jkoenig> ok, so + <jkoenig> at the very core, low-level, we have a very thin amount of JNI + code to access (proper) system calls. + <jkoenig> by "proper" I mean things like mach_task_self, mach_msg and + mach_reply_port, which are actually system calls rather than RPCs to the + kernel. + <braunr> right + <jkoenig> at this level, we manipulate port names as integers, and the + message buffers for mach_msg are raw ByteBuffers (from the java.nio + package) + <jkoenig> actually, so-called /direct/ ByteBuffers, which are backed by + memory allocated outside of the Java heap, rather than as a byte[] array + <jkoenig> we can retreive the pointer from the JNI code and use the buffer + directly. + <jkoenig> (so, good for performance and it's also portable.) + <braunr> ok + <braunr> i'm more interested in the higher level bindings :) + <jkoenig> ok so, higher up. + <jkoenig> design goal from my proposal: "the memory safety of Java should + be maintained and extended to Mach primitives such as port names and + out-of-line memory regions" + <jkoenig> so integer port names are not "safe" in the sense that they can + be forged and misused in all kinds of way + <jkoenig> which is why I have a layer of Java code whose job is to wrap + this kind of low-level Mach stuff into safe abstractions + <jkoenig> and ideally the user should only use these safe abstractions. + <tschwinge> (Not to restrict the programmer, but to help him write correct + code.) + <jkoenig> right. + <braunr> so you can't use mach RPCs directly + <jkoenig> tschwinge, also to actually restrict them, in a Joe-E / + object-capability context, but that's not the primary concern right now + ;-) + <braunr> or you force your wrappers to have these abstractions as input + <jkoenig> braunr, well, actually at this level you still have Mach RPC + <jkoenig> but for instance, port names are encapsulated into "MachPort" + objects which ensure they are handled correcly + <tschwinge> As I understand it, you use these abstractions to prepare a + usual mach_msg message, and then invoke mach_msg. + <braunr> ok + <jkoenig> and message buffers are wrapped into "MachMsg" objects which both + help you write the messages into the ByteBuffer and prevent you from + doing funky stuff + <jkoenig> and ensure the ports which you send/receive/pseudo-receive after + an error/... are deallocated as required, etc. + <braunr> what's the interface to use IPC ? + <tschwinge> Is MIG doing that, too, I think? (And antrik once found some + error there, which is still to be reviewed...) + <jkoenig> braunr, so basically as a user you would be free to use either + one of these layers, or to use MIG-generated classes which would + construct and exchange messages for you using the second (safe) layer. + <braunr> ok, let's just finish with the low level layer before going + further please + <jkoenig> tschwinge, MIG does some type checking on the received message + and saves you the trouble of constructing/parsing them yourself, but I'm + not sure about how mach_msg errors are handled + <braunr> what are the main methods of MachMsg for example ? + <jkoenig> braunr, you may want to have a look at + http://jk.fr.eu.org/hurd-java/doc/html/classorg_1_1gnu_1_1mach_1_1MachMsg.html + <braunr> right, sorry + <braunr> grabbed the code at work and forgot here + <jkoenig> and also + https://github.com/jeremie-koenig/hurd-java/blob/master/HelloMach.java + which uses it + <jkoenig> but roughly, you'd use setRemotePort, setLocalPort, setId to + write your message's header + <jkoenig> then use one of the putFoo() methods to add data items to the + message + <braunr> ok, the mapping with the low level C interface is very clear + <braunr> that's good for me + <jkoenig> the putFoo() methods would write the appropriate type + descriptors, then the actual data. + <braunr> we can go on with the MiG part if you want :) + <jkoenig> right, + <jkoenig> so here you may want to look at the UML class diagram from + http://www.bddebian.com/~hurd-web/user/jkoenig/java/proposal/ + <jkoenig> so in the C case, mig generates 3 files + <jkoenig> a header file which has the prototypes of the mig-generated + stubs, + <jkoenig> a *User.c which has their actual implementation + <jkoenig> and a *Server.c which handles demultiplexing the incoming + messages and helps with implementing servers. + <jkoenig> so we would do something along these lines, more or less: + <jkoenig> mig would generate the code for a Java interface in lieu of the + *.h file. + <jkoenig> a generated FooUser class would implement this interface by doing + RPC + <jkoenig> (so basically you would pass a MachPort object to the + constructor, and then you could use the resulting object to do RPC with + whatever is on the other end) + <jkoenig> and the generated FooServer class would do the opposite, + <braunr> ok + <braunr> issues with threads ? + <jkoenig> you would pass an object implementing the Foo interface to the + constructor, + <braunr> i'm guessing the demux part may have to create threads, right ? + <jkoenig> and the resulting object would handle messages by using the + object you passed. + <jkoenig> braunr, right, so that would be more a libports kind of code, + <braunr> the libports-like library, i see + <jkoenig> to which you could pass Server objects (for instance the + FooServer above), and it would handle incoming messages. + <braunr> how is message content mapped to a java interface ? + <jkoenig> this would be determined from the .defs files and MIG would + generate the appropriate code, hopefully. + <braunr> so the demux part would handle rpc integer identifiers ? + <jkoenig> right. + <braunr> but hm + <jkoenig> also mapping .defs files to Java interfaces might prove to be + tricky. data types conversion and all + <antrik> tschwinge: my mamory is rather hazy. IIRC the issue was that the + MIG-generated stubs deallocate out-of-line port arrays after the + implementation returns, before returning to the dispatcher + <braunr> i'll just overlook this specific implementation detail + <jkoenig> but we could use some annotation-based system if we need to + provide more information to generate the java code. + <antrik> but the Hurd (or rather glibc) RPC handling also automatically + deallocates everything if an error occurs + <antrik> so I changed the MIG code to deallocate only when no error occurs + <braunr> jkoenig: ok, we'll talk about that when there is more progress and + you have a better view of the problem + <antrik> at that time I was pretty sure that this is a correctly working + solution, but it always seemed questionable conceptually... however, I + wasn't able to come up with a better one, and nobody else commented on it + <braunr> antrik: shouldn't the hurd be changed not to deallocate something + it didn't allocate in the first place ? + <antrik> braunr: no, the server has to deallocate stuff before returning to + the client. the request message is destroyed before returning the reply. + <tschwinge> jkoenig, braunr: That's what I had in mind where MIG might be a + bit awkward. Then we can indeed either add annotations to the .defs + files, or reproduce them in some other format. That's some work, but + it's mostly a one-time work. + <tschwinge> After all, the RPC interface is a binary one, and there may be + more than one API for creating these messages, etc. + <antrik> jkoenig: actually, at least in the Hurd, server-side and + client-side headers are separate -- so MIG actually creates four files + <jkoenig> tschwinge, wrt to annotations I was more thinking about Java + ones, such as: @MIGDefsFile("mach/task.defs") @MIGCType("task_t") public + interface Task { } + <jkoenig> antrik, oh, ok, it makes sense. + <braunr> jkoenig: anything else ? + <jkoenig> braunr, nothing that I can think of + <braunr> ok + <antrik> tschwinge: I think it would be a *very* bad idea to introduce + redundancy regarding RPC definitions + <braunr> thanks for the tour :) + <antrik> (the _request.defs/_reply.defs mess is bad enough...) + <jkoenig> did I speak about the "Unsafe" pseudo-exception? that's + interesting :-) + <tschwinge> jkoenig: Also, virtual memory abstractions? + <braunr> jkoenig: you didn't + <tschwinge> antrik: Well, then we could create some other super-format. + But that's just a detail IMO. + <jkoenig> ok, so wrt virtual memory, a page we received can be wrapped with + some JNI help into a (direct) ByteBuffer object. + <jkoenig> deallocating sent pages will be tricky, though. + <tschwinge> antrik: To put it this way: for me the .defs files are just one + way of expressing the RPC interfaces' contracts. (At the same time, they + happen to be the actual reference for these, too. But the specification + itself could just as well be a textual one.) + <jkoenig> on approach I've been thinking about would be to "wrap" the + ByteBuffer object into an object which has the sole reference to it, so + that when it's deallocated the reference can be replaced with "null", and + further attempts to access the buffer would throw exceptions. + <braunr> sounds reasonable + <jkoenig> but that's still in flux in my head, we may end up needing our + own implementation of ByteBuffer-like objects. + <tschwinge> The problem being that there is no mechanism to ``revoke'' an + object once a reference to it has been shared. + <jkoenig> right. + <tschwinge> A wrapper is one possibility indeed. + <antrik> tschwinge: they are called interface *definitions* for a reason + :-) + <tschwinge> This is a very similar problem as with capabilities when there + is no revoke operation for these, too. + <tschwinge> antrik: Yes, because they define MIG's input. :-P + <tschwinge> Isn't that what is called a membrane in the capability world? + <antrik> I do not say that we have to consider the format of the .defs to + be set in stone; but I do insist on using a canonical machine-parsable + source for all language bindings + <tschwinge> attenuation + <jkoenig> tschwinge, you mean the revokable proxy contruct ? (It's the same + principle indeed) + <tschwinge> A common design pattern in object-capability systems: given + one reference of an object, create another reference for a proxy object + with certain security restrictions, such as only permitting read-only + access or allowing revocation. The proxy object performs security checks + on messages that it receives and passes on any that are allowed. Deep + attenuation refers to the case where the same attenuation is applied + transitively to any + <tschwinge> objects obtained via the original attenuated object, + typically by use of a "membrane". + <tschwinge> http://en.wikipedia.org/wiki/Object-capability_model + <tschwinge> Yes. + <tschwinge> Good. I understood something. ;-) + <tschwinge> antrik: OKAY! :-P + <tschwinge> jkoenig: And hopefully the JVM will optimize away all the + additional indirection... :-D + <tschwinge> jkoenig: Is there anything more to say about the VM layer? + <jkoenig> tschwinge, "hopefully", yes :-) + <tschwinge> Like, the data that I'm sharing -- is it untyped, isn't it? + <jkoenig> tschwinge, you mean that within the received/sent pages ? + <tschwinge> Yes. + <tschwinge> But that'S how it is, indeed. + <jkoenig> well actually the type descriptor should indicate what they + contain. + <tschwinge> I cannot trust anything I receive from externally. + <jkoenig> it's most often used for MACH_MSG_TYPE_CHAR items I guess, and it + will be type checked when retreive + <tschwinge> Yeah, and that then just *is* arbitrary data, like a block read + from a disk file. + <jkoenig> you would have something like: ByteBuffer + MachMsg.getBuffer(MachMsg.Type expected), and MachMsg would check the + type descriptor against that which you specified + <tschwinge> Or a packet transmitted over the network. + <tschwinge> OK, yes. + <antrik> jkoenig: in theory ints should be used quite often too. the whole + purpose of the type descriptors is to allow byte order swapping when + messages are passed between hosts with different architecture... + <jkoenig> tschwinge, right, except for out-of-line port arrays, which need + to be handled differently obviously. + <antrik> (which is totally irrelevat for our purposes -- especially since + the actual network IPC code doesn't exist anymore ;-) ) + <jkoenig> antrik, oh, interesting + <tschwinge> Yes, that was one original idea. + <jkoenig> actually my litmus test for what the bindings should be, is you + should be able to implement such a proxy in Java :-) + <tschwinge> antrik: And hey, you now have processors that can switch + between different modes during runtime... :-) + <jkoenig> (although arguably that's a little bit ambitious) + <braunr> tschwinge: there should be bits in page tables to indicate the + endianness to use on a page .. :) + <tschwinge> Hehe! + <tschwinge> jkoenig: Don't worry -- you're already known for ambitious + projects. One more can't hurt. + <jkoenig> Also, actually the word size is not something that I've been able + to abstract so far, so I'll be hardcoding little-endian 32 bits for now. + <braunr> why is that ? + <antrik> some of the Hurd RPC break the idea anyways BTW + <jkoenig> the org.vmmagic package (from Jikes RVM and JNode) could help + with that, but GCJ does not support it unfortunately (not sure about + OpenJDK) + <jkoenig> braunr, Java does not allow us to define new unboxed types + <braunr> jkoenig: does it have its own definition of the word size ? + <jkoenig> braunr, nope. + <jkoenig> (although, maybe, and also we could use JNI to query it) + <braunr> even if virtual, i'd expect a machine to have such a defnition + <jkoenig> braunr, maybe it has, but basically in Java nothing depends on + the word size + <jkoenig> 'int' is 32 bits, 'long' is 64 and that's it. + <braunr> oh right, i remember most types are fixed size, right ? + <jkoenig> right. + <braunr> if not all + <jkoenig> now Jikes RVM's "org.vmmagic" provides an interface to defined + new unboxed types which can depend on the actual word size, but Jikes RVM + is its own JVM so obviously they can use and provide whatever extensions + they need :-) + <jkoenig> (but maybe they've implemented them in OpenJDK for bootstrap + purposes, I'm not sure) + <tschwinge> I'm missing this detail: where does the word size come into + play here? + <jkoenig> anyway, I _could_ indiscriminately use 'long' for port names, and + sparkle the code with word size tests but that would be very clumsy + <braunr> jkoenig: port names are actually ints :/ + <jkoenig> tschwinge, the actual format of the message header and type + descriptors, for instance. + <braunr> jkoenig: ok, got your point + <jkoenig> braunr, by 'long' I mean 64-bits integers (which they are on + 64-bits machines I think?) + <braunr> :) + <braunr> jkoenig: port names are as large as the word size + <braunr> but in C at least, they're int, not long + <braunr> it doesn't change many things, but you get lots of warnings if you + try with a long :) + <tschwinge> What is the reason that port names are an + architecture-dependent word size's width, and not simply 32 bit? + <jkoenig> "4 billions of port names should be enough for everyone" :-) + <braunr> tschwinge: an optimization is to use them as pointers in the + kernel + <antrik> tschwinge: the machine's native word size is what it can process + most efficiently, and what should be used for most normal + operations... it makes sense to define stuff as int, except for network + communication + <tschwinge> jkoenig: Well, yeah, but if you want to communicate with a + peer, you have to agree on the maximum number anyway (not for port names, + though, which are local). + <braunr> antrik: int isn't the word size everywhere + <braunr> antrik: the most common type matching the word size is long, at + least on ILP32/LP64 data models + <antrik> braunr: that's just because some idiots assumed int would always + be 32 bits, and consequently when 64 architectures came up the compiler + guys chickened out ;-) + <braunr> without int, you wouldn't have a 32 bits type + <antrik> that's not true for all architectures and/or operating systems + though AFAIK + <braunr> or a 16 bits one + <braunr> antrik: windows guys got even more scared, so windows 64 is LLP64 + <antrik> BTW, I haven't checked, but it's quite possible that 32 bit + numbers are actually preferable even on AMD64... + <tschwinge> jkoenig: So, back on track. :-) + <tschwinge> jkoenig: You didn't find anything yet in Mach's VM interfaces + as well a MemoryObject, etc., that can't be used/implemented in the Java + world? + <braunr> antrik: they consume less memory, but don't have much effect on + performance + <jkoenig> tschwinge, once we have the basic system calls and the + corresponding abstractions in place, I don't think anything else + fundamentally problematic could possibly show up + <antrik> braunr: if you really *need* a type of a certain bit size, you + should use stdint types. so not having a 16 or 32 bit type in the + short/int/long canon is *not* an excuse + <tschwinge> jkoenig: That speaks for the Mach designers! + <braunr> antrik: right + <jkoenig> tschwinge, on trick is that for instance, mach_task_self would + still be unsafe even if it returned a nicely wrapped Task object, because + you could still wreck your own address space and threads with it. So we + would need the "attenuation" pattern mentionned above to provide a safe + one. + <jkoenig> (which would disallow thinks such as the port/thread/vm calls) + <braunr> jkoenig: you mentioned the unsafe pseudo exception earlier + <jkoenig> braunr, right, so the issue is with distinguishing safe from + unsafe methods + <antrik> braunr: BTW, the Windows guys actually broke a lot of stuff by + fixing long at 32 bits -- this way long doesn't match size_t and pointer + types anymore, which was an assumption that was true for pretty much any + system so far... + <tschwinge> jkoenig: Yes. (And again hope for the JVM to optim...) + <braunr> antrik: that's right :) + <braunr> antrik: that's LLP64 + <braunr> antrik: long long and pointers + <jkoenig> braunr, so basically the idea is that unsafe methods are declared + as "throws Unsafe" + <jkoenig> the effect is that if you use such a method you must either + "throw Unsafe" yourself, + <jkoenig> or if you're building a safe abstraction on top of Unsafe + methods, you'll "catch" the "exception" in question to tell the compiler + that it's okay. + <jkoenig> it's more or less inspired from the "semantic regimes" idea from + the org.vmmagic paper which is referenced in my original proposal, + <jkoenig> only implementing by hijacking the exception checking machinery, + which has a behaviour similar to what we want. + <braunr> ok + <braunr> but hmm this seems pretty normal, what's the tricky part ? :) + <tschwinge> braunr: The idea is that the programmer explicitly has to + acknowledge if he'S using an unsafe interface. + <braunr> tschwinge: sounds pretty normal too + <jkoenig> braunr, the trick is that you would not usually declare + exceptions which are never actually thrown (and actually since the + compiler does not know it's never thrown, I need to work around it in a + few places) + <braunr> oh, ok + <braunr> jkoenig: that's interesting indeed + <jkoenig> braunr, the org.vmmagic paper provides an example which uses some + annotations called @UncheckedMemoryAccess and @AssertSafe to the same + effect (which is kind of cleaner), but it would be a headache to + implement without help from the compiler I think (as far as I can tell + the annotation processor would have to inspect the bytecode) + <braunr> but hm + <braunr> what's the true problem about this ? + <jkoenig> (the paper advocates "high-level low-level programming" and is a + very interesting read I think, + http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.151.5253&rep=rep1&type=pdf, + for what it's worth) + <braunr> what's wrong if you just declare your methods unsafe and don't + alter anything else ? + <tschwinge> Yes, I read it and it is interesting. Unfortunately, it seems + I forgot most of it again... + <jkoenig> braunr, declare? alter? + <jkoenig> you mean just tag them with an annotation? + <braunr> just stating a method "throws Unsafe" + <jkoenig> braunr, well some compiler will output a warning because they can + tell there's no way the method is going to throw such an exception. + <jkoenig> and then some other compiler will complain that my + @SuppressWarnings("unused") does not serve any purpose to them :-) + <jkoenig> also, when initializing final fields, I need to work around the + fact that the compiler thinks "Unsafe" might be thrown. + <jkoenig> see for instance MachPort.DEAD + <braunr> jkoenig: ok + <jkoenig> braunr, but I'm more than willing to accept this in exchange for + a clear, compiler-enforced materialization of the border between safe an + unsafe code. + <jkoenig> actually another question I have is the amount of static typing I + should add to the safe version, for instance should I subclass MachPort + into MachSendRight, MachReceiveRight and so on. I don't want to depart + from the C inteface too much but it could be useful. + <braunr> jkoenig: can't answer that :) + <braunr> jkoenig: keep them in mind for later i think + <tschwinge> jkoenig: What's the safety concern w.r.t. having MachPort (not) + final? + <jkoenig> tschwinge, actually I'm partly wrong in that we only need name() + and a couple other methods to be final + <tschwinge> jkoenig: That's what I was thinking. :-) + <tschwinge> I though I'm missing something here. + <jkoenig> tschwinge, the idea is that the user (ie., the adversary :-) + could extend MachPort and inject their own fake port name into messages + <jkoenig> by overriding name() or clear() + <tschwinge> Yeah, but if these are final, that's not possible. + <jkoenig> right. + <tschwinge> And that *should* be enough, I think. + <tschwinge> Unless I'm missing something. + <jkoenig> I don't think so. Also I hope it is, because as mentionned above + there might be some value in subclassing MachPort. + <tschwinge> Yep. + <jkoenig> incidentally, declaring the class or the method final will allow + the JVM to inline them I think. + <tschwinge> It will help the JVM, yes. It can also figure that out without + final, though. (And may have to de-optimize the code again in case there + are additional classes loaded during run-time.) + <tschwinge> jkoenig: The reference counting in MachPort. I think I'm + beginning to understand this. + <jkoenig> oh ok + <jkoenig> tschwinge, yes the javadoc is maybe a bit obscure so far. + <jkoenig> but basically you don't want the port name you acquire to become + invalid before you're done using it. + <tschwinge> But how is this different from the C world? + <jkoenig> here my goal is to provide some guarantees if you use only safe + methods + <jkoenig> like, you can't forge a port name and things like that + <jkoenig> so basically it should never be possible to include an invalid + port name in a message if you use only safe methods. + <tschwinge> Ah, I see! + <tschwinge> Now that does make sense. + <jkoenig> but the mechanism in itself is similar to the Hurd port cells and + user_link structures + <tschwinge> It's again ``only'' helping the programmer. + <jkoenig> right, no object-capability ulterior motives :-) + <jkoenig> another assumption which the javadoc does not state yet it that + basically there should be exactly one MachPort object for each mach-level + port name reference (in the sense of mach_port_mod_refs) + <tschwinge> Yes, I figured out that bit. diff --git a/user/jkoenig/java/java-access-bridge.mdwn b/user/jkoenig/java/java-access-bridge.mdwn new file mode 100644 index 00000000..57c87068 --- /dev/null +++ b/user/jkoenig/java/java-access-bridge.mdwn @@ -0,0 +1,92 @@ +[[!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_porting]] + +Debian's *openjdk-7-jre* package depends on *libaccess-bridge-java-jni* (source +package: *java-access-bridge*). + +The latter one has *openjdk-6-jdk* as a build dependency, but that can be +hacked around: + + # ln -s java-7-openjdk /usr/lib/jvm/java-6-openjdk + +Trying to build it: + + $ LD_LIBRARY_PATH=/usr/lib/jvm/java-7-openjdk/jre/lib/i386/jli dpkg-buildpackage -b -uc -d + [...] + make[3]: Entering directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2/idlgen' + /usr/lib/jvm/java-6-openjdk/bin/idlj \ + -pkgPrefix Bonobo org.GNOME \ + -pkgPrefix Accessibility org.GNOME \ + -emitAll -i /usr/share/idl/bonobo-activation-2.0 -i /usr/share/idl/at-spi-1.0 -i /usr/share/idl/bonobo-2.0 \ + -fallTie /usr/share/idl/at-spi-1.0/Accessibility.idl + /usr/share/idl/at-spi-1.0/Accessibility_Collection.idl (line 66): WARNING: Identifier `object' collides with a keyword; use an escaped identifier to ensure future compatibility. + boolean isAncestorOf (in Accessible object); + ^ + /usr/share/idl/at-spi-1.0/Accessibility_Component.idl (line 83): WARNING: Identifier `Component' collides with a keyword; use an escaped identifier to ensure future compatibility. + interface Component : Bonobo::Unknown { + ^ + Exception in thread "main" java.lang.AssertionError: Platform not recognized + at sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:71) + at java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:108) + at java.nio.file.FileSystems$DefaultFileSystemHolder.access$000(FileSystems.java:89) + at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:98) + at java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:96) + at java.security.AccessController.doPrivileged(Native Method) + at java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:95) + at java.nio.file.FileSystems$DefaultFileSystemHolder.<clinit>(FileSystems.java:90) + at java.nio.file.FileSystems.getDefault(FileSystems.java:176) + at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:489) + at sun.util.calendar.ZoneInfoFile$1.run(ZoneInfoFile.java:480) + at java.security.AccessController.doPrivileged(Native Method) + at sun.util.calendar.ZoneInfoFile.<clinit>(ZoneInfoFile.java:479) + at sun.util.calendar.ZoneInfo.getTimeZone(ZoneInfo.java:658) + at java.util.TimeZone.getTimeZone(TimeZone.java:559) + at java.util.TimeZone.setDefaultZone(TimeZone.java:656) + at java.util.TimeZone.getDefaultRef(TimeZone.java:623) + at java.util.TimeZone.getDefault(TimeZone.java:610) + at java.text.SimpleDateFormat.initializeCalendar(SimpleDateFormat.java:682) + at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:619) + at java.text.DateFormat.get(DateFormat.java:772) + at java.text.DateFormat.getDateTimeInstance(DateFormat.java:547) + at com.sun.tools.corba.se.idl.toJavaPortable.Util.writeProlog(Util.java:1139) + at com.sun.tools.corba.se.idl.toJavaPortable.Skeleton.writeHeading(Skeleton.java:145) + at com.sun.tools.corba.se.idl.toJavaPortable.Skeleton.generate(Skeleton.java:102) + at com.sun.tools.corba.se.idl.toJavaPortable.InterfaceGen.generateSkeleton(InterfaceGen.java:159) + at com.sun.tools.corba.se.idl.toJavaPortable.InterfaceGen.generate(InterfaceGen.java:108) + at com.sun.tools.corba.se.idl.InterfaceEntry.generate(InterfaceEntry.java:110) + at com.sun.tools.corba.se.idl.toJavaPortable.ModuleGen.generate(ModuleGen.java:75) + at com.sun.tools.corba.se.idl.ModuleEntry.generate(ModuleEntry.java:83) + at com.sun.tools.corba.se.idl.Compile.generate(Compile.java:324) + at com.sun.tools.corba.se.idl.toJavaPortable.Compile.start(Compile.java:169) + at com.sun.tools.corba.se.idl.toJavaPortable.Compile.main(Compile.java:146) + make[3]: *** [org/GNOME/Accessibility/Accessible.java] Error 1 + make[3]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2/idlgen' + make[2]: *** [all-recursive] Error 1 + make[2]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2/idlgen' + make[1]: *** [all-recursive] Error 1 + make[1]: Leaving directory `/media/erich/home/thomas/tmp/libaccess-bridge-java-jni/java-access-bridge-1.26.2' + make: *** [debian/stamp-makefile-build] Error 2 + dpkg-buildpackage: error: debian/rules build gave error exit status 2 + + +IRC, freenode, #hurd, 2011-08-10: + + < jkoenig> and with my latest fix (hardwire os.name as "Linux"), + java-access-bridge actually built \o/ + < youpi> I wouldn't call it a "fix" :) + < jkoenig> true, but pretty much everything assumes we're either solaris, + linux or windows :-/ + < jkoenig> also we're actually using the Linux code which it is used to + select throughout the JDK + < jkoenig> if it's any consolation, os.version stays "GNU-Mach + 1.3.99/Hurd-0.3" :-) + < youpi> ideally it should simply be changed to "GNU" diff --git a/user/jkoenig/java/proposal.mdwn b/user/jkoenig/java/proposal.mdwn new file mode 100644 index 00000000..feb7e9dc --- /dev/null +++ b/user/jkoenig/java/proposal.mdwn @@ -0,0 +1,629 @@ +[[!tag stable_URL]] + +# Java for Hurd (and vice versa) + +Contact information: + + * Full name: Jérémie Koenig + * Email: jk@jk.fr.eu.org + * IRC: jkoenig on Freenode and OFTC + +## Introductions + +I am a first year M.Sc. student +in Computer Science at University of Strasbourg (France). +My interests include capability-based security, +programming languages and formal methods +(in particular, object-capability languages and proof-carrying code). + +### Proposal summary + +This project would consist in improving Java support on Hurd. +The first part would consist in +fixing bugs and porting Java-related packages. +The second part would consist in +creating low-level Java bindings for the Hurd interfaces, +as well as libraries to make translator development easier. + +### Previous involvement + +I started contributing to Hurd last summer, +during which I participated to Google Summer of Code +as a student for the Debian project. +I worked on porting Debian-Installer to Hurd. +This project was mostly a success, +although we still have to use a special mirror for installation +with a few modified packages +and tweaked priorities +to work around some uninstallable packages +with Priority: standard. + +Shortly afterwards, +I rewrote the procfs translator +to fix some issues with memory leaks, +make it more reliable, +and improve compatibility with Linux-based tools +such as `procps` or `htop`. + +Although I have not had as much time +as I would have liked to dedicate to the Hurd +since that time, +I have continued to maintain the mirror in question, +and I have started to work +on implementing POSIX threads signal semantics in glibc. + +### Project-related skills and interests + +I have used Java mostly for university assignments. +This includes non-trivial projects +using threads and distributed programming frameworks +such as Java RMI or CORBA. +I have also used it to experiment with +Google App Engine +(web applications) +and Google Web Toolkit +(a compiler from Java to Javascript which helps with AJAX code), +and I have some limited experience with JNI +(the Java Native Interface, to link Java with C code). + +My knowledge of the Hurd and Debian GNU/Hurd is reasonable, +as the Debian-Installer and procfs projects +gave me the opportunity to fiddle with many parts of the system. + +Initially, +I started working on this project because I wanted to use +[Joe-E](http://code.google.com/p/joe-e/) +(a subset of Java) +to investigate the potential +[[applications of object-capability languages|objcap]] +in a Hurd context. +I also believe that improving Java support on Hurd +would be an important milestone. + +### Organisational matters + +I am subscribed to bug-hurd@g.o and +I do have a permanent internet connexion. + +I would be able to attend the regular IRC meetings, +and otherwise communicate with my mentor +through any means they would prefer +(though I expect email and IRC would be the most practical). +Since I'm already familiar with the Hurd, +I don't expect I would require too much time from them. + +My exams end on May 20 so I would be able to start coding +right at the beginning of the GSoC period. +Next year's term would probably begin around September 15, +so that would not be an issue either. +I expect I would work around 40 hours per week, +and my waking hours would be flexible. + +I don't have any other plans for the summer +and would not make any if my project were to be accepted. + +Full disclosure: +I also submitted a proposal to the Jikes RVM project +(which is a research-oriented Java Virtual Machine, +itself written in Java) +for implementing a new garbage collector into the MMTk subsystem. + +## Improve Java support + +### Justification + +Java is a popular language and platform used by many desktop and web +applications (mostly on the server side). As a consequence, competitive Java +support is important for any general-purpose operating system. +Better Java support would also be a prerequisite +for the second part of my proposal. + +### Current situation + +Java is currently supported on Hurd with the GNU Java suite: + + * [GCJ](http://gcc.gnu.org/java/), + the GNU Compiler for Java, is part of GCC and can compile Java + source code to Java bytecode, and both source code and bytecode to + native code; + * libgcj is the implementation of the Java runtime which GCJ uses. + It is based on [GNU Classpath](http://www.gnu.org/software/classpath/). + It includes a bytecode interpreter which enables + Java applications compiled to native code to dynamically load and execute + Java bytecode from class files. + * The gij command is a wrapper around the above-mentioned virtual machine + functionality of libgcj and can be used as a replacement for the java + command. + +However, GCJ does not work flawlessly on Hurd.r +For instance, some parts of libgcj relies on +the POSIX threads signal semantics, which are not yet implemented. +In particular, this makes ant hang waiting for child processes, +which makes some packages fail to build on Hurd +(“ant” is the “make” of the Java world). + +### Tasks + + * **Finish implementing POSIX thread semantics** in glibc (high priority). + According to POSIX, signal dispositions should be global to a process, + while signal blocking masks should be thread-specific. Signals sent to the + process as a whole are to be delivered to any thread which does not block + them. By contrast, Hurd has per-thread signal dispositions and signals + sent to a process are delivered to the main thread only. I have been + working on refactoring the glibc signal code and implementing the POSIX + semantics as a per-thread option. However, due to lack of time I have not + yet been able to test and debug my code properly. Finishing this work + would be my first task. + * **Fix further problems with GCJ on Hurd** (high priority). While I’m not + aware of any other problems with GCJ at the moment, I suspect some might + turn up as I progress with the other tasks. Fixing these problems would + also be a high-priority task. + * **Port OpenJDK 6** (medium priority). While GCJ is fine, it is not yet + 100% complete. It is also slower than OpenJDK on architectures where a + just-in-time compiler is available. Porting OpenJDK would therefore + improve Java support on Hurd in scope and quality. Besides, it would also + be a good way to test GCJ, which is used for bootstrapping by the Debian + OpenJDK packages. Also note that OpenJDK 6 is now the default Java + Runtime Environment on all released Linux-based Debian architectures; + bringing Hurd in line with this would probably be a good thing. + * **Port Eclipse and other Java applications** (low priority). Eclipse is a + popular, state-of-the-art IDE and tool suite used for Java and other + languages. It is a dependency of the Joe-E verifier (see part 3 of this + proposal). Porting Eclipse would be a good opportunity to test GCJ and + OpenJDK. + +### Deliverables + + * The glibc pthreads patch and any other fixes on the Hurd side + would be submitted upstream + * Patches against Debian source packages + required to make them build on Hurd would be submitted + to the [Debian bug tracking system](http://bugs.debian.org/). + + +## Create Java bindings for the Hurd interfaces + +### Justification + +Java is used for many applications and often taught to +introduce object-oriented programming. The fact that Java is a +garbage-collected language makes it easier to use, especially for the less +experienced programmers. Besides, its object-oriented nature is a +natural fit for the capability-based design of Hurd. +The JVM is also used as a target for many other languages, +all of which would benefit from the access provided by these bindings. + +Advantages over other garbage-collected, object-oriented languages include +performance, type safety and the possibility to compile a Java translator to +native code and +[link it statically](http://gcc.gnu.org/wiki/Statically_linking_libgcj) +using GCJ, should anyone want to use a +translator written in Java for booting. +Note that Java is +[being](http://www.linuxjournal.com/article/8757) +[used](http://oss.readytalk.com/avian/) +in this manner for embedded development. +Since GCJ can take bytecode as its input, +this expect this possibility would apply to any JVM-based language. + +Java bindings would lower the bar for newcomers +to begin experimenting with what makes Hurd unique +without being faced right away with the complexity of +low-level systems programming. + +### Tasks summary + + * Implement Java bindings for Mach + * Implement a libports-like library for Java + * Modify MIG to output Java code + * Implement libfoofs-like Java libraries + +### Design principles + +The principles I would use to guide the design +of these Java bindings would be the following ones: + + * The system should be hooked into at a low level, + to ensure that Java is a "first class citizen" + as far as the access to the Hurd's interfaces is concerned. + * At the same time, the memory safety of Java should be maintained + and extended to Mach primitives such as port names and + out-of-line memory regions. + * Higher-level interfaces should be provided as well + in order to make translator development + as easy as possible. + * A minimum amount of JNI code (ie. C code) should be used. + Most of the system should be built using Java itself + on top of a few low-level primitives. + * Hurd objects would map to Java objects. + * Using the same interfaces, + objects corresponding to local ports would be accessed directly, + and remote objects would be accessed over IPC. + +One approach used previously to interface programming languages with the Hurd +has been to create bindings for helper libraries such as libtrivfs. Instead, +for Java I would like to take a lower-level approach by providing access to +Mach primitives and extending MIG to generate Java code from the interface +description files. + +This approach would be initially more involved, and would introduces several +issues related to overcoming the "impedance mismatch" between Java and Mach. +However, once an initial implementation is done it would be easier to maintain +in the long run and we would be able to provide Java bindings for a large +percentage of the Hurd’s interfaces. + +### Bindings for Mach system calls + +In this low-level approach, my intention is to enable Java code to use Mach +system calls (in particular, mach_msg) more or less directly. This would +ensure full access to the system from Java code, but it raises a number of +issues: + + * the Java code must be able to manipulate Mach-level entities, such as port + rights or page-aligned buffers mapped outside of the garbage-collected + heap (for out-of-line transfers); + * putting together IPC messages requires control of the low-level + representation of data. + +In order to address these concerns, classes would be encapsulating these +low-level entities so that they can be referenced through normal, safe objects +from standard Java code. Bindings for Mach system calls can then be provided +in terms of these classes. Their implementation would use C code through the +Java Native Interface (JNI). + +More specifically, this functionality would be provided by the `org.gnu.mach` +package, which would contain at least the following classes: + + * `MachPort` would encapsulate a `mach_port_t`. (Some of) its constructors + would act as an interface for the `mach_port_allocate()` system call. + `MachPort` objects would also be instantiated from other parts of the JNI + C code to represent port rights received through IPC. The `deallocate()` + method would call `mach_port_deallocate()` and replace the encapsulated + port name with `MACH_PORT_DEAD`. We would recommend that users call it + when a port is no longer used, but the finalizer would also deallocate the + port when the `MachPort` object is garbage collected. + * `Buffer` would represent a page-aligned buffer allocated outside of the + Java heap, to be transferred (or having been received) as out-of-line + memory. The JNI code would would provide methods to read and write data at + an arbitrary offset (but within bounds) and would use `vm_allocate()` and + `vm_deallocate()` in the same spirit as for `MachPort` objects. + * `Message` would allow Java code to put together Mach messages. The + constructor would allocate a `byte[]` member array of a given size. + Additional methods would be provided to fill in or query the information + in the message header and additional data items, including `MachPort` and + `Buffer` objects which would be translated to the corresponding port names + and out-of-line pointers. + A global map from port names to the corresponding `MachPort` object + would probably be needed to ensure that there is a one-to-one + correspondence. + * `Syscall` would provide static JNI methods for performing system calls not + covered by the above classes, such as `mach_msg()` or + `mach_thread_self()`. These methods would accept or return `MachPort`, + `Buffer` and `Message` objects when appropriate. The associated C code + would access the contents of such objects directly in order to perform the + required unsafe operations, such as constructing `MachPort` and `Buffer` + objects directly from port names and C pointers. + +Note that careful consideration should be given to the interfaces of these +classes to avoid “safety leaks” which would compromise the safety guarantees +provided by Java. Potential problematic scenarios include the following +examples: + + * It must not be possible to write an integer at some position in a + `Message` object, and to read it back as a `MachPort` or `Buffer` object, + since this would allow unsafe access to arbitrary memory addresses and + mach port names. + * Providing the `mach_task_self()` system call would also provide access to + arbitrary addresses and ports by using the `vm_*` family of RPC operations + with the returned `MachPort` object. This means that the relevant task + operations should be provided by the `Syscall` class instead. + +Finally, access should be provided to the initial ports and file descriptors +in `_hurd_ports` and provided by the `getdport()` function, +for instance through static methods such as +`getCRDir()`, `getCWDir()`, `getProc()`, ... in a dedicated class such as +`org.gnu.hurd.InitPorts`. + +A realistic example of code based on such interfaces would be: + + import org.gnu.mach.MsgType; + import org.gnu.mach.MachPort; + import org.gnu.mach.Buffer; + import org.gnu.mach.Message; + import org.gnu.mach.Syscall; + import org.gnu.hurd.InitPorts; + + public class Hello + { + public static main(String argv[]) + /* Parent class for all Mach-related exceptions */ + throws org.gnu.mach.MachException + { + /* Allocate a reply port */ + MachPort reply = new MachPort(); + + /* Allocate an out-of-line buffer */ + Buffer data = new Buffer(MsgType.CHAR, 13); + data.writeString(0, "Hello, World!"); + + /* Craft an io_write message */ + Message msg = new Message(1024); + msg.setRemotePort(InitPorts.getdport(1)); + msg.setLocalPort(reply, Message.Type.MAKE_SEND_ONCE); + msg.setId(21000); + msg.addBuffer(data); + + /* Make the call, MACH_MSG_SEND | MACH_MSG_RECEIVE */ + Syscall.machMsg(msg, true, true, reply); + + /* Extract the returned value */ + msg.assertId(21100); + int retCode = msg.readInt(0); + int amount = msg.readInt(1); + } + } + +Should this paradigm prove insufficient, +more ideas could be borrowed from the +[`org.vmmagic`](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.151.5253&rep=rep1&type=pdf) +package used by [Jikes RVM](http://jikesrvm.org/), +a research Java virtual machine itself written in Java. + +### Generating Java stubs with MIG + +Once the basic machinery is in place to interface with Mach, Java programs +have more or less equal access to the system functionality without resorting +to more JNI code. However, as illustrated above, this access is far from +convenient. + +As a solution I would modify MIG to add the option to output Java code. MIG +would emit a Java interface, a client class able to implement the interface +given a Mach port send right, an a server class which would be able to handle +incoming messages. The class diagram below, although it is by no means +complete or exempt of any problem, illustrates the general idea: + +[[gsoc2011_classes.png]] + +This structure is somewhat reminiscent of +[Java RMI](http://en.wikipedia.org/wiki/Java_remote_method_invocation) +or similar systems, +which aim to provide more or less transparent access to remote objects. +The exact way the Java code would be generated still needs to be determined, +but basically: + + * An interface, corresponding to the header files generated by MIG, would + enumerate the operations listed in a given .defs files. Method names would + be transformed to adhere to Java conventions (for instance, + `some_random_identifier` would become `someRandomIdentifier`). + * A user class, corresponding to the `*User.c` files, + would implement this interface by doing RPC over a given MachPort object. + * A server class, corresponding to `*Server.c`, would be able to handle + incoming messages using a user-provided implementation of the interface. + (Possibly, a skeleton class providing methods which would raise + `NotImplementedException`s would be provided as well. + Users would derive from this class and override the relevant methods. + This would allow them not to implement some operations, + and would avoid pre-existing code from breaking when new operations are + introduced.) + +In order to help with the implementation of servers, some kind of library +would be needed to associate Mach receive rights with server objects and to +handle incoming messages on dedicated threads, in the spirit of libports. +This would probably require support for port sets at the level of the Mach +primitives described in the previous section. + +When possible, operations involving the transmission of send rights +of some kind would be expressed in terms of the MIG-generated interfaces +instead of `MachPort` objects. +Upon reception of a send right, +a `FooUser` object would be created +and associated with the corresponding `MachPort` object. +If the received send right corresponds to a local port +to which a server object has been associated, +this object would be used instead. +This way, +subsequent operations on the received send right +would be handled as direct method calls +instead of going through RPC mechanisms. + +Some issues will still need to be solved regarding how MIG will convert +interface description files to Java interfaces. For instance: + + * `.defs` files are not explicitly associated with a type. For instance in + the example above, MIG would have to somehow infer that io_t corresponds + to `this` in the `Io` interface. + * More generally, a correspondence between MIG and Java types would have + to be determined. Ideally this would be automated and not hardcoded + too much. + * Initially, reply port parameters would be ignored. However they may be + needed for some applications. + +So the details would need to be flushed out during the community bonding +period and as the implementation progresses. However I’m confident that a +satisfactory solution can be designed. + +Using these new features, the example above could be rewritten as: + + import org.gnu.hurd.InitPorts; + import org.gnu.hurd.Io; + import org.gnu.hurd.IoUser; + + class Hello { + static void main(String argv[]) throws ... + { + Io stdout = new IoUser(InitPorts.getdport(1)); + String hello = “Hello, World!\n”; + + int amount = stdout.write(hello.getBytes(), -1); + + /* (A retCode corresponding to an error + would be signalled as an exception.) */ + } + } + +An example of server implementation would be: + + import org.gnu.hurd.Io; + import java.util.Arrays; + + class HelloIo implements Io { + final byte[] contents = “Hello, World!\n”.getBytes(); + + int write(byte[] data, int offset) { + return SOME_ERROR_CODE; + } + + byte[] read(int offset, int amount) { + return Arrays.copyOfRange(contents, offset, + offset + amount - 1); + } + + /* ... */ + } + +A new server object could then be created with `new IoServer(new HelloIo())`, +and associated with some receive right at the level of the ports management +library. + +### Base classes for common types of translators + +Once MIG can target Java code, and a libports equivalent is available, +creating new translators in Java would be greatly facilitated. However, +we would probably want to introduce basic implementations of file system +translators in the spirit of libtrivfs or libnetfs. They could take the form +of base classes implementing the relevant MIG-generated interfaces which +would then be derived by users, +or could define a simpler interface +which would then be used by adapter classes +to implement the required ones. + +I would draw inspiration from libtrivfs and libnetfs +to design and implement similar solutions for Java. + +### Deliverables + + * A hurd-java package would contain the Java code developed + in the context of this project. + * The Java code would be documented using javadoc + and a tutorial for writing translators would be written as well. + * Modifications to MIG would be submitted upstream, + or a patched MIG package would be made available. + +The Java libraries resulting from this work, +including any MIG support classes +as well as the class files built from the MIG-generated code +for the Mach and Hurd interface definition files, +would be provided as single `hurd-java` package for +Debian GNU/Hurd. +This package would be separate from both Hurd and Mach, +so as not to impose unreasonable build dependencies on them. + +I expect I would be able to act as its maintainer in the foreseeable future, +either as an individual or as a part of the Hurd team. +Hopefully, +my code would be claimed by the Hurd project as their own, +and consequently the modifications to MIG +(which would at least conceptually depend on the Mach Java package) +could be integrated upstream. + +Since by design, +the Java code would use only a small number of stable interfaces, +it would not be subject to excessive amounts of bitrot. +Consequently, +maintenance would primarily consist in +fixing bugs as they are reported, +and adding new features as they are requested. +A large number of such requests +would mean the package is useful, +so I expect that the overall amount of work +would be correlated with the willingness of more people +to help with maintenance +should I become overwhelmed or get hit by a bus. + + +## Timeline + +The dates listed are deadlines for the associated tasks. + + * *Community bonding period.* + Discuss, refine and complete the design of the Java bindings + (in particular the MIG and "libports" parts) + * *May 23.* + Coding starts. + * *May 30.* + Finish implementing pthread signal semantics. + * *June 5.* + Port OpenJDK + * *June 12.* + Fix the remaining problems with GCJ and/or OpenJDK, + possibly port Eclipse or other big Java packages. + * *June 19.* + Create the bindings for Mach. + * *June 26.* + Work on some kind of basic Java libports + to handle receive rights. + * *July 3.* + Test, write some documentation and examples. + * *July 17 (two weeks).* + Add the Java target to MIG. + * *July 24.* + Test, write some documentation and examples. + * *August 7 (two weeks).* + Implement a modular libfoofs to help with translator development. + Try to write a basic but non-trivial translator + to evaluate the performance and ease of use of the result, + rectify any rough edges this would uncover. + * *August 22. (last two weeks)* + Polish the code and packaging, + finish writing the documentation. + + +## Conclusion + +This project is arguably ambitious. +However, I have been thinking about it for some time now +and I'm confident I would be able to accomplish most of it. + +In the event multiple language bindings projects +would be accepted, +some work could probably be done in common. +In particular, +[ArneBab](http://www.bddebian.com/~hurd-web/community/weblogs/ArneBab/2011-04-06-application-pyhurd/) +seems to favor a low-level approach for his Python bindings as I do for Java, +and I would be happy to discuss API design and coordinate MIG changes with him. +I would also have an extra month after the end of the GSoC period +before I go back to school, +which I would be able to use to finish the project +if there is some remaining work. +(Last year's rewrite of procfs was done during this period.) + +As for the project's benefits, +I believe that good support for Java +is a must-have for the Hurd. +Java bindings would also further the Hurd's agenda +of user freedom by extending this freedom to more people: +I expect the set of developers +who would be able to write Java code against a well-written libfoofs +is much larger than +those who master the intricacies of low-level systems C programming. +From a more strategic point of view, +this would also help recruit new contributors +by providing an easier path to learning the inner workings of the Hurd. + +Further developments +which would build on the results of this project +include my planned [[experiment with Joe-E|objcap]] +(which I would possibly take on as a university project next year). +Another possibility would be to reimplement some parts +of the Java standard library +directly in terms of the Hurd interfaces +instead of using the POSIX ones through glibc. +This would possibly improve the performance +of some Java applications (though probably not by much), +and would otherwise be a good project +for someone trying to get acquainted with Hurd. + +Overall, I believe this project would be fun, interesting and useful. +I hope that you will share this sentiment +and give me the opportunity to spend another summer working on Hurd. + diff --git a/user/jkoenig/java/report.mdwn b/user/jkoenig/java/report.mdwn new file mode 100644 index 00000000..cb1acda9 --- /dev/null +++ b/user/jkoenig/java/report.mdwn @@ -0,0 +1,136 @@ +[[!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]]."]]"""]] + +# GSoC 2011 final report (Java on Hurd) + +This is my final report regarding my work on Java for Hurd +as a Google Summer of Code student for the GNU project. +The work is going on, +for recent status updates, see my [[java]] page. + +## Global signal dispositions and SA_SIGINFO + +Signal delivery was implemented in Hurd before POSIX threads were +defined. As a consequence the current semantics differ from the POSIX +prescriptions, which libgcj relies on. + +On the Hurd, each thread has its own signal dispositions and +process-wide signals are always received by the main thread. +In contrast, POSIX specifies signal dispositions to be global to the +process (although there is still a per-thread blocking mask), and a +global signal can be delivered to any thread which does not block it. + +To further complicate the matter, the Hurd currently has two options for +threads: the cthread library, still used by most of the Hurd code, and +libpthread which was introduced later for compatibility purposes. To +avoid breaking existing code, cthread programs should continue to run +with the historical Hurd signal semantics whereas pthread programs are +expected to rely on the POSIX behavior. + +To address this, the patch series I wrote allows selecting a per-thread +behavior: by default, newly created threads provide historical +semantics, but they can be marked by libpthread as global signal +receivers using the new function `_hurd_sigstate_set_global_rcv()`. +In addition, I refactored some of the signal code to improve +readability, and fixed a couple of bugs I came across in the process. + +Another improvement which was required by OpenJDK was the implementation +of the `SA_SIGINFO` flag for signal handlers. My signal patch series +provides the basic infrastructure. However it is not yet complete, as +some of the information provided by `siginfo_t` structures is not +available to glibc. Making this information available would require a +change in the `msg_sig_post()` RPC. + +### Related Debian changes + +In Debian GNU/Hurd, libpthread is provided the `hurd` package. Hurd also +uses extern inline functions from glibc which are affected by the new +symbols. This means that newer Hurd packages which take advantage of +glibc's support for global signal dispositions cannot run on older C +libraries and some thought had to be given to the way we could ensure +smooth upgrades. + +An early attempt at using weak symbols proved to be impractical. As a +consequence I modified the eglibc source package to enable +dpkg-gensymbols on hurd-i386. This means that packages which are built +against a newer libc and make use of the new symbols will automatically +get an appropriately versionned dependency on libc0.3. + +### Status as of 2012-01-28 + +The patch series has not yet been merged upstream. However, it is now +being used for the Debian package of glibc. + +## $ORIGIN substitution in RPATH + +Another feature used by OpenJDK which was not implemented in Hurd is the +substitution of the special string `$ORIGIN` within the ELF `RPATH` +header. `RPATH` is a per-executable library search path, within which +`$ORIGIN` should be substituted by the directory part of the binary's +canonical file name. + +Currently, a newly executed program has no way of figuring out which +binary it was created from. Actually, even the `_hurd_exec()` function, +which is used in glibc to implement the `exec*()` family, is never +passed the file name of the executable, but only a port to it. +Likewise, the `file_exec()`, `exec_exec()` and `exec_startup_get_info()` +RPCs do not provide a path to transmit the file name from the shell to +the file system server, to the exec server, to the executed program. + +Last year, Emilio Pozuelo Monfort submitted a patch series which fixes +this problem, up to the exec server. The series' original purpose was to +replace the guesswork done by `exec` when running shell scripts. It +provides new versions of `file_exec()` and `exec_exec()` which allow for +passing the file name. I extended Emilio's patches to add the missing +link, namely a new `exec_startup_get_info_2()` RPC. New code in glibc +takes advantage of it to retrieve the file name and use it in a +Hurd-specific `dl-origin.c` to allow for `RPATH` `$ORIGIN` substitution. + +### Status as of 2012-01-28 + +The (hurd and glibc) patch series for `$ORIGIN` are mostly complete. +However, there is still an issue related to the canonicalization of the +executable's file name. Doing it in the dynamic linker (where `$ORIGIN` +is expanded) is complicated due to the limited set of available +functions (`realpath()` is not). Unfortunately canonicalizing in +`_hurd_exec_file_name()` is not an option either because many shell +scripts use `argv[0]` to alter their behavior, but `argv[0]` is replaced +by the shell with the file name it's passed. + +Another issue is that the patches use a fixed-length string buffer to +transmit the file name through RPC. + +## OpenJDK 7 + +With the groundwork above being taken care of, I was able to build +OpenJDK 7 on Hurd, although heavy portability patching was also +necessary. A similar effort for Debian GNU/kFreeBSD was undertaken +around the same time by Damien Raude-Morvan, so I intend to submit a +more general set of "non-Linux" patches. + +Due to the lack of a `libpthread_db` library on the Hurd, I was only +able to build a Zero (interpreter only) virtual machine so far. However, +it should be possible to disable the debugging agent and build Hotspot. + +### Status as of 2012-01-28 + +I have put together generic `nonlinux-*.diff` patches for the `openjdk7` +Debian package, however I have not yet tested them on Linux and kFreeBSD. + +## Java bindings + +Besides improving Java support on Hurd, my original proposal also +included the creation of Java bindings for the Hurd interfaces. +My progress on this front has not been as fast as I would have liked. +However I have started some of the work required to provide safe Java +bindings for Mach system calls. + +See https://github.com/jeremie-koenig/hurd-java. + diff --git a/user/jkoenig/objcap.mdwn b/user/jkoenig/objcap.mdwn new file mode 100644 index 00000000..e4cd20e8 --- /dev/null +++ b/user/jkoenig/objcap.mdwn @@ -0,0 +1,85 @@ + +# Potential applications of object-capability languages + +The work discussed is this last part would have +fewer immediate benefits for the Hurd project +and has more of a research orientation. +It is also unlikely that there would be any time remaining +to work on it at the end of the summer. +(Though it could work as some kind of reward +if I somehow managed to do a prefect job of all the rest +within the allocated time :-) ). +As a consequence, +I don't really consider this a part of my application. + +This being said, +to some extent the project discussed here +will informed the way I design the Java bindings, +since it depends on them +and I intend to work on this at some point in the future. +I also believe it touches on some interesting ideas, +and a Summer of Code application is probably +as good an occasion as any to discuss them. + +### Justification + +The primary advantage of multi-server operating systems is the ability to +break what used to be the kernel into small pieces which can be isolated +from each others. This makes sense from an engineering perspective, as +smaller components can be swapped with different implementations and reduce +the impact of bugs. +A capability-based approach also ensures that the +authority wielded by components is clear and reduced to the minimum required +for them to function. +These properties are crucial to the Hurd's agenda of user freedom, +since in order to allow them to plug their own code into the system +[FIXME: développer] + +However, this flexibility has a cost. In a system where the isolation of +components relies on running them inside different address spaces, +communication between them must be done through IPC calls. +This introduces a trade-off between the size of the modules +and performance as well as practicality, +which imposes a limit to the granularity with which the system +can be decomposed and the principle of least authority applied +(to the code within a given process, a Mach port is ambient authority). + +Another issue is that of the threading structure of the system as a whole. +In systems based on a monolithic kernel, user threads execute the kernel +code themselves, which is then intrinsically concurrent. By contrast, in a +system based on a “client-server” paradigm, each server must be explicitly +multi-threaded if it is to serve requests concurrently. + +### Object-capability languages + +An object-capability language is an object-oriented language which is +restricted enough so that object references are themselves capabilities. + +One such language is Joe-E (FIXME: lien), +which is an object-capability subset of Java: +global state and static methods are mostly forbidden; +careful white-listing of the objects and methods +provided by the Java standard library +ensures that compliant code cannot not access ambient autority. +Ways in which object references can be transferred +are restricted to the most obvious ones +(for instance, exceptions are carefully restricted). + +As a result, untrusted Joe-E code can be executed without any further +isolation and its autority can be controlled by carefully limiting the +object references which are passed to it. +This would allow to load and execute translators written in Joe-E +in a single address space. + +### Bundling translators into a single process + +[mechanisme pour transmettre le code Joe-E +et les port initiaux au serveur] +[émulation des différentes tâches] + +### Challenges and further work + +[proof-carrying code / typed assembly, +resource accounting (passer en revue la conception de Viengoos?)] + + diff --git a/user/kam.mdwn b/user/kam.mdwn new file mode 100644 index 00000000..8ee68866 --- /dev/null +++ b/user/kam.mdwn @@ -0,0 +1,152 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!meta title="Karim Allah Ahmed"]] + +<karim.allah.ahmed@gmail.com> + +Egypt. + +--- + +#GSoC: 2010 Project +Goal: + +--- +#Roadmap + +##Progress + +###Preparation Phase: + +Understanding how gnumach ticks [ at least the parts related to the project ] + +--- + +####28th of April - 5th of May: + +* Reading the paging in code in gnumach. +* Reading the libpager code, and the multipage patch. +* Reading the translators code, only the part implementing the external pager interface. + +####5th of May - 12th of May: + +* Reading the paging out code in gnumach. +* Understanding IPC in gnumach and reading some code. +* Reading "[gnu_src]/kern/sched_prim.c" + +####12th of May - 19th of May: + +* Finishing the leftover code in some of the previous phases. +* Building a big and a more clear picture of how gnumach ticks [ wiring things together ]. + +####19th of May - 23th of May: + +* Off [College related-activities]. + +--- + +###Coding Phase: + +Stage 1: + +####24th of May - 26th of May: + +* Read the freeBSD multipages implementation. +* Basic Modifications of gnumach's code. +* err.. scratch this step. It's easier to work on porting OSF Mach's implementation of multi-pages. + +####26th of May - 28th of May: + +* (./) port OSF Mach's clustered pagein during 'page faults' ( [src]/vm/vm_fault.c ) +* (./) port "cluster_size" attribute of memory objects from OSF Mach. +* (./) port "behavior" attribute of vm_map entries from OSF Mach. + +####29th of May - 2nd of June: + +* Off ( Oral Exams ) + +####2nd of May - 4th of June: + +* Finish the port of the previous phase. + +--- + +####4th of June - 4th of July: + +* Off ( Final Exams ). + +--- + +Stage 2: + +####5th of July - 7th of July: + +* (./) Add "cluster_size" attribute to Neal Walfield's patch for the pager library. + +--- + +Stage 3: + +####8th of July - 15th of July: + +* (./) Patch the diskfs library to use the new pager library API. +* (./) Patch the ext2fs disk paging related routines to use the new pager library API. + + +####16th of July - 19th of July: + +* Testing the current patches. +* Stuck in compiling code ( http://30.media.tumblr.com/tumblr_l5ie1bb2u91qbjipvo1_500.jpg ) , so I started reading some documentation meanwhile ( [0] , [1] ). + +--- + +Stage 4: + +####19th of July - 31th of June: + +* Check OSF Mach's mach-defpager. +* Patch (or port OSF Mach's default pager) HURD's mach-defpager to use the new gnumach's RPCs. + +--- + +Stage 5: + +####1st of August - 10th of August: + +* Testing the ported translators. +* Fixing the boot bit-mapped memory allocator patch. + +--- + +Stage 1: + +* clustered_paging.diff patch http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00024.html + +TODO: + +* Update the headers of the modified files in GNU Mach to reflect the fact that they were ported from OSF Mach. + +* Implement posix_madvise(), posix_fadvise, and readahead() in glibc. + +* Update the documentation of GNU Mach with the new interfaces. + +* (./) Revise and finish the code related to default_memory_manager management in GNU Mach. [done] + +* Port the vm_page "clustered" attribute. [ to mark that the page wasn't requested but was paged-in as part of the cluster ]. + + +--- + + +# Readings + +[0] http://www.nongnu.org/ext2-doc/ext2.html +[1] http://kerneltrap.org/node/452 diff --git a/user/musial.mdwn b/user/musial.mdwn new file mode 100644 index 00000000..dee4588a --- /dev/null +++ b/user/musial.mdwn @@ -0,0 +1,15 @@ +[[!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]]."]]"""]] + +Robert Musial - Cleveland, OH + +musial/at/gnu/dot/org + +http://musial.sollux.net diff --git a/user/pochu.mdwn b/user/pochu.mdwn new file mode 100644 index 00000000..18e90de3 --- /dev/null +++ b/user/pochu.mdwn @@ -0,0 +1,136 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +# Emilio Pozuelo Monfort + +Email: pochu27@gmail.com + +--- + +# GSoC 2010: Hurd: Fix Compatibility Problems Exposed by Testsuites + +Mentor: Carl Fredrik Hammar + +## Abstract + +This project will consist of identifiying some projects' test suite +failures when executed on GNU/Hurd, debugging them, and if they are +truly GNU/Hurd issues (and not problems in the projects themselves), +fixing them. + +## Timeline +* July 18th: GLib finished. +* July 22nd: coreutils finished. +* July 25th: All Perl failures investigated. +* August 5th: Perl finished. +* August 8th: All Python failures investigated. +* August 16th: Python finished. +* August 16th: Firm 'pencils down' date + +## TODO +* Investigate why coreutils' nice test fails. +* Analyze Perl's testsuite failures. + +## Documentation +* [Towards a New Strategy of OS Design, an architectural overview by Thomas Bushnell, BSG](http://www.gnu.org/software/hurd/hurd-paper.html) +* [The Hurd, a presentation by Marcus Brinkmann](http://www.gnu.org/software/hurd/hurd-talk.html) +* [The Hurd Hacking Guide](http://www.gnu.org/software/hurd/hacking-guide/hhg.html) +* [MIG - The MACH Interface Generator](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps) + +## Log + +### July 26th - August 1st +* Tested /dev/fd/N patches and sent them for review. +* Finished SCM_RIGHTS patch. Created a minimal testcase without using + glibc to demonstrate the socket_send/recv failure with non-socket + fds. Sent the testcase and the patch for review. +* Investigated cp issues with O_NOFOLLOW & O_NOTRANS. Sent a mail to + bug-hurd explaining both issues and possible solutions. + +### July 19th - July 25th +* Initial SCM_RIGHTS implementation. Seems to work when sending pipes, but + fails miserably when sending fds from an open syscall. No idea why yet. +* Fixed memleaks in sendmsg() while implementing SCM_RIGHTS. Patch accepted + upstream. +* Had to build glibc thrice because the system crashed and the fs was totally + corrupted. I'll build stuff in a separate partition as suggested from now on. + Doesn't help. It turns out the issue seems to be with kvm, or at least it's + only reproducible for me there. I've switched to VirtualBox and there are no + filesystem issues there. +* Addressed comments in the /dev/fd/N patches. Need to test them (when I can + build glibc and Hurd without the system crashing). + +### July 14th - July 18th +* Catched up with email. +* Prepared a patch to implement getsockopt(fd, SOL_SOCKET, SO_TYPE, ...). + Patch committed to Hurd. +* Addressed comments in the /dev/fd/N patches and resent them. +* Investigated another glib's unix-fd failure: passing fds over a socket using + sendmsg() doesn't dup them. Created a minimal testcase. Prepared a preliminary + patch, needs testing and fixing. + +### May 26 - July 13th +* Copyright assignment on file. +* Studied a lot to finish my BSc. +* Got the linkat patch (Savannah #29655) committed upstream. + +### May 19 - May 26 +* Read [MIG - The MACH Interface Generator](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps) +* Worked on bug 28934. Send [patches](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html) for review. +* Requested GNU libc copyright papers to the FSF again since they didn't arrive the first time. + +### May 12 - May 19 +* Read http://www.gnu.org/software/hurd/hurd-talk.html +* Half read http://www.gnu.org/software/hurd/hacking-guide/hhg.html +* Read many Hurd interfaces (fs.defs, auth.defs, fsys.defs, io.defs, + password.defs). + +### May 5 - May 12 +* Read http://www.gnu.org/software/hurd/hurd-paper.html +* Improved the linkat() patch +* Fixed the issues mentioned in bug 28934, but after doing so I realized + that wouldn't work well. The only good solution is to pass file_name + from execve() to the exec server, so we need new RPCs. + +### April 28 - May 5 +* Submitted a talk proposal on Hurd with Michael Banck for DebConf +* Sent request to assign copyright to the FSF for Hurd/Mach/libc + +### Before April 28 +* Investigated the glib's gtester problem and tracked it down: + [bug 28934](https://savannah.gnu.org/bugs/?28934). Prepared a patch + but it's not good. +* [glib's garray test timeouts on Hurd](https://bugzilla.gnome.org/show_bug.cgi?id=568760). + The tests passes if the timeout is increased. The current upstream timeout + (10s) is quite small (it fails on many Debian builds for some Linux arches). + However on Hurd it needs a very big time it seems (like more than 100s). + Maybe do an allocation benchmarch? +* Investigated glib's unix-fd test failure: getsockopt() isn't implemented + on Hurd. Need to implement it in hurd/pflocal/socket.c. +* Investigated coreutils' ln EIEIO, with Samuel's help. linkat() is buggy. + Reported as [bug 29655](https://savannah.gnu.org/bugs/?29655). Prepared a + patch for it. +* Investigated coreutils' cp EACCES. Test case: 'mkfifo a && cp -R --copy-contents a b'. + Problem is that O_NOFOLLOW adds O_NOTRANS. + +## Midterm Evaluation +### Accomplished +* Assigned copyright to the FSF. +* Read many documentation and source code. +* /dev/fd/N bug fixed +* Prepared a patch for getsockopt() +* Fixed linkat() problems. +* Investigated bug with O_NOFOLLOW & O_NOTRANS (needs more work). +* Investigated a glib test failure (garray). Not a Hurd issue. +### Downtime +* Studied a lot to finish my BSc. Didn't work on Hurd for a month because of + that, so that's why I couldn't make a lot of progress (this was known in + advance, although in the end the downtime was a bit larger than expected). +* There's no expected downtime from now on. diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index 2f8ea542..017936e5 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -13,6 +13,49 @@ Sergiu Ivanov Mail: <mailto:unlimitedscolobb@gmail.com> +# Current Activity + +I am currently busy finishing the university semester, this is why I +am rather passive. + +## Roadmap + +* **Build `nsmux` under the Hurd tree** -- **antrik** has been urging + me to do this for a long time, so I definitely have to give it a + try. + +* **Try Thomas's `nsmux-notify` branch** -- To support his stance + against including `nsmux` in the Hurd source tree, Thomas added to + `nsmux` the ability to listen to port notification (as I understand + it). I have to try that, too. + +* **Make proxy nodes go away when the proxied translator goes away** + -- This should be done by listening to notifications on the ports to + the proxied translators. A similar functionality is already + implemented in `unionmount`, but it was decided that `nsmux` should + use standard notification interfaces, as opposed to the custom + demuxer and handler implemented in `unionmount`. + +* **Don't attach anonymous translators** -- There is no special point + in attaching anonymous (formerly known as dynamic) translators to + specific nodes. Keeping them orphan should simplify the design of + `nsmux` by eliminating the need for shadow nodes, whose main purpose + was to serve as virtual locations to attach translators to. + +* **Setup a list of nodes proxying static translators** -- This list + is needed when for the filter, which should also be able to go down + the static translator stack, not only the stack of anonymous + translators. + +* **Cleanup `nsmux`** -- When I was writing `nsmux` my acquaintance + with good coding and code formatting practices was very basic, which + resulted in messy and sometimes ugly code. + +* **Implement recursive propagation of translators down directories** + -- This task was planned long ago and is fascinating, but I won't be + working on it in the near future. + +--- # Google Summer of Code: 2009 Project @@ -23,6 +66,11 @@ tree of the node the translator is mounted onto. For documentation, see [[hurd/translator/unionmount]]. +At the Final Evaluation, this project was given a passing evaluation +by **antrik**. This means that the union-mount functionality is +working and has been tested normally to collaborate with +`eth-multiplexer`. + --- ## Roadmap @@ -93,38 +141,107 @@ For documentation, see [[hurd/translator/unionmount]]. instance of eth-multiplexer I learnt how I could compile GNU/Hurd in a Debian GNU/Hurd system. -### TODO - -(Dates in brackets show the *expected* completion date) - -* **Study eth-multiplexer.** *(19 Jun)* In order to get an idea of - what should the rules for eth-multipexer be, I will have to study - the current state of eth-multiplexer. - -* **Implement merging rules.** *(25 Jul)* Some details are still - awaiting discovery by me. - -* **Wrap up the project for upstream inclusion.** *(1 Aug)* - `unionmount` is intended to be included upstream, therefore it - should be mostly complete and polished by the end of GSoC. - -* **Decide as to location of unionmount.** *(1 Aug)* Presently, - `unionmount` is a (local) branch in `unionfs` git repository. The - first step of publishing it is planned to be pushing it to the - Savannah `unionfs` repository. Some agree that there should also be - a second step consisting in splitting `unionmount` in a separate git - repository, since the destinations of `unionfs` and `unionmount` are - *similar*, and not identical. - -* **Employ `unionmount` in eth-multiplexer.** *(10 Aug)* I still have - to scrounge for details. - -* **Use a different (better?) implementation idea.** *(17 Aug)* It has - been pointed out several times that `unionmount` could be - implemented not by forking off `unionfs`, but by keeping the merging - functionality in a stand-alone module (which could then be used by - `unionfs` as well). Different implementation ideas with their own - specific advantages may also arise in the future. +* **Setup the `devnode`--`eth-multiplexer`--`pfinet chain`.** *(30 + Jun)* Due to the fact that I was trying to build everything using + `gcc-4.3`, I got strange behaviour of pfinet and spend a week trying + to figure out the reason. + +* **Try to start the mountee during initialization of `unionfs`** *(4 + Jul)* Initially the mountee was started at the first lookup. Now it + is started immediately after initialization of `unionmount`. + +* **Fix the patches in `--mount` option series** *(5 Jul)* The patches + have been reviewed by **antrik**. I corrected them and posted them + to the ML for final reviews. + +* **Orphan the mountee after starting it** *(7 Jul)* Orphaning the + mountee after starting it up seems to be a nice work-around for the + necessity of keeping a proxy node in unionmount in simple + use-cases. It is possible that this functionality will provided as a + separate patch (without inclusion in master) should it turn out that + orphaning the mountee is a bad idea. + +* **Decide which RPCs should be forwarded to the mountee and how this + should happen** *(10 Jul)* This is the primary requirement in being + able to proxy the control port of `unionmount`. + +* **Fix the patches the have already been commented on** *(14 Jul)* + The new patches I have submitted have been reviewed; also, the older + patches have been reviewed again, which required correcting them. + +* **Add the `--no-mount` option** *(14 Jul)* Using the `--no-mount` + and `--mount` options, the user can decide whether unionmount should + be completely transparent (i.e. most control-port RPCs forwarded to + the mountee) or not. + +* **Make `unionmount` go away when the mountee goes away** *(14 Jul)* + `unionmount` makes sense only while the mountee is running, so it + has to go away as soon as the mountee has been shut down for some + reason. + +* **Proxy the control port of `unionmount`** *(14 Jul)* For + `unionmount` to become transparent, most of the RPCs invoked on the + its control port should be forwarded to the mountee. + +* **Fix adding filesystems to `unionmount`** *(16 Jul)* `settrans -a + foo unionfs -a <dir> -u -t <translator>` worked, but `settrans -a + foo unionfs -u -t <translator> -a <dir>` didn't. The problem was + that in a series of rebase operations I accidentally left the + "Orphan the mountee" commit out and the problem appeared when the + `start_mountee` function tried to attach the mountee. Of course, + this is not the definite solution, since I don't know why should the + attempt to attach the mountee work in the former case and fail in + the latter, but I will leave the investigation for some future time. + +* **Create the patch for supplying the mountee with a port to the + underlying node of unionfs** *(17 Jul)* Such functionality makes + `unionmount` even more transparent. + +* **Try to make `eth-multiplexer` work with static instances of + `devnode`** *(3 Aug)* A static `devnode` translator is a `devnode` + translator which is told to use the eth-multiplexer's pseudo master + device port via the "-M" option. Technically it looks like + `settrans -a <node> devnode -M <dir> <device-name>`, where `<dir>` + is the node on which eth-multiplexer is running. + + The problem was in the fact that the root node of `eth-multiplexer` + was not treated completely similarly as other nodes; specifically no + device port was created for it. Minor modifications to some + conditions solved the problem. + +* **Add the `MASTER` node to `eth-multiplexer`** *(5 Aug)* The + `MASTER` node, published by eth-multiplexer, allows creating any + number of virtual devices. This node is mainly accessed by static + instances of `devnode` to setup their corresponding virtual devices. + +* **Add support for priorities** *(6 Aug)* Now the mountee's + filesystem can be configured to "lie" beneath other filesystems. + +* **Use `unionmount` to merge the virtual filesystem of + `eth-multiplexer` with its underlying filesystem** *(7 Aug)* + `eth-multiplexer` can is unionmounted to "lie beneath" it's + underlying filesystem. If, for example, the multiplexer is + unionmounted on `veth/`, the user can both set (static) `devnode` + translator on the nodes shown in `veth/` and belonging to the + underlying filesystem and create normal virtual multiplexer devices + by accessing any node (not present in the underlying filesystem) and + opening a device using the port to the node as a pseudo device port. + +* **Rename the `MASTER` node into `.MASTER`** (7 Aug) This name seems + more natural for a special-purpose node. + +* **Set the stat information for `eth-multiplexer` nodes in + `netfs_validate_stat`** (9 Aug) In the initial version the stat + information was set up properly only at device creation. Before + that the stat information was copied from the underlying node, which + baffled `unionmount`. Now the stat information is setup in + `netfs_validate_stat`. + +* **Supply the mountee with the real root.** *(14 Aug)* Since the + mountee is *not attached* to its underlying node, it is okay to + supply it with the real root node of `unionfs`. The mountee's + filesystem will not obscure the `unionfs`'s one because the mountee + is *not attached* to the root node. --- diff --git a/user/tlecarrour.mdwn b/user/tlecarrour.mdwn new file mode 100644 index 00000000..46ab6c80 --- /dev/null +++ b/user/tlecarrour.mdwn @@ -0,0 +1,51 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +Tanguy LE CARROUR +================= + +Homepage: *none* +E-mail: [tanguy@bioneland.org](mailto:tanguy@bioneland.org) + +I am a Hurd enthusiast and new contributor, mostly working on porting packages +for **Debian GNU/Hurd**. + + +Contributions +------------- + + +### Porting Debian Packages: + +See the [[package porting general introduction|hurd/porting/guidelines]] and +my [[porting guide for dummies|porting_guide_for_dummies]]. + +For each patch make sure to respect the [[patch life cycle|patch_life_cycle]]. + +* Candidates + * [[gphoto2]] (PATH_MAX) + * [[libgphoto2]] (function doesn't accept `NULL` buffer) + * [[pidgin-microblog]] (PATH_MAX) + * [[schism]] (PATH_MAX) + * [[shush]] (PATH_MAX) + * [[sitecopy]] (PATH_MAX) +* Work in progress + * [[auto-apt]] (PATH_MAX), **submitted** + * [[rng-tools]] (PATH_MAX), **discussing** + * [[suckless-tools]] (PATH_MAX), **submitted** + * [[up-imapproxy]] (PATH_MAX), **discussing** + * [[sakura]] (PATH_MAX), **submitted** +* Accepted + * - +* Stopped + * [[memstat]] (PATH_MAX) + + diff --git a/user/tlecarrour/auto-apt.mdwn b/user/tlecarrour/auto-apt.mdwn new file mode 100644 index 00000000..cceaee9a --- /dev/null +++ b/user/tlecarrour/auto-apt.mdwn @@ -0,0 +1,97 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + +auto-apt +======== + +When you want to build a program from source and it fails due to missing headers. Auto-apt can search what package would provide the header files. +(from [[https://help.ubuntu.com/community/AutoApt]]) + + +[[!toc startlevel=2]] + + +* * * + + +Log +--- + +* **Started**: 2012-01-24 +* **Discussed**: [2012-01-26](http://lists.debian.org/debian-hurd/2012/01/msg00129.html) +* **Draft Submitted**: - +* **Submitted**: 2012-02-07, Bug#[659025](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659025) +* **Accepted**: - + + +* * * + + +ToDo +---- + +The output of `grep -R PATH_MAX auto-apt-0.3.22/*` is a bit long. It contains files that have been patched using `#define PATH_MAX XYZ`. +Here is the only file of interest: + + pkgcdb/pkgtab.c: char buf[PATH_MAX]; + pkgcdb/pkgtab.c: assert(p - pkg < PATH_MAX); + pkgcdb/pkgtab.c: static char buf[PATH_MAX]; + pkgcdb/pkgtab.c: assert(len < PATH_MAX); + + +* * * + + +Comments +-------- + + +++ auto-apt-0.3.22/auto-apt-pkgcdb.c 2012-02-03 09:25:54.045858173 +0100 + + + unsigned char *buf = NULL; + + + while (!feof(stdin)) { + unsigned char *fname, *pkg; + unsigned char *p; + int nslash = 0; + + + buf = get_line(stdin); + + if (buf == NULL) + + break; + +Reading from `stdin` using the `get_line()` function as explained in the [[porting guide|porting_guide_for_dummies]]. + + + free(buf); + + +++ auto-apt-0.3.22/pkgcdb/pkgtab.c 2012-01-30 09:05:07.883096049 +0100 + + + char *buf = NULL; + + + buf = (char *)malloc(p - pkg + 1); + + if (buf == NULL) { + + abort(); + + } + + + free(buf); + + - static char buf[PATH_MAX]; + + static char *buf; + + + if (buf != NULL) { + + free(buf); + + } + + buf = (char *)malloc(len + 1); + + if (buf == NULL) { + + abort(); + + } + + diff --git a/user/tlecarrour/gphoto2.mdwn b/user/tlecarrour/gphoto2.mdwn new file mode 100644 index 00000000..e5f80bbf --- /dev/null +++ b/user/tlecarrour/gphoto2.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + +gphoto2 +======= + +The gphoto2 digital camera command-line client. +**Home page**: [[http://www.gphoto.org/proj/libgphoto2]] + +[[!toc startlevel=2]] + + +* * * + + +Log +--- + +* **Started**: - +* **Discussed**: - +* **Draft Submitted**: - +* **Submitted**: - +* **Accepted**: - + + +* * * + + +ToDo +---- + +Only one file relies on `PATH_MAX`: gphoto2/main.c +First need to patch [[libgphoto2]] package. + + +* * * + + +Comments +-------- + +Not yet started. + diff --git a/user/tlecarrour/libgphoto2.mdwn b/user/tlecarrour/libgphoto2.mdwn new file mode 100644 index 00000000..fd18b7ae --- /dev/null +++ b/user/tlecarrour/libgphoto2.mdwn @@ -0,0 +1,51 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + +libgphoto2 +========== + +ImpulseTracker clone aiming at providing the same look&feel. +**Home page**: [[http://www.gphoto.org/proj/libgphoto2]] + +[[!toc startlevel=2]] + + +* * * + + +Log +--- + +* **Started**: - +* **Discussed**: - +* **Draft Submitted**: - +* **Submitted**: - +* **Accepted**: - + + +* * * + + +ToDo +---- + +Fix `gphoto2-settings.c:gp_setting_get()` to accept `NULL` pointer and do the allocation. +This is a requirement for [[gphoto2]] patch. + +* * * + + +Comments +-------- + +Not yet started. diff --git a/user/tlecarrour/memstat.mdwn b/user/tlecarrour/memstat.mdwn new file mode 100644 index 00000000..fc12bd25 --- /dev/null +++ b/user/tlecarrour/memstat.mdwn @@ -0,0 +1,145 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +memstat +======= + +Lists all the processes, executables, and shared libraries that are using up virtual memory. It's helpful to see how the shared memory is used and which 'old' libs are loaded. +**Home page**: [[http://sourceforge.net/projects/memstattool]] + +[[!toc startlevel=2]] + + +* * * + + +Log +--- + +* **Started**: 2012-01-20 +* **Discussed**: [2012-01-21](http://lists.debian.org/debian-hurd/2012/01/msg00081.html) +* **Draft Submitted**: [2012-01-25](http://lists.debian.org/debian-hurd/2012/01/msg00122.html) +* **Submitted**: 2012-02-02, Bug#[658384](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658384) +* **Stopped**: 2012-02-07, depends on `/proc` which is not yet totally implemented on the Hurd. +* **Accepted**: - + + +* * * + + +ToDo +---- + +Here is the output of `grep -R PATH_MAX memstat-0.9/*`: + + memstat.c: char *p, major[8], minor[8], buff[PATH_MAX + 300], *path, perm[4]; + memstat.c: char linkname[PATH_MAX], filename[PATH_MAX]; + memstat.c: if ((len = readlink(filename, linkname, PATH_MAX)) == -1) { + + +* * * + + +Comments +-------- + +Here are comments on the patch... + + +#define FMT_PROC_MAPS "/proc/%d/maps" + +#define FMT_PROC_EXE "/proc/%d/exe" + +Define string formats. + + static void read_proc(void) + { + unsigned int nread, pid; + unsigned long inode, lo, hi, offs; + - char *p, major[8], minor[8], buff[PATH_MAX + 300], *path, perm[4]; + + char *p, major[8], minor[8], *path, perm[4]; + + char *buff = NULL; + + size_t buff_size = 0; + +In this function we turn `buff` into dynamically allocated string. + + + - sprintf(buff, "/proc/%d/maps", pid); + - f = fopen(buff, "r"); + + char filename[sizeof(FMT_PROC_MAPS) + (sizeof(int) * 3) + 1]; + + sprintf(filename, FMT_PROC_MAPS, pid); + + f = fopen(filename, "r"); + +Compute the maximum size of `filename` using `sizeof(int) * 3` as explainend in the [[porting guide|porting_guide_for_dummies]]. + + + - while (fgets(buff, sizeof(buff), f)) { + + while (!feof(f)) { + + buff = get_line(f); + + if (buff == NULL) + + break; + +Read a line from the file using [[get_line()|porting_guide_for_dummies]]. + + + - if ((strlen(buff) == 10) && (strcmp(buff, " (deleted)") == 0)) + + if ((strlen(buff) == 10) && (strcmp(buff, " (deleted)") == 0)) { + + free(buff); + continue; + + } + nread = sscanf(buff, "%lx %lx %4s %lx %s %s %lu %as", &lo, &hi, perm, &offs, major, minor, &inode, &path); + + free(buff); + +Free the `buff` when it's not used anymore. + + + + buff_size = 4; /* size of the format string without "%x" expressions */ + + buff_size += strlen(major); + + buff_size += strlen(minor); + + buff_size += sizeof(int) * 3 + 1; /* inode */ + + buff_size += 1; /* '\0' */ + + buff = malloc(buff_size); + + if (buff == NULL) { + + perror("Cannot allocate memory!"); + + exit(1); + + } + +Compute the size that the `buff` must have. + + + - char linkname[PATH_MAX], filename[PATH_MAX]; + - ssize_t len; + + char *linkname = NULL; + + struct stat sb; + + ssize_t len = -1; + +In this function we turn linkname into dynamically allocated string. +filename will be declared later. + + + - sprintf(filename, "/proc/%d/exe", pid); + - if ((len = readlink(filename, linkname, PATH_MAX)) == -1) { + + char filename[sizeof(FMT_PROC_EXE) + (sizeof(int) * 3) + 1]; + + sprintf(filename, FMT_PROC_EXE, pid); + +Same as above with `FMT_PROC_MAPS`. + + + + char filename[sizeof(FMT_PROC_EXE) + (sizeof(int) * 3) + 1]; + + sprintf(filename, FMT_PROC_EXE, pid); + + linkname = readlink_malloc(filename); + + if (linkname == NULL) { + +Use `readlink_malloc()` as explained in the porting guide because `/proc/PID/exe` doesn't work with `readlink()` + + + + free(linkname); + +Free dynamically allocated variable that is not used anymore. + diff --git a/user/tlecarrour/patch_life_cycle.mdwn b/user/tlecarrour/patch_life_cycle.mdwn new file mode 100644 index 00000000..fd913378 --- /dev/null +++ b/user/tlecarrour/patch_life_cycle.mdwn @@ -0,0 +1,90 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +Patch Life Cycle +================ + +[[!toc startlevel=2]] + + +* * * + + +Start +----- + +Follow the steps listed on the [[package porting page|porting_guide_for_dummies]]. + + +Discuss +------- + +Send the patch for review to [debian-hurd@lists.debian.org](mailto:debian-hurd@lists.debian.org). +**Before** sending the patch, make sure that you've solved all the known problems listed in the [[package porting general introduction|hurd/porting/guidelines]] +and the [[porting guide for dummies|porting_guide_for_dummies]]. + + +Submit Draft +------------ + +When the patch is good enough, you can write the draft of the official bug report. +This draft should first be sent for review to [debian-hurd@lists.debian.org](mailto:debian-hurd@lists.debian.org) with the patch attached. + +Here is an example for memstat: + + Source: memstat + Version: 0.9 + Severity: important + Tags: patch + User: debian-hurd@lists.debian.org + Usertags: hurd + X-DebBugs-CC: debian-hurd@lists.debian.org + + Hi, + + This patch solves the build problems for GNU/Hurd due to PATH_MAX + issues. The solution is to make dynamic string allocations instead of + using fixed length buffers. The patch involves one file, and is + trivial. Parts of the code have been reviewed by GNU/Hurd developers + and Debian GNU/Hurd developers and maintainers. + + FIXME: + Is it really useful to check if BUFSIZ is defined? + + TODO: + Should the "whole package" be tested with valgrind on GNU/Linux?! + If yes, is there a standard procedure to do it?! + + Thanks! + Special thanks to Jérémie and Richard for their comments! + + (Not submitted yet, comments are welcome.) + +Once it's been approved, you can proceed to the submission. + + +Submit +------ + +The bug report is the same as above, with all the **FIXME**, **TODO** and final comment removed. +Attach the patch and send it to [submit@bugs.debian.org](mailto:submit@bugs.debian.org). +Convention for the e-mail subject: `memstat: FTBFS on hurd-i386` +Convention for the attachment name is: `fix_FTBFS4Hurd.patch` + + +Accept +------ + +Once the patch has been accepted, update your patch page! +**Congratulations!** + + + diff --git a/user/tlecarrour/pidgin-microblog.mdwn b/user/tlecarrour/pidgin-microblog.mdwn new file mode 100644 index 00000000..13e37c00 --- /dev/null +++ b/user/tlecarrour/pidgin-microblog.mdwn @@ -0,0 +1,57 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + +pidgin-microblog +================ + +Microblogging plugins for Pidgin. +**Home page**: [[http://code.google.com/p/microblog-purple/]] + +[[!toc startlevel=2]] + + +* * * + + +Log +--- + +* **Started**: - +* **Discussed**: - +* **Draft Submitted**: - +* **Submitted**: - +* **Accepted**: - + + +* * * + + +ToDo +---- + +Here is the output of `grep -R PATH_MAX pidgin-microblog-0.3.0/*`: + + pidgin-microblog-0.3.0/microblog/mb_cache.c:static char cache_base_dir[PATH_MAX] = ""; + pidgin-microblog-0.3.0/microblog/mb_cache.c:snprintf(cache_base_dir, PATH_MAX, "%s/mbpurple", user_dir); + +The `cache_base_dir` is static but should only be called through a getter. +If it has not been initialized, return "" from the getter. + +* * * + + +Comments +-------- + +Not yet started. + diff --git a/user/tlecarrour/porting_guide_for_dummies.mdwn b/user/tlecarrour/porting_guide_for_dummies.mdwn new file mode 100644 index 00000000..64f0ba0d --- /dev/null +++ b/user/tlecarrour/porting_guide_for_dummies.mdwn @@ -0,0 +1,230 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +Porting Guide for Dummies +========================= + +The problems addressed here were encountered while working +on fixing **PATH_MAX** and **MAXPATHLEN**. + +[[!toc startlevel=2 levels=3]] + + +* * * + + +Test on Hurd +------------ + + +### Installing the required files + +As `apt-get source` will download and extract many files, you may want to create a dedicated folder for the package and work from there. + + mkdir PACKAGE + cd PACKAGE + sudo apt-get build-dep PACKAGE + apt-get source PACKAGE + + +### Trying to build the package + + cd PACKAGE_SOURCE + dpkg-buildpackage -us -uc -rfakeroot -tc + + +### Test a quick fix + +In all the files that use **PATH_MAX**, include those lines at the beginning. + + #ifndef PATH_MAX + #define PATH_MAX 4196 + #endif + +Try to rebuild the package and see if it's solved the problem. +If yes, you can start working on the package. + + +* * * + + +Basic things +------------ + +### Maintaining a original version + + mkdir old + cp -r PACKAGE_SOURCE old/ + + +### Coding style + +Follow the conventions used in the source code! + + if (condition) { + do_smthg(); + } + +is not the same as: + + if (condition) + { + do_smthg(); + } + +and is not the same as: + + if (condition) + do_smthg(); + +Pay attention to spaces surrounding, or not, arithmetic signs and symbols: + + a = do_smthg( b + c ); + a = do_smthg(b+c); + + +### Indentation + +By default use 8 spaces as the size for 1 tab. +Then figure out if the code uses tab + 1/2 tab: + + ....if (condition) { + ------->do_smthg(); + ....} + +or tab only: + + ------->if (condition) { + ------->------->do_smthg(); + ------->} + + +### Creating a patch + + diff -Naur old/PACKAGE-VERSION PACKAGE-VERSION > fix_FTBFS4Hurd.patch + + +* * * + + +Known problems +-------------- + +### Dynamically allocated buffer returned by a function + +Use a static buffer + +### Buffer used to format an expression containing an INTEGER + +The length of an INTEGER in a string can be up to sizeof (int) * 3 + 1. + +> The usual trick for "%d" is to use the constant 'sizeof (int) * 3 + 1'. +I included + 1 for the sign, but it's not really necessary +if we exepect sizeof(int) >= 2, which we probably should. +**Jérémie Koenig** + + log(MAX_INT) + = log(2 ^ 32) + = 32 * log(2) + = 4 * 8 * log(2) + = sizeof(int) * 2.40823997 + < sizeof(int) * 3 + + +### Proper use of realloc() + +use a new_buff to check if everything went fine Free buf if realloc failed (and prog doesn't exit) + + +### Reading lines from file + +Function to read line (no size limit, ending with "\n") from a file. + + static char *get_line(FILE *f) + { + char *buff = NULL; + char *new_buff = NULL; + size_t buff_size = 0; + size_t last = 0; + + while (!feof(f)) { + buff_size = buff_size ? buff_size * 2 : BUFSIZ; + new_buff = realloc(buff, buff_size); + if (new_buff == NULL) { + free(buff); + return NULL; + } + buff = new_buff; + if (fgets(buff + last, buff_size - last, f) == NULL) { + free(buff); + return NULL; + } + last = strlen(buff); + if (buff[last - 1] == '\n') + return buff; + } + return buff; + } + + +### Proper use of readlink() + +One has to rely on lstat() to get the size of the link that readlink() returns. + +Declare what you need: + + char *linkname = NULL; + struct stat sb; + ssize_t len = -1; + +Call lstat() and check return value: + + if (lstat(filename, &sb) == -1) { + +Create a buffer of the appropriate size and check the return value: + + linkname = malloc(sb.st_size + 1); + if (linkname == NULL) { + +Call readlink(), check return value and set the null char in the linkname: + + len = readlink(filename, linkname, sb.st_size + 1); + if (len < 0 || len > sb.st_size) { + ... + linkname[sb.st_size] = '\0'; + + +### Alternative use of readlink(): readlink_malloc() + +In some cases the above approch doesn't work.for instance when reading from +**/proc/*/exe** on Linux. In this case you can try the following function. +The code comes from [[https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/coding/806-BSI.html]] + + static char *readlink_malloc(const char *filename) + { + int size = 100; + + while (1) { + char *buff = malloc(size); + if (buff == NULL) + return NULL; + int nchars = readlink(filename, buff, size); + if (nchars < 0) + return NULL; + if (nchars < size) { + buff[nchars] = '\0'; + return buff; + } + free (buff); + size *= 2; + } + } + diff --git a/user/tlecarrour/rng-tools.mdwn b/user/tlecarrour/rng-tools.mdwn new file mode 100644 index 00000000..4ea60ac8 --- /dev/null +++ b/user/tlecarrour/rng-tools.mdwn @@ -0,0 +1,58 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + +rng-tools +========= + +Daemon to use a Hardware TRNG. The rngd daemon acts as a bridge between a Hardware TRNG (true random number generator) such as the ones in some Intel/AMD/VIA chipsets, and the kernel's PRNG (pseudo-random number generator). +(from [[http://packages.debian.org/lenny/rng-tools]]) + +[[!toc startlevel=2]] + + +* * * + + +Log +--- + +* **Started**: 2012-01-28 +* **Discussed**: [2012-01-30](http://lists.debian.org/debian-hurd/2012/01/msg00177.html) +* **Draft Submitted**: - +* **Submitted**: - +* **Accepted**: - + + +* * * + + +ToDo +---- + +Here is the output of `grep -R PATH_MAX rng-tools-2-unofficial-mt.14/*`: + + viapadlock_engine.c:static char cpudev_path[PATH_MAX+1]; + viapadlock_engine.c:char devpath[PATH_MAX+1]; + + +* * * + + +Comments +-------- + +Work in progress, see related [thread](http://lists.debian.org/debian-hurd/2012/01/msg00177.html). + +Even if the **PATH_MAX** can be easily fixed, some problems remain. +The code uses `linux/types.h`, that has to be replaced by `sys/types.h`, but also uses `linux/random.h` which has no equivalent I know of. +At least one source file is named after the OS: `rngd_linux.c`. diff --git a/user/tlecarrour/sakura.mdwn b/user/tlecarrour/sakura.mdwn new file mode 100644 index 00000000..d0cd8711 --- /dev/null +++ b/user/tlecarrour/sakura.mdwn @@ -0,0 +1,77 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + +sakura +====== + +Simple but powerful libvte-based terminal emulator. +**Home page**: [[http://www.pleyades.net/david/sakura.php]] + +[[!toc startlevel=2]] + + +* * * + + +Log +--- + +* **Started**: 2012-02-03 +* **Discussed**: [2012-02-03](http://lists.debian.org/debian-hurd/2012/02/msg00031.html) +* **Draft Submitted**: - +* **Submitted**: 2012-02-07, Bug#[659018](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659018) +* **Accepted**: - + + +* * * + + +ToDo +---- + +Here is the output of `grep -R PATH_MAX sakura-2.4.2/*`: + + src/sakura.c: char buf[PATH_MAX+1]; + + +* * * + + +Comments +-------- + + + char *buf = NULL; + + struct stat sb; + +Will dynamically allocate the buffer according to information provided by `lstat()`. + + + if (lstat(file, &sb) == -1) { + + return cwd; + + } + + buf = malloc(sb.st_size + 1); + +Do the allocation. Don't bother to check for return value as `g_strdup_printf()` doesn't do it. + + + len = readlink (file, buf, sb.st_size + 1); + + + if (len < 0 || len > sb.st_size) { + + g_free(buf); + + return cwd; + + } + +Check `realink()` return value. + + + g_free(buf); + +Free the dynamically allocated buffer. + diff --git a/user/tlecarrour/schism.mdwn b/user/tlecarrour/schism.mdwn new file mode 100644 index 00000000..3f726832 --- /dev/null +++ b/user/tlecarrour/schism.mdwn @@ -0,0 +1,116 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + +schism +====== + +ImpulseTracker clone aiming at providing the same look&feel. +**Home page**: [[http://nimh.org/schismtracker]] + +[[!toc startlevel=2]] + + +* * * + + +Log +--- + +* **Started**: - +* **Discussed**: - +* **Draft Submitted**: - +* **Submitted**: - +* **Accepted**: - + + +* * * + + +ToDo +---- + +Here is the output of `grep -R PATH_MAX schism-0+20110101/*`: + + include/disko.h: char tempname[PATH_MAX]; + include/disko.h: char filename[PATH_MAX]; + include/headers.h:# undef PATH_MAX + schism/disko.c: if (len + 6 >= PATH_MAX) { + schism/audio_loadsave.c:char song_filename[PATH_MAX + 1]; + schism/audio_loadsave.c: strncpy(song_filename, file, PATH_MAX); + schism/audio_loadsave.c: song_filename[PATH_MAX] = '\0'; + schism/page_loadmodule.c:static char filename_entry[PATH_MAX + 1] = ""; + schism/page_loadmodule.c:static char dirname_entry[PATH_MAX + 1] = ""; + schism/page_loadmodule.c:char cfg_module_pattern[PATH_MAX + 1] = GLOB_DEFAULT; + schism/page_loadmodule.c:static char glob_list_src[PATH_MAX + 1] = ""; // the pattern used to make glob_list (this is an icky hack) + schism/page_loadmodule.c: strncpy(glob_list_src, globspec, PATH_MAX); + schism/page_loadmodule.c: glob_list_src[PATH_MAX] = '\0'; + schism/page_loadmodule.c: strncpy(cfg_dir_modules, ptr, PATH_MAX); + schism/page_loadmodule.c: cfg_dir_modules[PATH_MAX] = 0; + schism/page_loadmodule.c: create_textentry(widgets_loadmodule + 2, 13, 46, 64, 0, 3, 3, NULL, filename_entry, PATH_MAX); + schism/page_loadmodule.c: create_textentry(widgets_loadmodule + 3, 13, 47, 64, 2, 3, 0, NULL, dirname_entry, PATH_MAX); + schism/page_loadmodule.c: create_textentry(widgets_exportsave + 2, 13, 46, 64, 0, 3, 3, NULL, filename_entry, PATH_MAX); + schism/page_loadmodule.c: create_textentry(widgets_exportsave + 3, 13, 47, 64, 2, 0, 0, NULL, dirname_entry, PATH_MAX); + schism/util.c: char buf[PATH_MAX]; + schism/util.c: if (strlen(filename) > PATH_MAX - 16) { + schism/util.c: char buf[PATH_MAX + 1]; + schism/util.c: if (getcwd(buf, PATH_MAX)) + schism/util.c: char buf[PATH_MAX + 1]; + schism/util.c: if (getcwd(buf, PATH_MAX)) + schism/util.c: char buf[PATH_MAX + 1]; + schism/util.c: char buf[PATH_MAX]; + schism/util.c: char buf2[PATH_MAX]; + schism/util.c: if (!GetCurrentDirectory(PATH_MAX-1,buf)) return 0; + schism/util.c: snprintf(buf2, PATH_MAX-2, "%s.bat", name); + schism/main.c: strncpy(cfg_dir_modules, initial_dir, PATH_MAX); + schism/main.c: cfg_dir_modules[PATH_MAX] = 0; + schism/main.c: strncpy(cfg_dir_samples, initial_dir, PATH_MAX); + schism/main.c: cfg_dir_samples[PATH_MAX] = 0; + schism/main.c: strncpy(cfg_dir_instruments, initial_dir, PATH_MAX); + schism/main.c: cfg_dir_instruments[PATH_MAX] = 0; + schism/page_loadinst.c:static char inst_cwd[PATH_MAX+1] = ""; + schism/page_loadinst.c:static char slash_search_str[PATH_MAX]; + schism/page_loadinst.c: strncpy(cfg_dir_instruments, ptr, PATH_MAX); + schism/page_loadinst.c: cfg_dir_instruments[PATH_MAX] = 0; + schism/page_loadinst.c: strncpy(inst_cwd, ptr, PATH_MAX); + schism/page_loadinst.c: inst_cwd[PATH_MAX] = 0; + schism/page_loadinst.c: if (slash_search_mode < PATH_MAX) { + schism/config.c:char cfg_dir_modules[PATH_MAX + 1], cfg_dir_samples[PATH_MAX + 1], cfg_dir_instruments[PATH_MAX + 1], + schism/config.c: cfg_dir_dotschism[PATH_MAX + 1], cfg_font[NAME_MAX + 1]; + schism/config.c: strncpy(cfg_dir_dotschism, ptr, PATH_MAX); + schism/config.c: cfg_dir_dotschism[PATH_MAX] = 0; + schism/config.c: cfg_get_string(&cfg, "Directories", "modules", cfg_dir_modules, PATH_MAX, tmp); + schism/config.c: cfg_get_string(&cfg, "Directories", "samples", cfg_dir_samples, PATH_MAX, tmp); + schism/config.c: cfg_get_string(&cfg, "Directories", "instruments", cfg_dir_instruments, PATH_MAX, tmp); + schism/config.c: strncpy(cfg_module_pattern, ptr, PATH_MAX); + schism/config.c: cfg_module_pattern[PATH_MAX] = 0; + schism/page_vars.c: cfg_dir_modules, PATH_MAX); + schism/page_vars.c: cfg_dir_samples, PATH_MAX); + schism/page_vars.c: cfg_dir_instruments, PATH_MAX); + schism/page_loadsample.c:static char current_filename[PATH_MAX]; + schism/page_loadsample.c:static char search_str[PATH_MAX]; + schism/page_loadsample.c: PATH_MAX-1); + schism/page_loadsample.c: PATH_MAX-1); + schism/page_loadsample.c: strncpy(cfg_dir_samples, ptr, PATH_MAX); + schism/page_loadsample.c: cfg_dir_samples[PATH_MAX] = 0; + schism/page_loadsample.c: if (search_pos < PATH_MAX) { + + +* * * + + +Comments +-------- + +Not yet started. + +Looks like a lot, but most of them, if not all, are trivial. diff --git a/user/tlecarrour/shush.mdwn b/user/tlecarrour/shush.mdwn new file mode 100644 index 00000000..68a824f0 --- /dev/null +++ b/user/tlecarrour/shush.mdwn @@ -0,0 +1,75 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + +shush +===== + +Runs a command and optionally reports its output by mail. +**Home page**: [[http://web.taranis.org/shush]] + +[[!toc startlevel=2]] + + +* * * + + +Log +--- + +* **Started**: - +* **Discussed**: - +* **Draft Submitted**: - +* **Submitted**: - +* **Accepted**: - + + +* * * + + +ToDo +---- + +Here is the output of `grep -R PATH_MAX shush-1.2.3/*`: + + src/shush.c: char cfdir[PATH_MAX+1], *slfac, *to[3]; + src/shush.c: strlcpy(cfdir+1, optarg, PATH_MAX); + src/shush.c: snprintf(cfdir+1, PATH_MAX, "%s/.shush", getenv("HOME")); + src/crontab.c: static char cfname[PATH_MAX]; + src/crontab.c: snprintf(cfname, PATH_MAX, "%s/schedule", cfdname); + src/crontab.c: snprintf(cfname, PATH_MAX, "%s/%s", cfdname, token); + src/crontab.c: snprintf(cfname, PATH_MAX, "%s/%s", cfdname, entry->d_name); + src/crontab.c: char tag[PATH_MAX+80], *oldtab, *mytab, newtab[PATH_MAX]; + src/crontab.c: snprintf(newtab, PATH_MAX, "%s/%s-crontab.XXXXXX", + src/state.c:static char statepath[PATH_MAX]; + src/state.c: snprintf(statepath, PATH_MAX, "%s/.state/shtate-%lu-%s-%s-%u", + src/state.c: snprintf(statepath, PATH_MAX, "%s/shtate-%lu-%s-%s-%u", + src/run.c: char fname[PATH_MAX], outlog[PATH_MAX], errlog[PATH_MAX], *outstr, *errstr; + src/run.c: snprintf(fname, PATH_MAX, "%s/%s", cfdir, job); + src/run.c: snprintf(outlog, PATH_MAX, "%s.stdout", cf_getstr(CF_CONFIG)); + src/run.c: snprintf(errlog, PATH_MAX, "%s.stderr", cf_getstr(CF_CONFIG)); + src/run.c: snprintf(fname, PATH_MAX, "%s/.%s-%s", cfdir, jid, get_hostname(0)); + src/run.c: snprintf(outlog, PATH_MAX, "%s/%s-%s.stdout.XXXXXX", + src/run.c: snprintf(errlog, PATH_MAX, "%s/%s-%s.stderr.XXXXXX", + src/check.c: char fname[PATH_MAX], outre[PATH_MAX], errre[PATH_MAX], *outstr, *errstr; + src/check.c: snprintf(fname, PATH_MAX, "%s/%s", cfdir, job); + src/check.c: snprintf(outre, PATH_MAX, "%s.stdout", cf_getstr(CF_CONFIG)); + src/check.c: snprintf(errre, PATH_MAX, "%s.stderr", cf_getstr(CF_CONFIG)); + + +* * * + + +Comments +-------- + +Not yet started. diff --git a/user/tlecarrour/sitecopy.mdwn b/user/tlecarrour/sitecopy.mdwn new file mode 100644 index 00000000..11f512ae --- /dev/null +++ b/user/tlecarrour/sitecopy.mdwn @@ -0,0 +1,73 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + +sitecopy +======== + +A program for managing a WWW site via FTP, DAV or HTTP. +**Home page**: [[http://www.manyfish.co.uk/sitecopy]] + +[[!toc startlevel=2]] + + +* * * + + +Log +--- + +* **Started**: - +* **Discussed**: - +* **Draft Submitted**: - +* **Submitted**: - +* **Accepted**: - + + +* * * + + +ToDo +---- + +Here is the output of `grep -R PATH_MAX sitecopy-0.16.6/*`: + + intl/dcigettext.c: PATH_MAX but might cause redefinition warnings when sys/param.h is + intl/dcigettext.c:#ifndef _POSIX_PATH_MAX + intl/dcigettext.c:# define _POSIX_PATH_MAX 255 + intl/dcigettext.c:#if !defined PATH_MAX && defined _PC_PATH_MAX + intl/dcigettext.c:# define PATH_MAX (pathconf ("/", _PC_PATH_MAX) < 1 ? 1024 : pathconf ("/", _PC_PATH_MAX)) + intl/dcigettext.c:#if defined HAVE_SYS_PARAM_H && !defined PATH_MAX && !defined MAXPATHLEN + intl/dcigettext.c:#if !defined PATH_MAX && defined MAXPATHLEN + intl/dcigettext.c:# define PATH_MAX MAXPATHLEN + intl/dcigettext.c:#ifndef PATH_MAX + intl/dcigettext.c:# define PATH_MAX _POSIX_PATH_MAX + intl/dcigettext.c: path_max = (unsigned int) PATH_MAX; + src/ftp.c:#include <limits.h> /* for PATH_MAX */ + src/ftp.c:#ifndef PATH_MAX + src/ftp.c:#define PATH_MAX 2048 + src/ftp.c: char cwd[PATH_MAX]; + src/ftp.c: char dir[PATH_MAX]; + src/ftp.c: if (!sess->use_cwd || fn[0] != '/' || strlen(fn) > PATH_MAX) + debian/patches/10_bts410703_preserve_storage_files_sigint.dpatch:+ char filebuf[PATH_MAX]; + debian/patches/10_bts410703_preserve_storage_files_sigint.dpatch:+ char filebuf[PATH_MAX]; + + +* * * + + +Comments +-------- + +Not yet started. + +One of the PATH_MAX if used in debian patch. diff --git a/user/tlecarrour/suckless-tools.mdwn b/user/tlecarrour/suckless-tools.mdwn new file mode 100644 index 00000000..2a3cb5df --- /dev/null +++ b/user/tlecarrour/suckless-tools.mdwn @@ -0,0 +1,79 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +suckless-tools +============== + +Home of dwm, dmenu and other quality software with a focus on simplicity, clarity, and frugality. +**Home page**: [[http://suckless.org]] + +[[!toc startlevel=2]] + + +* * * + + +Log +--- + +* **Started**: 2012-01-31 +* **Discussed**: [2012-01-31](http://lists.debian.org/debian-hurd/2012/01/msg00191.html) +* **Draft Submitted**: [2012-02-01](http://lists.debian.org/debian-hurd/2012/02/msg00001.html) +* **Submitted**: 2012-02-02, Bug#[658386](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658386) +* **Accepted**: - + + +* * * + + +ToDo +---- + +Here is the output of `grep -R PATH_MAX suckless-tools-38/*`: + + dmenu/dmenu_path.c: char buf[PATH_MAX]; + + +* * * + + +Comments +-------- + +Here are comments on the patch... + + void + scan(void) { + - char buf[PATH_MAX]; + + char *buf = NULL; + + char *new_buf = NULL; + + size_t buf_size = 0; + +In this function we turn `buf` into dynamically allocated string. + + + while((ent = readdir(dp))) { + + buf_size = strlen(dir)+strlen(ent->d_name)+2; + + if(!buf || strlen(buf) < buf_size) { + + new_buf = realloc(buf, buf_size); + + if(!new_buf) + + die("realloc failed"); + + buf = new_buf; + + } + +For each directory entry we create or adapt the buffer size. + + + } + + free(buf); + +We free the buf when done. + diff --git a/user/tlecarrour/up-imapproxy.mdwn b/user/tlecarrour/up-imapproxy.mdwn new file mode 100644 index 00000000..f97207e0 --- /dev/null +++ b/user/tlecarrour/up-imapproxy.mdwn @@ -0,0 +1,59 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + +up-imapproxy +============ + +SquirrelMail's IMAP Proxy is a caching IMAP proxy server intended for use with webmail clients that cannot maintain persistent connections to an IMAP server. +**Home page**: [[http://www.imapproxy.org]] + +[[!toc startlevel=2]] + + +* * * + + +Log +--- + +* **Started**: 2012-01-31 +* **Discussed**: [2012-02-03](http://lists.debian.org/debian-hurd/2012/02/msg00027.html) +* **Draft Submitted**: - +* **Submitted**: - +* **Accepted**: - + + +* * * + + +ToDo +---- + +Here is the output of `grep -R PATH_MAX up-imapproxy-1.2.7/*`: + + src/main.c: char f_randfile[ PATH_MAX ]; + + +* * * + + +Comments +-------- + +Work in progress... + +Only the function that fills the buffer knows how long it can be. +This function is `RAND_file_name()` and is part of **OpenSSL**. + +Probably **OpenSSL** function has to be fixed first to accept `NULL` buffer. +Then fix the up-imapproxy code to use the new version of the function. diff --git a/user/tschwinge.mdwn b/user/tschwinge.mdwn index 2c75292b..eea5480c 100644 --- a/user/tschwinge.mdwn +++ b/user/tschwinge.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,8 +10,8 @@ is included in the section entitled [[!meta title="Thomas Schwinge"]] -<tschwinge@gnu.org> +<thomas@schwinge.name> Germany -<http://www.thomas.schwinge.homeip.net/> +<http://schwinge.homeip.net/~thomas/> diff --git a/user/zhengda.mdwn b/user/zhengda.mdwn index e15aade1..a7f57f35 100644 --- a/user/zhengda.mdwn +++ b/user/zhengda.mdwn @@ -2,14 +2,47 @@ Email: zhengda1936 at gmail dot com -Project: Network virtualization for subhurds etc. +--- + +#Project: Porting DDE to Hurd. + +##The goal: +porting DDE developed by DROPS to the Hurd, and it will still run in the user space. + +##Introduction +The introduction of DDE/DDEKit can be found in [here](http://wiki.tudos.org/DDE/DDEKit) and more information can be found [here](http://os.inf.tu-dresden.de/pipermail/l4-hackers/2009/004291.html). DDE/DDEKit is a library, and it should be compiled with the code of Linux or FreeBSD drivers. DDE Linux26 is still under development and it can now support network and block devices (but doesn't support SCSI). + +##The current status +Currently a few NIC cards work now. I tested pcnet32, e100, e1000, ne2k-pci and rtl8139 in VMWare and Qemu. But the DDE e100 driver cannot work for some e100 cards as currently DDE doesn't support firmware. Someone also reported sis900 cannot work, unfortunately, I cannot test it myself. I appreciate if someone can try some other NIC drivers and give me some feedbback. Please run DDE with GNUMach in the [master-user_level_drivers](http://git.savannah.gnu.org/cgit/hurd/gnumach.git/) branch. + +## My work +I separate DDE Linux26 to 2 parts: libddekit and libdde_linux26. I also provide a library called libmachdev on the top of the Linux code to provide the Mach device interface, so it is easy for the user to compile a Linux driver and run it in the Hurd. The latest code can be found in the dde branch of the incubator repository. + +There is a minor problem when we compile a Linux driver. Linux drivers use jiffies to measure time. Unfortunately, Mach doesn't provide it, so whenever we need it, we need to calculate it by ourselves. I decide to provide a macro to calculate it for the sake of performance and the cost is that the source code of Linux drivers has to include ddekit/timer.h. + +## Build and run DDE drivers + +To build a Linux driver with DDE Linux, we need libddekit, libdde_linux26, libmachdev and libhurd-slab. libddekit and libmachdev use the same Makefile system as other Hurd components but libdde_linux26 does not, so we have to build libdde_linux26 in its source file directory. DDE drivers use the same makefile system as libdde_linux26 and thus we need to build them in their source file directories as well. + +The repository has all DDE drivers I have tested, but in case you want to try other drivers, the easiest way is to use dde_pcnet32 as a template. The directory of dde_pcnet32 has Makefile, Makeconf.local, default.ld, pcnet32.c and main.c. If we need to build a new driver file, we only need to replace pcnet32.c with the new file and change Makefile accordingly. You also need to change DDEKITLIBDIR, DDEKITINCDIR, DDE26LIBDIR and OBJ_BASE in Makeconf.local to indicate the path to ddekit and dde_linux26. + +When all parts are ready, we can start to build DDE drivers now. In case someone hasn't installed libpciaccess, please install it first. We first build libddekit, libdde-slab, then libdde_linux26, then libmachdev and at last the DDE driver. It's better to install libddekit, libdde-slab and libmachdev to the system, so libdde_linux26 and the DDE driver find the library files and header files. + +To run a DDE NIC driver: It is better to disable the corresponding kernel drivers in GNU Mach. For example, if we use the pcnet card, we'd better disable lance and pcnet32 drivers in gnumach. DDE requires the pfinet with modification during my GSoC project in 2008 and that pfinet requires libpcap-dev (this pfinet is also in the dde branch). -The [code](http://www.assembla.com/spaces/VNetHurd/trac_subversion_tool). +settrans -acfg pcnet32 hurd/dde_pcnet32/dde_pcnet32 -The [[howto]] shows the instructions of setting up the virtual network in hurd and subhurd. +settrans -acfg /dev/eth0 hurd/devnode/devnode eth0 -M pcnet32 + +settrans -acfg /servers/socket/2 hurd/pfinet/pfinet -i /dev/eth0 -a 172.16.172.10 -g 172.16.172.2 -m 255.255.255.0 --- +#Project: Network virtualization for subhurds etc. + +The [code](http://www.assembla.com/spaces/VNetHurd/trac_subversion_tool). The [[howto]] shows the instructions of setting up the virtual network in hurd and subhurd. + + ## The design and the implementation ### The requirements: @@ -45,32 +78,26 @@ A filter translator is needed to enforce the policies between the interface and * BPF is also ported to the filter translator. There are two filers in the translator, one for outgoing packets, the other for incoming packets. * Only one pfinet can connect to the translator at a time. - ---- - ## TODO ### Coding - - make subhurds running without root privileges - merge BPF rules from the filter translator and the multiplexer ---- - ## Completed tasks ### Coding -The patch of glibc (pfinet server overriding) is [here](http://www.assembla.com/spaces/VNetHurd/documents/aJidqKp6ur3z-Nab7jnrAJ/download/A%20patch%20of%20glibc). +The patch of glibc (pfinet server overriding) is [here](http://www.assembla.com/spaces/VNetHurd/documents/aJidqKp6ur3z-Nab7jnrAJ/download/A%20patch%20of%20glibc), commited to debian for 2.11.2-7 and later. The patch of pfinet (open the virtual network interface) is [here](http://www.assembla.com/spaces/VNetHurd/documents/aWqYwYATKr3BBOab7jnrAJ/download/patch%20of%20pfinet%201%20(to%20use%20the%20virtual%20interface)). The patch of pfinet (fix pfinet to use the proper filter rule) is [here](http://www.assembla.com/spaces/VNetHurd/documents/besb-qATKr3AIxab7jnrAJ/download/patch%20of%20pfinet%202%20(to%20add%20an%20IP%20filter)). -The patch of pfinet (set the mach device in the promiscuous mode) is [here](http://www.assembla.com/spaces/VNetHurd/documents/bEovN6ATKr3B8uab7jnrAJ/download/patch%20of%20pfinet%203%20(to%20set%20the%20mach%20device%20into%20the%20promiscuous%20mode)). +The patch of pfinet (set the mach device in the promiscuous mode) is [here](http://www.assembla.com/spaces/VNetHurd/documents/bEovN6ATKr3B8uab7jnrAJ/download/patch%20of%20pfinet%203%20(to%20set%20the%20mach%20device%20into%20the%20promiscuous%20mode)), commited on 20100920. -The patch of boot (open the virtual network interface) is [here](http://www.assembla.com/spaces/VNetHurd/documents/cWkeEixHar3AdKab7jnrAJ/download/A%20patch%20of%20boot). +The patch of boot (open the virtual network interface) is [here](http://www.assembla.com/spaces/VNetHurd/documents/cWkeEixHar3AdKab7jnrAJ/download/A%20patch%20of%20boot), commited on 20100920. -The patch of gnumach (set the network device into the promiscuous mode) is [here](http://www.assembla.com/spaces/VNetHurd/documents/b0eLzUxHmr3ymXab7jnrAJ/download/A%20patch%20of%20gnumach). +The patch of gnumach (set the network device into the promiscuous mode) is [here](http://www.assembla.com/spaces/VNetHurd/documents/b0eLzUxHmr3ymXab7jnrAJ/download/A%20patch%20of%20gnumach), commited on 20100920. the multiplexer: @@ -92,11 +119,6 @@ the devnode translator: - Create a device file to help open the network device. - -### The Code Read - -- boot - ### Documentation Read diff --git a/user/zhengda/howto.mdwn b/user/zhengda/howto.mdwn index a2664a18..1258ffed 100644 --- a/user/zhengda/howto.mdwn +++ b/user/zhengda/howto.mdwn @@ -38,7 +38,7 @@ In this section, I show how to create two virtual interfaces and run three pfine Step 4: create the network device file in /dev with devnode. The network device file is used to help other translators open the device. - # settrans -acfg /dev/eth0 /root/hurd/devnode/devnode -d eth0 + # settrans -acfg /dev/eth0 /root/hurd/devnode/devnode eth0 Step 5: create the virtual network device with eth-multiplexer. diff --git a/virtualization.mdwn b/virtualization.mdwn index 52131c12..78457eb9 100644 --- a/virtualization.mdwn +++ b/virtualization.mdwn @@ -1,18 +1,28 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + * [[hurd/virtualization]] in the GNU Hurd's context. + # External + * [*Emulation: Role-Playing for + Computers*](http://www.informit.com/articles/printerfriendly.aspx?p=659522), + an article by David Chisnall. + + * [*Virtual Machines*](http://virtualsquare.org/vm.html). + * Wikipedia page about [[!wikipedia Virtualization]]. -# See Also +# Open Issues - * [[Emulation]]. + * [[open_issues/Virtualization]] |
