[ moved from source-changes to tech-net ]

I've committed the changes.

> Modified Files:
> 	basesrc/sbin/ifconfig: ifconfig.c
> 	syssrc/sys/dev/ic: awi.c
> 	syssrc/sys/dev/pcmcia: if_ray.c if_wi.c if_wivar.h
> 	syssrc/sys/net: if_ieee80211.h
> 
> Log Message:
> change the argument of SIOCS80211NWID and SIOCG80211NWID ioctls from
> u_int8_t array to struct ieee80211_nwid to prepend length field.
> The length field is necessary because IEEE 802.11 spec doesn't prohibit
> even '\0' for SSID.
> Though the name and the value of SIOC... macro is unchanged, this change
> breaks binary compatibility.  The only affected userland program on the
> tree is ifconfig(8).
> As Jason suggested on tech-net, it is better than live with problems
> since there are no releases for this ioctls yet.

[itojun]
> 	i'm not sure if I'm correct, but I thought that jason suggested to
> 	deprecate the old ioctl number and assign new ioctl number to
> 	SIOCS80211NWID, so that:
> 	- old binary would get EINVAL on new kernel
> 	- new binary works happy with new kernel
> itojun

[Jason]
> It should be fine -- since the size of the argument changed, a new
> ioctl value (as computed by the _IOW macro) is "magically" allocated.

[enami]
> The size of the argument isn't changed.  It's still struct ifreq.  The
> real value are passed though ifr_data.

I don't think we should reserve old ioctl number for deprecated ioctls.
It is only 8bit space for each group.  Changing the size of struct is
fine to change the macro value with same number in most cases.
Unfortunately, both SIOCS80211NWID and SIOCG80211NWID uses just struct
ifreq which doesn't includes the length of data.
Replacing the struct from ifreq to some others would be better for
general cases like this, IMHO.

But in this case, only affected is ifconfig for wireless LAN cards.
- old ifconfig on new kernel
	- setting nwid
		just failed with EINVAL unless nwid is ""
		(the first octet is interpreted as length which
		 must be between 0 to 32)
		overrun in copyin from user stack would be harmless.
	- getting nwid
		overrun in copyout to user stack.
		print control code to display
		(control code can be included in nwid, anyway)
- new ifconfig on old kernel
	- setting nwid
		succeeded but cannot connect to AP unless nwid is ""
	- getting nwid
		possible overrun at printing nwid
			-> ... this is bug and should be fixed, sorry

Since nwid stuff is not released yet, I don't think it is fatal problem.
So I'd like to leave current changes.

Atsushi Onoe