On Sun, 27 Aug 2000, Matthew Jacob wrote:

# > Not that I'd be against dynamic kernel loading, mind you, since then
# > only the needed devices would be loaded at boot time (kind of like
# > a working LKM on steroids), but the overhead that I've seen as-
# > sociated with this scheme has proven to be pretty high, not
# 
# I sure would like to see you quote some *real* numbers here (memory load,
# actual comparative speed of boot) on this for several systems that actually do
# this (not just Solaris). We've talked about this via email before, and, uh, I
# don't believe you're stating this fairly.

Does "feel of comparative speed" count?

It FEELS a hellova lot faster to watch a BSD system boot than a Solaris
system, IMHO.  I'm not trying to nix things completely, here, but that's
how things feel to me.

I have a 2x450 MHz Ultra-60 in my cube which I watch boot up, and then I
compare it to my UP PIII-450 running NetBSD, and the PIII comes up MUCH
quicker.  I'm counting post-POST, if you know what I mean.  From bootload
to multi-user goes much quicker on the BSD box -- it outstrips the Solaris
U60 by a good fifteen-twenty seconds.

# You have to have a kernel linker. In FreeBSD, kern_linker.o, subr_module.o and
# subr_kobj.o adds about 10K of text/data in a 300K generic kernel. The actual
# runtime linker in Solaris is about the same- maybe a bit beefier, but about
# the same.

Like I said, I'd not be against RTL of a kernel and its modules as long as
the performance can keep up.

# The speed at which modules are loaded depends on the mechanism you use. In
# Solaris, it's darned slow. That's because most of it (early on) is done via
# callbacks to the PROM driver.
# 
# But when you say "pretty high", I sure would like to know what you mean.

See above, that's all.  I don't mean in any way, shape or form that it
takes more space/memory/disk, only that on Solaris it's *slow*.  D'ya
think we could do this in a more time-efficient manner?

Tha above size requirements stated are not too bad, actually...

# > to mention that if you put in a new driver somewhere and somehow
# > rearrange the ordering of the major numbers, it can be a headache.
# > I'd like to see the drivers declare their own major numbers, possibly
# > maintaining a sparse numbering scheme.  It would match most closely
# > what we have today, except that the driver would declare its number
# > (and type) on load rather than having a big ?devsw[] compiled in.
# 
# Drivers should not declare a centrally contended resource unless there's a
# central registry for such major numbers. Drivers *should* create minor
# nodes are control that allocation (possibly with hints for name binding)
# since it is only the driver that knows what the minor bits mean.

Agreed, 100%.  The idea is that the resource would not be centrally contended.

That registry should probably exist somewhere under /sys/conf, I would think.
;-)

# -matt


				--*greywolf;
--
BSD: free yourself from Stallmanist thought!