From: Gerd Knorr <kraxel@bytesex.org>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] videodev.[ch] redesign
Date: 10 Feb 2002 08:34:09 GMT [thread overview]
Message-ID: <slrna6cc41.ret.kraxel@bytesex.org> (raw)
In-Reply-To: <20020209194602.A23061@bytesex.org> <200202092053.g19KrSN05200@oenone.homelinux.org> <slrna6b2gn.nnn.kraxel@bytesex.org> <200202100032.g1A0WGX06570@oenone.homelinux.org>
> > > Could you make a helper for open like for ioctl ?
> >
> > video_open does call video_device[minor]->fops->open(), isn't that
> > enought?
>
> I'd prefer seeing exclusive opening handeled in the helper initially.
Ok, I see what you mean. That was another issue I was thinking about.
Current videodev.c allows one open at a time only, the new code removes
that restriction (intentionally).
Should videodev.c provide a way to ask for exclusive opens to maintain
backward compatibility, using some flag in struct video_device maybe?
Is there some sane way to do this without having to hook into
fops->release? Checking inode->i_count maybe?
> > Sorry, I don't understand. What exactly do you mean?
> > file->private_data? videodev.c doesn't touch it ...
>
> But the skeleton driver you provide does so.
Thats just some sample code, a dummy driver which does nothing but print
some messages to the log. If you want allow multiple applications
access the driver at the same you need some way to disturgish the file
handles, and skeleton.c demonstrates how this can be done using
file->private_data.
usb drivers are free to do with file->private_data whatever they want
(like skeleton.c does), videodev.c doesn't use it.
Gerd
--
#define ENOCLUE 125 /* userland programmer induced race condition */
next prev parent reply other threads:[~2002-02-10 9:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-09 18:46 [PATCH/RFC] videodev.[ch] redesign Gerd Knorr
2002-02-09 20:53 ` Oliver Neukum
2002-02-09 20:44 ` Gerd Knorr
2002-02-10 0:32 ` Oliver Neukum
2002-02-10 8:34 ` Gerd Knorr [this message]
2002-02-09 20:53 ` Oliver Neukum
2002-02-10 2:03 ` [V4L] " Alan Cox
2002-02-10 8:59 ` Gerd Knorr
2002-02-11 21:10 ` [PATCH/RFC] videodev.[ch] redesign -- take #2 Gerd Knorr
2002-02-10 3:58 ` [V4L] [PATCH/RFC] videodev.[ch] redesign Mark McClelland
2002-02-10 9:11 ` Gerd Knorr
2002-02-10 12:54 ` Mark McClelland
2002-02-11 9:55 ` Gerd Knorr
2002-02-11 11:58 ` Mark McClelland
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=slrna6cc41.ret.kraxel@bytesex.org \
--to=kraxel@bytesex.org \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox