public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Dalecki <dalecki@evision-ventures.com>
To: "David S. Miller" <davem@redhat.com>
Cc: arjanv@redhat.com, rgooch@ras.ucalgary.ca, linux-kernel@vger.kernel.org
Subject: Re: kbuild 2.5 is ready for inclusion in the 2.5 kernel
Date: Thu, 02 May 2002 19:42:05 +0200	[thread overview]
Message-ID: <3CD17A6D.1040809@evision-ventures.com> (raw)
In-Reply-To: <3CD15CFA.1090208@evision-ventures.com>	<20020502132552.G8073@devserv.devel.redhat.com>	<3CD16F03.9090900@evision-ventures.com> <20020502.104817.06390889.davem@redhat.com>

Uz.ytkownik David S. Miller napisa?:
>    From: Martin Dalecki <dalecki@evision-ventures.com>
>    Date: Thu, 02 May 2002 18:53:23 +0200
> 
>    And then think about the fact that they are able to even *patch*
>    running kernels. There is no way I can be convinced that the whole
>    versioning stuff is neccessary or a good design for any purpose.
> 
> Hint: they never changes their ABIs for drivers.  This is why
> they can't fix several large scale bugs in their OS.  When the
> fix would break every third party Solaris driver on the planet
> they simply don't do the fix until the next major relase of the
> OS.

Yes I know. But my main point is that they maintain the
whole module symbol and dependency data entierly in user space
and MODULEVERSION in the *linux kernel*, just simply isn't worth the
trouble. Similarly the whole Tainted not tained MODULE_AUTHOR
and so on information simply shouldn't me maintained
in precious kernel RAM space.

Information about module dependencies does get resolved at
the proper level: not centralized in a single one Makefile
alike repository but by an *.conf file placed alongside of it.
The module objects them-self look very much like a simple *stripped*
ELF shared objects and don't contain any hack-in of string arrays
in the .text segment just to provide data which can be trivially
reconstructed and maintained in user space. Module request handling for hot
pluggable devices for example is done entierly inside user
space and so on...

Version consistency get's handled at the proper level - namely
the file packaging. Once and not repeatedly during every time
a particular module get's loaded and so on... And then there is
simple late kernel binding. After all having a messed up /kernel
dir is not a single bit more dangerous then just having a
trashed vmlinuz file.

Overall even the fact aside that they have a much stronger policy
about releases, the overall design is much cleaner then on the
linux side of the world.

