deps: bump uart_16550 to 0.6.0#565
Conversation
phip1611
changed the title
Uart16550 has a layout of (32 /* size*/, 4 /* align*/) whereas the old SerialPort had (2, 2). The test shows that this small change is sufficient to fail the test with the old stack size. We slightly increase the stack therefore.
| const BOOTLOADER_CONFIG: BootloaderConfig = { | ||
| let mut config = BootloaderConfig::new_default(); | ||
| config.kernel_stack_size = 3000; | ||
| config.kernel_stack_size = 3032; |
There was a problem hiding this comment.
Judging by the generated assembly, my guess is that most of the stack usage seems to come from Result<T, Uart16550TtyError>. Uart16550TtyError is quite big (36 bytes). On lower optimization levels, the compiler isn't very smart about this and allocates a variable slot on the stack for every function call that returns Result<T, Uart16550TtyError>.
Let's add some safety margin to make sure this doesn't get tripped by future small regressions. How about 4000?
Freax13
left a comment
Freax13
left a comment
There was a problem hiding this comment.
Thank you for your contribution!
| use core::fmt; | ||
| use uart_16550::backend::PioBackend; | ||
|
|
||
| pub struct SerialPort { |
There was a problem hiding this comment.
Should we replace SerialPort with Uart16550Tty? Both implement core::fmt::Write, so I don't see much of a reason to keep SerialPort around. Uart16550Tty also does the \n to \r\n conversion SerialPort does.
| const BOOTLOADER_CONFIG: BootloaderConfig = { | ||
| let mut config = BootloaderConfig::new_default(); | ||
| config.kernel_stack_size = 3000; | ||
| config.kernel_stack_size = 3032; |
There was a problem hiding this comment.
Judging by the generated assembly, my guess is that most of the stack usage seems to come from Result<T, Uart16550TtyError>. Uart16550TtyError is quite big (36 bytes). On lower optimization levels, the compiler isn't very smart about this and allocates a variable slot on the stack for every function call that returns Result<T, Uart16550TtyError>.
Let's add some safety margin to make sure this doesn't get tripped by future small regressions. How about 4000?
2 participants
Let's use the latest and greatest version