[arch-dev-public] New wireless and network scripts.

James iphitus at gmail.com
Mon Apr 2 04:28:38 EDT 2007

On 4/2/07, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> > A network "profile" is always only one interface. I'd expect a profile
> > to be several interfaces that are activated all at once and are sort of
> > tied together (I didn't read your latest version yet, did you already
> > add such a thing?).

one-to-many, multi support is included.

> > That leads me to the second: While configuration via bash-script is easy
> > for the programmer (you can simply parse it via 'source'), it is unsafe
> > and becomes rather complicated when features are added.

I designed these so they were clear and easy to work with.
Documentation needs a bit of work, but making changes anywhere is very
simple. And more approachable than C. Not sure how it's 'unsafe'

> > Especially when
> > we want more than one interface in a profile, it becomes messy.

Bash does have some nasty gotchas with scope, I'll agree there, but
again, that's a matter of design. These one's are designed to work
with bash not fight against it and shoehorn it into a design suitable
for another language.

> > suggest a inifile-like configuration style where each section '[foo]'
> > marks an interface. This is much more readable to the user and allows
> > more flexibility but itis not as easy to work with.

The bash is fairly simple and readable too though.

> > Last but not least, invoking our netcfg tool from a GUI or any other
> > external application is not optimal. netcfg is a shell script, but IMO
> > should be a library. We could then have proper bindings to C/C++/python
> > and so on. Also, when it becomes more complicated, writing bash becomes
> > ugly very fast.

Is there such a demand though? Arch has always tended away from GUI
tools. I'd rather not switch to a C implementation, just so we can
make writing GUI's easier.

> > I actually started a little C++ implementation of the above ideas, but
> > got lost in bison/flex soon (anyone wanna give me a crash course on how
> > to do it right? I have a parser that works good enough so I can start
> > experimenting, but nothing fool-proof). I may or may not continue this
> > work soon.

And that's the state of many Arch projects. Arch has needed these
scripts for *ages* and nobody else has had any interest. There is a
need though, every day, there's still multiple new threads on the
forums with wireless and other networking problems. And simply, the
current scripts do not cater nicely towards > 1 network per interface.

You can write C based scripts, but unless you knuckle down and work on
them, I doubt we'll see them before the end of the year. If they do
appear, they won't have reached the stage of the bash scripts before

This is the problem we have, ideas are raised, but we don't have
enough implementers.

> I think getting too complex with configuration tools is not the best
> idea.  I do, however agree that the profile-to-interface mapping
> should be a one-to-many mapping.

one-to-many available in these.

> Also, if bash is unsafe, we need to rewrite rc.conf, makepkg, and
> probably a hundred other utilities.  Dan and I might be willing to
> accept patches for a binary makepkg, so feel free.

Aye, so many of arch's scripts are written in bash. These network
scripts as they're implemented, are simpler and tidier than many other
things i've seen come out of Arch...

However..... we could make a compromise, a halfway.

If we could design a better config file, and then write a C(++) based
program to parse this file and spit out requested variables, then we
could have a tidier and better implementation in many aspects. We
could keep the simplicity of the bash scripts, and allow the extra
power of a better config file.

iphitus // Arch Developer // kernel26beyond // iphitus.loudas.com

More information about the arch-dev-public mailing list