From: Gerd Knorr <kraxel@bytesex.org>
To: Greg KH <greg@kroah.com>
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 22:20:18 +0200 [thread overview]
Message-ID: <20030716202018.GC26510@bytesex.org> (raw)
In-Reply-To: <20030716161924.GA7406@kroah.com>
> 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.
> 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 ...
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.
> 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 :)
Gerd
--
sigfault
next prev parent reply other threads:[~2003-07-16 20:10 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 [this message]
2003-07-16 21:08 ` Greg KH
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=20030716202018.GC26510@bytesex.org \
--to=kraxel@bytesex.org \
--cc=greg@kroah.com \
--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.