public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: The difference between Linus's kernel and Alan Cox's kernel
@ 2001-05-25 21:17 Wayne.Brown
  0 siblings, 0 replies; 7+ messages in thread
From: Wayne.Brown @ 2001-05-25 21:17 UTC (permalink / raw)
  To: Thiago Vinhas de Moraes; +Cc: linux-kernel, Linus Torvalds, Alan Cox



It really ought to be Linus and/or Alan who answers this, but from my own
observations, here's the way I think it goes:

Alan and Linus don't always agree on what should be in the kernel; and even when
they do, they sometimes disagree on when something is ready to be included.
Alan may think a particular set of patches are ready, while Linus thinks they
need to mature a bit more; or perhaps he thinks the whole approach is wrong and
should be scrapped.  So Alan puts it in his kernel, and Linus leaves it out of
his.  (Of course, sometimes it's Linus who adds something that Alan rejects.)
It sometimes happens that one of these new ideas turns out better than expected
(especially after going through a few bug report/new patch cycles), and the
person who rejected it changes his mind and includes it later; or maybe it
doesn't work out and gets dropped altogether.  Also, as you've already observed,
Alan regularly resyncs major parts of his tree with Linus' so they don't get too
far apart, and Linus occasionally does the same.

It used to bother me, too, to have to keep up with two different kernel trees.
But I've come to realize that this is a Good Thing.  It provides a way for
people with different viewpoints to approach an idea from more than one
direction.  If the two kernels are trying to solve a particular problem in
different ways, we get to see how each approach works in the real world, rather
than just in a theoretical discussion.  If the two kernels branch too far apart
it could be a problem, but Linus and Alan have been diligent about keeping that
from happening.  I think the interplay (is "competition" too strong a word?)
between the two branches has helped make the "official" kernel better than it
might have been otherwise.

Wayne



^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: ac15 and 2.4.5-pre6, pwc format conversion
@ 2001-05-25 19:37 Nemosoft Unv.
  2001-05-25 19:51 ` Jeff Garzik
  0 siblings, 1 reply; 7+ messages in thread
From: Nemosoft Unv. @ 2001-05-25 19:37 UTC (permalink / raw)
  To: Alan Cox, johannes; +Cc: linux-usb-devel, linux-kernel, Erik Mouw, randy.dunlap

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 4186 bytes --]

Greetings,

Coalescing two messages in one:

On 25-May-01 Alan Cox wrote:
> Nope. Its been policy since 2.0. Its both v4l1 and v4l2 policy. In fact its
> fairly nonsensical to handle any format conversions in kernel unless the
> device outputs a unique format of its own.

Oh come on. 2.0 has been out since, what? 1996? Methinks you have had plenty
of time to really do something about it then. You are now simply too late.

> It breaks apps by doing conversions, and it breaks important apps like H263
> codecs not silly little camera viewers, because you trash the performance

This is a NULL argument. First, it doesn´t break anything; I think H263 is
smart to pick a YUV format if it´s available. Second, conversion has to be
done at one point or another. If the native format of the camera is RGB,
H263 will have to convert to YUV. Wether or not this is done in kernel space
or user space doesn´t matter: it has to be done. And in case the native
format of the camera doesn´t resemble anything in V4L, you will have TWO
conversion: first, in kernel from native to V4L palette, and then in your
tool from V4L to whatever format you need, while maybe the driver could do
it all in one stage.

On 25-May-01 Alan Cox wrote:
>> > that none of the sound drivers does sample rate conversion although
>> > some sound chips are locked at 48kHz only.
>> 
>> True, but a number of audio tools will break, because they don=B4t supp=
> 
> So fix the tools
> 
>> if you limit the number of available palettes per driver. Plus, you wil=
>> l get
>> severe fragmentation of which program works with which driver. Which is
>> unacceptable, in my opinion (and certainly NOT the idea behind a common=
>>  API!)
> 
> Fix the tools.

Gee, ¨Fix the tools¨ seems to be your mantra :-(. Anyway, breaking the tools
doesn´t necessarely mean they are going to get fixed; not all are
being actively maintained at the moment (okay, that´s a pity; still it´s a
shame).

And you are probably not going to get the endless streams of mails to the
webcam developers which state: ¨I upgraded my kernel to 2.4.X and my webcam
broke!¨ Do you really think we will enjoy replying time after time: ¨Yes, I
know, but Alan Cox told me to do so¨. No. To a lot of users, and even
application developers, this just plainly sucks.

>> routines, while (nearly) nothing has been said about other (USB) webcam
>> drivers which have conversion routines.
> 
> I have those in my firing line too. It has always been the policy that
> format
> conversions go in user space. The kernel is an arbitrator of resources it
> is not a shit bucket for solving other peoples incompetence.

Now you are being insulting, really. There are a lot of competent people
who put a lot of time and effort into these tools. But the Video4Linux API
is not complete and not completely suitable for webcams. For example, it
misses the quite fundamental call to query the available palettes; nor does
the V4L API give any hint that the number of palettes might be severely
limited. The first tools that were created had the luxury of hardware that
did all the work for them, so why not use it? Webcams are not so lucky.
There´s no need to penalize them, because if the change goes through, a lot
of tools will not work with webcams but with TV cards.

                                         ...

Anyway, I am not going to debate this any further at this point. Johannes,
please remove my webcam driver from the USB source tree, until the software
YUV/RGB conversion has been removed from ALL other video devices (preferably
all at the same time). I will *not* have a crippled driver into the Linux
kernel. If this is going to be policy, fine. But then this policy will apply
to ALL drivers equally, not just mine because suddenly Alan realizes he has
been sleeping for the past 5 years and decides to implement a policy hardly
noone ever knew existed.

 - Nemosoft

-----------------------------------------------------------------------------
Try SorceryNet!   One of the best IRC-networks around!   irc.sorcery.net:9000
URL: never        IRC: nemosoft      IscaBBS (bbs.isca.uiowa.edu): Nemosoft
                        >> Never mind the daylight << 

^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2001-05-28 16:06 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-05-25 21:17 The difference between Linus's kernel and Alan Cox's kernel Wayne.Brown
  -- strict thread matches above, loose matches on Subject: below --
2001-05-25 19:37 ac15 and 2.4.5-pre6, pwc format conversion Nemosoft Unv.
2001-05-25 19:51 ` Jeff Garzik
2001-05-25 20:12   ` The difference between Linus's kernel and Alan Cox's kernel Thiago Vinhas de Moraes
2001-05-25 21:32     ` Erik Mouw
2001-05-25 21:40       ` CaT
2001-05-25 21:50         ` Erik Mouw
2001-05-25 23:05     ` Alan Cox
2001-05-28 15:50       ` Thiago Vinhas de Moraes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox