Re: Hurd lecture

[Thomas Schwinge]

Hi Brent!

On Thu, 18 Jan 2018 14:08:17 -0500, "Brent W. Baccala"  
wrote:
> FYI, I gave an hour and a half Hurd lecture yesterday at Catholic
> University in Washington, D.C.
> 
> I put a screencast of the lecture on youtube: [...]

Great, I'll be sure to view that!

> Could we add that to the collection of presentations that we've got on the
> documentation page?

If you'd like to, you can add it yourself using the wiki interface at
, or even just as a
patch to the web pages repository,
.  Or, if
you prefer, I'll take care of adding it later on.


Grüße
 Thomas

Re: Upstreaming the glibc Hurd port

[Thomas Schwinge]

Hi Joseph!

On Fri, 19 Jan 2018 00:34:42 +, Joseph Myers  
wrote:
> On Fri, 19 Jan 2018, Samuel Thibault wrote:
> 
> > Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +, wrote:
> > > Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise 
> > > there will be more to get it into a buildable state, e.g. the actual 
> > > libpthread implementation).
> > 
> > What I have pushed is basically only missing the libpthread
> > implementation, so you already have an idea of the minimal set of
> > modifications to get something building (and IIRC essentially passing
> > the testsuite).
> 
> I'd still like to have the libpthread implementation there (with a view to 
> seeing if I can get build-many-glibcs.py working for Hurd with this branch 

Many thanks for your offer!  As far as I'm aware indeed nobody from the
Hurd team has spent time on that yet.

> - if the branch has sources that build for Hurd, I should have some chance 
> of using 
> https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/cross-gnu?h=cross-gnu/master
>  
> to figure out how to do the Hurd-specific pieces that will need adding to 
> build-many-glibcs.py).

Beware that this script is from many years ago -- from times before my
dear CodeSourcery colleagues taught be how to ;-) properly build
cross-compilers.  But yes, cross-gnu did work back then.

Another thing to look into nowadays is David's (CCed) gnuxc,
<87r3vaw4os.fsf@gmail.com">http://mid.mail-archive.com/87r3vaw4os.fsf@gmail.com> "Scripts to build
a Hurd distro",  "GNU OS Cross-Compiler".
(I have not yet looked into that one myself.)

And, the Guix/Hurd effort also is capable of cross-compilation, as far as
I remember.  But probably cross-gnu/gnuxc will already give you enough
pointers of what needs to be done.


Grüße
 Thomas

Re: Hurd lecture

[Ricardo Wurmus]

Hi Brent,

> I put a screencast of the lecture on youtube:
>
> https://www.youtube.com/watch?v=JwsuAEF2FYE

thank you.  This was very interesting.  The introduction to Mach IPC and
memory management was especially good.  I wonder if a shorter variant of
this part of the lecture could be used by new contributors as an
alternative to reading the Mach kernel postscript books.

Personally, I’m very interested in a Single System Image Hurd cluster; I
still have a bunch of unused Sun cluster nodes with x86_64 CPUs, but
sadly there is no high-speed network to connect them all (just regular
old 1G network cards).

In your experience, is high-speed network very important or are there
ways to make it unlikely that memory has to be transferred across nodes?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Upstreaming the glibc Hurd port

[Manolis Ragkousis]

Hello,

On 01/19/18 12:10, Thomas Schwinge wrote:
> Beware that this script is from many years ago -- from times before my
> dear CodeSourcery colleagues taught be how to ;-) properly build
> cross-compilers.  But yes, cross-gnu did work back then.
> 
> Another thing to look into nowadays is David's (CCed) gnuxc,
> <87r3vaw4os.fsf@gmail.com">http://mid.mail-archive.com/87r3vaw4os.fsf@gmail.com> "Scripts to build
> a Hurd distro",  "GNU OS Cross-Compiler".
> (I have not yet looked into that one myself.)
> 
> And, the Guix/Hurd effort also is capable of cross-compilation, as far as
> I remember.  But probably cross-gnu/gnuxc will already give you enough
> pointers of what needs to be done.
> 

Guix should be able to cross-build the hurdish glibc with custom source
with `guix build --target=i586-pc-gnu glibc-hurd --with-source=glibc.tar.gz`

Manolis

Re: Upstreaming the glibc Hurd port

[Joseph Myers]

