Date: Sat, 20 Nov 1999 18:35:23 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Julian Elischer <julian@whistle.com> Cc: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, committers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Core responsibilities [was Re: PHK: "Shut up and go away quietly"] Message-ID: <Pine.BSF.4.05.9911201830060.6541-100000@semuta.feral.com> In-Reply-To: <Pine.BSF.4.10.9911201809100.6767-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > It did seem that the discussion was productive, but since it wasn't really > > my table, I didn't get involved. Now, if there's some talk about kernel > > threads, or more precisely, how a fully threaded kernel will need changes > > to the device I/O model, then I'm more interested. > > That's peculiar because teh first week was just discussing the goals. > from there we got to the fact that we need the following kernel > support. > > 1/ KSE's (kernel schedulable Entities that are separate from processes). > 2/ SUB-processes. (each with ONE OR MORE KSEs) > 3/ Processes (each with one or more Sub processes) > 4/ A second call-gate to implement the syscalls that are changed > 5/ A different syscall protocol (using #4) to implement the fact that all > IO becomes Async in a thread setting, and to return control to the > (User level) Thread Scheduler (UTS) when a KSE blocks. > 6/ A manner of returnig to the UTS after the subprocess is rescheduled > after a process preemption rather than returning to the thread that was > pre-empted. > 7/ A method for treating a pagefault as a blocking IO and returning to the > UTS when a thread get's a pagefault. > 7A/ A method of ensuring the UTS doesnt activate #7 if IT blocks. > 8/ A method of delivering a signal to the UTS rathe than to any randomly > running thread, and letting it decide which thread should handle it. > (7 and 8 are related) 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. -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.9911201830060.6541-100000>