Am 06/07/2011 11:23 AM, schrieb Laurent Gauch: > Hi Michael, >> Am 06/06/2011 02:10 PM, schrieb Laurent Gauch: >> >/ Yes, this is to decouple the open and init (open the handle, init >> />/ the associated specific layout). >> / >> Is there case where open is used without init, or init without open? >> > Actually no. But in the ft2232.c we could have the possibility to only > re-init a device+layout without the need to close open the handle. What is the use case for this? If this is not actually used, it just adds unnecessary complexity.
> Sure this will be useful when the ft2232.c will provide the > possibility to init for 'JTAG only' or init for 'SWD only' on a > already opened handle of the device. No ? Sure? No. Show a use case where this is really needed, *then* we can discuss if this is the right approach or not. Adding unused code for some future expansion that may never happen only adds cruft. >> Otherwise, this is just unnecessarily complex. >> >> >/ (more smaller function ... as good OO coding !) >> />/ >> />/ The ft2232_init_sub(void) and ft2232_init() could be merged again >> in a >> />/ ft2232_open if needed >> />/ >> />/ But yes, we have all different point of view regarding what is open >> />/ what is init ... >> />/ >> />/ The objective is to have something like : >> />/ >> />/ open >> />/ init >> />/ deinit >> />/ close >> />/ >> />/ and not as the actual >> />/ init >> />/ quit >> / >> open/close instead of init/quit is OK with me, but what is the advantage >> of the 4-function API instead of the old 2-function API? >> > > Now I understand . You are thinking we want to change the API of the > interface. NO NO NO . > We just want to decouple the open close handle and the init deinit > device + layout INSIDE the ft2232.c. > See the patch, we do not rename the quit() init(), we do not touch the > API concept ! Then why is the change *needed* at all? A simple deinit-on-exit should be possible with the current code with only minor modifications. cu Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
