flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Inter-OS standard drivers?

Author
Thread Post new topic Reply to topic
axlucas



Joined: 02 May 2014
Posts: 66
Location: Argentina
axlucas
I was thinking the other day that one reason why many hobby OSs end up being used by just one person and for a brief period of time, besides the project being abandoned unfinished, is that it takes a lot of work to develop all the drivers necessary for an OS to be able to do all the things OSs do. An OS without sound or without Internet... or without wide screen is reasonable for a hobbyist, but one would like to be able to build his one OS to actually be the one we use everyday on our PC.

Please correct me if I'm wrong, but without open specs, hobby OS drivers have to rely on reverse-engineering drivers made for other OSs or reading source code of drivers already made for free OSs such as GNU. This is already hard work, but besides, if we want to support more than the most common hardware, it'd take prohibitively long.

Now, somebody must have thought before me that if hobbyists agree to a certain level on the format of their drivers, the same drivers could be used, with little changes, for every hobby OS. Is there any project like this anywhere? If there is an obvious answer to this, please forgive my ignorance and show me the way Razz Thank you, guys!
Post 05 Nov 2014, 23:35
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17669
Location: In your JS exploiting you and your system
revolution
Perhaps EFI can once and for all solve the driver problem?

But I'm not holding my breath waiting for it to happen.
Post 05 Nov 2014, 23:47
View user's profile Send private message Visit poster's website Reply with quote
axlucas



Joined: 02 May 2014
Posts: 66
Location: Argentina
axlucas
Uhm... I don't know... BIOS was supposed to do that work too and you see what happened. Besides, the code within UEFI is not free, so a free OS "should not" use it. Also, if we begin to rely on UEFI, then how about Coreboot?

Now going back to shared drivers in theory, I've read somewhere sometime that reverse-engineering proprietary software is prohibited. Yet, I've heard Richard Stallman himself mention in an interview that GNU drivers were developed by doing just that. How is that possible? The man knows about law, there must be a catch. And then... what about publishing specs? Say I find out how to access a certain hardware, so I write my own specs to it (not the original ones). Is it legal for me to distribute these specs I wrote?
Post 06 Nov 2014, 00:02
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17669
Location: In your JS exploiting you and your system
revolution
axlucas wrote:
Now going back to shared drivers in theory, I've read somewhere sometime that reverse-engineering proprietary software is prohibited. Yet, I've heard Richard Stallman himself mention in an interview that GNU drivers were developed by doing just that. How is that possible? The man knows about law, there must be a catch. And then... what about publishing specs? Say I find out how to access a certain hardware, so I write my own specs to it (not the original ones). Is it legal for me to distribute these specs I wrote?
It first started with Compaq (IIRC) doing a BIOS clone. If you do it "correctly" you have something like "dirty" people that reverse and read the original code and turn it into a spec. And then "clean" people that have never seen the original code; they take the spec and write new code. Or something like that anyway. Besides, not all countries have such laws that require measures like that.
Post 06 Nov 2014, 00:31
View user's profile Send private message Visit poster's website Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
There are a lot of contributing factors that make this difficult and I've hit plenty myself. Be it standards/specifications and their degree of openness (plus working around implementations that don't adhere to these standards), the design/layout of your particular OS (runtime, built-time interfaces/API and code base), the tools you use, the architectures you wish to support (which may impact all of the previous) and many others.

While this doesn't make it impossible, it requires a lot of supporting code/wrapping to accommodate all of these variations, making it hard to maintain; particularly when it comes to the security vs speed question. Basically there will be at least two implementations of everything - probably closer to 10 to cover all the cases. Then it has to be well-documented Shocked as well as actually usable Laughing

You are right that most hobby OSs end up duplicating the "basic" stuff that could potentially be wrapped up into a nice little library and ease the pain for some Very Happy
Post 06 Nov 2014, 18:07
View user's profile Send private message Reply with quote
axlucas



Joined: 02 May 2014
Posts: 66
Location: Argentina
axlucas
Thanks! Yes, it's sad that we have to get stuck just when the OS would start to become useful. This, of course, isn't coders' fault, but it's the fact that the PC is not just one thing, but lots of different (and very dynamic) technologies that have to be supported in order to have a complete system up and running.

I think that, without some level of cooperation, only a few hobby OSs will reach the "useful" level. But my concern is that most hobby OSs, that is, the typical hobby OSs... say... a one-person work, is doomed to be abandoned. Of course, coders learn from working on them, but it'd be nice to go further. Certainly, OSs that are already designed from scratch without looking for driver-compatibility with others will be hard to support under a common driver structure, but on the other hand, new OSs could be designed thinking of this in advance. It's not necessary to make the whole system compatible; just the drivers. And well, this is FASM, so we're talking about Intel/AMDs and Assembly. We wouldn't need to provide support for other platforms. At most... 32bit vs 64bit.

