Re: [somewhat OT] binary modules agaaaain

From: Bartlomiej Zolnierkiewicz (B.Zolnierkiewicz_at_elka.pw.edu.pl)
Date: 04/22/04

  • Next message: Al Niessner: "atomic_t and atomic_inc" 
    To: Charles Shannon Hendrix <shannon@widomaker.com>
Date:	Thu, 22 Apr 2004 20:55:04 +0200

    What did I say about moving this discussion from lkml? :-)
    [ Well, it's my fault I shouldn't have replied. ]

    This is my last mail on this subject with lkml cc:ed, sorry for noise.

    On Thursday 22 of April 2004 18:19, Charles Shannon Hendrix wrote:
    > Tue, 20 Apr 2004 @ 16:11 +0200, Bartlomiej Zolnierkiewicz said:
    > > > A binary module is "considered good" if
    > >
    > > This is a false assumption IMO no binary only modules can be "good".
    >
    > True, but non-working hardware is even worse.

    For who? This is a tricky question. 8)

    > > I think that binary modules are evil because:
    > >
    > > - they slow down development (indirectly - think about it)
    >
    > I don't think this is true at all.

    Have you followed x86 4kb stacks discussion?

    > > - some vendors claim Linux support
    > > while they only provide binary only modules
    >
    > If they provide a binary for Linux, then they can claim Linux support.
    >
    > We may not like it, but it is a legitimate claim.

    No, they instead should claim support for specific distribution
    and specific distribution versions (and some vendors do this).

    > > - less informed users tend to put blame on kernel or distribution
    > > not the binary only module (!)
    >
    > True, but this is just noise in the signal in terms of what the less
    > informed users think.
    >
    > > I'm not a fanatic :-), I can see good sides of binary only modules:
    > >
    > > - additional hardware and features is supported
    > >
    > > - wider usage of Linux
    >
    > - some driver code is tied up in legal issues that are not currently
    > solvable

    They can often be solved with some effort (i.e. Intel WLAN driver).

    > - For some hardware, only the company has enough knowledge to write
    > a decent driver. I can't blame a company for wanting to control
    > the drivers for their hardware for quality reasons.

    Use Windows then. ;-) Most bugs (any OS) are *driver* bugs.

    The whole thing is about you having control over hardware
    (thus drivers) not hardware/software vendor.

    Yes, this scares some people. :)

    > - As a user, I need to get work done, not play politics with my
    > hardware. I prefer open solutions, but each day I have work to
    > do and can't afford to play politics with my hardware.

    And you are free to do this, just don't bring your problems on lkml
    wasting my time. Reproduce problem without binary modules,
    if you can't then bring your problems to the authors of these modules
    or pay somebody to debug+solve your problems.

    "Linux is free but my time is not." (hi Andre)

    > - I personally don't believe that building barriers to binary drives is
    > helpful. In fact, I think it ultimately means *less* open source
    > from manufacturers. I think of a good binary interface as a good
    > ambassador.

    I'm not advocating artificial barriers. I'm saying that IMO most kernel
    developers have _zero_ interest in supporting such interfaces.

    My point is that use/write/whatever binary only drivers if you like
    but don't waste my and other people time if you have problems.

    > > but I still think that cons > pros...
    >
    > Of course. We live in a highly imperfect world, and the computer
    > industry is among the most imperfect parts of it.
    >
    > At the same time, we need to make sure that in our posturing and
    > political moves, we don't end up making things worse.

    This list is for development not for politics.

    I personally hate kernel politics and try to concentrate on kernel hacking.

    > > > With this restrictions those "good" binary modules could be debugged,
    > > > run in a sandbox... The question remains if anybody will want to debug
    > > > them:-)
    > >
    > > In my opinion using binary only modules is equal to modifying your kernel
    > > but being unable to show your modifications so you are on your own and
    > > you shouldn't bring it on lkml.
    >
    > Sounds illogical to me.
    >
    > That's like saying that selling a turbocharger for a car is the same as
    > illegally copying the design of a car and selling it as your own.

    Sorry, I can't see how this two things are related.

    I'm rather saying that if you buy a turbocharger (binary only module)
    and modify your car you shouldn't expect car (kernel) producer to accept
    your warranty claims. [ and remember that you got kernel for free! ]

    I think you agree with this :-).

    By using binary only module you modify your kernel code (on runtime)
    and I can no longer see what really is going on and how do you expect
    me to solve your problems?

    > > Useful thing will be to create mailing list about Linux kernel
    > > + binary only modules and to move discussion from lkml there...
    >
    > True. Also useful would be to get manufacturers involved in any
    > such list so you can hear from them.

    True, this can be interesting and constructive.

    Regards,
    Bartlomiej

    -
    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: Al Niessner: "atomic_t and atomic_inc"

    Relevant Pages

    • Re: Nobody should ever need to patch the kernel!!
      ... The code if a driver may not. ... Modules are *required* to be built against the exact kernel ... Well at least I _can_ install system level software in Linux. ... | I don't know the hardware specifics of winmodem in particular, ...
      (comp.os.linux.development.system)
    • Re: easy alsa patches for the stable kernel?
      ... They even find their way into the stable-tree since ... longer to get into the kernel. ... But we nevertheless need to find a way to make todays hardware ... hardware-vendor is not the driver author at the same time (like in the ...
      (Linux-Kernel)
    • Re: [patch] pci: pci_enable_device_bars() fix
      ... Also a CC to linux-scsi and the driver author would be nice, ... are the ones with hardware and can verify. ... Instead i did a search of lkml (based on the function name in the build ... bugreport is hostility. ...
      (Linux-Kernel)
    • Re: [PATCH 02/12] Blackfin arch: Add label to call new GPIO API
      ... That is part of the natural evolution of the kernel isn't it - per ... driver requested, was already claimed by yyy driver". ... But requires custom bootloaders or board setup for every hardware ... For other systems - where you can have a UART on any pin - I completely ...
      (Linux-Kernel)
    • Re: why no gcc in 9.1 personal?
      ... - They licensed the driver or part of it from someone else. ... They fear that broken drivers could damage the hardware, ... A driver or at least the kernel interface of the driver ... has to be compiled on the target machine with the very same compiler ...
      (alt.os.linux.suse)