Dead Config Option STMMAC_ETH?

Dead Config Option STMMAC_ETH?

[Christian Dietrich]

Hi all!
       
        As part of the VAMOS[0] research project at the University of
Erlangen we are looking at multiple integrity errors in linux'
configuration system.

        I've been running a check on the drivers/net/stmmac sourcetree for
config Items not defined in Kconfig and found such a case. Sourcecode
blocks depending on these Items are not reachable from a vanilla
kernel -- dead code. I've seen such dead blocks made on purpose
e.g. while integrating new features into the kernel but generally
they're just useless.

As far as i can see in drivers/net/stmmac/Kconfig STMMAC_ETH and several
depending flags are dead in the linux vanilla kernel, because it depends
on CPU_SUBTYPE_ST40, but there isn't a Kconfig option for that. But
f96691872439ab2071171d4531c4a95b5d493ae5 suggests, that support for this
ST40 plattform was removed in 2007.

There seems to be, that there was much effort on the stmmac drivers in
the last few months, so i just wanted to ask if this problem is known.

Regards

        Christian Dietrich

[0] http://vamos1.informatik.uni-erlangen.de
-- 
(λ x . x x) (λ x . x x) -- See how beatiful the lambda is
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.

Dead Config Option STMMAC_ETH?

[Christian Dietrich]

Hi all!
       
        As part of the VAMOS[0] research project at the University of
Erlangen we are looking at multiple integrity errors in linux'
configuration system.

        I've been running a check on the drivers/net/stmmac sourcetree for
config Items not defined in Kconfig and found such a case. Sourcecode
blocks depending on these Items are not reachable from a vanilla
kernel -- dead code. I've seen such dead blocks made on purpose
e.g. while integrating new features into the kernel but generally
they're just useless.

As far as i can see in drivers/net/stmmac/Kconfig STMMAC_ETH and several
depending flags are dead in the linux vanilla kernel, because it depends
on CPU_SUBTYPE_ST40, but there isn't a Kconfig option for that. But
f96691872439ab2071171d4531c4a95b5d493ae5 suggests, that support for this
ST40 plattform was removed in 2007.

There seems to be, that there was much effort on the stmmac drivers in
the last few months, so i just wanted to ask if this problem is known.

Regards

        Christian Dietrich

[0] http://vamos1.informatik.uni-erlangen.de
-- 
(λ x . x x) (λ x . x x) -- See how beatiful the lambda is
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.

RE: Dead Config Option STMMAC_ETH?

[Peppe CAVALLARO]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2260 bytes --]

Hi Christian,

> -----Original Message-----
> From: Christian Dietrich [mailto:qy03fugy@stud.informatik.uni-erlangen.de]
> Sent: Tuesday, August 10, 2010 2:29 PM
> To: David S. Miller; Peppe CAVALLARO; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: vamos-dev@i4.informatik.uni-erlangen.de
> Subject: Dead Config Option STMMAC_ETH?
> 
> Hi all!
> 
>         As part of the VAMOS[0] research project at the University of
> Erlangen we are looking at multiple integrity errors in linux'
> configuration system.
> 
>         I've been running a check on the drivers/net/stmmac sourcetree for
> config Items not defined in Kconfig and found such a case. Sourcecode
> blocks depending on these Items are not reachable from a vanilla
> kernel -- dead code. I've seen such dead blocks made on purpose
> e.g. while integrating new features into the kernel but generally
> they're just useless.
> 
> As far as i can see in drivers/net/stmmac/Kconfig STMMAC_ETH and several
> depending flags are dead in the linux vanilla kernel, because it depends
> on CPU_SUBTYPE_ST40, but there isn't a Kconfig option for that. But
> f96691872439ab2071171d4531c4a95b5d493ae5 suggests, that support for this
> ST40 plattform was removed in 2007.
> 
> There seems to be, that there was much effort on the stmmac drivers in
> the last few months, so i just wanted to ask if this problem is known.

There is effort on this driver: currently the driver fully works on STM platforms and starts working on ARM (SPEAr Kernels).
The driver Kconfig actually depends on the CPU_SUBTYPE_ST40 but it built on x86 if remove this dependency (just verified).
In the past, I added this dependency because the driver was initially tested on ST kernels (where we continue to have the CPU_SUBTYPE_ST40) but I can review it if you like.

Regards,
Peppe


> Regards
> 
>         Christian Dietrich
> 
> [0] http://vamos1.informatik.uni-erlangen.de
> --
> (λ x . x x) (λ x . x x) -- See how beatiful the lambda is
> No documentation is better than bad documentation
> -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: Dead Config Option STMMAC_ETH?

[Peppe CAVALLARO]

Hi Christian,

> -----Original Message-----
> From: Christian Dietrich [mailto:qy03fugy@stud.informatik.uni-erlangen.de]
> Sent: Tuesday, August 10, 2010 2:29 PM
> To: David S. Miller; Peppe CAVALLARO; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: vamos-dev@i4.informatik.uni-erlangen.de
> Subject: Dead Config Option STMMAC_ETH?
> 
> Hi all!
> 
>         As part of the VAMOS[0] research project at the University of
> Erlangen we are looking at multiple integrity errors in linux'
> configuration system.
> 
>         I've been running a check on the drivers/net/stmmac sourcetree for
> config Items not defined in Kconfig and found such a case. Sourcecode
> blocks depending on these Items are not reachable from a vanilla
> kernel -- dead code. I've seen such dead blocks made on purpose
> e.g. while integrating new features into the kernel but generally
> they're just useless.
> 
> As far as i can see in drivers/net/stmmac/Kconfig STMMAC_ETH and several
> depending flags are dead in the linux vanilla kernel, because it depends
> on CPU_SUBTYPE_ST40, but there isn't a Kconfig option for that. But
> f96691872439ab2071171d4531c4a95b5d493ae5 suggests, that support for this
> ST40 plattform was removed in 2007.
> 
> There seems to be, that there was much effort on the stmmac drivers in
> the last few months, so i just wanted to ask if this problem is known.

