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 Mr. Seiya,
Thanks a lot for a quick response!
We're looking for things which connect to what we learn in an elementary OS course - process management, scheduling, memory management, virtual memory, threading, interprocess communication etc. We also don't mind shifting a bit out of our comfort zones. We'd possibly want to avoid subjects which are not related to core OS concepts for example, such as networking-related things as of now.
Please let us know how this sounds to you. We're really excited to work with Resea for our project.
Sounds great! Off the top of my head, project ideas for Resea are:
mallocimplementation. Currently it uses a very primitive algorithm. We need to implement another smarter algorithm to mitigate fragmentation.
task_schedulesystem call for that purpose, but we haven't yet implemented various scheduling algorithms (in the userspace). See MINIX3's approach for more details.
I'll let you know if I come up with other ideas.
By the way, you might already know but a microkernel-based OS is quite different from monolithic kernel based OS. AFAIK most operating system courses are implicitly based on monolithic ones.
For example, microkernels are based on a philosophy called "separation of mechanism and policy": we avoid adding code to the kernel as much as possible. Instead, we implement operating system features (like high-level process/memory management, process scheduler, referred to as policy) in the userspace. The kernel only provides a simple but flexible features (mechanism) to implement them.
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.