Driver Development <continued...>

Driver Development <continued...>
I don't have time now to post some of my latest thoughts, but I saw that this area had been opened up, and well, I saw the opportunity to be the first poster and I took it. Please continue your thoughts here on driver development. I'd like to come up with a common driver template for the few of us that are working on this subject. Since I think it would be beneficial to share our drivers and perhaps speed up our development a bit. I have jotted down some ideas that I will share on the template when I get home this evening.

Hi! I think that I will have diffrent interfaces for the common drivers, like a VFS thing for storgage media and FS's, some other interface for sound specific stuff, etc, etc.. Good or bad? Lets think in the app programmers view. If I program an application to play sound, how do I want the interface to work? Is a seperate interface to check for soundcards better then a "all-in-one-structure" where I need to specify.... some ID or other code to tell the OS it's a soundcard I'm looking for? Well, I'm not sure yet. Any thoughts?

Heres some of my thoughts, take sound from a programmers point of view, as a example, i would like a to have a set of function through a call table or int xxh, there would be a number function for doing all the likely things, eg: sound_on, sound_off etc, these calls will be implemented with all the other functions in the kernel, but would be empty eg: like this


sound_on:
        mov al,1 
        ret  
 ; Error code, no sound card, the error need
 ; to be tailored to the way the os returns error code

The job of a minimal driver is to provide support to all these function, as the address of the function is gotton from a list, the driver store the old address and replaces them with the new one that is in the driver, all some one who is programming for our OS's need do, is call any of the sound function if they get a error code, if its 1, then they can deal with it by printing a message, like no sound found!. As i am porting my simple cdplayer, i will be trying the above methed to see how it works, i will let you's know :wink:.

I talked with a few hobbyst OS developers and we agreed on a point: drivers are a nightmare to support for a hobby OS. Here's my two cents on the "unified drivers" architecture matter. Once upon a time there was UDI ( www.projectudi.org ) and from what I heard it's dead. UDI drivers were really ANSI C-written routines made to be portable between architectures. But you may agree with me... sometimes C is less portable than many other languages. I was thinking, instead, of having a simple and small language that serves only for drivers purpose. Example: a small list of operations an OS may do with a video card: Access framebuffer Put bitmap in card memory Blit Let's see an hypothetical "driver language":


fb_put_pixel:
	reg1: linear_frame_buffer
	reg2: color
pseudocode to put pixel

copy_bitmap:
	reg1: source_bitmap_location
	reg2: destination_bitmap_location
	reg3: bitmap_lenght
pseudocode to copy to video mem

blit:
	reg1: bitmap_in_videomem
	reg2: position_in_screen ( linear )
	reg3: lenght
pseudocode to make the blit

The compiler/interpreter will then translate the registers to real CPU registers, the subroutines to function calls, I/O calls to in/out instructions etc etc. This will be more portable than C ( because of it's simplicity ), Here's pros: A) a driver can be created for all compatible architetures B) an OS may do whatever it wants with the drivers. Load them at runtime, have a separate compiler compile them into the kernel, interpret them java-style... C) The language is enough low-level to permit assembly-like optimization of the drivers, while maintaining full portability. D) Efforts needed to port the unified drivers to an OS will be limited to coding or porting the compiler/interpreter and write the virtual generic layer. E) You can develop drivers on a development OS, and use them in your OS, so you can test first if the driver works and separate drivers from OS errors. and cons: A) Drivers language, to be optimized, needs to be a bit more low-level than C... the bare minimum to provide portability maintaining enough control over the machine. B) Writing a new driver will somehow require making a generic layer first, if not available. There are a lot new hobbyst OSes rising around and almost all are now in the process of fighting with drivers. That's the right moment to join our efforts and aid each other. By making a WORKING unified drivers arch an OS developer can focus his skills on the OS only, if he wants. Instead an hardware-manufacturer could one day think that making an unified driver could be more economically convenient than supporting three or four architectures. Last thing: I'm designing a generic driver infrastructure for my OS anyway so.. if anyone other is interested, we could setup a project to discuss and define standards to have a really usable drivers architecture. From the other posts, I think that most of the things I said are similar to your toughts. We only need a standard way to do it :) Sorry for the long post. Axel