On Fri, 19 Jan 2018, Thomas Schwinge wrote:

> > - if the branch has sources that build for Hurd, I should have some chance 
> > of using 
> > https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/cross-gnu?h=cross-gnu/master
> >  
> > to figure out how to do the Hurd-specific pieces that will need adding to 
> > build-many-glibcs.py).
> 
> Beware that this script is from many years ago -- from times before my
> dear CodeSourcery colleagues taught be how to ;-) properly build
> cross-compilers.  But yes, cross-gnu did work back then.
> 
> Another thing to look into nowadays is David's (CCed) gnuxc,
> <87r3vaw4os.fsf@gmail.com">http://mid.mail-archive.com/87r3vaw4os.fsf@gmail.com> "Scripts to build
> a Hurd distro",  "GNU OS Cross-Compiler".
> (I have not yet looked into that one myself.)
> 
> And, the Guix/Hurd effort also is capable of cross-compilation, as far as
> I remember.  But probably cross-gnu/gnuxc will already give you enough
> pointers of what needs to be done.

Do you have advice on versions to use of mig / gnumach / hurd?

Currently, build-many-glibcs.py uses (by default) release versions of most 
components other than glibc itself, release branches for gcc / binutils.  
Should the most recent releases from ftp.gnu.org of mig / gnumach / hurd 
be used for building current glibc for Hurd, or is it preferable or 
necessary to use newer development versions of those components?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Upstreaming the glibc Hurd port

[Thomas Schwinge]

Hi!

On Fri, 19 Jan 2018 13:08:01 +, Joseph Myers  
wrote:
> On Fri, 19 Jan 2018, Thomas Schwinge wrote:
> > > [build-many-glibcs.py]

> Do you have advice on versions to use of mig / gnumach / hurd?
> 
> Currently, build-many-glibcs.py uses (by default) release versions of most 
> components other than glibc itself, release branches for gcc / binutils.  
> Should the most recent releases from ftp.gnu.org of mig / gnumach / hurd 
> be used for building current glibc for Hurd, or is it preferable or 
> necessary to use newer development versions of those components?

The current releases should generally be fine, yes.

(This reminds me that I wanted to publish new GNU Mach, MIG, Hurd,
libpthread releases, but no need for you to wait for these, as far as I
know.)


Grüße
 Thomas

Re: Upstreaming the glibc Hurd port

[Joseph Myers]

On Fri, 19 Jan 2018, Thomas Schwinge wrote:

> Hi!
> 
> On Fri, 19 Jan 2018 13:08:01 +, Joseph Myers  
> wrote:
> > On Fri, 19 Jan 2018, Thomas Schwinge wrote:
> > > > [build-many-glibcs.py]
> 
> > Do you have advice on versions to use of mig / gnumach / hurd?
> > 
> > Currently, build-many-glibcs.py uses (by default) release versions of most 
> > components other than glibc itself, release branches for gcc / binutils.  
> > Should the most recent releases from ftp.gnu.org of mig / gnumach / hurd 
> > be used for building current glibc for Hurd, or is it preferable or 
> > necessary to use newer development versions of those components?
> 
> The current releases should generally be fine, yes.

The source file sysdeps/mach/hurd/bits/errno.h is generated from sources 
including some headers from those components.  I don't know how often 
those may change in ways that affect that header, or what versions the 
current header corresponds to, but in any case it's a known issue that 
there are several generated files in the source tree that 
build-many-glibcs.py doesn't yet touch on checkout.

> (This reminds me that I wanted to publish new GNU Mach, MIG, Hurd,
> libpthread releases, but no need for you to wait for these, as far as I
> know.)

Regarding libpthread, I don't propose build-many-glibcs.py support for a 
separate libpthread component; what's relevant is whatever version goes on 
the sthibaul/hurd-builds branch of glibc (set up to build without the old 
add-ons mechanism), and in due course on master.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Hurd lecture

[Brent W. Baccala]

On Fri, Jan 19, 2018 at 4:47 AM, Thomas Schwinge 
wrote:

> > Could we add that to the collection of presentations that we've got on
> the
> > documentation page?
>
> If you'd like to, you can add it yourself using the wiki interface at
> , or even just as a
> patch to the web pages repository,
> .  Or, if
> you prefer, I'll take care of adding it later on.


The web editing interface doesn't seem to be working, and I don't have
write access to the git repositories on either darnassus or savannah.

I'd be happy to add them myself, if somebody would give me the correct
permissions.

agape
brent

Re: Upstreaming the glibc Hurd port

[Joseph Myers]

On Fri, 19 Jan 2018, Thomas Schwinge wrote:

> Hi Joseph!
> 
> On Fri, 19 Jan 2018 00:34:42 +, Joseph Myers  
> wrote:
> > On Fri, 19 Jan 2018, Samuel Thibault wrote:
> > 
> > > Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +, wrote:
> > > > Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise 
> > > > there will be more to get it into a buildable state, e.g. the actual 
> > > > libpthread implementation).
> > > 
> > > What I have pushed is basically only missing the libpthread
> > > implementation, so you already have an idea of the minimal set of
> > > modifications to get something building (and IIRC essentially passing
> > > the testsuite).
> > 
> > I'd still like to have the libpthread implementation there (with a view to 
> > seeing if I can get build-many-glibcs.py working for Hurd with this branch 
> 
> Many thanks for your offer!  As far as I'm aware indeed nobody from the
> Hurd team has spent time on that yet.

This patch adds build-many-glibcs.py support for GNU Hurd.  It is
intended for master, where the builds of the i686-gnu configuration
would fail until sufficient support is merged to master, so completing
build-many-glibcs.py coverage of all glibc ABIs and making results
accurately reflect the broken state of builds for Hurd.  Using
sthibaul/hurd-builds branch, it reaches the glibc build, which then
falls over with errors starting:

In file included from mutex-init.c:19:0:
../mach/lock-intern.h: In function '__spin_lock_init':
../mach/lock-intern.h:41:13: error: 'LLL_INITIALIZER' undeclared (first use in 
this function)
   *__lock = LLL_INITIALIZER;
 ^~~
../mach/lock-intern.h:41:13: note: each undeclared identifier is reported only 
once for each function it appears in
../mach/lock-intern.h: In function '__spin_lock':
../mach/lock-intern.h:50:3: error: implicit declaration of function 'lll_lock' 
[-Werror=implicit-function-declaration]
   lll_lock (__lock, 0);
   ^~~~
In file included from mutex-init.c:20:0:
../mach/lowlevellock.h: At top level:
../mach/lowlevellock.h:21:10: fatal error: mach/gnumach.h: No such file or 
directory
 #include 
  ^~~~

Could Hurd people review how this handles building for Hurd, and
indicate whether the above errors indicate problems with these
changes, or simply incompleteness of the build support on the
sthibaul/hurd-builds branch at present?

2018-01-19  Joseph Myers  

* scripts/build-many-glibcs.py (Context.add_all_configs): Add
i686-gnu configurations.
(Context.run_builds): Include mig, gnumach and hurd in components
considered.
(Context.checkout): Add mig, gnumach and hurd to components.
(Context.checkout_tar): Add URL mappings for mig, gnumach and
hurd.
(Context.bot_cycle): Check for changes to mig, gnumach and hurd.
(Config.build): Install gnumach headers, build mig and install
hurd headers for 'gnu' OS.
(Config.install_gnumach_headers): New function.
(Config.install_hurd_headers): Likewise.
(Glibc.build_glibc): Do not use /usr for 'gnu' OS.  Specifiy MIG
when building for 'gnu' OS.

diff --git a/scripts/build-many-glibcs.py b/scripts/build-many-glibcs.py
index 8849574..6095584 100755
--- a/scripts/build-many-glibcs.py
+++ b/scripts/build-many-glibcs.py
@@ -193,6 +193,8 @@ class Context(object):
  '--with-fpu=vfpv3'])
 self.add_config(arch='hppa',
 os_name='linux-gnu')
+self.add_config(arch='i686',
+os_name='gnu')
 self.add_config(arch='ia64',
 os_name='linux-gnu',
 first_gcc_cfg=['--with-system-libunwind'])
@@ -461,13 +463,15 @@ class Context(object):
 old_versions = {}
 self.build_host_libraries()
 elif action == 'compilers':
-build_components = ('binutils', 'gcc', 'glibc', 'linux')
+build_components = ('binutils', 'gcc', 'glibc', 'linux', 'mig',
+'gnumach', 'hurd')
 old_components = ('gmp', 'mpfr', 'mpc')
 old_versions = self.build_state['host-libraries']['build-versions']
 self.build_compilers(configs)
 else:
 build_components = ('glibc',)
