1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
|
[[!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
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no 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]]
# "Weird Issue"
## IRC, freenode, #hurd, 2013-07-01
[[!tag open_issue_hurd]]
<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]].
<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
# `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); }
<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.
# 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
<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
|