On Tue, 6 Apr 2004, James Bottomley wrote:
> On Tue, 2004-04-06 at 01:52, Oliver Neukum wrote:
> > Pure refcounting can never protect you against races with freeing objects.
> > The counters themselves must be protected. Try as you might you need
> > locks for that and rules on how this locks are
On Tue, 2004-04-06 at 11:55, Alan Stern wrote:
> In principle, yes. However... The kernel still has to process requests
> correctly while the stack is partially deconstructed. It also has to
> protect against userland helpers trying to pull things apart in the wrong
> order.
This I agree wit
On 6 Apr 2004, James Bottomley wrote:
> Supposing we did no hotplug at all and just relied on the fact that a
> driver responds DID_NO_CONNECT to a missing device.
>
> We have a mounted fs on a CD on SCSI on USB which gets disconnected. No
> event is generated because no hotplug. Now every read o
James Bottomley wrote:
that's intra subsystem synchronisation, not inter subsystem
I'd say that device_driver.remove() calls from the bus management
code to a given device driver are inter-subsystem...
so using a subsystem provided API from another subsystem constitutes
inter subsytem synchronisati
On Tue, 2004-04-06 at 10:10, David Brownell wrote:
> James Bottomley wrote:
> > that's intra subsystem synchronisation, not inter subsystem
>
> I'd say that device_driver.remove() calls from the bus management
> code to a given device driver are inter-subsystem...
so using a subsystem provided A
James Bottomley wrote:
that's intra subsystem synchronisation, not inter subsystem
I'd say that device_driver.remove() calls from the bus management
code to a given device driver are inter-subsystem...
Look, the rules are very simple:
- Every subsystem gives out refcounted objects.
- Every subs
On Tue, 2004-04-06 at 01:52, Oliver Neukum wrote:
> Pure refcounting can never protect you against races with freeing objects.
> The counters themselves must be protected. Try as you might you need
> locks for that and rules on how this locks are to be used.
Which part of
On Mon, 2004-04-05 at 20
> The point is that all the disconnection event does is inform a subsystem
> that the entity represented by the other object has gone. What it
> chooses to do with the information is up to it. It could set it's own
> connected object to degraded, never use the other object again and drop
> the r
On Mon, 2004-04-05 at 18:23, David Brownell wrote:
> "Irrelevant" is pointlessly strong, even for what I'm guessing
> you really mean to be saying.
No, it's the very point.
If we have to enforce ordering on the event propagation across
subsystems, that can't be done without inter subsystem synchr
James Bottomley wrote:
On Sun, 2004-04-04 at 22:54, David Brownell wrote:
Which directly follows from what I said ... USB propagates
that knowledge in carefully defined ways. Other layers can
do the same, although clearly state associated with open file
descriptors needs to use a slightly differ
On Sun, 2004-04-04 at 22:54, David Brownell wrote:
> Which directly follows from what I said ... USB propagates
> that knowledge in carefully defined ways. Other layers can
> do the same, although clearly state associated with open file
> descriptors needs to use a slightly different strategy. A
> > Open process: Disconnect process:
> >
> > Get minor number from inode
> > Lookup USB interface using
> > minor number
> > Get device pointer from the
> > interface's private data
> > and check it's not NULL
>
> This is what's wrong. Here you
James Bottomley wrote:
So you dispute this assertion in the email you quoted above:
Since we cannot solve that
race, there's no reason to try to solve the "some parts of the kernel
know but others don't" part of the race.
On what basis? This, I think, is the core of the differences between
On t
On Sun, 2004-04-04 at 14:16, David Brownell wrote:
> You're assuming that synchronization is there to establish a single
> global notion of state. Clearly that's impossible; also undesirable.
Thank you.
> The synchronization is actually there to let the "device gone" state
> spread cleanly throu
James Bottomley wrote:
Let me illustrate: the user may disconnect the device then open it. If
they open it before even the USB subsystem gets notified of the
disconnection then all the elaborate synchronisation in the world isn't
going to be able to prevent that (the device was gone when they open
15 matches
Mail list logo
