yamt commented on code in PR #14695:
URL: https://github.com/apache/nuttx/pull/14695#discussion_r1834185665
##########
drivers/syslog/Kconfig:
##########
@@ -267,19 +267,25 @@ config SYSLOG_STREAM
config SYSLOG_CONSOLE
bool "Log to /dev/console"
- default !ARCH_LOWPUTC && !SYSLOG_CHAR && !RAMLOG_SYSLOG &&
!SYSLOG_RPMSG && !SYSLOG_RTT
+ default !SYSLOG_CHAR && !RAMLOG_SYSLOG && !SYSLOG_RPMSG && !SYSLOG_RTT
Review Comment:
> > it's a valid concern.
> > IMO, using syslog from interrupt is a design mistake.
>
> Why is it mistake? If syslog can't support the interrupt, what's other
kernel facility could do?
syslog is an api for ordinary applications.
it isn't free for an api to be prepared to be used by interrupts. eg.
complex locking.
yes, it's simpler to have a separate api for interrupts, IMO.
> > anyway, it won't be a disaster as syslog_device.c already has a check
for that case. (syslog_dev_outputready)
>
> Different syslog channel has the different capability: uputc/ramlog/rpmsg
support interrupt, console/device/file doesn't support. Since the default
syslog(uputc) support the interrupt before, the change need keep this behavior,
otherwise all board will break.
>
> > for panic, maybe it's enough to make it fall back to up_putc if
g_nx_initstate == OSINIT_PANIC. as the panic logic should have already stopped
moving parts (eg. pause_all_cpu) at that point, it should be ok to use up_putc
in that case.
>
> panic is just one case; driver may output log in interrupt too.
>
> > how do you think?
>
> I think the default syslog channel need support the output from interrupt
to handle all possible case. So, I would suggest improving syslog console to
support the interrupt before making it as default. serial driver framework
already contains the special code to handle the interrupt case, so there is no
block issue to improve it.
have you read https://github.com/apache/nuttx/issues/14662?
do you prefer to sprinkle more serialization in syslog and/or up_putc?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
