* WAN device configuration, again...
@ 2009-10-28 13:28 Krzysztof Halasa
2009-10-28 16:03 ` Dan Williams
0 siblings, 1 reply; 3+ messages in thread
From: Krzysztof Halasa @ 2009-10-28 13:28 UTC (permalink / raw)
To: netdev
Hi,
I'm currently at final stages of "producing" two WAN drivers and there
is one thing to solve: they have really complex options. It's no longer
a V.35 with ca. 4 clock modes, a clock rate and few encodings etc. They
need many options unique to each driver/board. I think I need a more
capable interface to configure the devices than the current ioctl-based
one.
I think of something:
- using netlink or similar interface
- with potentially unlimited "payload" size (data may be transfered in
smaller packets)
- the "command" and "response" should be variable-length ASCII-based,
instead of fixed structures. This way I don't have to duplicate all
option handling in userspace, only the specific driver has to know
about them.
Comments? Perhaps there is already an example?
Should I use something else?
I also thought about using /sys read/write calls, but I'm not sure it's
a good idea.
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: WAN device configuration, again...
2009-10-28 13:28 WAN device configuration, again Krzysztof Halasa
@ 2009-10-28 16:03 ` Dan Williams
2009-10-29 14:48 ` Krzysztof Halasa
0 siblings, 1 reply; 3+ messages in thread
From: Dan Williams @ 2009-10-28 16:03 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: netdev
On Wed, 2009-10-28 at 14:28 +0100, Krzysztof Halasa wrote:
> Hi,
>
> I'm currently at final stages of "producing" two WAN drivers and there
> is one thing to solve: they have really complex options. It's no longer
> a V.35 with ca. 4 clock modes, a clock rate and few encodings etc. They
> need many options unique to each driver/board. I think I need a more
> capable interface to configure the devices than the current ioctl-based
> one.
>
> I think of something:
> - using netlink or similar interface
If you're doing a new config interface, I'd suggest netlink like the
wireless guys did to replace WEXT with cfg80211. Using netlink makes
your interface easily available from programs/libraries without having
to screenscrape anything. If you want some advice on netlink API stuff,
ask Johannes Berg.
Dan
> - with potentially unlimited "payload" size (data may be transfered in
> smaller packets)
> - the "command" and "response" should be variable-length ASCII-based,
> instead of fixed structures. This way I don't have to duplicate all
> option handling in userspace, only the specific driver has to know
> about them.
>
> Comments? Perhaps there is already an example?
> Should I use something else?
>
> I also thought about using /sys read/write calls, but I'm not sure it's
> a good idea.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: WAN device configuration, again...
2009-10-28 16:03 ` Dan Williams
@ 2009-10-29 14:48 ` Krzysztof Halasa
0 siblings, 0 replies; 3+ messages in thread
From: Krzysztof Halasa @ 2009-10-29 14:48 UTC (permalink / raw)
To: Dan Williams; +Cc: netdev
Dan Williams <dcbw@redhat.com> writes:
>> I think of something:
>> - using netlink or similar interface
>
> If you're doing a new config interface, I'd suggest netlink like the
> wireless guys did to replace WEXT with cfg80211. Using netlink makes
> your interface easily available from programs/libraries without having
> to screenscrape anything. If you want some advice on netlink API stuff,
> ask Johannes Berg.
Thanks for your mail. It seems I'll do it this way.
--
Krzysztof Halasa
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-10-29 14:47 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-28 13:28 WAN device configuration, again Krzysztof Halasa
2009-10-28 16:03 ` Dan Williams
2009-10-29 14:48 ` Krzysztof Halasa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).