Very Computer

Hi,
I have 32 bit Adapter Driver, but I am using Sun solaries new 64bit
OS.  So this driver is not working.  Is there any way to tell OS to
load this 32bit driver?

Thanks,
Raja

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

No, the 64 bit OS cannot load 32 bit drivers.  (How would a 32 bit driver
stuff a 64 bit kmem_alloc() return value in a 32 bit * variable)?

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Well, the OS could magically know that some drivers are 32-bit, and try
to reserve space for them in a region they understand...

-s
--

C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Will work for interesting hardware.  http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

Then a 64 bit process would perform a ioctl, passing a 64 bit (userland)
pointer to the 32 bit driver; and what to do on really big kernels were
you may run out of memory with 32 bits of zero at the front?

Not to mention the fact that you need to duplicate nearly all kernel
functions that are usable by drivers; have 32 bit and 64 bit version.
Map between 32 bit and 64 bit versions of public system structures (there
should be relatively few of those)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

On those really big kernls, as noted, you reserve space in the 32-bit
region.

In other words, you do what i386 people have done for ISA cards for years;
bounce buffers.

It sucks, but it *could be made to work*.

Quote:>Not to mention the fact that you need to duplicate nearly all kernel
>functions that are usable by drivers; have 32 bit and 64 bit version.
>Map between 32 bit and 64 bit versions of public system structures (there
>should be relatively few of those)

Awful, isn't it?

I'd tend to agree, you're probably better off just telling the driver writers
they lose.  However, the users of devices for which there are only 32-bit
drivers are better off if they work slowly than if they don't work at all.

-s
--

C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Will work for interesting hardware.  http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!

Quote:> In other words, you do what i386 people have done for ISA cards for years;
> bounce buffers.

That's not an appropriate analogy. On a i386 ISA system all the user
code and all the kernel code is ILP-32. The only time 24-bit (or 16-bit)
pointers come into play is for ISA adapters which support bus-mastering DMA.
In that situation only the *physical* memory addresses that are actually
passed to the adapters DMA engine need to "re-mapped" to the bounce buffers.
That's such a narrow requirement that it can be handled almost transparently
by the x86 kernel's existing DMA page translation (ALL x86 I/O is done
via physical addresses because x86 systems don't support DVMA). In other
words writing a driver for a bus-mastering ISA adapter is no harder or
different than writing a driver for a 32-bit EISA or 32-bit PCI
bus-mastering adapter.

Quote:> It sucks, but it *could be made to work*.

It not only sucks, it blows chunks. I'm not a Windows expert, but I
understand that even with the *huge* amounts of 16-bit application
compatibility *builtin to Win9x and NT, I don't think
either of those systems support 16-bit kernel mode device drivers.

Yeh, it would basically suck.  But why does Sun have the 64 bit support
bit integrated in initializing an FS driver?!?  Hum.  Damn.  Sorry to
ruin your theory, Casper.  You already do it by making us 3rd party guys
say if we are 32 or 64 bit compliant in an FS.  (I know you are just
being helpful, and I always read your messages, and that your word here
is not "official", but I had to bring it up.)

(I totally agree with the "let's cut it off here (i.e. 64 vs 32)"
concept, but this issue is interesting and _deserves_ attention.)

Mark

[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]

Quote:>Yeh, it would basically suck.  But why does Sun have the 64 bit support
>bit integrated in initializing an FS driver?!?  Hum.  Damn.  Sorry to
>ruin your theory, Casper.  You already do it by making us 3rd party guys
>say if we are 32 or 64 bit compliant in an FS.  (I know you are just
>being helpful, and I always read your messages, and that your word here
>is not "official", but I had to bring it up.)

Those are different 64 bit issues: 64 bit filesystems is for supporting
large files; that's something entirely orthogonal to having a 32 bit or
64 bit kernel address space.

I.e., you only tell whether you can acept 64 bit file offsets; not whether
you can handle 64 bit kmem_alloc() return values or 64 bit parameters.

It is possible to call 32 bit code from 64 bit code and vice versa, with some
glue.  However, you will need to restrict the 64 bit code to the lower
4GB of the address space.  And then, what's point in running a 64 bit kernel?
Just boot the 32 bit kernel instead (all 64bit bootable UltraSPARC systems
automatically support booting a 32bit kernel; it comes for free)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.