Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Driver Protocol Idea?

Eli Gottlieb (917758) writes | more than 8 years ago

User Journal 0

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.

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.

cancel ×

0 comments

Sorry! There are no comments related to the filter you selected.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>