Date: Tue, 1 Apr 1997 20:28:27 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: dfr@nlsystems.com, current@freebsd.org Subject: Re: A new Kernel Module System Message-ID: <199704011058.UAA19942@genesis.atrad.adelaide.edu.au> In-Reply-To: <20519.859756869@time.cdrom.com> from "Jordan K. Hubbard" at "Mar 30, 97 01:21:09 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
(Apologies for lobbing in at the wrong end of a discussion. I promise to backtrack when I have dealt with my easter-holiday mail backlog 8) Jordan K. Hubbard stands accused of saying: > > Ah, OK, this is the bit I missed. So you'd use this to load drivers > that the kernel had never seen before, e.g. say I get a floppy from > ABC Systems along with their new network interface card which none of > us have ever even heard of before, and when I say: > > mcopy a:abc_foonic.so /lkm/devs/isa > isaconf -a foo0 port=0x320 irq=11 iomem=0xd0000 > modload /lkm/devs/isa/foo0.so > > It all does the right stuff? That sounds pretty right. It's likely that isaconf should backend onto the "registry" thing, ie. the probe parameters for the ISA device(s) would be persistent across reboots etc. > What if it's a PCI or EISA card, do I just do the modload and expect > it to DTRT? That would make sense; if the module supported PCI/EISA hardware it should know how to look for the hardware it grokked, but that's not so easy because the driver may well support hardware it doesn't actually know it supports. > Jordan -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704011058.UAA19942>