All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Edgar Hucek <hostmaster@ed-soft.at>
Cc: Jean Delvare <khali@linux-fr.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: New Linux Development Model
Date: Sat, 5 Nov 2005 14:44:09 +0100	[thread overview]
Message-ID: <20051105134409.GF5368@stusta.de> (raw)
In-Reply-To: <436CB162.5070100@ed-soft.at>

On Sat, Nov 05, 2005 at 02:19:30PM +0100, Edgar Hucek wrote:

> Hi.

Hi Edgar,

> Sorry for not posting my Name.
> 
> Maybe you don't understand what i wanted to say or it's my bad english.
> The ipw2200 driver was only an example. I had also problems with, vmware,
> unionfs...
> What i mean ist, that kernel developers make incompatible changes to the 
> header
> files, change structures, interfaces and so on. Which makes the kernel 
> releases
> incompatible.

you've already been given a pointer to the                               
Documentation/stable_api_nonsense.txt document in the kernel sources 
that explains these issues.

> There are several reasons why modules are not in the mainline kernel and 
> will never
> get there. So saying, bring modules to the kernel is wrong.

It's not wrong.

Every vendor of any kind of software will tell you A is supported and 
B is not supported.

It's a consensus among the Linux kernel developers that the Linux kernel 
does not support a stable API for external modules.

You don't have to like this decision, but stable_api_nonsense.txt 
explains it.

If you dislike this decision, there are several other operating systems 
whose vendors do offer a stable API for external modules.

> The right way would be to take care of defined interfaces, header files, 
> and so on.
> Otherwise you could only say the kernel 2.6.14 is only compatible to 
> 2.6.14.X and
> you there is no stable 2.6 mainline kernel.

The 2.6 is a stable kernel series in the sense that it doesn't crash 
very often.

2.6.14 is not API-compatible with 2.6.15.

But this has always been this way, the new development model only brings 
more API changes than the previous development models.

> I think it's also no task for the user, to search the net why external 
> driver xyz not
> works with a new kernel ( because of incompatibilties ). Basicly in new 
> kernel there
> could be a chance for the user a driver works better, because a bug was 
> fixed in the
> kernel.
>...

I do agree, this is not a task for the user.

It's a task for the vendors of the external modules.

> cu
> 
> ED.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2005-11-05 13:44 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-05  9:42 New Linux Development Model hostmaster
2005-11-05 10:29 ` Francois Romieu
2005-11-05 11:29 ` Jean Delvare
2005-11-05 13:19   ` Edgar Hucek
2005-11-05 13:44     ` Adrian Bunk [this message]
2005-11-05 13:47     ` Alistair John Strachan
2005-11-05 22:23       ` Mark Lord
2005-11-06  0:28         ` Alistair John Strachan
2005-11-05 14:34     ` Jesper Juhl
2005-11-05 14:48       ` Oliver Neukum
2005-11-05 14:56         ` Fawad Lateef
2005-11-05 15:28         ` Adrian Bunk
2005-11-06 10:52     ` jerome lacoste
2005-11-06 11:55       ` Edgar Hucek
2005-11-06 12:39         ` Adrian Bunk
2005-11-06 12:57         ` Bernd Petrovitsch
2005-11-06 17:38         ` Jean Delvare
     [not found]       ` <436DEEFC.4020301@ed-soft.at>
2005-11-06 13:43         ` jerome lacoste
2005-11-09  0:11           ` caszonyi
2005-11-09  0:23             ` Con Kolivas
2005-11-09  7:00               ` Diego Calleja
2005-11-09 12:30             ` jerome lacoste
2005-11-09 14:03               ` caszonyi
2005-11-09 15:45                 ` Marcos Marado
2005-11-06 16:50       ` John Carlson
2005-11-06 18:17     ` Bernd Petrovitsch
2005-11-09  0:16       ` caszonyi
2005-11-06 15:22 ` Jim Nance
2005-11-06 16:55   ` John Carlson
  -- strict thread matches above, loose matches on Subject: below --
2005-11-09  1:47 Ian Kumlien
2005-11-09 11:08 ` Marcos Marado
2005-11-09 11:30   ` Ian Kumlien
2005-11-09 12:03     ` Wed, 9 Nov 2005 13:03:07 +0100
2005-11-09 15:49       ` Ian Kumlien
2005-11-09 15:58         ` Al Viro
2005-11-09 16:32           ` Ian Kumlien
2005-11-09 12:37     ` Marcos Marado
2005-11-09 16:01       ` Ian Kumlien
2005-11-10  0:55         ` Alistair John Strachan
2005-11-10 15:10           ` Mark Lord
2005-11-10 19:29             ` Alistair John Strachan
2005-11-10 19:47               ` Ian Kumlien
2005-11-09 19:05   ` Bill Davidsen
2005-11-09 20:10     ` Marcos Marado
2005-11-10  0:57       ` Alistair John Strachan
2005-11-10 20:08         ` Bill Davidsen
2005-11-10 20:21           ` Alistair John Strachan
2005-11-12 13:45       ` Bill Davidsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051105134409.GF5368@stusta.de \
    --to=bunk@stusta.de \
    --cc=hostmaster@ed-soft.at \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.