-old_components = ('gmp', 'mpfr', 'mpc', 'binutils', 'gcc', 'linux')
+old_components = ('gmp', 'mpfr', 'mpc', 'binutils', 'gcc', 'linux',
+  'mig', 'gnumach', 'hurd')
 old_versions = self.build_state['compilers']['build-versions']
 self.build_glibcs(configs)
 self.write_files()
@@ -694,7 +698,10 @@ class Context(object):
 'gmp': '6.1.2',
 'linux': '4.14',
 'mpc': '1.1.0',
-'mpfr': '4.0.0'}
+'mpfr': '4.0.0',
+  

Re: Upstreaming the glibc Hurd port

[Samuel Thibault]

Joseph Myers, on ven. 19 janv. 2018 17:23:29 +, wrote:
> or simply incompleteness of the build support on the
> sthibaul/hurd-builds branch at present?

It's still incomplete, yes.

Samuel

Re: Hurd lecture

[Brent W. Baccala]

On Fri, Jan 19, 2018 at 7:35 AM, Ricardo Wurmus  wrote:

>
> Hi Brent,
>
> > I put a screencast of the lecture on youtube:
> >
> > https://www.youtube.com/watch?v=JwsuAEF2FYE
>
> thank you.  This was very interesting.  The introduction to Mach IPC and
> memory management was especially good.  I wonder if a shorter variant of
> this part of the lecture could be used by new contributors as an
> alternative to reading the Mach kernel postscript books.
>

That's a good idea, and I can leverage the work I've already done with the
graphics.  I'll have to think about what we might want in a second video
that isn't in the first one.  Any suggestions?

Personally, I’m very interested in a Single System Image Hurd cluster; I
> still have a bunch of unused Sun cluster nodes with x86_64 CPUs, but
> sadly there is no high-speed network to connect them all (just regular
> old 1G network cards).
>
> In your experience, is high-speed network very important or are there
> ways to make it unlikely that memory has to be transferred across nodes?
>

My experience is that we're nowhere close to 1 Gbps vs 40 Gbps being an
issue.

My primary test environment is a virtual machine that talks to itself as
the "remote", and the performance problems there are severe enough that
running remote programs results in a delay that is noticeable to the human
running the program.

Actually, we're barely even at that point.  Stock hurd can't even execute
remote programs.  You either need to patch the exec server so that it reads
binaries and shared libraries instead of memory mapping them, or use the
multi-client libpager that I've been working on the past six months, but is
still failing some test cases.

See, for example,
http://lists.gnu.org/archive/html/bug-hurd/2016-08/msg00099.html, or do a
reverse chronological search on bug-hurd for "libpager".

At the very end of that video lecture, I suggested how we might address the
performance problems in "netmsg", after we've got a multi-client libpager,
and after we've got a 64-bit user space, and after we've got SMP support.
(Who cares about a cluster where you can only use 4 GB and one core on each
node?)

First, netmsg needs to be rewritten so that it doesn't serialize all the
Mach traffic over a single TCP session.  That's probably its biggest
bottleneck.

After that, I think we should move our networking drivers into a shared
library, so that netmsg can access the PCI device directly.  That would
avoid a lot of context switches, like netmsg <-> TCP/IP stack <-> network
driver.

And it's not as crazy as it might first seem.  Networking devices are
increasingly virtuallized.  Not only can you just fiddle a few software
options to add a virtual PCI device to a virtual machine, but Cisco's vNIC
cards can present themselves as anywhere from 1 to 16 PCI devices.  So just
fiddle a few options in your management console, and even your hardware can
now made a new PCI device appear out of thin air.

So, it makes sense to allocate an entire PCI device to netmsg, and let all
your inter-node Mach traffic run over one interface, while your normal
TCP/IP stack has a separate interface.  Of course, we also need to support
configurations where you can't do that, but I think raw PCI access is going
to be the way to go if you really want performance.

Those are my current thoughts on Hurd cluster performance.  In short,
priorities are:

1. multi-client libpager (nearly usable)
2. 64-bit user space
3. SMP
4. rewrite netmsg to avoid TCP serialization (and other issues)
5. raw PCI device access

agape
brent

