From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 26-MAY-1994 13:29:41.07 To: EVERHART CC: Subj: Accessing the intrusion database Date: Thu, 26 May 1994 17:23:13 +0300 (CET-DST) From: "All thoughts, all passions, all delights..." To: info-vax@sri.com Message-Id: <940526172313.8581@DECUS.DECUS.DE> Subject: Accessing the intrusion database Hi Joel, I just revided my opinion about syncronisation of access to intrusion database. I isn't spinlock. It is mutex. If you'll link sys$system:sys.stb to get the map ( link/noexe/map=sys/full ) for readability, you would find there besides CIA$GQ_INTRUDER another CIA symbol: CIA$GL_MUTEX. It is a mutex used by CIA.EXE (program, that actually will executed, when you issue show intr|del/intr). You could lock that resource using sch$lockr (for read) and sch$lockw (for write) and then unlock it with sch$unlock. All mentioned SCH$ routines take MUTEX as they first parameter (address in R0) and PCB as the second one (address in R4). They are described in Black Book 8.5 Mutual Exclusion Semaphores (mutexes). So what you actually need to do is: $cmkrnl acquire the mutex in appropriate mode (read/write) read/modify intrusion database free mutex To write kernel mode you could read some articles in Digital Systems Journal (former VAX Professional) or Hitchhicker's Guide to Vms by Bruce Ellis ISBN 1-878956-00-0 (some parts of this book were published in VAX Profesional). However tasks, you intend to do on kernel stack not very sophisticated, and reading of all above mentioned books will not insure you 100%, so if you nave a VAX that could be crashed some times during the day ... Many happy minutes with SDA ... ... and happy hacking = Seva PS a properly written exception handler could save your system from crashes caused by some dumb/typo mistakes. +-----------------------------------+------------------------------------------+ | V.Semuschin | | | SONY Deutschland GmbH | | | Cologne/Germany | This side is intentionly left blank | +------------Disclaimer-------------+ | | It's not a trick, it's my opinion | | +-----------------------------------+------------------------------------------+