I was making something time dependent with <time.h> and discussing it with someone on IM, and it got me thinking.
How exactly does the operating system deal with time?
Some questions that came to mind, what processes interact with the hardware clock? how often? what raw data does it give them? how do they process it? What about the software clock? Same basic questions.
The <time.h> is a C-header providing a std. interface for time and date handling. It does hide the time handling of the OS for the C-programmer.
Regarding UNIX/Linux time: Quite simple, it just counts the seconds since 00h00:00 01 Jan. 1970.
Heh, in reference to that I found this.
I found this interesting:
If the number of seconds since the 1st of January 1970 UTC is stored as an signed 32-bit integer (as it is on your Linux/Intel system) [b]not on mine :p[/b], your clock will stop working sometime on the year 2038. Linux has no inherent Y2K problem, but it does have a year 2038 problem. Hopefully we'll all be running Linux on 64-bit systems by then. 64-bit integers will keep our clocks running quite well until aproximately the year 292271-million.
It also said that the system only interacts with the hardware clock at boot to set the system clock. But I am still curious exactly what form of information the hardware clock has and how it passes that information on, how does the os interface with it etc.
The hardware clock is read at boot time to set the internal Linux kernel clock which you can read this directly through the proc filesystem;
cat /proc/driver/rtc
To get / set the hardware clock directly use;
hwclock
For a more automated approach to making sure your machine’s time is correct, do;
ntpdate ntp.ubuntu.com
And make sure your timezone is correct, /etc/localzone should either contain the contents of or point to /usr/share/zoneinfo/GB …
But how does it work?
Perhaps I can ask more generally, how do hardware and software interact? You’ve got a bunch of electrons in the clock, moving around in some specific way that represents this “time” information that it has and keeps track of? How does the operating system get hold of that pattern (or specifically get hold of the information in that pattern) of electrons and understand in the context of probably a different means of creating electron patterns than is in the clock.
LOL.
And another thing, how do drivers work? I’m pretty much used to the idea you plug something in, you install the drivers, everything recognises it and nothing more to be done. But now that I think about it, its really amazing and weird that this abstract thing called software can interact with all my little bits that make up my computer. And even though I never really thought about it before suddenly Im really curious.
Like if someone had an led, and connected it to their computer, just one led… what would a driver for one led, that turns it on, or off, and that’s it, actually, at the most basic level do?
I mean it would have to be able to either send or not send a current into the LED. So that would be the first thing, but “it” probably isn’t going to be doing that right? Someone, or various program would decide to light up the led for whatever reason probably at specific times or because of specific events. So it couldn’t just send a current into the LED (and anyway, how would it regulate that current, how strong, what voltage etc, and what monitoring of the current would it do?) it would have to send a current to the LED and have some kind of way of interacting with people and programs who want to choose when to turn the LED on and off right?
So what would it look like, a driver for one LED, to just turn it on and off on command?
Ok, generically, you’ll have a bit of electronics on the motherboard that vibrates at a specific frequency, powered by the ‘watch’ battery on the motherboard. Every beats, a counter gets incremented, then you get to read the contents of this counter via a specific memory mapped hardware address. (generally this is done via the BIOS and the OS makes a BIOS call to get/set the clock)
Drivers are a lot easier than they sound, firstly the Linux kernel has a modular driver model which means you can write some driver code and load / unload it dynamically while the system is running, without the need for a reboot.
From a hardware perspective, an LED panel would map itself to a specific memory range and you would communicate with it by reading / writing to a range of memory addresses which map to the LED hardware, rather than the computer’s memory. So essentially most drivers are relatively straightforward and all do a very similar thing, i.e. shift data to/from memory mapped locations and return the results / data to the user typically via /proc or via devices in /dev.
It’s the devices themselves that often do much of the work presenting the OS / driver with a ‘relatively’ high level interface … take a look at some of the older network card drivers, these are often quite readable … 