From owner-freebsd-current Tue Sep 22 23:25:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA16644 for freebsd-current-outgoing; Tue, 22 Sep 1998 23:25:34 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA16636; Tue, 22 Sep 1998 23:25:32 -0700 (PDT) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id XAA03952; Tue, 22 Sep 1998 23:25:29 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpd003923; Tue Sep 22 23:25:27 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id XAA13119; Tue, 22 Sep 1998 23:25:19 -0700 (MST) From: Terry Lambert Message-Id: <199809230625.XAA13119@usr09.primenet.com> Subject: Re: DEVFS & SLICE? To: bde@zeta.org.au (Bruce Evans) Date: Wed, 23 Sep 1998 06:25:18 +0000 (GMT) Cc: bde@zeta.org.au, tlambert@primenet.com, abial@nask.pl, current@FreeBSD.ORG, jkh@time.cdrom.com, peter@netplex.com.au, sos@FreeBSD.ORG In-Reply-To: <199809230342.NAA22172@godzilla.zeta.org.au> from "Bruce Evans" at Sep 23, 98 01:42:45 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Not only better control, but also the ability to become desynchronized > >from the current kernel, just like libkvm. A highly desirable > >feature? > > In a way. Decoupling of libkvm from the currently running kernel helps > keep it working on dead kernels. A desirable feature. As I have discussed before, the correct way to implement libkvm is as a share object component of an ELF section of the kernel image. Basically, you use the running kernel to (effectively) get a shared library applicable to the running kernel. In this fashion, it is impossible for libkvm and the kernel to which it is associated to become detached. If you have a kernel image from which to obtain symbols, you have the shared library applicable to that kvm. That still leaves data interfaces exposed via kmem, but it's much easier to conver these to procedural interfaces (unlike kernfs or procfs, which imply a running kernel to proxy the lookups on your behalf). This is the same reason the SLICE code should manage the disk partititioning mechanism through an abstract functional interface (via ioctl): you have already compiled knowledge of a "disklabel" structure into the SLICE management modules. There's no reason, other than perhaps *wanting* to allow desynchronization of user and kernel space code, ala libkvm, to export anything other than a uniform functional interface to user space. That you would incidently end up with a single program for DOS partition, DOS extended partition, dislabel, agregation (i.e., vinum and ccd) and media perfection layers (i.e., bad144), and any future SLICE manager loaded as an LKM/KLD, is merely gravy... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message