lkml.org 
[lkml]   [1999]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A module bug in 2.2.1?
Alan Cox wrote:
>
> > the 2.1.45 relase. Thereafter RedHat fucked them up, without even giving
> > me
> > a single notice. I can assure you that I have never coded something
> > that stiupid into it...
>
> Lies like that deserve a direct response.

Go and just ask Richard Henderson please.

> > - Why the hell is there something like MODVERSIONS --- that's just
> > giving you a placebo of upgrade security --- nothing more.
>
> Almost all incompatibilities get caught by this. The alternative is to

You are naming the problem yourself: "Almost".

> > - Why the hell do we handle pure object files instead of some
> > 'prelinked'
> > simple special purpose module object format. All standard kernel symbols
> > could be resolved by depmod without even calling the kernel itself back.
>
> Tools dear boy, Tools. I can objdump pure object files. I can use libbfd
> to handle them and symbol resolution. I don't have to write my own half
> baked solution for it.

If you would implement the prelinker as just another object format for
the GNU ld you would have all those tools tools tools just for free you
are
screaming after.

> > - Why the hell do we store the modules in the file system instead of a
> > special purose database (read: single file), which would facilitate it
> > to load them from a contignous block area on the disk really in front of
> > the init process. (The system map should be stored at the same place.)
>
> Because
> a) I want to be able to use standard tools on them

No you are just telling excuses for coding and design lazyness...

--Marcin

-
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:50    [from the cache]
©2003-2011 Jasper Spaans