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.