Andrea Arcangeli (firstname.lastname@example.org)
Fri, 25 Sep 1998 18:36:43 +0200 (CEST)
On Fri, 25 Sep 1998, David Campbell wrote:
>> I have a network adapter on
>> the first parport that will exactly to that: claim the port on open(),
>> release it on stop(). So you need to have to implement a counter that
>> makes you give up after some attempts or, even better, don't wait for
>> the bus to become idle at all but unregister the driver again and try
>> the next port.
>Urk! Sounds like this driver needs to be made a lurker. There is support for
If I remeber well a lurker device doesn' t make sense anymore. All
pardevice are put in the round robin waitlist without differences.
>> If a driver is required to allow "stealing" of its ressources, parport
>> is simply fundamentally broken. As long as the device is actually in use
>> by the driver, how should it release it's ressources? If it would, and
It _has_ to release its resources the first time it can if it' s passed
PARPORT_TIMESLICE seconds after it gained the port. The ppa case is a bit
different because it always claim and release the port because a scsi cmd
is pretty long so never check for PARPORT_TIMESLICE. The ppa case is
different also because ppa never run in normal kernel mode but it always
run in bh handlers. BTW, once I tried to remove the additional
claim/release but it make not sensible performance differences and
increased a lot the complexity of the driver.
>> another driver would try to initialise its native hardware on that port
>> (which will fail), it'll propably leave the attached device broken. Now,
>> what happens when the original driver comes back - bang.
I don' t understand very well but be quiet if there are no bugs everything
runs fine. Try to print while using the ZIP drive and you' ll see.
>> So,if the kernel stability actually demands on this,
>> I'd regard this as a fundamental design flaw.
If you use _one_ device per parellel port you won' t use at all the
parport scheduling facilities. If you use more than one pardevice on the
same parallel port you are agreeing with us.
-- To unsubscribe, send mail to: email@example.com --
-- 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:23 EST