Re: Possibly offtopic : Binary only driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > rest is required to be GPL anyway in principle so can be adjusted.
> 
> I thought binary modules were OK, hence the whole GPL vs non-GPL symbol
> versioning system?

you think wrong most likely. It kinda depends on which lawyer you talk
to, and on in which country that lawyer is. But there is no explicit
permission to do non-GPL kernel modules. At least not from most authors
of the kernel, and certainly not for the parts of which I own the
copyright. 

It all is a bit of a gray area (eg the "which lawyer" part), the _GPL
exports are a start to make it clear that certain parts sure are NOT
part of the gray area.

> > At least that's the intention. Some people think they can get away with
> > not being GPL while still using and depending on deep kernel internals;
> > well... to be honest the pain is on them though.
> 
> Actually the pain is on the users. You just don't see it.

people who choose to use binary modules suffer, I am fully aware of
that. I rather not have them suffer that. But in a way they choose that
pain when they choose to start using binary modules.

But look at it with a slightly longer pervue; about half the bugs
reported against the kernel are in the drivers. The fact that the driver
sources are available gives us a shot at fixing those, just as the
availability of the core source allows us to fix bugs there.
If the drivers weren't part of that, their quality would lag WAY behind.
(And to be honest, you do see that in several binary drivers: bad
quality. Nvidia seems to be improving somewhat there but they didn't
always have that; others are still struggling).

> > As for your comparison to X, glibc, gtk etc, those EXTERNAL interfaces
> > remain stable, just like the kernel external interface is. 
> 
> The X server has provided a stable driver interface for a very long time
> now. GTK provides a stable interface for theming engines, glibc for DNS
> resolver plugins and so on. Clearly the kernel *does* provide an interface

btw the glibc NSS abi is changing all the time ...  X is about to change
their driver interfaces because they suffered too much bitrot.

> > But those
> > projects do change the internal interfaces a lot.. just they don't allow
> > anyone to see it, unlike the kernel where modules do get to see it.
> 
> As already pointed out, these projects actually make it clear which
> interfaces are internal and which aren't. Whether you like it or not,
> parts of the module interface aren't internal, they are being used by
> external developers sometimes because they have no choice.

they do have a choice. they can do things on the other side of the
designed stable interface. For example, NVidia could do this. Their IP
is in code that easily can be on the userspace side (the open source DRM
modules prove this, they do it that way). They need a very thin layer in
the kernel for support in that scenario, which is so thin that it
doesn't contain IP.
But they *choose* to not do that. That's their choice. With that, they
choose the pain and problems that come with that approach. They not only
chose for themselves but also for all their customers who want to use
their 3D engine.


Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux