Requirement to customize Linux Network Interface naming Convention

Requirement to customize Linux Network Interface naming Convention

[Akash Bhatnagar]

Hi,

We have a requirement to tweak the Linux Network Interface Naming
conventions so that, it can support names of interfaces with "/" character.

For example, ip tuntap add dev fe/1/1 mode tap

With iproute2 it simply shows error as INVALID Argument. What are the
changes we supposed to do inside Kernel and iproute2 package?

Thanks
Akash Bhatnagar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150805/ab9b2562/attachment.html 

Requirement to customize Linux Network Interface naming Convention

[Greg KH]

On Wed, Aug 05, 2015 at 09:24:41AM +0530, Akash Bhatnagar wrote:
> Hi,
> 
> We have a requirement to tweak the Linux Network Interface Naming
> conventions so that, it can support names of interfaces with "/" character.

Who is "we"?

And why do you want such a thing?

> For example, ip tuntap add dev fe/1/1 mode tap
> 
> With iproute2 it simply shows error as INVALID Argument. What are the
> changes we supposed to do inside Kernel and iproute2 package?

Lots, good luck :)

But first, push back, you should never care what the network interface
name is, that never matters.

greg k-h

Requirement to customize Linux Network Interface naming Convention

[Akash Bhatnagar]

Hi Greg,

Thanks for a quick reply, "We" means me and my manager :)

In our company we provide HTTP based View to  User with naming conventions
of interfaces in these formats.
This is done and stored via higher layer applications in Databases and a
lower application (X) will
make interfaces at Linux Level accordingly.

Thus, we need to maintain a mapping of names, of what user have given with
what is created. This mapping is available to only X and not to other Linux
daemons (like dhcpd etc). Right now, all daemons need some tweaking in
order to fetch the
mappings from X.

Hence, there comes requirement to store all the mapping somehow inside
kernel
so that every daemon can easily accessible Interface related information
via ioctls.

Thanks
Akash Bhatnagar
? Show quoted text
On 5 Aug 2015 09:34, "Greg KH" <greg@kroah.com> wrote:
>
> On Wed, Aug 05, 2015 at 09:24:41AM +0530, Akash Bhatnagar wrote:
> > Hi,
> >
> > We have a requirement to tweak the Linux Network Interface Naming
> > conventions so that, it can support names of interfaces with "/"
character.
>
> Who is "we"?
>
> And why do you want such a thing?
>
> > For example, ip tuntap add dev fe/1/1 mode tap
> >
> > With iproute2 it simply shows error as INVALID Argument. What are the
> > changes we supposed to do inside Kernel and iproute2 package?
>
> Lots, good luck :)
>
> But first, push back, you should never care what the network interface
> name is, that never matters.
>
> greg k-h
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150805/5c36cabe/attachment-0001.html 

Requirement to customize Linux Network Interface naming Convention

[Greg KH]

On Wed, Aug 05, 2015 at 08:09:59PM +0530, Akash Bhatnagar wrote:
> Hi Greg,
> 
> Thanks for a quick reply, "We" means me and my manager :)
> 
> In our company we provide HTTP based View to? User with naming conventions of
> interfaces in these formats.
> This is done and stored via higher layer applications in Databases and a lower
> application (X) will make interfaces at Linux Level accordingly.

I don't understand what this means, and how it relates to network names.

> Thus, we need to maintain a mapping of names, of what user have given with
> what is created. This mapping is available to only X and not to other Linux
> daemons (like dhcpd etc). Right now, all daemons need some tweaking in order to
> fetch the mappings from X.
> 
> Hence, there comes requirement to store all the mapping somehow inside kernel
> so that every daemon can easily accessible Interface related information via
> ioctls.

Don't use the kernel as a database for something it was not meant to be.
Again, network names should not "mean" anything, I suggest you revisit
your "requirements".

good luck,

greg k-h