From: volodya@mindspring.com
To: Gerd Knorr <kraxel@bytesex.org>
Cc: video4linux-list@redhat.com, livid-gatos@linuxvideo.org,
linux-kernel@vger.kernel.org
Subject: Re: [V4L] Re: [RFC] alternative kernel multimedia API
Date: Tue, 6 Nov 2001 10:41:22 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.20.0111061033150.4730-100000@node2.localnet.net> (raw)
In-Reply-To: <20011105225201.A17854@bytesex.org>
On Mon, 5 Nov 2001, Gerd Knorr wrote:
> > > different kernel versions because a driver IMHO should be maintained for
> > > both current stable and current hacker kernels.
> >
> > The change I was talking about has occured someplace between 2.4.2 and
> > 2.4.9. On the other hand some interface did not change at all - for
> > example serial devices /dev/ttySx. I do not see anything too special to
> > video capture to warrant constanly changing interfaces.
>
> That was me in kernel 2.4.3 IIRC. Added one more argument to allow
> drivers to ask for specific minor numbers (so you can give your devices
> fixed minor numbers using insmod options). And this has _NOTHING_ to do
> with the API visible to the applications.
>
It has to do with the API visible to the driver.
>
> > > Why this needs to be in the kernel? Simply ship a copy of the header
> > > file with both application and driver or require the driver being
> > > installed to build the application. Once you've worked out good,
> > > working interfaces they can go into the kernel headers. You don't need
> > > that for experimental stuff.
> >
> > And what am I to do if someone introduces the exact same ioctl number into
> > the kernel ? I will get instant breakage. People will start saying: this
> > does not work with kernele 2.4.(N+x). So, I'll change the number and will
> > get bugreports of the kind "it does not work with 2.4.(N-1-y)". I do not
> > want that.
>
> Such clashes shouldn't happen as v4l has ioctl number ranges for driver
> private stuff which can be used for such tests and shouldn't cause
> clashes with new, official ioctls.
I did not know that - thanks. Where do I find notes on this ?
>
> Beside that I don't see why breaking applications is a problem for
> _experimental_ interfaces. On the one hand you want to have the
It is a problem because I want as many people as possible to try them.
This is the only way to work out installation dependent bugs. There is a
lot of variety out there: Redhat, Mandrake, Slackware, Suse, ix86,
PowerPC, Alpha, Sparc.. Each is a little different.
> flexibility to change interfaces easily to test them, on the other hand
> you care alot about compatibility and stuff. You can't get both, I
> don't see a way to do that without making either the drivers or the
> applications (or both) very complex.
Now here you are wrong. C have not changed in a while and you can still
write any programs in it ;) As for complexity.. I don't mind 10000 line
file if it is backed up by good algorithm. The good news is that with this
approach we separate interface stuff from driver dependent stuff - and,
hence, the most complex part can be easily tested.
>
> That is the price users will have to pay for playing with bleeding edge
> stuff.
>
> > > becomes harder to debug because the failures are more subtile. With a
> > > obsolete ioctl struct you likely get back -EINVAL, which is quite
> > > obvious if the application does sane error checking. Or the application
> > > doesn't even compile. Both are IMHO much better than some stange
> >
> > This is a separate issue.. Just keep in mind that there are plenty of
> > applications that ignore return values from ioctl's.
>
> s/applications/broken applications/
The line here is even finer than between AI and clever algorithm ;)
Vladimir Dergachev
>
> Gerd
>
> --
> Netscape is unable to locate the server localhost:8000.
> Please check the server name and try again.
>
next prev parent reply other threads:[~2001-11-06 15:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <slrn9tiq3v.69j.kraxel@bytesex.org>
2001-10-26 15:19 ` [V4L] Re: [RFC] alternative kernel multimedia API volodya
2001-10-26 17:52 ` Gerd Knorr
2001-10-26 21:28 ` volodya
2001-10-29 12:40 ` Gerd Knorr
2001-10-29 13:21 ` volodya
2001-10-30 9:51 ` Gerd Knorr
2001-11-02 15:10 ` volodya
2001-11-05 8:52 ` Gerd Knorr
2001-11-05 20:56 ` volodya
2001-11-05 21:52 ` Gerd Knorr
2001-11-06 15:41 ` volodya [this message]
2001-11-06 16:45 ` Gerd Knorr
2001-10-30 11:43 ` Mark McClelland
2001-11-04 8:39 ` Albert D. Cahalan
2001-11-04 17:44 ` volodya
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=Pine.LNX.4.20.0111061033150.4730-100000@node2.localnet.net \
--to=volodya@mindspring.com \
--cc=kraxel@bytesex.org \
--cc=linux-kernel@vger.kernel.org \
--cc=livid-gatos@linuxvideo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).