χ Wed, 09.10.2002, Χ 10:17, Bruce Evans ΞΑΠΙΣΑΜ: > On Tue, 8 Oct 2002, John Baldwin wrote: > > > On 08-Oct-2002 Vladimir B. " Grebenschikov wrote: > > > χ Tue, 08.10.2002, Χ 22:25, Maxime Henrion ΞΑΠΙΣΑΜ: > > >> - I'm not sure if using the context of the init process to do sysctl > > >> calls is the right way to go. However, it is not very clear what you > > >> should use to do this, at least to me. > > > > > > kernel_sysctl need thread pointer, it may be used in sysctl handlers. > > > > Use curthread perhaps. In -current you always have a thread context, > > even when idle. > > Not in ddb you don't. ddb may be invoked at any point, including in > the middle of a thread switch. ddb also use any normal lock, since > doing so may deadlock or worse. I don't see how ddb can safely use > any of the general sysctl code, especially for writing. There are > almost no locks for sysctl now, but that will change when Giant is > pushed down and/or removed. Reading can work in the same way as db_ps() > now, provided the code doesn't go near any locks: when a data struct > is invalid, following garbage pointers cause traps if you are unlucky > (endless loops if you are unlucky) and ddb's trap handler longjmp()s > back to the main loop. Going near locks causes at least the following > problems: > - deadlock
As minimal, It will deadlocked if you call sysctl when drop to DDB from another sysctl handler. > - not releasing locks in the trap handler before longjmp()'ing. The > trap handler cannot reasonably know which locks to release if they > were aquired by general code. > - traps in the middle of aquiring and releasing locks may leave the > locks in a half-initialized state, and the trap handler cannot even > unreasonably klnow how to fix this. Similarly for any other global > data structures that are modified by general code called from ddb. Yes, you are right but for me code is still usable in many cases. Code is for development, not for any production use. And one, as developer, can look at backtrace before use it. > Bruce -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