Gosh - the whole /devices file-system is an old hat for Solaris.


  reply	other threads:[~2002-05-02 18:44 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-01 14:23 kbuild 2.5 is ready for inclusion in the 2.5 kernel Keith Owens
2002-05-02 15:17 ` Denis Vlasenko
2002-05-02 10:38   ` tomas szepe
2002-05-02 12:21     ` Keith Owens
2002-05-02 12:49       ` Martin Dalecki
2002-05-02 14:26         ` Alan Cox
2002-05-02 13:32           ` Martin Dalecki
2002-05-02 14:54             ` Kai Germaschewski
2002-05-02 15:17             ` Alan Cox
2002-05-05  9:43               ` Mike Fedyk
2002-05-05 10:16                 ` Keith Owens
2002-05-02 15:21             ` Arjan van de Ven
2002-05-02 15:59               ` Richard Gooch
2002-05-02 15:36                 ` Martin Dalecki
2002-05-02 17:15                   ` Alan Cox
2002-05-02 16:30                     ` Martin Dalecki
2002-05-02 18:20                       ` Alan Cox
2002-05-02 17:25                   ` Arjan van de Ven
2002-05-02 16:53                     ` Martin Dalecki
2002-05-02 17:48                       ` David S. Miller
2002-05-02 17:42                         ` Martin Dalecki [this message]
2002-05-02 19:11                           ` Alan Cox
2002-05-02 18:22                             ` Martin Dalecki
2002-05-02 18:49                             ` David S. Miller
2002-05-02 18:33                       ` Alan Cox
2002-05-02 14:24       ` Kai Germaschewski
2002-05-02 15:18         ` David Woodhouse
2002-05-02 15:40           ` Kai Germaschewski
2002-05-02 23:40             ` Keith Owens
2002-05-02 23:25               ` Martin Dalecki
2002-05-03 14:48               ` Kai Germaschewski
2002-05-03 15:45                 ` Keith Owens
2002-05-02 15:19         ` Alan Cox
2002-05-02 22:57           ` Pavel Machek
2002-05-03  8:33             ` Vikram
2002-05-03 12:07               ` Keith Owens
2002-05-18  1:14                 ` Andrea Arcangeli
2002-05-18  1:33                   ` Dave Jones
2002-05-18  3:06                     ` Oliver Xymoron
2002-05-18 12:28                     ` [PATCH] move jiffies from sched.h to it's own jiffies.h Tim Schmielau
2002-05-19 22:33                       ` Tim Schmielau
2002-05-20  2:32                       ` Rusty Russell
2002-05-18  2:12                   ` kbuild 2.5 is ready for inclusion in the 2.5 kernel Gerhard Mack
2002-05-18  2:13                   ` Keith Owens
2002-05-18  2:30                     ` Andrea Arcangeli
2002-05-20  2:38                     ` Miles Bader
2002-05-02 21:34       ` tomas szepe
2002-05-02 21:42         ` Dave Jones
2002-05-03  1:19           ` John Covici
2002-05-03  1:33             ` Keith Owens
2002-05-03  1:39               ` tomas szepe
2002-05-03  2:31             ` Alexander Viro
2002-05-03  3:21               ` Davide Libenzi
2002-05-02 21:42         ` Alexander Viro
2002-05-02 23:25           ` tomas szepe
2002-05-03 21:05           ` Mark H. Wood
2002-05-04 13:58             ` Kurt Wall
2002-05-06  1:54             ` Mike Fedyk
2002-05-02 22:54 ` Pavel Machek
2002-05-03  9:00   ` Keith Owens
2002-05-03  4:17 ` Randy.Dunlap
2002-05-03  5:02   ` Keith Owens
2002-05-03  6:32     ` Randy.Dunlap
2002-05-03 10:06     ` Gerd Knorr
2002-05-03 10:42       ` Keith Owens
2002-05-03 12:05         ` Gerd Knorr
2002-05-03 13:31           ` Keith Owens
2002-05-04  6:44         ` Paul Mackerras
2002-05-04  8:03           ` Paul Mackerras
2002-05-06  0:42             ` Mike Fedyk
2002-05-06  4:07               ` Paul Mackerras
2002-05-04  9:03           ` Keith Owens
2002-05-04  9:38             ` Russell King
2002-05-04 10:33             ` Paul Mackerras
2002-05-04 11:49               ` Keith Owens
2002-05-06  8:40                 ` Gerd Knorr
2002-05-07  4:14                   ` Keith Owens
2002-05-04 15:30               ` Richard Gooch
2002-05-05 17:23 ` Urban Widmark
2002-05-05 23:36   ` Keith Owens
2002-05-06 11:33     ` Urban Widmark
2002-05-06 23:54       ` Keith Owens
2002-05-06 10:54 ` Alex Riesen
2002-05-08  2:54   ` Keith Owens
2002-05-08 17:25     ` Alex Riesen
2002-05-09  0:10       ` Keith Owens
2002-05-09  0:55         ` Daniel Jacobowitz
2002-05-09  1:44           ` Keith Owens
  -- strict thread matches above, loose matches on Subject: below --
2002-05-05 16:42 Dan Kegel
2002-05-05 23:44 ` Keith Owens
2002-05-06  0:02   ` Dan Kegel
2002-05-06  0:40     ` Keith Owens
2002-05-06 15:38 ` Alan Cox
2002-05-06 15:33   ` Tomas Szepe
     [not found] <cs.lists.linux-kernel/18740.1020729269@ocs3.intra.ocs.com.au>
2002-05-07 23:48 ` Ion Badulescu
2002-05-08  0:10   ` Keith Owens
2002-05-08  0:37     ` Alan Cox
2002-05-08  0:34       ` Keith Owens

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=3CD17A6D.1040809@evision-ventures.com \
    --to=dalecki@evision-ventures.com \
    --cc=arjanv@redhat.com \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgooch@ras.ucalgary.ca \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox