Messages in this thread | | | Subject | Re: RFC: configuring net interfaces | From | Krzysztof Halasa <> | Date | 03 Apr 2001 15:07:01 +0200 |
| |
Francois Romieu <romieu@cogenit.fr> writes:
> > I think we should separate two things there: > > - the place (files) where SIOCxxx values are defined > > - the way we use ioctl call. > > (1) and (2) may be related: > no sub-ioctl (2) + scattered files (1) = *ouch*
Sure.
> Variant: > struct sub_req sub; > > sub.fr_protocol.t391 = 20; > sub.fr_protocol.n293 = 5; > sub.sub_ioctl = SIOC_SET_FR_PROTO_PARAMETERS; > ifreq.name = "qwe0"; > ifreq.data = ⊂ > ioctl(s, SIOC_FR_PROTO, &ifreq);
Yes, it's a little nicer than my second variant. But it's still more complicated than the first one and I'm not sure if doing that is worth it
> struc sub_req { > int sub_ioctl;
... as we lose 4 bytes here (currently the union of structs in ifreq is limited to 16 bytes)
> union { > struct fr_protocol fr_prot; > ... > struct xx_protocol xx_prot; > } > }
What might be actually better than my first variant, is a variable-length data:
struct ifreq { char name[16]; union { ... struct { int sub_command; int data_length; void *data; } }ifru; }
... while "data" would be fr_protocol, eth_physical etc.
It's (of course) more complicated, but there is a gain: - we can have different size requests (from 0 bytes to, say, 100KB) - we split SIOC namespace into domains - the core ioctl handler can still "verify" data area for the underlying driver -- Krzysztof Halasa Network Administrator - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |