diff options
Diffstat (limited to 'glibc')
| -rw-r--r-- | glibc/file_descriptor.mdwn | 32 | ||||
| -rw-r--r-- | glibc/process.mdwn | 2 | ||||
| -rw-r--r-- | glibc/startup.mdwn | 16 |
3 files changed, 47 insertions, 3 deletions
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/process.mdwn b/glibc/process.mdwn index ded2e1f7..c8a1ce79 100644 --- a/glibc/process.mdwn +++ b/glibc/process.mdwn @@ -13,7 +13,7 @@ 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. +[[environment_variable]]s, [[file_descriptor]]s, [[hurd/authentication]]. # Startup 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 |