Re: Upstreaming the glibc Hurd port

[Joseph Myers]

Incidentally, building for GNU/Linux (at least x86_64) is broken on the 
sthibaul/hurd-builds branch (I suspect, based on the error messages, that 
"t2.26/sched_param" was responsible, but didn't verify that).  (I was 
testing to make sure my build-many-glibcs.py changes didn't affect 
GNU/Linux builds and so are safe to apply to master.  Building for 
GNU/Linux is not of course a priority for the branch, but any such issues 
with changes to non-OS-specific code will need fixing for merging to 
master.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Upstreaming the glibc Hurd port

[Samuel Thibault]

Joseph Myers, on ven. 19 janv. 2018 17:50:19 +, wrote:
> Incidentally, building for GNU/Linux (at least x86_64) is broken on the 
> sthibaul/hurd-builds branch (I suspect, based on the error messages, that 
> "t2.26/sched_param" was responsible, but didn't verify that).

sched_param is very probably a culprit, yes.

Samuel

Re: Upstreaming the glibc Hurd port

[Joseph Myers]

On Fri, 19 Jan 2018, Zack Weinberg wrote:

> On Fri, Jan 19, 2018 at 10:11 AM, Joseph Myers  
> wrote:
> > On Fri, 19 Jan 2018, Thomas Schwinge wrote:
> >
> > The source file sysdeps/mach/hurd/bits/errno.h is generated from sources
> > including some headers from those components.  I don't know how often
> > those may change in ways that affect that header, or what versions the
> > current header corresponds to, but in any case it's a known issue that
> > there are several generated files in the source tree that
> > build-many-glibcs.py doesn't yet touch on checkout.
> 
> Note that there is no particularly good reason to have this file
> checked in.  It's generated with an awk script, and the files it's

I'm not sure if having a non-checked-in generated file override another 
file in the source tree works correctly, the way a checked-in sysdeps file 
does override other files in the source tree.  (sysdeps/gnu/errlist.c is 
another case of a sysdeps generated file - it needs to override 
stdio-common/errlist.c, and for that matter gets included by 
sysdeps/mach/hurd/errlist.c.)

If the search orderings work correctly - both for finding files during the 
build, and for installing the correct bits/errno.h header (and the 
build-tree errlist.c can be properly included from the source-tree 
sysdeps/mach/hurd/errlist.c) - then there shouldn't be any need for either 
sysdeps/mach/hurd/bits/errno.h or sysdeps/gnu/errlist.c to be checked in.

-- 
Joseph S. Myers
jos...@codesourcery.com

Glibc port: commit clenup

[Anatoly A. Kazantsev]

Hello,

I've seen Upstreaming the glibc Hurd port thread and want to help with
the "boring" part of it. As the first step I'm going to go throw all
affected branches and fix/check for following topics:

- Copyright notices (years and wording in licence notice).
- Comment on the first line.
- Drop "Contributed by" notices.
- Code formatting (spaces and indents, etc). I'm pretty sure I won't
  spot everything :-)
- Will check/grep for various "not recommended" things from Glibc
  Coding Style and Conventions manual [1].

I will report on what I won't be able to fix/change myself.

I've discussed with Samuel the way I should organise and commit my
changes on irc.

[1] https://sourceware.org/glibc/wiki/Style_and_Conventions

-- 
Regards,
Anatoly

Re: Upstreaming the glibc Hurd port

[Zack Weinberg]

On Fri, Jan 19, 2018 at 10:11 AM, Joseph Myers  wrote:
> On Fri, 19 Jan 2018, Thomas Schwinge wrote:
>
> The source file sysdeps/mach/hurd/bits/errno.h is generated from sources
> including some headers from those components.  I don't know how often
> those may change in ways that affect that header, or what versions the
> current header corresponds to, but in any case it's a known issue that
> there are several generated files in the source tree that
> build-many-glibcs.py doesn't yet touch on checkout.

Note that there is no particularly good reason to have this file
checked in.  It's generated with an awk script, and the files it's
generated from are Mach and MIG headers that I believe must be present
in order to build glibc for Hurd at all.  If the Hurd build were
testable, I would probably have removed it from the source tree when I
cleaned up the errno.h __need macros, but in the current state I
didn't think it was safe.

That's the only Hurd-specific generated-but-checked-in file that I
know anything about.

zw