linux-kernel - RE: [PATCH 00/13] drivers: hv: kvp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <426367E2313C2449837CD2DE46E7EAF9155EF7C6@SN2PRD0310MB382.namprd03.prod.outlook.com>
Date:	Tue, 3 Jul 2012 15:24:15 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Ben Hutchings <ben@...adent.org.uk>
CC:	Olaf Hering <olaf@...fle.de>, Greg KH <gregkh@...uxfoundation.org>,
	"apw@...onical.com" <apw@...onical.com>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"virtualization@...ts.osdl.org" <virtualization@...ts.osdl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH 00/13] drivers: hv: kvp



> -----Original Message-----
> From: Ben Hutchings [mailto:ben@...adent.org.uk]
> Sent: Monday, July 02, 2012 3:57 PM
> To: KY Srinivasan
> Cc: Olaf Hering; Greg KH; apw@...onical.com; devel@...uxdriverproject.org;
> virtualization@...ts.osdl.org; linux-kernel@...r.kernel.org;
> netdev@...r.kernel.org
> Subject: Re: [PATCH 00/13] drivers: hv: kvp
> 
> On Mon, Jul 02, 2012 at 03:22:25PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Olaf Hering [mailto:olaf@...fle.de]
> > > Sent: Thursday, June 28, 2012 10:24 AM
> > > To: KY Srinivasan
> > > Cc: Greg KH; apw@...onical.com; devel@...uxdriverproject.org;
> > > virtualization@...ts.osdl.org; linux-kernel@...r.kernel.org
> > > Subject: Re: [PATCH 00/13] drivers: hv: kvp
> > >
> > > On Tue, Jun 26, KY Srinivasan wrote:
> > >
> > > > > From: Greg KH [mailto:gregkh@...uxfoundation.org]
> > > > > The fact that it was Red Hat specific was the main part, this should be
> > > > > done in a standard way, with standard tools, right?
> > > >
> > > > The reason I asked this question was to make sure I address these
> > > > issues in addition to whatever I am debugging now. I use the standard
> > > > tools and calls to retrieve all the IP configuration. As I look at
> > > > each distribution the files they keep persistent IP configuration
> > > > Information is different and that is the reason I chose to start with
> > > > RedHat. If there is a standard way to store the configuration, I will
> > > > do that.
> > >
> > >
> > > KY,
> > >
> > > instead of using system() in kvp_get_ipconfig_info and kvp_set_ip_info,
> > > wouldnt it be easier to call an external helper script which does all
> > > the distribution specific work? Just define some API to pass values to
> > > the script, and something to read values collected by the script back
> > > into the daemon.
> >
> > On the "Get" side I mostly use standard commands/APIs to get all the
> information:
> >
> > 1) IP address information and subnet mask: getifaddrs()
> > 2) DNS information:  Parsing /etc/resolv.conf
> > 3) /sbin/ip command for all the routing information
> 
> If you're interested in the *current* configuration then (1) and (3)
> are OK but you should really use the rtnetlink API.
> 
> However, I suspect that Hyper-V assumes that current and persistent
> configuration are the same thing, which is obviously not true in
> general on Linux.  But if NetworkManager is running then you can
> assume they are.

I am only interested in the currently active information. Why do you
recommend the use of rtnetlink API over the "ip" command. If I am not
mistaken, the ip command uses netlink to get the information. 

> 
> > 4)  Parse /etc/sysconfig/network-scripts/ifcfg-ethx for boot protocol

This is the only information that requires parsing a distro specific configuration file. Do
you have any suggestion on how I may get this information in a distro independent way.
 
> >
> > As you can see, all but the boot protocol is gathered using the "standard distro
> > independent mechanisms. I was looking at NetworkManager cli and it looks
> > like I could gather all the information except the boot protocol information. I am
> > not sure how to gather the boot protocol information in a distro independent
> fashion.
> >
> > On the SET side, I need to persistently store the settings in an appropriate
> configuration
> > file and flush these settings down so that the interface is appropriately
> configured. It is here
> > that I am struggling to find a distro independent way of doing things. It would
> be great if I can
> > use NetworkManager cli (nmcli) to accomplish this. Any help here would be
> greatly appreciated.
> [...]
> 
> What was wrong with the NetworkManager D-Bus API I pointed you at?
> I don't see how it makes sense to use nmcli as an API.

I saw some documentation that claimed that nmcli could be used to accomplish
all that can be done with the GUI interface. I am looking for a portable way
to accomplish configuring an interface. If nmcli can do that, I would use it. With
regards to D-BUS API, I took a cursory look at the APIs. I am still evaluating
my options.

Regards,

K. Y


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/