Alan Cox <[EMAIL PROTECTED]> writes:
> I think we are agreeing
>
>
> I'm saying use something like
>
> struct
> {
> u16 media_group;
> union
> {
> struct hdlc_physical ...
> struct hdlc_bitstream
Alan wrote :
> struct wireless_physical
> struct wireless_80211
> struct wireless_auth
Please do not underestimate 802.11 (and others). Even two
cards based on the same MAC controller can have very different way to
> > 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 e
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 say
> 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
st
Alan Cox <[EMAIL PROTECTED]> 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 AD
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 anoth
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 t
> 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
>
> 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 ifc
> 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 be
[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
On Tue, 5 Dec 2000, Mark Cooke wrote:
>
> struct foo {
> unsigned intcrufty_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
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 a
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 para
On Tue, 5 Dec 2000, Francois Romieu wrote:
> Ivan Passos <[EMAIL PROTECTED]> é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/
From: "Ivan Passos" <[EMAIL PROTECTED]>
> 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
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
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 ev
> - 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
>
Ivan Passos <[EMAIL PROTECTED]> é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.
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
22 matches
Mail list logo
