Kristian Vander Vliet, aka Vanders, has been working on a document that explains how to port drivers to Syllable. This document first starts off as a primer on how to write drivers for Syllable. Then the document shows how to port a driver from Linux to Syllable. Kristian chooses to focus on network drivers and ported the broadcom tg3 driver from Linux while writing this document.
Sorry to be slightly off-topic, but this is a great way to encourage driver porting!
I had asked on the Haiku mailing list a while back if someone could put this type of documentation together for Haiku. I suspect it still may happen once Haiku gets more mature, but I’m not sure anyone with the know-how will volunteer
I think this is a great way to encourage would-be developers to “attempt” driver porting, even if they’re not experienced in that type of development yet. I sort of fall into this camp myself.
I had asked on the Haiku mailing list a while back if someone could put this type of documentation together for Haiku. I suspect it still may happen once Haiku gets more mature, but I’m not sure anyone with the know-how will volunteer
“Doing something” and instructing others in how to “do something” are two very different things. There’s the cliche of “those who can, do; those who can’t, teach (and those who can’t teach, teach teachers).” But I think that being able to convey knowledge to others requires a greater understanding of said knowledge than just being able to apply that knowledge
I am working on something right now.
Check out my very rough sound driver tourial on BeBits (http://www.bebits.com/app/4425). At present I am working on driver internals and test code, also trying to understand multi-audio to doc it.
I am working on adding a number of other driver types but it will take time.
I am working on something right now.
Thanks! I actually did download your driver from bebits some weeks ago.
When I get some time, I’ll definitely build one of those too
I am actually interested in porting some net drivers from Linux or BSD to Haiku – but have still struggled enough to prevent me from getting anywhere quickly. I did note that the Syllable documentation makes sense, and a lot of the basics can be applied to my experiences. I’ll definitely be looking into it more when I have some spare time.
Network and Video drivers are hard to understand (for me), I have some reference material and the docs this thread is originally about will help a lot. But it will take some time.
Basicly I need to develop a working driver to understand how it work. If I can get some materials together maybe some one else can fill in the blanks. Otherwise it will take some time before I get the docs finished and longer to get the quality of documentation that Kristian Vander Vliet, aka Vanders has done.
If Syllable get more docs like this, it is a sure winner as it will not lack in drivers.
Speaking of “news,” this is GREAT news that there’s new documentation out there to port drivers to a maturing OS. The simplicity and the clarity of the explanations make this documentation viable for attracting new developers.
This is just GREAT documentation… Nice!
Easy to understand also for a foreign, unexperienced programmer like me!
Thanks a lot Vanders Keep up the good work on Syllable!
> But I think that being able to convey knowledge to
> others requires a greater understanding of said
> knowledge than just being able to apply that knowledge
I don’t know about that. I think teaching mostly just takes a knack for guessing what the other person is wondering about while you’re trying to explain some given node to them.
Then, just recursively traverse each of those nodes (depth-first) until there’s nothing left that a reasonable student would be left behind wondering about, and BOOM — you’ve got your docs.
Trouble is, not many folks have that knack.
> (and those who can’t teach, teach teachers)
Heh. Well, I’ll give you that one.
Edited 2006-12-09 09:57
I with say it is the opposite. Instead of guessing correctly what another person will want to know, you need to stop assuming what a person knows or needs to know – assume nothing – and supply all the information about everything period.
Example: I am writing benchmarking results of testing the snooze_until vs the interrupt handler to see which are really better to use for certain timing functions.
Turns out there are some odd results with the latency of interrupt handlers that people don’t notice on higher speed systems, but shows up on my slow PII-366 Dell laptop.
This is always a problem when I want to find out why certain things were done, not how, why?
I plan to steal some document formatting ideas from it.
great article!