Re: [ros-dev] [ros-diffs] [janderwald] 44644: [SETUPAPI] - Implement SetupDiInstallDeviceInterfaces, SetupDiCreateDeviceInterfaceRegKeyW which are required to store device specific information

[Hervé Poussineau]

janderwald(a)svn.reactos.org a écrit :
>   Author: janderwald
>  Date: Fri Dec 18 05:37:15 2009
>  New Revision: 44644
>
>  URL: http://svn.reactos.org/svn/reactos?rev=44644&view=rev
>  Log:
>  [SETUPAPI]
>  - Implement SetupDiInstallDeviceInterfaces, SetupDiCreateDeviceInterfaceRegKeyW which are
> required to store device specific information
>
>  Modified:
>      trunk/reactos/dll/win32/setupapi/devinst.c
>      trunk/reactos/dll/win32/setupapi/interface.c
>      trunk/reactos/dll/win32/setupapi/setupapi_private.h
>
>     
[...]
>   +
>  +    InsertTailList(&devInfo->InterfaceListHead, &DevItf->ListEntry);
>  +
>  +    memcpy(&DeviceInterfaceData.InterfaceClassGuid,
> &DevItf->InterfaceClassGuid, sizeof(GUID));
>  +    DeviceInterfaceData.cbSize = sizeof(SP_DEVICE_INTERFACE_DATA);
>  +    DeviceInterfaceData.Flags = DevItf->Flags;
>  +    DeviceInterfaceData.Reserved = (ULONG_PTR)DevItf;
>  +
>  +    hKey = SetupDiCreateDeviceInterfaceRegKeyW(DeviceInfoSet, &DeviceInterfaceData,
> 0, KEY_ALL_ACCESS, NULL, 0);
>  +    HeapFree(GetProcessHeap(), 0, DevItf);
>  +    if (hKey == INVALID_HANDLE_VALUE)
>  +    {
>  +        return FALSE;
>  +    }
>  +
>     
Seems like you're keeping in DeviceInterfaceData.Reserved a pointer to a 
deleted structure... Is it intentional?

[Gregor Schneider]

Most likely not, MSDN mentions "do not use" concerning this field.
Ref: http://msdn.microsoft.com/en-us/library/ms793004.aspx

2009/12/18 Hervé Poussineau <hpoussin(a)reactos.org>

>   janderwald(a)svn.reactos.org a écrit :
> >   Author: janderwald
> >  Date: Fri Dec 18 05:37:15 2009
> >  New Revision: 44644
> >
> >  URL: http://svn.reactos.org/svn/reactos?rev=44644&view=rev
> >  Log:
> >  [SETUPAPI]
> >  - Implement SetupDiInstallDeviceInterfaces, 
>  SetupDiCreateDeviceInterfaceRegKeyW
> which are required to store device
>  specific information
> >  
> >  Modified:
> >      trunk/reactos/dll/win32/setupapi/devinst.c
> >      trunk/reactos/dll/win32/setupapi/interface.c
> >      trunk/reactos/dll/win32/setupapi/setupapi_private.h
> >
> >  
>  [...]
> >   +
> >  +    InsertTailList(&devInfo->InterfaceListHead, &DevItf->ListEntry);
> >  +
> >  +    memcpy(&DeviceInterfaceData.InterfaceClassGuid, 
> &DevItf->InterfaceClassGuid, sizeof(GUID));
> >   +    DeviceInterfaceData.cbSize =
> > sizeof(SP_DEVICE_INTERFACE_DATA);
> >  +    DeviceInterfaceData.Flags = DevItf->Flags;
> >  +    DeviceInterfaceData.Reserved = (ULONG_PTR)DevItf;
> >  +
> >  +    hKey = SetupDiCreateDeviceInterfaceRegKeyW(DeviceInfoSet, 
> &DeviceInterfaceData, 0, KEY_ALL_ACCESS, NULL, 0);
> >   +    HeapFree(GetProcessHeap(), 0, DevItf);
> >  +    if (hKey == INVALID_HANDLE_VALUE)
> >  +    {
> >  +        return FALSE;
> >  +    }
> >  +
> >  
>  Seems like you're keeping in DeviceInterfaceData.Reserved a pointer to a
>  deleted structure... Is it intentional?
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Johannes Anderwald]

