[RFC-2] Configuring Synchronous Interfaces in Linux

[RFC-2] Configuring Synchronous Interfaces in Linux

[Ivan Passos]

Hello,

Thanks to all of you who responded to my first RFC on this subject. The
discussion ended up going in the Ethernet direction, and I frankly don't
know whether that applies to this case, or even if it _should_ apply or
they should really be separate config. subsystems. This is another thing
that you may wanna throw your opinions on.

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
- Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
            already supported by the 'hw' option)
- 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) 
- Frame Relay only: 
	- End type: DCE or DTE (maybe this applies to other interface
                    types as well)
	- DLCI: DLC number for the interface
- 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

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;
- where I should create the new ioctl's to handle these new parameters.

Suggestions / comments are more than welcome.

Later,
Ivan

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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Francois Romieu]

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/

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Ivan Passos]

On Tue, 5 Dec 2000, Francois Romieu wrote:

> Ivan Passos <lists@cyclades.com> é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
parameters.

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

Later,
Ivan

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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Alan Cox]

> - Media: V.35, RS-232, X.21, T1, E1
		DS1, DS3, ...

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

Not nicely. 

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

Yep

> 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

And more

Generic Z85x30 drivers can run with multiple framing CRC versions (all the
chip can do in theory). So I think you need

	bitcoding		[NRZ, NRZI]
	crctype			CRC16, ...
	hunt

> I'm willing to go for this implementation, but I wanted to know first:
> - whether ifconfig is the right place to do it;
> - where I should create the new ioctl's to handle these new parameters.

I think a new ioctl would be sensible. There is a lot to go in it. 

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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Greg Parrott]

I have a vested interest in how this all turns out.  I own a Packet Over SONET
device driver for our OC-12 and OC-48 NICs that I currently pass all parameters
to the driver via arguments on the insmod.  To avoid lengthy commands, we
provide the common defaults.  We accept some basic ifconfig input, but with
SONET/SDH and chip specific items that needed to be controlled, ifconfig did not
seem the way to go.

Thanks!

Greg
--
Greg Parrott
Lucent Technologies, Inc.
Optical Area Networking
(919) 838-6095
http://www.lucent-optical.com/oan


Alan Cox wrote:

> > - Media: V.35, RS-232, X.21, T1, E1
>                 DS1, DS3, ...
>
> > - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
> >             already supported by the 'hw' option)
>
> Not nicely.
>
> > - 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)
>
> Yep
>
> > 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
>
> And more
>
> Generic Z85x30 drivers can run with multiple framing CRC versions (all the
> chip can do in theory). So I think you need
>
>         bitcoding               [NRZ, NRZI]
>         crctype                 CRC16, ...
>         hunt
>
> > I'm willing to go for this implementation, but I wanted to know first:
> > - whether ifconfig is the right place to do it;
> > - where I should create the new ioctl's to handle these new parameters.
>
> I think a new ioctl would be sensible. There is a lot to go in it.

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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Ivan Passos]

On Tue, 5 Dec 2000, Alan Cox wrote:
> 
> I think a new ioctl would be sensible. There is a lot to go in it. 

Alan, what's the approach you'd feel more comfortable with:
- One ioctl that passes a pointer to a known structure in ifr.ifr_data as 
  its argument.
- Several ioctl's, one for each parameter, that pass only the specific 
  parameter new value as the argument.

The former is good because it relies on a _single_ ioctl. However, every
time you change the ioctl structure you may lose backward compatibility.

The latter is good because new implementations / features won't affect
previous working features. However, it'd create a huge list of ioctl's.

Please let me know whatcha think.

Later,
Ivan

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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Peter Samuelson]

[Ivan Passos]
> - One ioctl that passes a pointer to a known structure in
>   ifr.ifr_data as its argument.

struct sync_params_ioctl_data {
  int opcode;
  union {......

Seems straightforward to me.  Basically just ioctl numbers within ioctl
numbers.

Peter
-
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/

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Alan Cox]

> Alan, what's the approach you'd feel more comfortable with:
> - One ioctl that passes a pointer to a known structure in ifr.ifr_data as 
>   its argument.
> - Several ioctl's, one for each parameter, that pass only the specific 
>   parameter new value as the argument.
> 
> The former is good because it relies on a _single_ ioctl. However, every
> time you change the ioctl structure you may lose backward compatibility.

One ioctl with a set of subcommands seems to be quite common

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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Matthew G. Marsh]

On Mon, 4 Dec 2000, Ivan Passos wrote:

> Hello,

[snip details...]
 
> I'm willing to go for this implementation, but I wanted to know first:
> - whether ifconfig is the right place to do it;

