Exactly.... having to use ioctls can lead to problems if the ioctls change
(ioctls are driver specific and the driver code can change). But if we have
an API like "x = create_interface("foo0")" the backend no matter how complex
is hidden from the user and he can be sure that the interface wont change
even if the backend changes. This is good for both the user of the interface
and the developers of the interface (who can change the backend easily
knowing that it wont affect the public interface).In my personal opinion exposing an interface is the best an OS can do (as against ioctls or using system utilities). I may be wrong :-) On Mon, Oct 5, 2009 at 10:49 PM, Darren Reed <[email protected]> wrote: > Girish Moodalbail wrote: > >> On 10/05/09 09:43, Gireesh Nagabhushana wrote: >> >>> So, are we getting APIs which can be used for interface configurations? >>> >>> Plumb/unplumb was his initial requirement. His last mail was not just on >>> plumb/unplumb but on a wide number of operations on network interfaces >>> which we do through ndd/dladm/ifconfig.. >>> >> >> We know the gaping hole in doing network interface configuration >> programmatically in Solaris. We are addressing this issue in Brussels II >> project. More on it here: >> >> http://arc.opensolaris.org/caselog/PSARC/2009/306/commitment.materials/ >> >> and here >> >> http://opensolaris.org/os/project/brussels/ >> >> However it will be a while before we could make those API's public. >> > > Why? > > That's quite sad :-( > > We seem to sometimes miss the obvious things, in our pursuit of the > finer details. For example, how hard would it be to support a library > function call that was a "x = create_interface("foo0")" and then one that > was "add_address_to_interface(x, "192.168.1.1/24")''? > > Darren > >
_______________________________________________ networking-discuss mailing list [email protected]
