[ros-kernel] RE: [ros-cvs] CVS Update: reactos

[Alex Ionescu]

Hi Steven (and all),

Because the CC Stubs are, for now, the most important, I've audited them
all, and will post the results below:

CcCanIWrite OSR
CcCopyRead OSR
CcCopyWrite OSR
CcDeferWrite OSR
CcFastCopyRead OSR
CcFastCopyWrite OSR
CcFlushCache OSR
CcGetDirtyPages OSR
CcGetFileObjectFromBcb OSR 
CcGetFileObjectFromSectionPtrs OSR
CcGetLsnForFileObject OSR
CcInitializeCacheMap OSR
CcIsThereDirtyData OSR
CcMapData OSR
CcMdlRead OSR
CcMdlReadComplete OSR
CcMdlWriteComplete OSR
CcPinMappedData OSR
CcPinRead OSR
CcPrepareMdlWrite OSR
CcPreparePinWrite OSR
CcPurgeCacheSection OSR
CcRepinBcb OSR
CcSetAdditionalCacheAttributes OSR
CcSetBcbOwnerPointer OSR
CcSetDirtyPageThreshold OSR
CcSetDirtyPinnedData OSR
CcSetFileSizes OSR
CcSetLogHandleForFile OSR
CcSetReadAheadGranularity OSR
CcUninitializeCacheMap OSR
CcUnpinData OSR
CcUnpinDataForThread OSR
CcUnpinRepinnedBcb OSR
CcZeroData OSR
CcGetFlushedValidData GNU IFS
CcFastMdlReadWait GOOGLE GROUPS
CcFastReadNotPossible GOOGLE GROUPS
CcFastReadWait GOOGLE GROUPS
CcRemapBcb GNU IFS
CcScheduleReadAhead GNU IFS
CcWaitForCurrentLazyWriterActivity GNU IFS
CcMdlWriteAbort GNU IFS

I will continue auditing the other stubs that I've added (Mostly FsRtl,
because they are also in the IFS), but I won't post any sources here, unless
anyone requests it. I will be removing anything that I cannot find in an
alternate source.

Best regards,
Alex Ionescu


-----Original Message-----
From: ros-kernel-bounces at reactos.com [mailto:ros-kernel-bounces at reactos.com]
On Behalf Of Steven Edwards
Sent: June 25, 2004 6:42 PM
To: ReactOS Kernel List
Subject: RE: [ros-kernel] RE: [ros-cvs] CVS Update: reactos

Hi Hartmut,

--- Hartmut Birr <Hartmut.Birr at gmx.de> wrote:
> the first paragraph of each M$ EULA says what you can do with the
> software. 
> This one comes from the w2kddk:

Ok I didnt have the DDK or the IFS kit here. 

In the case of the ext2fsd driver Alex sent me stubs for, I can think
of one way we can get around this issue. It is a Windows driver, and as
such you are going to have to know the interface names and paramaters
in order to be able to develop a driver for Windows. Now if we take the
information we learn in developing that driver and adapt it in ReactOS
this would not violate the EULA as far as I can tell. After all we have
just developed a Windows driver. 

So whats the solution? 

As far as I see it all of our drivers should work out of the box on
Windows. All of your recent work in making the storage drivers and such
compatible is a step in the right direction. If we do this with all of
our drivers then we are building drivers for a Windows platform and we
are not violating the EULA. 

So what about stubs?

It means we are limited to only what we can find on google or MSDN
unless someone develops a driver for Windows/ReactOS and then stubs the
interface. This does not sound like a bad thing. It means you cant
develop a driver for ReactOS thats incompatible with Windows.

Does this sound like a workaround that can work? I mean a EULA is not
the same thing as copyright so how could you claim that by me stubbing
a interface from a driver I developed using the DDK is a derivative
work. If anything its a Derivative work of the driver. If you try to
say that I cant take the information I learn from looking at the
ext2fsd and add stubs to ReactOS then you have added a restriction on
the GPL. 

If that wont work then it means you cant develop GPL drivers from the
DDK at all.

Thanks
Steven



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 
_______________________________________________
Ros-kernel mailing list
Ros-kernel at reactos.com
http://reactos.com/mailman/listinfo/ros-kernel