Krzysztof Halasa <[EMAIL PROTECTED]> écrit :
[...]
> 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)
I
Francois Romieu <[EMAIL PROTECTED]> 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:
> str
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
>
Jeff Garzik <[EMAIL PROTECTED]> writes:
> First of all, you as the HDLC subsystem maintainer have a lot more
> control over what goes into include/linux/hdlc.h than
> include/linux/sockios.h. New SIOC ioctls should not be added on a
> whim, but after examination of the issues involved.
Righ
On 1 Apr 2001, Krzysztof Halasa wrote:
> Jeff Garzik <[EMAIL PROTECTED]> writes:
> > I'm not suggesting you modify ethtool for your needs :) But ethtool
> > perfectly illustrates the technique of using a single socket ioctl
> > (SIOCETHTOOL) to extend a set of standard, domain-specific ioctls
>
Jeff Garzik <[EMAIL PROTECTED]> writes:
> I'm not suggesting you modify ethtool for your needs :) But ethtool
> perfectly illustrates the technique of using a single socket ioctl
> (SIOCETHTOOL) to extend a set of standard, domain-specific ioctls
> (ETHTOOL_xxx) to Linux networking drivers.
I
On 29 Mar 2001, Krzysztof Halasa wrote:
> Jeff Garzik <[EMAIL PROTECTED]> writes:
>
> > > Maybe it's a better idea to have just two ioctl's here (GET and SET), and
> > > have "subioctl's" inside the structure passed to the HDLC layer (and
> > > defined by the HDLC layer). This would allow chan
> > Parameters for retransmission of a trame specified in Q922. t200 is the
> > timeout value and n200 the maximal number of retransmissions. They can
> > be negocied and default to t200=1,5s, n200=3.
>
> Hmm... I've taken a look at it, but it seems to me that they are only
> used with "acknowled
Jeff Garzik <[EMAIL PROTECTED]> writes:
> > Maybe it's a better idea to have just two ioctl's here (GET and SET), and
> > have "subioctl's" inside the structure passed to the HDLC layer (and
> > defined by the HDLC layer). This would allow changes in the HDLC layer
> > without having to change so
Francois Romieu <[EMAIL PROTECTED]> writes:
> Parameters for retransmission of a trame specified in Q922. t200 is the
> timeout value and n200 the maximal number of retransmissions. They can
> be negocied and default to t200=1,5s, n200=3.
Hmm... I've taken a look at it, but it seems to me that t
"Paul Fulghum" <[EMAIL PROTECTED]> writes:
> > +struct hdlc_physical /* 10 bytes */
> > +{
> > + unsigned int interface;
> > + unsigned int clock_rate;
> > + unsigned short clock_type;
> > +};
>
> What about encoding (NRZ/NRZI)?
>
> Plus I think the CRC type would be a good idea for
> raw HDLC
Ivan Passos <[EMAIL PROTECTED]> writes:
> I guess 'interface' means media type (e.g. V.35, RS-232, X.21, etc.).
> Maybe it would be more intuitive to call it 'media'. What do you think?
Probably.
> Also, for synchronous cards that have built-in DSU/CSU's (such as the
> Cylades-PC300/TE), it's a
Krzysztof Halasa <[EMAIL PROTECTED]> écrit :
[...]
> That's a physical interface like V.35 or RS232.
Ok.
[...]
> > * n200, t200 ?
>
> What's that?
Parameters for retransmission of a trame specified in Q922. t200 is the
timeout value and n200 the maximal number of retransmissions. They can
be n
From: "Krzysztof Halasa" <[EMAIL PROTECTED]>
> +struct hdlc_physical /* 10 bytes */
> +{
> + unsigned int interface;
> + unsigned int clock_rate;
> + unsigned short clock_type;
> +};
What about encoding (NRZ/NRZI)?
Plus I think the CRC type would be a good idea for
raw HDLC mode. (CRC-16, CRC-
On Wed, 28 Mar 2001, Jeff Garzik wrote:
> Ivan Passos wrote:
> > Maybe it's a better idea to have just two ioctl's here (GET and SET), and
> > have "subioctl's" inside the structure passed to the HDLC layer (and
> > defined by the HDLC layer). This would allow changes in the HDLC layer
> > withou
Ivan Passos wrote:
> Maybe it's a better idea to have just two ioctl's here (GET and SET), and
> have "subioctl's" inside the structure passed to the HDLC layer (and
> defined by the HDLC layer). This would allow changes in the HDLC layer
> without having to change sockios.h (you'd still have to c
On 28 Mar 2001, Krzysztof Halasa wrote:
>
> What about a patch like this:
> That would move interface configuration out of private ioctl range,
> making it universal for all types of interfaces (now, we have different
> configuration mechanisms even between different HDLC cards).
Yes! This would
Francois Romieu <[EMAIL PROTECTED]> writes:
> > +struct hdlc_physical /* 10 bytes */
> > +{
> > + unsigned int interface;
> > + unsigned int clock_rate;
> > + unsigned short clock_type;
> > +};
>
> What do you mean with 'interface' ?
That's a physical interface like V.35 or
Krzysztof Halasa <[EMAIL PROTECTED]> écrit :
[...]
> making it universal for all types of interfaces (now, we have different
> configuration mechanisms even between different HDLC cards).
Alas :o(
> +struct hdlc_physical /* 10 bytes */
> +{
> + unsigned int interface;
> + unsigne
Hi,
What about a patch like this:
That would move interface configuration out of private ioctl range,
making it universal for all types of interfaces (now, we have different
configuration mechanisms even between different HDLC cards).
Of course, *_protocol and *_physical struct for other type of
20 matches
Mail list logo
