Date: Mon, 17 May 2004 15:46:20 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Doug Rabson <dfr@nlsystems.com> Cc: Peter Wemm <peter@FreeBSD.org> Subject: Re: cvs commit: src/sys/kern kern_linker.c Message-ID: <Pine.BSF.4.21.0405171537260.27448-100000@InterJet.elischer.org> In-Reply-To: <200405172259.00791.dfr@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I came to the conclusion that we'd need something LIKE (but not exactly the same as) TLS to correctly support vimages (done by Marco Zec in Croatia) in a full pruduction environment.. (Vimages is the scheme where there are multiple actual virtual machines even in the kernel point of view.. each with its own interfaces, routing tables, firewalls etc..) To do it properly, loading a new kernel module would be similar to loading a new shared library in a threaded app.. you need to add a TLS section for each 'instance' of the new module on each virtual machine. you you'd need %gs:0->curentvm->modules[modindex]->variable which is pretty similar to what TLS does.. (or in kernelspeak, PCPU(currentvm)->modules[modindex]->variable On Mon, 17 May 2004, Doug Rabson wrote: > I've been thinking about that on and off for a while. It would be fairly > easy to represent most of struct pcpu using TLS... > > On Monday 17 May 2004 22:31, Julian Elischer wrote: > > which brings up the question of TLS in the kernel :-) > > > > On Mon, 17 May 2004, Peter Wemm wrote: > > > peter 2004/05/17 14:24:40 PDT > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/kern kern_linker.c > > > Log: > > > Since we go to the trouble of compiling the kobj ops table for > > > each class, and cannot handle it going away, add an explicit > > > reference to the kobj class inside each linker class. Without > > > this, a class with no modules loaded will sit with an idle refcount > > > of 0. Loading and unloading a module with it causes a 0->1->0 > > > transition which frees the ops table and causes subsequent loads > > > using that class to explode. Normally, the "kernel" module will > > > remain forever loaded and prevent this happening, but if you have > > > more than one linker class active, only one owns the "kernel". > > > > > > This finishes making modules work for kldload(8) on amd64. > > > > > > Revision Changes Path > > > 1.111 +1 -0 src/sys/kern/kern_linker.c >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0405171537260.27448-100000>