Re: addi-data drivers

On Monday 03 September 2007 02:56, Anders Blomdell wrote:
> Frank Mori Hess wrote:
> > I have some suggestions:  the addi-data stuff should be built in its
> > subdirectory instead of being pulled up into comedi/drivers, so you
> > want to edit the Kbuild and Makefile.am in the addi-data subdirectory.
>
> Why handle the addi-data drivers differently from other drivers? If
> ADDI-DATA had shown interest in maintaining their drivers, the current
> organization makes sense (since restricted CVS access could be used).
> The drivers I build, is just a quick hack to break apart the big
> monolitic driver into one driver per card-type (and only stop building
> the drivers that need kernel floating point).

It would be fine if the addi-data subdirectory is completely removed too.  
Although, I slightly prefer having it, as the main drivers directory is 
becoming rather large, and the addi-data stuff does include a couple files 
shared only among the addi drivers.  Or, if the addi-data subdirectory was 
for building a shared addi_common module that would make sense too.  I'm 
just trying to prod you into submitting nicer code than "a quick hack".  
If everyone who adds code to comedi just puts in quick hacks, the code 
quality will only degenerate.  That said, what you've done is certainly 
better than nothing and I will commit it, as you don't seem interested in 
spending more time on it.  Maybe I'll fix it myself one day, after I stop 
the NI drivers from including ni_mio_common.c.

> > Also, would it be difficult to make addi_common a module instead of
> > including it into all the drivers?
>
> I guess so, since addi_common.c declares boardtypes[] (which I
> blantantly break apart by ugly ifdef's). I'm also not sure what it's
> worth, since it would only matter if you have two different kinds of
> cards in the same computer (or am I missing something?).

You're probably not missing anything, but to be specific: it increases 
compile time, increases the sum total size of the binary modules as far as 
disk and memory space goes (memory only in the case you note), and most 
importantly to me it's ugly code (as you note yourself).

-- 
Frank