Date: Wed, 23 Sep 1998 06:25:18 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bde@zeta.org.au (Bruce Evans) 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 Subject: Re: DEVFS & SLICE? Message-ID: <199809230625.XAA13119@usr09.primenet.com> In-Reply-To: <199809230342.NAA22172@godzilla.zeta.org.au> from "Bruce Evans" at Sep 23, 98 01:42:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809230625.XAA13119>