Hi I been looking if it was posible todo, but it is not it is allot lowlevel stuff u need emulated, Linux kernel handling DMA, IRQ, IO complete diffent and it is not posible port OSS driver to windows arch or ros, it will be involed around 2 year coding todo so, see the USB stack that is from linux crow stack, and the network stack from freebsd both took two year getting alive in reactos. and it is really bad idea trying proting OSS it will invold another 2 year works only getting it alive, then u need getting bugs out. sorry to say that. it is almost same time frame getting OSS and orginal WDM audio driver working. in devloping time. and it is bad decistions using OSS
----- Original Message ----- From: reactos-development@silverblade.co.uk To: ros-dev@reactos.org Sent: Saturday, September 22, 2007 2:27 AM Subject: [ros-dev] Open Sound System porting
Hi guys,
I've been in touch with the guy that ported OSS to Haiku (open-source BeOS) after some discussion with the folks over at #winehackers to get some help with audio development.
Anyway, basically the idea so far is to use OSS as a "fall-back" audio driver implementation. So unless there is a "better" driver installed (ie an official one for an audio device), ReactOS can use an Open Sound System driver instead.
The result? There will at least be sound functionality.
OSS is designed to be mostly platform-independent. By rewriting a few of the core modules, the entire set of drivers will be able to work with whatever platform you desire.
This can be implemented on top of the existing MME API architecture for the moment, and can later be translated to use the WDM audio framework.
Anyway, having stuck the OSS code into my local ReactOS source tree, I'm trying to figure out how to get it to compile using rbuild. The first hurdle I have come across is that there is extensive use of ioctl. Indeed it seems that most ports of OSS work on platforms based on Posix (Unix?)
So my main question at this time is how to handle this? The calls in question appear to be documented inside a file called "soundcard.h" in the OSS sources however this just seems to be definitions for the ioctl codes. So I suspect a majority of the drivers are calling ioctl.
Therefore, I figure the best way around this is probably to provide a fake ioctl that provides the expected functionality, and make this wrap DeviceIoControl with something that can translate the ioctl parameters into whatever...
The only other way I see around this is to rewrite all calls to ioctl, and rewrite the IOCTL codes with NT-style ones.
Thoughts/ideas?
-------------------------------------------------------------------- mail2web.com - Microsoft® Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev