> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Jeff> FWIW, -every single- Windows driver source code I've seen
Jeff> has been bloody awful. Asking them to release that code
Jeff> would probably result in embarrassment. Same reasoning why
Jeff> many companies won't
"Jeff" == Jeff Garzik [EMAIL PROTECTED] writes:
Jeff FWIW, -every single- Windows driver source code I've seen
Jeff has been bloody awful. Asking them to release that code
Jeff would probably result in embarrassment. Same reasoning why
Jeff many companies won't release
Mikulas Patocka <[EMAIL PROTECTED]> writes:
> Imagine that there is specification of mark_buffer_dirty. That
> specification says that
> 1. it may not block
> 2. it may block
>
> In case 1. implementators wouldn't change it to block in stable kernel
> relese because they don't
On Mon, 19 Feb 2001 10:58:36 -0500 (EST),
"Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
>I was unable to use the new kernel because the drivers I need for
>`initrd` all had undefined symbols relating to some high memory stuff.
>This, in spite of the fact that I did:
>
>cp .config ..
>make
> One of these things must happen:
>
> a. follow the specification, even if that makes code slow and contorted
> b. change the specification
> c. ignore the specification
> d. get rid of the specification
>
> Option "a" will not be accepted around here. Sorry.
It should be followed in stable
Mikulas Patocka writes:
> Imagine that there is specification of mark_buffer_dirty. That
> specification says that
> 1. it may not block
> 2. it may block
>
> In case 1. implementators wouldn't change it to block in stable kernel
> relese because they don't want to violate the
On Mon, 19 Feb 2001, Henning P . Schmiedehausen wrote:
> And yes, there _is_ IMHO a difference in telling someone on LKM,
> especially someone without deeper knowledge that is lookin for help:
>
> "You're using a non-open source driver, so we can't help you. Please
> ask your vendor for
> > > > I suspect part of the problem with commercial driver support on Linux is that
> > > > the Linux driver API (such as it is) is relatively poorly documented
> > >
> > > In-kernel documentation, agreed.
> > >
> > > _Linux Device Drivers_ is a good reference for 2.2 and below.
> >
> > And
> One of the latest module killers was the opaque type, "THIS_MODULE",
> put at the beginning of struct file_operations. This happened between
> 2.4.0 and 2.4.x. So it's not "imagination".
No it happened before 2.4.0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Mon, 19 Feb 2001, Mikulas Patocka wrote:
> > > I suspect part of the problem with commercial driver support on Linux is that
> > > the Linux driver API (such as it is) is relatively poorly documented
> >
> > In-kernel documentation, agreed.
> >
> > _Linux Device Drivers_ is a good reference
On Mon, 19 Feb 2001, Richard B. Johnson wrote:
> One of the latest module killers was the opaque type, "THIS_MODULE",
> put at the beginning of struct file_operations. This happened between
> 2.4.0 and 2.4.x. So it's not "imagination".
Richard,
Time to join the rest of us on planet Earth.
> So, is it legal to put changes to a twin licensed driver in the Linux
> kernel tree back into the same driver in the BSD tree?
Just make it plain that patches and contributions to that driver must be
dual licensed. We have several shared drivers with BSD and most people seem
happy that small
On Mon, 19 Feb 2001, Henning P . Schmiedehausen wrote:
> So, is it legal to put changes to a twin licensed driver in the Linux
> kernel tree back into the same driver in the BSD tree?
IANAL, but AIUI:
if the changes are made the copyright holder then they may do whatever
they want. (release
On Mon, 19 Feb 2001, Jeff Garzik wrote:
> On Mon, 19 Feb 2001, David Howells wrote:
> > I suspect part of the problem with commercial driver support on Linux is that
> > the Linux driver API (such as it is) is relatively poorly documented
>
> In-kernel documentation, agreed.
>
> _Linux Device
> > I suspect part of the problem with commercial driver support on Linux is that
> > the Linux driver API (such as it is) is relatively poorly documented
>
> In-kernel documentation, agreed.
>
> _Linux Device Drivers_ is a good reference for 2.2 and below.
And do implementators of generic
On Mon, 19 Feb 2001, David Howells wrote:
> I suspect part of the problem with commercial driver support on Linux is that
> the Linux driver API (such as it is) is relatively poorly documented
In-kernel documentation, agreed.
_Linux Device Drivers_ is a good reference for 2.2 and below.
> and
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Jeff> On Mon, 19 Feb 2001, Werner Almesberger wrote:
>> Now what's at stake ? Look at the Windows world. Also there,
>> companies could release their drivers as Open Source. Quick, how
>> many do this ? Almost none. So, given the choice,
I suspect part of the problem with commercial driver support on Linux is that
the Linux driver API (such as it is) is relatively poorly documented and seems
to change almost on a week-by-week basis anyway. I've done my share of chasing
the current kernel revision with drivers that aren't part of
Henning P . Schmiedehausen wrote:
> No, I don't. I don't at all. But I prefer a more pragmatic approach to
> the developers and companies who don't.
I actually think it's good if we appear to be a little more "hard-liners"
than we really are. If companies assume that only open source will get
- Original Message -
From: "David Lang" <[EMAIL PROTECTED]>
To: "Nicholas Knight" <[EMAIL PROTECTED]>
Cc: "Jeff Garzik" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, February 19, 2001 3:36 AM
Subject: Re: [LONG RANT] Re
- Original Message -
From: "Jeff Garzik" <[EMAIL PROTECTED]>
To: "Nicholas Knight" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, February 19, 2001 3:47 AM
Subject: Re: [LONG RANT] Re: Linux stifles innovation...
> On Mon, 19 Feb 200
On Mon, Feb 19, 2001 at 05:07:02AM -0600, Jeff Garzik wrote:
> On Mon, 19 Feb 2001, Werner Almesberger wrote:
> > Now what's at stake ? Look at the Windows world. Also there, companies
> > could release their drivers as Open Source. Quick, how many do this ?
> > Almost none. So, given the choice,
Jeff Garzik wrote:
> FWIW, -every single- Windows driver source code I've seen has been
> bloody awful. Asking them to release that code would probably result in
> embarrassment.
Maybe a good analogy is that drivers are to hardware companies like
excrements are to living creatures: in order to
On Mon, Feb 19, 2001 at 11:53:14AM +0100, Werner Almesberger wrote:
> Henning P. Schmiedehausen wrote:
> Fine. So you've reinvented AIX, HP-UX, SCO, etc. The question is what
> you expect from Linux. After all, you strongly disagree with the main
> common denominator of Linux developers, that it
On Mon, 19 Feb 2001, Nicholas Knight wrote:
> From: "Jeff Garzik" <[EMAIL PROTECTED]>
> > FWIW, -every single- Windows driver source code I've seen has been
> > bloody awful. Asking them to release that code would probably result in
> > embarrassment. Same reasoning why many companies won't
ONG RANT] Re: Linux stifles innovation...
>
> - Original Message -
> From: "Jeff Garzik" <[EMAIL PROTECTED]>
> To: "Werner Almesberger" <[EMAIL PROTECTED]>
> Cc: "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>;
> <[EMAIL PR
- Original Message -
From: "Jeff Garzik" <[EMAIL PROTECTED]>
To: "Werner Almesberger" <[EMAIL PROTECTED]>
Cc: "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, February 19, 2001 3:07 AM
Subject: Re:
On Mon, 19 Feb 2001, Werner Almesberger wrote:
> Now what's at stake ? Look at the Windows world. Also there, companies
> could release their drivers as Open Source. Quick, how many do this ?
> Almost none. So, given the choice, most companies have defaulted to
> closed source. Consistently
Henning P. Schmiedehausen wrote:
> Company wants to make at least some bucks with their
> products and the driver is part of the product. So they may want to
> release a driver which is "closed source".
Usually, the driver doesn't play a large role in product differentiation,
at least not in a
"Henning P. Schmiedehausen" wrote:
>
> _BUT_ all these people that want to use Linux ask sometimes for help
> outside their vendor contracts, they get told exactly this: "Go away
> where. You're not using the "one true source from kernel.org". They're
> more locked it with their "open software"
"Henning P. Schmiedehausen" wrote:
_BUT_ all these people that want to use Linux ask sometimes for help
outside their vendor contracts, they get told exactly this: "Go away
where. You're not using the "one true source from kernel.org". They're
more locked it with their "open software" than
Henning P. Schmiedehausen wrote:
Company wants to make at least some bucks with their
products and the driver is part of the product. So they may want to
release a driver which is "closed source".
Usually, the driver doesn't play a large role in product differentiation,
at least not in a
On Mon, 19 Feb 2001, Werner Almesberger wrote:
Now what's at stake ? Look at the Windows world. Also there, companies
could release their drivers as Open Source. Quick, how many do this ?
Almost none. So, given the choice, most companies have defaulted to
closed source. Consistently
- Original Message -
From: "Jeff Garzik" [EMAIL PROTECTED]
To: "Werner Almesberger" [EMAIL PROTECTED]
Cc: "Henning P. Schmiedehausen" [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, February 19, 2001 3:07 AM
Subject: Re: [LONG RANT] Re: Linux stifles i
and worth them spending their money there.
David Lang
On Mon, 19 Feb
2001, Nicholas Knight wrote:
Date: Mon, 19 Feb 2001 03:28:56 -0800
From: Nicholas Knight [EMAIL PROTECTED]
To: Jeff Garzik [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [LONG RANT] Re: Linux stifles innovation
On Mon, 19 Feb 2001, Nicholas Knight wrote:
From: "Jeff Garzik" [EMAIL PROTECTED]
FWIW, -every single- Windows driver source code I've seen has been
bloody awful. Asking them to release that code would probably result in
embarrassment. Same reasoning why many companies won't release
On Mon, Feb 19, 2001 at 11:53:14AM +0100, Werner Almesberger wrote:
Henning P. Schmiedehausen wrote:
Fine. So you've reinvented AIX, HP-UX, SCO, etc. The question is what
you expect from Linux. After all, you strongly disagree with the main
common denominator of Linux developers, that it be
Jeff Garzik wrote:
FWIW, -every single- Windows driver source code I've seen has been
bloody awful. Asking them to release that code would probably result in
embarrassment.
Maybe a good analogy is that drivers are to hardware companies like
excrements are to living creatures: in order to
On Mon, Feb 19, 2001 at 05:07:02AM -0600, Jeff Garzik wrote:
On Mon, 19 Feb 2001, Werner Almesberger wrote:
Now what's at stake ? Look at the Windows world. Also there, companies
could release their drivers as Open Source. Quick, how many do this ?
Almost none. So, given the choice, most
- Original Message -
From: "Jeff Garzik" [EMAIL PROTECTED]
To: "Nicholas Knight" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, February 19, 2001 3:47 AM
Subject: Re: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Nicholas Knight wrote:
Henning P . Schmiedehausen wrote:
No, I don't. I don't at all. But I prefer a more pragmatic approach to
the developers and companies who don't.
I actually think it's good if we appear to be a little more "hard-liners"
than we really are. If companies assume that only open source will get
them
I suspect part of the problem with commercial driver support on Linux is that
the Linux driver API (such as it is) is relatively poorly documented and seems
to change almost on a week-by-week basis anyway. I've done my share of chasing
the current kernel revision with drivers that aren't part of
"Jeff" == Jeff Garzik [EMAIL PROTECTED] writes:
Jeff On Mon, 19 Feb 2001, Werner Almesberger wrote:
Now what's at stake ? Look at the Windows world. Also there,
companies could release their drivers as Open Source. Quick, how
many do this ? Almost none. So, given the choice, most companies
On Mon, 19 Feb 2001, David Howells wrote:
I suspect part of the problem with commercial driver support on Linux is that
the Linux driver API (such as it is) is relatively poorly documented
In-kernel documentation, agreed.
_Linux Device Drivers_ is a good reference for 2.2 and below.
and
I suspect part of the problem with commercial driver support on Linux is that
the Linux driver API (such as it is) is relatively poorly documented
In-kernel documentation, agreed.
_Linux Device Drivers_ is a good reference for 2.2 and below.
And do implementators of generic kernel
On Mon, 19 Feb 2001, Jeff Garzik wrote:
On Mon, 19 Feb 2001, David Howells wrote:
I suspect part of the problem with commercial driver support on Linux is that
the Linux driver API (such as it is) is relatively poorly documented
In-kernel documentation, agreed.
_Linux Device Drivers_
On Mon, 19 Feb 2001, Henning P . Schmiedehausen wrote:
So, is it legal to put changes to a twin licensed driver in the Linux
kernel tree back into the same driver in the BSD tree?
IANAL, but AIUI:
if the changes are made the copyright holder then they may do whatever
they want. (release the
So, is it legal to put changes to a twin licensed driver in the Linux
kernel tree back into the same driver in the BSD tree?
Just make it plain that patches and contributions to that driver must be
dual licensed. We have several shared drivers with BSD and most people seem
happy that small
On Mon, 19 Feb 2001, Richard B. Johnson wrote:
One of the latest module killers was the opaque type, "THIS_MODULE",
put at the beginning of struct file_operations. This happened between
2.4.0 and 2.4.x. So it's not "imagination".
Richard,
Time to join the rest of us on planet Earth.
That
On Mon, 19 Feb 2001, Mikulas Patocka wrote:
I suspect part of the problem with commercial driver support on Linux is that
the Linux driver API (such as it is) is relatively poorly documented
In-kernel documentation, agreed.
_Linux Device Drivers_ is a good reference for 2.2 and
One of the latest module killers was the opaque type, "THIS_MODULE",
put at the beginning of struct file_operations. This happened between
2.4.0 and 2.4.x. So it's not "imagination".
No it happened before 2.4.0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
I suspect part of the problem with commercial driver support on Linux is that
the Linux driver API (such as it is) is relatively poorly documented
In-kernel documentation, agreed.
_Linux Device Drivers_ is a good reference for 2.2 and below.
And do implementators of
On Mon, 19 Feb 2001, Henning P . Schmiedehausen wrote:
And yes, there _is_ IMHO a difference in telling someone on LKM,
especially someone without deeper knowledge that is lookin for help:
"You're using a non-open source driver, so we can't help you. Please
ask your vendor for support."
Mikulas Patocka writes:
Imagine that there is specification of mark_buffer_dirty. That
specification says that
1. it may not block
2. it may block
In case 1. implementators wouldn't change it to block in stable kernel
relese because they don't want to violate the
One of these things must happen:
a. follow the specification, even if that makes code slow and contorted
b. change the specification
c. ignore the specification
d. get rid of the specification
Option "a" will not be accepted around here. Sorry.
It should be followed in stable releases.
On Mon, 19 Feb 2001 10:58:36 -0500 (EST),
"Richard B. Johnson" [EMAIL PROTECTED] wrote:
I was unable to use the new kernel because the drivers I need for
`initrd` all had undefined symbols relating to some high memory stuff.
This, in spite of the fact that I did:
cp .config ..
make clean
make
Mikulas Patocka [EMAIL PROTECTED] writes:
Imagine that there is specification of mark_buffer_dirty. That
specification says that
1. it may not block
2. it may block
In case 1. implementators wouldn't change it to block in stable kernel
relese because they don't want to
Henning P. Schmiedehausen writes:
> The matter with me is: "Vendors AAA ships its hardware product with a
> driver for i386/Linux". The driver may be closed source, but at least
> there _is_ a driver. Russell now says: "This is bad, because I can't use
> the driver for my ARM box. So the vendor
I wrote:
>The matter with me is: "Vendors AAA ships its hardware product with a
>driver for i386/Linux". The driver may be closed source, but at least
>there _is_ a driver. Russell now says: "This is bad, because I can't use
>the driver for my ARM box. So the vendor should ship no driver at
[EMAIL PROTECTED] (Felix von Leitner) writes:
>Thus spake Henning P . Schmiedehausen ([EMAIL PROTECTED]):
>> "If a company does not write a driver which works on all hardware
>> platforms in all cases and gives us the source, then it is better,
>> that the company writes no drivers at all."
*** Please don't reply directly to me, either via CC: or To:.
*** I'll pick up any replies via linux-kernel. Thanks.
Henning P . Schmiedehausen writes:
> Maybe not. But you can use this print engine API to pay anyone to
> write a driver for you. What you just said, is exactly my point. You
>
*** Please don't reply directly to me, either via CC: or To:.
*** I'll pick up any replies via linux-kernel. Thanks.
Henning P . Schmiedehausen writes:
Maybe not. But you can use this print engine API to pay anyone to
write a driver for you. What you just said, is exactly my point. You
said:
[EMAIL PROTECTED] (Felix von Leitner) writes:
Thus spake Henning P . Schmiedehausen ([EMAIL PROTECTED]):
"If a company does not write a driver which works on all hardware
platforms in all cases and gives us the source, then it is better,
that the company writes no drivers at all."
"If I
I wrote:
The matter with me is: "Vendors AAA ships its hardware product with a
driver for i386/Linux". The driver may be closed source, but at least
there _is_ a driver. Russell now says: "This is bad, because I can't use
the driver for my ARM box. So the vendor should ship no driver at
all.
Henning P. Schmiedehausen writes:
The matter with me is: "Vendors AAA ships its hardware product with a
driver for i386/Linux". The driver may be closed source, but at least
there _is_ a driver. Russell now says: "This is bad, because I can't use
the driver for my ARM box. So the vendor
Jacob Luna Lundberg wrote:
>> Speaking as a Linux _USER_, if this happens, can I get said print
>> engine working on my ARM machines with these closed source drivers?
>> Can Alpha users get this print system working? Can Sparc uses
>> get it working? What? I can't? They can't? Well, its no
[Jacob Luna Lundberg]
> Just out of curiosity, why can't the specification be along the lines
> of a vendor data file saying ``if you want the printer to do x then
> say y'' and ``if the printer says x then it means y''. That ought to
> add a lot of functionality right there.
Think about it.
Thus spake Henning P . Schmiedehausen ([EMAIL PROTECTED]):
> "If a company does not write a driver which works on all hardware
> platforms in all cases and gives us the source, then it is better,
> that the company writes no drivers at all."
> "If I can't force a company to write a driver for
> Speaking as a Linux _USER_, if this happens, can I get said print
> engine working on my ARM machines with these closed source drivers?
> Can Alpha users get this print system working? Can Sparc uses
> get it working? What? I can't? They can't? Well, its no good to
> me nor them. You've
On Sat, Feb 17, 2001 at 01:37:58PM +, Russell King wrote:
> Henning P. Schmiedehausen writes:
> > But at least I would be happy if there would be a printing
> > engine that is entirely open source and all the printer vendors can
> > write a small, closed source stub that drives their printer
>Henning P. Schmiedehausen writes:
>> But at least I would be happy if there would be a printing
>> engine that is entirely open source and all the printer vendors can
>> write a small, closed source stub that drives their printer over
>> parallel port, ethernet or USB and give us all the
*** Please drop me from the CC: and To: lists before replying to this.
*** I do read linux-kernel, so there is no need to send me two copies
*** of your replies.
Henning P. Schmiedehausen writes:
> But at least I would be happy if there would be a printing
> engine that is entirely open source
[EMAIL PROTECTED] (Alan Cox) writes:
>> For example, if there were six different companies that marketed ethernet
>> drivers for the eepro100, you'd have a choice of which one to buy..perhaps
>> with different "features" that were of value to you. Instead, you have
>> crappy GPL code that
[EMAIL PROTECTED] (Alan Cox) writes:
For example, if there were six different companies that marketed ethernet
drivers for the eepro100, you'd have a choice of which one to buy..perhaps
with different "features" that were of value to you. Instead, you have
crappy GPL code that locks up
*** Please drop me from the CC: and To: lists before replying to this.
*** I do read linux-kernel, so there is no need to send me two copies
*** of your replies.
Henning P. Schmiedehausen writes:
But at least I would be happy if there would be a printing
engine that is entirely open source and
Henning P. Schmiedehausen writes:
But at least I would be happy if there would be a printing
engine that is entirely open source and all the printer vendors can
write a small, closed source stub that drives their printer over
parallel port, ethernet or USB and give us all the features, that
Speaking as a Linux _USER_, if this happens, can I get said print
engine working on my ARM machines with these closed source drivers?
Can Alpha users get this print system working? Can Sparc uses
get it working? What? I can't? They can't? Well, its no good to
me nor them. You've just
On Sat, Feb 17, 2001 at 01:37:58PM +, Russell King wrote:
Henning P. Schmiedehausen writes:
But at least I would be happy if there would be a printing
engine that is entirely open source and all the printer vendors can
write a small, closed source stub that drives their printer over
Thus spake Henning P . Schmiedehausen ([EMAIL PROTECTED]):
"If a company does not write a driver which works on all hardware
platforms in all cases and gives us the source, then it is better,
that the company writes no drivers at all."
"If I can't force a company to write a driver for
[Jacob Luna Lundberg]
Just out of curiosity, why can't the specification be along the lines
of a vendor data file saying ``if you want the printer to do x then
say y'' and ``if the printer says x then it means y''. That ought to
add a lot of functionality right there.
Think about it. A
Jacob Luna Lundberg wrote:
Speaking as a Linux _USER_, if this happens, can I get said print
engine working on my ARM machines with these closed source drivers?
Can Alpha users get this print system working? Can Sparc uses
get it working? What? I can't? They can't? Well, its no good to
81 matches
Mail list logo
