kern/104675: Apparently there is a clash between two ioctls

[Bruce Evans]

The following reply was made to PR kern/104675; it has been noted by GNATS.

From: Bruce Evans <bde at zeta.org.au>
To: "Jukka A. Ukkonen" <jau at iki.fi>
Cc: FreeBSD-gnats-submit at FreeBSD.org, freebsd-bugs at FreeBSD.org
Subject: Re: kern/104675: Apparently there is a clash between two ioctls
Date: Sun, 22 Oct 2006 23:24:10 +1000 (EST)

 On Sun, 22 Oct 2006, Jukka A. Ukkonen wrote:
 
 >> Description:
 > 	It seems that the bktr driver cannot change the input connector
 > 	used when using a card with multiple connectors.
 > 	When I used ktrace to see what happens at the kernel API level
 > 	I got somewhat disturbing output...
 >
 > 56314 try      CALL  ioctl(0x3,METEORGINPUT,0xbfbfed24)
 > 56314 try      RET   ioctl 0
 > 56314 try      CALL  ioctl(0x3,SERIAL_SETINVCLK,0xbfbfed20)
 > 56314 try      RET   ioctl 0
 > 56314 try      CALL  ioctl(0x3,METEORGINPUT,0xbfbfed20)
 > 56314 try      RET   ioctl 0
 >
 >      It seems that METEORGINPUT is recognized properly but its
 >      complement METEORSINPUT is not. Instead METEORSINPUT gets
 >      mapped to something completely unrelated (SERIAL_SETINVCLK).
 
 This is probably not the real problem.  There are too many ambiguous
 ioctls for kdump to fix, so kdump carefully avoids seeing the problem
 by not invoking mkioctls with -s.  But this is only a debugging problem.
 The ioctl numbers are unique for each device, so device drivers have
 no problems with their ambiguity.  To do the same for just the above,
 kdump would have to determine that fd 0x3 is for bktr and use bktr's
 ioctl switch statement instead of Cronyx serial's one.  It now just
 uses an elseif ladder that has all the ioctls but only finds the
 first match.
 
 Bruce