Date: Thu, 30 Oct 1997 18:05:58 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: Chris Vance <cvance@tis.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: LKM Interface Message-ID: <19971030180558.63267@hydrogen.nike.efn.org> In-Reply-To: <199710301844.NAA23676@clipper.hq.tis.com>; from Chris Vance on Thu, Oct 30, 1997 at 01:44:17PM -0500 References: <199710301844.NAA23676@clipper.hq.tis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971030180558.63267>