Xref: news2.mv.net comp.os.msdos.djgpp:5787 From: alaric AT abwillms DOT demon DOT co DOT uk (Alaric B. Williams) Newsgroups: comp.os.msdos.djgpp Subject: Re: Locking RAM for hardware interrupts Date: Tue, 09 Jul 1996 21:59:32 GMT Lines: 60 Message-ID: <836949498.23711.1@abwillms.demon.co.uk> References: NNTP-Posting-Host: abwillms.demon.co.uk To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Eli Zaretskii wrote: >There is another approach: get the sample interrupt handlers donated by >Martynas Kunigelis and use them as starting point. This is available >from the DJGPP ftp server as > ftp://ftp.delorie.com/pub/djgpp/contrib/sample-interrupt-handlers-v2.zip Presumably, their approach is not too popular, though, since I've only heard of the above methods! >If that tutorial is not good enough, maybe it could be improved by people >who use it? Maybe even by you? I've a flair for writing; I'd be pleased to have a bash at it. >You can do that yourself, using the symbols `start' and `etext': > extern unsigned start __asm__ ("start"); > extern int etext; >`start' is defined on crt0.s and `etext' is defined by the linker. Use >the addresses of these two to lock the code. >> Lock the lot, and leave the programmer responsible >> for locking dynamically allocated blocks (which are usually the >> candidates for paging, since they can be huge bitmaps etc. unlikely to >> be declared as static data). >I'm not sure this is a safe solution for every program. There might be >cases when you don't really have control of all the data that is touched >by the interrupt handler. Well, anything dynamically allocated would have to be locked manually, as would pointers into other images (rare, but possible, I guess). But both of those tend to be very well defined memory addresses. The real problem is in locking the functions; for GCC does not give any guarantees about contiguity (although it does make functions contiguous, will it in the future??), and a function requested inlined that the handler uses might just not be inlined for some reason - 'inline' is only a request, not a command - in which case the handler would be using a piece of code outside it's own extent. Et Cetera. To summarise: An image lock would be slightly overkill, but would be a security blanket. Anything outside the image can be locked much more precisely, in general. Comments? ABW -- I have become... Comfortably numb... Alaric B. Williams Internet : alaric AT abwillms DOT demon DOT co DOT uk http://www.hardcafe.co.uk/Alaric/