[lkml]   [2000]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC-2] Configuring Synchronous Interfaces in Linux

On Tue, 5 Dec 2000, Francois Romieu wrote:

> Ivan Passos <> écrit :
> >
> > - Media: V.35, RS-232, X.21, T1, E1
> 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.

Yes. The PC300/RSV supports RS-232 and V.35, software selectable. The
PC300/TE supports T1 and E1, also software selectable.

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

As I said, for sure there will be parameters left out, but this would be
my _initial_ set of parameters. Subsequent patches would add more and more

> > - 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 ?

Same protocols as before: Frame Relay, X.25, PPP, HDLC ... Did I
misunderstood your question??

> 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.

The point is not to prevent the tool from doing ioctl's, is having _one
single_ tool that generates _the same_ ioctl to all sync drivers. That
would mean that a user wouldn't care if his sync card is from X, Y or Z
manufacturer, the command syntax to set a specific link configuration
would be the same for all of them. How to translate this standard command
to the hardware, that's a device driver problem (no news here).

> > - 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.

That's what everybody does currently, but each driver uses their _own_ set
of ioctl's. Having one unified set of ioctl's for all drivers would ease
the user's life a lot.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:51    [W:0.065 / U:3.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site