lkml.org 
[lkml]   [2000]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Announce] BKL shifting into drivers and filesystems - beware


Horst von Brand wrote:
>
> "Jeff V. Merkey" <jmerkey@timpanogas.com> said:
>
> [...]
>
> > I'm posting MANOS today -- there's an NT flavor DLL loader in the
> > sources if you want to look at it that's more like Microsoft's than the
> > one in Linux. NT uses something called a forwarder chain in the DLL
> > loader to handle this problem for dynanmically linked modules, though I
> > agree that the way they do it is an absolute hack. They allow the
> > loader to detect changed APIs and insert a "forwarder" function when the
> > external reference is resolved by the DLL loader -- this function
> > evenually calls the real function in kernel but if it's added a
> > parameter or something, it lets you slip in a forwarder function to
> > fixup the stack and munge the parms if someone altered an interface.
> > Something like this would allow us to go modular, and give you the
> > flexibility you want, but I agree it's still going to be a f_cking
> > nightmare to get this thing coordinated properly. You may want to
> > consider diverging after 2.4 and create a "modular" linux tree and see
> > how many of us bite on it (I certainly would).
>
> To maintain the "forwarders" sounds like as much (if not more) work than
> just fixing the errant modules in the first place. Plus you loose the
> flexibility of changing data structures and functions which are inlined and
> just #included, which is exactly the advantage Linus was talking about.


Guys!!!!!

Well, let's just wait until the monolithic kernel is 500MB in size and
requires 8GB of ram to load (or alternately the .config file requies an
8GB disk to hold it when you build Linux).

What I am hearing are no technical arguments, just "control, control,
control ...". What this would do is restrict folks from busting code
all the time by stopping people from changing interfaces all the time.
Linux has matured -- it's time it started heading this way. The
"freedom to bastardize" arguments were valid when Linux was growing up,
but it's an adult now, and how many ways can you re-organize a kernel?
Time to focus on making it more maintainable and shippable, which Linus
agreed with -- his issue is the best way to do this, and I'll certainly
defer so he can explore this for himself and come up with a way he feels
OK with. I understand the arguments, but sooner or later, we are going
to have to bite the bullet on this, or it's going to bite us.

Diverging a modular experimental tree to support this would be an easy
way to make the transition without disrupting the main stream kernel.

:-)

Jeff


> --
> Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
> Departamento de Informatica Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria +56 32 654239
> Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.625 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site