Excellent post Axel. I have read the UDI documents. In theory it ROCKS. Unfortunately, I think it is a matter of money with UDI and why it didn't take off. Money and the right software vendor working it. I am bummed that in order to get good quality product you have to pay an arm and a leg, oh and quite possibly a kidney for something substantial, and without the inclination of how it was accomplished. If UDI had the right backing it could have gone somewhere but alas it didn't. OK, I see that there are about five or six of us currently developing an OS. I am glad for that because it is interresting to see how we all implement our own seperate code, and who uses who's code in order to make their's work. I personally don't know the story behind V02, and really, I don't wanna know the full thing, but what I did hear seems an inevitable problem with a group in concert, people can not always agree. Thus the direction of the OS suffers because no-one can move forward, at least that was the way I saw it (Dex, please forgive me if I am wrong here...just my perception). I think that a way to eliminate that hurdle is to work on a common driver interface. Sure, our OSes are entirely different, with different goals. I think if we can, and I feel like it will happen, get a symbolance of ideas together, we can all benefit from our combined knowledge. For instance, I am not entirely into sound cards, but I am into precision in calculations. I might write a group of routines that may be useable for graphics or gaming based on that precision. I may use it for Cartesian plots (multidimensional), statistical analysis, or counting the number of photons incident on a sensor (some PCI hardware I plan to develop). The take away here is we all have our individual talents and wants. Together, as diverse as we are, we can achieve astounding things. Axel, I think you've nailed something a lot better, with your examples, than I could do with words. That is a common language. It may have to come down to an interpreted ideal or engine in order to facilitate it, perhaps. At least from what I see now, however, if I am blinded from the wrong color light let me know. I think if we work together we'll accomplish a win-win situation for all of us. I assume at the moment most everyone is considering a DOS style, albeit very morphed into 32-bits, device driver convention. If not please speak up. I like installabe drivers...I also want to uninstall them at my whim. These are two things that are most important to me as I see resources as something I do not wish reconfigure and reboot for ever. The basics: Header Strategy (this may need to be morphed) Commands As I mentioned in previous posts, here and elsewhere, I think it is essential to be able to have an an initialize and finalize routines. Everything else really needs to be ironed out. Are the list of DOS conventional commands outdated for our use? As for the header, we can make it simple, we can make it specific for the group consensus, in that there is an identifying marking, like DEX1 in the executeables, or BOS1, or DennisCGcOS1, etcetera. As long as we can recognize each others headers, we're in business (proably a poor choice of word). This also leads into is there a set of devices names we can all recognize, like CON, NUL, PRN, etc. Is it a good idea to add a remarks to the header section? It could include the device name(s). Do we allow interrupt calling within the drivers, or just pass the drivers an API command table for calling specific OS calls? This is essential in standardizing between OSes, since there will the the occasion when writting to the screen is needed. If we all have different print string functions, how do we tell the driver how to do it? A stardard set of OS commands may have to be passed to the driver for its own use. They don't need to be the same in all OSes, but the command table sequence and type of command would need to be set. I better run, this is a long post and I'm interrested in more thoughts. Forum at'cha tomorrow.

I think it's very interesting that we are working to get a few different operating systems running the same drivers... It's more like the DEX group rather then a single os team. I think that's healthy, as we can go in all different directions and still go foreward with everyone's developement. I'll be coding again soon, the school term will be over this weekend and I will be back home, hopefully getting a job... On another line, I just acquired a dual Pentium Pro PC with USB, ethernet, SCSI raid, and DVD, and 2 video cards. I'm going to get the specs on all the hardware and see what I can cook up.

That is a common language. It may have to come down to an interpreted ideal or engine in order to facilitate it, perhaps. At least from what I see now, however, if I am blinded from the wrong color light let me know. Exactly. My idea is to have a standard pseudolanguage that defines how to use a particular piece of hardware, then it's up to the OS to use the infos to make the peripheral works. I think if we work together we'll accomplish a win-win situation for all of us. Yeah! 8) I assume at the moment most everyone is considering a DOS style, albeit very morphed into 32-bits, device driver convention. If not please speak up. I like installabe drivers...I also want to uninstall them at my whim. That's the most interesting part of my idea! By defining a standard language every OS can then use it how they wants. You want to have installable drivers? Then simply make your "common drivers" compiler being able to output a loadable module in your OS format. Or maybe you're a driver developer and you don't want the burden of compiling drivers every time you change something? You could use an interpreter, then! It will be slower but you can test your code immediately. We only define a standard way of storing informations about how the hardware works, the rest it's all up to you :D As I mentioned in previous posts, here and elsewhere, I think it is essential to be able to have an an initialize and finalize routines. Everything else really needs to be ironed out. Are the list of DOS conventional commands outdated for our use? My idea is to have a set of standard "hooks" for every type of driver ( for example a video driver will have a standard set of routines, a sound driver another standard driver ) and the OS will use these standard calls to have a virtualization layer. Then into the driver there will be subroutines and other mechanisms that will be proprietary to that piece of hardware. The OS will not need to know about that ( except when translating the pseudocode to real machine code ) As for the header, we can make it simple, we can make it specific for the group consensus, in that there is an identifying marking, like DEX1 in the executeables, or BOS1, or DennisCGcOS1, etcetera. As long as we can recognize each others headers, we're in business (proably a poor choice of word). Mmm if you're talking about putting a specification of every single OS supported in the header I don't fully agree. We have a standard, so it's the same for all OSes. We don't need to have code for PutyourOSHere or ThatOtherOS. It's the same for all. This also leads into is there a set of devices names we can all recognize, like CON, NUL, PRN, etc. Is it a good idea to add a remarks to the header section? It could include the device name(s). That would be OS-dependent, too. We have standard wrapper for routines that deals with low-level things. Then the OS with his virtualization layer will deal on how the driver will be show. Not every OS around here is DOS based ( mine, for example ). It's not difficult to have your OS show your USB port as: USB0 or /dev/usb0 or whatever once you have the routines that makes it work and a standard virtual layer that does the job of hooking up the driver routines to your OS way of viewing things :D sort of VFS. Do we allow interrupt calling within the drivers, or just pass the drivers an API command table for calling specific OS calls? I think it differently. It's not the OS that needs to pass anything to the drivers. It's the drivers that needs to be "injected" into the OS. The driver won't need to have a print routine in it, instead it will pass strings to the OS in a standard way:


Loading_Str 'Sound Card Driver v 0.0.1'

Error_Str_1 'Sound Card internal error!'

and then in the driver code:

error_handler:
if error == 1
return_error_string Error_Str_1

This way the OS will know that at the driver loading event it will display the Loading_Str and it will receive the signals/strings/other data and then will decide what to do on various events ( you can print it into the console, use a window, a blinking red square on the screen... ). It's important to have something that's close to the hardware way of working but separate from the OS. At the same time the OS will have a proprietary way of working but will not need to deal with low level things. Another giantish post :P

:) Bubach, Smiddy, Dex4u, Axel and Tony: your ideas are very well expressed. Thanks. :D :D :D HOWEVER, :( (and I don't mean to throw cold water on these well considered ideas), HOWEVER (I guess it's worth repeating?) (ok, maybe a little water 8) ) Please remember, these are RING ZERO operating systems. Right? In other words, the ADVANTAGE of such an OS, is that ONE NEED NOT be constrained by the sort of thinking you have skillfully articulated in several posts above. In fact, well, let's consider the specific example of DEX4U's comment about sound cards: A ring zero os is not going to be fooling around with HIGH LEVEL LANGUAGE constructs such as you have suggested. Rather, one will be ACCESSING THE REGISTERS OF THE SOUND CHIP ITSELF. Ditto for Video controllers. So, I would suggest that INSTEAD of building up LIBRARIES of routines, a la C, one puts the same energy into DOCUMENTING skillfully the OS itself, so that an application that needs to use a timer resource, or add an element to a table of interrupt response addresses, can do so, EFFORTLESSLY. Isn't that the REAL value of a library? To REDUCE the effort, and DUPLICATION of effort. Won't that be BETTER accomplished by embellishing the documentation of the OS itself, so that, for example, on downloading the OS, one has a DETAILED explanation of how the code works, and why it is written as it is. We don't need MORE C libraries, i.e. C-like. Linux is readily available for that sort of activity. Well, that's my opinion. Regards, tom :)

