RE: [hpoj-devel] A better way to print!

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Hi, Joe.  Thanks for your feedback on ptal-printd.

Joe Piolunek wrote:
> The daemon is indeed very easy to set up and use. It looks 
> like you're headed 
> in the right direction with this. Maybe it could become the 
> solution to many 
> of the problems we've been having. Are you planning to 
> eventually use it as a 
> printer control/communication device?
Offhand I can't think of other uses for this concept of using a named pipe
to simulate a character device, but if something comes up where it makes
sense then I'll consider using it.  At one point I had considered making all
of the peripheral's services (such as scan, PML, fax send, fax receive)
available this way, but I decided it was overkill, since that is what PTAL
is for.  Of course, the only reason ptal-printd was necessary in the first
place is that lpd and friends don't like to talk to anything other than a
file.

Another "problem" limiting the usefulness of this named pipe scheme is that
it doesn't permit bidirectional data flow.  Originally I was going to use a
Unix-domain socket (which also involves the creation of a special file), but
I discovered the hard way that clients can't just open() the file and start
write()ing data to it the way one can with a character device or named pipe.
In addition to sacrificing bidirectionality, use of named pipes means that
ptal-printd can't reliably detect job boundaries for back-to-back jobs for
purposes of wrapping each job with UELs (Esc%-12345X) the same way
ieee12844_print does.  This shouldn't be a problem as long as the filter is
configured to add its own end-of-job indicator (EscE), and ptal-printd
should notice when the string of jobs is over and send the UEL then.

That said, I do want to move more in the direction of user-mode daemons as
opposed to kernel-mode drivers to handle the background infrastructure of
all-in-one support.  In addition to the I/O driver, this could include
things like a gateway that forwards received faxes to e-mail, a daemon that
waits for and handles a color copy request from the front panel (since the
older OfficeJets can't do this standalone), and maybe something that keeps
the time in sync.  Of course, device control that requires user input would
still need to be handled by a foreground application, such as the fancy
xojpanel replacement we talked about a while back.

> You mentioned in the README that some security issues need to 
> be addressed. 
> If you can make it secure enough, then by all means add it to 
> the next 
> release.  
The main security issue I can think of is that there essentially is no
access control over which users get to write to the pipe, as opposed to
/dev/lpX, which on my system at least is readable and writeable by user root
and group daemon, and inaccessible by anyone else.  Of course, I wouldn't
say that the rest of hpoj is inherently secure, since anybody can access
whatever service they want to on the peripheral, so maybe this isn't such a
big deal after all.  There shouldn't be any danger in buffer overflows or
format string vulnerabilities, since all ptal-printd does is relay received
data in the same buffer.  So you'd probably be OK to start it at boot time,
or at least you wouldn't be any worse off than if you started it from the
command line.

> I printed several pages without trouble. The only problem 
> encountered so far 
> was the old one that occurs when xojpanel is running when a 
> second print job 
> is requested. Could ptal-printd eventually fix that, if for instance, 
> xojpanel (or a replacement control GUI) talks to the daemon 
> instead of the 
> printer directly?
No, that's a driver-level issue (ieee12844.c), which I plan to fix in the
future user-mode driver implementation I mentioned earlier.  I'm a little
afraid to make a lot of changes right now to the kernel drivers due to the
risk of breaking things in an environment (kernel mode) of which I have
dangerously little knowledge.  :-)  Of course, I did make a lot of changes
to the parallel port signalling in ieee12844pp.c, but I didn't really alter
the control flow and interaction with the kernel very much.

David