In  <el2vigymvvf.fsf@zygorthian-space-raiders.MIT.EDU> , you wrote:

> 
> Matt Thomas <matt@lkg.dec.com> writes:
> 
> > 
> > I agrree with Chris that this should go into struct ifnet.
> > if_media is fine with me.
> 
> Seems to me that `medium' would be more appropriate.

Whatever.

> > And SIOC[GS]MTU too.
> 
> I'm really not convinced that this is useful for most interfaces.

It's very useful for FDDI (sometime you want to shirnk the MTU of link
to 1500 to bypass bridges which can't fragment).  Now if IP would
actually use the rt_rmx.rmx_mtu field for doing fragmentation, I might
agree with you.  But it doesn't so you need way of controlling the MTU
of an interface.

> > What do you do about media with full-duplex support?  (Note
> > that you can do full-duplex on FDDI too if you use the DEC
> > FDDI adapters).
> 
> I don't see how this is relevant.  There is already a mechanism (using
> IFF_SIMPLEX) to deal with it, and there's no reason to expose this
> directly to the user.

Full Duplex is completely orthogonal to IFF_SIMPLEX.  I'm talking about
full-duplex at the physical level.  10baseT full duplex (ie. suppress
collision circuitry and run rx/tx at the time).

> > Another problem is that ifreq is too limiting and lead to a proliferation
> > of ioctls.
> >
> > [...]
> >
> > You could then use value[0] as an option id and value[1] as the data:
> > 
> > #define	ifr_attr_id	ifr_ifru.ifru_values[0]
> > #define	ifr_attr_value	ifr_ifru.ifru_values[2]
> 
> A switch table by another name is still a switch table.  Add the
> annoyance of needing to emulate the old ioctl(2) calls, and it really
> doesn't seem worthwhile.

If I want to implement a local ioctl (say setting the beacon and
domain keys for a WaveLAN card), it would be nice to be able to do
so without have to 1) eat the ioctl space and 2) not change any other
header files but the ones for the driver.

-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt.html
Westford, MA              Disclaimer: I disavow all knowledge of this message