--liOOAslEiF7prFVr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 16, 2001 at 07:51:33AM -0500, gabriel rosenkoetter wrote:
> On Fri, Mar 16, 2001 at 10:17:35AM +0100, Ignatios Souvatzis wrote:
> > teach the compiler a switch to always create long jumps/calls/loads,=20
> > and teach the LKM Makefiles to set it when on ppc.
>=20
> Ah, and here we have the problem, as a perfectly good gcc patch to
> enable long calls on PowerPC architectures exists (by Mike Stump
> of WindRiver/VxWorks), but has previously been rejected from
> inclusion in gcc. The hearsay I was given was that it "tried to
> do too much".[1]

Ah. I wasn't aware of those details.

> 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)? 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=20
time.

> I'm none too big on maintaining my own, private version of gcc,
> nor in supporting everyone else who wants to use LKMs under NetBSD
> on PowerPC architectures. (This is really something that ought just
> work, not something that developers ought to have to wrangle with
> just to get around to developing.)
>=20
> Oh, and I'm presuming the "right" way to make LKMs tick for powerpc-
> based ports goes something like this:
>=20
> 1) Have -mlong_calls and __attribute__ ((shortcall)) (or something
> with similar function) in the gcc you're using.
>=20
> 2) Tag all your internal-use-only function prototypes with
> __attribute__ ((shortcall)).
>=20
> 3) Build your LKM with -mlong_calls in CFLAGS in the Makefile.
>=20
> This puts the onus of accounting for the weirdness of long/short
> calls on the PowerPC on the LKM author. That is, LKM whose author
> doesn't write it with these things (presumably wrapped in a #ifdef
> __powerpc__) will (still) be broken for all the powerpc ports.

Well, it is perfectly reasonable to require something like -mlong_calls=20
for powerpc, and I guess we can even provide makefile templates or
something similar to that that. As for the __attribute__((shortcall)):

Thats just an optimization. IMO, this should be pointed out to the=20
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 :-)

> Is this the approach tech-kern thinks appropriate? If so, I'll see
> if I can get a gcc that will properly link LKMs on my powerpc box
> and submit patches to the appropriate place (presuming someone can
> tell me where that is), but I need to know that the method will
> even be accepted before I give up a few days of class work to do
> it.

Mmmm, Todd? Whats our official procedure?

> > Yes. Stop complaining, instead start coding *know*.
> > I guess you're aware this is a volunteer project?
>=20
> That was, of course, what I was implying by the "What can I do..."
> rephrasing.

Please forgive the harsh tone; I didn't detect the "real offer" part in
your original mail.

Regards,
	-is

--liOOAslEiF7prFVr
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: 2.6.i

iQEVAgUBOrIfnTCn4om+4LhpAQHjMgf/RsWjFKrzP+2WcFQfFa+Wls6yP8wu3ffk
mXOI6Rv2NzImTKdqAaDQi74UbkRUU1iAE/7TIia2xXd8x4k5pB6/GfOs6Qwk3qKr
Q1OAmZvZDoamdXv4c5/FMlH6AwKa7cDx2DT2412X5bBRnvEu/feEewSKYoHUAo8F
zFJSmTqMl0+NYb42MXF62kuaEip53xR6kk80+QmfveJdHKBEYNVh/fnnHC+x05vU
hGAOqTauqt754paQjgPYca1PzcD5qQ5FrHfi7adJDJ9+r26FBhi2RHauOBWynURg
9XSQYQfPh/maxebhXNIIHLG7tX12RiQ7dl445wFwtqeFSVH8SJ+vxg==
=6hZF
-----END PGP SIGNATURE-----

--liOOAslEiF7prFVr--