[unix-pc.general] loadable device drivers

jonwest@rosevax.Rosemount.COM (Jon Westbrock) (11/04/88)

I am interested talking to anyone who has dealt with loadable device
drivers for the unix pc.  I am especially need of information about
what happens when a driver is loaded and how the line disciplines routines
that can be written are related to the line disciplines in linesw[].

-- 
Jon Westbrock, Rosemount Inc.                          +1 612 828 3057
Domain: jonwest@Rosemount.COM                   Path: uunet!rosevax!jonwest

ditto@cbmvax.UUCP (Michael "Ford" Ditto) (11/07/88)

In article <6637@rosevax.Rosemount.COM> jonwest@rosevax.Rosemount.COM (Jon Westbrock) writes:
>I am interested talking to anyone who has dealt with loadable device
>drivers for the unix pc.  I am especially need of information about
>what happens when a driver is loaded and how the line disciplines routines
>that can be written are related to the line disciplines in linesw[].

I have found several problems with /etc/lddrv/lddrv related to drivers with
line disciplines.  In particular, it seems that id doesn't correctly compare
the entry-point symbol names; it thinks "FOOin" is the "FOOinit" routine and
calls it immediately when the driver is installed!  Apparrently, it just
compares the first 5 characters, since the AT&T-supplied "xt" driver loads
just fine while my driver called "sxt" has the above mentioned problem.
Also, I found that lddrv didn't put an entry in linesw[] when my driver was
loaded, even if I had told it the driver had linesw functions.  But again,
the "xt" driver is in conflict with this:  it simply looks for an entry with
(linesw[n].l_input == xtin) and uses n.

I ended up not telling lddrv about my linesw functions and searching for
(linesw[n].l_input == sxtin), and if I don't find one, I search for
(linesw[n].l_input == NODEV), and then poke my functions into that slot.
Currently, the first search will always fail, but I put I put it in just in
case I ever get lddrv to work the "right" way.  I have verified that lddrv
will avoid using that slot after I "take it over".

Here's the code I am currently using in my sxt driver (don't bother asking
for it; it's not finished and it's not on the top of my project stack,
either.)


int sxtline;		/* "global" variable which holds linesw slot # */

sxtinit()
{
    for ( sxtline = 0 ; sxtline < linecnt ; ++sxtline )
	if (linesw[sxtline].l_input == sxtin)
	    return;

    for ( sxtline = 0 ; sxtline < linecnt ; ++sxtline )
	if ((linesw[sxtline].l_input == nodev) &&
	    (linesw[sxtline].l_output == nodev))
	{
	    linesw[sxtline].l_input = sxtin;
	    linesw[sxtline].l_output = sxtout;
	    /* other fields would be initialized here if needed. */
	    return;
	}

    u.u_error = ENXIO;
}
-- 
					-=] Ford [=-

"The number of Unix installations	(In Real Life:  Mike Ditto)
has grown to 10, with more expected."	ford@kenobi.cts.com
- The Unix Programmer's Manual,		...!sdcsvax!crash!elgar!ford
  2nd Edition, June, 1972.		ditto@cbmvax.commodore.com