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

Text File | 1992-08-25 | 9.2 KB | 180 lines

Newsgroups: comp.unix.bsd
Path: sparky!uunet!haven.umd.edu!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: [e-mail] (Terry Lambert)
Subject: Re: WD Ethernet Card not found on warmboot
Message-ID: <[e-mail]>
Sender: terry@thisbe (Terry Lambert)
Nntp-Posting-Host: thisbe.eng.sandy.novell.com
Organization: Novell NPD -- Sandy, UT
References: <[e-mail]> <[e-mail]> <veit.714671205@du9ds3> <[e-mail]> <veit.714724604@du9ds3>
Date: Tue, 25 Aug 1992 16:55:42 GMT
Lines: 167

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?
|> >>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
                    [e-mail]
                    [e-mail]

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.