[Prev][Next][Index][Thread]
RE: COM completeness
> One of the things that intrigues me about the OsKit design is the possibility
> that it might be a good starting point for a family of universal drivers. I
am
> inclined to suspect that if a universal kernel driver model existed, it would
> become easier to persuade vendors to do drivers for operating systems, and
easier
> for research systems to have a rich set of drivers.
> In order for this to be possible, it is necessary to be able to implement the
> NetBSD, Linux, etc. driver interfaces on TOP of the corresponding OsKit
> interfaces (presumably with a suitable translation layer). This exercise
would
> be an interesting test of the "completeness" of the COM-defined APIs. I am
curious
> if anyone has tried this, even as a "thought experiment."
Interesting question.
It is, perhaps, possible to do coarsely. After all, we have various
filesystems and a network stack running on top of devices from different OSs.
What is most obviously missing is an interface to things like number of RX
packets, size of TX queue and all the other things you can normally observe
about a device.
The obvious problems in adding that information back in are:
1) The various OSs probably differ in minor ways in what they choose to make
available. We have to come up with a superset of all those requirements and
decide which pieces of info are really the same thing. This could get
difficult if any OS assumes that all devices of a given type can provide a
certain piece of information but this turned out to be true only for the subset
of the devices that they support.
Of course, this would be no problem if we could persuade the OS hackers to
adapt to our standard - but I think we'd have to start by showing that it is
feasible by adapting to their standards.
2) What would the interface for all this information look like? Given the
number and variety of different counters and strings and ..., I suspect it
would be similar to the ioctl interface (i.e., a random messed of untyped bits
flowing across the interface). Blech!
Oh, and a couple of other (potentially serious) problems:
1) BSD systems use mbufs whereas Linux uses contiguous buffers. We'd want to
be very sure that no system incurred extra copies as a result of this
restriction. This probably means extending the bufio abstraction with
mbuf-like operations. (This has been talked about a number of times. We might
even have done it already(??))
2) Linux drivers assume that buffers have the same virtual and physical
addresses. If any of our client OSs don't satisfy that property, we have to
copy buffers whenever they're passed to a Linux-derived driver. (Again, not a
problem in the long term (i.e., once we rule the world) but a serious problem
in the short term.)
We're planning to use Knit (see our OSDI paper) to enforce the second
restriction and, perhaps, to generate warnings about the overhead when you
configure the system in a way that does incur copies.
--
Alastair Reid
References: