Krzysztof Halasa <[EMAIL PROTECTED]> écrit :
[...]
> > Comments welcome.  IMHO domain-specific ioctls are a better direction
> > than the current make-sockios.h-huge-with-new-ioctls approach.
> 
> 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*

[...]
> you have to call it with:
>         proto = malloc();
>         ifreq.name = "qwe0";
>         ifreq.data = proto;
>         (int*)proto = SIOC_SET_FR_PROTO_PARAMETERS;
>         (fr_protocol)(((int*)proto) + 1).fr_protocol.t391 = 20;
>         (fr_protocol)(((int*)proto) + 1).fr_protocol.n393 = 5;
>         ioctl(s, SIOC_FR_PROTO, &ifreq);

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 = &sub;
        ioctl(s, SIOC_FR_PROTO, &ifreq);

At least it avoids digging at a special position in a structure 
to know the expected operation and the underlying structure.

struc sub_req {
        int sub_ioctl;
        union {
                struct fr_protocol fr_prot;
                ...
                struct xx_protocol xx_prot;
        }
}

struct if_req {
        int name;

        struct sub_req sub;
}

It could avoid a flat name-space. Opinion anyone ?

-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to