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
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
>
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.
> >
> > :-)
>
>
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
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
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?
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
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
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
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
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
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 kref
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 driver
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 private data
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/O. What
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 as
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 place?
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? Why do you
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
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 driver
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.
There still
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 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.
:-)
Coming to think
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
kernel he
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 represented in a
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
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
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
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
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
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
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
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
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
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
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
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 data used to
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
refcounting
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 lightning bolt from high
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 to
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 goes
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 to release
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
missing is
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 /sys/devices/.../attribute_file
The rmmod process would never actually read the attribute, so until it
exited the private data structure
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 closing the
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 device itself
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 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
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
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 kref *
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 following
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
58 matches
Mail list logo
