Date: Wed, 14 Mar 2001 18:35:36 -0600 From: Mike Meyer <mwm@mired.org> To: Phelip Cray <phelipc@yahoo.com> Cc: questions@freebsd.org Subject: Re: freebsd kernel Message-ID: <15024.3672.847976.601214@guru.mired.org> In-Reply-To: <35415364@toto.iv>
next in thread | previous in thread | raw e-mail | index | archive | help
Phelip Cray <phelipc@yahoo.com> types: > He says that the kernel of an operating system should > be as simple as possible, but that nowadays system > designers tend to push everything they can into the > kernel area. ( I have read this from other authors > also ... ) > > Is this true with the FreeBSD project? I would say that FreeBSD does *not* push everything they can into the kernel. > If it is, how > come you have to set up a sound board or a NIC by > recompiling the kernel? Isn't this stuff suposed to be > left outside? There are two thing a kernel has to do, no matter *how* minimal you make it. Even DOS managed to do these things. One is control access to system resources. The other is to provide a uniform API to those resources. Basically, this means that anything that talks to the device drivers directly has to be in the kernel. The question then comes down to where you draw the API line. Further up means user software will work with more hardware, but it also means the kernel gets bigger to deal with it. The reason you used (<- key word) to have to recompile kernels was because there were so many different kinds of sound card, all of it different. Putting them all in would have bloated the kernel incredibly so none went in, and you had to add them yourself. The new sound driver has a better design, and will work with most non-legacy cards. Apparently, that will be in the kernel in 4.4, unless they decide that being loadable will do the trick. None of this is absolute, of course. There are mechanisms to allow user programs to access the hardware directly, but that means you lose the uniform API, and the user program has to know how to deal with different hardware. It tends to be used to write portable software when there's no Unix API, and only a few such devices. The various MB heat monitoring tools comes to mind. I believe the ACPI code that's being developed for 5.0 will provide an API for that, among lots of other things, so the user code will stop talking to it directly. CD Burners make another good example. SCSI cd burners are a diverse, lot, with lots of quirks and variations. There's a user program (cdrecord) to talk to them; all the kernel provides is a way to send raw commands to SCSI devices (which also gets used by the SCSI scanner code, and probably some other things). For ATA, there's only supposed to be one hardware API for cd burners. Since it's relatively simple, that was put in the kernel rather than providing a mechanism to let cdrecord send SCSI commands to ARA devices. Anyone who thinks things are bad now should consider what was going on before Unix, when kernels new the internal structure of the files. Programs had to tell know that as well before they could open a file and read it. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15024.3672.847976.601214>