Andrea Arcangeli (andrea@e-mind.com)
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
>LURK.
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?
Yes.
>> 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.
ftp://e-mind.com/pub/linux/parport/parport-arca-2.1.122-12.diff.gz
Andrea[s] Arcangeli
-- 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 2.0b3 on Wed 30 Dec 1998 - 10:18:25 EST