> "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 relea
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 clean
> 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 re
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 support.
> > > > 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 d
> 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.
That
> 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 fi
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
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 D
> > 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 kern
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 s
> "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, mo
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
the
- 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: L
- 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 s
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 rel
> Subject: Re: [LONG RANT] Re: Linux stifles innovation...
>
> - Original Message -
> From: "Jeff Garzik" <[EMAIL PROTECTED]>
> To: "Werner Almesberger" <[EMAIL PROTECTED]>
> Cc: "Henning P. Schmiedehausen" <[EMAIL PROTECTED]>
- 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 compla
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 po
"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 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 sh
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.
[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
> sai
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 g
[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
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 e
> 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 j
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 features
*** 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 an
[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 lock
41 matches
Mail list logo