Skip site navigation (1)Skip section navigation (2)
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-stable" 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>