nuta on main
Drop support for ARMv6-M I hav… (compare)
nuta on move-cursor
Update Update Update and 1 more (compare)
nuta on move-cursor
Update Update Update (compare)
Hello @nuta, we have finalized working on resea for our project with our instructor. We have proposed the malloc implementation and zero-copy IPC as the issues that we'd like to tackle.
Also, we're looking forward to try our hands with implementing new features. We saw your project board and we were hooked by some of the ideas like - random number generation and Datetime management server. We're also excited by the idea of writing applications in Rust. As the maintainer and the person behind the thinking, can you please tell us what is in our mind regarding these?
Also, we'll be putting up our thoughts in the issue comments as we go through them. I hope you won't mind assigning them to us once we do so.
Hey @nuta, I'm also part of the same team as @yashrajkakkad. I took a look at the project board and was looking to discuss one of the new features that you've listed there. We're interested in,
Which one of these do you think is favorable given our knowledge and timeframe (which you might know given your discussions with @yashrajkakkad)? Also, we would appreciate it if you give us some pointers on the topic you suggest.
datetimeserver. It initializes its internal time by asking the RTC device, and periodically advances it by
timer_setAPI. It should provide a message interface to get the current date & time.
timer_setAPI is supposed to be used.
datetimeserver. Once you specify that, I can finalize the message interface and corresponding functions.
timer_set. I hope it helps.
gettimeofday(2)on Linux (i.e. unixtime):
rpc gettimeofday() -> (unixtime: uint64).
timer_setsurely helps. I'll share my progress on that soon. And I agree with dealing with time values as Linux does. I have seen implementations before and I should be able to get back with something on it soon.
I've sent the PR for RTC driver (nuta/resea#30).
I haven't thought about timezones yet. Regarding apps that make use of this API, I had thought of implementing a simplified version of
date(1). I also thought maybe we could show the current time on the QEMU screen. Please let me know your ideas/thoughts on this.
date(1)-like interface because sending a string over IPC is not efficient (we need some memory allocations and additional IPC calls). Instead, consider returning a tuple of integers
(year, month, day, ...).
unixtimesince it would be easier to handle the time internally in that case. So the
datetimeserver gets the time from RTC (in terms of
month, etc.) which is then converted to
unixtime. The timer keeps on incrementing and sends the timestamp if
gettimeofdaymessage is requested.