On Fri, 2010-03-05 at 17:06 +0000, Alan Jenkins wrote: > On 3/5/10, Jon Masters <jcm@xxxxxxxxxx> wrote: > > On Fri, 2010-03-05 at 10:31 +0000, Alan Jenkins wrote: > >> On 3/4/10, Ozan Çağlayan <ozan@xxxxxxxxxxxxx> wrote: > > > >> > http://bugs.gentoo.org/attachment.cgi?id=189127&action=view > >> > > >> > Shortly I think that m-i-t should track this pulled-in dependency chain > >> > and > >> > could be able to prune them all upon > >> > unloading. According to the manpage of modprobe, -r seems to handle this > >> > if > >> > the dependencies are not used too. Maybe > >> > it's just a missed use-case where the dependencies have refcount >= 0 > >> > and > >> > not refcount == 0. > >> > >> Ah. After trying this myself, I see how annoying this could be. > >> There's not really any better way to do this without kernel > >> modifications, sorry. > > > > Right. This is a known problem. And it's something I was thinking about > > after sending the other mail. I agree that this could do with fixing. As > > you say, a lot of this will get better with softdeps, but there's always > > the case that a module load triggers a uevent that loads another module > > we will now depend upon, or several other possibilities. > > > > Let's start with softdeps (and look at hinting in kernel modules), then > > the next step will be to address the deps we read from the kernel so > > that we know who the additional user is in order to unload. > > > > Jon. > > Sure. I wasn't saying it was a good idea to modify the kernel for > this :). Unloading is only for debugging nowadays. :) > That said, it might be nice to have "modprobe -r a b c" do the same as > the gentoo script: repeatedly select modules with refcnt=0 for removal > (and then complain about the rest). Then you can do > > modprobe -r `lsmod | cut -d " " -f 1 | grep snd` > > which would be easier on the fingers and/or eyes. Yup. Ok. That's worthwhile doing. Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
