From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Wed, 26 Feb 2014 12:32:06 +0100
Subject: IRC.

---
 glibc/file_descriptor.mdwn | 32 +++++++++++++++++++++++++++++++-
 glibc/startup.mdwn         | 16 +++++++++++++++-
 2 files changed, 46 insertions(+), 2 deletions(-)

(limited to 'glibc')

diff --git a/glibc/file_descriptor.mdwn b/glibc/file_descriptor.mdwn
index 2c56d070..78c496b1 100644
--- a/glibc/file_descriptor.mdwn
+++ b/glibc/file_descriptor.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2014 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -11,3 +11,33 @@ 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]]).
+
+
+# IRC, freenode, #hurd, 2013-11-29
+
+[[!tag open_issue_documentation]]
+
+    <gnu_srs> Hi, are there any advantages to use the __USEPORT and
+      HURD_DPORT_USE etc macros?
+    <braunr> some things don't work without htem
+    <teythoon> I wondered that too
+    <teythoon> could you be more specific ?
+    <braunr> i can try
+    <braunr> __USEPORT is merely a wrapper to HURD_DPORT_USE
+    <braunr> HURD_PORT_USE handles concurrent access to ports
+    <braunr> is that enough ?
+    <teythoon> so not using these makes loading the port name racy ?
+    <braunr> shared ones, yes
+    <braunr> mostly, file descriptors
+    <teythoon> ok
+    <teythoon> so yes, that's reason enough ;)
+    <gnu_srs> so even if file descriptor ports are not accessed, it's use is
+      preferred?
+    <gnu_srs> I assume the answer is yes:-D
+    <braunr> gnu_srs: not accessed ?
+    <gnu_srs> file descriptor ports not used, but e.g. auth ports
+    <gnu_srs> there is code in hurd and eglibc sometimes using the macros,
+      sometimes not
+    <braunr> the macro is used when ports are shared
+    <braunr> or can be shared
+    <gnu_srs> k!, thanks
diff --git a/glibc/startup.mdwn b/glibc/startup.mdwn
index b7ab9d96..24553048 100644
--- a/glibc/startup.mdwn
+++ b/glibc/startup.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2014 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -18,3 +18,17 @@ is quite hairy on GNU Hurd systems.
   * [[!message-id "3B7BF2B1.1417CD84@alcor.concordia.ca"]]
 
   * [[!message-id "871xc9qv6y.wl@ulysses.g10code.de"]]
+
+
+# IRC, freenode, #hurd, 2013-12-31
+
+    <youpi> braunr: btw, after patching glibc and trying installing it, do you
+      try rebuilding hurd against it? ext2fs.static often breaks due to details
+    <braunr> youpi: yes
+    <braunr> youpi: always
+    <youpi> ok, good :)
+    <braunr> i want the rootfs to benefit from it too :)
+    <youpi> heh :)
+    <braunr> and yes, there were issues that occurred only in the rootfs
+    <braunr> but because of the special early state, not because of static
+      linking
-- 
cgit v1.2.3