At 12:20 PM 6/28/2001 -0700, Bill Studenmund wrote:
>On Thu, 28 Jun 2001, MAEKAWA Masahide wrote:
>
> > - Are interfaces to each devices necessary to be global? What do you think
> >   that exists kludge hacks to avoid namespace conflicts?
>
>Which "hacks" are you refering to?
>
> > 3.1.  Ideas
> >
> > The bdevsw/cdevsw tables are dealed with in the abstract to support
> > to attach/detach the bdevsw/cdevsw data dynamically. Each drivers should
> > use devsw_get(9) and devsw_lookup(9) to get the device interface instead of
> > accessing them directly.
> >
> > The initial bdevsw/cdevsw tables are generated automatically by config(8)
> > Each bdevsw/cdevsw entry is a set of device interface functions and
> > is put as a structure data in each drivers source.
> > The structure data only refers to bdevsw/cdevsw interfaces. Now each
> > interfaces are not global functions but local functions in their source.
> > I.e. all interfaces are declared as a static function. If necessary to 
> access
> > the interface, we must access it via its structure data. Again, we must not
> > access the interfaces directly now.
>
>I think making all of the routines static would be a bad idea. ddb and kdb
>don't deal well with static routines - traces will show ?? for routine
>names, which is quite cryptic. :-)

So what?  I define my static routines so that they aren't static under DDB.
Static routines are there to guarantee local interfaces don't get exported.
Ideally each driver would only have it's foo_bus_ca cfattach and its devsw
exported.  DDB should show 'closest symbol'+offset which gives an idea of
where the code is close to.

static routines also compilers to do better optimization since they can do
global register usage for all the callers of a static routine.


--
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message