Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 24 2021 07:00

    nuta on main

    Drop support for ARMv6-M I hav… (compare)

  • Dec 20 2021 14:03
    nuta commented #54
  • Dec 20 2021 13:46
    krishpranav commented #54
  • Dec 20 2021 13:45
    krishpranav commented #54
  • Dec 13 2021 12:12
    nuta commented #56
  • Dec 13 2021 12:04
    AlessandroSangiuliano opened #56
  • Nov 12 2021 10:34
    nuta commented #54
  • Nov 11 2021 17:43
    Sologix commented #54
  • Nov 11 2021 13:28
    nuta commented #54
  • Nov 11 2021 13:24
    Sologix commented #52
  • Nov 11 2021 13:22
    Sologix commented #52
  • Nov 11 2021 12:17
    Sologix opened #54
  • Nov 07 2021 16:40
    Sologix commented #52
  • Oct 26 2021 22:55
    nuta commented #48
  • Oct 26 2021 15:01
    nagesh-c commented #48
  • Sep 02 2021 14:10

    nuta on move-cursor

    Update Update Update and 1 more (compare)

  • Sep 02 2021 10:03

    nuta on move-cursor

    Update (compare)

  • Sep 02 2021 09:54

    nuta on move-cursor

    Update (compare)

  • Sep 01 2021 13:23

    nuta on move-cursor

    Update Update Update (compare)

  • Sep 01 2021 10:01

    nuta on move-cursor

    Update (compare)

Seiya Nuta
@nuta
Since Resea is still a hobby-level project, there're a lot things we need to work on. Do you have any interested topics on operating system? (e.g. memory management, file systems, device drivers, TCP/IP, ...)
Yashraj Kakkad
@yashrajkakkad

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.

Seiya Nuta
@nuta

Sounds great! Off the top of my head, project ideas for Resea are:

  • Improving malloc implementation. Currently it uses a very primitive algorithm. We need to implement another smarter algorithm to mitigate fragmentation.
  • User-level scheduler. In microkernel-based systems, task schedulers are implemented in the user-space using special kernel interfaces. I've implemented task_schedule system 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.

Of course I welcome your idea if you have :)
Seiya Nuta
@nuta

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.

For that reason, I highly recommend surveying microkernel research (e.g. MINIX3, L4) a little. You don't have to understand everything but they would stimulate your curiocity.

Yashraj Kakkad
@yashrajkakkad
Hello Seiya! Thanks a lot for the wonderful insights .
We went through everything and are about to submit our project proposal to our faculty.
Yashraj Kakkad
@yashrajkakkad

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.

Seiya Nuta
@nuta
Sounds great! Let's enjoy projects you mentioned! I'll update issues on GItHub tomorrow to clarify what we need to do.
Seiya Nuta
@nuta
That said, since you have a deadline (6 weeks), I think it's good idea to give priority to projects according to your interests and preferences.
Yashraj Kakkad
@yashrajkakkad
Thank you very much @nuta. We went through the malloc function and understood the implementation. We could relate to the ideas we are currently learning in memory management related to fragmentation. We are just not sure what "smart" algorithm you're expecting as the solution.
Yashraj Kakkad
@yashrajkakkad
Yes, about the deadline, we want to go by the "easiest" first strategy and gain confidence. About the topics, we're fine with literally anything which we can relate to our course.
As you mentioned MINIX once, I did check out its implementation of malloc() and its pretty daunting
Seiya Nuta
@nuta
As you say implementing a smart malloc is not obvious and it would be difficult since it is one of crucial research topic on operating system. As the first step, I'd recommend adding a small but effective heuristic improvement to the existing malloc on Resea. For example, supporting multiple bins ( I'll describe more details in #23 later).
If you're new to malloc, have a look at an article about the internals of glibc's malloc.
Seiya Nuta
@nuta
You just need to understand high-level algorithms, and you don't need to understand the implementation.
Yashraj Kakkad
@yashrajkakkad
Thank you very much. I went through the article and we have started working on the problems.
Seiya Nuta
@nuta
Enjoy ;)
Prayag Savsani
@PrayagS

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,

  • RISC-V support
  • datetime management server
  • random number generation

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.

