On Wed, 12 Jul 2006 22:24:07 -0700
"Randy.Dunlap" <[email protected]> wrote:
> > > The class_dev is created like this, in video_register_device():
> > >
> > > memset(&vfd->class_dev, 0x00, sizeof(vfd->class_dev));
> > > if (vfd->dev)
> > > vfd->class_dev.dev = vfd->dev;
> > > vfd->class_dev.class = &video_class;
> > > vfd->class_dev.devt = MKDEV(VIDEO_MAJOR, vfd->minor);
> > > sprintf(vfd->class_dev.class_id, "%s%d", name_base, i - base);
> > > class_device_register(&vfd->class_dev);
> > > class_device_create_file(&vfd->class_dev,
> > > &class_device_attr_name);
> > >
> > > so it looks like class_device_register() is putting the 1 into the dentry?
> > > Culprit looks to be class_device_add() in that case.
> >
> > Perhaps we should check the return value of class_device_register() to
> > verify that nothing bad happened there? A dentry of 1 is very odd.
>
> Yes. We are in the process of adding such checks.
> Join the fun.
Chuck got about as far through this as I did. Yes, I'm suspecting an
earlier uncaught error of some form. The videodev changes since 2.6.17 are
small and look to be unrelated. I'd be suspecting preexisting videodev
bugs which have been exposed by sysfs/driver-model changes. But it's very
hard to tell.
Going through and adding 1000 missing check-error-then-recover instances is
the ideal approach, but I suspect that leaving callers as-is and blurting a
message from the driver core when some of these things fail might get us
what we need. But right now we have neither, and we see the result.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
