-
Notifications
You must be signed in to change notification settings - Fork 334
Offer a means to send the tty to the Apple log system #199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
f0c4d94
0b65533
7740375
4327975
f310710
06c3cf7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,7 @@ | ||
| #pragma once | ||
|
|
||
| /* Initialize ASL logger and local buffer. */ | ||
| void log_init(void); | ||
|
|
||
| /* Send one character to the logger: wait for full lines before actually sending. */ | ||
| void log_put(uint8_t _c); |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,50 @@ | ||
| #include <asl.h> | ||
| #include <pwd.h> | ||
| #include <fcntl.h> | ||
| #include <stdio.h> | ||
| #include <time.h> | ||
|
|
||
| #include <SystemConfiguration/SystemConfiguration.h> | ||
|
|
||
| #include <xhyve/log.h> | ||
|
|
||
| static aslclient log_client = NULL; | ||
| static aslmsg log_msg = NULL; | ||
|
|
||
| static unsigned char buf[4096]; | ||
| /* Index of the _next_ character to insert in the buffer. */ | ||
| static size_t buf_idx = 0; | ||
|
|
||
| /* asl is deprecated in favor of os_log starting with macOS 10.12. */ | ||
| #pragma GCC diagnostic ignored "-Wdeprecated-declarations" | ||
|
|
||
| /* Initialize ASL logger and local buffer. */ | ||
| void log_init(void) | ||
| { | ||
| log_client = asl_open(NULL, NULL, 0); | ||
| log_msg = asl_new(ASL_TYPE_MSG); | ||
| } | ||
|
|
||
|
|
||
| /* Send the content of the buffer to the logger. */ | ||
| static void log_flush(void) | ||
| { | ||
| buf[buf_idx] = 0; | ||
| asl_log(log_client, log_msg, ASL_LEVEL_NOTICE, "%s", buf); | ||
| buf_idx = 0; | ||
| } | ||
|
|
||
|
|
||
| /* Send one character to the logger: wait for full lines before actually sending. */ | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There's a slight risk that hyperkit or the guest might crash with something useful still buffered. There isn't much we can sensibly do if hyperkit has crashed, but a guest crash will look like a VM shutdown and be controlled from the hypervisor PoV -- perhaps (as a future improvement?) we should add a
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good. |
||
| void log_put(uint8_t c) | ||
| { | ||
| if ((c == '\n') || (c == 0)) { | ||
| log_flush(); | ||
| } else { | ||
| if (buf_idx + 2 >= sizeof(buf)) { | ||
| log_flush(); | ||
| } | ||
| buf[buf_idx] = c; | ||
| ++buf_idx; | ||
| } | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we care that
\n\n\n\nwill log a bunch of blank messages? A simpleif (buf_idx == 0) returncheck at the top would fix that if we did.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, that's what I wanted, to keep the current output.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes, that's a good point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, would you happen to know why we have two whales? Maybe it's D4D specific, I have not checked yet, but I'm kinda worried by the backslashes having been processed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was some strangeness wrt how/where motd was handled in linuxkit but that was more than a year ago, I don't recall having seen anything like this recently.
Are you running the getty in a container or within the root? Or even both (which might explain things)?
I presume the console is functional (i.e. you can login and type normally)? If it isn't that might suggest you've got two
gettyprocesses somehow.Only other thought I have is if you had configured two serial ports you would get a getty and motd on both of them, but the patches here would combine them into the logs without indicating which was which. If that were the case I'd expect them to be more mixed up though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before these patches, both whales were already in
console-ring. I have not dug the issue yet, so I can't even answer to your questions now. It was just in case it rang a bell. Thanks for the hints, I'll use them when I focus on the twin-whale-issue.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually looks like I misremembered. In LinuxKit (modern ones at least) it is actually an initscript which cats
/etc/issue(notmotd) to any device with aconsole=on the kernel command line.Looks like
agetty(which LinuxKit uses) will also print/etc/issuebut if it is in a container then that is a different/etc/issue, unless you bind it in or arrange to use a different getty container. LinuxKit demos don't have that bind but maybe you do? Or if you were running getty on the host you would see it.