Re: [Openocd-development] policy vs. mechanism
On Tuesday 01 December 2009, Zach Welch wrote: > > However ... splitting ft2232.c into chunks would be good. > > One per adapter. It's quite a mess now. > > I just mentioned this to someone else today off-list! It's like you're > reading my mind eeek! ;) Creepy! Great minds think alike. :) Yeah, I'm carrying around some XDS100 code, waiting for a real opportunity to test. (Or maybe someone with some XDS100 version and some time would be interested ... ?) It needs updating every time someone provides a new FT2232x based driver; ugh. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] policy vs. mechanism
On Tue, 2009-12-01 at 20:57 -0800, David Brownell wrote:
> On Tuesday 01 December 2009, Zach Welch wrote:
> > After the command cleanup that I have started, I believe this type of
> > factoring deserves to be pursued in the other modules. I propose making
> > these changes in the following order:
> >
> > - svf, xsvf, pld: simple core/tcl separation: */core.c and */tcl.c
>
> And maybe merge svf and xsvf into a common directory, so their
> sharing is a bit less convoluted.
Great. I am all for this too.
> > - flash/nor, flash/nand: likewise, if renamed; otherwise *_{core,tcl}.c
> > - target.c: split into target/core.c and target/tcl.c
>
> Probably fair, although I'd be skeptical about internals
> getting exposed there.
>
> One way to address that issue of exposure: switch #include "foo.h"
> over to #include "subdir/foo.h", and minimize the inclusion of
> stuff from other directories. The "/" will flag potential trouble.
I just sent another proposal that I had written up, waiting for feedback
from others on this one. :) We are on the same page here, I think.
>
> > - split drivers similarly: .c and _tcl.c
>
> I'm not quite so keen on that one. Few of them have many Tcl
> functions, and splitting them out separately wouldn't win ...
> it'd just open up innards that *ought* to stay private.
It's about using the same tricks I just used with #if.
I suppose that this could be skipped... anyway, it's a ways out and this
point deserves revisiting.
> However ... splitting ft2232.c into chunks would be good.
> One per adapter. It's quite a mess now.
I just mentioned this to someone else today off-list! It's like you're
reading my mind eeek! ;) Creepy! Great minds think alike.
--Z
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] policy vs. mechanism
On Tuesday 01 December 2009, Zach Welch wrote:
> After the command cleanup that I have started, I believe this type of
> factoring deserves to be pursued in the other modules. I propose making
> these changes in the following order:
>
> - svf, xsvf, pld: simple core/tcl separation: */core.c and */tcl.c
And maybe merge svf and xsvf into a common directory, so their
sharing is a bit less convoluted.
> - flash/nor, flash/nand: likewise, if renamed; otherwise *_{core,tcl}.c
> - target.c: split into target/core.c and target/tcl.c
Probably fair, although I'd be skeptical about internals
getting exposed there.
One way to address that issue of exposure: switch #include "foo.h"
over to #include "subdir/foo.h", and minimize the inclusion of
stuff from other directories. The "/" will flag potential trouble.
> - split drivers similarly: .c and _tcl.c
I'm not quite so keen on that one. Few of them have many Tcl
functions, and splitting them out separately wouldn't win ...
it'd just open up innards that *ought* to stay private.
However ... splitting ft2232.c into chunks would be good.
One per adapter. It's quite a mess now.
- Dave
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
