[EROS-Arch] UDI project

[Norman Hardy]

At 4:50 PM +0600 3/19/01, Constantine Plotnikov wrote:
>http://www.project-udi.org/
>
>"... This is the home page for Project UDI, a multi-company effort to define
>a Uniform Driver Interface, which provides an environment for portable
>driver code, and to establish program plans for deploying this technology.
>..."
>
>I have not seen it mentioned on eros-arch.
>
>>From first sight at spec, the project could be used in EROS and is mappable
>to capabilities (there is notion of channel). It specify both software
>interfaces and binary interfaces to drivers and has potential to solve
>problem with lack of drivers. I would like if anyone with more knowledge of
>EROS and dirvers will look into it.
>
>Constantine
>
>_______________________________________________
>eros-arch mailing list
>eros-arch@mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/eros-arch

I was struck at how much SCSI was like the 370 channels which allowed 
Keykos to remove almost all device savvy code from the kernel. There 
are two significant differences:

What IBM called "channel function" is provided mostly in software for 
SCSI. There is no standard that I have heard of for what the SCSI 
hardware stub looks like to the code.
The general privileged IO code for the 370 Keykos kernel is aware of 
neither the CPU model, nor the particular IO device in use. Network 
interface function, such as X25, is really ugly viewed thru a channel.

The other difference is that the SCSI standard defined a message 
towards the host that carried a real RAM host address from which or 
to which to transfer subsequent data. This is a really bad idea.

Firewire, (IEEE 1394) has adopted the entire SCSI convention suite 
via SPC2, if I am not mistaken. Intel has recently said that they 
like Firewire, just so long as you call it something else. Somewhere 
I saw a standard called OHCI (I think) which was a standard by which 
a program could control a PCI card that controlled a Firewire host 
interface. It looked reasonable.

There is also something called CAM (Common Access Method) which is 
supposed to be a software interface that drivers of SCSI devices 
could call to share the hardware SCSI stub.

There may be parts of a solution here. I have not laid eyes on any of 
the above rumored code. If you are interested and Google wont help, I 
think I have references somewhere.
-- 
Norman Hardy  <http://cap-lore.com/>