Hi Maurizio, thanks for bringing this to the ML. For now, I'll just replay some of my comments or shed some light into what I said on IRC.
On 03/12/2012 10:11 PM, Maurizio Lombardi wrote: > The "readclock" (minix/drivers/readclock/readclock.c) service is > launched at boot, it reads the CMOS memory, 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 I suggested on IRC, there is no need for the kernel to know the wall clock time and thus no need for the dedicated syscall. Instead, the rtc driver can be providing it upon client request. > 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: In HelenOS, drivers can implement several "standard" interfaces, such as the CHAR_DEV, NIC_DEV, PCI_DEV etc. and new interfaces can be defined when it makes sense. In theory, a driver can implement more than one interface. HelenOS DDF drivers can also implement a completely arbitrary protocol or a protocol primarily used by non-DDF services (think of the block device protocol used in the usbmast driver). The CHAR_DEV interface is suitable for reading and writing byte streams, which is not necessarily the best way how to read / write time. For that, I think that specific, more structured interface / protocol should be used. On the other hand, the rtc driver could offer the CHAR_DEV interface as an alternate way for reading time. HTH, Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