Hervé Poussineau schrieb:
>   janderwald(a)svn.reactos.org a écrit :
>    
>
>  Seems like you're keeping in DeviceInterfaceData.Reserved a pointer to a 
>  deleted structure... Is it intentional?
>     
Definitely not ;)

Thanks
Johannes Anderwald

[Gregor Schneider]

Good one in r44649, but I guess Hervè was actually concerned about this
line:

DeviceInterfaceData.Reserved = (ULONG_PTR)DevItf;

(It also stores the pointer to the freed structure.)

2009/12/18 Johannes Anderwald <janderwald(a)reactos.org>

>   Hervé Poussineau schrieb:
> >   janderwald(a)svn.reactos.org a écrit :
> >
> >
> >  Seems like you're keeping in DeviceInterfaceData.Reserved a pointer to a
> >  deleted structure... Is it intentional?
> >  
>  Definitely not ;)
>
>  Thanks
>  Johannes Anderwald
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Johannes Anderwald]

Gregor Schneider schrieb:
>   Good one in r44649, but I guess Hervè was actually
> concerned about 
>  this line:
>   
>  DeviceInterfaceData.Reserved = (ULONG_PTR)DevItf;
>   
>  (It also stores the pointer to the freed structure.)
>    
Hi,
That structure is just a local variable and it is not touched after 
freeing the DevItf.

kind regards,
Johannes Anderwald

[victor martinez]

Hi,
Latelly i am finding myself(and also other Testers) arriving to big gaps of non-built isos
while performing a regression testing.
Most of these big gaps are caused by "broken trunk" while devs keep commiting. 
My suggestion is:
-Could we create a parallel repository where the devs can continue commiting in a safe way
while the trunk is automatically frozen by our buildbot when an ISO cant be created?
-Just the guilty dev will have access to send the patch to the main repository, then
buildbot tries to compile with the patch, detects the ISO has been correctly compilled and
it automatically opens the SVN again AFTER pulling ONE by ONE(and compilling them) all the
revisions sent to this second repository.

Advantages:
-Devs wont find the trunk closed and can commit.
-Testers wont find gaps when regtesting.

Disadvantages: 
? (fill them here)

Thanks for your minute of attention. :)
 		 	   		  
_________________________________________________________________

[Ged Murphy]

This has already been discussed at length many times and even attempted in
the past. It's called a Content Management System.
We know exactly what's needed, the problem is getting someone to implement
it, and implement it well



On Fri, Dec 18, 2009 at 2:11 PM, victor martinez <vicmarcal(a)hotmail.com>wrote;wrote:

>  
>
>  Hi,
>  Latelly i am finding myself(and also other Testers) arriving to big gaps of
>  non-built isos while performing a regression testing.
>  Most of these big gaps are caused by "broken trunk" while devs keep
>  commiting.
>  My suggestion is:
>  -Could we create a parallel repository where the devs can continue
>  commiting in a safe way while the trunk is automatically frozen by our
>  buildbot when an ISO cant be created?
>  -Just the guilty dev will have access to send the patch to the main
>  repository, then buildbot tries to compile with the patch, detects the ISO
>  has been correctly compilled and it automatically opens the SVN again AFTER
>  pulling ONE by ONE(and compilling them) all the revisions sent to this
>  second repository.
>
>  Advantages:
>  -Devs wont find the trunk closed and can commit.
>  -Testers wont find gaps when regtesting.
>
>  Disadvantages:
>  ? (fill them here)
>
>  Thanks for your minute of attention. :)
>
>  _________________________________________________________________
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Daniel Verkamp]

On Fri, Dec 18, 2009 at 1:44 PM, Ged Murphy <gedmurphy(a)gmail.com> wrote:
>   This has already been discussed at length many times
> and even attempted in
>  the past. It's called a Content Management System. 
You probably mean Continuous Integration System.

[Ged Murphy]

Hah, yep I meant CIS
Not sure why that came out as CMS ... 

-----Original Message-----
From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Daniel Verkamp
Sent: 18 December 2009 22:21
To: ReactOS Development List
Subject: Re: [ros-dev] Another SVN repository...

On Fri, Dec 18, 2009 at 1:44 PM, Ged Murphy <gedmurphy(a)gmail.com> wrote:
>   This has already been discussed at length many times
> and even attempted in
>  the past. It's called a Content Management System. 
You probably mean Continuous Integration System.

_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev