idle kernel changes: run on startup, flashing new kernel after startup #276
@ -729,11 +729,6 @@ async fn load_and_run_idle_kernel(
|
||||
info!("Loading idle kernel");
|
||||
let res = handle_flash_kernel(buffer, control, up_destinations, aux_mutex, routing_table, timer).await;
|
||||
srenblad marked this conversation as resolved
Outdated
|
||||
match res {
|
||||
#[cfg(has_drtio)]
|
||||
Err(Error::DestinationDown) => {
|
||||
let mut countdown = timer.countdown();
|
||||
delay(&mut countdown, Milliseconds(500)).await;
|
||||
}
|
||||
Err(_) => warn!("error loading idle kernel"),
|
||||
_ => (),
|
||||
sb10q
commented
Why does this need to be aware of DRTIO? DRTIO link status is to be handled manually by the user in idle kernels Why does this need to be aware of DRTIO?
DRTIO link status is to be handled manually by the user in idle kernels
srenblad
commented
mwojcik
commented
It was there to ensure that DRTIO was fully set up before a startup kernel would run. It could take a considerable while for all required destinations to start. With an idle kernel that can run on startup as well, I would recommend keeping it. It was there to ensure that DRTIO was fully set up before a startup kernel would run. It could take a considerable while for all required destinations to start. With an idle kernel that can run on startup as well, I would recommend keeping it.
sb10q
commented
This is for the user to handle. That's why we have an API for it. The behavior hardcoded here of waiting for 1 second is messy and not applicable to all use cases. This is for the user to handle. That's why we have an API for it. The behavior hardcoded here of waiting for 1 second is messy and not applicable to all use cases.
mwojcik
commented
Since all subkernels are distributed before the kernel starts (to reduce load and latency when the kernels are actually running), that doesn't give the user an opportunity to act accordingly. However, since idle kernels will be retried and restarted until they can finally run, this check could be removed here. Since all subkernels are distributed before the kernel starts (to reduce load and latency when the kernels are actually running), that doesn't give the user an opportunity to act accordingly. However, since idle kernels will be retried and restarted until they can finally run, this check could be removed here.
sb10q
commented
Idle subkernels and startup subkernels need to be flashed into their respective satellites. I think I mentioned this already. Idle subkernels and startup subkernels need to be flashed into their respective satellites. I think I mentioned this already.
mwojcik
commented
Oh then it would make perfect sense, but that's feasible only after artiq#2498 is implemented. So to get this PR merged before that, let's remove that part. Oh then it would make perfect sense, but that's feasible only after [artiq#2498](https://github.com/m-labs/artiq/issues/2498) is implemented. So to get this PR merged before that, let's remove that part.
|
||||
}
|
||||
|
formatting