Re: kernel 2.6.8 pwc patches and counterpatches

From: Nemosoft Unv. (nemosoft_at_smcc.demon.nl)
Date: 08/25/04

  • Next message: Greg KH: "Re: kernel 2.6.8 pwc patches and counterpatches" 
    To: Greg KH <greg@kroah.com>
Date:	Wed, 25 Aug 2004 00:58:24 +0200

    Hello,

    On Tuesday 24 August 2004 00:10, you wrote:
    > On Wed, Aug 18, 2004 at 09:05:36AM -0700, Fr?d?ric Detienne wrote:
    > > On Tue, 2004-08-17 at 21:38, Andrew Morton wrote:
    > > > Fr?d?ric Detienne <fd@cisco.com> wrote:
    > > > > I suppose this is not the only place where we
    > > > > prepare API's for modules that do not belong to the kernel tree.
    > > >
    > > > It _is_ the only place, and that's the problem.
    > >
    > > yes and no. By providing a hook, there is a chance to insert an other
    > > decompressor (hopefully, a reverse engineered, open source one).
    >
    > Actually, in thinking about this even more, I just realized that I have
    > to rip this hook out. I say this because we are allowing a change to
    > the kernel that is needed _only_ for a closed source module. See
    > Linus's comments about "if a change is needed to be made to the kernel
    > in order to get a closed source module to work, that module must be made
    > opensource" or something close to that.
    >
    > So, I'll rip this out with the next round of USB patches that I send off
    > to Linus.
    >
    > Nemosoft, any thoughts?

    Uhm, excuse me? This hook has been there since the beginning of PWC in the
    kernel, so I don't consider it a 'change'. The only change there has been
    is in the declaration part, to allow for a single type of linkage with an
    external library [*]. Actually, if they hadn't started using "Register
    parameters" in the kernel to squeeze out a a few microseconds, I wouldn't
    have had this problem, and nobody would have noticed. The real problem is
    that GCC 2.95 doesn't like 'asmlinkage' in function pointer declarations
    which is why PWC failed to compile. I was _about_ to create in a patch
    tonight that would solve this problem and make it work on both GCC 2 and
    GCC 3 again, until I read this mail.

    Anyway....

    I've just about had it with the increasing
    "we-don't-want-binary-stuff-in-Linux" attitude lately. If you rip out this
    hook for PWC (pwc_register_decompressor), which would make it impossible to
    load a decompressor, closed source *OR* open source (should that happen one
    day), is going to be the last straw.

    Without this hook, PWC will work, but with limitations, just as it always
    has. But the _user_ always had a choice of loading a closed source module
    to get the extras. If you, kernel developers, maintainers, etc. are going
    to take away that right from the _users_, I think you're way over head,
    forgetting what open source is about, IMO.

    I accept that the Linux kernel is the work of Linus and the maintainers, and
    they can do with it as they please, but I will not accept that they can put
    arbitrary limits on the kernel's use by me, or other users.

    I've been maintaining this driver for the past 4 years, and it's always been
    an uphill battle against the closed sourceness of the driver. First, it was
    completely binary, which proved to be quite a support burden but I managed.
    Then I got allowance to open source part of the driver and add it to the
    kernel, so a) the webcam could run on more platforms, b) I could narrow
    down the support issues. Then, I started introducing cross-compiled PWCX
    (decompressor) modules for a variety of platforms, so it would work on even
    more systems. In the mean time, I had to dodge several changes to the
    kernel that, intentionally or unintentionally, caused the PWCX part to
    break down. But I managed. [**] And now, finally with PWC 9, I could
    provide even better cross-platform support. All to get these webcams
    working, make _a lot_ of people happy, and make Linux the top OS it
    deserves to be. Appearantly all in vain.

    To come back to Linusīs comment "if a change is needed [...] in order to get
    a closed source module to work, that module must be made opensource". Well,
    that ain't gonna work. There is no way that manufacturers are suddenly
    going to wave their hands in the air and start panicking "Oh dear, we're
    going to loose Linux support! What must we do?! Should we open source?
    Argh!" It is not going to happen. Period. Get down to earth, now.

    Actually, I've got a little surprise for you. The NDA I signed with Philips
    has already expired a year ago. Yet, I didn't just throw the decompressor
    code on the Internet. First, there could still be legal remedies since the
    cams are still in production to this very day. Second, that NDA was signed
    on a basis of trust and I do not want to lose that trust. I'm looking at
    the bigger picture here: if we (Linux developers) can show we are
    trustworthy, we may be able to get better support from hardware
    manufacturers now and in the future (and really, that's what the kernel is
    for 75% about ....) I'm still in contact with Philips and who knows, maybe
    we can get all the source opened up...

    Anyway, before this gets too long... I'm giving you a choice here. Either:

    * you are going to accept that there is a driver in the Linux kernel that
    has a hook that _may_ be used to load a binary-only decompressor part into
    the kernel, at the user's disgression. Maybe, one day, that part will be
    open source too but I cannot guarantuee that.

    * Or, you're saying: no, we cannot allow this under any circumstance. We do
    not even want to provide the means for the theoretical possibility that a
    binary module might be loaded into the kernel (in which case you can scrap
    the whole idea of loadable modules, if you want my opinion)

    Those are the options. No more, no less.

    In case the answer is "No", then I will:
    - demand that the PWC driver is removed from any further Linux kernel
    releases; Open source or not, it's still _my_ work.
    - remove the website (http://www.smcc.demon.nl/webcam/), all webpages and
    PWC version available for download from that site.
    - shut down the bug-tracker
    - remove the PWC related mailbox from my system
    - not respond to ANY mail related to PWC anymore; no user requests, no
    problem solving, no queries for information.

    Basicly, the PWC driver will then be null and void. And yes, that is a
    threat, but it shows how fed up I am with this. And believe me, there are a
    lot of users who will NOT be happy. But if you (kernel peeps) show contempt
    for all the work that I have done, then I'm not going to help you anymore,
    with Linux. Simple as that.

    I'm demanding a clear, and unambiguous answer on my question, if need be
    from Linus himself. I think the status of binary-only drivers, or in this
    case, a plugin, has always been in some sort of 'legal' limbo, and that PWC
    has always more or less meandered through the gaps. Now I want to know
    where I'm standing at.

     - Nemosoft

    [*] Two different version are possible, but most people would probably not
    have a clue as to how their kernel is compiled; and you won't know until
    the module Oopses...

    [**] To the nitwit on /. who once said "Well, you brought that all onto
    yourself when you signed that NDA", I can only say: "Go suck a lemon", to
    quote Maj. Carter. (SG-1)

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Greg KH: "Re: kernel 2.6.8 pwc patches and counterpatches"

    Relevant Pages

    • Re: pwc+pwcx is not illegal
      ... The driver got removed because the author ... will assume that since PWC is in the kernel, ... hook, Greg or anybody else had said: "Look, we really don't want this kind ...
      (Linux-Kernel)
    • Re: Logitech Quickcam Pro 4000
      ... the name of "kernel purity" so the pwc module maintainer stopped work on ... the pwc and pwcx modules. ... pwcx is not part of the kernel, never was, never will be. ... that allowing any proprietary modules to hook into the pure kernel is evil ...
      (alt.os.linux.suse)
    • 2.6.0 reboots after several hours with usb webcam
      ... Goede GX 300MHz system with 64MB RAM and 128MB Flash, usb-ohci and pwc ... The system is working perfect for serveral hours (with reading video ... reboot without webcam (tested 17 hours with not loaded usb modules). ... I log the kernel messages over the serial console. ...
      (Linux-Kernel)
    • Re: [PATCH 2 of 4] Introduce i386 fibril scheduling
      ... Also, when returning, check and clear the thread-blocked hook. ... - The hook copies the necessary state to a new kernel ... notices that its scheduler hook is no longer set. ... use a different scheduler hook function) and set up the state machine ...
      (Linux-Kernel)
    • Embedded processor (and OS, tools) selection for long-life product
      ... This is industrial safety monitoring equipment that also has to meet some minimal radiation rating. ... I think I will want the source for every piece, so open source or commercialized open source. ... The original system design used the Intel i960 running the Intel iRMK kernel. ...
      (comp.arch.embedded)