The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

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.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.