NEWBUS states

[M. Warner Losh]

In message: <3bbf2fe10909050817w4e8da3adxd8e431749b432070 at mail.gmail.com>
            Attilio Rao <attilio at freebsd.org> writes:
: 2009/9/5 M. Warner Losh <imp at bsdimp.com>:
: > In message: <20090904.172310.-1939841993.imp at bsdimp.com>
: >            "M. Warner Losh" <imp at bsdimp.com> writes:
: > : OK.  Let me ponder based on that...  It might be better for this round
: > : of changes to leverage off the device 'flags' field to indicate that
: > : we're attaching/detaching.  This would not break the
: > : device_is_attached() usage, and would solve the interlock problem
: > : nicely.  While it isn't as aesthetically pleasing as the new states,
: > : it would allow us to easily MFC it without API/ABI breakage.  This
: > : field surely would be covered by the same set of locks as the state
: > : field.
: > :
: > : I know that there's a good aesthetic argument to be made against this,
: > : but on the other hand 'compatibility' hacks can violate one's
: > : aesthetics.  We can migrate to a more pleasing state-based model in 9
: > : and reduce the risk to other code from changing its semantics at this
: > : late date.
: >
: > For a version of this hack, see
: > http://people.freebsd.org/~imp/newbus-flags.diff
: 
: So you propose to offer the transition on the device flags instead
: than the device states?
: That is an interesting approach mostly because it won't require an ABI
: breakage, but let me think about locking implications with it as I
: want to review some code and came up with a patch/thoughts in some
: hours.

Please do.  I wanted this to provoke thought and experimentation.
While not the most beautiful approach, it is one that we can use to
get around the API/ABI issues.  Please let me know how it works
out...  The assumption in the patch is that locking requirements for
state and flags are identical...

Warner