Matthew Dillon wrote:
> :
> :I have a problem with this portion of the smp-patch-02.diff:
> :
> :Index: sys/lock.h
> :===================================================================
> :RCS file: /home/ncvs/src/sys/sys/lock.h,v
> :retrieving revision 1.16
> :diff -u -r1.16 lock.h
> :--- lock.h 1999/08/28 00:51:50 1.16
> :+++ lock.h 1999/11/18 08:22:37
> :@@ -208,4 +208,15 @@
> : #endif /* NCPUS == 1 */
> : #endif /* !SIMPLELOCK_DEBUG */
> :
> :+#ifdef SMP
> :+void get_mplock(void);
> :+void rel_mplock(void);
> :...
>
> Yes, that's actually not part of my patch set, but Alfred's, thanks
> for pointing it out! I accidently left it in there. It will not be part
> of the commit.
>
> That said, I'm not sure it's possible to make modules SMP-unaware
> unless we commit ourselves to having dummy mplock and simplelock
> procedures for non-SMP kernels. i.e. real procedures that are empty
> instead of a #define to non-existance.
>
> Without a kernel device driver or module API, we are pretty much S.O.L.
> with modules already - if you don't recompile your modules when you
> recompile the kernel, bad things often happen.
Yes, it's a big nasty problem for how to do this efficiently.. The main
thing I have in mind though is when we hit 4.x-RELEASE where each has a
fixed set of binary interfaces... A lot of folks *do* run the CD release
verbatum without changes, and it would be nice (if possible) to enable a
single high level module to work on both SMP and non-SMP 4.x-RELEASE
generic kernels.
Anyway, it's just a goal that I thought it'd be worth re-mentioning.. ie:
don't make SMP vs non-SMP differences if it's reasonably possible to avoid.
Making some stub functions is easy..
BTW; are you aware of the Digital approach to this? If you call a stub
function when smp isn't present, it modifies the calling code to NOP the
call. We can do some nifty things along these lines with the loader at
load time, it's ideally positioned to do this, so that the calls to the
stubs never happen in the first place, assuming it's worth going that far.
That won't help the register allocation distruptions but may be better than
nothing.
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message