[ros-kernel] Differences between ntdll and ntoskrnl Rtl functions

[Gunnar Dalsnes]

> > Most stuff are now merged, but still problems:
> >
> > Ntdll\rtl\registry.c->RtlQueryRegistryValues and
> > ntoskrnl\rtl\cm\rtlfunc.c->RtlQueryRegistryValues are very 
> different. The
> > ntdll version does correctly handle the environment 
> argument while the
> > ntoskrnl variant seem to have various other improvements. 
> Can one of them
> be
> > dumped or should i try to merge them?
> 
> Don't merge them! Kernel-mode doesn't use the environment 
> because it is a
> user-mode-only concept. Both versions have to stay the way they are.

I disagree. I mean we should merge them. It wont hurt for the kmode variant
to have code for the environment handling. Searching thru debug symbols for
windows ntoskrnl reveals that all the Rtl functions for dealing with
environment is in the kernel also, from this i conclude that windows also
use a common version for RtlQueryRegistryValues .

> 
> Btw, don't dare to merge the rangelist code! Both 
> implementations differ and
> I plan to use a lookaside list for the kernel-mode version.
> 

If they do not differ except for the memory allocators, i see no reason for
not merging them?!?

> 
> > Another problem:
> > First priority is to get all shared (ntdll/ntoskrnl) 
> components into rtl
> but
> > i would prefer to add every rtl component into the library. 
> This would
> have
> > worked fine if the linker would behave. Currently the 
> linker links in
> object
> > files without external references also, bloating both 
> ntoskrnl and ntdll
> > with unused and non-exported rtl routines. Is it possible 
> to fix this by
> > passing some parameter to the linker?
> 
> This is one of the reasons why I am strictly against sharing 
> source code.

Not in general I hope:-)

> Most linkers work object-file-based. This means they cannot 
> take a function
> from an object file and omit the unused ones they add all 
> code of an object
> file. That's why the runtime libaries use to implement a 
> single function per
> source file.

Our rtl is well distributed into function groups/files, so this will not be
a problem.

> 
> Another reason against shared code is the fact that a simple 
> 'make ntdll'
> won't build the shared code even if it has been modified. 
> This requires a
> 'make rtl' and 'make ntdll'. This effect caused me a lot of 
> trouble when I
> fixed the FAT12/16/32 format code for usetup because the 
> format code resides
> in vfatlib, so 'make vfatlib' must be run before running 
> 'make usetup'. IMO,
> this is not acceptable.
> 

This is not the libraries fault! It's the buildsystem that has to be fixed.

> The third reason against sharing source code this the fact that
> implementations may differ more or less. ExAllocatePool vs. 
> RtlAllocateHeap
> come to my mind. Adding wrapper functions to hide the 
> differences raise the
> complexity of the code without a real gain.

If you have a look at the library, you will see it's not complex at all.
I have preserved the ExAllocateXxx routines for memory allocation and added
wrappers for these in ntdll. In ntoskrnl, critical sections are wrapped as
fast mutexes. That's all that had to be done!
The merging prosess (dealing with different forks of code) was the hard
stuff!!

> 
> IMO, the disadvantages of sharing code outweigh the benefits.

Imo, the advantages of sharing code outweigh anything else! Forking code
just to make it "easy" is just wrong!

-Gunnar