question about netconf and GSoC.

[martin f krafft]

Just some short comments from me, maybe others have something to
pitch in too.

also sprach Alexey Tarasov <glorgster at gmail.com> [2008.03.12.1017 +0100]:
> = 1 =
> I want port netconf to FreeBSD (cause I like FreeBSD last years
> more than Linux). For this purpose some replacement is needed,
> cause netconf deeply relies on shell scripts, that utilize
> iproute2.
[...]
> One of possible solutions is to make system dependent dictionary
> mapping event to some script and use it like in such pseudocode:
> 
> runner = RunnersFactory.createRunner(EVENT_NAME)

Why not just replace the shell script with a version that uses tools
available on FreeBSD?

> Other one opportunity - forget about scripts and use C module,
> which executes system calls. There are not so many network related
> events, so one solid network related module may handle all of them
> by cost of a little bit harder extensibility.

I definitely want to stay with scripts because it makes porting much
easier and gives distros enough flexibility. Also, netconf is
supposed to stay as small as possible. System calls make it
complicated when more than one kernel/userland combo is involved.

> = 2 =
> Actually I've worked with DHCP-client in PXE environment, so some
> DHCP related tasks such as lease renewal, getting DHCP options and
> etc may implement without external DHCP client and use python or
> C for this purpose.

I want to keep netconf as simple as possible and, in true Unix
fashion, it should let other programmes what they do.

> = 3 =
> I've looked through sources and found that IP class uses only
> IPv4. it's better to revise all related modules and provide
> partial support of IPv6 at least.

I agree. This definitely has to happen before 1.0.

> = 4 =
> May be policy and security related problems. IMHO, syntax like
> squid acls is good enough. E.g.
> 
> acl all_users user1 user2 group
> acl bad_users user3
> allow all_users interface control
> deny bad_users interface any
> 
> where 'interface' may be just name for module, or plugin, or some other
> keyword.

The policy also needs to be able to encode flow, like what is to
happen when DHCP fails to get a lease.

> = 5 =
> Some kind of related plugins. E.g. There is some task. Try first
> plugin, then next if first failed. This may help use IPv6 (fall
> over to IPv4) and some other fall overs from protocol to protocol.

This is more or less what I want, yes: the policy tells you which
approach to take when the previous one failed. Approaches are
implemented by modules.

> = 6=
> It seems good idea to extract plugins from existing sources and
> make core really small core with a huge amount of plugins, that
> now are only python based only (mainly cause EventHandlers are
> python based). That also needs some specification of core <->
> plugins data exchange.

In theory, every FD reactor right now is a plugin and the core is
just core.py. I would 

> = 7 =
> May be some ACPI related events. Usually (at least in FreeBSD) two
> scripts are used to handle power state changes. So, new events
> must be implemented, that are generated from this scripts. Not
> only power state change, but configuration change (e.g. power for
> notebook Ethernet NIC is offed by switch, driver is loaded,
> logical interface still exists but not works really)

ACPI handlers should talk to netconf vie the control socket; they're
not part of netconf, and netconf should not even know about ACPI.

Thanks for your interest. Sorry if my answers are a bit short, I am
too tired...

-- 
 .''`.   martin f. krafft <madduck at debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"those are my principles, and if you don't like them...
 well, I have others."
                                                       -- groucho marx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/netconf-devel/attachments/20080312/f1c2a580/attachment.pgp