* * * * *
“These are not the devices you are looking for.”
It's always interesting talking about programming with Mark. [1] 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 [2] 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.
[1]
http://www.conman.org/people/myg/
[2]
http://www.tunes.org/
Email author at
[email protected]
