cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h

M. Warner Losh imp at
Thu Jun 3 08:32:50 PDT 2004

In message: <xzp7juo8y8r.fsf at>
            des at (Dag-Erling Smørgrav) writes:
: "M. Warner Losh" <imp at> writes:
: > des at (Dag-Erling Smørgrav) writes:
: > : Scott Long <scottl at> writes:
: > : This should be fairly easy to do.  I'll try to come up with some
: > : patches.
: > How about an API?  How does the driver deal with the global/instance
: > variable split?  If I set dev.fxp.gerbil to 1 and dev.fxp.1.gerbil to
: > 23?  Is that order dependent?
: that's up to the driver author to decide.

That's why I want to know the API the driver will use so that it can
be judged as sufficient or not.  I also think we should have some kind
of default design pattern.

It would also be good to have some hook to the boot loader tunables as
well.  This is easy to do for static ones, but non-static ones need
some glue to make it happen.

: so far, what I think I'll do is give each devclass its own context and
: node, and place each device's node below the devclass's node, so you
: get
: dev.fxp.fxp0.%desc
: dev.fxp.fxp0.%driver
: dev.fxp.fxp0.%location
: you can't have the driver be the parent, because some devices have no
: driver (but they all have a class), and I want to use dev.fxp.fxp0
: instead of dev.fxp.0 on the off chance that there might be multiple
: devices in a class with the same unit number but different names.

That can't happen.  If it does, I want other things to break as well
so we notice when it does.  I'd rather see symetry with the hints

Although it is safe to assume that people have written drivers with
numbers in them.  We have tsc2011, tsc2050, etc for some of the
modules that we do and this has worked since 3.x at least.  These
names will work either way with your way or my way, but I wanted to
point it out.


More information about the cvs-src mailing list