Hi,
thanks for the quick reaction on my report!
> >>> if (pb->irq == -1) {
> >> printk(KERN_INFO "plip: %s has no IRQ. Using IRQ-less
> >
> >The problem with using prio INFO is that many distributions are
> >configured to only report WARNING and higher priorities to the console,
> >so the warning will not appear when loading the driver. In addition to
> >that, the driver really needs an irq to function properly, so not getting
> >one is rather like an error situation for the driver.That, IMHO, makes
> >ERR or WARNING the appropriate priority.
>
> If you change it to be higher priority, people who genuinely intended to run it
> without an irq will get messages on the console that they don't really want.
> I think it would be better to leave it how it is. You can always use `dmesg'
> to see the messages after the fact, no matter what their priority was.
Well, seeing that plip.c produces WARNING messages in quite a few other
places (such as when reporting transmit / receive timeouts, which don't
really seem to do any harm [or do they?]), I thought WARNING would be
more appropriate than INFO. After all, you *are* warned that PLIP
will work inefficiently.
I understand you don't want to flood people with unwanted messages by
raising priorities. In this case, that does not really appear
problematic to me, as the message can only come once, when the module
is inserted. As I mentioned above, plip.c produces WARNING messages for
timeouts anyway, which are a lot more frequent (at least with my
cable), so I don't feel like one msg more when the module is
inserted really make a difference in that respect.
In summary, I still think WARNING is the right priority for the
'missing irq' message, both for practical and technical reasons (it
*is* a warning that PLIP will work inefficiently, after all).
Of course you are free to choose whatever you think right, just take
this as a suggestion and a feedback from a (otherwise happy) PLIP user.
Keep up the good work!
Greetings,
Sebastian
P.S. Again & again I read about the infamous "Parallel Transfer Mode 1"
described in linux/Documentation/networking/PLIP.txt. It's supposed to
be much faster than PLIP mode 0, but I couldn't find any info on it.
Is it implemented at all in the kernel, and if yes, how is it used?
I'd be grateful for any pointers to information.
It would probably also make sense to update PLIP.txt, if only to say
that Mode 1 has never been implemented (I'd be willing to update the
docs.)
*******
Please CC me on replies, as I am not subscribed to the parport mailing
list. Thank you.
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 02:19:16 EDT