Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!mips!mips!darwin.sura.net!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!park.uvcc.edu!ns.novell.com!gateway.novell.com!thisbe!terry From: terry@thisbe.npd.Novell.COM (Terry Lambert) Subject: Re: WD Ethernet Card not found on warmboot Message-ID: <1992Aug25.165542.5689@gateway.novell.com> Sender: terry@thisbe (Terry Lambert) Nntp-Posting-Host: thisbe.eng.sandy.novell.com Organization: Novell NPD -- Sandy, UT References: <1992Aug21.171828.14323@doug.cae.wisc.edu> <1992Aug24.085511.21092@autelca.ascom.ch> <veit.714671205@du9ds3> <1992Aug25.035924.29631@fcom.cc.utah.edu> <veit.714724604@du9ds3> Date: Tue, 25 Aug 1992 16:55:42 GMT Lines: 167 In article <veit.714724604@du9ds3>, veit@du9ds3.uni-duisburg.de (Holger Veit) writes: |> In <1992Aug25.035924.29631@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: |> |> >In article <veit.714671205@du9ds3> veit@du9ds3.uni-duisburg.de writes: |> >>DO YOU REALLY NEED THIS? |> >>Do you modify you hardware once a week, once a |> >>day or so? UNIX is not that memory restricted like MessDos such that you |> >>have to unload mouse drivers to get 3 bytes more in the lower 640K if you |> >>have a large program to run. This loading and unloading considerably |> >>decreased when I loaded a full featured OS/2, i.e. once the "best" configuration |> >>was found, I modified CONFIG.SYS only for alteration of paths and |> >>inclusion of enviroment variables (which has nothing to do with loadable |> >>device drivers). |> |> >This would be a good mechanism for bipartite SCSI drivers. This would let |> >you have a single small kernel that would load a driver for a SCSI board |> >based on the results of a probe. |> |> You seem to carry your OS around, don't you? During installation I can |> live with a large "GENERIC" kernel which has support for all possible devices. |> After it has been relocated to the disk (IDE,SCSI or whatever) you can |> eliminate the unnecessary devices, and get this "small" kernel. Yes, but the idea is to have a generic kernel that has a piece of each SCSI driver in it (the probe), and loads the rest based on the results of the probe. This lets me have an apparently large kernel which is actually a small kernel. Thus, like a stripped kernel, we can run in 640K, for instance. This is important for systems like the Amiga, where I have a limited amount of "fast" vs. "chip" ram. It would also allow me to load 100% into the cache on some systems if I could get the kernel small enough. Then I could really haul. The main advantage of loadable kernel modules is the ability to reconfigure without rebuilding the kernel. Many people are having problems in that they can not install enough to, for instance, recompile the kernel to get a new ethernet driver in so thay can remote mount /usr so they can recompile the kernel to get a new ethernet driver [ ... reminds me of the anti-cocaine commercial ...]. |> >Another use would be loadable file systems, also with an initially small |> >kernel. |> |> Loadable filesystems is a good idea, if you frequently reconfigure your |> disk layout. You may certainly have a UFS system, NFS, MFS, CDFS, and |> DOS/FAT FS (the last to be written yet). I would call these the basic |> facilities of the kernel. If you have no network card, not much RAM, no CDROM, |> and/or no DOS partitions, you can live with the UFS only. Do you want to load |> them whenever you need them, for instance if you want to run mtools the DOS FS |> driver (server?) is loaded on line? Sounds like microkernel stuff such as |> MACH. First off, I've got the DOS/FAT FS I wrote for 0.0 basically up. 8-). 8-). Give me 2-3 weeks to clean it up (I have a very specific rewrite of the VFS layer in mind, and I want it to be easily convertable to the new interface) before I release it. Second, there's no reason to have the ISOFS (what you called the CDFS) loaded in the kernel unless you have a CD ROM mounted. Generally, one can only mount one CDROM at a time, and it usually isn't mounted. Why have the overhead if you get only marginal benefit from it? Third, I'd like to get RFS working on 386BSD. I know, I know, it's an AT&T standard, but it's something I want to play with. With respect to RFS and NFS, why have them in the kernel unless they are being used? This is especially true of network file systems, since there are basically seperate client and server pieces, and one is generally a client or a server, but not necessarily both. Fourth, I'd like to make diskless 386BSD clients (fact is, I'd like to use remote reset off a NetWare server to load the boot image, but could actually care less where it really boots from). The easiest way to do this would be to have a RAM file system that looks like the root file system until the root FS has been NFS mounted. Certainly, I'd like to not only have the memory back, but I'd also like to avoid confusing the poor kernel about which root FS is it's root. If I unload the ram FS, I can do this. Fifth, I'd like to support mounting of Sun 4.1.2 SCSI disks with automatic byte order compensation without eating the compare overhead in the normal file system; besides which, the current vnode brain damage doesn't support reserved volume flags so that I can mark a volumes "byte order bit" to coerce sharing the code. This would be a nice interim soloution. Sixth, I'd like to support attributed files, such as file marked "read only" with jpeg, mpeg, or some other form of stream compression on the. I'd like to be able to add compression modules in the future. No, generally, with the exception of ISOFS and possibly DOSFS, I *don't* want to "load as needed". But I do want the ability to run a bunch of machines off the same base kernel, with only the applicable device drivers for that hardware loaded. Yes, this sounds like microkernel, but I draw one important distinction: In most cases, the kernel will actually *be* small as opposed to just providing a subset of kernel services. This is much more to my liking, given the meaning of "micro" I was taught in my Latin classes. |> >The ability to load system calls buys you, again, a standard kernel with, |> >as an example, a kernel implementation of variable granularity locks (with |> >intention modes). |> |> >There are lots of things which it would be nice to be able to put in the |> >kernel, use, and remove. |> |> Which system calls do you want to make "loadable"? It is an interesting idea |> to add features but it makes the software that rely on it unportable. The only thing that is "unportable" about it are any device drivers you load. Given a uniform underlying interface, everything else would have no problem running. My major peeve with VFS is that it doesn't have a uniform underlying interface; only the top side is well defined. As to system call candidates for being "loadable": o Auditing (auditsys) o Quotas (oldquota, quotactl) o Accounting (sysacct) o Async I/O for a threads library (aioread, aiowrite, aiowait, aiocancel) o Real time scheduling (rtschedule) o SysV compatable semaphores (semsys) o SysV compatable message queues (msgsys) o SysV compatable shared memory (shmsys) o 386 debug register access (???) o Backward compatability calls (otime, ostime, oalarm, outime, opause, onice, oftime, osetpgrp, otimes, ossig, ovlimit, ovtimes, osetuid, osetgid, ostat, ofstat) o SysV compatable calls (omount, oumount) o Tracing (vtrace) o Grandfathering of wait3 o Debugging (debug) o NFS client (async_daemon) o NFS server (nfs_svc, nfs_getfh, exportfs) o RFS (rfssys) o VPIX or a clone thereof (vpixsys) o Vax Unibus (resuba) |> I might be persuaded that e.g. X11 needs some kernel optimizations to access |> the I/O efficiently, this may or may not be a system call, and software that |> needs to do fast I/O to a measurement device (who does realtime processing |> with plain UNIX, however?), but this is not necessary for the general |> purpose application. Actually, X is one area where loadable kernel modules aren't very useful(unless you count mouse drivers). Mapping video adapter ram into a user processes address space is actually the job of the video driver. This defeats the need to cross the kernel boundry. It is arguable that one would want to implement the X engine in the kernel and so avoid the off-the wire/keyboard/mouse crossings as well, but then you are in the province of kernel processes. Admittedly, we will probably eventually go this was anyway, since a user space threads package is, almost by definition, non-preemptive... and it has the advantage of forcing us to pre-think out any mutex points, since it implies kernel preemption. This is probably needed if we are ever to add SMP support (this is yet another reason VFS needs it's brains rewired). Personally, I vote for kernel mapping of user streams buffers to avoid the majority of the boundry crossing, and would argue that mouse and keyboard I/O are insignificant in comparison. All this from code that is already written plus some slight compiler and linker changes that are going to be needed to support shared libraries anyway. Terry Lambert terry_lambert@gateway.novell.com terry@icarus.weber.edu --- Disclaimer: Any opinions in this posting are my own and not those of my present or previous employers.