[EROS-Arch] UDI project

[Ben Laurie]

Norman Hardy wrote:
> 
> 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.

There is, actually: CAM.

> 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.

?? SCSI certainly does not - the standard has nothing to do with RAM.
CAM does, though, because typically SCSI controllers use DMA, so there
isn't much option.

> 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.

If you want to see CAM in action, then just look at any old FreeBSD SCSI
driver (or, probably, Linux).

Cheers,

Ben (who used to write SCSI device drivers).

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

ApacheCon 2001! http://ApacheCon.com/