On Tue, 28 Nov 2006, Oliver Neukum wrote:
> Documented core VFS code? The notion is indecent verging on blasphemous ;-)
I can just see the flamewars starting up: "There's no kerneldoc for VFS,
so why do we have to write documentation for USB?" :-)
> > This looks reasonable, subject to the quest
On Tue, Nov 28, 2006 at 06:51:12AM +0100, Oliver Neukum wrote:
> Am Dienstag, 28. November 2006 04:38 schrieb Alan Stern:
> > On Mon, 27 Nov 2006, Oliver Neukum wrote:
> >
> > > OK, let's make some basic observation. Sysfs exists in memory only,
> > > as long as the dentry exists the inode cannot
Am Dienstag, 28. November 2006 04:38 schrieb Alan Stern:
> On Mon, 27 Nov 2006, Oliver Neukum wrote:
>
> > OK, let's make some basic observation. Sysfs exists in memory only,
> > as long as the dentry exists the inode cannot be freed.
>
> How do you know that?
>
> For that matter, is there any w
On Mon, 27 Nov 2006, Oliver Neukum wrote:
> OK, let's make some basic observation. Sysfs exists in memory only,
> as long as the dentry exists the inode cannot be freed.
How do you know that?
For that matter, is there any written explanation at all of how the
dentry and inode lifecycles work?
Am Montag, 27. November 2006 23:08 schrieb Alan Stern:
> On Mon, 27 Nov 2006, Oliver Neukum wrote:
> > IMHO by a previous dropping all dentries, you make sure the usage count of
> > an inode will monotonically decrease.
>
> Sure. However suppose there used to be open file references and they hav
On Mon, 27 Nov 2006, Oliver Neukum wrote:
> > In sysfs_remove_file(), kobj->dentry is the dentry for the device, not for
>
> Therefore I got no ENODEV!
Exactly.
> > the attribute. The place where you need to call orphan_all_buffers() is
> > in inode.c:sysfs_drop_dentry(). I'm not sure exactly
Am Montag, 27. November 2006 21:43 schrieb Alan Stern:
> On Mon, 27 Nov 2006, Oliver Neukum wrote:
>
> > Am Montag, 27. November 2006 20:45 schrieb Alan Stern:
> > > I like it, except for one little detail. You don't need buffer->anchor;
> > > it gets used only in remove_from_collection(), which
On Mon, 27 Nov 2006, Oliver Neukum wrote:
> Am Montag, 27. November 2006 20:45 schrieb Alan Stern:
> > I like it, except for one little detail. You don't need buffer->anchor;
> > it gets used only in remove_from_collection(), which is called only from
> > sysfs_release(), so you can pass the in
Am Montag, 27. November 2006 20:45 schrieb Alan Stern:
> I like it, except for one little detail. You don't need buffer->anchor;
> it gets used only in remove_from_collection(), which is called only from
> sysfs_release(), so you can pass the inode directly as an argument.
Right.
Regar
On Mon, 27 Nov 2006, Oliver Neukum wrote:
> Am Montag, 27. November 2006 04:00 schrieb Alan Stern:
> > > > Fourth, you might consider deallocating the sysfs_buffer_collection as
> > > > soon as the last buffer is removed from its list. I don't know if this
> > > > really matters...
> > >
> > > T
Am Montag, 27. November 2006 04:00 schrieb Alan Stern:
> > > Fourth, you might consider deallocating the sysfs_buffer_collection as
> > > soon as the last buffer is removed from its list. I don't know if this
> > > really matters...
> >
> > That would mean having to use the inode's lock.
>
> As
Am Montag, 27. November 2006 04:00 schrieb Alan Stern:
> On Sun, 26 Nov 2006, Oliver Neukum wrote:
>
> > > Second, instead of putting a lock in the buffer_collection you could just
> > > use the inode's lock.
> >
> > That's a layering violation.
>
> Your patch already uses inode->i_mutex. Does
On Sun, 26 Nov 2006, Oliver Neukum wrote:
> > Second, instead of putting a lock in the buffer_collection you could just
> > use the inode's lock.
>
> That's a layering violation.
Your patch already uses inode->i_mutex. Does that mean it already
contains a layering violation?
> Plus that lock
Am Sonntag, 26. November 2006 20:01 schrieb Alan Stern:
> On Sun, 26 Nov 2006, Oliver Neukum wrote:
>
> > > Go ahead and try to write it. You may find it's a little tricky to create
> > > the sysfs_buffer_collection in the first place (and to delete it at the
> > > end). It may also be hard to a
On Sun, 26 Nov 2006, Oliver Neukum wrote:
> > Go ahead and try to write it. You may find it's a little tricky to create
> > the sysfs_buffer_collection in the first place (and to delete it at the
> > end). It may also be hard to acquire the locks for the dentry, the
> > buffer, and the buffer_co
Am Samstag, 25. November 2006 23:20 schrieb Alan Stern:
> On Sat, 25 Nov 2006, Oliver Neukum wrote:
>
> > OK. How about:
> >
> > struct sysfs_buffer_collection {
> > struct list_headassociated_buffers;
> > struct mutexlock;
> > };
> >
> > struct sysfs_buffer {
On Sat, 25 Nov 2006, Oliver Neukum wrote:
> OK. How about:
>
> struct sysfs_buffer_collection {
> struct list_headassociated_buffers;
> struct mutexlock;
> };
>
> struct sysfs_buffer {
> size_t count;
> loff_t
Am Samstag, 25. November 2006 17:23 schrieb Alan Stern:
> On Sat, 25 Nov 2006, Oliver Neukum wrote:
>
> > > > OK, a bit more elaborate.
> > > >
> > > > 1. add a list to struct attribute
> > > > 2. add any struct sysfs_buffer opened to that list
> > > > 3. in class_device_remove_file walk this lis
On Sat, 25 Nov 2006, Oliver Neukum wrote:
> > > OK, a bit more elaborate.
> > >
> > > 1. add a list to struct attribute
> > > 2. add any struct sysfs_buffer opened to that list
> > > 3. in class_device_remove_file walk this list and mark all buffers on a
> > > list orphaned
> > > 4. in fill_read
Am Samstag, 25. November 2006 03:54 schrieb Alan Stern:
> On Sat, 25 Nov 2006, Oliver Neukum wrote:
>
> > > > > By the way, you should be aware that creating an attribute file in
> > > > > the
> > > > > interface's device directory (like dev_attr_speed above) is
> > > > > inherently
> > > > >
On Sat, 25 Nov 2006, Oliver Neukum wrote:
> > > > By the way, you should be aware that creating an attribute file in the
> > > > interface's device directory (like dev_attr_speed above) is inherently
> > > > unsafe. A user process can open the file, hold it open while the
> > > > driver
> > >
Am Freitag, 24. November 2006 21:55 schrieb Alan Stern:
> On Fri, 24 Nov 2006, Oliver Neukum wrote:
>
> > > By the way, you should be aware that creating an attribute file in the
> > > interface's device directory (like dev_attr_speed above) is inherently
> > > unsafe. A user process can open t
On Fri, 24 Nov 2006, Oliver Neukum wrote:
> > By the way, you should be aware that creating an attribute file in the
> > interface's device directory (like dev_attr_speed above) is inherently
> > unsafe. A user process can open the file, hold it open while the driver
> > is unloaded, and then
Am Freitag, 24. November 2006 18:44 schrieb Alan Stern:
> On Fri, 24 Nov 2006, Oliver Neukum wrote:
>
> > --- drivers/usb/misc/trancevibrator.c~ 2006-11-16 05:03:40.0
> > +0100
> > +++ drivers/usb/misc/trancevibrator.c 2006-11-24 12:30:29.0
> > +0100
> > @@ -120,8 +120
On Fri, 24 Nov 2006, Oliver Neukum wrote:
> --- drivers/usb/misc/trancevibrator.c~2006-11-16 05:03:40.0
> +0100
> +++ drivers/usb/misc/trancevibrator.c 2006-11-24 12:30:29.0 +0100
> @@ -120,8 +120,8 @@
> struct trancevibrator *dev;
>
> dev = usb_get_intfdata
25 matches
Mail list logo
