On Fri, 21 Oct 2005 21:12:28 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> Replacing a spinlock with an rwlock -- did it really happen that way? I
> got the impression that the rwlock was there all along, and then was taken
> out of notifier_call_chain because some people wanted their entr
On Fri, 21 Oct 2005, Greg KH wrote:
> > Is this worth pursuing?
>
> I think so, it looks good. But why not use the list walk macros we have
> availble instead of following the links on your own?
Because I tried to make minimal changes to the existing code and data
structures, which use a singly
On Fri, 21 Oct 2005 16:46:40 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> > If you go for it, prepare for talking to netdev@, and they will ask
> > about taking and dropping the spinlock at every iteration when
> > traversing. They are very sensitive to performance.
>
> Are they really doing notif
On Fri, Oct 21, 2005 at 04:41:49PM -0700, Pete Zaitcev wrote:
> On Fri, 21 Oct 2005 16:59:21 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]>
> wrote:
>
> > I haven't tested this, although kernel/sys.c source file compiles okay.
> > A complete patch would have to adjust the definitions of all 22 exist
On Fri, 21 Oct 2005 16:59:21 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> I haven't tested this, although kernel/sys.c source file compiles okay.
> A complete patch would have to adjust the definitions of all 22 existing
> notifier chains.
>
> Is this worth pursuing?
I think it is, but
On Fri, Oct 21, 2005 at 04:59:21PM -0400, Alan Stern wrote:
> Guys:
>
> Here's an example patch showing how the existing notifier chain code can
> be reimplemented in a safe manner (and how the code's appearance can be
> improved!).
>
> I haven't tested this, although kernel/sys.c source file c
Guys:
Here's an example patch showing how the existing notifier chain code can
be reimplemented in a safe manner (and how the code's appearance can be
improved!).
I haven't tested this, although kernel/sys.c source file compiles okay. A
complete patch would have to adjust the definitions of a
On Wed, 19 Oct 2005 11:48:57 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> > Also, do you see that rwlock which IS TAKEN FOR WRITE ONLY?
> > Why? The only explanation is: the author intended read locks
> > in notifier_call_chain, but either forgot them, or they were
> > dropped by other person.
> I
On Fri, Oct 21, 2005 at 08:39:09AM -0700, Pete Zaitcev wrote:
> On Wed, 19 Oct 2005 11:48:57 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > Also, do you see that rwlock which IS TAKEN FOR WRITE ONLY?
> > > Why? The only explanation is: the author intended read locks
> > > in notifier_call_chain
On Mer, 2005-10-19 at 14:21 -0700, gary clark wrote:
> The reasons why I want to do this without breaking a
> confidentiality agreement is to not let the user know
> that I have disabled/enabled the USB devices.
> I dont want it in user space, simply because he can
> kill the app with ease...in ker
On Wed, Oct 19, 2005 at 02:21:45PM -0700, gary clark wrote:
> The reasons why I want to do this without breaking a
> confidentiality agreement is to not let the user know
> that I have disabled/enabled the USB devices.
> I dont want it in user space, simply because he can
> kill the app with ease..
The reasons why I want to do this without breaking a
confidentiality agreement is to not let the user know
that I have disabled/enabled the USB devices.
I dont want it in user space, simply because he can
kill the app with ease...in kernel space well thats a
bit more tricky.
Ok basically as I said
On Wed, 19 Oct 2005, Greg KH wrote:
> On Wed, Oct 19, 2005 at 01:24:58PM -0700, gary clark wrote:
> > I am new to this evolving linux USB list. Hence please
> > excuse my lack of understanding of the current state
> > of design.
> >
> > What I want to achieve is to have the ability to
> > enable/d
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I includ
: Pete Zaitcev <[EMAIL PROTECTED]>
Cc: linux-usb-devel@lists.sourceforge.net
Subject: [linux-usb-devel] Re: [PATCH 01/04] USB: add
notifier
functions to the USB core for devices and busses
---
This SF.Net email is sponsored by:
Power Architect
On Tue, Oct 18, 2005 at 09:55:32PM -0700, Pete Zaitcev wrote:
> On Tue, 18 Oct 2005 21:11:45 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > Woops, I assumed that notifier_call_chain had one inside. It was
> > > inconceivable to me that you would neglect to lock the chain.
> > >
> > > Very well
On Tue, 18 Oct 2005 21:11:45 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> It looks like it's safe to walk the list and add a new notifier at the
> same time. Take a look at kernel/sys.c::notifier_chain_register() to
> see if I missed something.
By the way, to follow-up, look at this:
http://www.u
On Tue, 18 Oct 2005 21:11:45 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> > Woops, I assumed that notifier_call_chain had one inside. It was
> > inconceivable to me that you would neglect to lock the chain.
> >
> > Very well, what does prevent a module to call usb_register_notify
> > (on a context
On Tue, Oct 18, 2005 at 08:45:12PM -0700, Pete Zaitcev wrote:
> On Tue, 18 Oct 2005 20:28:48 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > > Any objections to me adding this?
> > >
> > > No objections. You do add a lock which wasn't there before, but it
> > > seems that usbmon at least is not
On Tue, 18 Oct 2005 20:28:48 -0700, Greg KH <[EMAIL PROTECTED]> wrote:
> > > Any objections to me adding this?
> >
> > No objections. You do add a lock which wasn't there before, but it
> > seems that usbmon at least is not affected. It does not call much
> > from initialization and tear-down fun
20 matches
Mail list logo
