Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Dec 1997 19:14:24 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        ada@bsd.org
Cc:        hackers@freebsd.org
Subject:   Re: Bus/Processor specific I/O methods - was Re: Beginning SPARC port
Message-ID:  <199712161914.MAA19768@usr01.primenet.com>
In-Reply-To: <199712160839.TAA05709@noether.blah.org> from "Ada" at Dec 16, 97 07:39:58 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> >   This type of dynamic loading of modules can't be implemented correctly until
> > we have a method of easily tracking resources dynamically. John-Mark's
> > bus/device system does this, and, based on my observations of he current
> > codebase, it is obvious (at least to me, YMMV) that this code is greatly
> > required.
> There is a fundamental problem between this and devfs:
> 
> if devfs waits for the driver to create device nodes, and the driver waits
> until its device entry is touched before it's loaded, how does the
> process begin?

The probe code is seperate from the code that implements what is being
probed for... it lives in a seperate ELF segment in the driver image.

Alternately, you load the driver, try the probe, and if it fails, you
discard the driver.  You can do this on a whole driver without needing
initial support for ELF sections seperating the probe code.

This presumes that in a post-link static kernel that drivers which may
be discarded live in their own sections.  This lets the kernel recover
the memory used by an unused static device.

If you have section tagging (preload,nonswappable) for boot critical
and swap path components, then the kernel loader can decide to load
only part of the kernel initially.  You could then also have the
scenario where you have all devices linked into the kernel, and the
kernel's disk footprint was much larger than the kernels memory footprint.
This is actually a less desirable scenario, however, since it means
that it's more difficult to dynamically add things like third party
drivers and FS's.


I personally have a preference for /libexec and /usr/libexec for
boot-path and non-boot-path components for things like file systems.

The boot FS must be statically linked for the kernel to be able to
find additional components, but after that, what's needed?  Basically,
a way to hook a new FS into the FS commands (mount/fsck/etc.) and
a way to get the code into the kernel on demand.

A probe=true is the definition of an "arrival event".


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712161914.MAA19768>