Certainly. Please keep in mind that the explanation below is a
simplification...
One of the fundamental concepts of UDI is that code executes within
one or more "regions" where a region is a formal construct within
UDI. Each region is "scheduled" based on I/O requests and interrupts.
The only interface that a region has with the operating system is
through the defined UDI interface operations (thus insuring
portability).
For certification and validation, the driver code can be tested (via
many methods including source analysis, symbol references, etc) to
verify that it does not use any non-UDI operations.
A related concept within UDI is that the environment is allowed to be
only as trusting as it desires about driver regions. Should it so
choose, the environment can perform many tests to validate the
parameters of UDI operations invoked by the region. The obvious
tradeoff is speed v.s. reliability, but one can imagine a
"certification" or "testing" process using a region with zero trust to
validate a driver before distributing it for use in fast and fully
trusting regions. The environment can go even further in validating
the region; to provide portability the driver is not allowed to access
global memory (e.g. the u structure, etc.) so it's conceivable that
when "scheduling" a region into the run state that only the memory
accessible to that region is writeable and all other memory is set to
fault if read or written, thereby allowing the environment to
establish a fault handler to detect if the region code is violating
the access rules.
The final step is that once the environment has determined that a
region is behaving irrationally, the environment can mark the region
(and possibly related regions) so that they are never scheduled for
execution again. This will render the device unuseable unless active
steps are taken, but will hopefully leave the system itself functional
rather than coming in to work to find a panic message as a result of a
bad driver.
>
>
> >One perspective that hasn't been discussed is that UDI may *force* hardware
> >vendors to write better drivers... if they don't someone else will (at
>
> No need. You can just specify in the specification that in order to obtain
> certification for a UDI conformant device, hardware vendor must either provide
> an open source driver or provide hardware specs for the device in question such
> that someone else can write an open source driver instead.
UDI is a technical specification. It provides exactly the same
capabilities that currently exist for delivering drivers: binary or
source.
The decision of whether to release source or not should be the
decision of the driver writer (or company as the case may be).
Freedom means freedom of choice. Legislated freedom is an oxymoron.
>
> >better drivers). Isn't that already how the game is played already
> >except that with UDI its more of a "winner take all" situation? Since
>
> I'm sorry to disappoint you, but the game should be played such that all sides
> win.
I think perhaps I didn't make my point clearly enough. If you write
the "better" driver then UDI would allow more people to use it rather
than just the Linux community.
In the above, "better" is defined by the consumers. Sometimes it will
mean source availability. Sometimes it will mean reliability.
Sometimes it will mean performance. Usually it will mean a
combination of the above.
>
> The deal is about drivers, drivers for all parties. All parties have produced
> or have been involved in producing a number of drivers for various hardware
> devices. Some of these have been implemented on all platforms, some in a
> smaller number of platforms.
>
> Right now, everybody is producing their own drivers, duplicating the work of
> others. A possible improvement on the situation is such that everybody works
> together on drivers, and of course everybody benefits from produced drivers. As
> equal, all parties must be able to produce an UDI conforming driver if there
> is a UDI conforming device out there that isn't supported in a UDI conforming
> environment.
>
> Everybody has its own peculiarities, and open source's is that it's free. Since
> UDI project members count on open source community to help in the effort, it
> would be fair if this peculiarity is taken into account.
UDI exists in a broad community of which Linux is only a part. UDI
project members don't "count" on the help of the open source
community... we "welcome" the help of the open source commmunity.
UDI will continue to exist even if no one in the open source community
does anything to help. This is not a threat; it's pragmatism.
It's frustrating that I don't seem to be able to correct the
misinterpretation of my quote in the trade journals.
>
> >winning is likely to be based on stability, performance, and features,
> >there's every reason for a Linux developer to expect that they can
> >"win".
>
> I would, and I'm quite certain that a number of Linux developers would also,
> enjoy such a deal. It's always good to keep a good competitive
> spirit.
Well said!
>
> Andrej
>
> --
> Andrej Presern, andrejp@luz.fe.uni-lj.si
>
Regards,
Kevin
-- ________________________________________________________________________ Kevin Quick Interphase Corporation Engineering Dallas, Texas kquick@iphase.com http://www.iphase.com 214.654.5173- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/