New wpa_supplicand dbus API proposal

Dan Williams dcbw
Tue Jun 16 13:06:14 PDT 2009


On Fri, 2009-06-12 at 01:31 +0200, Marcel Holtmann wrote:
> Hi Witold,
> 
> > >> Here is second proposal of new DBus API build basing of our earlier
> > >> e-mail correspondence, Marcel's remarks and arrangement I made with Dan
> > >> on #wireless.
> > >> I will start to implement this in next week. Request for comments.
> > >>
> > >> Service Name: fi.w1.wpa_supplicant1
> > >>
> > >> O: /fi/w1/wpa_supplicant1
> > >> I : fi.w1.wpa_supplicant1
> > >>
> > >> M: CreateInterface(args a{sv}) -> path o
> > >>    args: Ifname -> s
> > >>          Driver -> s
> > >>          Bridge-ifname -> s
> > >>          Level -> u
> > >>          Timestamp -> b
> > >>          Show_keys -> b
> > >>     
> > Level should be DebugLevel - my mistake.
> > >
> > > can we add an Ifindex -> u here. So you can optionally give the
> > > interface index or the name. Could be useful in some cases where
> > > everything is based around the ifindex anyway.
> > >   
> > OK. We would return InterfaceExists error if specified index is in use.
> > Do we actually need that indexing? Couldn't we just use paths like
> > s/Interfaces/<ifname>/... instead of s/Interfaces/<ifindex>/...? That
> > would make paths more telling, and we could kill interface indexing.
> 
> I think it is a bad idea to make the object path in D-Bus meaningful. I
> would advise against it.

Yeah, object paths are opaque and should not be depended on by
applications.  They are like pointers, they mean nothing and are just a
bunch of numbers.

> > >> E: fi.w1.wpa_supplicant1.InterfaceExists
> > >>    fi.w1.wpa_supplicant1.InterfaceUnknown
> > >>    fi.w1.wpa_supplicant1.UnknownError
> > >>
> > >> M: RemoveInterface(path o)
> > >> E: fi.w1.wpa_supplicant1.InterfaceUnknown
> > >>    fi.w1.wpa_supplicant1.UnknownError
> > >>
> > >> M: GetInterface(ifname s) -> path o
> > >> E: fi.w1.wpa_supplicant1.InterfaceUnknown
> > >>    fi.w1.wpa_supplicant1.UnknownError
> > >>
> > >> P: Interfaces -> ao
> > >>    EapMethods -> as
> > >>
> > >> S: InterfaceAdded -> path o
> > >> S: InterfaceRemoved -> path o
> > >> S: PropertiesChanged -> properties a{sv}
> > >>     
> > >
> > > I still think using Device instead of Interface is better for the sake
> > > of mind :)
> > >   
> > Heh, actually I agree with Dan's explanation. I would rather consider
> > Device as hardware device, and Interface as logical network Interface.
> > Since there may be more than one interface on one device, and we are
> > actually interested in interfaces, *not* in devices here, I think that
> > Interface describes matter better than Device.
> 
> I agree with that, no questions asked. However using "Interface" as
> D-Bus interface name is nasty and makes you drive crazy.

Sort of, but that's the terminology we're stuck with :(

Dan





More information about the Hostap mailing list