Date: Sun, 5 Sep 2004 21:19:12 +0200 From: gerarra@tin.it To: freebsd-hackers@freebsd.org Cc: ctodd@chrismiller.com Subject: RE: KLD and USB driver Message-ID: <411972290001A708@ims3a.cp.tin.it> In-Reply-To: <Pine.BSI.4.58L.0409041924100.24206@vp4.netgate.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>I'm working on a usb device driver I've derived from existing drivers in= >sys/dev/usb (4.10-RELEASE). > >I can successfully load and unload the module, but the usb subsystem doe= s >not appear to see the driver. However if I compile my driver in the >kernel, the usb sub system uses the driver correctly. Unfortunately this= >is making it time consuming to test changes to my driver code as I have to >compile the kernel each time. > >I haven't see this used in the existing usb drivers code, but I tried >using the "KLD Skeleton" from the FreeBSD Architecture Handbook. >Although I see the uprintf output at the terminal when load/unloading th= e >module, the usb subsystem does not use my driver. Like the existing usb >drivers, I'm using USB_DECLARE_DRIVER and DRIVER_MODULE statements. > >Is the KLD DECLARE_MODULE code really necessary for this driver (doesn't= >USB_DECLARE_DRIVER make the driver available already)? How can I determi= ne >why the driver works when compiled in the kernel, but not when dynamical= ly >loaded? I'm able to load/unload the uhid and ugen drivers and they work as >expected. FreeBSD is dived into subsystems and every subsystem contains a certain number of components. To mantain specific order starting subsystems SYSIN= IT macro is provided by the kernel; very struct sysinit obj has a double-cod= e priority referencing subsystem priority and priority within the subsystem= (you can give a look to them in sys/kernel.h, enum sysinit_sub_id and enu= m sysinit_elem_order enumerations). When you code a generic KLD, DECLARE_MO= DULE macro is provided to manage linking; between the other things a struct sy= sinit obj is done (through a call to SYSINIT macro) and initialized within a sp= ecified subsystem and with a specified priority inside the subsystem, to let modu= le start properly. DRIVER_MODULE just does that: among the other things, cal= ls DECLARE_MODULE linking the new module in the DRIVERS subsystems. USB_DECL= ARE_DRIVER, instead, just defines some functions to manage your usb driver. In the en= d, the real linking is done by DRIVER_MODULE and you should not use DECLARE_= MODULE (DRIVER_MODULE alredy does). However for a review of the code the complet= e source code might be provided. greetings rookie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?411972290001A708>