Hi Maurizio, > Some days ago I began to work on a real time clock driver for HelenOS, > the final goal is to fix ticket #397 (Implement wall-clock time > facility); > I've already discussed some little details with Jakub both on IRC and > via email but since > the arguments are becoming a bit technical a more open communication > on the ML is now required. Great!
> > What I've done until now: > > Basically, I was looking at how the RTC driver has been implemented in > other operating systems, namely Minix, Linux and some BSDs. > > - How the RTC driver works in Minix > > The "readclock" (minix/drivers/readclock/readclock.c) service is > launched at boot, it reads the CMOS memory Right. But this is specific to the PC platform. You should give at least some thought to how this would work on other platforms to get the overall architecture right. > execute a syscall that > sets a "time_t boottime" variable inside the kernel and finally exits; > the current time is obtained by a simple sum (boottime + uptime). As Jakub mentioned the kernel has no need to know anything about wall clock time. The kernel makes use of some monotonous time source (such as tick register, timer interrupt) and in some cases it might be necessary/convenient to export this time source to user space. OTOH only user space is interested in wall clock time. > - How the RTC driver works in Linux: > > The RTC is implemented a character device driver > (linux/drivers/char/rtc.c), you can read /dev/rtc to make use of timer > interrupts or /proc/drivers/rtc to read the current time/date, battery > status etc etc. > -------------------------------------- > > Jakub said that in HelenOS there are more possibilities than just > implement the driver as a character device; > quoting his words: Let's first look at the overall architecture, instead. In the end you probably want to have some 'time server' which provides current time to applications upon request. The time server probably combines multiple sources of information / time sources, depending on what's available (e.g. CMOS, timer interrupt, tick register). The server could have knowledge about specific methods of obtaining time or it could be completely generic and all the platform/device-specific knowledge could be hidden in separate servers/drivers. In the simplest case the time server could know about CMOS and kernel monotonous time and combine them. The applications could do IPC call to get the current time - first class, certainly not as a stream of characters :-) With CMOS you can certainly get away with accessing it via something which is not a DDF driver since accessing the CMOS is no big deal. True, the prettiest approach would be having a DDF driver for CMOS. This driver could either just provide access to the CMOS (e.g. read time, write time, etc.) or it could act directly as some sort of time provider (i.e. one of the sources used by the generic time server). > <jermar> [...] as for classifying rtc as a character device > <jermar> in Linux, this is probably because devices there are either > character, or block Looking at how Linux does it can be useful *sometimes* because it gives you a great example of how *not* to do it. I usually don't even bother. Linux clinges to the block-character device dogma much more than any other UNIX-like system. The way you control some Linux drivers (via text commands sent over the character interface) is just ridiculous. > <jermar> in HelenOS, there are more possibilities For each new class of device new interfaces are created as needed. There is no need to pretend that a device is something it isn't, rather we use first-class interfaces. > <jermar> not so sure rtc needs to be a char device That would probably make no sense. > I have to look at some existing drivers to figure out how. > > That's all. Coding phase has not begun yet because I need to get some > confidence with the DDF before. You could prototype this without DDF and then, eventually, split some part that talks to the CMOS to a DDF driver. Cheers, Jiri _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
