Re: Maybe we should stop "Paging Beth Stone" already...


Richard Cooper wrote:

| I'm just thinking about the last milisecond being only half as long as
| the others, but it could probably be made to sync well enough.

With a PIT setting of 1195 (04ab) I once measured it with counters and
a oscilloscope:
The average millisecond (0..998) was 1.001525 +/-0.15% so every 1000th
(RTCL-extension only) become only 0.5238 +/-0.25%, while the rest of the
IRQ0-counters remained equal timed with the +1.525 ppm error.

Unfortunately this PIT frequency+divider wont allow exact settings
for even time values. I found just 50mS(20Hz) to be the only exact.
Perhaps this were once the base to define the 1.193180 Mhz/65535,
seems not just defined to avoid 50 and 60 Hz interfierence as this
two beccome very close [ie: 5d37h 50.00125718 Hz].


| > | Only if the IRQ handler is interrupting the kernel and not an
| > application.
| > ?? I see this in the opposite direction.
| > I wouldn't allow user-mode event-handlers to direct hook IRQ-handlers.

| Well what I mean is, if you've got a user-space process executing when the
| IRQ goes off, then you've got to do a TSS switch to get back to kernel
| space.


If an INT or IRQ results in a PL-change it will swap ss:esp anyway
without swapping all contents of the TSS.
An IRET with a PL-change will restore ss:esp from the interrupted
to reverse the above.

As my all code run PL0, I may have not fully understood what I read so
far about IRQ ? ;)

<Intel>
IA-32 Intel Architecture
Software Developer’s
Manual
Volume 2:
(page 343)
....
TRAP-OR-INTERRUPT-GATE
....
IF code segment is non-conforming AND DPL < CPL
THEN IF VM=0
THEN
GOTO INTER-PRIVILEGE-LEVEL-INTERRUPT;
(* PE = 1, interrupt or trap gate, nonconforming *)
(* code segment, DPL<CPL, VM = 0 *)
....
INTER-PREVILEGE-LEVEL-INTERRUPT
(* PE=1, interrupt or trap gate, non-conforming code segment, DPL<
(* Check segment selector and descriptor for stack of new privilege
IF current TSS is 32-bit TSS
THEN
TSSstackAddress ? (new code segment DPL * 8) + 4
IF (TSSstackAddress + 7) > TSS limit
THEN #TS(current TSS selector); FI;
NewSS ? TSSstackAddress + 4;
NewESP ? stack address;
....
</Intel>

| > Also if an IRQ-routine would use some stack lines of the users stack,
| Then a user space process could crash the driver by setting ESP to zero
| and then entering an infinite loop. It could happen accidentally given
| the correct circumstances.

It would crash with a user stack fault, but the stack exception handler
must be a TSS anyway and it may also not return to the faulty user code.


| > I wouldn't let a user run his own user-space device-drivers anyway,

| I certainly would. (at least, the non-hardware variety) Say a user just
| has a disk image of a DOS floppy and wants to read it. ...

Non-hardware drivers ... OK.
For me non-hardware devices belong to software and don't need 'drivers'.

| > Driver development is a story on its own, hardware can't be emulated
| > and drivers must run in PL0, so doing it from a user-platform may not
| > work.

| In Linux, if you're root, you can get I/O permissions. If there were just
| some way to set up an IRQ handler, you could write user-space drivers.
| (of course, you wouldn't be able to make those things in /dev/, but I have
| a better idea than that)

I don't know Linux, but even winNT's grant 'super-admin' I/O-access.

| > But you sure don't mean Device drivers creation in user-mode ?
| Certainly. The user would be 'root' of course, but user-mode none the
| less.

So you optionally allow I/O-access in user space. Good, but wouldn't this
somehow be against your strict protection demands ?

| > Many developers use emulators, ...
| So that's where things like "Does not boot on a real computer and only
| runs on versions of Bochs below 1.x." come from...

Still a frequently asked question in A.O.D. also for newer Boch's. :)

[speed vs. protection...]

I'm confident for there is a way to have fully protection with minimum
time losses instead of the 'oh so common, but bloated' book-methods.


[HEXTUTOR]
| I'm in Linux now, so I can't run any DOS executables.

HEXTUTOR.exe isn't a DOS-file, it is a windoze-PE file.
Only the disass.com will install as 32-bit TSR if executed in DOS,
it is just loaded without the DOS-part from hextutor.exe.


[the worse ASM ..]
| > This seems to be a result of great books teaching
| > and fully misinterpreted optimisation hints. :)

| What I don't get is the aligning of everything into columns (just makes it
| hard to read in my opinion),

