Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-02 Thread Christoph Hellwig
On Thu, Dec 02, 2004 at 12:41:59PM +0100, Christoffer Sawicki wrote:
> What if the PCI ID associations in the kernel for eepro100 and e100 were 
> changed so that a card is only associated with the module it works (best) 
> with? The only issue I see with this approach is collecting the necesary 
> data...

There's not exact data I know of.  One idea would be to remove all PCI
IDs from eeproo100 and only allow assigning cards to it why the dynamic
pci device ids through sysfs approach




Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-02 Thread Christoffer Sawicki
> > Apart from the issue Jerome mentions where some older hardware isn't
> > supported by e100 but is supported by eepr100, what if new kernels didn't
> > build/provide eepro100 and instead eepro100 was aliased to e100, or do
> > they have incompatible parameters?
>
> I am quite confortable with not including the eepro100 driver
> as it is being debricated upstream.

What if the PCI ID associations in the kernel for eepro100 and e100 were 
changed so that a card is only associated with the module it works (best) 
with? The only issue I see with this approach is collecting the necesary 
data...

*/ Christoffer Sawicki <[EMAIL PROTECTED]>




Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-02 Thread Mike Hommey
On Thu, Dec 02, 2004 at 08:33:32AM +1100, Brian May <[EMAIL PROTECTED]> wrote:
> > "Mike" == Mike Hommey <[EMAIL PROTECTED]> writes:
> 
> Mike> On Wed, Dec 01, 2004 at 01:33:32PM +0100, Marco d'Itri
> Mike> <[EMAIL PROTECTED]> wrote:
> >> This is not a problem
> >> (/etc/hotplug/blacklist.d/kernel-image-n.n.n-m).
> 
> Mike> Actually, it can be. Let's imagine the absurd case where
> Mike> kernel-image-x blacklists eepro100 and kernel-image-y
> Mike> blacklists e100, we have a system with no intel ethernet pro
> Mike> 100 support. That won't happen for this particular module
> Mike> set, but i'm pretty sure such case could happen some day.
> 
> Shouldn't it depend on what kernel is booted rather then what kernels
> are installed?

That's what i was implying. It *should*. The thing is that it's not the
way hotplug works.

Mike




Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-01 Thread Horms
On Thu, Dec 02, 2004 at 11:40:55AM +1100, Andrew Pollock wrote:
> On Wed, Dec 01, 2004 at 01:51:28PM +0100, Josselin Mouette wrote:
> > Le mercredi 01 d??cembre 2004 ?? 18:48 +0900, Horms a ??crit :
> > > > Another example are the Realtek 8149 drivers. I had to blacklist one 
> > > > of the drivers. This chipset is really common. So many people will 
> > > > have to do this.
> > > 
> > > If the blacklist exists for other devices, then yes this sounds like
> > > a good idea. The e100 should be used over the eepro100 as
> > > the later is in the process of being debricated upstream.
> > 
> > The solution looks obvious: don't build these deprecated drivers when
> > there is already one working driver in the same kernel package.
> > 
> > Or build them, but put them in a directory which depmod and hotplug will
> > omit. The module will still be loadable by hand, but won't be used by
> > default.
> 
> Apart from the issue Jerome mentions where some older hardware isn't
> supported by e100 but is supported by eepr100, what if new kernels didn't
> build/provide eepro100 and instead eepro100 was aliased to e100, or do they
> have incompatible parameters?

I am quite confortable with not including the eepro100 driver
as it is being debricated upstream.

-- 
Horms




Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-01 Thread Andrew Pollock
On Wed, Dec 01, 2004 at 01:51:28PM +0100, Josselin Mouette wrote:
> Le mercredi 01 d??cembre 2004 ?? 18:48 +0900, Horms a ??crit :
> > > Another example are the Realtek 8149 drivers. I had to blacklist one 
> > > of the drivers. This chipset is really common. So many people will 
> > > have to do this.
> > 
> > If the blacklist exists for other devices, then yes this sounds like
> > a good idea. The e100 should be used over the eepro100 as
> > the later is in the process of being debricated upstream.
> 
> The solution looks obvious: don't build these deprecated drivers when
> there is already one working driver in the same kernel package.
> 
> Or build them, but put them in a directory which depmod and hotplug will
> omit. The module will still be loadable by hand, but won't be used by
> default.

Apart from the issue Jerome mentions where some older hardware isn't
supported by e100 but is supported by eepr100, what if new kernels didn't
build/provide eepro100 and instead eepro100 was aliased to e100, or do they
have incompatible parameters?

regards

Andrew

-- 
linux.conf.au 2005   -  http://lca2005.linux.org.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://lca2005.linux.org.au/  -   LINUX
Canberra, Australia  -  http://lca2005.linux.org.au/  -Get bitten!




Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-01 Thread Marco d'Itri
On Dec 01, Brian May <[EMAIL PROTECTED]> wrote:

