Re: newbus integration of MOD_QUIESCE
From: M. Warner Losh (imp_at_bsdimp.com)
Date: 07/14/04
- Previous message: Robert Watson: "Re: newbus integration of MOD_QUIESCE (was Re: cvs commit: src/sbin/kldunload kldunload.8 kldunload.c )"
- In reply to: Robert Watson: "Re: newbus integration of MOD_QUIESCE (was Re: cvs commit: src/sbin/kldunload kldunload.8 kldunload.c )"
- Next in thread: Robert Watson: "Re: newbus integration of MOD_QUIESCE"
- Reply: Robert Watson: "Re: newbus integration of MOD_QUIESCE"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 13 Jul 2004 18:14:19 -0600 (MDT) To: rwatson@freebsd.org
In message: <Pine.NEB.3.96L.1040713195126.63836A-100000@fledge.watson.org>
Robert Watson <rwatson@freebsd.org> writes:
: MOD_WEAKUNLOAD - Unload if you're not in use. I.e., unattached driver,
: unmounted file system, netgraph nodes that aren't instantiated, network
: protocol without any sockets, etc. Be harmlessly gone, but vetoed
: at a low cost.
This is desirable.
: MOD_STRONGUNLOAD - Unload even though you're in use. Detach the driver,
: deadfs the file system, wither the geom, sever the sockets, etc. May
: cause disruption, but may also veto, depending on the subsystem,
: especially if the subsytem has no way to notify its consumers of
: impending doom. Can be vetoed, but try harder before vetoing. Some
: subsystems might always return EBUSY for this if there's really no way
: to express "undesirable departure" upwards.
This is tue current MOD_UNLOAD
: MOD_QUIESCE - Attempt MOD_WEAKUNLOAD, and if that fails, ask the module to
: start draining in some form. I'm a bit unclear on quite what's
: intended, but this seems to be less atomic notion than "unload, or
: don't" at various points on the spectrum. I.e., it kicks off a state
: transition in what is likely a slightly poorly defined state machine.
: Right now, the state machine is "Not loaded", "Loaded", and we use a
: lock to prevent intermediate states from colliding.
This is the heart of my questions about MOD_QUIESCE.
Warner
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Robert Watson: "Re: newbus integration of MOD_QUIESCE (was Re: cvs commit: src/sbin/kldunload kldunload.8 kldunload.c )"
- In reply to: Robert Watson: "Re: newbus integration of MOD_QUIESCE (was Re: cvs commit: src/sbin/kldunload kldunload.8 kldunload.c )"
- Next in thread: Robert Watson: "Re: newbus integration of MOD_QUIESCE"
- Reply: Robert Watson: "Re: newbus integration of MOD_QUIESCE"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: newbus integration of MOD_QUIESCE (was Re: cvs commit: src/sbin/kldunload kldunload.8 kldunload.
... > detach all instances of devices contained in that module. ... I.e., unattached
driver, ... MOD_STRONGUNLOAD - Unload even though you're in use. ... deadfs
the file system, wither the geom, sever the sockets, etc. ... (freebsd-arch) - Re: I finally found the wooden stake to drive through my programs still beating heart!
... Once I had executed my Unload procedure, the code following the Unload statement sometimes
made reference to a control, which would apparently "randomly" restart my form! ... Unload
routine, and put the following line of code just after every subroutine call that could eventually
result in an Unload statement being executed: ... That timer was keeping my form from terminating,
even though it was not actually executing any code at the time I was Unloading. ... A one-minute
watchdog-like timer that runs a small diagnostic whenever it ticks, and if things don't appear to be
proceeding normally, it resets the state machine back to an idle condition. ... (microsoft.public.vb.enterprise)