I would like to note an objection to using ifconfig to carry all of this.
For example I do not use or even have ifconfig on any of my systems as I
only use/need/want Alexey's ip utility to perform all of those tasks. 

I would rather have an independant utility that could set and check the
settings of all of these variables for whatever classes of networking
connections existed. This would provide a cleaner split between the
protocol configuration (IPv4, IPv6, IPX, ...) and the device (V.##,
10/100, 4/16/100, etc) parameters. 

Such a split should make for a cleaner configuration structure WRT virtual
devices as well which for the most part deal with the protocol config and
do not need much device config. 

FWIW: Alexey's ip has replaced both ifconfig and route on my systems.
Something that could now replace having several different card config
utils around with one binary would be fantastic.

> - where I should create the new ioctl's to handle these new parameters.
> 
> Suggestions / comments are more than welcome.
> 
> Later,
> Ivan

Thanks! I will volunteer to test/break/etc as my coding skills verge
beyond ludicrous. 

--------------------------------------------------
Matthew G. Marsh,  President
Paktronix Systems LLC
1506 North 59th Street
Omaha  NE  68104
Phone: (402) 932-7250
Email: mgm@paktronix.com
WWW:  http://www.paktronix.com
--------------------------------------------------



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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Ivan Passos]

On Tue, 5 Dec 2000, Matthew G. Marsh wrote:
> 
> I would like to note an objection to using ifconfig to carry all of this.
> For example I do not use or even have ifconfig on any of my systems as I
> only use/need/want Alexey's ip utility to perform all of those tasks. 
> 
> I would rather have an independant utility that could set and check the
> settings of all of these variables for whatever classes of networking
> connections existed. This would provide a cleaner split between the
> protocol configuration (IPv4, IPv6, IPX, ...) and the device (V.##,
> 10/100, 4/16/100, etc) parameters. 
> 
> Such a split should make for a cleaner configuration structure WRT virtual
> devices as well which for the most part deal with the protocol config and
> do not need much device config. 
> 
> FWIW: Alexey's ip has replaced both ifconfig and route on my systems.
> Something that could now replace having several different card config
> utils around with one binary would be fantastic.

Very good point IMHO. I'll have a look at ip to see if I can get ideas
from it. Thanks for the info!!

Later,
Ivan

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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Paul Fulghum]

From: "Ivan Passos" <lists@cyclades.com>
> the parameters we currently need to configure on our board (the
> PC300) are as follows:
>
> - Media: V.35, RS-232, X.21, T1, E1
> - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is
>             already supported by the 'hw' option)
> - 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)
> - Frame Relay only:
> - End type: DCE or DTE (maybe this applies to other interface
>                     types as well)
> - DLCI: DLC number for the interface
> - 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

Some others (less common):
- Serial Encoding (NRZ/NRZI)
- Transmit Idle Mode (Flags/Marks)
- Transmit Preamble

> 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;
> - where I should create the new ioctl's to handle these new parameters.

The ioctl interface is more universally applicable for my driver
(synclink.c) which offers both the network oriented sync interface
*and* a tty oriented sync interface.

Paul Fulghum paulkf@microgate.com
Microgate Corporation www.microgate.com


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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Ivan Passos]

On Tue, 5 Dec 2000, Mark Cooke wrote:
> 
> struct foo {
> 	unsigned int	crufty_compatability_number;
> 	.
> 	.
> 	.
> };
> 
>  ?

The problem is not this, but structure alignment and copy_[to|from]_user
operations. This approach, although it's my preferred one (due to being
self-contained), requires synchronization between kernel and utility, and
this sometimes is not always true.

Anyhow, I still prefer this approach over the "tons of different ioctl's"
one. I'd like to get the opinion of the community though (especially
Alan).

Later,
Ivan

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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Stuart Lynne]

> 
> I have a vested interest in how this all turns out.  I own a Packet Over SONET
> device driver for our OC-12 and OC-48 NICs that I currently pass all parameters
> to the driver via arguments on the insmod.  To avoid lengthy commands, we
> provide the common defaults.  We accept some basic ifconfig input, but with
> SONET/SDH and chip specific items that needed to be controlled, ifconfig did not
> seem the way to go.

Ditto, we have an adsl driver that we setup by overloading various otherwise
unused options in ifconfig (mem_start, io_addr etc) to do this. Cheaper and
faster than writing yet another ioctl using device configuration agent, but
distasteful non the less.

Some generic way to pass configuration data using a generic configuration
agent to network (and other) drivers would be interesting.

