On Wed, 14 Feb 2001, Robert Lipe wrote:
> Gérard Roudier wrote:
>
> > Being smart with kernel interface is important for drivers to be fast and
> > reliable. Puting some stinky layer between native kernel interfaces and
> > drivers looks horrible to me.
>
> Fast and reliable are both covered.
>
> For example, the specification (though not the current reference
> implementation) allows things like having different drivers and even
> different instances of the same driver in separate address spaces. Want
> to debug your driver in user space? It could happen. Reliability
> can be realized by making it impossible for a driver to panic the
> system. (And I do realize that flies directly in the face of fast. :-)
Certainly not full impossible. DMA at some wrong place or not handling
properly level-triggerred interrupt, for example ...
> A more recognizable reliabilty improvement is the more unified and
> constitent programming interface. No more "you can't call malloc with
> WAIT_OK while holding a spin lock on another processor at an elevated
> PL" bugs.
This looks like matter of taste to me. Unless all O/S architects since day
one until UDI have been incompetent idiots. :-)
> > Why isn't UDI proposed as a native kernel interface, instead?
>
> In at least three OSes, it will be a native kernel interface in versions
> shipping this year.
How the 'open-ness' of UDI is guaranteed?
As a corollary:
- Are these three mysterious O/Ses using some vendor-specific extensions
or undocumented differences in their UDI stuff?
- What the risk of UDI getting steered by some coalition of vendors?
- Finally, as some large collection od UDI drivers may well exist, how can
I download the source and how FreeBSD is intended to gain adavantage of
this driver collection in the future ?
> The current "UDI Demarcation Point" isn't fixed. It can be moved to
> suit the needs of the host OS. As a practical matter, the thickness of
> that "layer" is very slim at runtime, so the potential gains aren't as
> large as some imagine they are.
I want to beleive you here.
> In its early life, a very natural way to bring up the UDI interface
> (remember, we were developing spec, drivers, and environment
> simultaneously) was to do it in terms of existing kernel interfaces.
> UDI and the existing interfaces could be implemented side-by-side. In
> many cases, you could even make UDI the primary interface and implement
> another interface -perhaps the current interface for compatibility- in
> terms of UDI. I'm looking at doing exactly this in some of my OSes.
Was the main point of my question. Thanks for the reply.
> Besides, if I walked into this crowd and said, "Here's a new driver
> interface and a megabyte of patches to /usr/src/sys. Whaddya think?",
> how quickly would you have thrown me out? That's what I thought. :-)
A mega-byte large patch is not that unusual nowadays. :-)
> Now repeat that exercise for a dozen or so OSes...
Only. :-)
Gérard.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
