public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@intrepid.pm.waw.pl>
To: <linux-kernel@vger.kernel.org>
Subject: Re: RFC: configuring net interfaces
Date: 29 Mar 2001 13:24:59 +0200	[thread overview]
Message-ID: <m3y9to6cms.fsf@intrepid.pm.waw.pl> (raw)
In-Reply-To: <Pine.LNX.4.30.0103281558140.15795-100000@intra.cyclades.com>
In-Reply-To: Ivan Passos's message of "Wed, 28 Mar 2001 16:24:19 -0500 (EST)"

Ivan Passos <lists@cyclades.com> 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 also necessary to configure T1/E1 parameters
> (e.g. line code, frame mode, active channels, etc.). Should we make these
> parameters also available here or keep them in the driver realm?? I think
> we should have them here too, but maybe you see some problem with this
> that I don't.

No problem. That was just an example.

> > +struct hdlc_protocol		/* 4 bytes */
> > +{
> > +	unsigned int proto;
> > +};
> 
> What are the possible protocols to be set here?? I imagine PPP, Cisco
> HDLC, Raw HDLC, Frame Relay, X.25, and ... ?? Is that it??

Exactly.

> > +struct fr_protocol		/* 12 bytes */
> > +{
> > +	unsigned short lmi_type;
> > +	unsigned short t391;
> > +	unsigned short t392;
> > +	unsigned short n391;
> > +	unsigned short n392;
> > +	unsigned short n393;
> > +};
> 
> So we would have hdlc_protocol->proto set to PROTO_FR, and then the
> details about Frame Relay would be set in this separate structure. Is that
> what you have in mind??

Exactly. With defaults filled in by the (some) driver.

> 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 change HDLC's
> code and definitions, but this would be more self-contained). Again, this
> may be better, or maybe not. What do you think?

I think it would make it more complicated. ioctl namespace is huge enough.
Without changing ifmap struct size (which would require recompilation
of all programs using it - ip, ifconfig etc), the *_protocol/physical
structures can only be 16 bytes long each (8 shorts or 4 ints) - I would
rather not put command code there.

Of course, the structs I outlined are just an example, which need
checking for max and min values and then setting variable length
(int/short/char).
-- 
Krzysztof Halasa
Network Administrator

  parent reply	other threads:[~2001-03-29 11:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m3itkuq6xt.fsf@intrepid.pm.waw.pl>
2001-03-28 21:24 ` RFC: configuring net interfaces Ivan Passos
2001-03-29  0:11   ` Jeff Garzik
2001-03-28 21:53     ` Ivan Passos
2001-03-29 11:29     ` Krzysztof Halasa
2001-03-30  5:43       ` Jeff Garzik
2001-03-31 22:41         ` Krzysztof Halasa
2001-04-01 22:18           ` Jeff Garzik
2001-04-02 19:10             ` Krzysztof Halasa
2001-04-03  8:27               ` Francois Romieu
2001-04-03 13:07                 ` Krzysztof Halasa
2001-04-04  8:18                   ` Francois Romieu
2001-03-29 11:24   ` Krzysztof Halasa [this message]
     [not found] ` <20010328182729.A16067@se1.cogenit.fr>
2001-03-28 23:03   ` Krzysztof Halasa
2001-03-29  0:13     ` Paul Fulghum
2001-03-29 10:34       ` Krzysztof Halasa
2001-03-29  9:25     ` Francois Romieu
2001-03-29 11:07       ` Krzysztof Halasa
2001-03-29 14:55         ` Paul Fulghum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3y9to6cms.fsf@intrepid.pm.waw.pl \
    --to=khc@intrepid.pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox