Date: Sun, 14 Dec 1997 23:32:06 -0800 From: Jonathan Mini <j_mini@efn.org> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Darren Reed <avalon@coombs.anu.edu.au>, hackers@FreeBSD.ORG Subject: Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port Message-ID: <19971214233205.37702@micron.mini.net> In-Reply-To: <19971214225639.55532@hydrogen.nike.efn.org>; from John-Mark Gurney on Sun, Dec 14, 1997 at 10:56:39PM -0800 References: <19971214183034.27523@hydrogen.nike.efn.org> <199712150617.WAA20179@resnet.uoregon.edu> <19971214225639.55532@hydrogen.nike.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John-Mark Gurney <gurney_j@efn.org> stands accused of saying: > Darren Reed scribbled this message on Dec 15: > > > I have larger plans for my code than just managing hardware devices... > > > the code will be VERY simply to expand it to support such things as > > > using to keep track of char/block devices, and other things... with a > > > common interface.. it will be VERY easy to create something like the > > > win95's list of system devices that is VERY complete... > > > > Hmmm, here's a question for you... > > How long before FreeBSD has an 10-MB kernel at boot-time, just like NT ? > > (Well, minus whatever bloat there is for the GUI) > > hmm... here's a question for you... > how much kernel work have you done in making the freebsd kernel as small > as possible?? with the changes that I'm working on... the ONLY things > neccessary in a static kernel will be the boot device (be it network > card or hard disk), and file system for modules... then the rest will > be dynamicly loaded... It looks like there is a slight misconception here. John-Mark was talking about how the code would allow the system to provide a _single_ tree which tracked all system resources, as well as pseudo and virtual resources. Aside from his comment about dynamic loading (which is very useful in some situations, less useful in others) I would like to put forth that his specification (as I have seen it) will actually cause an overall net REDUCTION of code and datapsace usage in the kernel due to the fact that it will allow the removal of several redundant pieces of code. This resource tracking method will help a lot of pieces of code which are pretty much hacks currently. Devfs will become much slimmer, and much easier to maintain. (devices won't need to declare both device nodes and device instances, since the tree will handle this) Also, all of the bus systems, such as ISA, PCI and the "dynamic" busses like the PCMCIA card bus will be able to share much of their code. It will also allow for machine dependancy of several bus types to be removed, such as the ISA bus which is currently in the i386 tree. Through the use of John-Mark's bus/device code, the ISA busses hanging off of PCI busses (and other arrangements, such as non-PCI x86 machines) will be able to be tracked and maintained without machine-dependant code pushed onto the device driver. In addition, much of the bus/device implementation itself is machine independant -- not to mention bus independant, which means that creating ports, and managing new bus types in the future will be very easy. The only parts of the implementation that are bus dependant (and possibly machine dependant) are the portions of code that allow a device to access the resources it has allocated. This is like having a 'bus driver' for each bus as well as a 'device driver' for each device. Because of this, devices which have the same interface, but a different transporting bus, can be "installed" onto multiple busses without ANY change to the driver itself. Your comment of "how long until FreeBSD has a 10M kernel" is valid, but only under a different context than you meant it. FreeBSD needs to look farther down the road at every turn if we are going to avoid undue kernel bloat. This system, in conjunction with the kld system, will make the kernel completely dynamic, and give it the tools needed to track static and dynamic resource usage. This change will result in increased flexibility in our kernel now, and down the road, when FreeBSD truely is multi-platform, it will give FreeBSD a much smaller code-base to maintain, as well as a smaller (and most likely faster) resulting kernel. Although it seems rediculous, I ask a different question : "how long until FreeBSD has a 256k kernel?" I'd like to see a system come into implementation where all modules can become dynamic, including things such as the UFS and inet modules, which currently are basically manditory. (the astute reader would realise that a dynamic module system that did this would require a built-in dependancy system, but that's another issue altogether) This type of dynamic loading of modules can't be implemented correctly until we have a method of easily tracking resources dynamically. John-Mark's bus/device system does this, and, based on my observations of he current codebase, it is obvious (at least to me, YMMV) that this code is greatly required. -- Jonathan Mini Ingenious Productions Software Development P.O. Box 5693, Eugene, Or. 97405 "A child of five could understand this! Quick -- Fetch me a child of five."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971214233205.37702>