atom feed20 messages in org.freebsd.freebsd-arch[RFC] kldunload -f argument.
FromSent OnAttachments
Poul-Henning KampJul 8, 2004 1:21 pm 
Brian Fundakowski FeldmanJul 8, 2004 1:58 pm 
Dag-Erling SmørgravJul 8, 2004 1:58 pm 
Poul-Henning KampJul 8, 2004 2:03 pm 
Dag-Erling SmørgravJul 8, 2004 2:14 pm 
Poul-Henning KampJul 8, 2004 2:19 pm 
Bruce M SimpsonJul 8, 2004 2:30 pm 
Sam LefflerJul 8, 2004 2:41 pm 
Lukas ErtlJul 8, 2004 2:51 pm 
Magnus B{ckstr|mJul 9, 2004 2:54 am 
Brian SomersJul 9, 2004 3:37 am 
Magnus B{ckstr|mJul 9, 2004 3:42 am 
Poul-Henning KampJul 9, 2004 3:42 am 
Brian SomersJul 9, 2004 4:00 am 
Poul-Henning KampJul 9, 2004 4:11 am 
Poul-Henning KampJul 9, 2004 5:06 am 
Robert WatsonJul 9, 2004 7:32 am 
Poul-Henning KampJul 9, 2004 7:35 am 
Pawel Jakub DawidekJul 9, 2004 7:51 am 
Paul SchenkeveldJul 13, 2004 3:36 am 
Subject:[RFC] kldunload -f argument.
From:Poul-Henning Kamp (ph@phk.freebsd.dk)
Date:Jul 9, 2004 3:42:57 am
List:org.freebsd.freebsd-arch

In message <2004@dev.lan.Awfulhak.org>, Brian Somers writes:

Comments ?

I would have thought a MOD_UNQUIESCE would be required too - maybe called MOD_ACTIVATE (but I don't care much about the name). It'd make things more orthogonal.

When a module is loaded, it would be in a quiescent state allowing only a MOD_UNLOAD or a MOD_ACTIVATE. It's open for business between MOD_ACTIVATE and MOD_QUIESCE.

I'm not sure I see any real-world application for this ? Can you give an example ? Why would you load a module and not use it ?

The idea is that the user can be more active in getting rid of the active module by QUIESCEing it, then running around murdering processes before unloading it.

I could maybe see a point in this but I cannot remember one single instance where I would have actually done this myself.