useful libraries (includes NIC drivers)

[qqi at world.std.com (Quality Quorum)]

On Tue, 10 Aug 1999, ccaudle wrote:

> I found some libraries which look like they might be very useful.
> 
> Take a look at:
> http://www.cs.utah.edu/projects/flux/oskit/
> 
> This is part of a research project at the University of Utah dealing with OS 
> and language interactions.  To facilitate their research, they have bundled 
> libraries of components which can be reused as support pieces for other 
> operating systems.  These include device drivers, file systems, name space 
> implementations, and X client libraries.
> 
> What caught my attention is that the libraries include the FreeBSD network 
> stack, and the device drivers for SCSI, IDE, and network devices from Linux 
> 2.0.29.

There is a problem here - Linux has license incompatible with intended
use of RTEMS.
 
> All these libraries use a consistent interface, and are fully documented as to 
> the functions which the OS using the libraries is required to supply.
> The libraries currently have X86 code only for hardware-dependent code, but 
> since the drives are based on Linux code pretty much verbatim, any drivers 
> which also run on other Linux ports should be portable using these libraries 
> (Alpha, MIPS, ARM, Sparc, etc.).
> 
> The documentation addresses performance concerns.  Since the libraries have a 
> layer of wrapper code around the FreeBSD network code and the Linux filesystem 
> and device driver code, you do take a performance hit.  The performance 
> reduction is small, so you will have to decide on a case by case basis whether 
> the hit is too large (and also whether the code is too large).
> 
> The nice thing about these libraries from a development stand point is that 
> the functionality is well debugged, and the interface is very well defined and 
> extensible (based on the concepts of Component Object Model), so you can 
> develop using these libraries, and if the code is too large, or performance 
> too slow, you can reimplement some or all of the code to suit your needs; if 
> you keep the same interface, that should be the only thing you have to change, 
> the rest of the app can remain the same.
> 
> I hope to have a first cut of an RTEMS support file in about a day or two, 
> which will map the functions needed by these libraries to RTEMS function 
> calls.
> I'll post that and the results of my first tests with these libraries in a few 
> days.
> 
> -- Chris Caudle
> 
> 

Thanks,

Aleksey