From owner-freebsd-hackers Thu Oct 30 18:06:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA01592 for hackers-outgoing; Thu, 30 Oct 1997 18:06:16 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA01582 for ; Thu, 30 Oct 1997 18:06:10 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id SAA21894; Thu, 30 Oct 1997 18:05:59 -0800 (PST) Message-ID: <19971030180558.63267@hydrogen.nike.efn.org> Date: Thu, 30 Oct 1997 18:05:58 -0800 From: John-Mark Gurney To: Chris Vance Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: LKM Interface References: <199710301844.NAA23676@clipper.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199710301844.NAA23676@clipper.hq.tis.com>; from Chris Vance on Thu, Oct 30, 1997 at 01:44:17PM -0500 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chris Vance scribbled this message on Oct 30: > > 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? actually.. Doug Rabson did some work to get a kernel linker and module design up and running (sys/kern_{module,linker}.c, sys/link_aout.c) and it works quite nicely... utilities to load/unload/stat are kld* in /sbin... this works VERY nicely.. you declare each part of the system as a module, then your handler code will be delivered a load and unload event when they happen.. also at shutdown, your module gets a shutdown event... this works really well.. as the module is the same for both dynamic and staticly link modules... no changes neccessary... right now on my -current boxes, the "module" for new filesystems only require an extra run through ld to make the object files into a sharable image... > 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. actually... I'm going to be also redesigning the bus/device system.. right now each bus has it's own code, and there is no way to easily have one bus be attached to another bus (i.e. pci to isa bridge)... right now my spec so far is: http://resnet.uoregon.edu:6971/~jmg/FreeBSD/busdevice.html but it still needs a lot of work... > 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. personally, I think lkm's are to limiting... they require specially designed code JUST to handle the lkm problem... I was able to simply take code from a normal kernel compile, run it through ld, and bam, I could load it.. sure it didn't prevent me from unloading and causing a kernel to panic.. :) but then if the code was using the generic module system, that wouldn't of happened... if you have any questions, just ask me... I have the VFS and psuedo devices work... I am working on getting screen savers up and running.. If someone would like to make the screen savers a bit more interesting, they could change the interface to add_scrn_saver so that if would keep a list of "loaded" screen savers, then upon activation, it would randomly select a screen saver... this along with the new code would allow you to staticly compile in a number of screen savers.. and then you would have a nice selection of savers.. ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD