Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 12 10:34
    nuta commented #54
  • Nov 11 17:43
    Sologix commented #54
  • Nov 11 13:28
    nuta commented #54
  • Nov 11 13:24
    Sologix commented #52
  • Nov 11 13:22
    Sologix commented #52
  • Nov 11 12:17
    Sologix opened #54
  • Nov 07 16:40
    Sologix commented #52
  • Oct 26 22:55
    nuta commented #48
  • Oct 26 15:01
    nagesh-c commented #48
  • Sep 02 14:10

    nuta on move-cursor

    Update Update Update and 1 more (compare)

  • Sep 02 10:03

    nuta on move-cursor

    Update (compare)

  • Sep 02 09:54

    nuta on move-cursor

    Update (compare)

  • Sep 01 13:23

    nuta on move-cursor

    Update Update Update (compare)

  • Sep 01 10:01

    nuta on move-cursor

    Update (compare)

  • Aug 28 13:18
    nuta edited #41
  • Aug 28 13:18
    nuta edited #41
  • Aug 26 15:10

    nuta on move-cursor

    Update Update Update (compare)

  • Aug 26 09:48
    nuta edited #41
  • Aug 26 09:47
    nuta edited #41
  • Aug 26 09:47
    nuta edited #41
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
Seiya Nuta
@nuta
How about placing them in the standard library? (libs/resea and libs/resea/include/resea).
Prayag Savsani
@PrayagS
@nuta Done. Anything else you suggest?
Seiya Nuta
@nuta
Your design looks good to me! Could you create a PR to review?
Prayag Savsani
@PrayagS
The PR is up. nuta/resea#31
Arpit Vaghela
@arpitvaghela
@nuta Won't the test for nuta/resea#28 be similar to usage of shm in linux.Also, I believe shm.c to be a part of resea/include/ or will it be in the kernel/ as well ?
Seiya Nuta
@nuta

@nuta Won't the test for nuta/resea#28 be similar to usage of shm in linux.

I think so. Specifically, we need at least two tasks (apps/test and a new app like app/shm_test). app/test creates a shared memory and tell it app/shm_test. It maps the shm and writes something to the shm. Lastly, apps/test checks if the written data is visible.

Also, I believe shm.c to be a part of resea/include/ or will it be in the kernel/ as well ?

Do you mean API wrappers like libs/resea/include/async.h? If so, I think it should be resea/include/experimental/shm.h since its not yet matured feature.

Prayag Savsani
@PrayagS
Congratulations on the new release @nuta! I'm glad that our team could be part of it.
Seiya Nuta
@nuta
Thank you a lot for your contribution @PrayagS! :D
Yashraj Kakkad
@yashrajkakkad
Hi @nuta I apologise for being inactive. I am not able to contribute due to my upcoming examinations. I will be up soon.
Seiya Nuta
@nuta
@yashrajkakkad That's absolutely no problem and don't have to be sorry! You're totally right and preparing for examinations is more and more important. Please work on only when you have time to spare :)
malbx
@malbx
@nuta I have started working on the random number server. Can you take a look and let me know if this approach is what you had in mind? Also, do you have any thoughts on how you would like to handle the seed?
malbx/resea@803d14e
Seiya Nuta
@nuta

@malbx Your design looks good to me! Could you create a PR? Let's improve it incrementally.

Also, do you have any thoughts on how you would like to handle the seed?

Towards a cryptographic-secure RNG, we might need to add kernel support and a system call to get the seed from the hardware. I'm not familiar with random number generators but AFAIK Linux extracts randomness from interrupt timings and RDRAND instruction on x64.

Yashraj Kakkad
@yashrajkakkad
Thank you @nuta! See you soon hopefully :D
Seiya Nuta
@nuta
good luck 👍
Prayag Savsani
@PrayagS
@nuta Our presentations are due soon and we've around a week until that. I was thinking of another project to work on and saw virtio-blk and Userspace debugging using LLDB on the board. Which one do you think is more suitable given the short timeframe? Does the LLDB one involve that much work? Please let me know your thoughts.
Or if you have any ideas on something completely else that fits the timeframe, please feel free to share those as well.
Prayag Savsani
@PrayagS

@nuta So I started some work on the virtio-blk driver and went through the spec and some existing implementations (1, 2).

I noticed how they're sending three different buffers (one for header, one for data and one for device writeable status byte) and chaining them using the next field. resea's virtio_modern implementation doesn't have that but does mention descriptor chaining in the code. So can you please explain how that would work in resea?

I think I should be able to make it work like those existing ones using the legacy interface but I'm confused regarding how chaining works in the modern implementation.

Seiya Nuta
@nuta

@PrayagS I think implementing virtio-blk driver (for legacy virtio device) is more realistic.

You may already know, Resea's virtio_modern implementation uses Packed Virtqueue. See 2.7.6 Next Flag: Descriptor Chaining in the spec (the specification describes both legacy and modern devices in the single page and it makes a bit confusing...).

I haven't tried yet but according to the QEMU's implemenetation (in virtqueue_packed_read_next_desc()), we don't use next field in the packed virtqueue. Instead, we need to use continuous descriptors as a chain and set VIRTIO_DESC_F_NEXT to the descriptor flags (except the last one).

The current virtio-net driver does not use that simply because it's not needed. Thus, you may also need to improve also the Resea's virtio_modern to handle the descriptor chaining.