[[!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]] oh, btw, there is this weird issue that I cannot figure out I noticed that there is no newline printed by /hurd/init after printing " proc" and " auth" but there *is* a printf("\n"); fflush(stdout); in there it's just not working iirc a newline is supposed to be printed after all the essential servers have been started that one yes but this doesn't happen for whatever reason printf("foo"); yields no output how are proc and auth printed ? neither does printf("%s", "foo"); using printf but printf("%i fooo", 4); works uh ?? and does printf("loooooooooong line") worker? no uh -er and yes, the code is always fflushing stdout perhaps trying to put a sleep(1); to check for timing issues? yes, I suspect something like that b/c *sometimes* my hurd just freezes at this point ??? after printing proc auth and not printing the newline such horror stories . .. and I *think* that putting more printfs there for testing purposes makes this worse, but I'm not sure about this in case you need to debug using printf, there is the mach_print system call (in -dbg kernels) [[microkernel/mach/gnumach/interface/syscall/mach_print]]. what's wrong with using printf? you need to write the little assembly call yourself, where you intend to use it, because it's not exported by glibc printf is an RPC teythoon: RPCs are complicated stuff in particular in core glibc parts like signal handling and printf goes through the console translator also, if you don't yet have a console server available, it comes in handy better direct output directly to the kernel # `stderr` buffered ## IRC, freenode, #hurd, 2011-11-06 [[!tag open_issue_hurd]] about CLI_DEBUG, you can use #define CLI_DEBUG(fmt, ...) { fprintf(stderr, fmt, ## __VA_ARGS__); fflush(stderr); } Isn't stderr in auto-flush mode by default? man setbuf: The standard error stream stderr is always unbuffered by default. tschwinge: "by default" is the important thing here in the case of translators iirc stderr is buffered youpi: Oh! 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 we'd need a special logging task for hurd servers if syslog would work, that could be used optionally no, it relies on services provided by the hurd i'm thinking of something using merely the mach interface e.g. using mach_msg to send log messages to a special port used to reference the logging service which would then store the messages in a circular buffer in ram maybe sending to syslog if the service is available the hurd system buffer if you want