Re: [PARPORT] parport-arca-11 avaible

Andrea Arcangeli (
Sun, 27 Sep 1998 16:57:44 +0200 (CEST)

On Sun, 27 Sep 1998, Tim Waugh wrote:

>On Sun, 27 Sep 1998, Andrea Arcangeli wrote:
>> The LURK flag is still in and it will printk() a warning if used (it' s
>> still as Tim implemented it).
>KERN_WARNING "%s: lurking is deprecated so fix %s\n"
> ^^^^^^^^^^ that looks new.. ;-)

Yes ;-).

>Please Andrea, if you insist on keeping the warning there, at least change

If you think that I am _insisting_ you think that I am wrong.

>the printk level to KERN_DEBUG. Drivers that want to use the LURK flag
>don't do any harm to other drivers, or even to themselves.

Done thanks.

>> I still personally think that this is the
>> best choice. A printk will not harm at all pardevice developers and it
>> will not hurt performance or resources at all, but it will help to
>> _semantically_ put pardevice in sync with parport (and btw all pardevice
>> in the standard kernel are just uptodate).
>I agree that it's much nicer that all standard kernel drivers don't use

Ok, but do you agree to leave the warning there? Phil didn' t agreed but I
hope to have convinced it.

>> drivers/char/hfmodem/main.c | 12 ---
>Does the hfmodem really need exclusive access to the port? Also, was I

The hfmodem seems to have the same parport structure of the baycom
hamradio stuff. I CC'ed to the developer for a confirm.

>right in assuming that the Baycom hamradio drivers were what started all
>the exclusion stuff?


>> drivers/net/plip.c | 5 +
>Your change here changes "LURK" to "TRAN". I thought we were phasing out
>the distinction? I'd set it to 0 for "no special flags".

Hmm now I have understood. TRAN is the oppsite of LURK! Yes I can remove
all the TRAN reference and declare TRAN obsolete as LURK in parport.h.

>Also, I think ENODEV would be better than EBUSY if register_device fails.

That has not pratical differences. We only care to return a number != 0. I
could return -231231 and it would be fine and nobody would see -231231
from the outside. I think that -EBUSY would be better since it mean that
the parallel port is busy from a LURK device for example but OK I can
change it.

>> drivers/scsi/imm.c | 21 +++++-
>> drivers/scsi/ppa.c | 15 ++++
>What about when jiffies roll over to zero? (Very minor issue, but..)

It' s not a minor issue. I think many other places in the kernel would
have problems (more interesting that an insmod stall that now _should_
never happen anymore because there' s the EXCL thing). 64bit arch fix
this problem well though ;-).

I' ve produced a parport-arca-12 that should fix the problems reported by
Tim + the imm parbus_base[] thing and ppa braces minor issues.

Andrea[s] Arcangeli

-- To unsubscribe, send mail to: --
-- with the single word "unsubscribe" in the body of the message. --

This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:25 EST