Date: Tue, 24 Jun 1997 13:30:36 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: un_x@anchorage.net (Steve Howe) Cc: hackers@FreeBSD.ORG Subject: Re: BSD io Message-ID: <199706242030.NAA03815@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.95q.970623222529.7612B-100000@aak.anchorage.net> from "Steve Howe" at Jun 23, 97 10:41:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > you don't want to probe ports while the system is running > > i do, i'd like to set an "inert" flag or something > so the kernel isn't bothered by these things. > > i'd like to be able to take control of the hardware > without rebooting the system while some code does > hardware diags. This would be generally useful for "WDCONFIG" type utilities. I personally would prefer that such code be placed in the driver for flags modification event actions. This would allow me to use a general interface to configure any device, rather that a device specific interface to configure a particular device which has been marked "inert". There is also the reprobing problem after reconfiguration on the marking of the device from "inert" to "active" once again; the previous probe data can not be static. This leaves a smaller set of non-configuration based card diagnostics as the set of useful things you could do with an inert device. I would say "allow this". You will need to support interrupt delivery to the user space program, probably through a poll() system call event type for this to happen. There are people currently working on getting the NetBSD poll() code over to enable this type of "user event" programming. You should contact them on the -current list with a subject like "NetBSD poll done yet?" or something similar. Then explain that you want interrupt events delivered to user space as poll() call events. > > boot from a floppy and have your diagnostic there > > that's not an option. It's not very cleanly integrated either. It's a bad suggestion. > > BSD will not run on a 186 > > no? you're kidding. BSD's virtual memory requires paged memory management and memory protection based on protection domain. This was not available until the 386. Theoretically, you could write a BSD VM that did not rely on a PMMU facility. If you did this, you would be severlylimited in the size and number of programs you could run at the same time. Your best bet would be to implement all code as PIC code and break it into page boundries. This is the same way Windows ran in "enhanced mode" on these machines. This means that you would not be able to run most commercial x86 code. > > but a 386sx20 will run ports at 115000 without flow control. > > i'd say that's pushing it, if there's some truth, i'd > bet you'd get errors on a long steady stream. Actually, this is a reuslt of Bruce's "fast interrupt" code. You should look at it before you assume it can't work. In point of fact, I worked on a DOS communications program that could do the same on an 8MHz AT. It took the interrupt for the first character, disabled interrupts, and polled like hell until there was a break in the data. It's all a matter of how you program it. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706242030.NAA03815>