Eli Gottlieb's Journal: Driver Protocol Idea?

I'm designing a driver interface for a little bunch of hobbyist operating systems, including my own. It's goals are to be small, easy to comprehend and implement, portable across multiple operating systems, and extensible. A small class/object system has been created to allow drivers and kernels to implement and request extensions and standardized functionality with one mechanism.

Most of how the driver interacts with the hardware via the kernel is finished; what's still needed as a protocol for driver I/O via streams. To help keep the standards from becoming dependent on one kernel design standard input, output and error streams are the only standardized link to the outside world beyond the driver interface itself, and some protocol for using those streams is therefore needed.

Simply writing error strings to the error stream makes sense, but what about the other two? What kind of communications protocol design would be able to communicate real content, control data, possibly extension data, and the meaning/context of all of them to the outside world? Neither I nor the hobby operating system community have been able to come up with anything real so far.

And if you've got a fundamentally better idea than communicating via two or three streams, that'd be good to hear, too.

The entire standard (as embodied by the PDF docs about it) is currently under the GNU Free Documentation License. Anyone who wants to fork it, add to it, or whatever is free to do so. Anyone who implements it or a fork can license their implementation how they please. Basically, EDI needs good ideas and good implementors more than licensing issues at this point, so there's absolutely no chance anything commented here will ever get you or me sued.

Yes, I reposted a rejected "Ask Slashdot" submission as a journal entry.