Re: reserved/local ioctl values?
> I'l looking at defining about a dozen ioctl calls for a local device driver. > When looking at the _IO, _IO, _IOW, _IOR, and _IOWR macros, I'm interested if > there are any "reserved" or "local" values for the first parameter? Not really, as such. > In short, I'd hate to use a seemly unused value, just to suddenly be in > conflict with a major set of ioctls (particularly terminal, as this is the > type of driver it will be). Also, would it be wise to reuse an existing value? If you want to add private ioctls to a given subsystem, either pick an arbitrarily high function number, or another letter that's not commonly associated with that subsystem. Eg. I would probably pick 'z' if I were going to add a local ioctl to the tty subsystem. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: reserved/local ioctl values?
> I'l looking at defining about a dozen ioctl calls for a local device driver. > When looking at the _IO, _IO, _IOW, _IOR, and _IOWR macros, I'm interested if > there are any "reserved" or "local" values for the first parameter? Not really, as such. > In short, I'd hate to use a seemly unused value, just to suddenly be in > conflict with a major set of ioctls (particularly terminal, as this is the > type of driver it will be). Also, would it be wise to reuse an existing value? If you want to add private ioctls to a given subsystem, either pick an arbitrarily high function number, or another letter that's not commonly associated with that subsystem. Eg. I would probably pick 'z' if I were going to add a local ioctl to the tty subsystem. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
reserved/local ioctl values?
I'l looking at defining about a dozen ioctl calls for a local device driver. When looking at the _IO, _IO, _IOW, _IOR, and _IOWR macros, I'm interested if there are any "reserved" or "local" values for the first parameter? In short, I'd hate to use a seemly unused value, just to suddenly be in conflict with a major set of ioctls (particularly terminal, as this is the type of driver it will be). Also, would it be wise to reuse an existing value? For instance, 'C' is used apparently by the SCSI system in /usr/include/cam/scsi/scsi_targetio.h, ISDN in /usr/include/machine/i4b_debug.h, and sound in /usr/include/machine/soundcard.h. In short, I want a value thats 'safe', in so far as I probably won't have to go back and redefine it later. I've been burned on thsi before (see majors.i386 in /usr/src/sys/i386/conf where 200-255 are now reserved... They weren't until post 2.2.6-ish when I spent 3 weeks doing tech support because one of the new device drivers in 2.2.8 conflicted with locally released code). Anyhow, good thoughts? -Brian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
reserved/local ioctl values?
I'l looking at defining about a dozen ioctl calls for a local device driver. When looking at the _IO, _IO, _IOW, _IOR, and _IOWR macros, I'm interested if there are any "reserved" or "local" values for the first parameter? In short, I'd hate to use a seemly unused value, just to suddenly be in conflict with a major set of ioctls (particularly terminal, as this is the type of driver it will be). Also, would it be wise to reuse an existing value? For instance, 'C' is used apparently by the SCSI system in /usr/include/cam/scsi/scsi_targetio.h, ISDN in /usr/include/machine/i4b_debug.h, and sound in /usr/include/machine/soundcard.h. In short, I want a value thats 'safe', in so far as I probably won't have to go back and redefine it later. I've been burned on thsi before (see majors.i386 in /usr/src/sys/i386/conf where 200-255 are now reserved... They weren't until post 2.2.6-ish when I spent 3 weeks doing tech support because one of the new device drivers in 2.2.8 conflicted with locally released code). Anyhow, good thoughts? -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
