> > 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/