[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
useful libraries (includes NIC drivers)
- Date: Tue, 10 Aug 1999 11:08:04 -0400 (EDT)
- From: qqi at world.std.com (Quality Quorum)
- Subject: useful libraries (includes NIC drivers)
On Tue, 10 Aug 1999, ccaudle wrote:
> I found some libraries which look like they might be very useful.
> Take a look at:
> 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
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
> I'll post that and the results of my first tests with these libraries in a few
> -- Chris Caudle