From: Jan Beulich <hidden> Date: 2011-02-17 13:29:30
The CHELSIO_T{3,4}_DEPENDS options are really awkward, and can be
easily dropped if the reverse dependencies of SCSI_CXGB{3,4}_ISCSI on
the former get converted to normal (forward) ones referring to
CHELSIO_T{3,4}.
Signed-off-by: Jan Beulich <redacted>
---
drivers/net/Kconfig | 14 ++------------
drivers/scsi/cxgbi/cxgb3i/Kconfig | 3 +--
drivers/scsi/cxgbi/cxgb4i/Kconfig | 3 +--
3 files changed, 4 insertions(+), 16 deletions(-)
The CHELSIO_T{3,4}_DEPENDS options are really awkward, and can be
easily dropped if the reverse dependencies of SCSI_CXGB{3,4}_ISCSI on
the former get converted to normal (forward) ones referring to
CHELSIO_T{3,4}.
Signed-off-by: Jan Beulich <redacted>
I think the goal of these strange rules is not to be complicated
on purpose, but rather to cause the iSCSI drivers to appear without
the user having to know that he needs to enable the networking
driver in order for that to happen.
The CHELSIO_T{3,4}_DEPENDS options are really awkward, and can be
easily dropped if the reverse dependencies of SCSI_CXGB{3,4}_ISCSI on
the former get converted to normal (forward) ones referring to
CHELSIO_T{3,4}.
Signed-off-by: Jan Beulich <redacted>
I think the goal of these strange rules is not to be complicated
on purpose, but rather to cause the iSCSI drivers to appear without
the user having to know that he needs to enable the networking
driver in order for that to happen.
While I realize that this might have been the reason, it's completely
contrary to how everyone else writes dependencies, and hence I
think these should be removed.
Jan
The CHELSIO_T{3,4}_DEPENDS options are really awkward, and can be
easily dropped if the reverse dependencies of SCSI_CXGB{3,4}_ISCSI on
the former get converted to normal (forward) ones referring to
CHELSIO_T{3,4}.
Signed-off-by: Jan Beulich <redacted>
I think the goal of these strange rules is not to be complicated
on purpose, but rather to cause the iSCSI drivers to appear without
the user having to know that he needs to enable the networking
driver in order for that to happen.
While I realize that this might have been the reason, it's completely
contrary to how everyone else writes dependencies, and hence I
think these should be removed.
If you knew you were changing the behavior of the config option in
this way, you sure didn't think it was worth mentioning in your commit
message.
I definitely would never expect to have to enable a scsi option to get
some network driver visible to enable in the config, and therefore I
could see the opposite being insanely frustrating too.
You can't ignore these issues and just say "that's not the normal way
so I'm going to change it anyways."
The CHELSIO_T{3,4}_DEPENDS options are really awkward, and can be
easily dropped if the reverse dependencies of SCSI_CXGB{3,4}_ISCSI on
the former get converted to normal (forward) ones referring to
CHELSIO_T{3,4}.
Signed-off-by: Jan Beulich <redacted>
I think the goal of these strange rules is not to be complicated
on purpose, but rather to cause the iSCSI drivers to appear without
the user having to know that he needs to enable the networking
driver in order for that to happen.
While I realize that this might have been the reason, it's completely
contrary to how everyone else writes dependencies, and hence I
think these should be removed.
If you knew you were changing the behavior of the config option in
this way, you sure didn't think it was worth mentioning in your commit
message.
I stated in the comment what I think this is - awkward.
I definitely would never expect to have to enable a scsi option to get
some network driver visible to enable in the config, and therefore I
could see the opposite being insanely frustrating too.
The resulting dependency seems quite logical to me: Some higher
level networking functionality (iSCSI) depends on some lower level
networking functionality (an actual driver).
You can't ignore these issues and just say "that's not the normal way
so I'm going to change it anyways."
Admittedly I considered only my personal perspective.
Now, to get the whole discussion productive again - where do we
go from here? I don't think these drivers are so special that they
really need to behave backwards to how (almost?) everything else
is done... If changing it the way I did in the first try isn't deemed
acceptable, would it be at least acceptable to remove those
helper options (or, not as welcome from my perspective not the
least because of the odd dependency on INET instead of NET,
fold them into a single more generic one that others could also
benefit from)?
As to that INET vs NET dependency - is it possible that the
network drivers really just need NET, but the iSCSI ones need
INET? In which case the only common dependency would be
PCI - certainly not worth a custom helper option.
Jan
As to that INET vs NET dependency - is it possible that the
network drivers really just need NET, but the iSCSI ones need
INET? In which case the only common dependency would be
PCI - certainly not worth a custom helper option.
I see about a dozen network drivers that depend on INET. These may be the
result of cut&paste from other drivers' Kconfig entries rather than actual
dependencies. Also some of these drivers select or selected in the past
INET_LRO and that may have something to do with their INET dependency, not sure.
Reading the commit message that introduced CHELSIO_T3_DEPENDS, it talks of
hidden dependencies that select does not see. I am not sure which exactly
but since it's been a few years since that commit I'll try to see what the
situation is today without the *_DEPENDS symbols and let you know.
As to that INET vs NET dependency - is it possible that the
network drivers really just need NET, but the iSCSI ones need
INET? In which case the only common dependency would be
PCI - certainly not worth a custom helper option.
Reading the commit message that introduced CHELSIO_T3_DEPENDS, it talks
of hidden dependencies that select does not see. I am not sure which
exactly but since it's been a few years since that commit I'll try to
see what the situation is today without the *_DEPENDS symbols and let
you know.
I looked into this and found that with the current Kconfig the iSCSI driver
does not appear in the SCSI menu until one first enables NETDEVICES and
NETDEV_10000 in the network driver menu. It appears that the *_DEPENDS
symbols were added to capture dependencies on such symbols within the
network driver Kconfig, besides the dependencies the driver's entry listed
explicitly.
The patch below removes *T4*_DEPENDS and the network drivers' unnecessary
dependency on INET, and updates the iSCSI driver's entry so it is visible
without requiring any net driver options to be enabled first and has
adequate selects to be able to build the net driver (this part is adapted
from bnx2i's Kconfig entry). I still need to do the T3 part of this and
check that there isn't a conflict with the current scsi tree. Just for
review at this time.
From: Jan Beulich <hidden> Date: 2011-02-28 08:19:58
quoted
quoted
On 25.02.11 at 20:51, Dimitris Michailidis [off-list ref] wrote:
Dimitris Michailidis wrote:
quoted
Jan Beulich wrote:
quoted
As to that INET vs NET dependency - is it possible that the
network drivers really just need NET, but the iSCSI ones need
INET? In which case the only common dependency would be
PCI - certainly not worth a custom helper option.
Reading the commit message that introduced CHELSIO_T3_DEPENDS, it talks
of hidden dependencies that select does not see. I am not sure which
exactly but since it's been a few years since that commit I'll try to
see what the situation is today without the *_DEPENDS symbols and let
you know.
I looked into this and found that with the current Kconfig the iSCSI driver
does not appear in the SCSI menu until one first enables NETDEVICES and
NETDEV_10000 in the network driver menu. It appears that the *_DEPENDS
symbols were added to capture dependencies on such symbols within the
network driver Kconfig, besides the dependencies the driver's entry listed
explicitly.
The patch below removes *T4*_DEPENDS and the network drivers' unnecessary
dependency on INET, and updates the iSCSI driver's entry so it is visible
without requiring any net driver options to be enabled first and has
adequate selects to be able to build the net driver (this part is adapted
from bnx2i's Kconfig entry). I still need to do the T3 part of this and
check that there isn't a conflict with the current scsi tree. Just for
review at this time.
On 25.02.11 at 20:51, Dimitris Michailidis [off-list ref] wrote:
Dimitris Michailidis wrote:
quoted
Jan Beulich wrote:
quoted
As to that INET vs NET dependency - is it possible that the
network drivers really just need NET, but the iSCSI ones need
INET? In which case the only common dependency would be
PCI - certainly not worth a custom helper option.
Reading the commit message that introduced CHELSIO_T3_DEPENDS, it talks
of hidden dependencies that select does not see. I am not sure which
exactly but since it's been a few years since that commit I'll try to
see what the situation is today without the *_DEPENDS symbols and let
you know.
I looked into this and found that with the current Kconfig the iSCSI driver
does not appear in the SCSI menu until one first enables NETDEVICES and
NETDEV_10000 in the network driver menu. It appears that the *_DEPENDS
symbols were added to capture dependencies on such symbols within the
network driver Kconfig, besides the dependencies the driver's entry listed
explicitly.
The patch below removes *T4*_DEPENDS and the network drivers' unnecessary
dependency on INET, and updates the iSCSI driver's entry so it is visible
without requiring any net driver options to be enabled first and has
adequate selects to be able to build the net driver (this part is adapted
from bnx2i's Kconfig entry). I still need to do the T3 part of this and
check that there isn't a conflict with the current scsi tree. Just for
review at this time.
Thanks, this looks good to me.
Dimitris, please submit this anew with a proper commit log messag and
signoff. Thanks.