> > > I'm willing to go for this implementation, but I wanted to know first:
> > > - whether ifconfig is the right place to do it;
> > > - where I should create the new ioctl's to handle these new parameters.
> >
> > I think a new ioctl would be sensible. There is a lot to go in it.
 
-- 
                                            __O 
Fireplug - a Lineo company                _-\<,_ 
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <sl@fireplug.net>         www.lineo.com         604-461-7532
-
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/

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Alan Cox]

> Ditto, we have an adsl driver that we setup by overloading various otherwise
> unused options in ifconfig (mem_start, io_addr etc) to do this. Cheaper and
> faster than writing yet another ioctl using device configuration agent, but
> distasteful non the less.

Generic is not always good , thats why we have SIOCDEVPRIVATE. One thing Im
pondering is if we should make the hardware config ioctl take a hardware type
ident with each struct. That would help make all the ethernet agree, all the
wan agree, all the ADSL agree without making a nasty mess.

> 

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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Dan Hollis]

On Wed, 6 Dec 2000, Alan Cox wrote:
> > Ditto, we have an adsl driver that we setup by overloading various otherwise
> > unused options in ifconfig (mem_start, io_addr etc) to do this. Cheaper and
> > faster than writing yet another ioctl using device configuration agent, but
> > distasteful non the less.
> Generic is not always good , thats why we have SIOCDEVPRIVATE. One thing Im
> pondering is if we should make the hardware config ioctl take a hardware type
> ident with each struct. That would help make all the ethernet agree, all the
> wan agree, all the ADSL agree without making a nasty mess.

Id be up for that, but its hard to standardize on IOCTLs without people
publishing their drivers, as long as people hide their code we dont know
what everyone else is doing config interface wise...

Lets see the code, people...

-Dan

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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Stuart Lynne]

On Tue, Dec 05, 2000 at 05:34:50PM -0800, Dan Hollis wrote:
> On Wed, 6 Dec 2000, Alan Cox wrote:
> > > Ditto, we have an adsl driver that we setup by overloading various otherwise
> > > unused options in ifconfig (mem_start, io_addr etc) to do this. Cheaper and
> > > faster than writing yet another ioctl using device configuration agent, but
> > > distasteful non the less.
> > Generic is not always good , thats why we have SIOCDEVPRIVATE. One thing Im
> > pondering is if we should make the hardware config ioctl take a hardware type
> > ident with each struct. That would help make all the ethernet agree, all the
> > wan agree, all the ADSL agree without making a nasty mess.
> 
> Id be up for that, but its hard to standardize on IOCTLs without people
> publishing their drivers, as long as people hide their code we dont know
> what everyone else is doing config interface wise...
> 
> Lets see the code, people...

We are trying to get permission from the customer to release it.

-- 
                                            __O 
Fireplug - a Lineo company                _-\<,_ 
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <sl@fireplug.net>         www.lineo.com         604-461-7532
-
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/

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Krzysztof Halasa]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> Generic is not always good , thats why we have SIOCDEVPRIVATE. One thing Im
> pondering is if we should make the hardware config ioctl take a hardware type
> ident with each struct. That would help make all the ethernet agree, all the
> wan agree, all the ADSL agree without making a nasty mess.

What's wrong with returning -Exxx error code when the user requests
unsupported interface or function?

I think we should just #define possible values in standard include file
and make ifconfig/ip use it. We can add additional media types as
required.

2.5 task IMHO.

I think we need few ioctl calls: get + set media (int argument),
get + set speed (probably two - RX and TX), etc.
In my 2.4 HDLC stuff - to be published :-( - there something like that
(in private ioctl range, of course).
-- 
Krzysztof Halasa
Network Administrator
-
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/

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Alan Cox]

> I think we need few ioctl calls: get + set media (int argument),
> get + set speed (probably two - RX and TX), etc.
> In my 2.4 HDLC stuff - to be published :-( - there something like that
> (in private ioctl range, of course).

I think we are agreeing


I'm saying use something like

	struct 
	{
		u16 media_group;
		union
		{
			struct hdlc_physical ...
			struct hdlc_bitstream
			struct hdlc_protocol
			struct fr_protocol
			struct eth_physical
			struct atm_physical
			struct dsl_physical
			struct dsl_bitstream
			struct tr_physical
			struct wireless_physical
			struct wireless_80211
			struct wireless_auth
		} config;
	}

Alan

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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Jeff Garzik]

