Ros-dev

ros-dev@reactos.org

1 participants
5793 discussions

Re: [ros-dev] Open Sound System porting
by reactos-development＠silverblade.co.uk 23 Sep '07

23 Sep '07

Thanks for all the replies so far. I find it quite insane that MSDN compares ioctl to DeviceIoControl. Whilst they achieve the same results, the actual parameters used etc. are entirely different. I'm not sure if Steven's suggestion would work (ie, use ws2_32) since, to my knowledge, that particular implementation is specific to sockets. Probably the best way around this then, would be to make an ioctl wrapper that takes the OSS-specific IOCTL codes, and translates them into custom NT IOCTL codes. The wrapper would take things like structures being passed via the ioctl and send them via DeviceIoControl instead. It does seem like a fair amount of work but if an appropriate "wrapper" is created, it could work... Original Message: ----------------- From: King InuYasha ngompa13(a)gmail.com Date: Sat, 22 Sep 2007 10:28:50 -0500 To: ros-dev(a)reactos.org Subject: Re: [ros-dev] Open Sound System porting Couldn't the source be patched to use DeviceIOControl instead of ioctl? According to MSDN about porting from UNIX to Win32, ioctl maps directly to DeviceIOControl, so it could be possible to simply change all the instances of ioctl to DeviceIOControl... On 9/22/07, Aleksey Bragin <aleksey(a)reactos.org> wrote: > > I didn't thoroughly look through the OSS source code, but if it has > some kind of platform-independent design in mind, then I would really > recommend porting, and porting with as minimal changes to the > original source code required (you probably are going to need a > wrapper-library, for ioctls at least, plus NT-specific parts). > > I may help too, because of the usb stack wrapping I did a while ago. > > > WBR, > Aleksey Bragin. > > > > > 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? > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -------------------------------------------------------------------- mail2web.com What can On Demand Business Solutions do for you? http://link.mail2web.com/Business/SharePoint

3 2

Re: [ros-dev] Open Sound System porting
by reactos-development＠silverblade.co.uk 22 Sep '07

22 Sep '07

4Front. Apparently it's "better". Original Message: ----------------- From: King InuYasha ngompa13(a)gmail.com Date: Sat, 22 Sep 2007 16:32:11 -0500 To: reactos-development(a)silverblade.co.uk, ros-dev(a)reactos.org Subject: Re: [ros-dev] Open Sound System porting Which OSS implementation are you looking at? The OSS/Free one, or the OSS one from 4Front? On 9/22/07, reactos-development(a)silverblade.co.uk < reactos-development(a)silverblade.co.uk> wrote: > > Thanks for all the replies so far. > > I find it quite insane that MSDN compares ioctl to DeviceIoControl. Whilst > they achieve > the same results, the actual parameters used etc. are entirely different. > > I'm not sure if Steven's suggestion would work (ie, use ws2_32) since, to > my knowledge, > that particular implementation is specific to sockets. > > Probably the best way around this then, would be to make an ioctl wrapper > that takes the > OSS-specific IOCTL codes, and translates them into custom NT IOCTL codes. > The wrapper > would take things like structures being passed via the ioctl and send them > via > DeviceIoControl instead. > > It does seem like a fair amount of work but if an appropriate "wrapper" is > created, it > could work... > > > Original Message: > ----------------- > From: King InuYasha ngompa13(a)gmail.com > Date: Sat, 22 Sep 2007 10:28:50 -0500 > To: ros-dev(a)reactos.org > Subject: Re: [ros-dev] Open Sound System porting > > > Couldn't the source be patched to use DeviceIOControl instead of ioctl? > According to MSDN about porting from UNIX to Win32, ioctl maps directly to > DeviceIOControl, so it could be possible to simply change all the > instances > of ioctl to DeviceIOControl... > > On 9/22/07, Aleksey Bragin <aleksey(a)reactos.org> wrote: > > > > I didn't thoroughly look through the OSS source code, but if it has > > some kind of platform-independent design in mind, then I would really > > recommend porting, and porting with as minimal changes to the > > original source code required (you probably are going to need a > > wrapper-library, for ioctls at least, plus NT-specific parts). > > > > I may help too, because of the usb stack wrapping I did a while ago. > > > > > > WBR, > > Aleksey Bragin. > > > > > > > > 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? > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > > > > -------------------------------------------------------------------- > mail2web.com What can On Demand Business Solutions do for you? > http://link.mail2web.com/Business/SharePoint > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -------------------------------------------------------------------- mail2web - Check your email from the web at http://link.mail2web.com/mail2web

