ioctl() 64-bit issues
ssmailys at komvista.lt
Tue Nov 2 12:22:47 PST 2004
Last time I forgot to cc to the list.
Peter Wemm wrote:
> On Tuesday 02 November 2004 12:56 pm, Stasys Smailys wrote:
>>Peter Wemm wrote:
>>>If you have a look at cdrio.h:
>>>#define CDRIOCGETPROGRESS _IOR('c', 111, int)
>>>And the implementation is:
>>> case CDRIOCGETPROGRESS:
>>> error = acd_get_progress(cdp, (int *)addr);
>>>#define CDRIOCSENDCUE _IOW('c', 104, struct cdr_cuesheet)
>>>burncd.c: if (ioctl(fd, CDRIOCSENDCUE, &sheet) < 0)
>>> case CDRIOCSENDCUE:
>>> error = acd_send_cue(cdp, (struct cdr_cuesheet *)addr);
>>>Our ioctl wrapper code causes a copyin/copyout according to the
>>>IOR/IOW encoding. It should be an int, and is being accessed as
>>>though it were an int within the kernel.
>>I think you are somewhere right. But anyway I can't
>>CDRIOCGETPROGRESS. Can it be only my CDRW drive's issue?
>>>If I had to guess, I'm wondering if you got this info from gdb.. I
>>>don't trust gdb for this stuff yet. I'd be more concerned if it
>>>was printf("pct %d\n", pct) that told you this. If you want to
>>You're right. I was using printf() to get values.
>>>something, set pct to 12345 right before the ioctl call in case
>>>you're looking at random contents or something.
>>Done. Getting "burncd: ioctl(CDRIOCGETPROGRESS): Inappropriate ioctl
>>for device". Seems to be fine, but pct still has 0.
> Well, this means that nothing is updating the 'pct' value because the
> ioctl isn't executed at all. So you were seeing the previous random
> contents. The big question is though... why doesn't the driver
> recognize the ioctl?
I don't know. I'll check tomorrow. It's late already.
> Here's a silly thought.. you dont have a 32 bit burncd binary lying
> around in your path by any chance, do you?
No. It is impossible.
# file `which burncd`
/usr/sbin/burncd: ELF 64-bit LSB executable, AMD x86-64, version 1
(FreeBSD), dynamically linked (uses shared libs), stripped
More information about the freebsd-amd64