Re: kldunload DIAGNOSTIC idea...

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

  • Next message: M. Warner Losh: "Re: kldunload DIAGNOSTIC idea..." 
    To: "M. Warner Losh" <imp@bsdimp.com>
Date: Wed, 21 Jul 2004 18:38:47 +0200

    In message <20040721.084926.84362543.imp@bsdimp.com>, "M. Warner Losh" writes:
    >[[ only cc'd arch@ ]]
    >
    >In message: <83182.1090412961@critter.freebsd.dk>
    > "Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
    >: >Any ideas on how network interfaces should
    >: >work in this?
    >:
    >: I talked with Robert briefly about this yesterday, and the problem
    >: there is that struct ifnet is embedded in the softc. If the softc
    >: had a pointer to the ifnet, then we could do something similar, but
    >: as long as it's embedded we're stuck.
    >
    >Why is that the case? We don't detach the ifnet stuff after deleting
    >the softc. Why would a pointer to ifnet in the softc make this
    >easier?

    Because it would allow the softc could be freed before the ifnet
    structure.

    >I mean, I understand that having a pointer would insulate the size of
    >ifnet from the driver, but there's so many offsets in ifnet that are
    >encoded in the driver that doesn't seem that big a win.

    That's not the point here. The problem here is that we cannot unload
    the driver until we have hunted down and exterminated all references
    to the ifnet structure.

    If softc only pointed to the ifnet, we could neuter the ifnet (like
    we do for cdev and vnodes with a set of dead_* functions) wait for
    all threads to drain out of the module and unload it. The ifnet
    cleanup will happen "when convenient".

    It is less of an issue in networks than in cdevsw{} context, but
    dismantling things from above is easier than the opposite. 

    -- 
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: M. Warner Losh: "Re: kldunload DIAGNOSTIC idea..."

    Relevant Pages

    • Re: kldunload DIAGNOSTIC idea...
      ... :>: there is that struct ifnet is embedded in the softc. ... :>encoded in the driver that doesn't seem that big a win. ... We can't unload the driver until we've exterminated all references to ...
      (freebsd-arch)
    • Re: kldunload DIAGNOSTIC idea...
      ... there is that struct ifnet is embedded in the softc. ... Why would a pointer to ifnet in the softc make this ... encoded in the driver that doesn't seem that big a win. ...
      (freebsd-arch)
    • Re: kldunload DIAGNOSTIC idea...
      ... > the drivers, because it's all the same for them. ... > there is that struct ifnet is embedded in the softc. ... so a pointer to an ifnet or softc or whatever is almost always ...
      (freebsd-arch)
    • Re: kldunload DIAGNOSTIC idea...
      ... > the drivers, because it's all the same for them. ... > there is that struct ifnet is embedded in the softc. ... so a pointer to an ifnet or softc or whatever is almost always ...
      (freebsd-arch)
    • Re: kldunload DIAGNOSTIC idea...
      ... >drain out before we unload the module. ... >but it seems that the requirements for softc are stronger than ifnet ... >wait for the ifnet reference count to drop before returning for ... so that it isn't actually in the driver). ...
      (freebsd-arch)