There is effort on this driver: currently the driver fully works on STM platforms and starts working on ARM (SPEAr Kernels).
The driver Kconfig actually depends on the CPU_SUBTYPE_ST40 but it built on x86 if remove this dependency (just verified).
In the past, I added this dependency because the driver was initially tested on ST kernels (where we continue to have the CPU_SUBTYPE_ST40) but I can review it if you like.

Regards,
Peppe


> Regards
> 
>         Christian Dietrich
> 
> [0] http://vamos1.informatik.uni-erlangen.de
> --
> (λ x . x x) (λ x . x x) -- See how beatiful the lambda is
> No documentation is better than bad documentation
> -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.

Re: Dead Config Option STMMAC_ETH?

[Christian Dietrich]

Peppe CAVALLARO <peppe.cavallaro@st.com> writes:

[...]

> There is effort on this driver: currently the driver fully works on
> STM platforms and starts working on ARM (SPEAr Kernels).  The driver
> Kconfig actually depends on the CPU_SUBTYPE_ST40 but it built on x86
> if remove this dependency (just verified).  In the past, I added this
> dependency because the driver was initially tested on ST kernels
> (where we continue to have the CPU_SUBTYPE_ST40) but I can review it
> if you like.

Hm, i think it would be good if this dependency is removed, if it isn't
needed, because then a allyes config would compile test this peace of
code, and it can't die silently with changes around it.

greetz didi
-- 
(λ x . x x) (λ x . x x) -- See how beatiful the lambda is
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.

Re: Dead Config Option STMMAC_ETH?

[Christian Dietrich]

Peppe CAVALLARO <peppe.cavallaro@st.com> writes:

[...]

> There is effort on this driver: currently the driver fully works on
> STM platforms and starts working on ARM (SPEAr Kernels).  The driver
> Kconfig actually depends on the CPU_SUBTYPE_ST40 but it built on x86
> if remove this dependency (just verified).  In the past, I added this
> dependency because the driver was initially tested on ST kernels
> (where we continue to have the CPU_SUBTYPE_ST40) but I can review it
> if you like.

Hm, i think it would be good if this dependency is removed, if it isn't
needed, because then a allyes config would compile test this peace of
code, and it can't die silently with changes around it.

greetz didi
-- 
(λ x . x x) (λ x . x x) -- See how beatiful the lambda is
No documentation is better than bad documentation
-- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.

RE: Dead Config Option STMMAC_ETH?

[Peppe CAVALLARO]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1521 bytes --]

Hi Christian,

> -----Original Message-----
> From: Christian Dietrich [mailto:qy03fugy@stud.informatik.uni-erlangen.de]
> Sent: Monday, August 23, 2010 10:42 AM
> To: Peppe CAVALLARO
> Cc: Christian Dietrich; David S. Miller; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; vamos-dev@i4.informatik.uni-erlangen.de
> Subject: Re: Dead Config Option STMMAC_ETH?
> 
> Peppe CAVALLARO <peppe.cavallaro@st.com> writes:
> 
> [...]
> 
> > There is effort on this driver: currently the driver fully works on
> > STM platforms and starts working on ARM (SPEAr Kernels).  The driver
> > Kconfig actually depends on the CPU_SUBTYPE_ST40 but it built on x86
> > if remove this dependency (just verified).  In the past, I added this
> > dependency because the driver was initially tested on ST kernels
> > (where we continue to have the CPU_SUBTYPE_ST40) but I can review it
> > if you like.
> 
> Hm, i think it would be good if this dependency is removed, if it isn't
> needed, because then a allyes config would compile test this peace of
> code, and it can't die silently with changes around it.

No problem. I'll remove it and review the Kconfig asap.

Peppe

> 
> greetz didi
> --
> (λ x . x x) (λ x . x x) -- See how beatiful the lambda is
> No documentation is better than bad documentation
> -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: Dead Config Option STMMAC_ETH?

[Peppe CAVALLARO]

Hi Christian,

> -----Original Message-----
> From: Christian Dietrich [mailto:qy03fugy@stud.informatik.uni-erlangen.de]
> Sent: Monday, August 23, 2010 10:42 AM
> To: Peppe CAVALLARO
> Cc: Christian Dietrich; David S. Miller; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; vamos-dev@i4.informatik.uni-erlangen.de
> Subject: Re: Dead Config Option STMMAC_ETH?
> 
> Peppe CAVALLARO <peppe.cavallaro@st.com> writes:
> 
> [...]
> 
> > There is effort on this driver: currently the driver fully works on
> > STM platforms and starts working on ARM (SPEAr Kernels).  The driver
> > Kconfig actually depends on the CPU_SUBTYPE_ST40 but it built on x86
> > if remove this dependency (just verified).  In the past, I added this
> > dependency because the driver was initially tested on ST kernels
> > (where we continue to have the CPU_SUBTYPE_ST40) but I can review it
> > if you like.
> 
> Hm, i think it would be good if this dependency is removed, if it isn't
> needed, because then a allyes config would compile test this peace of
> code, and it can't die silently with changes around it.

No problem. I'll remove it and review the Kconfig asap.

Peppe

> 
> greetz didi
> --
> (λ x . x x) (λ x . x x) -- See how beatiful the lambda is
> No documentation is better than bad documentation
> -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.