From owner-freebsd-bugs  Fri Mar 22 05:00:24 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id FAA04609
          for bugs-outgoing; Fri, 22 Mar 1996 05:00:24 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA04591
          Fri, 22 Mar 1996 05:00:17 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id XAA05969; Fri, 22 Mar 1996 23:58:50 +1100
Date: Fri, 22 Mar 1996 23:58:50 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199603221258.XAA05969@godzilla.zeta.org.au>
To: bde@freebsd.org, pst@shockwave.com
Subject: Re: modloaded block/char device drivers
Cc: bugs@freebsd.org, hackers@freebsd.org, jmz@freebsd.org
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>(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