On Mon, 7 Aug 2000, David A. Gatwood wrote:

> On Mon, 7 Aug 2000, Bill Studenmund wrote:
> 
> > I don't think lkm's work the way you are thinking. In NetBSD, an LKM has
> > access to ALL the symbols in the kernel, including all of the other
> > function calls. When it is working right (or done right), an LKM even has
> > access to symbols in other loaded lkm's.
> 
> Ah, but the question was, is it strictly necessary to have access to all
> the symbols directly, or are 90+ percent of the calls to only a few
> functions?

You're right that in practice only a few are called. :-)

For device drivers, it's just enough to hook into the dispatch table. For
vfs's, it's just enough to get the vfs registered.

It's just we could do something more like what solaris does and make more
system calls lkm-loaded. Right now there are a few lkm-specific syscalls
(210 through 219), but we could have more standard system calls
implimented via lkm's. Like most of the system-V stuff could be made
loadable. :-) Then we could have oodles of routines being called. :-)

> > The original proposal was to add something along the lines of
> > __attribute__ ((long-call)) to the prototypes of functions outside the lkm
> > so that the lkm's calls used a long-style jump or branch rather than a
> > short one. As we open up all of the functions in the kernel to LKM's, that
> > means that ALL of the prototypes need to have this __attribute__
> > ((long-call)) added. Only when we're compiling an lkm. :-)
> 
> True, but it seems like that's going to bload the headers a lot.

I agree! Strongly! :-) It would be a lot of bloat! :-)

> > I think adding something like -mlong-call and __attribute__ ((short-call))
> > would be the most efficient thing. :-)
> 
> Agreed.  Makes a lot of sense to go at it from that direction.

Agreed. :-)

Take care,

Bill