On Wed, 11 Jul 2007, Tejun Heo wrote:
> Alright, there's our confusion. I thought you were gonna use dev->sem
> to protect new device addition && driver binding. We can use the same
> rwsem directly for binding protection too but I guess there's no big
> difference one way or the other.
The rws
On Wed, 11 Jul 2007 14:04:44 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Thanks for enlightening me. Probably what can be done is blocking
> regular file sysfs nodes automatically and make it optional (optionally
> enable or disable) for bin attrs.
Perhaps all files should block by default, bu
Alan Stern wrote:
>> Please also note that currently dev->sem does not protect against adding
>> children. It says it does in the comment on the definition of the field
>> but it's never acquired during device_add().
>
> That's why we need the rwsem.
Alright, there's our confusion. I thought yo
On Wed, 11 Jul 2007, Tejun Heo wrote:
> >> How high performance device addition/removal should be? Wouldn't rwlock
> >> be enough?
> >
> > rwlock is a type of spinlock, right? Hence it can't sleep and can't be
> > used for device addition/removal. Also rwlocks aren't fair and are
> > subject t
Hello,
Alan Stern wrote:
>> When a bus device is being woken up and rescanning the bus, all
>> prerequisites for the bus should have been resumed already. As long as
>> the newly added device is placed after the bus device itself, things
>> should be safe. Well, that's the theory at least.
>
>
On Wed, 11 Jul 2007, Tejun Heo wrote:
> > Addition during resume is _not_ safe. The new device can easily get
> > added to the already-processed list in the wrong position, so that the
> > next time the system is suspended the PM core tries to suspend the new
> > device's parent before suspending
Hello,
Alan Stern wrote:
> Instead we should broadcast a notification to all threads which might
> try to add a device, telling them not to do it until the suspend is
> over. After that notification is sent and current additions have
> completed, the driver core can simply fail further calls to
>
On Tue, 10 Jul 2007, Tejun Heo wrote:
> >>> A general immediate disconnect of the buffers (which will be handled in
> >>> a second pass) would be great, but doesn't sound easy.
> >> I haven't thought too hard about actual implementation but it's pretty
> >> specific case. If doing things in gener
On Tue, 10 Jul 2007, Tejun Heo wrote:
> > Well, it turns out that this approach may confict with suspend/resume
> > processing. In brief, it's not a good idea to unregister devices while
> > a suspend is in progress, but on the other hand it's not a good idea to
> > block keventd waiting until th
On Tue, 10 Jul 2007 18:13:43 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> More like "device unregistering itself from its attribute" vs. "whatever
> else".
Ah, ok. I don't think we can make those the same, but "trigger an
action and return" vs. "whatever else" may be possible.
>
> >>> A genera
Cornelia Huck wrote:
> On Tue, 10 Jul 2007 17:49:37 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> What I was trying to say was that suicide and murder could be done the
>> same way from the driver's POV or am I misunderstanding?
>
> Do you mean a device unregistering itself from its attribut
On Tue, 10 Jul 2007 17:49:37 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> What I was trying to say was that suicide and murder could be done the
> same way from the driver's POV or am I misunderstanding?
Do you mean a device unregistering itself from its attribute vs. a
device unregistering anot
Cornelia Huck wrote:
>> I like it because it shifts complexity from the drivers into driver
>> core. IOW, the driver model is kinder to drivers that way - the driver
>> writer doesn't have to care whether something is suicidal or not - and I
>> think that's the way we should be headed although we'
On Tue, 10 Jul 2007 14:09:41 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> > I haven't paid much attention to your sysfs updates. Is it still true
> > that calls to show/store methods are mutually exclusive with attribute
> > unregistration? Assuming the answer is Yes, would it be possible to
>
Hello, Alan.
Alan Stern wrote:
> You remember the problem we faced with "suicidal" sysfs attributes and
> the device_schedule_callback() routine that fixes it?
Sure.
> Well, it turns out that this approach may confict with suspend/resume
> processing. In brief, it's not a good idea to unregist
On Mon, 9 Jul 2007, Cornelia Huck wrote:
> On Sun, 8 Jul 2007 10:31:21 -0400 (EDT),
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > There are some ways around this such as using a different workqueue,
> > one that could safely be blocked during the suspend.
>
> This would be the simplest solution
On Sun, 8 Jul 2007 10:31:21 -0400 (EDT),
Alan Stern <[EMAIL PROTECTED]> wrote:
> There are some ways around this such as using a different workqueue,
> one that could safely be blocked during the suspend.
This would be the simplest solution, I think.
> The user writes to an attribute file
17 matches
Mail list logo