2 1

Audit
by Aleksey Bragin 22 Sep '07

22 Sep '07

Hello, I recently asked Klemens to remove audit progress bar from the frontpage. Some wonder: why? The simple answer is obvious: Audit doesn't have anything to do with end-users, testers, or patch- submitters of the project. Audit is an effort run by ReactOS Development Team, and has only one goal: Reduce possible legal problems in future, when, and if, ReactOS starts to have commercial appliances. The process with file locking-unlocking is only the top of the iceberg, there is a huge amount of work to be done in order to maintain solid legal base for all our code. It can't be measured with a single progressbar, nor it needs to. It can't be done only with the help of ReactOS Development Team, a third party code reviewer is a must. We plan that too, but for later time, when there are more stable modules in ReactOS. Legal base consists of a number of factors: authorship and sources of the code and their legality, availability of documentation for certain interfaces and algorithms, development of test cases showing internal behaviour of certain API functions, licensing issues, 3rd party code reviewing process results, etc, etc, etc. I think it's rather clear to see that measuring all the above factors in a single percentage number can't sound serious for a project, nor can it be a real value of cleannes of the project. The respective Audit wikipage needs to be updated too WRT this email. Also please note, our audit process results are fully seen via SVN commits, so there is no hiding involved. With the best regards, Aleksey Bragin.

2 1

Re: [ros-dev] Open Sound System porting
by Aleksey Bragin 22 Sep '07

22 Sep '07

I didn't thoroughly look through the OSS source code, but if it has some kind of platform-independent design in mind, then I would really recommend porting, and porting with as minimal changes to the original source code required (you probably are going to need a wrapper-library, for ioctls at least, plus NT-specific parts). I may help too, because of the usb stack wrapping I did a while ago. WBR, Aleksey Bragin. > > 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?

2 1

Re: [ros-dev] rbuild and HALs module optimization
by Aleksey Bragin 22 Sep '07

22 Sep '07

David, what does a kernel-dev have to do with rbuild? Also, recent massive commits to the rbuild itself, and to various .rbuild files hardly prove your "rbuild is an umaintained piece of ... stuff" theory. It's, by the least measure, offensive to Herve's (and there were a few different patches submitted by various authors submitted) work he's been doing with rbuild. Or what is a "maintained rbuild", by your definition? How more should it be maintained? Note: not improved (we have a number of improvements pending to be implemented in it), but *maintained*. Another thing is completely wrong and counter-productive: irc is a wrong place for such question, since not all devs are there all the time. Now, back to the actual question. The biggest difference between ntoskrnl and HAL is that the first is as machine-independent as possible (still including some dependent code, but it's conditionally included), while the latter is actually very hardware dependent, so it does not make sense to unite x86 and PowerPC HALs, because they are going to contain just simply different source code. With the best regards, Aleksey Bragin. On Sep 21, 2007, at 8:11 PM, David Hinz wrote: > > Marc Piulachs schrieb: >> Does anyone agree with me on this? Maybe I’m missing something >> here but >> I would like to improve it. > > I don't think you will have much luck getting an answer, as afaik > rbuild > is currently more or less unmaintained and our kernel-dev left the > project. > > Maybe arty or hpoussin do have an oppinion regarding your question, > but > they seem to be rather busy most of the time... > > Have you tried asking on irc? Most devs hang out there... > > Greets, > > David Hinz