Anyway, you are right. I realise it's still hard. I just would like this idea to remain in people's mind from time to time so that at some point, maybe we can build something on it Smile I mean, it can't be harder than what we're already doing by building one OS per person alone!
Post 07 Nov 2014, 18:03
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> only a few hobby OSs will reach the "useful" level

IIRC only one hobby OS reached a "useful" level (more accurately: useless but used by everybody nevertheless) so far: MS-DOG (later renamed into "Windows" ...).

> takes a lot of work to develop all the drivers necessary for an OS

very true

> somebody must have thought before me that if
> hobbyists agree to a certain level on the format

This (create a common driver standard for multiple OS'es) had been thought and tried already 1'000'000'000'000 times. Result: failure. The only thing people can agree about is, that everything must be 100% compatible with Windaube, so they end up with the situation that nobody uses hobby OS XXX, not even the author oneself, but everybody uses Windaube, and YES, it must be the latest and greatest one (XP is dead, welcome Windaube 9/XXX64 !!!

By the way, I have a slightly different opinion: don't create a "new" driver standard for old hardware, but create a new (much simpler) hardware standard, together with a new FS (much simpler and more efficient), and new programming language (much safer than C and with better syntax).
Post 09 Nov 2014, 06:18
View user's profile Send private message Reply with quote
BAiC



Joined: 22 Mar 2011
Posts: 272
Location: California
BAiC
perhaps the single greatest part of "hobby" is the freedom to let your imagination run wild. imposing "standards" within the kernel has far reaching implications in OS development so "standard" drivers are not something to take seriously.
Post 09 Nov 2014, 06:44
View user's profile Send private message Visit poster's website Reply with quote
zir_blazer



Joined: 05 Dec 2006
Posts: 66
zir_blazer
It SHOULD be possible to do this in UEFI, in the form of EFI Drivers. That would be your multiOS "compatibility layer". May also want to read this
http://board.flatassembler.net/topic.php?t=17261


axlucas wrote:
Uhm... I don't know... BIOS was supposed to do that work too and you see what happened. Besides, the code within UEFI is not free, so a free OS "should not" use it. Also, if we begin to rely on UEFI, then how about Coreboot?

The current status is not comparable to what happened originally with the BIOS. The BIOS provided services for OSes, but these services were hardcoded and pretty much only worked for the original Hardware supported functions of the PC IBM Hardware. You still needed OS level Drivers for any other non supported Hardware. Basically, as newer Hardware appeared with its own Drivers needs, BIOS became obsoleted for that purpose. But in the current API-driven world, you could make EFI Drivers, a standarized API, and let hobby OSes it.
Also, this is not related to Coreboot at all. Coreboot itself just initializes Hardware, it implements BIOS compatibility and services via SeaBIOS, and can also support UEFI with TianoCore.
Post 17 Nov 2014, 10:11
View user's profile Send private message MSN Messenger Reply with quote
sid123



Joined: 30 Jul 2013
Posts: 340
Location: Asia, Singapore
sid123
Maybe this should help? http://wiki.osdev.org/Uniform_Driver_Interface
Beware though, UDI is quite complex to implement, not really of a killer but hard.
Post 28 Nov 2014, 16:18
View user's profile Send private message Reply with quote
i-don



Joined: 18 Jul 2003
Posts: 66
i-don
Lately, I'm thinking the same like the OP but in wider scope such as an initiative to collect all of those open source OS source codes and turn it into a reusable OS building libraries in FASM includes tree similar to FASM libraries itself.

Various bootloaders, kernels, drivers, memory management, so on and so forth. Even the original OS creator also contribute to these OS building libraries under FASM so a new hobbyist OS no longer stuck in the beginning level. By objectify every level possible in OS making, the progress could advance into intermediate and advance level for hobbyist OS maker.

DexOS/MikeOS, Kolibri/Menuet, Linuxes and ReactOS could be a good resource to be started with to build this OS Building Libraries for FASM.
Post 14 Dec 2014, 16:00
View user's profile Send private message Reply with quote
bubach



Joined: 17 Sep 2004
Posts: 341
Location: Trollhättan, Sweden
bubach
There's also these interfaces, for your review:
EDI - http://forum.osdev.org/viewtopic.php?f=15&t=16592
CDI - http://lpt.tyndur.org/cdi/english/
Post 11 Jan 2015, 18:10
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.