Re: Honest does not pay here ...

Re: Honest does not pay here ...

[Adam J. Richter]

	I believe that the illegality of proprietary kernel modules
has resulting in more GPL-compatible kernel code than without such
a restriction.

	Perhaps more people would initially write contributions in the
absense of such a restriction, but my experience has been that, given
that choice, enough contributors eventually evolve their policies to
something not sufficiently free that there is less in total to build
on, and the net result is that software does not advance in the long
term as quickly as with something like the GPL.  That is one reason
why this Berkeley alumnus decided to bet on Linux rather than BSD back
in 1992. It's a complex empirical question.  I believe that copying
conditions have been *one* of the determining factors in adoption of
Linux versus Berkeley Software Distribution (and I'm not a BSD
detractor; I'd like to see Linux distributions that could boot dual
boot a BSD kernel with Linux-compatible system calls, but I digress).

	This brings me to my suggestion for how you could legally
accomplish what you're trying to do with only modest change in your
procedures.  You could do your proprietary work on BSD and port any
GPL-compatible stuff that you want to release to Linux.  I expect the
BSD people would probably welcome you and it might even improve
communication and reduce duplication of effort between BSD and Linux
camps.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

Re: Honest does not pay here ...

[Henning P. Schmiedehausen]

"Adam J. Richter" <adam@yggdrasil.com> writes:

>	I believe that the illegality of proprietary kernel modules
>has resulting in more GPL-compatible kernel code than without such
>a restriction.

What people like you don't understand is, that there no such thing as
a "illegal proprietary kernel module" according to the GPL.

There is only an "illegal distribution of a proprietary binary kernel
module with the linux kernel" under the GPL.

If Andres' customers are happy with getting a binary only module for
use with their kernel, there is no violation of the GPL by Andre.

	Regards
		Henning (writing this on a computer with the nvidia
                         module loaded and happy about it.  And
                         completely within the boundaries of the
                         GPL. No matter what RMS says).



-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Honest does not pay here ...

[David van Hoose]

Henning P. Schmiedehausen wrote:
> "Adam J. Richter" <adam@yggdrasil.com> writes:
> 
> 
>>	I believe that the illegality of proprietary kernel modules
>>has resulting in more GPL-compatible kernel code than without such
>>a restriction.
> 
> 
> What people like you don't understand is, that there no such thing as
> a "illegal proprietary kernel module" according to the GPL.
> 
> There is only an "illegal distribution of a proprietary binary kernel
> module with the linux kernel" under the GPL.
> 
> If Andres' customers are happy with getting a binary only module for
> use with their kernel, there is no violation of the GPL by Andre.
> 
> 	Regards
> 		Henning (writing this on a computer with the nvidia
>                          module loaded and happy about it.  And
>                          completely within the boundaries of the
>                          GPL. No matter what RMS says).

Binary-only drivers are great as long as they work. Every such driver I 
have used so far has worked perfectly.
I have only one problem with NVidia's driver: It refuses to compile 
under 2.5.54 which requires me use X's nv driver or use 2.4.21 for KDE.
Anyone know how to get around that? :-)

-David

Re: Honest does not pay here ...

[Henning P. Schmiedehausen]

David van Hoose <davidvh@cox.net> writes:

>Binary-only drivers are great as long as they work. Every such driver I 
>have used so far has worked perfectly.
>I have only one problem with NVidia's driver: It refuses to compile 
>under 2.5.54 which requires me use X's nv driver or use 2.4.21 for KDE.
>Anyone know how to get around that? :-)

You get what you paid for. Go to the nVidia support forum and complain
loudly. That's what it is there for. I'd probably say that they tell
you to stick to the "released versions of Linux". If you consider this
support policy sucky, well there is the ATI Radeon chip...

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Honest does not pay here ...

[David van Hoose]

Henning P. Schmiedehausen wrote:
> David van Hoose <davidvh@cox.net> writes:
> 
> 
>>Binary-only drivers are great as long as they work. Every such driver I 
>>have used so far has worked perfectly.
>>I have only one problem with NVidia's driver: It refuses to compile 
>>under 2.5.54 which requires me use X's nv driver or use 2.4.21 for KDE.
>>Anyone know how to get around that? :-)
> 
> 
> You get what you paid for. Go to the nVidia support forum and complain
> loudly. That's what it is there for. I'd probably say that they tell
> you to stick to the "released versions of Linux". If you consider this
> support policy sucky, well there is the ATI Radeon chip...

Very true. And if they don't want to support the beta kernel, that's 
there choice. I'd rather them throw a driver in for people that use the 
beta kernel for possibly testing new chipsets, know whether or not they 
need to do revisions before their own driver can be released, and so 
when the beta kernel is finally released that they'll have a driver 
right then to provide.
The impression I am getting from the GPL argument is that people want 
100% opensource drivers. Well, to be frank, I'd rather have a driver 
that isn't 100% opensource to no driver at all. I think most everyone on 
this mailing list agrees. If not, I'd like to know why.
Personally, I think Andre does a lot of good for the kernel. I don't 
know of many desktop systems that don't use IDE. Without someone like 
Andre to keep up support as well as he does, IMO a lot of people would 
get left unsupported and end up not using Linux. Less Linux users means 
less demand for Linux support from mainstream developers and hardware 
companies. People want a name to be able to communicate to when they are 
having issues. Some will find their way to this mailing list, but others 
will look for something that has (or has better) support.

-David

Re: Honest does not pay here ...

[Henning Schmiedehausen]

On Mon, 2003-01-06 at 01:22, David van Hoose wrote:
> Henning P. Schmiedehausen wrote:
> > David van Hoose <davidvh@cox.net> writes:
> > 
> > 
> >>Binary-only drivers are great as long as they work. Every such driver I 
> >>have used so far has worked perfectly.
> >>I have only one problem with NVidia's driver: It refuses to compile 
> >>under 2.5.54 which requires me use X's nv driver or use 2.4.21 for KDE.
> >>Anyone know how to get around that? :-)
> > 
> > 
> > You get what you paid for. Go to the nVidia support forum and complain
> > loudly. That's what it is there for. I'd probably say that they tell
> > you to stick to the "released versions of Linux". If you consider this
> > support policy sucky, well there is the ATI Radeon chip...
> 
> Very true. And if they don't want to support the beta kernel, that's 
> there choice. I'd rather them throw a driver in for people that use the 
> beta kernel for possibly testing new chipsets, know whether or not they 
> need to do revisions before their own driver can be released, and so 
> when the beta kernel is finally released that they'll have a driver 
> right then to provide.

As I use the nvdriver on 2.4, I didn't have the pressure yet to chase a
driver for 2.5. But I'd guess that nvidia has some sort of non-public
beta program where they do testing of their stuff on latest kernels. I'd
simply ask whether there is such a program and how to join. 

After all, they surely _want_ their driver to be used. Because it sells
boards. :-) 


> The impression I am getting from the GPL argument is that people want 
> 100% opensource drivers. Well, to be frank, I'd rather have a driver 
> that isn't 100% opensource to no driver at all. I think most everyone on 

Couldn't agree more.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Honest does not pay here ...

[Matthias Andree]

On Sun, 05 Jan 2003, David van Hoose wrote:

