Due to a bug (compare #2058) in the make system a more modular structure is not feasible at the moment.

So, now we would have two rtc shell command handlers?

Yes and no - one is called rtc and the other gettime/settime. But the rtc handler will only be active if the peripheral is available, and that is currently not implemented.

Also, the driver shell command (from sys/shell/commands/sc_rtc) would be available only if the rtc module is being used and I expect implementations to only support one of both (either module for legacy implementations or peripheral driver for contemporary ones) during the transition.

That's getting more and more weird. I'll take a look at merging the two interfaces.

They don't offer the same functionality. I'd just eradicate drivers/rtc.

("Would" because I don't want to do the work at the moment.)

@haukepetersen wrote in #2056 (comment) that these shell commands are a doubled effort for the existing test applications.

I think it is necessary to differentiate between interfaces. I agree that a random shell command might be superfluous, but this is not the case for the rtc. I have not looked into the other interfaces yet.

PS:
If none of the interfaces despite rtc should make sense to support, I could also just move the implementation into the rtc shell command if @OlegHahm comes through with a PR that converts the remaining periph/rtc implementations.

@haukepetersen @OlegHahm OK, after looking at the current peripheral drivers and thinking about it I guess I'll just move this PR's rtc command implementation into sys/shell/commands/sc_rtc.c and discard this PR. What do you think?

👍

+1

#2061