For what it's worth... I would second the notion that the new behavior be the default. Much higher likelihood that it would "just work."
On 02/27/2017 10:52 AM, Jon Elson wrote: > On 02/27/2017 09:42 AM, John Kasunich wrote: >> >> On Sun, Feb 26, 2017, at 03:51 PM, Jon Elson wrote: >>> Actually, I thought option 1 was the "best", but required a >>> bit more code and more testing. >>> Since I've discovered the offending line occurs in ONE and >>> only one place in the whole driver (I think), >>> then conditional compilation of one copy of the source seems >>> like a workable solution. >> Option 1 seems complex, and you really don't want to be twiddling parport >> bits on every LinuxCNC startup, who knows what is connected to those bits. > Well, the driver certainly twiddles some bits as it scans > the bus to see what PPMC devices are out there. If you > don't have one of the Pico Systems boards attached, you'd > have no reason to invoke the ppmc driver. I'm not > contemplating touching the generic parport driver, only > hal_ppmc. >> I prefer option 2. If there are tweaks needed to help the driver adapt to >> the hardware, the logical thing to do is to tell the driver about those >> tweaks at load time. > Yes, this may actually be easier, as it doesn't require > major mucking around in the Makefiles to produce two > versions of hal_ppmc. I'm now leaning more toward this. I > think I will make the default setting to be the "new way", > so existing configs won't have to be changed to use it. >> I'm not a big fan of option 3, but I suppose it works. But imagine if you >> later find another idiosyncrasy that requires the driver to do some other >> thing differently? Do you make "hal_ppmc", and "hal_ppmc_old" and >> "hal_ppmc_not_so_old"? >> >> Better to have command line args with meaningful names like "change_dir=1" >> for the old behavior, and "change_dir=0" for the new behavior. The default >> should be the old behavior, and the manual page should say to try the >> alternate if the default doesn't work. > OK, I'll think about your parameter name, and unless I come > up with a better one, that will be it. > No, I don't want the default to be the old behavior, as that > has been PROVEN to break on at least a couple parport > chips. I am not, at present, able to find any parport chip > that fails with the new method. (Still digging in boxes for > some older PCI cards to try.) > > > Thanks much, John! > > Jon > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
