On Mon, 1 Jul 2002 23:45:34 -0700
"Greg KH" <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 28, 2002 at 04:47:57PM +0200, Soewono Effendi wrote:
> >
> > And I think there must be some locking to protect
> > if (driver->owner)
> > __MOD_INC_USE_COUNT(driver->owner);
> > and
> >
> > The goal is just to minimize the kernel locking time as much as
> > possible, with the cost of size, I admit that.
>
> Why do you think that the BKL or any lock is needed around the test and
> set functions?
>
> I agree module unloading is extreemly racy, but take a look at the
> current thre
On Fri, Jun 28, 2002 at 04:47:57PM +0200, Soewono Effendi wrote:
>
> And I think there must be some locking to protect
> if (driver->owner)
> __MOD_INC_USE_COUNT(driver->owner);
> and
> if (driver->owner)
> __MOD_DEC_USE_COUNT(driver->owner);
>
> may be:
>
On Thu, Jun 27, 2002 at 09:21:02PM +0200, Oliver Neukum wrote:
>
> PS: Is it true that the IBM guys have a keyboard they make
> a notch into whenever they reduce BKL usage ?
Heh, yes, I think there is something like that in the main BKL
squasher's cubical. I know I enjoy bugging him about it by
About the BKL stuffs...
As I can see on linux-2.5.22 no BKL is needed.
The idea is just to use __MOD_INC_USE_COUNT and __MOD_DEC_USE_COUNT, though I have the
feeling that there should be at least a minimum locking mechanism to guide safe
"driver->owner".
Is this idea also applicable on 2.4 or
Am Donnerstag, 27. Juni 2002 23:41 schrieb David Brownell:
> Oliver Neukum wrote:
> > Am Donnerstag, 27. Juni 2002 21:33 schrieben Sie:
> >>OK, I'll let you fix that BKL stuff (didn't you add it
> >>in the first place? :) but this looks like the locking
> >
> > I did not add it. It was there for a
OK, I'll let you fix that BKL stuff (didn't you add it
in the first place? :) but this looks like the locking
is being done at the wrong level:
> @@ -1349,7 +1351,9 @@
> usbfs_add_device(dev);
>
> /* find drivers willing to handle this device */
> + lock_kernel(); /* guard agai
Am Donnerstag, 27. Juni 2002 20:24 schrieb David Brownell:
> >>>Hotpluggings are rare events ... Besides they take BKL and thus
> >>>couldn't run in concurrency.
> >>
> >>What was the reason they have BKL? In principle it shouldn't
> >>be needed, since all the relevant USB data structures are lo
>>>Hotpluggings are rare events ... Besides they take BKL and thus
>>>couldn't run in concurrency.
>>
>>What was the reason they have BKL? In principle it shouldn't
>>be needed, since all the relevant USB data structures are locked
>>correctly, and there's no comment in the code explaining why
>
Am Donnerstag, 27. Juni 2002 18:20 schrieb David Brownell:
> Oliver Neukum wrote:
> >>after looking around in source codes and searching in mailing list and
> >>G*gle, I still couldn't find any hints why there exists only one
> >> "khubd" in USB Stack.
> >
> > Hotpluggings are rare events ... Bes
On Thu, 27 Jun 2002 09:15:25 -0700
"David Brownell" <[EMAIL PROTECTED]> wrote:
> Periodic urbs get some special treatment, "automagic resubmission" where urbs
> don't get handed back to drivers in most completion callbacks. Ownership
> of the URB there is in a strange "shared between drivers" st
Oliver Neukum wrote:
>>after looking around in source codes and searching in mailing list and
>>G*gle, I still couldn't find any hints why there exists only one "khubd"
>>in USB Stack.
>
> Hotpluggings are rare events ... Besides they take BKL and thus
> couldn't run in concurrency.
What was t
> Well, actually I wanted to know how exactly URB flows through the Linux USB Stack,
>e.g.
> driver allocates URB, submitted to USB Core, goes to HCD, something done there,
> returned to to driver by callback function, etc.
> And how does it apply for all the different transfer modes.
That's th
On Thu, 27 Jun 2002 10:38:37 -0400
"Johannes Erdfelt" <[EMAIL PROTECTED]> wrote:
> Simplicity. [snip]
I see.
>
> > Is there any informations about "URB lifetime" ? who allocates and deallocates it,
> > when one should/shouldn't remove it, etc.
>
> The driver allocates and deallocates the URB
Am Donnerstag, 27. Juni 2002 14:49 schrieb Soewono Effendi:
> Hello there,
>
> after looking around in source codes and searching in mailing list and
> G*gle, I still couldn't find any hints why there exists only one "khubd"
> in USB Stack. Isn't it "better (performance?)" to have one "khubd" for
On Thu, Jun 27, 2002, Soewono Effendi <[EMAIL PROTECTED]> wrote:
> after looking around in source codes and searching in mailing list and G*gle,
> I still couldn't find any hints why there exists only one "khubd" in USB Stack.
> Isn't it "better (performance?)" to have one "khubd" for each HC? (t
Hello there,
after looking around in source codes and searching in mailing list and G*gle,
I still couldn't find any hints why there exists only one "khubd" in USB Stack.
Isn't it "better (performance?)" to have one "khubd" for each HC? (thinking of multi
processor platform)
What was the design
17 matches
Mail list logo
