> On Tue 10 June 2003 23:12, Randy.Dunlap wrote: >> >> Hi Daniele, > > Hi Randy, nice to see you (even if nice to hear you would be more > appropriate ;) ) > >> Were you able to test this new code path? If so, how? > > Well, that's a good question ... > because i don't know if there is any distro program that play with > LP_ABORTOPEN i've just tried with a simple user code that set/clear > LP_ABORTOPEN through a ioctl syscall. Apparently it works fine.
Hi-- I'm trying to use 'tunelp' to test it. The latest version that I can find source code for is 1.3, but it doesn't play nicely with usblp. I've had to modify it slightly to work with usblp. (Patch to tunelp-1.3 is attached.) > Because you are at it i wish to say that, in my opinion, adding an entry to > sysctl tables would be more appropriate than playing with ioctl. > For example, a user/sysadm could set automaticaly LP_ABORTOPEN in any init > script to avoid to code a program that just set/clear it. Be aware that this > will break compatibility with parallel printer device drivers where such > sysctl entry doesn't exist. That does make sense, yes. Or they could use tunelp, except that it has binary ioctl interface problems. Ugh. >> More comments after I try to test it... I'm still trying to see if this patch is useful. Thanks, ~Randy
tunelp-1.3-usblp.diff
Description: Binary data