> 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


Attachment: tunelp-1.3-usblp.diff
Description: Binary data

Reply via email to