Hello all
I came across an idea, how Linux could allow binary modules, still having
reasonable control over them.
I am not advocating for binary modules, nor I am trying to make their life
harder, this is just an idea how it could be done.
I'll try to make it short, details may be discussed later, if any interest
arises.
A binary module is "considered good" if
1) It is accompanied by a "suitably licensed" (GPL-compatible) open-source
glue-module.
2) The sourced used to compile the binary part do not access any of the
kernel functionalities directly. Which means:
a) they don't (need to) include any kernel header-files
b) they don't access any kernel objects or methods directly
c) all interfacing to the kernel goes over the glue module and the
interface is _purely functional_ - no macros, no inlines.
With this restrictions those "good" binary modules could be debugged, run
in a sandbox... The question remains if anybody will want to debug them:-)
Again - no advocating, just in case anyone find it useful / worthy.
Regards
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
On Mon, 19 Apr 2004, Guennadi Liakhovetski wrote:
> A binary module is "considered good" if
>
> 1) It is accompanied by a "suitably licensed" (GPL-compatible) open-source
> glue-module.
>
> 2) The sourced used to compile the binary part do not access any of the
> kernel functionalities directly. Which means:
> a) they don't (need to) include any kernel header-files
> b) they don't access any kernel objects or methods directly
> c) all interfacing to the kernel goes over the glue module and the
> interface is _purely functional_ - no macros, no inlines.
And for which architectures do they have to provide the binary-only part? 22
and still counting...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, 20 Apr 2004, Geert Uytterhoeven wrote:
> On Mon, 19 Apr 2004, Guennadi Liakhovetski wrote:
> > A binary module is "considered good" if
>
> And for which architectures do they have to provide the binary-only part? 22
> and still counting...
They don't have to. Otherwise, I guess, for those they want their modules
to work on.
Again, I am not saying: "under this conditions binary modules will be most
welcome in Linux and will be absolutely beneficial". I am just saying, one
could try to impose something like this to try to better handle those evil
things. If at all...
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
On Monday 19 of April 2004 17:53, Guennadi Liakhovetski wrote:
> Hello all
>
> I came across an idea, how Linux could allow binary modules, still having
> reasonable control over them.
>
> I am not advocating for binary modules, nor I am trying to make their life
> harder, this is just an idea how it could be done.
>
> I'll try to make it short, details may be discussed later, if any interest
> arises.
>
> A binary module is "considered good" if
This is a false assumption IMO no binary only modules can be "good".
> 1) It is accompanied by a "suitably licensed" (GPL-compatible) open-source
> glue-module.
>
> 2) The sourced used to compile the binary part do not access any of the
> kernel functionalities directly. Which means:
> a) they don't (need to) include any kernel header-files
> b) they don't access any kernel objects or methods directly
> c) all interfacing to the kernel goes over the glue module and the
> interface is _purely functional_ - no macros, no inlines.
What you've just described are the most evil binary only modules. :-)
Please think a while about all these recent "the most famous binary module"
vs 4kb kernel stacks mails...
I think that binary modules are evil because:
- they slow down development (indirectly - think about it)
- some vendors claim Linux support
while they only provide binary only modules
- less informed users tend to put blame on kernel or distribution
not the binary only module (!)
I'm not a fanatic :-), I can see good sides of binary only modules:
- additional hardware and features is supported
- wider usage of Linux
but I still think that cons > pros...
> 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.
> Again - no advocating, just in case anyone find it useful / worthy.
Useful thing will be to create mailing list about Linux kernel
+ binary only modules and to move discussion from lkml there...
Regards,
Bartlomiej
On Tue, 20 Apr 2004, Bartlomiej Zolnierkiewicz wrote:
> > A binary module is "considered good" if
>
> This is a false assumption IMO no binary only modules can be "good".
I agree! That was just an idea to make Linux life easier __if__ it
__must__ live with binary modules.
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
Guennadi Liakhovetski <[email protected]> said:
> On Tue, 20 Apr 2004, Bartlomiej Zolnierkiewicz wrote:
> > > A binary module is "considered good" if
> > This is a false assumption IMO no binary only modules can be "good".
> I agree! That was just an idea to make Linux life easier __if__ it
> __must__ live with binary modules.
Then call it "tolerable", not "good". ("Barely tolerable" comes to mind,
but might be a bit harsh...).
In any case, one of the biggest advantages of Linux is that in-kernel
interfaces aren't set in stone. They are extremely efficient because they
are expressed in terms of access to data structures and inline functions
and macros. The kernel is extremely flexible because it can be configured
in hundreds of different ways. All of this is lost through a fixed
binary-only interface to the binary blob inside the module.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Tue, 20 Apr 2004, Horst von Brand wrote:
> Guennadi Liakhovetski <[email protected]> said:
> > On Tue, 20 Apr 2004, Bartlomiej Zolnierkiewicz wrote:
> > > > A binary module is "considered good" if
>
> > > This is a false assumption IMO no binary only modules can be "good".
>
> > I agree! That was just an idea to make Linux life easier __if__ it
> > __must__ live with binary modules.
>
> Then call it "tolerable", not "good". ("Barely tolerable" comes to mind,
> but might be a bit harsh...).
>
> In any case, one of the biggest advantages of Linux is that in-kernel
> interfaces aren't set in stone. They are extremely efficient because they
> are expressed in terms of access to data structures and inline functions
> and macros. The kernel is extremely flexible because it can be configured
> in hundreds of different ways. All of this is lost through a fixed
> binary-only interface to the binary blob inside the module.
Hi,
Maybe I am totally wrong, but I think that binary modules should (if they
must exists) be divided into source (better opensource) interface and
binary only part. But I think that majority of binary only drivers could
be moved to user space in the great part. Some of them for example are in
kernel only to allow to create new device and "bind" to it. The rest can
be probably moved to userspace. Yes, there is performance issue, but only
in some very rare cases: video cards and maybe something more. But modem
drivers, vlan drivers, most raid drivers, archiving and versioning
filesystem implementations, network filesystems (LUFS?), and probably more
can be removed from kernel.
So I think that there should be some kind of special user-space processes
that are userspace, have separate adress space, have some special
scheduling rules (to make them more important than normal processes) and
can interface with kernel better than normal processes (maybe they will
have more special syscalls and some kind of callback functionality...).
The interface should allow create and "bind" to device, allocate memory
region, dma, interrupt, port range, etc. This interface can be considered
unstable and change with the kernel. There should be way to allow some
process to do something and disallow to do everything else (to protect
from hidden secret code or simply broken driver). And the interface can be
not very portable but should be highly extendable by vendors to allow them
add other functionality to it (if vendor will make this functionality gpl
and if it will be good it can be included into mainline kernel). This way
vendors can cooperate with kernel developers.
What do you think?
Grzegorz Kulewski
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.
> 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.
> - 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.
> - 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
- 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.
- 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.
- 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.
> 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.
> > 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.
> 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.
--
shannon "AT" widomaker.com -- [4649 5920 4320 204e 4452 5420 5348 5920 4820
2056 2054 434d 2048 4d54 2045 204e 5259 4820 444e 0a53]
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
And it must, if only because there are laws that require some device
drivers to be binary only.
I kid you not, take a look at the FCC software radio rules. Some wireless
cards fall into their definition.
Wierd world, but there we go...
Andrew
--On Tuesday, 20 April 2004 5:08 p.m. +0200 Guennadi Liakhovetski
<[email protected]> wrote:
> On Tue, 20 Apr 2004, Bartlomiej Zolnierkiewicz wrote:
>
>> > A binary module is "considered good" if
>>
>> This is a false assumption IMO no binary only modules can be "good".
>
> I agree! That was just an idea to make Linux life easier __if__ it
> __must__ live with binary modules.
>
> Thanks
> Guennadi
> ---------------------------------
> Guennadi Liakhovetski, Ph.D.
> DSA Daten- und Systemtechnik GmbH
> Pascalstr. 28
> D-52076 Aachen
> Germany
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
---------
Andrew McGregor
Director, Scientific Advisor
IndraNet Technologies Ltd
http://www.indranet-technologies.com/
On Fri, 23 Apr 2004, Andrew McGregor wrote:
> And it must, if only because there are laws that require some device
> drivers to be binary only.
WRONG. I work in the industry. There are no such rule(s). In fact,
it's quite the opposite. Anything that is FCC Type Accepted or
Type Approved has, as a matter of law, its complete design
information, to the extent required for FCC Type Acceptance,
available for public inspection in the Public Reference Room.
Therefore, it can't be hidden as something "proprietary".
>
> I kid you not, take a look at the FCC software radio rules. Some wireless
> cards fall into their definition.
>
The requirement that the devices "not be modified" has been interpreted
by some to mean that software can't be supplied to the end-user. This
is an interpretation and, in fact, an invalid one.
If a user were to modify the device, (presumably by changing the
software) it is no longer Type Approved in the case of receivers,
and, if a transmitter the modification must be done in accordance
with "good standards of engineering practice" under the authority
of a holder of a General Radiotelephone (or Radiotelegraph) License.
The operation of a receiver that is not "Type Approved" is not
unlawful unless it produces "harmful interference". Type Approval
was necessary to SELL a device that generates radio frequency
energy, not to use it.
FYI Amateur Radio Operators make receivers and transmitters. They
are not Type Approved. Holders of FCC Radiotelephone licenses are
allowed to make or modify even 50,000 watt broadcast transmitters.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
Note 96.31% of all statistics are fiction.
--On Friday, 23 April 2004 8:29 a.m. -0400 "Richard B. Johnson"
<[email protected]> wrote:
> On Fri, 23 Apr 2004, Andrew McGregor wrote:
>
>> And it must, if only because there are laws that require some device
>> drivers to be binary only.
>
>
> WRONG. I work in the industry. There are no such rule(s). In fact,
> it's quite the opposite. Anything that is FCC Type Accepted or
> Type Approved has, as a matter of law, its complete design
> information, to the extent required for FCC Type Acceptance,
> available for public inspection in the Public Reference Room.
> Therefore, it can't be hidden as something "proprietary".
I was aware of that much, but does that actually include the code of the
drivers?
By the way, there are examples outside wireless as well, but they are very
exotic.
>> I kid you not, take a look at the FCC software radio rules. Some
>> wireless cards fall into their definition.
>>
>
> The requirement that the devices "not be modified" has been interpreted
> by some to mean that software can't be supplied to the end-user. This
> is an interpretation and, in fact, an invalid one.
That is very good news. I'll have to get an opinion myself, of course, but
I think it is good to get this clarified in public.
> If a user were to modify the device, (presumably by changing the
> software) it is no longer Type Approved in the case of receivers,
> and, if a transmitter the modification must be done in accordance
> with "good standards of engineering practice" under the authority
> of a holder of a General Radiotelephone (or Radiotelegraph) License.
>
> The operation of a receiver that is not "Type Approved" is not
> unlawful unless it produces "harmful interference". Type Approval
> was necessary to SELL a device that generates radio frequency
> energy, not to use it.
>
> FYI Amateur Radio Operators make receivers and transmitters. They
> are not Type Approved. Holders of FCC Radiotelephone licenses are
> allowed to make or modify even 50,000 watt broadcast transmitters.
I was aware of the situation regarding license holders.
>
> Cheers,
> Dick Johnson
Thanks for pointing this out,
Andrew
---------
Andrew McGregor
Director, Scientific Advisor
IndraNet Technologies Ltd
http://www.indranet-technologies.com/
Guennadi Liakhovetski wrote:
> Hello all
>
> I came across an idea, how Linux could allow binary modules, still having
> reasonable control over them.
>
> I am not advocating for binary modules, nor I am trying to make their life
> harder, this is just an idea how it could be done.
>
> I'll try to make it short, details may be discussed later, if any interest
> arises.
>
> A binary module is "considered good" if
>
I belive that you forgot to make "The Point."
And "discussion" (good vs. bad isn't discussion, but flames) went in
wrong direction.
Be constructive. For example: Let's aks h/w producers making at least
glue layer open source (bsd or something), so people eventually might
help to maintain this glue layer.
How it can help? - producer with time may move bigger parts of driver
into open source domains.
How it can gets screwed? - producer might just start liking when
someone is doing his work for him. Some license a-la GPL to not let glue
layer to slip into binary only domain back must be in place.
This could be a good starting point for h/w producers and linux
comunity as a whole.
Saying Good/Bad is just B.S. - helps no-one.
Building bridges between comunity and producers - might improve and
deepen relationships. And that's what I hope for.
P.S. nVidia driver might be an example: IIRC nVidia engineers were
saying that they have four 2/3rd party code parts inside driver, which
they are not able to open source/GPL. But open source glue layer to
connect this "tainted" 4 parts with Linux kernel might help everyone:
nVidia, LK and even those four companies. At least I hope for this.
On Sat, 24 Apr 2004, Ihar 'Philips' Filipau wrote:
> Guennadi Liakhovetski wrote:
> > Hello all
> >
> > I came across an idea, how Linux could allow binary modules, still having
> > reasonable control over them.
> >
> > I am not advocating for binary modules, nor I am trying to make their life
> > harder, this is just an idea how it could be done.
> >
> > I'll try to make it short, details may be discussed later, if any interest
> > arises.
> >
> > A binary module is "considered good" if
>
> I belive that you forgot to make "The Point."
May be...
> And "discussion" (good vs. bad isn't discussion, but flames) went in
> wrong direction.
Very right. Let me try to explain it again. It was just an idea, that
popped in my mind. I was not sure if it was good or bad, so, I decided to
dump it to lkml, so, that the people here could evaluate it. And, if it
can be of any use - use it. I, personally, don't care much (at least at
the moment) about binary drivers. And I most of all wanted to avoid
starting a new wave of flames. That's why I tried to avoid answering to
other posters (sorry, if it was somewhat impolite).
> Be constructive. For example: Let's aks h/w producers making at least
> glue layer open source (bsd or something), so people eventually might
> help to maintain this glue layer.
> How it can help? - producer with time may move bigger parts of driver
> into open source domains.
> How it can gets screwed? - producer might just start liking when
> someone is doing his work for him. Some license a-la GPL to not let glue
> layer to slip into binary only domain back must be in place.
>
> This could be a good starting point for h/w producers and linux
> comunity as a whole.
>
> Saying Good/Bad is just B.S. - helps no-one.
> Building bridges between comunity and producers - might improve and
> deepen relationships. And that's what I hope for.
Thanks! You seem to have understood the idea pretty close to what I mean,
and, probably, you are better capable of explaining things, than I:-) But,
I think, if it is going to be discussed further, let's move it away from
LKML (you are right, Bart). It can either be discussed in private emails,
or, maybe someone could create a dedicated mailing list somewhere.
Thanks
Guennadi
---
Guennadi Liakhovetski