> The impression I am getting from the GPL argument is that people want 
> 100% opensource drivers. Well, to be frank, I'd rather have a driver 
> that isn't 100% opensource to no driver at all. I think most everyone on 
> this mailing list agrees. If not, I'd like to know why.

You're at the author's mercy if you need to upgrade your kernel or if
the driver doesn't work for you. I'd rather know before buying a product
(modem, GFX board, ...) if there's either non-NDA'd documentation or
better an OpenSource driver or at least support for such.

-- 
Matthias Andree

Re: Honest does not pay here ...

[Andre Hedrick]

On Tue, 7 Jan 2003, Matthias Andree wrote:

> On Sun, 05 Jan 2003, David van Hoose wrote:
> 
> > The impression I am getting from the GPL argument is that people want 
> > 100% opensource drivers. Well, to be frank, I'd rather have a driver 
> > that isn't 100% opensource to no driver at all. I think most everyone on 
> > this mailing list agrees. If not, I'd like to know why.
> 
> You're at the author's mercy if you need to upgrade your kernel or if
> the driver doesn't work for you. I'd rather know before buying a product
> (modem, GFX board, ...) if there's either non-NDA'd documentation or
> better an OpenSource driver or at least support for such.

Well I am silly and toss in a 1 year free upgrade service clause.
For product upgrades and kernel upgrades, so your arguement is not an
issue for me.

Regardless, it looks like the issues are still muddy on modules so, all of
this noisy may be for nothing.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: Honest does not pay here ...

[Andrew Walrond]

Matthias Andree wrote:
> On Sun, 05 Jan 2003, David van Hoose wrote:
> 
> 
>>The impression I am getting from the GPL argument is that people want 
>>100% opensource drivers. Well, to be frank, I'd rather have a driver 
>>that isn't 100% opensource to no driver at all. I think most everyone on 
>>this mailing list agrees. If not, I'd like to know why.
> 
> 
> You're at the author's mercy if you need to upgrade your kernel or if
> the driver doesn't work for you. I'd rather know before buying a product
> (modem, GFX board, ...) if there's either non-NDA'd documentation or
> better an OpenSource driver or at least support for such.
> 

Fine for us developers, but 99.5% of users wouldn't recognise a c 
function if it jumped up and bit them on the ass. If it doesn't say 
"linux supported" on the box, they won't buy it. Google? Source Forge? 
./configure? WTFIT?. Where is their freedom?

Until the manufacturers start providing good quality supported drivers 
for their hardware, binary or source, linux will stay exactly where it 
is now; a server room tool and a hobbyists playground.

I for one think thats a real shame

Re: Honest does not pay here ...

[Steven Barnhart]

On Mon, 2003-01-06 at 19:07, Andrew Walrond wrote:
> Fine for us developers, but 99.5% of users wouldn't recognise a c 
> function if it jumped up and bit them on the ass. If it doesn't say 
> "linux supported" on the box, they won't buy it. Google? Source Forge? 
> ./configure? WTFIT?. Where is their freedom?
> 
> Until the manufacturers start providing good quality supported drivers 
> for their hardware, binary or source, linux will stay exactly where it 
> is now; a server room tool and a hobbyists playground.
> 
> I for one think thats a real shame

You are just being silly. Any half-decent person (including my grandma,
seriously!) can set up distributions such as Mandrake and now maybe even
Red Hat. The problem I see, especially here (but atleast normal people
won't subscribe :P), is that a lot of Linux users hate proprietary
software and bla bla you get what I was going to say there. Anyways its
quite easy to set up a system and you no longer have to be a hobbyiest.
you did read IDC's predictions didn't you? Linux has a chance of
becoming #2 in the next year or so. Beats me what this had to do w/the
topic either..geez.

-- 
Steven
sbarn03@softhome.net
GnuPG Fingerprint: 9357 F403 B0A1 E18D 86D5  2230 BB92 6D64 D516 0A94

Re: Honest does not pay here ...

[Henning P. Schmiedehausen]

Steven Barnhart <sbarn03@softhome.net> writes:

>On Mon, 2003-01-06 at 19:07, Andrew Walrond wrote:
>> Fine for us developers, but 99.5% of users wouldn't recognise a c 
>> function if it jumped up and bit them on the ass. If it doesn't say 
>> "linux supported" on the box, they won't buy it. Google? Source Forge? 
>> ./configure? WTFIT?. Where is their freedom?
>> 
>> Until the manufacturers start providing good quality supported drivers 
>> for their hardware, binary or source, linux will stay exactly where it 
>> is now; a server room tool and a hobbyists playground.
>> 
>> I for one think thats a real shame

>You are just being silly. Any half-decent person (including my grandma,
>seriously!) can set up distributions such as Mandrake and now maybe even
>Red Hat. The problem I see, especially here (but atleast normal people

And that is exactly what most of the OSS advocates get wrong. They
can't.  My wife (which is a physician and my prime example here
because she's in nuclear medicine and works with computers (Sun, Vax
(sic!), Windows, MacOS) all day long at work and knows quite a bit
about Unix) can't set up RedHat Linux, SuSE Linux, Windows 98, Windows
2000 or MacOS either. And I can't adjust a PET scanner which is
trivial to her. It is simply not my area of work. And your grandma
_can't_ set up Linux because when the first window pops up and asks
about "workstation / server / laptop / custom" installation, she's
lost. Because she does not _know_ what a workstation or a server
is. She has a computer for surfing and text processing.
Not a "work" station.

Yes, looks trivial to you and me. But it isn't to your grandma.

Most of the people advocating that "Linux is simple to use for
everyone" never really tried to install Linux to "everyone" and then
leave them alone just like most people do with Windows installations.

Install Linux for your grandma, show her how to use it and then don't
answer her phone calls for about two weeks. Rinse. Repeat with
Windows. You will be surprised about the outcome. Rinse. Repeat with a
non-english speaker and a localized version of Linux / Windows. You
will be surprised even more. BTDTGTT.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Honest does not pay here ...

[Alexander Kellett]

On Tue, Jan 07, 2003 at 09:57:25AM +0000, Henning P. Schmiedehausen wrote:
> Install Linux for your grandma, show her how to use it and then don't
> answer her phone calls for about two weeks. Rinse. Repeat with
> Windows. You will be surprised about the outcome. Rinse. Repeat with a
> non-english speaker and a localized version of Linux / Windows. You
> will be surprised even more. BTDTGTT.

Rather than "moaning", if do you have such good ideas
for improving distributions could you not simply contribute,
to the Debian desktop project for example?

I agree, the distributions are not quite ready yet, 
but a few good ideas and emails a week may actually 
make the difference.  

Alex

--
One of the hundreds of KDE contributors

Re: Honest does not pay here ...

[Daniel Egger]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

Am Die, 2003-01-07 um 10.57 schrieb Henning P. Schmiedehausen:

> Install Linux for your grandma, show her how to use it and then don't
> answer her phone calls for about two weeks. Rinse. Repeat with
> Windows. You will be surprised about the outcome. Rinse. Repeat with a
> non-english speaker and a localized version of Linux / Windows. You
> will be surprised even more. BTDTGTT.

