summaryrefslogtreecommitdiff
path: root/open_issues/translator_stdout_stderr.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/translator_stdout_stderr.mdwn')
-rw-r--r--open_issues/translator_stdout_stderr.mdwn87
1 files changed, 74 insertions, 13 deletions
diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn
index 14ea1c6d..89efd4e1 100644
--- a/open_issues/translator_stdout_stderr.mdwn
+++ b/open_issues/translator_stdout_stderr.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2013 Free Software
+Foundation, 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,25 +9,69 @@ Sections, no 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]]
-There have been several discussions and proposals already, about adding a
-suitable logging mechanism to translators, for example.
+# "Weird Issue"
-Decide / implement / fix that (all?) running (passive?) translators' output
-should show up on the (Mach / Hurd) console / syslog.
+## IRC, freenode, #hurd, 2013-07-01
+[[!tag open_issue_hurd]]
-[[!taglink open_issue_documentation]]: [[!message-id
-"87oepj1wql.fsf@becket.becket.net"]]
+ <teythoon> oh, btw, there is this weird issue that I cannot figure out
+ <teythoon> I noticed that there is no newline printed by /hurd/init after
+ printing " proc" and " auth"
+ <teythoon> but there *is* a printf("\n"); fflush(stdout); in there
+ <teythoon> it's just not working
+ <pinotree> iirc a newline is supposed to be printed after all the essential
+ servers have been started
+ <pinotree> that one
+ <teythoon> yes
+ <teythoon> but this doesn't happen
+ <teythoon> for whatever reason printf("foo"); yields no output
+ <braunr> how are proc and auth printed ?
+ <teythoon> neither does printf("%s", "foo");
+ <teythoon> using printf
+ <teythoon> but printf("%i fooo", 4); works
+ <youpi> uh
+ <braunr> ??
+ <youpi> and does printf("loooooooooong line") worker?
+ <teythoon> no
+ <youpi> uh
+ <youpi> -er
+ <teythoon> and yes, the code is always fflushing stdout
+ <youpi> perhaps trying to put a sleep(1); to check for timing issues?
+ <teythoon> yes, I suspect something like that
+ <teythoon> b/c *sometimes* my hurd just freezes at this point
+ <braunr> ???
+ <teythoon> after printing proc auth and not printing the newline
+ <braunr> such horror stories .
+ <braunr> ..
+ <teythoon> and I *think* that putting more printfs there for testing
+ purposes makes this worse, but I'm not sure about this
+ <braunr> in case you need to debug using printf, there is the mach_print
+ system call
+ <braunr> (in -dbg kernels)
+[[microkernel/mach/gnumach/interface/syscall/mach_print]].
-[[!taglink open_issue_documentation]]: Neal once had written an email on this
-topic.
+ <teythoon> what's wrong with using printf?
+ <braunr> you need to write the little assembly call yourself, where you
+ intend to use it, because it's not exported by glibc
+ <braunr> printf is an RPC
+ <braunr> teythoon: RPCs are complicated stuff
+ <braunr> in particular in core glibc parts like signal handling
+ <youpi> and printf goes through the console translator
+ <braunr> also, if you don't yet have a console server available, it comes
+ in handy
+ <youpi> better direct output directly to the kernel
-IRC, freenode, #hurd, 2011-11-06
+# `stderr` buffered
+
+## IRC, freenode, #hurd, 2011-11-06
+
+[[!tag open_issue_hurd]]
<youpi> about CLI_DEBUG, you can use #define CLI_DEBUG(fmt, ...) {
fprintf(stderr, fmt, ## __VA_ARGS__); fflush(stderr); }
@@ -40,7 +84,24 @@ IRC, freenode, #hurd, 2011-11-06
<tschwinge> That sounds wrong.
-IRC, freenode, #hurd, 2011-11-23
+# Logging
+
+[[!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-23
<braunr> we'd need a special logging task for hurd servers
<pinotree> if syslog would work, that could be used optionally