Date: Tue, 6 Jun 2000 02:49:17 -0400 From: Coleman Kane <cokane@one.net> To: Mike Smith <msmith@freebsd.org> Cc: Alfred Perlstein <bright@wintelcom.net>, Coleman Kane <cokane@one.net>, stable@freebsd.org, hackers@freebsd.org Subject: Re: kerneld for FreeBSD Message-ID: <20000606024917.B2006@cokane.yi.org> In-Reply-To: <200006060025.RAA00952@mass.cdrom.com>; from msmith@freebsd.org on Mon, Jun 05, 2000 at 08:22:36PM -0400 References: <20000605165916.X17973@fw.wintelcom.net> <200006060025.RAA00952@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable No, they are technically shareable, as long as you don't attept to expect either of them at the software level to respond at a certain time. This is why you can have COM2 and COM4 on the same interrupt in windows or DOS, as long as you don't use them at the same time. The ISA bus is a very simple interface, and typically nothing at the hardware level causes a system to crash when resources are shared. It is usually a driver expecting information from its device, when another one is already using a certain interrupt. The only counter to this is MIO and PIO, where the result of an input is undefined, and an output is supposed to cause the data to go to both devices. I was actually aiming more towards, memory allocations, and other things like MTRRs and X and stuff. From the MTRR standpoint, most 6th gen processors (for the sake of argument the K6CXT is 6th gen) have MTRRs, registers that can define how memory ranges are utilized in the processor. There are only a finite number of these, therefore if you were to disable them for some hardware that didn't need them you could spread them out. It would also be really great (and I was originally not informed about the current state of autoloading/unloading of modules for fs and net devices) to move completely to loading everything out of klds, rather than compiling the kernel. It may also help some debugging to be able to pull apart the kernel peice by peice, having a basic default "failsafe" kernel to boot from that would subsequently begin to load the necessary modules specified, or to load them in real time and unload them when finished. I really am not sure about the reality of this proposal, and someone brought it up earlier, so I thought I'd stick my head in on it. This email is getting rather lengthy, maybe I'll try fiddling with something tonight... school is over until summer quarter starts. Mike Smith had the audacity to say: >=20 > They're "non shareable" at the hardware level ... like all the "non=20 > shareable" hardware resources. >=20 --=20 Coleman Kane President,=20 UC Free O.S. Users Group - http://pohl.ececs.uc.edu --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.0 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE5PJ7tERViMObJ880RAaS0AJ0eck/61rwJHDiatT75DuAxViyMAACg2vMA Xxv40cqzxSdnoFvFtGjCA7s= =f7Jz -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000606024917.B2006>