Drivers?
Drivers?
Hi, everyone!
I just read your discussion about UDI at 2010 and didn't understand - are there some UDI drivers and implemented interface or not?
But in spite of UDI, where can I get drivers for my hobby OS if I am too lazy to write drivers like video driver etc.?
I just read your discussion about UDI at 2010 and didn't understand - are there some UDI drivers and implemented interface or not?
But in spite of UDI, where can I get drivers for my hobby OS if I am too lazy to write drivers like video driver etc.?
Hobby stuff (suckless libs, compilators, game engines, kernels): github. Work @ zabbix: arseniuss@zabbix
Re: Drivers?
There is a reference implementation, at the very least. Some drivers, too.arseniuss wrote:...are there some UDI drivers and implemented interface or not?
Well, just make your kernel fully Linux compatible, and use the Linux drivers. Or make it Windows compatible, and use the Windows drivers.But in spite of UDI, where can I get drivers for my hobby OS if I am too lazy to write drivers like video driver etc.?
No, wait...
Don't start OS development. We're talking man-years of work before you can do anything sensible with your OS, drivers or not. If you talk about "lazy" before you even get started, save the effort....if I am too lazy...
Every good solution is obvious once you've found it.
Re: Drivers?
My TIP:Dont be lazy ,be hardworking.All of them who suceed came through hardwork.
I had read a lot to make myself through OSdevelopment.
Dont be lazy, hope you know many many moral stories.
I had read a lot to make myself through OSdevelopment.
Dont be lazy, hope you know many many moral stories.
Re: Drivers?
I was kidding about laziness 'cause I have only one life and I can't write all drivers for every machine.
But I'm searching for interface which allows me don't worry about drivers.
And also I wanted know what are happening with UDI, CDI. Does anyone implementing UDI and really testing?
But I'm searching for interface which allows me don't worry about drivers.
And also I wanted know what are happening with UDI, CDI. Does anyone implementing UDI and really testing?
Hobby stuff (suckless libs, compilators, game engines, kernels): github. Work @ zabbix: arseniuss@zabbix
Re: Drivers?
CDI is actively used by some OSes, and even though there haven't been many changes or new drivers lately, developers are still around and would pick it up again if they need anything new for their OSes.
But, of course, it's not big and professional like UDI...
But, of course, it's not big and professional like UDI...
Re: Drivers?
Start with UDI.
The short of it is, the "official" UDI project is dormant, as the major players have withdrawn their funding when the dotcom bubble went "pop". But the architecture, the specifications etc. are there.
Linux has issues regarding the license and the kernel / driver interface, Windows drivers are out of the question for obvious reasons, I don't know how well BSD drivers could be made to work outside the BSD kernel / POSIX environment, and I also don't know how well the Extensible Driver Interface or CDI efforts fared, or how well-designed they are.
The short of it is, the "official" UDI project is dormant, as the major players have withdrawn their funding when the dotcom bubble went "pop". But the architecture, the specifications etc. are there.
Linux has issues regarding the license and the kernel / driver interface, Windows drivers are out of the question for obvious reasons, I don't know how well BSD drivers could be made to work outside the BSD kernel / POSIX environment, and I also don't know how well the Extensible Driver Interface or CDI efforts fared, or how well-designed they are.
Every good solution is obvious once you've found it.
Re: Drivers?
I think it doesn't hurt that Linux, Windows etc. are not using UDI (at least not in the context of this question). It would be more important whether other hobby OSes here around are using it, so that you can discuss and actually share stuff with them. Last time I checked, Combuster had some first parts, but most other people were discussing on a mostly theoretical basis.
Re: Drivers?
So there is some example code of UDI implemented?Last time I checked, Combuster had some first parts, but most other people were discussing on a mostly theoretical basis.
Hobby stuff (suckless libs, compilators, game engines, kernels): github. Work @ zabbix: arseniuss@zabbix
Re: Drivers?
*sigh*
You haven't read UDI, have you?
There's a complete reference implementation available on SourceForge.
You haven't read UDI, have you?
There's a complete reference implementation available on SourceForge.
Every good solution is obvious once you've found it.
Re: Drivers?
I meant operating system which uses UDI...
And I'm going to print UDI documentation anyway.
And I'm going to print UDI documentation anyway.
Hobby stuff (suckless libs, compilators, game engines, kernels): github. Work @ zabbix: arseniuss@zabbix
Re: Drivers?
I am not sure what you mean with "operating system which uses UDI". The reference implementation supports Linux (2.4 kernel), FreeBSD, Solaris, and UnixWare.arseniuss wrote:I meant operating system which uses UDI...
Every good solution is obvious once you've found it.
Re: Drivers?
I meant hobbyists.
Hobby stuff (suckless libs, compilators, game engines, kernels): github. Work @ zabbix: arseniuss@zabbix
Re: Drivers?
...aaaaand what difference would that make, whether the UDI implementation is by a hobbyist or the UDI people themselves?
Every good solution is obvious once you've found it.
Re: Drivers?
Based on basics and not so complicated which makes it easier understand and implement...
Hobby stuff (suckless libs, compilators, game engines, kernels): github. Work @ zabbix: arseniuss@zabbix
Re: Drivers?
I feared something like that.
UDI is based on an API. A contract.
If you dumb down your UDI implementation, chances are the driver you take from somewhere else won't work on top of that. And if you write drivers specific to a dumbed-down version of UDI, it wouldn't benefit those who employ a full-fledged implementation. You would effectively create a fork, harming the whole concept of UDI.
UDI is not simple. Nor is it well-maintained. If that scares you, don't use it.
UDI is based on an API. A contract.
If you dumb down your UDI implementation, chances are the driver you take from somewhere else won't work on top of that. And if you write drivers specific to a dumbed-down version of UDI, it wouldn't benefit those who employ a full-fledged implementation. You would effectively create a fork, harming the whole concept of UDI.
UDI is not simple. Nor is it well-maintained. If that scares you, don't use it.
Every good solution is obvious once you've found it.