Hi,
On 2019/06/25 13:13, KUSABA Takeshi wrote:
I think if_description in struct ifnet should be moved before the #ifdef
_KERNEL block so it stays at the same offset for non-_KERNEL users.
Thank you.
I updated the patch.
Just my 3 cents...
dms> But it also occurs to me that calling it a "description" is misleading
dms> if it's really an alternative name. To me, "description" would be
dms> something like "Inter-office VPN" or "4th floor desktops". [...]
Yepp, that's actually how I understand the initial
On Tue, Jun 25, 2019 at 10:43:32AM +0200, Michael van Elst wrote:
> On Tue, Jun 25, 2019 at 09:49:46AM +0200, Manuel Bouyer wrote:
> > On Mon, Jun 24, 2019 at 09:56:35PM -, Michael van Elst wrote:
> > > IMHO such functionality doesn't belong into the kernel, it's much easier
> > > to have a
On Tue, Jun 25, 2019 at 09:49:46AM +0200, Manuel Bouyer wrote:
> On Mon, Jun 24, 2019 at 09:56:35PM -, Michael van Elst wrote:
> > IMHO such functionality doesn't belong into the kernel, it's much easier
> > to have a configuration syntax with variables or macros to achieve hte
> > same.
>
>
> But it also occurs to me that calling it a "description" is misleading
> if it's really an alternative name. To me, "description" would be
> something like "Inter-office VPN" or "4th floor desktops".
Yes. I was thinking about something like "VLAN 104" or "easerv" (our
internal network name)
> I think I would prefer that attempting to set a description that
> equals an interface name is rejected, and, when attaching an interface
> after boot (ie, after interface descriptions can have been set), when
> choosing an interface disambiguator number, putative names are tested
> for
On Mon, Jun 24, 2019 at 09:56:35PM -, Michael van Elst wrote:
> e...@math.uni-bonn.de (Edgar =?iso-8859-1?B?RnXf?=) writes:
>
> >Or is there an argument that descriptions ought to be able to look like
> >names?
>
> These are not really descriptions but aliases and people like to
> use them
> I think if_description in struct ifnet should be moved before the #ifdef
> _KERNEL block so it stays at the same offset for non-_KERNEL users.
Thank you.
I updated the patch.
e...@math.uni-bonn.de (Edgar =?iso-8859-1?B?RnXf?=) writes:
>Or is there an argument that descriptions ought to be able to look like names?
These are not really descriptions but aliases and people like to
use them as such. If you allow arbitrary strings (even with special
characters, whitespace
On Mon, Jun 24, 2019 at 08:08:24AM -0400, Mouse wrote:
>
> I think I would prefer that attempting to set a description that
> equals an interface name is rejected, and, when attaching an interface
> after boot (ie, after interface descriptions can have been set), when
> choosing an interface
>>> Couldn't you just enforce the description to not match
>>> /[a-z]+[0-9]+/?
>> That breaks down if you want the descriptions to be "wan0", "lan0",
>> "lan1", etc.
> But you could use "wan-0", "wan_0" or "WAN 0" or whatever.
wan_0 and wan-0 are not fixes; _ and - are permitted in device names
EF> Couldn't you just enforce the description to not match /[a-z]+[0-9]+/?
JT> That breaks down if you want the descriptions to be "wan0", "lan0", "lan1",
etc.
But you could use "wan-0", "wan_0" or "WAN 0" or whatever.
Or is there an argument that descriptions ought to be able to look like names?
> On Jun 24, 2019, at 6:42 AM, Edgar Fuß wrote:
>
>> I think I would prefer that attempting to set a description that
>> equals an interface name is rejected, and, [...]
> Couldn't you just enforce the description to not match /[a-z]+[0-9]+/?
That breaks down if you want the descriptions to
>> I think I would prefer that attempting to set a description that
>> equals an interface name is rejected, and, [...]
> Couldn't you just enforce the description to not match
> /[a-z]+[0-9]+/?
Well, according to scan.l in the usr.bin/config I have at ready hand,
it's [A-Za-z_][-A-Za-z_0-9]*
> I think I would prefer that attempting to set a description that
> equals an interface name is rejected, and, [...]
Couldn't you just enforce the description to not match /[a-z]+[0-9]+/?
On Mon, Jun 24, 2019 at 04:59:04AM -0700, Jason Thorpe wrote:
>
> > On Jun 24, 2019, at 4:29 AM, Manuel Bouyer wrote:
> >
> > I'd say that we should explicitely mention if we're looking up a name or
> > a description, to avoid confusion. For example if wm0 has descrition
> > "external if" we
> On Jun 24, 2019, at 4:29 AM, Manuel Bouyer wrote:
>
> I'd say that we should explicitely mention if we're looking up a name or
> a description, to avoid confusion. For example if wm0 has descrition
> "external if" we should be able to write in ipf:
>
> block in on wm0 from any to any
> or
>
> I agree, we should be able to use the description as a means of looking up t$
> 1- Duplicate descriptions are not allowed (should return EEXIST if an attemp$
Agreed. At least, unless and until someone comes up with reasonable
semantics for handling multiple interfaces at once in all relevant
On Mon, Jun 24, 2019 at 04:20:59AM -0700, Jason Thorpe wrote:
>
> > On Jun 24, 2019, at 12:15 AM, Manuel Bouyer wrote:
> >
> > I'd like to see this in NetBSD. I'd also like packet filters to be able
> > to use the description instead of the name for interfaces. This would make
> > my life much
> On Jun 24, 2019, at 12:15 AM, Manuel Bouyer wrote:
>
> I'd like to see this in NetBSD. I'd also like packet filters to be able
> to use the description instead of the name for interfaces. This would make
> my life much easier for e.g. ipfilter in Xen dom0, where the domU's virtual
>
I think if_description in struct ifnet should be moved before the #ifdef
_KERNEL block so it stays at the same offset for non-_KERNEL users.
Cheers,
Jared
On Mon, 24 Jun 2019, KUSABA Takeshi wrote:
Hi,
I would like to propose a feature: a description of a network interface.
(FreeBSD and
On Mon, Jun 24, 2019 at 01:52:18PM +0900, KUSABA Takeshi wrote:
> Hi,
>
> I would like to propose a feature: a description of a network interface.
> (FreeBSD and OpenBSD support this feature.)
>
> Here is a patch.
>
>
Hi,
I would like to propose a feature: a description of a network interface.
(FreeBSD and OpenBSD support this feature.)
Here is a patch.
https://gist.githubusercontent.com/maleic1618/f4881717cbd3b1e3182984f9773b1001/raw/114b5d6c4fbe1fd9cd473fdc802b003c072c2794/description.patch
The sammary
23 matches
Mail list logo