> Shouldn't it depend on what kernel is booted rather then what kernels
> are installed?
Maybe it should, but I'm not sure that there is an easy way to implement
this. grep blacklist /etc/hotplug/*

-- 
ciao, |
Marco | [9533 fiSC3qo3K2SOw]


signature.asc
Description: Digital signature


Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-01 Thread Brian May
> "Mike" == Mike Hommey <[EMAIL PROTECTED]> writes:

Mike> On Wed, Dec 01, 2004 at 01:33:32PM +0100, Marco d'Itri
Mike> <[EMAIL PROTECTED]> wrote:
>> This is not a problem
>> (/etc/hotplug/blacklist.d/kernel-image-n.n.n-m).

Mike> Actually, it can be. Let's imagine the absurd case where
Mike> kernel-image-x blacklists eepro100 and kernel-image-y
Mike> blacklists e100, we have a system with no intel ethernet pro
Mike> 100 support. That won't happen for this particular module
Mike> set, but i'm pretty sure such case could happen some day.

Shouldn't it depend on what kernel is booted rather then what kernels
are installed?

Last I heard, you can only boot one kernel at a time, so only one
module should get blacklisted at a time?

Not that I understand how the kernel works, but it strikes me as odd
that you would want to make decisions on kernel modules based on what
kernels are installed.
-- 
Brian May <[EMAIL PROTECTED]>




Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-01 Thread Christoph Hellwig
On Wed, Dec 01, 2004 at 07:55:59PM +0900, Mike Hommey wrote:
> The problem is the following: is the e100 driver available in all kernel
> flavours/versions ?
> If yes, then it is safe to blacklist it in hotplug directly.
> If not, then it is not safe to do it in hotplug because it would
> blacklist eepro100 which would be the only working module on some
> flavours/versions.

eepro100 is the older driver, but e100 has been available since early
2.4, so it's there in all debian kernels.  e100 supports much more
hardware than eepro100 (like the one on the mainboard of one of my
boxens) and is actively maintained by Intel while eepro100 only gets
odd fixes.  Unfortunately there's some older hardware where eepro100
works and e100 doesn't, and debugging this is really hard because the
hardware has gazillions of slightly incompatible variants.




Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-01 Thread Mike Hommey
On Wed, Dec 01, 2004 at 01:33:32PM +0100, Marco d'Itri <[EMAIL PROTECTED]> 
wrote:
> This is not a problem (/etc/hotplug/blacklist.d/kernel-image-n.n.n-m).

Actually, it can be. Let's imagine the absurd case where kernel-image-x
blacklists eepro100 and kernel-image-y blacklists e100, we have a system
with no intel ethernet pro 100 support. That won't happen for this
particular module set, but i'm pretty sure such case could happen some
day.

Mike




Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-01 Thread Josselin Mouette
Le mercredi 01 dÃcembre 2004 Ã 18:48 +0900, Horms a Ãcrit :
> > Another example are the Realtek 8149 drivers. I had to blacklist one 
> > of the drivers. This chipset is really common. So many people will 
> > have to do this.
> 
> If the blacklist exists for other devices, then yes this sounds like
> a good idea. The e100 should be used over the eepro100 as
> the later is in the process of being debricated upstream.

The solution looks obvious: don't build these deprecated drivers when
there is already one working driver in the same kernel package.

Or build them, but put them in a directory which depmod and hotplug will
omit. The module will still be loadable by hand, but won't be used by
default.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=


Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-01 Thread Marco d'Itri
On Dec 01, Mike Hommey <[EMAIL PROTECTED]> wrote:

> The problem is the following: is the e100 driver available in all kernel
> flavours/versions ?
> If yes, then it is safe to blacklist it in hotplug directly.
But it's still not obvious that it's desirable: I hate that when someone
compiles his own kernel with some blacklist driver he has to remove it
from the blacklist to have it work. It would be much better if all
binary kernel packages blacklisted the drivers that need to be
blacklisted by default.

> First, how to cleanly handle the fact that several kernel packages want
> to set the blacklist ? But that issue can be solved, it's not really a
> problem.
This is not a problem (/etc/hotplug/blacklist.d/kernel-image-n.n.n-m).

> Second, let's say we have kernel x and kernel y installed on the host,
> and x doesn't have e100, while y has it. The kernel package y blacklists
> eepro100, well then, we have the problem that we can't boot on kernel x
> and have eepro100 loaded...
This cannot be solved easily.

-- 
ciao, |
Marco | [9524 opfbu80iartn.]


signature.asc
Description: Digital signature


Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-01 Thread Mike Hommey
On Wed, Dec 01, 2004 at 06:48:35PM +0900, Horms <[EMAIL PROTECTED]>
wrote:
> If the blacklist exists for other devices, then yes this sounds like a
> good idea. The e100 should be used over the eepro100 as the later is
> in the process of being debricated upstream.

The problem is the following: is the e100 driver available in all kernel
flavours/versions ?
If yes, then it is safe to blacklist it in hotplug directly.
If not, then it is not safe to do it in hotplug because it would
blacklist eepro100 which would be the only working module on some
flavours/versions.
But then, we have 2 other problems.
First, how to cleanly handle the fact that several kernel packages want
to set the blacklist ? But that issue can be solved, it's not really a
problem.
Second, let's say we have kernel x and kernel y installed on the host,
and x doesn't have e100, while y has it. The kernel package y blacklists
eepro100, well then, we have the problem that we can't boot on kernel x
and have eepro100 loaded...

Mike




Re: Simultaneous loading of e100 and eepro100 by hotplug

2004-12-01 Thread Horms
On Tue, Nov 30, 2004 at 02:06:04PM +0100, Michael Koch wrote:
> Am Dienstag, 30. November 2004 13:48 schrieb Marco d'Itri:
> > On Nov 30, Jérôme Warnier <[EMAIL PROTECTED]> wrote:
> > > Currently, I blacklist one of them in hotplug
> > > (/etc/hotplug/blacklist.d), but wonder if it should not be done
> > > by default in the hotplug package.
> >
> > I wonder if it should not be up to our kernel packages to blacklist
> > drivers which should not be loaded by default (another example is
> > the watchdog drivers, currently blacklisted by hotplug).
> > I'd like to know the opinion of the debian kernel maintainers.
> 
> Another example are the Realtek 8149 drivers. I had to blacklist one 
> of the drivers. This chipset is really common. So many people will 
> have to do this.

If the blacklist exists for other devices, then yes this sounds like
a good idea. The e100 should be used over the eepro100 as
the later is in the process of being debricated upstream.

-- 
Horms