From owner-freebsd-hackers Thu Oct 30 10:49:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA29129 for hackers-outgoing; Thu, 30 Oct 1997 10:49:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [192.94.214.100]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA29107 for ; Thu, 30 Oct 1997 10:49:04 -0800 (PST) (envelope-from cvance@tis.com) Received: by relay.hq.tis.com; id NAA17210; Thu, 30 Oct 1997 13:55:35 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0) id xma017200; Thu, 30 Oct 97 13:55:28 -0500 Received: from tis.com (skippy.hq.tis.com [10.33.112.187]) by clipper.hq.tis.com (8.7.5/8.7.3) with ESMTP id NAA23676; Thu, 30 Oct 1997 13:44:15 -0500 (EST) Message-Id: <199710301844.NAA23676@clipper.hq.tis.com> To: freebsd-hackers@freebsd.org cc: cvance@tis.com Subject: LKM Interface Date: Thu, 30 Oct 1997 13:44:17 -0500 From: Chris Vance Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have recently begun using FreeBSD's LKM interface to test and write extensions to the base kernel. In the past, I have read messages on hackers calling for a newer, cleaner LKM interface. >From the hackers list archives, I gather that it would be a good idea to have: - a defined kernel interface - a symbol/image mapping to include module symbols in the exported interface - efficient loading/unloading (for demand loaded/unloaded modules?) - ??? What are the other details of the desired interface and is there currently any work being done on this front? I am not using the LKM interface for device drivers or filesystems, I'm just extending and supplementing miscellaneous existing structures and interfaces. Since most of the discussion focuses on device drivers (or which I care very little) I wanted to know how a redesign will affect other general kernel modules (are they being kept in mind?). There are many interesting ways a person might want to extend the kernel while maintaining the claim that it is compatible with the GENERIC FreeBSD kernel. Also, testing extensions to the kernel are expedited by the use of modload/modunload rather than /sbin/reboot; you still get your share of page faults and panics, but iterative development of a relatively stable extension consumes much less time. I have limited experience with kernel design and theory, but am a competent BSD kernel programmer. Perhaps I could help with some of the details that others have already thought through but don't have time to jump in and implement? LKM's are an area that I would love to see developed to a greater extent than they currently are. chris.