Subject: RE: Any resolution for LKM issues?
To: 'Bill Studenmund' <firstname.lastname@example.org>
From: Greg Kritsch <email@example.com>
Date: 03/16/2001 13:49:58
Option 3: have the module loader change the relative branch instructions to
absolute branch instructions, in place, since the entire kernel is reachable
by an absolute branch instruction. This would be nicely efficient, too.
Again, just throwing out ideas.
Oh, and point taken that it's 4 instructions, not 3, for a long call.
> -----Original Message-----
> From: Greg Kritsch [mailto:firstname.lastname@example.org]
> Sent: Friday, March 16, 2001 1:43 PM
> To: 'Bill Studenmund'; Wolfgang Solfrank
> Cc: email@example.com; firstname.lastname@example.org; email@example.com
> Subject: RE: Any resolution for LKM issues?
> I'm going to reiterate my point of view for fun, mainly
> because it doesn't
> involve changing the compiler, just all the .h files from the kernel.
> If you added a macro, say, LKMCALL, to the end of every
> kernel function
> prototype, and then, when compiling an LKM, defined it to be
> ((longcall))", and otherwise left it as nothing, calls from
> LKMs to the real
> kernel would be done as inefficient, 3 instruction long calls, and
> everything else would be done with efficient, 1 instruction branches.
> This would fix the problem for all architectures that have
> LKM trouble due
> to limited branch range.
> Now, someone has reported a problem with compiler builtin
> functions. I
> haven't looked into that problem, so maybe some additional fixing is
> required there.
> The second best solution, in my opinion, hasn't been
> expressed yet. What if
> some piece of code, say the linker, took any branch target
> that was too far
> away and changed it to a branch to a little stub of code that
> does a long
> call? Perhaps this could even be integrated with the module
> loading tool
> rather than the linker, for now.
> I know NetBSD is all about machine independance and portability, but I
> believe in efficiency as well. This approach prevents us
> from having to
> deal with using inefficient long calls all over the place unless we
> explicitly ask the compiler not to use them (the shortcall
> attribute). But
> all the .h files do need to change.
> No, I'm not volunteering. I don't believe in LKMs. Just making the
> > -----Original Message-----
> > From: Bill Studenmund [mailto:firstname.lastname@example.org]
> > Sent: Friday, March 16, 2001 1:20 PM
> > To: Wolfgang Solfrank
> > Cc: email@example.com; firstname.lastname@example.org; email@example.com
> > Subject: Re: Any resolution for LKM issues?
> > On Fri, 16 Mar 2001, Wolfgang Solfrank wrote:
> > > Minor nit: it's segment 0 for the kernel code and segment E
> > for LKMs.
> > Ahhh.. Thanks. I forgot exactly which ones it was. I knew
> > they were more
> > than 32 MB apart.
> > > Well, yes, that's an unfortunate side effect of the ppc
> > kernel layout:
> > >
> > > While running kernel code, all but segments D & E are
> > mapped 1:1 between
> > > virtual and real addresses. This mapping is totally
> > invisible to uvm.
> > >
> > > The kernel text/data/bss isn't part of what memory
> management calls
> > > "kernel virtual memory", i.e. the address range
> accessible by kernel
> > > virtual addresses known to uvm (which happens to be in segment E).
> > >
> > > The kernel itself just happens to live somewhere in low
> > core and due to
> > > the above 1:1 mapping can be accessed easily. Any real
> memory that
> > > isn't occupied by the kernel is managed by uvm, so we
> cannot easily
> > > allocate contiguous real memory that is close enough to
> the kernel.
> > >
> > > Therefore (and in order to avoid implementing a totally
> > different LKM
> > > loading scheme) LKMs are allocated in the E segment (just
> > as any other
> > > memory that is allocated by the kernel).
> > Unfortunatly that means that we MUST change the toolchain to
> > get them to
> > work. :-(
> > > Hope this explains things a bit.
> > >
> > > PS: If you wondered about segment D in the above, it is used to
> > > access user virtual memory during copyin/copyout and friends.
> > Thanks!
> > Bill