Mmm no... Maybe I was not clear. I didn't want to create another library in a high level language. That's sort of UDI did things. I, instead, am saying to create a low level pseudolanguage that instruct the OS on how to access hardware. It will have the informations, for example, to instruct the OS that to change resolution you must send xx xx xx bytes to xx I/O ports. Then it's the OS that will use these as it likes. Naturally there will be a sort of simple subroutine support for hardware-dependent functionality. You can achieve an assembly-like performance this way, but maintaining compatibility with other architectures, using generic low-level construct that will be translated to real low-level ones by the interpreter/compiler. That will in fact give the OS the possibility to access hardware registers directly, as you are saying. If you have a detailed documentation repository it would be easy to understand how to do something with hardware... but you will need to code it anyway. With an unified drivers architecture you can write only the compiler/interpreter and then forget about writing drivers ( did you ever see how many drivers exists today? Every two months a new technology is out... Wireless, bluetooth, sata, firewire, new video boards, digital audio... ). And, naturally, I never said that if you write the driver you are not going write extensive documentation... you're encouraged to do so. Having a parallel documentation and driver repository will have both advantages. But don't say to me that you dislike the fact that coding the framework you will have immediate access to all drivers around ( so you can program your gui directly with hardware accelerated windows, having surround sound and using wireless to connect to internet... ) :roll: Everyone wants to learn... but not everyone wants to learn everything... at times is frustrating.

I have not the time right now (working :cry: ) to comment on the ? razed, but i must say i agree with 95% of the comments, and 100% with AxelDominatoR ideas, you could of taken the words right out of my mouth, great post all 8). I will add my 2 cents tonight. Edited: Over the weekend, i will be putting together a simple driver interface for "Dex4u" which will do the task in a non OS pacific way or way that other OS can easily implement, this will include a way to load and unload drivers on the fly. From this we can see and test ideas to see there pros and cons, then you can compear it to your own OS designs and interface and see where the problem would come on implement them on your OS's. See this as a simple test bed, were any thing can be changed and modified if people do not like it or have a better way of doing it. Once we find a way we are all happy with, we can go a head and write a spec proposal.

Everyone wants to learn... but not everyone wants to learn everything... at times is frustrating. I don't have time right now to write my reactions to your earlier posts and this recent one, or Tom's and Dex', but I wanted to address your quote here. I half heartedly laughed and did some reflecting of myself and think this a very qualified statement of mankind. I do, however, wish I could know everything but I am honest enough to know that that is not possible. BTW, Axel, don't take Tom's post personally, I really think he is challenging us to be the best we can. I think part of us writting here is in understanding one another. That being said, we should all appreciate one another's perspectives and not belittle them either. I think your reiteration nails a few things I hadn;t considered either. Thanks! I have to run...bicycle riding for my 2 year old. He loves his little chopper. ;)

Hi! Great ideas... I'm in ahurry, so I'll make it short. I don't know if we really need 100% compability between our OS's, I mean for stuff like printing "driver loading...", that seems a bit.. well, to much.. :P A standard way of loading/unloading them should be enought? Simple things like adjusting the loading messages etc. could easily be done by the OS creator in question (just changing the int numbers or systemcalls). I've only looked throught your posts quickly so I might not understand every aspect of your suggestions yet. I'll be back.... :)

Ooops sorry about that :shock: I really didn't mean to get "personal" in these posts :) Excuse me tomtobias, I have not absolutely nothing against you, just commenting out each other ideas! ( I know that sometimes I put too much emphasis... still trying to become perfect 8) ) P.S. There's growing interest in that discussion. May we link it to a Mega-Tokyo post to have other opinions, Dex4u? ( that forum is not mine so better first asking permission :wink: )

First let me say we are all free thinking programmers, ( if not we would be only programming for window/linux and using VB, C, C++), by throwing our new ideas, at each other is the only way we can come up, with new ways of doing things. So keep it friendly and respect each others options, and we can really show those C boy, how the men code :lol: . @AxelDominatoR, you are free to link to anything you see fit, as long as it's to do with programming or hardware etc, that goes for going off topic abit, theres no P**e.C*****r here :lol: .

There is a lot of good stuff here, I only wish I had time to address everything. I'll give it a shot tomorrow. @Dex, I think a starting point is a good idea. I may present a decent alternative we can work from together. I have, as I said earlier, jotted down some things and am working out the details. It won't be a finished product, but it will be useable (read; Install/Deinstall drivers). @Axel, I think we can workout a common language in terms of using the drivers... There are a number of permutations, but I think we can address most of them in one afternoon. Then the rest, the next... :) I'm out of here! Off to the hardware store, for some man fun with paower tools. YEAH!

View Full Version: Driver Development <continued...>