Subject: Re: Any resolution for LKM issues?
To: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
From: gabriel rosenkoetter <gr@eclipsed.net>
List: tech-kern
Date: 03/16/2001 09:36:32
On Fri, Mar 16, 2001 at 03:13:53PM +0100, Ignatios Souvatzis wrote:
> > Is it necessary to separate out just the bits of that patch we
> > actually want (implementing the -mlong_calls flag on powerpc for
> > gcc, preferably allowing __attribute__ ((shortcall)) so that
> > prototypes used entirely internally in the LKM can be tagged with it
> > so as not to waste 3 or more instructions where one would have been
> > sufficient)?
Assuming the below is a response just to that question, what about
this?
-mlong-calls is one thing, but I don't *think* the gcc we're using
even has a shortcall attribute. I wish I knew the piece of
documentation from which to find that out, but, fwiw, changing my
code to use __attribute ((shortcall)) where it had use longcall
(blatantly wrong, but whatever), I get:
cc -D_LKM -D_KERNEL -I/sys -c miscmod.c
miscmod.c: In function `miscmod_handle':
miscmod.c:95: warning: `shortcall' attribute directive ignored
... which makes me think that shortcall doesn't actually exist. But
I could be completely wrong, as always. :^>
(The original behemoth patch from the gcc mailing list even
automatically generated shortcalls when referencing the something in
the same code block under -mlong-call... but this seems to be part
of the excessiveness that led to it's not being commited to gcc. Go
figure.)
> > If so, can it be committed to a NetBSD-maintained
> > version of gcc (say, in the toolchain), or will it have to go
> > through gcc channels?
> Well, I'm not our toolchain maintainer... but I guess, both at the same
> time.
Sounds good.
> Well, it is perfectly reasonable to require something like -mlong_calls
> for powerpc, and I guess we can even provide makefile templates or
> something similar to that that.
Perhaps even in the /usr/share/lkm examples, from which I'm working?
:^>
> As for the __attribute__((shortcall)):
>
> Thats just an optimization. IMO, this should be pointed out to the
> knowledgable developer in some documentation, but is not really
> necessary. When in doubt, not using it is fine (and on the secure
> side; you know, an LKM *might* be > 64MB in size itself, although
> this is unlikely :-)
None too sure I'd want to sit around while it loaded either... ;^>
Again, probably belongs in a comment or a README somewhere in
/usr/share/lkm.
> Please forgive the harsh tone; I didn't detect the "real offer" part in
> your original mail.
No trouble. Forgive the tone of my response.
(I got a little weary of saying, "I will do this, tell me where to
start," in the original fracas over this. ;^>)
~ g r @ eclipsed.net