Interesting you mention it: I'm "supporting" several equally skilled 
family members' computers, half of them running Windows (XP Prof, ME,
98SE - you pick the flavour) half of them running Debian testing, guess
which call more often? Oh yes, and if they call: The Linux people call
in advance *before* making decisions (like buying new hardware) while
the Windows people only call me to clean up the messed system...

-- 
Servus,
       Daniel

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Honest does not pay here ...

[Matthias Andree]

On Tue, 07 Jan 2003, Andrew Walrond wrote:

> Matthias Andree wrote:
> >You're at the author's mercy if you need to upgrade your kernel or if
> >the driver doesn't work for you. I'd rather know before buying a product
> >(modem, GFX board, ...) if there's either non-NDA'd documentation or
> >better an OpenSource driver or at least support for such.
> 
> Fine for us developers, but 99.5% of users wouldn't recognise a c 
> function if it jumped up and bit them on the ass. If it doesn't say 
> "linux supported" on the box, they won't buy it. Google? Source Forge? 
> ./configure? WTFIT?. Where is their freedom?

> Until the manufacturers start providing good quality supported drivers 
> for their hardware, binary or source, linux will stay exactly where it 
> is now; a server room tool and a hobbyists playground.

> I for one think thats a real shame

Only that you can't trust in the el-cheapo vendors claiming Linux
support, and an independent certification is needed (not only for Linux,
for the *BSDs as well). Without a trusted certification, some crooks may
try to claim Linux support and it won't quite work out.

Re: Honest does not pay here ...

[Henning P. Schmiedehausen]

Matthias Andree <matthias.andree@gmx.de> writes:

>> Until the manufacturers start providing good quality supported drivers 
>> for their hardware, binary or source, linux will stay exactly where it 
>> is now; a server room tool and a hobbyists playground.

>> I for one think thats a real shame

>Only that you can't trust in the el-cheapo vendors claiming Linux
>support, and an independent certification is needed (not only for Linux,
>for the *BSDs as well). Without a trusted certification, some crooks may
>try to claim Linux support and it won't quite work out.

http://www.cs.helsinki.fi/linux/linux-kernel/2001-35/0559.html

Dated 5. September 2001.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Honest does not pay here ...

[Alan Cox]

On Tue, 2003-01-07 at 10:07, Henning P. Schmiedehausen wrote:
> >Only that you can't trust in the el-cheapo vendors claiming Linux
> >support, and an independent certification is needed (not only for Linux,
> >for the *BSDs as well). Without a trusted certification, some crooks may
> >try to claim Linux support and it won't quite work out.
> 
> http://www.cs.helsinki.fi/linux/linux-kernel/2001-35/0559.html
> 
> Dated 5. September 2001.

Its one of the things the new module loader and the presence of 
the crypto libs in 2.5 will make a lot easier to do...

Re: Honest does not pay here ...

[Matthias Andree]

On Tue, 07 Jan 2003, Henning P. Schmiedehausen wrote:

> Matthias Andree <matthias.andree@gmx.de> writes:
> 
> >> Until the manufacturers start providing good quality supported drivers 
> >> for their hardware, binary or source, linux will stay exactly where it 
> >> is now; a server room tool and a hobbyists playground.
> 
> >> I for one think thats a real shame
> 
> >Only that you can't trust in the el-cheapo vendors claiming Linux
> >support, and an independent certification is needed (not only for Linux,
> >for the *BSDs as well). Without a trusted certification, some crooks may
> >try to claim Linux support and it won't quite work out.
> 
> http://www.cs.helsinki.fi/linux/linux-kernel/2001-35/0559.html
> 
> Dated 5. September 2001.

Close, but I hadn't meant signing in mind, but something like "we write
we support Linux" when they only have 2.0 binary-only modules. I want
the term "Linux compatible" to be certified, not soft- or hardware per
se. Signing drivers is difficult, because of the said problems, and
because a faithful and trustworthy vendor then has to have his stuff
re-certified over and over.

I you happened to read the German c't magazine 1/2003 about RAID
hardware and Linux, or the 2/2003 edition about TV cards, then look at
the pertinent sections to know what I mean.

The other thing (Linus labs) is already there: module tainting...

Re: Honest does not pay here ...

[Bill Davidsen]

On Tue, 7 Jan 2003, Matthias Andree wrote:

> Only that you can't trust in the el-cheapo vendors claiming Linux
> support, and an independent certification is needed (not only for Linux,
> for the *BSDs as well). Without a trusted certification, some crooks may
> try to claim Linux support and it won't quite work out.

To be honest, support for Windows is much easier than Linux. There are
only a few versions of Windows out, in terms of how many versions are
needed, and in many cases the same driver will work for several versions.

For Linux, there are not only dozens of kernel versions around, but the
uni and smp versions are not the same. Vendors who want to provide drivers
really want to provide the binary even if the module is open source, just
because the average person has no desire to build any part of a kernel.

So it is possible to release a driver and claim in good faith that it
works, and still not have it work with *your* system. Not because the
vendor is evil, incompetent, a "crook" (your term), dishonest, or even
that testing was poor, but because all kernels are very much not created
equal. 

Try to understand why vendors want to ship binary modules and why they
don't always work before making accusations.

All that said, an independent testing service would be of use to the
vendors, because they could find things before shipping and have someone
to share the blame if the module didn't work with another kernel.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Honest does not pay here ...

[Ryan Anderson]

On Tue, Jan 07, 2003 at 11:32:48AM -0500, Bill Davidsen wrote:
> Try to understand why vendors want to ship binary modules and why they
> don't always work before making accusations.

I don't think *anyone* has a problem with vendors shipping binary
modules that the source is available for. (and has a free license)

-- 

Ryan Anderson
  sometimes Pug Majere

Re: Honest does not pay here ...

[Jesse Pollard]

On Tuesday 07 January 2003 10:32 am, Bill Davidsen wrote:
> On Tue, 7 Jan 2003, Matthias Andree wrote:
> > Only that you can't trust in the el-cheapo vendors claiming Linux
> > support, and an independent certification is needed (not only for Linux,
> > for the *BSDs as well). Without a trusted certification, some crooks may
> > try to claim Linux support and it won't quite work out.
>
> To be honest, support for Windows is much easier than Linux. There are
> only a few versions of Windows out, in terms of how many versions are
> needed, and in many cases the same driver will work for several versions.
>
> For Linux, there are not only dozens of kernel versions around, but the
> uni and smp versions are not the same. Vendors who want to provide drivers
> really want to provide the binary even if the module is open source, just
> because the average person has no desire to build any part of a kernel.
>
> So it is possible to release a driver and claim in good faith that it
> works, and still not have it work with *your* system. Not because the
> vendor is evil, incompetent, a "crook" (your term), dishonest, or even
> that testing was poor, but because all kernels are very much not created
> equal.

I would still incline toward the "testing was poor". If the vendor just says 
"works with Linux", and not "works with Linux 2.4.18", then it is deceptive, 
and worst case it becomes dishonest.

> Try to understand why vendors want to ship binary modules and why they
> don't always work before making accusations.

Been there (though it wasn't within the last 20 years). The only justification
for not releasing the specifications is incompetent hardware design worked
around by software. Releasing the software would reveal how incompetent
some designers are.

> All that said, an independent testing service would be of use to the
> vendors, because they could find things before shipping and have someone
> to share the blame if the module didn't work with another kernel.

Releasing the source would save more money than the testing service costs.
Besides, I'm not buying a driver - I only want the device, and the specs on 
the device that may allow me or someone else to create a driver for Linux
or some other purpose (ie - a dedicated, embeded system not necessarily based
on Linux)...

Personally, I view binary only drivers as evidence of incompetence, or
embarassement over how poor a design is in the first place...
-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Honest does not pay here ...

[Bill Davidsen]

On Tue, 7 Jan 2003, Jesse Pollard wrote:

> On Tuesday 07 January 2003 10:32 am, Bill Davidsen wrote:

> > For Linux, there are not only dozens of kernel versions around, but the
> > uni and smp versions are not the same. Vendors who want to provide drivers
> > really want to provide the binary even if the module is open source, just
> > because the average person has no desire to build any part of a kernel.

> > Try to understand why vendors want to ship binary modules and why they
> > don't always work before making accusations.
> 
> Been there (though it wasn't within the last 20 years). The only justification
> for not releasing the specifications is incompetent hardware design worked
> around by software. Releasing the software would reveal how incompetent
> some designers are.
> 
> > All that said, an independent testing service would be of use to the
> > vendors, because they could find things before shipping and have someone
> > to share the blame if the module didn't work with another kernel.
> 
> Releasing the source would save more money than the testing service costs.
> Besides, I'm not buying a driver - I only want the device, and the specs on 
> the device that may allow me or someone else to create a driver for Linux
> or some other purpose (ie - a dedicated, embeded system not necessarily based
> on Linux)...
> 
> Personally, I view binary only drivers as evidence of incompetence, or
> embarassement over how poor a design is in the first place...

Either you didn't read or didn't understand the points I was making that
even if the driver is open source the vendors still have good reasons to
release a binary module with the hardware.

I'm sorry I don't know how to state it more clearly than I did the first
time, it has zero to do with open source or not, and all to do with what
the majority of users are capable of installing.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: Honest does not pay here ...

[Andre Hedrick]

On Tue, 7 Jan 2003, Jesse Pollard wrote:

> Personally, I view binary only drivers as evidence of incompetence, or
> embarassement over how poor a design is in the first place...

Funny how you would call a persons work who you trust in open source now
becomes dirty in closed.  Next time you spout crap of this magnitude,
remember who made possible for the DCFL "Defense Computer Forensics Lab",
your cluster computers to use ATA by writing giving away almost all the
pci chipsets supported to date.

I am not incompetence or embarassement, just want to pay the mortgage.
So why don't you offer to pay my mortgage and bills for the next 30 years?

So from the "incompetence" and "embarassed" author of your disk drives,
you are welcome.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: Honest does not pay here ...

[Jesse Pollard]

On Tuesday 07 January 2003 02:58 pm, Andre Hedrick wrote:
> On Tue, 7 Jan 2003, Jesse Pollard wrote:
> > Personally, I view binary only drivers as evidence of incompetence, or
> > embarassement over how poor a design is in the first place...
>
> Funny how you would call a persons work who you trust in open source now
> becomes dirty in closed.  Next time you spout crap of this magnitude,
> remember who made possible for the DCFL "Defense Computer Forensics Lab",
> your cluster computers to use ATA by writing giving away almost all the
> pci chipsets supported to date.
>
> I am not incompetence or embarassement, just want to pay the mortgage.
> So why don't you offer to pay my mortgage and bills for the next 30 years?
>
> So from the "incompetence" and "embarassed" author of your disk drives,
> you are welcome.

Not quite the same thing. I'm referring to the hardware design. I've seen too
much crap hidden in drivers to try and coverup crappy hardware
design/implementation.

I would presume your cut would come from my willingness to purchace the
hardware. Your added value is a software demonstration of capability. My
contribution is to test your source under other versions of the kernel, and if
I improve/fix bugs that are then returned to the community which you then
merge into your driver back to the company. Then more hardware would get
sold, and you get another cut.

If they don't pay you for support, then you are not required to provide
additional support by merging, redesigning, or extending. Your contribution
to the company is to improve their sales.

I used to develop drivers for DEC hardware, for OSs that were NOT from DEC.
I was paid by those who used that hardware for additional sales (actually, 
they leased equipment/services for oil surveys). Why was DEC equipment
used?

1. full hardware documentation was available
2. it was the least expensive hardware
3. the devices worked (well.. up until they started trying to kill the PDP11s)

Out of the hardware designed by the company (not DEC), the only parts they
would NOT release was a piece of crap that was a radio ranging interface. It
did not even provide a synchronous parallel interface (we were forced to read
the device twice and compair the reads. If they didn't match, then we had to 
read it again and compair. If this didn't match the preceeding answer, we had 
to start over... If two of them matched then we got a good read... 90 times 
out of a 100...)

Oh, I almost forgot the other crappy one - a spread spectrum modem that would 
receive 130 to 140 bytes for every 128 bytes sent... We had to implement a 
full packet protocol just to send 15 bytes (it wouldn't start tansmitting 
until the 16th byte was sent to the device). Then we had to be sure to send
AT LEAST enough to fill out 128 bytes, even if we didn't have that much data.
(I don't think it stopped transmitting until it had sent 128) and nulls 
weren't accepted for some reason. I could not convince the designer that
it would be much better to put the packet protocol in the modem itself and
hide those bad bytes.

Neither of these were very acceptable to the clients... but we hid most of
the crap in the drivers.

In your case, If I can't get the full specs (even to understand what the 
device is supposed to do), then I don't really want it. If I recieve drivers
that work, and available in source (all of mine currently are this way), then
I'll use it, and I am willing to purchase more of them.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Honest does not pay here ...

[Andre Hedrick]

On Tue, 7 Jan 2003, Jesse Pollard wrote:

> Not quite the same thing. I'm referring to the hardware design. I've seen too
> much crap hidden in drivers to try and coverup crappy hardware
> design/implementation.

I never said there was hardware involved.
I could add hardware in the form of CAM.
	Content Addressable Memory.

> I would presume your cut would come from my willingness to purchace the
> hardware. Your added value is a software demonstration of capability. My

Nope, it is pure software ... my cut is you buying the driver.

If the hardware fails, it is in opensouce drivers.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: Honest does not pay here ...

[Matthias Andree]

On Tue, 07 Jan 2003, Jesse Pollard wrote:

> Been there (though it wasn't within the last 20 years). The only justification
> for not releasing the specifications is incompetent hardware design worked
> around by software. Releasing the software would reveal how incompetent
> some designers are.

Or they just didn't have the time or other resources to go for the real
solution, but just /had/ to crutch around. They wouldn't be allowed to
tell even their wife as long as they worked with the same employer.

Re: Honest does not pay here ...

[Matthias Andree]

On Tue, 07 Jan 2003, Bill Davidsen wrote:

> For Linux, there are not only dozens of kernel versions around, but the
> uni and smp versions are not the same. Vendors who want to provide drivers
> really want to provide the binary even if the module is open source, just
> because the average person has no desire to build any part of a kernel.

That's sad but true. Would there be a way to have universal interfaces
that are always the same? I mean, I'd think that if all SMP stuff is
conditionally compiled and optimized to nothing on a UP kernel that only
has the do-nothing stubs (yes, it costs overhead), but if it cuts the
maintenance workload down to half its former size, it'd be worth it.

> So it is possible to release a driver and claim in good faith that it
> works, and still not have it work with *your* system. Not because the
> vendor is evil, incompetent, a "crook" (your term), dishonest, or even
> that testing was poor, but because all kernels are very much not created
> equal. 

Well, if someone claims "Linux driver coming soon" and that driver gets
never released, that'd qualify for the harsh term. If it claims Linux
support but the performance is not on par with other OSs or similar
hardware, that's no support either.

> Try to understand why vendors want to ship binary modules and why they
> don't always work before making accusations.

Binary drivers can still be OpenSource, if they just ship with the
source. Binary-only is the problem, and that is what I was referring to.
Please excuse my causing misunderstandings.

> All that said, an independent testing service would be of use to the
> vendors, because they could find things before shipping and have someone
> to share the blame if the module didn't work with another kernel.

Indeed.

Re: Honest does not pay here ...

[Dana Lacoste]

On Mon, 2003-01-06 at 18:41, Matthias Andree wrote:

> You're at the author's mercy if you need to upgrade your kernel or if
> the driver doesn't work for you. I'd rather know before buying a product
> (modem, GFX board, ...) if there's either non-NDA'd documentation or
> better an OpenSource driver or at least support for such.

Which is why you chose an open source driver over a closed source
driver, but you're STILL ignoring the "any driver is better than none"
argument.

Dana "Not playing 3d, so fully open source driven" Lacoste
Ottawa, Canada

Re: Honest does not pay here ...

[Matthias Andree]

On Tue, 07 Jan 2003, Dana Lacoste wrote:

> On Mon, 2003-01-06 at 18:41, Matthias Andree wrote:
> 
> > You're at the author's mercy if you need to upgrade your kernel or if
> > the driver doesn't work for you. I'd rather know before buying a product
> > (modem, GFX board, ...) if there's either non-NDA'd documentation or
> > better an OpenSource driver or at least support for such.
> 
> Which is why you chose an open source driver over a closed source
> driver, but you're STILL ignoring the "any driver is better than none"
> argument.

Depends on the driver quality. If it's stable, then it might qualify. If
it confuses my computer, then I'll rather sell the hardware to someone
who doesn't use Linux and buy a hardware that is documented and has
decent OpenSource drivers.

-- 
Matthias Andree

Re: Honest does not pay here ...

[venom]

What really surprises me is that in this thread, nor in the other one about
NVIDIA module, none made a mantion about the 2.5 modules infrastructure
of next 2.6 kernels using runqueue instead of task queues and tasklets.

In very semplicistic words:
In 2.5/2.6 kernels, non GPL modules have a big
penalty, because they cannot create their own queue, but have to use a default
one.

(tasklets still remains, so that I can use with 2.5 kernel tha NVIDIA
modules with the patch fronm www.minion.de.)

I saw just a very defuse mention from Andre Hedrick.

That would be an important point, because some term of the discussion changes.

First of all, I do not mnd about binary only modules, and fixed ones like
nvidia, I was knowing I would had to use them when I bought those cards.

I do also agree with reasons of Andre Hedrick.

But this particular new modules infrastructures is a big penality for binary
only modules, AND SO IS A STRONG POSITION OF THE LINUX KERNEL AS A WHOLE
ABOUT THIS TOPIC.

This is a good incentive for company to GPL the drivers, and for users to use
GPL ones. This is a fact, and every one forgot it.

Then, if a developers wants to release a binary only modules, and then release
the sources when his work is repaid,
he can do so. I will be happy to use this module, if I need it, if it is stable
and works with the kernel version i choice (if not, I simply will go for
another hardware if I can),
and happier when it will be GPL
also because potentially it could work even better.

On the other side, the the linux kernel has implemented the just one smart
incentive for all to release modules under GPL, and who instead
choiche to release binary only modules knows very well that he will have
to face some true limitation. The developers has a serious reason to GPL
the code when he is "repaid".


For big companies like NVIDIA situation is slighly different.
They are already repaid by hardware, and they have all the interess
to have drivers that work at best. Image is important for them,
and performance gain too.
So they are strongly pushed since the
beginning to GPL the code, to avoid any kind of penalty.

how could they loose costumers just because a worse hardware works better
because of a GPL driver?

maybe my samples are too extreme (of course they are, ad every
provocation), but I was tired
to listen all
discussion about ideological points, and none considering
a pragmatic technical argument.

Luigi Genoni

On Wed, 8 Jan 2003, Matthias Andree wrote:

> Date: Wed, 8 Jan 2003 00:28:20 +0100
> From: Matthias Andree <matthias.andree@gmx.de>
> To: linux-kernel@vger.kernel.org
> Subject: Re: Honest does not pay here ...
>
> On Tue, 07 Jan 2003, Dana Lacoste wrote:
>
> > On Mon, 2003-01-06 at 18:41, Matthias Andree wrote:
> >
> > > You're at the author's mercy if you need to upgrade your kernel or if
> > > the driver doesn't work for you. I'd rather know before buying a product
> > > (modem, GFX board, ...) if there's either non-NDA'd documentation or
> > > better an OpenSource driver or at least support for such.
> >
> > Which is why you chose an open source driver over a closed source
> > driver, but you're STILL ignoring the "any driver is better than none"
> > argument.
>
> Depends on the driver quality. If it's stable, then it might qualify. If
> it confuses my computer, then I'll rather sell the hardware to someone
> who doesn't use Linux and buy a hardware that is documented and has
> decent OpenSource drivers.
>
> --
> Matthias Andree
> -
> 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/
>

Re: Honest does not pay here ...

[Larry McVoy]

> In very semplicistic words:
> In 2.5/2.6 kernels, non GPL modules have a big
> penalty, because they cannot create their own queue, but have to use a default
> one.

I may be showing my ignorance here (won't be the first time) but this makes
me wonder if Linux could provide a way to do "user level drivers".  I.e.,
drivers which ran in kernel mode but in the context of a process and had
to talk to the real kernel via pipes or whatever.  It's a fair amount of
plumbing but could have the advantage of being a more stable interface
for the drivers. 

If you think about it, drivers are more or less open/close/read/write/ioctl.
They need kernel privileges to do their thing but don't need (and shouldn't
have) access to all the guts of the kernel.

Can any well traveled driver people see this working or is it nuts?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Honest does not pay here ...

[venom]

well, I was forgetting to specify,
queues are kernel threads, and that is quite
optimum expecially on SMP systems.
One big advantage is that conflicts possibilities are
(should be) less than minimal.

Luigi

On Tue, 7 Jan 2003, Larry McVoy wrote:

> Date: Tue, 7 Jan 2003 16:30:50 -0800
> From: Larry McVoy <lm@bitmover.com>
> To: venom@sns.it
> Cc: Matthias Andree <matthias.andree@gmx.de>, linux-kernel@vger.kernel.org,
>      andre@linux-ide.org
> Subject: Re: Honest does not pay here ...
>
>
> > In very semplicistic words:
> > In 2.5/2.6 kernels, non GPL modules have a big
> > penalty, because they cannot create their own queue, but have to use a default
> > one.
>
> I may be showing my ignorance here (won't be the first time) but this makes
> me wonder if Linux could provide a way to do "user level drivers".  I.e.,
> drivers which ran in kernel mode but in the context of a process and had
> to talk to the real kernel via pipes or whatever.  It's a fair amount of
> plumbing but could have the advantage of being a more stable interface
> for the drivers.
>
> If you think about it, drivers are more or less open/close/read/write/ioctl.
> They need kernel privileges to do their thing but don't need (and shouldn't
> have) access to all the guts of the kernel.
>
> Can any well traveled driver people see this working or is it nuts?
> --
> ---
> Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm
>

Re: Honest does not pay here ...

[Andre Hedrick]

Luigi,

You forgot one thing.  None of us can control what the end user does.
If a vendor tells the enduser to alter the 2.5/2.6 kernel and recompile.
What are you going to do?

Add a clause where the enduser can not change the source code or apply a
patch to do it for them?

Funny, you lost your rights to do that w/ GPL, as did I.

*sigh*

Andre Hedrick
LAD Storage Consulting Group

On Wed, 8 Jan 2003 venom@sns.it wrote:

> 
> well, I was forgetting to specify,
> queues are kernel threads, and that is quite
> optimum expecially on SMP systems.
> One big advantage is that conflicts possibilities are
> (should be) less than minimal.
> 
> Luigi
> 
> On Tue, 7 Jan 2003, Larry McVoy wrote:
> 
> > Date: Tue, 7 Jan 2003 16:30:50 -0800
> > From: Larry McVoy <lm@bitmover.com>
> > To: venom@sns.it
> > Cc: Matthias Andree <matthias.andree@gmx.de>, linux-kernel@vger.kernel.org,
> >      andre@linux-ide.org
> > Subject: Re: Honest does not pay here ...
> >
> >
> > > In very semplicistic words:
> > > In 2.5/2.6 kernels, non GPL modules have a big
> > > penalty, because they cannot create their own queue, but have to use a default
> > > one.
> >
> > I may be showing my ignorance here (won't be the first time) but this makes
> > me wonder if Linux could provide a way to do "user level drivers".  I.e.,
> > drivers which ran in kernel mode but in the context of a process and had
> > to talk to the real kernel via pipes or whatever.  It's a fair amount of
> > plumbing but could have the advantage of being a more stable interface
> > for the drivers.
> >
> > If you think about it, drivers are more or less open/close/read/write/ioctl.
> > They need kernel privileges to do their thing but don't need (and shouldn't
> > have) access to all the guts of the kernel.
> >
> > Can any well traveled driver people see this working or is it nuts?
> > --
> > ---
> > Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm
> >
> 
> -
> 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/
> 

Re: Honest does not pay here ...

[venom]

if I understand your point, a vendor could ask to the end user to apply a patch
to the new kernels, so that modules infrastructure will be changed, and also non
GPLed modules can create their own run queue.


Yes, it is possible, because we are talking about open source (I mean a more
generic definition instead of free-software, i.e. all the software that comes
with source code). I would add, it's in the rules of the game.
But developers for this patch have to be paid, and
patch could create conflicts, and has to be maintained togheter with the
binary only module (depends on costs).

To say the truth, I do not even expect end users to care if the modules is
running with its own kernel threads in his own run queue, or it is using the
defaul queue.

Anyway I found the runqueue concept, as it has been implemented, an
equilibrate and factual solution to incentivate companies to GPL their code,
and I was surprised that none (except a short allusion from you),
in two threads took the opportunity to talk about a fact and a good point.

Luigi Genoni


On Tue, 7 Jan 2003, Andre Hedrick wrote:

> Date: Tue, 7 Jan 2003 17:10:41 -0800 (PST)
> From: Andre Hedrick <andre@linux-ide.org>
> To: venom@sns.it
> Cc: Larry McVoy <lm@bitmover.com>, Matthias Andree <matthias.andree@gmx.de>,
>      linux-kernel@vger.kernel.org
> Subject: Re: Honest does not pay here ...
>
>
> Luigi,
>
> You forgot one thing.  None of us can control what the end user does.
> If a vendor tells the enduser to alter the 2.5/2.6 kernel and recompile.
> What are you going to do?
>
> Add a clause where the enduser can not change the source code or apply a
> patch to do it for them?
>
> Funny, you lost your rights to do that w/ GPL, as did I.
>
> *sigh*
>
> Andre Hedrick
> LAD Storage Consulting Group
>
> On Wed, 8 Jan 2003 venom@sns.it wrote:
>
> >
> > well, I was forgetting to specify,
> > queues are kernel threads, and that is quite
> > optimum expecially on SMP systems.
> > One big advantage is that conflicts possibilities are
> > (should be) less than minimal.
> >
> > Luigi
> >
> > On Tue, 7 Jan 2003, Larry McVoy wrote:
> >
> > > Date: Tue, 7 Jan 2003 16:30:50 -0800
> > > From: Larry McVoy <lm@bitmover.com>
> > > To: venom@sns.it
> > > Cc: Matthias Andree <matthias.andree@gmx.de>, linux-kernel@vger.kernel.org,
> > >      andre@linux-ide.org
> > > Subject: Re: Honest does not pay here ...
> > >
> > >
> > > > In very semplicistic words:
> > > > In 2.5/2.6 kernels, non GPL modules have a big
> > > > penalty, because they cannot create their own queue, but have to use a default
> > > > one.
> > >
> > > I may be showing my ignorance here (won't be the first time) but this makes
> > > me wonder if Linux could provide a way to do "user level drivers".  I.e.,
> > > drivers which ran in kernel mode but in the context of a process and had
> > > to talk to the real kernel via pipes or whatever.  It's a fair amount of
> > > plumbing but could have the advantage of being a more stable interface
> > > for the drivers.
> > >
> > > If you think about it, drivers are more or less open/close/read/write/ioctl.
> > > They need kernel privileges to do their thing but don't need (and shouldn't
> > > have) access to all the guts of the kernel.
> > >
> > > Can any well traveled driver people see this working or is it nuts?
> > > --
> > > ---
> > > Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm
> > >
> >
> > -
> > 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/
> >
>

Re: Honest does not pay here ...

[Andre Hedrick]

Luigi,

I have finally determined that nobody really gives a flying flip what you
do or what ship.  Nobody cares.

I have made more noise than a jackass in tin barn.

Trying to grab the attention of peer developers.
There are binary modules out there left and right.
Many are dirty, many are okay, many do not give a rip.
I have seen and know of lots of them.
The really bad ones I laugh in the face of the vendor.
Then there are the really slick ones, which I suspect can spoof anything.

I have asked for people to object, and only one person really has.

I have pissed off everyone.
While searching for the exact line of where things are black and white.
Nobody cares enough to help clear the air.
Nobody cares to pursue any of the existing binary modules.

I just do not get it anymore.
I guess I will shutup and do whatever.
Maybe I will get sued maybe I will not.

Regards,

Andre Hedrick
LAD Storage Consulting Group

Sorry for buggy everyone.
Sorry for asking first, instead of just doing it with thumb on nose.
Sorry most that I never found an answer.
Guess I need to listen to a lawyer.

On Wed, 8 Jan 2003 venom@sns.it wrote:

> 
> if I understand your point, a vendor could ask to the end user to apply a patch
> to the new kernels, so that modules infrastructure will be changed, and also non
> GPLed modules can create their own run queue.
> 
> 
> Yes, it is possible, because we are talking about open source (I mean a more
> generic definition instead of free-software, i.e. all the software that comes
> with source code). I would add, it's in the rules of the game.
> But developers for this patch have to be paid, and
> patch could create conflicts, and has to be maintained togheter with the
> binary only module (depends on costs).
> 
> To say the truth, I do not even expect end users to care if the modules is
> running with its own kernel threads in his own run queue, or it is using the
> defaul queue.
> 
> Anyway I found the runqueue concept, as it has been implemented, an
> equilibrate and factual solution to incentivate companies to GPL their code,
> and I was surprised that none (except a short allusion from you),
> in two threads took the opportunity to talk about a fact and a good point.
> 
> Luigi Genoni
> 
> 
> On Tue, 7 Jan 2003, Andre Hedrick wrote:
> 
> > Date: Tue, 7 Jan 2003 17:10:41 -0800 (PST)
> > From: Andre Hedrick <andre@linux-ide.org>
> > To: venom@sns.it
> > Cc: Larry McVoy <lm@bitmover.com>, Matthias Andree <matthias.andree@gmx.de>,
> >      linux-kernel@vger.kernel.org
> > Subject: Re: Honest does not pay here ...
> >
> >
> > Luigi,
> >
> > You forgot one thing.  None of us can control what the end user does.
> > If a vendor tells the enduser to alter the 2.5/2.6 kernel and recompile.
> > What are you going to do?
> >
> > Add a clause where the enduser can not change the source code or apply a
> > patch to do it for them?
> >
> > Funny, you lost your rights to do that w/ GPL, as did I.
> >
> > *sigh*
> >
> > Andre Hedrick
> > LAD Storage Consulting Group
> >
> > On Wed, 8 Jan 2003 venom@sns.it wrote:
> >
> > >
> > > well, I was forgetting to specify,
> > > queues are kernel threads, and that is quite
> > > optimum expecially on SMP systems.
> > > One big advantage is that conflicts possibilities are
> > > (should be) less than minimal.
> > >
> > > Luigi
> > >
> > > On Tue, 7 Jan 2003, Larry McVoy wrote:
> > >
> > > > Date: Tue, 7 Jan 2003 16:30:50 -0800
> > > > From: Larry McVoy <lm@bitmover.com>
> > > > To: venom@sns.it
> > > > Cc: Matthias Andree <matthias.andree@gmx.de>, linux-kernel@vger.kernel.org,
> > > >      andre@linux-ide.org
> > > > Subject: Re: Honest does not pay here ...
> > > >
> > > >
> > > > > In very semplicistic words:
> > > > > In 2.5/2.6 kernels, non GPL modules have a big
> > > > > penalty, because they cannot create their own queue, but have to use a default
> > > > > one.
> > > >
> > > > I may be showing my ignorance here (won't be the first time) but this makes
> > > > me wonder if Linux could provide a way to do "user level drivers".  I.e.,
> > > > drivers which ran in kernel mode but in the context of a process and had
> > > > to talk to the real kernel via pipes or whatever.  It's a fair amount of
> > > > plumbing but could have the advantage of being a more stable interface
> > > > for the drivers.
> > > >
> > > > If you think about it, drivers are more or less open/close/read/write/ioctl.
> > > > They need kernel privileges to do their thing but don't need (and shouldn't
> > > > have) access to all the guts of the kernel.
> > > >
> > > > Can any well traveled driver people see this working or is it nuts?
> > > > --
> > > > ---
> > > > Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm
> > > >
> > >
> > > -
> > > 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/
> > >
> >
> 

Re: Honest does not pay here ...

[Stephen Satchell]

At 03:05 AM 1/8/03 -0800, Andre Hedrick wrote:
>I have pissed off everyone.
>While searching for the exact line of where things are black and white.
>Nobody cares enough to help clear the air.
>Nobody cares to pursue any of the existing binary modules.

Well, Andre, you haven't pissed me off in any way, sir.  You have raised 
some very interesting questions, questions that need to be answered if 
Linux is going to continue to live in the real world.  Real world, as 
opposed to the Utopia (or Utopias) that some contributor here would like to 
see.

This is for the rest of you:

I'm not knocking the sincerity of those contributors who have made their 
views known on this subject, nor do I want to disabuse them of their 
dream.    I want them, though, to recognize the dream for what it is, goals 
that would be nice to achieve but not a reality no matter how much they may 
wish it so.  Goals that have merit, as long as they don't become a 
straitjacket to making Linux useful to its users.

The concept of a kernel "tainted" by binary-only modules was, as I recall 
the prior threads on the subject, was focused on preventing developers from 
"spinning their wheels" trying to debug a black box for which no source is 
available and which may have unintended and astonishing effects on the rest 
of the kernel.  In this goal, the Linux Developer Community has followed in 
the footsteps of Microsoft Corporation, in wanting to focus their support 
efforts on situations where the variables are minimized.

-->  The whole purpose of Microsoft's Windows Hardware Certification Lab 
(WHCL) process was to ensure that hardware and the drivers that come with 
them meet certain minimum performance and configuration parameters, 
reducing Microsoft's technical support triage efforts.

-->  The whole purpose of the "tainted" kernel indication was to ensure 
that a problem report involving black boxes indicate that black boxes are 
involved, reducing the Linux Developer Community's technical support triage 
efforts.

Sauce for the goose is sauce for the gander.

The contributors who champion "free (as in speech) software" must recognize 
that the concept of intellectual property is a global concept, not just the 
child of one country such as the United States.  Limiting customer choice 
by blocking closed-source binary-only drivers only serves to make Gnu/Linux 
(ok, Stallman?) less useful to our customers because it does eliminate a 
choice.  I applaud the goal of emphasizing open-source drivers where open 
source is possible.  Just as the holder of a hammer tends to look at all 
problems as nails, some of the contributors here appear to think  that 
open-source is the be-all and end-all -- but the real world of intellectual 
property royalties and cutthroat competition sometimes makes open source 
impractical or impossible.

I want to make this clear:  if the customer requirements are such that s/he 
need to use hardware with a closed-source driver, then it is the customer's 
choice to incorporate said hardware and drivers.  The problem that some 
contributors to this discussion on LKML are trying to create an environment 
that  is specifically intended to rob the customer of that choice in the 
pursuit of a dream, a dream that WILL force that customer to a different 
solution other than Linux.

That's bad for Linux, that's bad for GNU, that's bad for the customer the 
Linux user.

You DO believe that we should be looking out for the Linux user, don't you?

Educate.  Don't dictate.

OK, now the coffee should be ready, and I can medicate myself.

Stephen Satchell


-- 
The human mind treats a new idea the way the body treats a strange
protein:  it rejects it.  -- P. Medawar
This posting is for entertainment purposes only; it is not a legal opinion.

Re: Honest does not pay here ...

[Matthias Andree]

On Tue, 07 Jan 2003, Larry McVoy wrote:

> 
> > In very semplicistic words:
> > In 2.5/2.6 kernels, non GPL modules have a big
> > penalty, because they cannot create their own queue, but have to use a default
> > one.
> 
> I may be showing my ignorance here (won't be the first time) but this makes
> me wonder if Linux could provide a way to do "user level drivers".  I.e.,
> drivers which ran in kernel mode but in the context of a process and had
> to talk to the real kernel via pipes or whatever.  It's a fair amount of
> plumbing but could have the advantage of being a more stable interface
> for the drivers. 

Some parts of the kernel have opened up for user space, think the
user-space file system efforts as one example.

Re: Honest does not pay here ...

[Alan Cox]

On Wed, 2003-01-08 at 00:30, Larry McVoy wrote:
> 
> I may be showing my ignorance here (won't be the first time) but this makes
> me wonder if Linux could provide a way to do "user level drivers".  I.e.,
> drivers which ran in kernel mode but in the context of a process and had
> to talk to the real kernel via pipes or whatever.  It's a fair amount of
> plumbing but could have the advantage of being a more stable interface
> for the drivers. 

Its actually quite messy because level triggered interrupts create priority
handling problems and memory allocations create all sorts of amazing deadlocks

Re: Honest does not pay here ...

[Jesse Pollard]

On Tuesday 07 January 2003 06:30 pm, Larry McVoy wrote:
> > In very semplicistic words:
> > In 2.5/2.6 kernels, non GPL modules have a big
> > penalty, because they cannot create their own queue, but have to use a
> > default one.
>
> I may be showing my ignorance here (won't be the first time) but this makes
> me wonder if Linux could provide a way to do "user level drivers".  I.e.,
> drivers which ran in kernel mode but in the context of a process and had
> to talk to the real kernel via pipes or whatever.  It's a fair amount of
> plumbing but could have the advantage of being a more stable interface
> for the drivers.
>
> If you think about it, drivers are more or less
> open/close/read/write/ioctl. They need kernel privileges to do their thing
> but don't need (and shouldn't have) access to all the guts of the kernel.
>
> Can any well traveled driver people see this working or is it nuts?

The big problem is overhead.

The last successful user mode driver I used was in the old RSX-11
systems - all drivers were user mode.

The other place user mode drivers are used is in microkernel structures.

The problem is context switching time. If the hardware isn't designed to
support 10-20 simultaneous contexts, you must save/restore register sets
on each interrupt for the device.

If you split the driver into a kernel interface driver (the 
open/close/read/write/ioctl style) then you have a VERY limited time
for doing certain types of processing - consider the time delays that
would get imposed on audio synthesis - each segment must be encoded
by the driver before being sent to the kernel interface driver. The 
application then has to switch:
	appuser mode ->kernel->user mode driver->kernel mode
		interface->user mode driver->kernel->appuser mode
Before the application being able to resynchronize with the video.. which
would go through the same type of interface.

What Linux is using is more like a real time system. The tasklets/task queues
are more like a full featured RT system with priority queues. This allows a
fair amount of processing to be done by the driver without requiring heavy
handed context switching loads. What it appears to lack for a RT system is
a guaranteed interrupt latency.

In a microkernel envionment (where it can work) there need to be enough 
resources available to minimize the context switching - The Cray T3 used
basic Alpha processors (a LOT of them). The UNICOS kernel on top of the
microkernel distributed the load by puting only one or two drivers per
processor.

These drivers appear (I didn't get to see the source) to perform full context
switches for each interrupt/read/write/open/close/ioctl. The key here is that
the processor really doesn't have to do anything else. Cache memory remains
hot, and nothing is delayed.

User applications run on totally different CPUs (out of 1048 processors, 40
of them might be OS processors, out of the 40 there might be 20 that are 
filesystem/device drivers, the others handle user batch scheduling 
scheduling, resource allocation and  system calls. 8 to 10 additional ones
are used for "command" processors (not handling batch jobs) used for
complers, interactive access, and non-parallel utilties. The rest are
 "application processors" and are dedicated to batch and/or parallel programs.

I have never really seen a generic processor that could run user mode
drivers very well - even the PDP-11s could not do that well for certain
devices, and they only had 8 registers to save/restore.

I would think that user mode drivers would need (ideally):

1. multiple user register sets in hardware - at least (5 to 10).
2. near zero context switching - calling for the MMU to support (5 to 10) 
	simultaneous contexts.
3. use one control register to switch between user register sets and MMU
	contexts.
4. multiple cache memory modules ... 10 desirable, one per register set.
5. multiple processing levels (almost every processor has 2, Intel has 4)

The 5-10 register sets/MMU sets is based on:

1. disk driver
1. filesystem driver
1. video driver
1. keyboard driver
1. system call/user process

If more drivers are loaded/active then you would want more or you get into
scheduling collisions with context save/restore overhead. It would also
be desirable to have one for the system call/scheduler to eliminate that
overhead too, but IMHO that one can be shared with the user process.

Context switching time should be very nearly equivalent to a subroutine call
then - select the context, select the entry point, switch. Any parameter
passing could be almost the same as a subroutine parameter + a cache miss.
-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: Honest does not pay here ...

[Pavel Machek]

Hi!

> > In very semplicistic words:
> > In 2.5/2.6 kernels, non GPL modules have a big
> > penalty, because they cannot create their own queue, but have to use a default
> > one.
> 
> I may be showing my ignorance here (won't be the first time) but this makes
> me wonder if Linux could provide a way to do "user level drivers".  I.e.,
> drivers which ran in kernel mode but in the context of a process and had
> to talk to the real kernel via pipes or whatever.  It's a fair amount of
> plumbing but could have the advantage of being a more stable interface
> for the drivers. 

You don't need kernel mode to touch hw.

> If you think about it, drivers are more or less open/close/read/write/ioctl.
> They need kernel privileges to do their thing but don't need (and shouldn't
> have) access to all the guts of the kernel.
> 
> Can any well traveled driver people see this working or is it nuts?

Well, nbd was originally created just for that.

								Pavel

-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

User mode drivers (Honest does not pay here ...)

[Pete Zaitcev]

> I may be showing my ignorance here (won't be the first time) but this makes
> me wonder if Linux could provide a way to do "user level drivers".

It is a question often asked in comp.os.linux.development.system.
If performance penalties and security problems are no obstacle,
a lot of hardware can be serviced with a user mode driver, except
one that requires interrupts to operate. There is no way to deliver
an interrupt safely to the user mode, because a device specific
deactivation or ack-ing must be performed before interrupts are
enabled (on i386 at least). Other problems can be worked around
with ioperm and friends.

-- Pete

Re: User mode drivers (Honest does not pay here ...)

[Dmitry A. Fedorov]

On Tue, 7 Jan 2003, Pete Zaitcev wrote:

> > I may be showing my ignorance here (won't be the first time) but this makes
> > me wonder if Linux could provide a way to do "user level drivers".
> 
> It is a question often asked in comp.os.linux.development.system.
> If performance penalties and security problems are no obstacle,

Perfomance is slightly higher since there are no extra switching to
kernel and back to user space and parameters passing.

> a lot of hardware can be serviced with a user mode driver, except
> one that requires interrupts to operate. There is no way to deliver
> an interrupt safely to the user mode, because a device specific
> deactivation or ack-ing must be performed before interrupts are

Some devices (ISA based, at least) does not requires immediate interrupt
acknowledge, they are can be serviced from the user space with 
interrupts and they do.