Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Nov 1999 19:05:51 -0800 (PST)
From:      Matthew Jacob <mjacob@feral.com>
To:        Julian Elischer <julian@whistle.com>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Threads stuff
Message-ID:  <Pine.BSF.4.05.9911201904580.6541-100000@semuta.feral.com>
In-Reply-To: <Pine.BSF.4.10.9911201853440.6767-100000@current1.whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> > 
> > Sure- that's kernel stuff, but it doesn't really work much in the area I
> > would be interested, namely making interrupt and other kernel threads
> > (e.g., for CAM device inventory management) for all drivers that could use
> > them (an interrupt thread per interrupt entry point is not unreasonable),
> > replacing all spl type locking with mutex_init (based on device interrupt
> > levels) and mutex_enter/mutex_exit usages, perhaps replacing sleep/wakeup
> > which is a per-process thingie with cv_wait/cv_signal.. you know, that
> > kinda low level kernel I/O stuff- more nuts and bolts and less
> > theoretical. When the discussion gets around to these things and policies
> > about whether SMP safe and SMP-unsafe drivers can coexist, then I'll be
> > more than happy to waste everyone's time with my opinions.
> 
> But it's all inter-related.. The KSE allocator would be the same
> KSE allocator that would be used to innitially allocate KSEs for
> interrupt handling. (My secret agenda starts to show). My aim is to
> get the BSDI "lazily evaluated threads" interrupt scheme. however the
> threads they would be evaluating to would be the same KSEs that would
> be allocated to the User thread scheme.. 
> 
> "A thread is a thread is a thread"
> 
> Believe me my heart is in the "low level more nuts and bolts". I just see
> a convergence of needs here.
> 
> We certainly need someone to help with the KSEs and specifically the Mutexy
> stuff. That should be quite applicable to both ends..

Okay. I'll start to pay more attention. Sorry if I was OTL....

-matt







To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9911201904580.6541-100000>