Using linux drivers in reactos !

[Z98]

Even ignoring the technical challenges, no one has presented an argument of why this is in any way beneficial. Windows already has wider hardware support. Completing support for the Windows kernel interface would get us access to much more hardware than any equivalent effort to getting Linux drivers to work. So why should we do more work for less benefits?

[Aeneas]

Dear Z98,

Because it is presumed to be faster?

Linux WORKS. Linux' source is available.

Windows works, too, but you do not have the source. While Windows works, that is no immediate advantage to ReactOS, because it is ReactOS that does not work yet.

And ReactOS' progress of clean re-engineering is ... well, SUPER SLOW. It does not look like you can use Windows' drivers within the next year or two, does it? And how long do you think can you still develop, before the driver model becomes irrelevant? For all I know, Vista handles stuff differently. How long are new products going to come out into the market that even HAVE XP drivers?

You are doing an outstanding job, but I read somewhere that a programmer can realistically manage 5000 lines of C-code (as rough as such estimates may be). 30 developers gives 300k lines of code if each of you are double as good as the others.

So... "what's the plan"? How precisely do you intend to make ReactOS useable to the "real world hardware"? Maybe, after all, you do not need that long to adapt ReactOS to use Windows drivers?

[Z98]

The goal of this project is to be able to run Windows applications and use Windows drivers. If what you want is an OS you can use for everyday tasks right now, ReactOS is not it. People keep presenting what they think are shortcuts to everyday usability. Allow me to state here and now that code reuse from the Linux kernel will do nothing to help shorten the time it will take. It is far more likely to increase the amount of work and time needed because of the need to set up a translation layer and then accommodate all of the edge cases or functionality that Linux provides but does not exist in NT, or exists in an incompatible fashion. Then there's the fact that the Linux kernel devs like to constantly change their driver API, which risks breaking all sorts of things between their so-called versions. Nobody else has seriously attempted to do what this project is doing at the kernel level. Therefore there does not exist a large body of code that is useful or usable by this project to fill in gaps. When considering kernel code, there is almost nothing that can be shared between OSes of different architectures. Every attempt to try and borrow code from another OS' kernel for ReactOS has ended in either failure or the component was incredibly unreliable to the point of being unusable by most people trying it. The only times where importing of third party code worked was when the original developers intended for their code to be embedded, so that they took the effort to make their interfaces clean and did not depend on dozens of other libraries and the like.

[BlackRabbit]

t is far more likely to increase the amount of work and time needed because of the need to set up a translation layer and then accommodate all of the edge cases or functionality that Linux provides but does not exist in NT, or exists in an incompatible fashion.

I agree. It is better to attack the primary problem head-on than spend time on something secondary.

[alexei]

Allow me to state here and now that code reuse from the Linux kernel will do nothing to help shorten the time it will take. It is far more likely to increase the amount of work and time needed

I agree. This issue came up on this forum repeatedly, and this answer was given several times (shouldn't it be a sticky post with explanation once and for all?).
I proposed different approach, which is not reuse of lunux code, but using Linux (or other) OS as is (or with minimal changes) to provide hardware support for ROS. Having such technology implemented may give practical benifits instantly, but most importantly would open perspective of improving ROS stability, flexibility, and security. For example, running multiple ROS instances designated to different hardware (and software?). Here we come to the question of to which extent ROS should mimic MS Windows and try to keep up with it?
But that's off topic here...

[fred02]

Allow me to state here and now that code reuse from the Linux kernel will do nothing to help shorten the time it will take. It is far more likely to increase the amount of work and time needed

I agree. This issue came up on this forum repeatedly, and this answer was given several times (shouldn't it be a sticky post with explanation once and for all?).

I agree that something similar to "read this if you found a software useful for ROS" can be helpful. But I would rather see a link to an FAQ on the wiki, so it can be edited and maintained more easily and by several persons.
Should I go ahead and try to compile such a list? Out of my head I have these topics:
- Why not use Linux drivers in ROS?
- Why not run ROS on top of Linux/XEN/<other hyperviser>?
- Why not use <programming language here> to develop ROS?
- ROS must be compatible with Seven/8/Metro.
- ROS should switch its effort to develop ARM port.
- ROS must target new/old hardware.
- Developers must work on <USB/user shell/NTFS/etc.> and forget <updater/arwinss/MM/CC>.
- ROS should switch to ext2/3/4 fs.
- ROS should have browser/mail/office/photoshop included.
- ROS should support DirectX9/10/11.
- (many more)

The main difficulty is to dig official and up to date statements about these. At the moment I know where are two: about Linux drivers in this thread, and about programming language in GO thread.
I can try to find the others, if the official ROS representatives agree to have such a list compiled and pinned.

(I had a quick look on the current FAQ, but it seems dated, and does not answer to the above questions, at least not directly.)

[milon]

I proposed different approach, which is not reuse of lunux code, but using Linux (or other) OS as is (or with minimal changes) to provide hardware support for ROS.

That's not the goal of ReactOS, nor does it help approach the goal of ReactOS. The goal of ReactOS is to provide a Windows-compatible OS. Introducing things that are not a part of the goal will either have to be a fork that you create yourself, or else an additional goal added after the primary goal is met. Please do not attempt to create a fork of ReactOS - that would hurt everyone to divide the project like that. As for it being a goal added down the road, I don't see a solid reason for it at that point. In short, there is no reason now and there will be no reason in the future to blend any other OS into ROS.

Having such technology implemented may give practical benifits instantly, but most importantly would open perspective of improving ROS stability, flexibility, and security. For example, running multiple ROS instances designated to different hardware (and software?). Here we come to the question of to which extent ROS should mimic MS Windows and try to keep up with it?

1) It will not give any benefits instantly. I guarantee that.
2) Any improved stability, flexibility, or security would be an illusion. If the benefit doesn't come from ReactOS itself, then it will not be around in the long run. Again, the goal of ReactOS is to be a Windows-compatible OS. That means any linux (or whatever) code will be scrapped down the line. There is no point pouring time & effort into a temporary crutch when we could instead be making ROS stable and flexible and secure in its own right.

