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

Text File | 1992-08-26 | 7.6 KB | 138 lines

Newsgroups: comp.unix.bsd
Path: sparky!uunet!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: [e-mail] (A Wizard of Earth C)
Subject: Re: WD Ethernet Card not found on warmboot
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Weber State University  (Ogden, UT)
References: <veit.714724604@du9ds3> <[e-mail]> <veit.714840609@du9ds3>
Date: Thu, 27 Aug 92 01:47:08 GMT
Lines: 126

In article <veit.714840609@du9ds3> [e-mail] writes:
>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.

Naw.  The first basic point is to allow shared diskless use of the same kernel,
rather than having multiple kernels for each diskless clinet.

The second basic point is the ability to not load the Adaptech, WD7000, and
AMD controller drivers if all you have is an IDE controller, and to only load
an NE2000 ethernet driver if that's all you have, rather than having 5 drivers
for nonexistant cards.

I have been able to run 386BSD in 640K, but I can't do it with the kernel
on dist.fs and expect it to not thrash or lock up after it is installed on
the hard drive.  This means I have to buy more memory before I can run with
less memory, or I need a bazillion dist.fs disks for every possible hardware
configuration so I can install and run in a small amount of memory.  I would
like to avaoid this, thank you.

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

I agree that installation out to be on a "kit" basis, and that there ought
to be base, runtime, source, developement, and link kits.  But this still
means I have to do my kernel work on one machine and copy over the kernel
if I have a 30/32Meg drive.  This is a bummer for people on the net who
don't have a lot of disk on any local machine, and pretty much makes them
run DOS (a pretty mean thing, in my book... 8-) 8-)).

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

I disagree with this sentiment.  If I am interested in an OS or a piece of
hardware, I will find out everything I want to find out about it, come hell
or high water.  To say that "there is no benefit" discounts diskless and/or
dataless configurations, which many of us use on Sun systems and would like
to see on 386BSD.  The idea of pulling or identifying files from compressed
binaries has validity in *any* restricted memory environment, and if it is
possible to reduce memory in a diskless environment, one reduces over the
wire swapping, which is a good thing to do.

The fact that, eventually, we hope 386BSD is robust enough that a user doesn't
need how to write a SCSI driver to use it, doesn't bother me.  That this may
attract users who can't write SCSI drivers to save their lives, also does
not bother me.  I think it is still possible to have people (like ourselves)
who "know what's going on" without requiring that every user be his own
support engineer.  I think that trouble shooting a kernel nearly always
requires a kernel hacker, and that Joe Business won't be able to do it.  You
seem to be implying that all users should be as informed as kernel hackers,
and that if Joe isn't willing to become a kernel hacker, he shouldn't use
386BSD.  This is nonsensical.

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

Yep, and some of them aren't.  They shouldn't be configurable by means of a
kernel rebuild (rather than being loadable) because, as I've stated before,
not everyone has 40M or larger hard drives.

>The interface you can use for inclusion or loading of the above optional
>features is good for "value-adding" as well.

I see this as a benefit, not a detriment.  Although, if you don't allow the
kernel to be relinked (like AIX), you protect it from a lot of problems
that could be introduced, and loadable modules still allow customization...
not that I'm suggesting that approach!

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

I was already thinking of an initial determination mechanism for system call
usage, such that absolute values are available, but not the norm, for system
call numbers.  The device driver major/minor allocation problem is resolved
by performing a mknod when the device is loaded.  If I really wanted to be
faciestic (I don't!), it would be possible to disallow load of a physical
driver whose memory mapped I/O range for DMA, or whose interrupt, overlapped
that of an existing driver.  This would solve the "tape drive" problem.

One of the more interesting applications, that of dynamically loadable streams
modules, isn't applicable, since there isn't (currently) a streams package.

To argue against loadable modules on the basis of keeping conflicts from
existing is rather nonsensical, since by definition they are either addon
(in which case the conflict is resolved by not adding it on or recompiling)
or they are supplied with the system (in which case the conflict is avoided
by judicious assignment).


                    Terry Lambert
                    [e-mail]
                    [e-mail]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
                                                       [e-mail]
 "I have an 8 user poetic license" - me
-------------------------------------------------------------------------------