Alan Cox wrote:
> 
> > I think we need few ioctl calls: get + set media (int argument),
> > get + set speed (probably two - RX and TX), etc.
> > In my 2.4 HDLC stuff - to be published :-( - there something like that
> > (in private ioctl range, of course).
> 
> I think we are agreeing
> 
> I'm saying use something like
> 
>         struct
>         {
>                 u16 media_group;
>                 union
>                 {
>                         struct hdlc_physical ...
>                         struct hdlc_bitstream
>                         struct hdlc_protocol
>                         struct fr_protocol
>                         struct eth_physical

Not yet another one for eth...  We now have ethtool for this.  And a
generic netdevice::set_config wrapper can be created that simply calls
the ethtool ioctl with the proper info and locking.

	Jeff


-- 
Jeff Garzik         |
Building 1024       | These are not the J's you're lookin' for.
MandrakeSoft        | It's an old Jedi mind trick.
-
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/

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Alan Cox]

> >                         struct hdlc_protocol
> >                         struct fr_protocol
> >                         struct eth_physical
> 
> Not yet another one for eth...  We now have ethtool for this.  And a
> generic netdevice::set_config wrapper can be created that simply calls
> the ethtool ioctl with the proper info and locking.

There I disagree. I would do it the other way up. Post 2.4 you make the
ethtool ioctl simply build an eth_physical and run in that way. Right now
the ethtool stuff is a bit hackish and cannot handle upcoming real world
situations such as setting the cryptokey for onboard crypto on ethernet
cards, or handling devices that present themselves as ethernet but are not
at the physical layer being remotely honest about it.

Alan

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

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

[Krzysztof Halasa]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> I think we are agreeing
> 
> 
> I'm saying use something like
> 
> 	struct 
> 	{
> 		u16 media_group;
> 		union
> 		{
> 			struct hdlc_physical ...
> 			struct hdlc_bitstream
> 			struct hdlc_protocol
> 			struct fr_protocol
> 			struct eth_physical
> 			struct atm_physical
> 			struct dsl_physical
> 			struct dsl_bitstream
> 			struct tr_physical
> 			struct wireless_physical
> 			struct wireless_80211
> 			struct wireless_auth
> 		} config;
> 	}

I think union like this is fine.


We currently have:
ioctl(sock, COMMAND, ifreq*)

where ifreq is defined in include/linux/if.h and is 16 bytes long:

struct ifreq {
        {
                char    ifrn_name[IFNAMSIZ];    /* if name, e.g. "en0" */
        } ifr_ifrn;

        union {
                struct  sockaddr ifru_addr;
                struct  sockaddr ifru_dstaddr;
                struct  sockaddr ifru_broadaddr;
                struct  sockaddr ifru_netmask;
                struct  sockaddr ifru_hwaddr;
                short   ifru_flags;
                int     ifru_ivalue;
                int     ifru_mtu;
                struct  ifmap ifru_map;
                char    ifru_slave[IFNAMSIZ];   /* Just fits the size */
                char    ifru_newname[IFNAMSIZ];
                char *  ifru_data;
        }

I understand we can put a config structure address in ifru_data - but
do we really need another level?
Wouldn't it be better put config structs there (in the union)?

It would then read:
struct ifreq {
        {
                char    ifrn_name[IFNAMSIZ];    /* if name, e.g. "en0" */
        } ifr_ifrn;

        union {
                struct  sockaddr ifru_addr;
                struct  sockaddr ifru_dstaddr;
                struct  sockaddr ifru_broadaddr;
                struct  sockaddr ifru_netmask;
                struct  sockaddr ifru_hwaddr;
                short   ifru_flags;
                int     ifru_ivalue;
                int     ifru_mtu;
                struct  ifmap ifru_map;
                char    ifru_slave[IFNAMSIZ];   /* Just fits the size */
                char    ifru_newname[IFNAMSIZ];
                char *  ifru_data;
		struct hdlc_physical ...
		struct hdlc_bitstream
		struct hdlc_protocol
		struct fr_protocol
		struct eth_physical
		struct atm_physical
		struct dsl_physical
		struct dsl_bitstream
		struct tr_physical
		struct wireless_physical
		struct wireless_80211
		struct wireless_auth
        }

while I'd put "media_group" in ioctl command code:
#define SIOCSHDLC_PHY ...
#define SIOCGHDLC_PHY ... /* get */
#define SIOCSFR ...
#define SIOCSETH_PHY ...
#define SIOCSATM...

A possible problem is if the struct gets longer - we would have to recompile
all utils using it. Doing that before distributions start using 2.4 as
a kernel for general use would save us (we can use pointers in such cases
as well, as some operations - downloading firmware or crypto keys - may have
very long data areas).

What do you think about it?
-- 
Krzysztof Halasa
Network Administrator