public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Francois Romieu <romieu@cogenit.fr>
To: Ivan Passos <lists@cyclades.com>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>,
	Philip Blundell <philb@gnu.org>,
	netdev@oss.sgi.com
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
Date: Tue, 5 Dec 2000 10:38:15 +0100	[thread overview]
Message-ID: <20001205103815.A25405@se1.cogenit.fr> (raw)
In-Reply-To: <Pine.LNX.4.10.10012042135090.5269-100000@main.cyclades.com>
In-Reply-To: <Pine.LNX.4.10.10012042135090.5269-100000@main.cyclades.com>

Ivan Passos <lists@cyclades.com> écrit :
[...]
> Anyhow, the parameters we currently need to configure on our board (the
> PC300) are as follows:
> 
> - Media: V.35, RS-232, X.21, T1, E1

drivers/net/wan/lmc/lmc_media.c:65
char *lmc_t1_cables[] = {
  "V.10/RS423", "EIA530A", "reserved", "X.21", "V.35",
  "EIA449/EIA530/V.36", "V.28/EIA232", "none", NULL
};
(Where it's used btw).
I don't exactly see the point here: do some of your cards supports these
media at the same time ? I would have believed it to be set in stone.

> - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
>             already supported by the 'hw' option)

+ Transparent HDLC ?

> - Clock: 'ext' (or 0, which implies external clock) or some numeric value
>          > 0 (which implies internal clock); setting it to 'int' would set
>          it to some fixed numeric value > 0 (useful for T1/E1 links, just
>          to indicate master clock as opposed to slave or 'ext' clock) 

Ok.

[...]
> - T1/E1 only:
> 	- Line code: 
> 	- Frame mode:
> 	- LBO (T1 only): line-build-out
> 	- Rx Sensitivity: short-haul or long-haul
> 	- Active channels: mask that represents the possible 24/32
>                            channels (timeslots) on a T1/E1 line

May I ask what kind of protocol support you have in mind here ?

> I'm sure that _all_ the other sync cards need to configure the _same_
> parameters (or a subset of them), and there may be cards that need even
> more parameters (but we have to start somewhere ... ;). So having a
> unified interface and making the drivers compliant to it is not that hard
> and surely would help users to dump the currently ridiculous set of
> individual config. tools for these cards (yes, we currently have our own
> pc300cfg, along with the -- not absolute -- "standard" sethdlc utility).
> 
> I'm willing to go for this implementation, but I wanted to know first:
> - whether ifconfig is the right place to do it;

We can pass (media/clock) through his "media" parameter but I won't claim it
to be sexy. So far, I don't see how we may avoid some tool to do all the
required ioctl. 

> - where I should create the new ioctl's to handle these new parameters.

drivers/net/wan/sbni.[ch] uses the SIOCDEVPRIVATE range for different things.
The x25 protocol uses the SIOCPROTOPRIVATE. I'd rather avoid both.

> Suggestions / comments are more than welcome.

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

  reply	other threads:[~2000-12-05 10:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-05  5:58 [RFC-2] Configuring Synchronous Interfaces in Linux Ivan Passos
2000-12-05  9:38 ` Francois Romieu [this message]
2000-12-05 19:17   ` Ivan Passos
2000-12-05  9:41 ` Alan Cox
2000-12-05 15:15   ` Greg Parrott
2000-12-05 19:23   ` Ivan Passos
2000-12-05 20:41     ` Peter Samuelson
2000-12-05 21:56     ` Alan Cox
2000-12-05 14:43 ` Matthew G. Marsh
2000-12-05 19:40   ` Ivan Passos
2000-12-05 15:18 ` Paul Fulghum
     [not found] <Pine.LNX.4.30.0012051925330.6718-100000@pc24.sr.bham.ac.uk>
2000-12-05 19:46 ` Ivan Passos
  -- strict thread matches above, loose matches on Subject: below --
2000-12-05 22:55 Stuart Lynne
2000-12-06  1:21 ` Alan Cox
2000-12-06  1:34   ` Dan Hollis
2000-12-06  1:55     ` Stuart Lynne
2000-12-07  0:14   ` Krzysztof Halasa
2000-12-07 14:09     ` Alan Cox
2000-12-07 14:12       ` Jeff Garzik
2000-12-07 14:40         ` Alan Cox
2001-03-19 16:28       ` Krzysztof Halasa

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=20001205103815.A25405@se1.cogenit.fr \
    --to=romieu@cogenit.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lists@cyclades.com \
    --cc=netdev@oss.sgi.com \
    --cc=philb@gnu.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