Am 05.09.2012 um 04:15 schrieb Kent A. Reed: > On 9/4/2012 6:11 PM, Sebastian Kuzminsky wrote: >> On Sep 4, 2012, at 15:46 , Kent A. Reed wrote: >> >>> On 9/4/2012 5:02 PM, Sebastian Kuzminsky wrote: >>>> On Sep 4, 2012, at 13:12 , Michael Haberler wrote: >>>> >>>>> I've committed the simulator (user-mode) parport driver to master: >>>>> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=31acddb62d957f1059046caa5e7236c2b5eef613 >>>>> >>>>> it's separate for now from the real hal_parport files until it has shaken >>>>> out a bit. See src/hal/simdrivers/README.uparport for the fineprint. >>>>> >>>>> I'd be interested to hear about experiences >>>> It broke many of the buildbot builds: >>>> >>>> http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/502 >>>> >>> Presumably because it introduces a new dependency on an external project >>> https://libcpuid.svn.sourceforge.net >>> >>> I'm not sure what the right answer is here. Putting this experimental >>> driver into master makes it easily accessible to folks like me who >>> forget Michael's git hub but at the same time it's what the Saturday >>> Night show would call Not Ready For Prime Time. >> I generally dislike forking external projects and including a copy of them >> within LinuxCNC. It adds the developer burden of merging from the external >> project, and bloats our repo and our packages. >> >> I'd prefer to use external packages that are available as debian packages >> for our supported distros (LTSes Hardy, Lucid, and Precise), or (if that's >> not possible) packaging the external project as a deb and making it >> available in our debian archives (like Jeff did with asciidoc to make it >> available on Hardy). >> >> It just makes for more modular, debuggable, sharable software over all. >> > > Sebastian: you won't get an argument from me about that, but this isn't > my driver we're talking about. > > Michael: at a quick glance, it appears there are two possibilities > > 1) include all of Veselin Georgiev's source code. The good thing is, his > license statement permits this, even if we modify it in someway. The bad > news is, he has rolled his own license statement so it is one more thing > to worry about.
uh. I'll find an alternative way to get the clock frequency, and remove the libcpuid dependency. > 2) I didn't dig very deep, but it looks like you only need libcpuid to > get the cpu_clock value. yes, that's all I used. > For Linux, Georgiev's code does just what I > would do, it looks at the content of /proc/cpuinfo. Couldn't we do that > too? [I know you run MacOS so this may not be an acceptable solution for > you.] > > Regards, > Kent - Michael > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