3 2

Open Sound System porting
by reactos-development＠silverblade.co.uk 22 Sep '07

22 Sep '07

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

5 5

Documentation
by Colin Finck 21 Sep '07

21 Sep '07

Hello, Recently, some developers wrote documentation about certain stuff related to ReactOS. But this documentation was only placed on their own web servers. In my opinion, it would be better if such stuff would (also) be committed to the "documentation" directory in SVN. Having documentation there makes sure that it does not get lost. Additionally, if the source file is committed (not a PDF or something like that), another person could extend the documentation further. I agree that not all documentary stuff needs to be on SVN. An example might be Magnus' Win32k syscall tables. But for example Andrew Greenwood's documentation about the Windows Multimedia Subsystems looks like something, which should be committed in my opinion. If you don't agree on committing this stuff, it would be nice if we could at least agree on an official document format, which should be used in the SVN tree. >From what I see, most documentations were created by using OpenOffice, so I think the OpenDocument Text format (ODT) would be a great choice. It is also supported by most word processors, thus most people should be able to open an ODT file. Up to now, I used RTF for formatted text documentations in SVN, but this format does not support things like shapes. Regards, Colin

7 16

Re: [ros-dev] Bugzilla's bug assigning process
by Aleksey Bragin 21 Sep '07

21 Sep '07

There is a list linked from that wikipage, which has a simple 1:1 relationship between developer and some development area. If it's wrong, please edit it. WBR, Aleksey Bragin. On Sep 21, 2007, at 3:04 AM, Ged wrote: > Aleksey Bragin wrote: >> If there are any questions, please post them right away here. >> > > How are these bugs being assigned? > I've been watching and most of the bugs which have been assigned have > been assigned to the wrong developer. > > Ged.

2 2

rbuild and HALs module optimization
by Marc Piulachs 21 Sep '07

21 Sep '07

If we don't have a ntoskrnl rbuild module for every supported architecture I don't understand why we do have a separate HAL rbuild module for every architecture (X86 , PowePC) and sub architecture (x86-Generic , x86-xbox , PowerPC-Generic) Currently we have a very complicated logic to compile the appropriate HAL with conditions (IF) and alias that point to the correct module for the target architecture. At the end always two dlls are going to be generated for every architecture hal_up and hal_mp so what's the reason to have a specific module for every architecture and not two generic modules that represent the two possible HAL modes (uniprocessor and multiprocessor) that dynamically include the appropriate source code for the platform (Architecture + Sub Architecture) being build? For example : <module name="hal_generic" > (common code to all architectures, sub architectures , UP and MP HALs) </module> <module name="hal_up" installname="halup.dll"> <library>hal_generic</library> <library>.. (common files to all UP HALs) <if property="ARCH" value="i386"> (X86 common files to all X86 UP HALs) <if property="OARCH" value="xbox"> (xbox specific files) </if> </if> </if propery="ARCH" value="powerpc"> (PPC common files) </if> </module> And the same for multiprocessor <module name="hal_mp" installname="halmp.dll" /> both files can be simply copied to the install cd and usetup will install the correct HAL renamed as hal.dll depending on the user selection. IMHO it greatly simplifies the process and is a more elegant solution than the current one.

2 2

Bugzilla's bug assigning process
by Aleksey Bragin 20 Sep '07

20 Sep '07

Hello, as you may already noticed Amine started his work as a bugzilla maintainer today, and some people were surprised by bugs being assigned to them. Amine does a preliminary bugs assignment, according to developers' work history in ReactOS. You are free to reassign to another dev, or reasign back to Ros-bugs(a)reactos.org if you don't want to fix that bug. Also, it's very important that you put your valid email address to the bugzilla account, so that it works correctly and emails you when needed. If there are any questions, please post them right away here. With the best regards, Aleksey Bragin.

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev