On Mon, Feb 6, 2012 at 12:00 PM, Laine Stump <la...@laine.org> wrote:
> On 02/06/2012 01:47 PM, hiren panchasara wrote: > >> Hi Folks, >> >> I am trying to make netcf work with FreeBSD. >> > > Nice! Please keep us informed and be sure to ask when you need help (like > now) :-) Thanks Laine! Sean (sbr...@freebsd.org) and myself are working on this effort. And being a newbie I assure you that I *will* ask questions :D > > >> I am looking for more documentation on xml part of it. (I think augeas is >> used for xml/xslt?) >> > > Yes, that's true for the current ports (Fedora/RHEL, debian/ubuntu, and > SuSe), but doesn't need to be true for any new port (although you may find > it easier to deal with all the corner cases of config files by letting > augeas deal with the details). You *could* just read the native freebsd > config files and do a series of asprintfs. (going in the other direction it > might be nice to at least use libxml2 to parse the XML into a form that > would be easy to extra the info from). > I think, I will not use Augeas and just do asprintfs and use libxml2 for parsing. > > The best documentation of the XML is contained in the examples in > tests/interface. Basically, the idea is that if one interface is attached > to another (e.g. a physical ethernet attached to a bridge), then that slave > interface is represented as a sub-element of the master interface (e.g. > tests/interface/bridge.xml, similar to the example at > https://start.fedorahosted.**org/netcf/<https://start.fedorahosted.org/netcf/>). > Four main types of interfaces are supported - ethernet, bridge, vlan, and > bond. Here's the combinations that are supported: > > a bridge can enslave a bond, vlan, or ethernet. > a bond can enslave ethernets > a vlan can *reference* an ethernet, bond, or bridge. > > Here's a diagram that shows the relationships: > > https://start.fedorahosted.**org/netcf/wiki/**InterfaceNesting<https://start.fedorahosted.org/netcf/wiki/InterfaceNesting> > > The black lines show a proper master-slave relationship, and can be > represented in a single xml config (== one "toplevel" interface == a single > entry in the output of "ncftool list"; the green lines just show a > reference, and in these cases each interface will be configured separately > (== multiple toplevel interfaces == multiple entries in the output of > "ncftool list". > > For example, it's possible to bond two ethernets together, and attach that > bond to a bridge device - see tests/interface/bridge-bond.**xml for an > example. (If you wonder why I'm avoiding putting XML examples in my > response, partly it's for brevity, but mostly its because Thunderbird > insists on eating the formatting whitespace in xml examples :-( ) > > Or, you can have a bridge with a vlan attached - > tests/interface/bridge-vlan.**xml. (Note that in that example, the > interface eth0 would still need a separate definition, as the vlan in > bridge-vlan.xml only *references* eth0, it doesn't enslave it (meaning it > can still be used for other purposes, e.g. for other vlans, and/or as an > interface in its own right. > > In short, 1) when writing your xml parser and formatter, you need to > account for the idea that there may be an interface within and interface > within an interface, and when you're listing the interfaces, you should > only list the toplevel of each of these hierarchies. Thanks. This info is really helpful. So, just to understand, if I have an ethernet interface "em0" getting ip from dhcp, my "dumpxml em0" o/p should look like test/interface/ethernet-dhcp.xml, right? and that should be the format which "define" should take as input to configure an ethernet interface with dhcp. > > > "list" the interfaces but "dumpxml" does not work as I need to prepare >> xml/xsl scaffolding. >> >> Any pointers would be appreciated. >> > > In general, to do a port of netcf, you need to create a new > drv_${platform}.c file that defines all of the functions declared at the > end of src/internal.h, then modify configure.ac to figure out your > platform (just search for "suse" within that file) and src/Makefile.am to > add the correct drv_*.c file (and whatever other dutil*.[ch] files are > appropriate - maybe you want to write one yourself for bsd-specific things, > or add functions to dutil.c) when that platform is selected (again, search > for "suse"). If you don't use augeas, you won't want to defint get_aug() > and put_aug(), and thus won't be able to build ncftransform.c, but that > isn't essential to operation, it's only for testing that augeas transforms > are working properly (the mswindows port is an example of leaving those > functions out, and not compiling ncftransform) > Thanks! > > > You may find that not all the functions in dutil.[ch] are useful for you > (if you don't use libxml2, although I would strongly recommend you do), and > in that case feel free to either move them to another file > (dutil_libxml.[ch]) or just conditionally compile them. > I will try and use libxml2. Really appreciate your help :-) Hiren
_______________________________________________ netcf-devel mailing list netcf-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/netcf-devel
