netdev - Re: extending feature word.

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BANLkTi=JH0R_T_sH4nYKeGRUA4GXt6Q5bQ@mail.gmail.com>
Date:	Tue, 5 Apr 2011 15:15:21 -0700
From:	Mahesh Bandewar <maheshb@...gle.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	Michał Mirosław <mirq-linux@...e.qmqm.pl>,
	linux-netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: extending feature word.

On Tue, Apr 5, 2011 at 5:07 AM, Ben Hutchings <bhutchings@...arflare.com> wrote:
> On Tue, 2011-04-05 at 13:30 +0200, Michał Mirosław wrote:
>> On Sat, Apr 02, 2011 at 08:09:14PM -0700, Mahesh Bandewar wrote:
>> > On Sat, Apr 2, 2011 at 5:42 AM, Michał Mirosław <mirq-linux@...e.qmqm.pl> wrote:
>> > > On Fri, Apr 01, 2011 at 07:07:05PM -0700, Mahesh Bandewar wrote:
>> > > If you want to split the work, it would be clearer to first convert
>> > > hw_features and wanted_features (with all the core code touching it -
>> > > this is the easy part), then vlan_features (this includes drivers'
>> > > and VLAN code) and then features (it's all over).
>> > I like the idea of splitting but it will be only useful when all of it
>> > is done and not partially, isn't it? Or am I missing something?
>>
>> Since this is a big change, when split it might be easier to follow.
>> OTOH, with your idea of macro it might be easier to do incremental
>> changes (I think this will be a lot of work for no gain in this case).
>
> I strongly disagree with using macros for this.  They are very likely to
> conflict with other identifiers..
>
> We might be able to get away with something like:
>
>        union {
>                u32 features;
>                u32 feature[N];
>        };
>        union {
>                u32 vlan_features;
>                u32 vlan_feature[N];
>        };
>        union {
>                u32 hw_features;
>                u32 hw_feature[N];
>        };
>
unfortunately the members have to be of the same size to be part of a
name-less union. Otherwise you have to name it and add a macro to
provide backward compatibility. I did not find other occurrence of
"legacy_(hw/wanted/vlan)_features" if that was your only concern.

Having a macro is not the best thing and ideally I would want this to
live as little as possible. Since the use is so wide spread, having
the ability to make incremental changes is required. Once we switch to
the new method, hopefully we can eliminate this macro.

> (assuming hw_features is new enough that there is no need for the
> alias).
>
> Anyway, if we're going to put all the feature words in net_device
> there's no longer any reason for NETIF_F_LOOPBACK not to be in the first
> word.
>
Too late Ben, I think Tom already used the last available bit :)

> Ben.
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html