"T. Ribbrock" wrote: > > On Fri, Jan 10, 2003 at 10:41:45AM +0100, abel deuring wrote: > [...] > > The SS20 is as 32 bit machine, so this looks indeed like a 32/64 bit > > problem. > > > > But is there really no way to compile Sane as a 64 bit program on an > > UltraSparc? > > I jst checked back with some Aurora folks and they confirmed what I > already thought: Userland on UltraSparc is mostly 32bit - only where > it's really needed 64bit is used. 32bit apps and libs are also assumed > to be faster. > > For sane this means that to compile sane 64bit one would have to > (re-)build *all* related libraries (starting with libc, libm, etc.pp.) > 64bit - quite a lot of work.
So you run *only* 32 bit applications? > > The default is 32bit, so I'd say that sane should be able to cope with > that... :-} I asked Doug Gilbert, the maintainer of the SG driver, for hints how to solve the problem. While he agrees with my diagnosis, he had no easy solution at hand. It simply does not work to pass 32 bit pointers from a application, where the kernel expects 64 bit pointers. Using the old SG interface would make things a bit easier, because no pointers are passed as parameters. But the size of the ints in struct sg_header might nevertheless be a problem. > > > Another option could be to define a "64 bit version" of struct sg_io_hdr > > in sanei_scsi.c and to use this struct for SG driver write calls. I am > > not sure though, if it is simply possible to convert 32 bit pointers to > > 64 bit pointers by filling in leading zeros. Would be good to know a bit > > more, how 32 bit programs are run on the 64 bit platform. > > Unfortunately, neither do I know this. Has that issue been resolved > for Alpha machines? I don't know. But according to Doug , similar problems exist for Itanium processors. Abel
