NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/unix/bsd/4731

Text File | 1992-08-26 | 8.8 KB | 172 lines

Newsgroups: comp.unix.bsd
Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!haven.umd.edu!darwin.sura.net!Sirius.dfn.de!math.fu-berlin.de!unidui!du9ds3!veit
From: [e-mail] (Holger Veit)
Subject: Re: WD Ethernet Card not found on warmboot
References: <[e-mail]> <[e-mail]> <veit.714671205@du9ds3> <[e-mail]> <veit.714724604@du9ds3> <[e-mail]>
Date: 26 Aug 92 14:50:09 GMT
Reply-To: [e-mail]
Organization: Uni-Duisburg FB9 Datenverarbeitung
Sender: @unidui.uni-duisburg.de
Message-ID: <veit.714840609@du9ds3>
Lines: 159

In <[e-mail]> [e-mail] (Terry Lambert) writes:

>In article <veit.714724604@du9ds3>, [e-mail] (Holger Veit) writes:
>|> In <[e-mail]> [e-mail] (A Wizard of Earth C) writes:
>|> >In article <veit.714671205@du9ds3> [e-mail] writes:
>|> >>DO YOU REALLY NEED THIS?
[...]
>|> 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 question is what a kernel really is. Even device drivers are IMHO "kernel",
loadable or not. It is quite uninteresting which size all the parts have in
a disk directory. A microkernel of 100K and 10 loaded "value-added" or
"mandatory" drivers, 100K each, is 1.1MB and needs 1.1MB in memory unless
you want to do swapping on parts of the kernel which I would regard with
suspect. You may, however, allocate different parts of the kernel to faster
or slower memory and tune your system (although, I personally think the
Amiga is a hacked hardware with its chip and fast ram).

>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 ...].

The kernel source subtree is ~ 5 MB, and needs 2-3 MB more to generate. I
think that was an unlucky decision to bundle it into the 40MB src01 file set
which contains the complete source of all the utilities which some people even
do not know of that they exist at all. In a less busy moment, I think I'll
unpack this part and repack it into the "kernel01" kit and make it available
on the next FTP server (10 meters distance).

>|> >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.

That's good news.

[...]
>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.

This is what I meant with "carrying the OS around." I see a little bit more
convenience for sysops here, but but not very much else. It means you can
throw a number of strange files on a system and let it find the best solution.
I hate this kind of "user friendlyness", not for job security of the sysops,
but because in the long terms the knowledge necessary not to lose track of
the system will disappear. With the OS/2 I installed on my system just to
see what it does I have already lost the insight almost because everything is
hidden under a "user friendly" surface and every kind of trouble shooting
(for which there is no need: there are no bugs and there are exactly (int)NULL
questions in comp.os.os2.* groups ;-) ;-) ;-) ;-) becomes a tricky or dirty
hack of the knowing wizards.

>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.

Yes, MIT uses a different dictionary for looking up "micro".

>|> >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)

And why then loadable instead of configurable (by kernel generation)? Some of
them are already excludable by #ifdef's and appear as an option in kernel
config, others will possibly follow in future releases.

Perhaps I was not accurate enough (you unfortunately removed my sarcastic
remark on the "QEMM for UNIX"): The interface you can use for inclusion or
loading of the above optional features is good for "value-adding" as well.
Anyone has a much easier job to add his own "feature" to the system and
uses this for his own applications, for instance some special
block read system call which returns a disk block in reversed order
(I know this is a stupid example but there ARE such ill brains) and allocates
a SYScall number for it (lets say 0x12345678 to use unique long numbers in
this interface). Another one uses the same number for the famous "Apple-II
emulator trap" and immediately, we have a conflict. Things like that on
other levels are the daily pain under "free" systems like MSDOS. The simple
example could be solved by a RPC like numbering system, but the more
interesting problems that deal with resource scheduling ("The tape drive is
mine! No, I was faster!") remain or could come up again from the abyss.

Holger


>                    Terry Lambert
>                    [e-mail]
>                    [e-mail]

>---
>Disclaimer:  Any opinions in this posting are my own and not those of
>my present or previous employers.
--
|  |   / Holger Veit             | INTERNET: [e-mail]
|__|  /  University of Duisburg  | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO
|  | /   Dept. of Electr. Eng.   | "No, my programs are not BUGGY, these are
|  |/    Inst. f. Dataprocessing |          just unexpected FEATURES"