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
19 matches
Mail list logo
