Tuesday, May 02, 2000
“These are not the devices you are looking for.”
It's always interesting talking about programming with Mark. Somehow we got into a discussion about device drivers and how they should be named.
I had the notion of physical device drivers, and virtual device drivers. A physical device driver is a driver that drives a physical device, like a UART (Universal Asynchronous Receiver/Transmitter), while a virtual device driver would be something like a PPP (Point-to-Point Protocol) driver or a NULL device. So, the PPP device driver would be associated with a serial device driver.
Mark descimated that view.
There are no such thing as virtual devices (although the concept of a NULL device didn't come up actually). Only physical devices. Things I would consider a virtual device would be handlers pushed onto a physical device, much like the SysV Streams concept (although just because SysV has a bad implementation doesn't mean the idea is bad). So you open a physical device, then request a particular behavior, like a serial device with PPP.
I couldn't wrap my brain around that, since it smacks too much like the way UNIX serial drivers always contain TTY discipline code, but that's a problem I have (mantra: because a system does it poorly doesn't make it a poor idea).
Because as Mark pointed out, there might be a serial device that has PPP built into hardware. It seems that there are network cards with portions of TCP/IP built in, but, for instance, Linux can't take advantage of such hardware assistance because the way the networking stacks work.
It gets even worse—there are devices that the main CPU can't even talk with. They exist, but you can't program them or even write a device driver, but you can detect their presence. He even gave examples. So my assertion that all devices can be written to/read from is false.
The other concept is letting “things” or “objects” talk with each other
and not caring. Like letting a network device “talk” with a serial
device. The problem I have with that is how do these “objects” “talk?”
This all smacks of automagic to me, much like the
Tunes people talk
about—no implementation details, it just happens. Like with COM
or DCOM or CORBA implementations. No real talk about how
it works. Lots of talk about this talking with that, but how?
But much of what Mark works on works like that. Even device drivers.
It's not so much a conversation as it is a discovery process of capabilities between two objects.
Like I said, talking with Mark is interesting.
And I hate it when he's right.
“Smile!”
I was given an older color Connectix webcam to use. The software compiled and worked without incident, although the first image was rather interesting.
The Connectix webcam was easy to take apart (since someone else already did that). The electronics in the unit are on two small boards and it looked like the two boards were being pressed together too close. A small piece of paper folded up provided a good spacer and the subsequent images were recognizable, although way out of focus.
It is easier to focus this one than my other one. But without sufficient light, the pictures appear very muddy and dark.
I'm torn. I like that this doesn't use batteries, but the image quality isn't quite as good. Oh well.
X-Files
So I exit out of X, then restart it.
“Now that's odd,” I thought, watching the screen awash in a non-synced image. “It worked a few seconds ago.”
Playing around with the settings didn't fix it. My monitor just suddenly stopped supporting 1024x768. Which sucks. I'm now stuck back at 800x600. I think it may be time to get a new monitor.
Sigh.
