On Mon, 2007-03-12 at 16:31 -0400, Dmitry Torokhov wrote:
> On 3/12/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> > On Mon, 12 Mar 2007, Oliver Neukum wrote:
> > > > > I don't like reverting my own code. But I predict he'll tell you
> > > > > that a
> > > > > driver's bond with a device should be r
On Mon, 12 Mar 2007, Dmitry Torokhov wrote:
> > Do you think Linus would listen if all three of us (plus maybe Greg) tried
> > to convince him?
> >
>
> If we'd accompany the argument with the patch that changes scsi to use
> wq to perform deletion so we don't have deadlock regression in the
> ker
On 3/12/07, Alan Stern <[EMAIL PROTECTED]> wrote:
On Mon, 12 Mar 2007, Oliver Neukum wrote:
> > > I don't like reverting my own code. But I predict he'll tell you that a
> > > driver's bond with a device should be represented in a data structure
> > > that is to be refcounted.
> >
> > :-)
>
> C
Am Montag, 12. März 2007 21:03 schrieb Alan Stern:
> On Mon, 12 Mar 2007, Oliver Neukum wrote:
>
> > > > I don't like reverting my own code. But I predict he'll tell you that a
> > > > driver's bond with a device should be represented in a data structure
> > > > that is to be refcounted.
> > >
>
On Mon, 12 Mar 2007, Oliver Neukum wrote:
> > > I don't like reverting my own code. But I predict he'll tell you that a
> > > driver's bond with a device should be represented in a data structure
> > > that is to be refcounted.
> >
> > :-)
>
> Coming to think about it, he might be right there.
Am Montag, 12. März 2007 20:31 schrieb Alan Stern:
> On Mon, 12 Mar 2007, Oliver Neukum wrote:
>
> > > I'm with Dmitry; the whole thing becomes much, much simpler if we put back
> > > your patch and prevent sysfs access after unregistering an attribute
> > > file. No API changes are needed, no d
On Mon, 12 Mar 2007, Oliver Neukum wrote:
> > I'm with Dmitry; the whole thing becomes much, much simpler if we put back
> > your patch and prevent sysfs access after unregistering an attribute
> > file. No API changes are needed, no driver changes are needed, no radical
> > core changes are ne
Am Montag, 12. März 2007 17:21 schrieb Alan Stern:
> On Mon, 12 Mar 2007, Oliver Neukum wrote:
>
> > > > Yes, I was missing the point. In consequence, drivers must not use
> > > > dev_get_drvdata() to get their references to their private data. It's
>
> You do realize how foolish that sounds? Wh
On Mon, 12 Mar 2007, Oliver Neukum wrote:
> > > Yes, I was missing the point. In consequence, drivers must not use
> > > dev_get_drvdata() to get their references to their private data. It's
You do realize how foolish that sounds? Why do you think
dev_get_drvdata() was written in the first plac
Am Montag, 12. März 2007 16:42 schrieb Dmitry Torokhov:
> On 3/12/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Am Montag, 12. März 2007 15:57 schrieb Alan Stern
> > > No, you're missing the point. Let's say driver A's disconnect() is
> > > called, so the driver marks its private data structure
On 3/12/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
Am Montag, 12. März 2007 15:57 schrieb Alan Stern:probably nece
> On Mon, 12 Mar 2007, Oliver Neukum wrote:
>
> > > > Why? What's wrong with simply calling kref_get/put?
> > >
> > > It's the same old problem: the race between unbind and sysfs I
Am Montag, 12. März 2007 15:57 schrieb Alan Stern:probably nece
> On Mon, 12 Mar 2007, Oliver Neukum wrote:
>
> > > > Why? What's wrong with simply calling kref_get/put?
> > >
> > > It's the same old problem: the race between unbind and sysfs I/O. What
> > > good does holding a reference to the
On Mon, 12 Mar 2007, Oliver Neukum wrote:
> > > Why? What's wrong with simply calling kref_get/put?
> >
> > It's the same old problem: the race between unbind and sysfs I/O. What
> > good does holding a reference to the private data structure do if the
> > show/store method gets called after the
Am Samstag, 10. März 2007 20:19 schrieb Alan Stern:
> On Fri, 9 Mar 2007, Oliver Neukum wrote:
>
> > Am Freitag, 9. März 2007 21:08 schrieb Alan Stern:
> > > After some more thought, I basically agree with what Oliver wrote
> > > originally. sysfs_dirent is indeed the logical place to store the k
On Fri, 9 Mar 2007, Oliver Neukum wrote:
> Am Freitag, 9. März 2007 21:08 schrieb Alan Stern:
> > After some more thought, I basically agree with what Oliver wrote
> > originally. sysfs_dirent is indeed the logical place to store the kref
> > pointer. However it needs to be used during open and
Am Freitag, 9. März 2007 21:08 schrieb Alan Stern:
> After some more thought, I basically agree with what Oliver wrote
> originally. sysfs_dirent is indeed the logical place to store the kref
> pointer. However it needs to be used during open and release, not during
OK.
> read, write, and poll.
Am Freitag, 9. März 2007 21:27 schrieb Alan Stern:
> On Fri, 9 Mar 2007, Oliver Neukum wrote:
>
> > > Adding a new release() callback would solve the problem by creating
> > > another. Drivers need to release their data as soon as possible after
> > > they unbind from a device, not when the devi
On Fri, 9 Mar 2007, Oliver Neukum wrote:
> > Adding a new release() callback would solve the problem by creating
> > another. Drivers need to release their data as soon as possible after
> > they unbind from a device, not when the device itself goes away. Think
>
> Wait, the callback from clos
On Fri, 9 Mar 2007, Alan Stern wrote:
> Oliver, your idea won't work either. Think about what would happen if
> someone did
>
> rmmod driver_module
> The rmmod process would never actually read the attribute, so until it
> exited the private data structure would have a positive refcoun
Am Freitag, 9. März 2007 20:32 schrieb Alan Stern:
> On Fri, 9 Mar 2007, Dmitry Torokhov wrote:
>
> > On 3/9/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > > Am Freitag, 9. März 2007 18:02 schrieb Dmitry Torokhov:
> > >
> > > > I think we already have all refcounting that is needed. What is
> >
On Fri, 9 Mar 2007, Dmitry Torokhov wrote:
> On 3/9/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > Am Freitag, 9. März 2007 18:02 schrieb Dmitry Torokhov:
> >
> > > I think we already have all refcounting that is needed. What is
> > > missing is subsystem-provided ->release() hooks for drivers t
On 3/9/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
Am Freitag, 9. März 2007 18:02 schrieb Dmitry Torokhov:
> I think we already have all refcounting that is needed. What is
> missing is subsystem-provided ->release() hooks for drivers to release
> driver-specific resources when a device finally
Am Freitag, 9. März 2007 18:02 schrieb Dmitry Torokhov:
> I think we already have all refcounting that is needed. What is
> missing is subsystem-provided ->release() hooks for drivers to release
> driver-specific resources when a device finally goes away.
This is an interesting idea. Is it nice t
On 3/9/07, Oliver Neukum <[EMAIL PROTECTED]> wrote:
Am Freitag, 9. März 2007 17:32 schrieb Alan Stern:
> On Fri, 9 Mar 2007, Oliver Neukum wrote:
>
> > Am Donnerstag, 8. März 2007 17:02 schrieb Alan Stern:
> > > On Thu, 8 Mar 2007, Oliver Neukum wrote:
> > >
> > > > Hi,
> > > >
> > > > after a li
Am Freitag, 9. März 2007 17:32 schrieb Alan Stern:
> On Fri, 9 Mar 2007, Oliver Neukum wrote:
>
> > Am Donnerstag, 8. März 2007 17:02 schrieb Alan Stern:
> > > On Thu, 8 Mar 2007, Oliver Neukum wrote:
> > >
> > > > Hi,
> > > >
> > > > after a lightning bolt from high above I've been looking into
On Fri, 9 Mar 2007, Oliver Neukum wrote:
> Am Donnerstag, 8. März 2007 17:02 schrieb Alan Stern:
> > On Thu, 8 Mar 2007, Oliver Neukum wrote:
> >
> > > Hi,
> > >
> > > after a lightning bolt from high above I've been looking into refcounting
> > > the data structures drivers use to provide the d
Am Donnerstag, 8. März 2007 17:02 schrieb Alan Stern:
> On Thu, 8 Mar 2007, Oliver Neukum wrote:
>
> > Hi,
> >
> > after a lightning bolt from high above I've been looking into refcounting
> > the data structures drivers use to provide the data used to refill sysfs
> > buffers. I've come to the f
On Thu, 8 Mar 2007, Oliver Neukum wrote:
> Hi,
>
> after a lightning bolt from high above I've been looking into refcounting
> the data structures drivers use to provide the data used to refill sysfs
> buffers. I've come to the following conclusion.
>
> 1. struct sysfs_buffer must have a struct
Hi,
after a lightning bolt from high above I've been looking into refcounting
the data structures drivers use to provide the data used to refill sysfs
buffers. I've come to the following conclusion.
1. struct sysfs_buffer must have a struct kref * and probably a destructor
pointer
2. drivers must
29 matches
Mail list logo
