Date: Wed, 6 Nov 1996 11:06:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: tony@netcon.com (Tony Ardolino) Cc: hackers@freebsd.org Subject: Re: Loadable Kernel Modules Docs Message-ID: <199611061806.LAA08471@phaeton.artisoft.com> In-Reply-To: <328077F6.D47@netcon.com> from "Tony Ardolino" at Nov 6, 96 06:35:18 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Hi! > Could someone help me with Documentation or explanation on FreeBSD > Loadable Kernel Modules. We have a VFS File system and a Protocol stack > that we want to make loadable modules. We think we have added all the > code thats required but we are just guessing. We have done the > same loadable modules for SunOS, Solaris and AIX before, so just a litte > help is all thats required. We like to try to avoid making this a > lifetime occupation. > Thank for all you help. Hi Tony, long time, no hear! If the VFS adds VOP calls, you will need to rebuild the kernel. The design of the VFS framework supports adding VOP calls, but vfs_init() uses the contents of the UFS/FFS struct vnops in order to set the number of VOP calls instead of the size of the structure in vnode_if.c. I have submitted patches to fix this, but no one has integrated them. At a minimum, you will have to build a new vnode_if.c and recompile UFS and FFS to understand and FS extensions. Since you have a history of putting NetWare Clients into UNIX OS's, I suspect you may need to force a recompile of the client machine, even if you use binary modules. If you aren't assing VOP's, then the source examples in /usr/src/lkm for mfs and procfs are probably your best bet. If you consume functions from your protocol module in the FS, you will need to load the protocol module first. If the protocol module is IPX, I'd suggest using the built in IPX. The other two possibilities are SPX (since you also have a history of building NVT -- NetWare Virtual Terminal -- support for UNIX boxes 8-)) and a MUX and/or client services device. For the SPX, you may have a problem. Protocol stacks and socksys layers are problematically interfaced. The best you could hope for is to submit some patches for adding blank slots, which your LKM would then fill in. If you do this, then the ipfw code is probably your best example. If you want to discuss LKM consumer interfaces for protocol stacks, you should start with the discussion Garrett Wollman and I had on the -current list when the ISO networking was removed (this was the libc version bump). The discussion is archives in the -current list archives on www.freebsd.org. I have some stub code I built during the discussion which uses socket classes with some generic routines, and has backward compatability code to implement the stubs for inet_*(), etc.. Basically, it provides some generic socket top-end interfacing, and the libc opens a shared object via dlopen, one per supported socket class, from a table of protocol families vs. modules. The idea is that you can dump a protocol family in the kernel, add an object to /usr/lib, and add a table entry to /usr/lib/protocols, and you ,agically can add back support for ISO and XNS protocol families. It would work for SPX or DECNet Phase V or whtever you wanted to add to the kernel dynamically, as well. Unfortunately it's only stub code. 8-(. For a MUX (which you might need for "Server Busy" NCP turnaround, or to support "hot engine scheduling" if your user space server uses a "work to do model" with anonymous engines), the IPFW code is your best bet. The reason for this is that a mux is a consumer interface more than it is a provider, and you should be able to push everything you need in user space over a standard device node. The only tricky part will be creating the device. I suggest breaking the module into a "device" piece and a "mux" piece, and loading them in [mux,device] order. Alternately, you could use the device table code in /sys/kern/kern_lkm.c to handle the device creation as part of the init strategy. I recommend breaking it up, since the LKM number for a device can be determined from user space (see the "modstat" sources), and this is its index in the bdev/cdev table (depending on the device type). I could have guess wrong on all this, and if so, at least you have some pointers for a basic strategy for the types of modules you want to load. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611061806.LAA08471>