Date: Fri, 22 Mar 1996 23:58:50 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@freebsd.org, pst@shockwave.com Cc: bugs@freebsd.org, hackers@freebsd.org, jmz@freebsd.org Subject: Re: modloaded block/char device drivers Message-ID: <199603221258.XAA05969@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>(a) calling dev_attach() from a modloaded device panics the system. > I have not even attempted to mess with this yet, but it can be There isn't much to go wrong. There must be a bad pointer. > trivially reproduced by removing the #ifndef ACTUALL_LKM_NOT_KERNEL > wrappers around the call in qcam.c. It panics with a kernel page > fault, but the current calling chain did /not/ include any of the > qcam routines in the stack frame. I just found this by scratching Perhaps ebp got trashed (the stack trace stops when it hits ebp == 0). Then the problem might not be in dev_attach. >(b) I was forced to manually call qcam_registerdev() which is the code > that attaches the driver's cdevsw structure to the rest of the kernel. > Without this, of course, devices are not reachable via their inodes. > I feel that it's not proper for the LKM <driver>_load function to be > doing this. This really should be done as part of the LKM load process > since you already have the major number and the pointer to the structure > passed in. I think it's proper (except qcam_sysinit() doesn't handle failures and isn't designed to be reused) and the SYSINITs for installing the device switches are improper. The only reason for the SYSINITs is that they saved Julian from having to find the correct places to call [bc]devsw_add() in dozens of driver attach functions. It's simpler for statically configured drivers to call [bc]devsw_add() directly if you're writing a new driver (see sio, syscons and pcvt - the SYSINITs didn't even work for syscons and pcvt because the major number is shared). I think the SYSINITs get in the way even more for dynamically configured drivers. >(c) LKMs for device drivers with hardware that is not at a fixed address > (e.g. the joystick) or completely auto-scanable are really kludgy > right now. There's no easy way, other than editing the driver source, qcam should also worry about conflicts with lpt* :-). Someone might even want to use the same lpt port at different times for printing, parallel port TCP/IP, and qcam. The lpt driver and the plip driver are in the same file so that they can be selected between using an ioctl. There's gotta be a better way to do this. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603221258.XAA05969>