[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    kldload(2) family (was Re: loadable aio)
From:       Mike Barcroft <mike () FreeBSD ! ORG>
Date:       2001-12-31 9:36:33
[Download RAW message or body]

[Moved to -arch, BCC'd to -hackers.]

Peter Pentchev <roam@ringlet.net> writes:
> Okay, so it's not documented in the manual, but one look at the source
> should suffice :)

:(

> As Mike said, there is a search path.  However, the current directory
> is tried first.  If a file by that name is not found in the current
> directory, the search path is, well, searched ;)  The search path
> is available in the kern.module_path sysctl or in the output of
> 'kldconfig -r'.

Oh no, it's worse than I feared.

> This is similar to what shells have been doing for decades, with
> the added feature of an implicit '.' at the start of the search path.

Yes, the usual approach shells take is much better designed.

Here's how I would design this interface:
o _kldload(2) accepts a file path (similar to open(2))
o kldunload(2) accepts a filename (no path)
o kldload(3) accepts a module name (procfs), file name (procfs.ko), or
  file path (/boot/kernel/procfs.ko).
o Search paths for kldload(3) are controlled by the environment
  variable `KLDPATH' (similar to MANPATH and PATH).
o When kldload(3) locates a module file, it calls _kldload(2).
o kldload(8) uses kldload(3)
o kldunload(8) uses kldunload(2)

The main advantage of this design is that it allows a Unix programmer
to utilize it. :)

Best regards,
Mike Barcroft

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
[prev in list] [next in list] [prev in thread] [next in thread]