[snip]
> - Why the hell is there any need to hold the symbol tables of the kernel
> in
> unswappable kernel memmory with the strings describing the call
> addresses there?
>
> - Why the hell is there something like MODVERSIONS --- that's just
> giving you a placebo of upgrade security --- nothing more.
>
> - 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.
> The prelinkage
> could be done esaly by using the bfd and objects libraries in a generic
> way,
> without the need of a special purpose ELF format reading library in the
> modutils themself.
>
> - 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.)
>
> I could continue but who cares anyway...
I suggest we take this discussion to linux-future; I think most of your
ideas are interesting. But they are not for the v2.2.x tree...
/David Weinehall
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
-
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/