Prayag Savsani
@PrayagS
So I was exploring the datetime management server feature, and I managed to get the current time using a very simple CMOS driver. What do you suggest as further work? Implement a complete RTC driver and then maybe look towards adding NTP support?
Seiya Nuta
@nuta
Sounds great! As the first step, I recommend you implement datetime server incrementally:
  1. Add your RTC device driver server. Since this is the first RTC device, you need to define a new interface for such devices in interface.idl.
  2. Add datetime server. It initializes its internal time by asking the RTC device, and periodically advances it by timer_set API. It should provide a message interface to get the current date & time.
  3. Implement other further improvements like NTP client.
Prayag Savsani
@PrayagS
Thanks for sharing your thoughts @nuta. I'll share my progress soon
Arpit Vaghela
@arpitvaghela
@nuta , Can you help me on how do i go about on implementing shm API.
Seiya Nuta
@nuta
Of course. Go head.
Arpit Vaghela
@arpitvaghela
I have seen the man pages n understood the api, but i cannot find any implementation related doc or so
Seiya Nuta
@nuta
Implementing a shared memory API on Resea would be completely different from other operating systems.
Note that you don't have to implement POSIX's shared memory API as it is.
Arpit Vaghela
@arpitvaghela
Is it something tough n might take too long ?
Seiya Nuta
@nuta
I think it is not easy but not too hard. I'll create an issue on GitHub to describe more details later.
Arpit Vaghela
@arpitvaghela
that will be of great help :)
Seiya Nuta
@nuta
@arpitvaghela I wrote my ideas. Could you take a look at it? nuta/resea#28
Seiya Nuta
@nuta
@yashrajkakkad Hi, I wrote some advices on KASAN. Hope this helps: nuta/resea#29
Arpit Vaghela
@arpitvaghela
@nuta Will shm_id be a random number ?
Seiya Nuta
@nuta
It doesn't have to be random. Use a sequential number for now.
Prayag Savsani
@PrayagS
Hey @nuta, I have been working on the datetime server feature and wanted your inputs on a few things.
  • I completed the RTC driver which lives at servers/drivers/time/rtc.
  • I defined the interface for this RTC device in interface.idl. For now, it only returns a string.
  • I added the datetime server which inits itself by asking the RTC driver. It lives at servers/experimental/datetime. As of now, it only fetches the time from the RTC server. It would be great if you can elaborate on how exactly the timer_set API is supposed to be used.
  • Also, please let me know what kind of functions you expect from the datetime server. Once you specify that, I can finalize the message interface and corresponding functions.
Yashraj Kakkad
@yashrajkakkad
Thanks @nuta, it does help!
Seiya Nuta
@nuta
@PrayagS I skimmed through your code and am sure that you're on the right track! I've added a doc about timer_set. I hope it helps.
The datetime server would set a timer periodically so that it can update its internal wall clock.
Regarding the datetime server's interface, I think it should provide a single API like gettimeofday(2) on Linux (i.e. unixtime): rpc gettimeofday() -> (unixtime: uint64).
Seiya Nuta
@nuta
I'm not sure and have been thinking how we should handle timezones btw.
Also, we need to convert the date (e.g. 2020-11-13) from the RTC into unixtime, but it seems to be complicated. I need to study the algorithm first...
First of all, I recommend you to send a PR for your RTC driver.
Prayag Savsani
@PrayagS
@nuta Thanks for taking the time to go through the code. That doc on timer_set surely 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.

Seiya Nuta
@nuta
Thank you for the PR, @PrayagS! I replied review comments on GitHub.
As the first step, let's forget about the timezone for now. I don't recommend implementing 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, ...).
Seiya Nuta
@nuta
Since handling unixtime is complicated, tuple of integers (year, month, ...) seems to be a realistic approach to me. That is, datetime calls the rtc driver at startup, update the datetime internally using timer_set, and reply the tuple to clients.
Prayag Savsani
@PrayagS
Thanks for laying out the complete picture again @nuta! Working with a tuple, in this case, is indeed easier. I'll go ahead with that and still maybe take a look at how other OSes handle unixtime. Might just implement it if the conditions are in our favor. I'll be sure to discuss that first.
Prayag Savsani
@PrayagS
So I did up going with unixtime since it would be easier to handle the time internally in that case. So the datetime server gets the time from RTC (in terms of year, month, etc.) which is then converted to unixtime. The timer keeps on incrementing and sends the timestamp if gettimeofday message is requested.
I'm confused regarding the location of the helper functions since we're sending the timestamp and applications might need to convert it back to the datetime struct. For now, they're defined in datetime/datetime.h