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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:15 EST