From: Greg KH <greg@kroah.com>
To: Gerd Knorr <kraxel@bytesex.org>
Cc: Kernel List <linux-kernel@vger.kernel.org>,
video4linux list <video4linux-list@redhat.com>
Subject: Re: [RFC/PATCH] sysfs'ify video4linux
Date: Wed, 16 Jul 2003 14:08:00 -0700 [thread overview]
Message-ID: <20030716210800.GE2279@kroah.com> (raw)
In-Reply-To: <20030716202018.GC26510@bytesex.org>
On Wed, Jul 16, 2003 at 10:20:18PM +0200, Gerd Knorr wrote:
> > It looks like the video drivers include a "struct video_device"
> > structure within their own structures, right?
>
> Yes, it is allocated/freed by the driver, most seem to simply include
> one ore more "struct video_device" somewhere in the per-device struct.
So you CAN NOT just blindly put a kobject (meaning a class_device)
structure inside of there.
> > That will have to be changed to a pointer to that structure in order
> > for the lifetime rules to work properly.
>
> Hmm. I doubt it will be that simple. struct video_device has a priv
> field which can be used by the drivers to hook in some driver-private
> data. That may point into nowhere if struct video_device has a longer
> live time due to some kobject still being referenced. Wouldn't be a
> issue for videodev.o itself, but might become a problem for drivers
> which want add private properties and rely on video_device->priv
> for finding the per-device data. Problem isn't solved but justed
> moved to the next corner ...
No, just have the video drivers have a release callback to do the
freeing. It's pretty simple, look at usb_host_release() in
drivers/usb/core/hcd.c. That's exactly what that is for. Hm, I
shouldn't have to check for bus->release() there, as release is now
required...
> Maybe let video_unregister sleep on a semaphore which gets woken up
> by the release function? That should make sure the sysfs objects are
> not referenced any more if video_unregister() returns. I use a similar
> method in some places when shutting down kernel threads, to make sure it
> is really stopped before rmmod frees the memory.
Ick, no. Try doing what I did for usb hosts, it's much simpler.
> > Look at the dev file in /sys/class/tty/*, or in /sys/block/hd* or in
> > /sys/class/usb/*, and so on...
>
> I've found the code in drivers/block/genhd.c in the meantime :)
genhd.c uses "raw" kobjects. It might be easier to look at a
class_device example like the above mentioned usb_host one.
If you have any other questions/problems, feel free to ask.
thanks,
greg k-h
next prev parent reply other threads:[~2003-07-16 20:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-15 14:31 [RFC/PATCH] sysfs'ify video4linux Gerd Knorr
2003-07-15 15:21 ` Ronald Bultje
2003-07-15 16:19 ` Matt Porter
2003-07-15 21:27 ` Greg KH
2003-07-16 8:44 ` Gerd Knorr
2003-07-16 16:19 ` Greg KH
2003-07-16 20:20 ` Gerd Knorr
2003-07-16 21:08 ` Greg KH [this message]
2003-07-17 12:01 ` Gerd Knorr
2003-07-17 14:57 ` Greg KH
2003-07-17 16:37 ` Gerd Knorr
2003-07-17 21:49 ` Greg KH
2003-07-18 9:59 ` Gerd Knorr
[not found] ` <20030718234359.GK1583@kroah.com>
2003-07-21 7:28 ` Gerd Knorr
2003-07-21 7:55 ` Ronald Bultje
2003-07-21 15:43 ` [RFC/PATCH] 1/2 v4l: sysfs'ify video4linux core Gerd Knorr
2003-07-21 15:47 ` [RFC/PATCH] 2/2 v4l: sysfs'ify bttv driver Gerd Knorr
2003-07-21 16:27 ` [RFC/PATCH] 1/2 v4l: sysfs'ify video4linux core Greg KH
2003-07-16 13:33 ` [RFC/PATCH] sysfs'ify video4linux Mark McClelland
2003-07-16 14:10 ` root
2003-07-16 16:23 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030716210800.GE2279@kroah.com \
--to=greg@kroah.com \
--cc=kraxel@bytesex.org \
--cc=linux-kernel@vger.kernel.org \
--cc=video4linux-list@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.