Date: Thu, 1 May 1997 06:02:27 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, julian@whistle.com Cc: avalon@coombs.anu.edu.au, hackers@freebsd.org, msmith@atrad.adelaide.edu.au Subject: Re: Unloading LKMs (was Re: A Desparate Plea for Help...) Message-ID: <199704302002.GAA06530@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> Actually, it builds tables of functions at link time using linker
>> sets. The functions are then used early at runtime to build the
>> devsw tables. This implementation was expedient 17 months ago and
>> bad 16 months ago.
>
>wellll, the eventual aim is to have an init function that is called
>the same regardless of whether the driver is preloaded or loaded at
>run-time.
This function is essentially { if (probe() && no_conflicts()) attach(); }.
For statically loaded devices, the probe() and attach() functions are
currently called from higher level code. The attach() function is
separated from the probe() function so that the higher layer can handle
conflict checking. Attaching to the devsw's is a small part of the
attach() function. The conflict checking should including not clobbering
active devsw entries or existing instances of the driver, but is currently
null in most LKM drivers.
>I think we should consider pre-loaded modules as modules that
>are identical to LKM modules, but that the loading is automatic and
>already done at boot time and that all that remains to be done is the
>execution of the init function.
>(for which SYSINIT works admirably) it is possible that a
>separate linker set might have some advantages, but SYSINIT exists
>and works well.
An array of function pointers generated by config() would work even better
for statically configured devices. You can read its sources and debug it.
>> There are (BAD) interface functions bdevsw_add(), cdevsw_add() and
>> bdevsw_add_generic().
>The (BAD as you call them) interfaces are pre-existing from
>2.1 (as Darren noted) and were modified to be as compatible as before
>with the pre-existing LKM scheme with which they were original
>bundled.
The BADness is in the first and third args of the functions. The first
arg is a dev_t but should have been a device name so that drivers don't
need to know their major number. The last arg shouldn't have existed.
It is only used by the LKM upper layer to save the existing devsw entry,
but the existing devsw entry is of no interest (except for conflict
checking which isn't done and probably needs to be done at a different
time). The LKM layer had to save it for the old devsw tables because
the tables had non-null pointers to `enxio' functions. Things are
simpler now that an `enxio' devsw entry is simply a null pointer.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704302002.GAA06530>