Very Computer

by **David L. Markowi** » Sat, 03 Jul 1993 03:44:55

Does a SPARC Solaris driver run on x86 Solaris? Are
any changes needed? If so, is it a big deal, or trivial?
--

David L. Markowitz
Solaris Systems Division - Genisco Technology Corporation

by **Ed Whittemo** » Thu, 08 Jul 1993 10:11:13

>Does a SPARC Solaris driver run on x86 Solaris? Are
>any changes needed? If so, is it a big deal, or trivial?
>--

> David L. Markowitz
> Solaris Systems Division - Genisco Technology Corporation

What do you mean? Can unmodified sparc binaries run on intel processors?

No. Can unmodified code written to machine specific interfaces be

recompiled on intel machines? No.
--

American Micro Group, Inc. 201-944-3293

by **Joerg Miche** » Thu, 08 Jul 1993 22:47:44

It is the idea of the DDI/DKI to enable such a transition. In particular,
if you have the source for, say a SCSI device, you should be able to
compile it under both x86 and SPARC and get it running without modification.
In general, I think, this is a little bit more difficult to achieve, since
you will have to handle the different register layout of the bus-specific
adaptor you are talking to.

Joerg

--
GMD German National Research Center for Computer Science
FOKUS Open Communication Systems Research Center
Berlin, Germany

by **Guy Harr** » Fri, 09 Jul 1993 03:19:53

Quote:>In general, I think, this is a little bit more difficult to achieve, since
>you will have to handle the different register layout of the bus-specific
>adaptor you are talking to.

SCSA (Sun Common SCSI Architecture) *might* handle that, as it has
separate bits of driver code for SCSI adapters and SCSI targets; you may
be able to have a target driver that can work with SCSI adapters both on
various SPARC-based machines and with various PeeCee SCSI adapters - the
target driver doesn't have to know about the register layout of the
adapter, that's the adapter driver's job.

Dunno if SCSA is used in Solaris 2.x for x86; I think it's used in all
SCSI drivers in Solaris 2.x for SPARC.

by **Joerg Miche** » Fri, 09 Jul 1993 04:40:48

|> >In general, I think, this is a little bit more difficult to achieve, since
|> >you will have to handle the different register layout of the bus-specific
|> >adaptor you are talking to.
|>
|> SCSA (Sun Common SCSI Architecture) *might* handle that, as it has

Correct. With "In general" I ment non-SCSI device drivers. Usually, the
leaf (adaptor specific) driver will poke around in registers directly,
thus must have knowledge of the register layout. The "same" adaptor
(read as "same functionality, different primary bus system") has probably a
different layout when manufactured for different busses. All this is
not the case with SCSI.

Joerg

--
GMD German National Research Center for Computer Science
FOKUS Open Communication Systems Research Center
Berlin, Germany

by **Dan Mi** » Thu, 22 Jul 1993 06:14:01

It is certainly possible to port drivers more easily than in the past.
The DDI/DKI codifies a lot of the behaviour of the kernel with respect
to drivers. Solaris 2.1 for x86 does advertise the same SCSA interface
as Solaris for SPARC; SCSA-compliant target drivers, in fact, port with
almost no effort. I personally have run the same character-mode driver
on both Solaris SPARC and Solaris x86.

There are one or two minor differences in SCSA having to do with
physical DMA on the x86 platform (it's Virtual DMA on the SPARC); the
I/O request may need to be deblocked to handle the discontiguous
physical space.

This same difference (DMA) exists for non-SCSA drivers, and of course
most x86 devices have a different bus interface (using I/O ports
rather than memory-mapped registers), but the facilities for accessing
everything besides DMA and I/O ports are exactly the same, and DMA
is very similar. Porting shouldn't be hard if the hardware has
essentially the same capabilities on a different bus.

Anyone interested in porting drivers to x86 should inquire about a copy
of the Device Developer's Kit for x86; it's Sun part number 792-1692-01.
Not sure of price, but I know it's a token amount to cover production
costs.