I also tend to have columns for
|address |opcode |source .... |comments
as this makes life easy for plain text storage/print and it allow
masking off unwanted fields without much software overhead.

| and the constant use of byte/word/dword prefixes which make reading
| even more difficult. The "out word dx, al" line isn't even correct,
| but I'm sure it still works since NASM probably just ignores the
| byte/word/dword nonsense.

Yes, I see this in the same way.


[the 'leave'..]
| Actually, my enter and leave macros have nothing to do with the enter and
| leave instructions by the same name. Here's the code for them:

[...]
I use INT3 instead, and if I ever would use conditional compiling
I'd use something like:

%ifdef debug_version
INT3
%endif

[your debugger window...]
| Much more useful than the enter and leave instructions...

:) Yes, indeed.

I also use my crash-message box for debugging, it then displays
"EDIT" or "INT3: or "BRK!" instead of "EXCn", it looks like:
________________________________________
MOV AL,FF |CLC |RET
mode:PM32 status:BRK! EFL:00007632
flags: DPFAVR-NLLODITSZ-A-P-C
CS:0028 EIP:000001FC [EIP]:C3F8FFB0
SS:0008 ESP:0000FF50 [ESP]:000063F0
EBP:00000080 [EBP]:FFFFC000
DS:0020 ESI:00000000 [ESI]:0040FFFF
ES:0020 EDI:00000008 [EDI]:0840FFFF
FS:0030 EAX:00000000 DR7:00000000
GS:0030 ECX:00000000 DR6:00000000
EDX:00000000 DR3:00000000 gl
EBX:00000000 DR2:00000000 gl
CR4:00000000 LT:0000 DR1:00000000 gl
CR3:00000000 TR:0000 DR0:001001FC Gl
CR2:00000000 TSC:0000000000000000
CR0:00000011 LIN:001000FC _______ mS
GDT:00100300 FFFF IDT:00100400 07FF
_________________________________________

In debug mode most of the fields are editable and let me step/trace/run/
quit/ and also change mode or view/dump stack/mem/fpu/mmx/xmm from here.

But it looks better in reality than here, as it got
coloured fields and highlighted items in both, text and graphic modes ;)
__
wolfgang






.

Relevant Pages

  • Re: State of the Union: Wireless
    ... > * Wireless drivers and the wireless stack need to be maintained IN-TREE ...
    (Linux-Kernel)
  • Re: [patch 2.6.20-rc1 5/6] SA1100 GPIO wrappers
    ... require drivers map the other way themselves when they need to. ... Having that GPIO-to-IRQ mapping is quite routine; ... GPIO is in the required state. ... IRQ framework can't do "all" the needed stuff on platforms ...
    (Linux-Kernel)
  • Re: [RFC] [PATCH -mm] ASIC3 driver
    ... asic3 defines an additional range of IRQs for the ... so this delves into the innards of the IRQ management. ... Currently nothing, but the plan is to push several drivers (leds, MMC, ... * Copyright 2001 Compaq Computer Corporation. ...
    (Linux-Kernel)
  • Re: [RFC][PATCH 2/2] PM: Rework handling of interrupts during suspend-resume
    ... not generate an irq. ... Subject: PM: Rework handling of interrupts during suspend-resume ... Introduce two helper functions allowing us to prevent device drivers ... suspend and resume. ...
    (Linux-Kernel)
  • Re: custom install cd
    ... >don't use hpnicinstall to install the "hp tested and verified drivers ... >those drivers are newer and they work. ... >devices have to share an irq and all of them have to share with at ...
    (comp.unix.sco.misc)