uart: Superfluous syscalls for driver API

[pfalcon]

Split from #10761 (comment)

"Even more surprising was that bunch of IRQ-related functionality of UART API was made userspace syscalls. @andrewboie, how did we get to that? Even with reading the docstring, it's pretty clear that uart_irq_tx_enable() is IRQ related. What's the point of exporting it userspace, like, user calls uart_irq_tx_enable(), what happens next? It's not possible to define ISR callback from userspace anyway. And most of the UART API is strictly related to interrupt-driven mode. Only uart_poll_in()/uart_poll_out() could be exposed to userspace (and perhaps err_check()). They're also not too useful, but why not? IMHO, we should fix that ASAP."

[pfalcon]

@nashif : I don't see a good label for userspace-vs-kernel split and/or syscalls. I suggest to create one, as many already introduced syscalls are questionable, so might be a regular topic.

[andrewboie]

What's the point of exporting it userspace, like, user calls uart_irq_tx_enable(), what happens next? It's not possible to define ISR callback from userspace anyway.

The thought process for the current state of the code was that the interrupt callback could be setup at application initialization, but once everything is set up and the app drops most of its threads to user mode, enabling/disabling the interrupt could still be controlled from a user mode thread granted access to that uart device.

If this scenario would never be useful, I have no objections to removing these syscalls.

[pfalcon]

The thought process for the current state of the code was that the interrupt callback could be setup at application initialization, but once everything is set up and the app drops most of its threads to user mode, enabling/disabling the interrupt could still be controlled from a user mode thread granted access to that uart device.

That's exactly the kind of feedback I'm looking for, thanks! And thanks for expanding beyond the original "If you don't think those calls should be there, remove them.". So, I definitely have a stereotype thinking that usermode would work as in Linux, where an app starts in user mode right away. This is both inflexible thinking and pretty far from Zephyr model, we "applications" don't "start", but rather a single one runs on boot.

I'm not closing this right away, let me think on this until release times. Even if there's a theoretic usecase, we may want to account of API status ("legacy" and being replaced by others) and pragmatic matters like keeping syscall set bounded.

[pfalcon]

I guess this should be closed after all. I definitely not up to speed with complete understanding of userspace and its APIs, and even if I'd think I am, I'd be reluctant to change something a more experience colleague set forth, given the good explanations given.

Thanks for guidance @andrewboie here and elsewhere.