Re: newbus integration of MOD_QUIESCE (was Re: cvs commit: src/sbin/kldunload kldunload.8 kldunload.c )

From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 07/14/04

  • Next message: Jay Sern Liew: "increased machine precision for FreeBSD apps?" 
    To: Robert Watson <rwatson@freebsd.org>
Date: Wed, 14 Jul 2004 09:54:26 +0200

    In message <Pine.NEB.3.96L.1040713195126.63836A-100000@fledge.watson.org>, Robe
    rt Watson writes:
    >
    >On Tue, 13 Jul 2004, M. Warner Losh wrote:
    >
    >> The nasty case I've come up with is what happens when the module is idle
    >> (not busy), but becomes busy (not idle) after the MOD_QUIESCE call?
    >> Right now newbus modules that receive a MOD_UNLOAD call attempt to
    >> detach all instances of devices contained in that module. If I have a
    >> way to poll the driver to see if it is busy (which is relatively easy to
    >> implement), then if it becomes busy after the MOD_QUIESCE call, I get a
    >> MOD_UNLOAD which would force instances to detach.
    >
    >So, it sounds like a couple of concepts are floating around:

    I considered most of what you suggest here myself but concluded that
    since we had been able to get by with only -force in mount for so
    long, we really only needed two levels:

            MOD_QUIESCE "stop and prepare for unload if not in use"

            MOD_UNLOAD "unload unless there are memory references into
                            the module which cannot be invalidated"

    I did make the kldunloadf() take a flag argument so if people want
    higher granularity more can be added, but remember that would come
    at a cost of more code in all modules. 

    -- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
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"
  • Next message: Jay Sern Liew: "increased machine precision for FreeBSD apps?"