[fred02]

there is no reason now and there will be no reason in the future to blend any other OS into ROS.

I would like to nuance that: there is no need to blend an OS, since NT core made provision for multiples personalities from start.
[dream mod on] So in a distant future in a galaxy far far,,, oups, where was I, ah personalities. POSIX will probably be the most interesting to import or implement, and we can try to convert some OS/2 addicts.[dream mod off] And so there were no more OS WARS, duh, got carried away again.

[Z98]

Allow me to state here and now that code reuse from the Linux kernel will do nothing to help shorten the time it will take. It is far more likely to increase the amount of work and time needed

I agree. This issue came up on this forum repeatedly, and this answer was given several times (shouldn't it be a sticky post with explanation once and for all?).
I proposed different approach, which is not reuse of lunux code, but using Linux (or other) OS as is (or with minimal changes) to provide hardware support for ROS. Having such technology implemented may give practical benifits instantly, but most importantly would open perspective of improving ROS stability, flexibility, and security. For example, running multiple ROS instances designated to different hardware (and software?). Here we come to the question of to which extent ROS should mimic MS Windows and try to keep up with it?
But that's off topic here...

If you want support for Windows drivers, your proposal is no different than trying to reuse Linux kernel code, with all of the difficulties I've already stated. If you only care about Windows applications, then just go use Linux with Wine.

[PascalDragon]

Even ignoring the technical challenges, no one has presented an argument of why this is in any way beneficial. Windows already has wider hardware support. Completing support for the Windows kernel interface would get us access to much more hardware than any equivalent effort to getting Linux drivers to work. So why should we do more work for less benefits?

There might not be any direct benefit for ReactOS, but it might nevertheless be a worthwhile and interesting topic to research independantly(!) of ReactOS.

And as I already wrote: I would do that if I currently had the time for something like this.

I would like to nuance that: there is no need to blend an OS, since NT core made provision for multiples personalities from start.

Only for user mode though.

Regards,
Sven

[fred02]

I would like to nuance that: there is no need to blend an OS, since NT core made provision for multiples personalities from start.

Only for user mode though.

Of course, thank you to precise that.

[hbelusca]

- Developers must work on <USB/user shell/NTFS/etc.> and forget <updater/arwinss/MM/CC>.
- ROS should switch to ext2/3/4 fs.

Ouuhh là là là là là là !!!!!!

I don't think you know what MM and CC is.

Because without working AND stable Memory Manager and Cache Controller, you can say "goodbye" to working USB, NTFS / ext2/3/4 fs (any other file-system), etc. etc...

[Z98]

He was pointing out examples of bad suggestions.

[fred02]

Ouuhh là là là là là là !!!!!!

I don't think you know what MM and CC is.

Because without working AND stable Memory Manager and Cache Controller, you can say "goodbye" to working USB, NTFS / ext2/3/4 fs (any other file-system), etc. etc...

He was pointing out examples of bad suggestions.

Indeed, although I probably pushed a bit far with these two.
The main point of this line was to illustrate some intransigent (and also exotic/unrealistic or blatantly technically incorrect, as you pointed out) demands that are made to the developers, almost as they were subordinates, completely disregarding the fact that it is a FOSS project based on voluntary contributions.

[alexei]

Any improved stability, flexibility, or security would be an illusion. If the benefit doesn't come from ReactOS itself, then it will not be around in the long run. Again, the goal of ReactOS is to be a Windows-compatible OS. 


Take a look at Qubes OS, QNX, Genode, even Puppy Linux. They are secure and flexible, though via very different approaches.
Ability to use several instances of Linux to support designated hardware would allow to do the same with ROS when it become mature enough. Each driver or application could be run in its own ROS instance isolated from the rest of the system. Don't you see security advantage here? Don't you see how flexible such system could be?
The earlier such multi-instanse capability is established, the better. That's why I'm talking about it now.