So far we seem to hit a few different problems when upgrading kernels.
1) mkinitrd may need changing, e.g. the raid4, raid5 and raid6 modules were combined into raid456 a while ago, breaking mkinitrd completely on raid machines.
2) some modules may now work that were broken, but they need new options, like snd-hda-intel which now works on my acer notebook if "probe_mask=1" is added to the module options.
3) like (2) but options may need to be removed. suddenly drivers that worked refuse to load becuase they no longer recognize options that used to be valid.
I'm especially concerned about (2) and (3) because there doesn't seem to be a system in place to update driver options after the system is installed. We can collect the needed changes but the logic to do all of this is in anaconda, and can only be applied during system install, as far as I can tell.
On Thu, 2007-03-22 at 12:54 -0400, Chuck Ebbert wrote:
- mkinitrd may need changing, e.g. the raid4, raid5 and raid6 modules were combined into raid456 a while ago, breaking mkinitrd completely on raid machines.
There are a pile of other userspace packages that also commonly need updates. alsa stuff, pcmcia, kudzu, udev/hal (less these days), ...
- some modules may now work that were broken, but they need new options, like snd-hda-intel which now works on my acer notebook if "probe_mask=1" is added to the module options.
This is just a case of broken drivers. Having to manually (modprobe.conf counts :) specify a module option to make a driver work means that the driver is broken -- these things _have_ to be auto-detected. Punting it to the user just isn't practical or reasonable.
- like (2) but options may need to be removed. suddenly drivers that worked refuse to load becuase they no longer recognize options that used to be valid.
And this is really a breakage of the "interface" exposed to userspace and really should be beaten down as driver breakage. Trying to handle things like this is a losing battle.
Jeremy
On Thu, 2007-03-22 at 13:05 -0400, Jeremy Katz wrote:
On Thu, 2007-03-22 at 12:54 -0400, Chuck Ebbert wrote:
- mkinitrd may need changing, e.g. the raid4, raid5 and raid6 modules were combined into raid456 a while ago, breaking mkinitrd completely on raid machines.
There are a pile of other userspace packages that also commonly need updates. alsa stuff, pcmcia, kudzu, udev/hal (less these days), ...
Oh don't count on that, I've got some plans to make udev/hal break a bit more often...joke.
- some modules may now work that were broken, but they need new options, like snd-hda-intel which now works on my acer notebook if "probe_mask=1" is added to the module options.
This is just a case of broken drivers. Having to manually (modprobe.conf counts :) specify a module option to make a driver work means that the driver is broken -- these things _have_ to be auto-detected. Punting it to the user just isn't practical or reasonable.
Indeed. And options that are removed *must* be supported for a while. We can't have modules that loaded previously now failing just because the maintainer decided to remove a previously valid option without warning. This needs strong upstream coercion on the part of those taking patches.
Jon.
Jon Masters wrote:
Indeed. And options that are removed *must* be supported for a while. We can't have modules that loaded previously now failing just because the maintainer decided to remove a previously valid option without warning. This needs strong upstream coercion on the part of those taking patches.
We can always put the option back in the module just to make it load, but I really don't want to be doing that all the time. Maybe I could write patches that put the options back and just make them print a warning saying the option is no longer valid, then send them upstream. Maybe after a few iterations of that people will get the point?
On Thu, 2007-03-22 at 14:21 -0400, Chuck Ebbert wrote:
Jon Masters wrote:
Indeed. And options that are removed *must* be supported for a while. We can't have modules that loaded previously now failing just because the maintainer decided to remove a previously valid option without warning. This needs strong upstream coercion on the part of those taking patches.
We can always put the option back in the module just to make it load, but I really don't want to be doing that all the time. Maybe I could write patches that put the options back and just make them print a warning saying the option is no longer valid, then send them upstream. Maybe after a few iterations of that people will get the point?
Sounds like exactly the right answer to me!
Jeremy
On Thu, 2007-03-22 at 14:21 -0400, Chuck Ebbert wrote:
Jon Masters wrote:
Indeed. And options that are removed *must* be supported for a while. We can't have modules that loaded previously now failing just because the maintainer decided to remove a previously valid option without warning. This needs strong upstream coercion on the part of those taking patches.
We can always put the option back in the module just to make it load, but I really don't want to be doing that all the time. Maybe I could write patches that put the options back and just make them print a warning saying the option is no longer valid, then send them upstream. Maybe after a few iterations of that people will get the point?
That's what I was thinking...I just didn't want to think too loudly in case you said "Hey Jon, wanna help?" :P
Jon.
On Thu, 2007-03-22 at 14:26 -0400, Jon Masters wrote:
On Thu, 2007-03-22 at 14:21 -0400, Chuck Ebbert wrote:
Jon Masters wrote:
Indeed. And options that are removed *must* be supported for a while. We can't have modules that loaded previously now failing just because the maintainer decided to remove a previously valid option without warning. This needs strong upstream coercion on the part of those taking patches.
We can always put the option back in the module just to make it load, but I really don't want to be doing that all the time. Maybe I could write patches that put the options back and just make them print a warning saying the option is no longer valid, then send them upstream. Maybe after a few iterations of that people will get the point?
That's what I was thinking...I just didn't want to think too loudly in case you said "Hey Jon, wanna help?" :P
Thanks for volunteering ;-)
Jeremy
Jeremy Katz wrote:
- some modules may now work that were broken, but they need new options, like snd-hda-intel which now works on my acer notebook if "probe_mask=1" is added to the module options.
This is just a case of broken drivers. Having to manually (modprobe.conf counts :) specify a module option to make a driver work means that the driver is broken -- these things _have_ to be auto-detected. Punting it to the user just isn't practical or reasonable.
But don't we do that now? Doesn't Anaconda know about options needed for certain hardware and put them in modprobe.conf at install time?
On Thu, 2007-03-22 at 14:22 -0400, Chuck Ebbert wrote:
Jeremy Katz wrote:
- some modules may now work that were broken, but they need new options, like snd-hda-intel which now works on my acer notebook if "probe_mask=1" is added to the module options.
This is just a case of broken drivers. Having to manually (modprobe.conf counts :) specify a module option to make a driver work means that the driver is broken -- these things _have_ to be auto-detected. Punting it to the user just isn't practical or reasonable.
But don't we do that now? Doesn't Anaconda know about options needed for certain hardware and put them in modprobe.conf at install time?
Nope! We list the module name and that's in. Any module options that end up there were specified manually (and through an excruciatingly painful UI) by the user
Jeremy
Jeremy Katz wrote:
But don't we do that now? Doesn't Anaconda know about options needed for certain hardware and put them in modprobe.conf at install time?
Nope! We list the module name and that's in. Any module options that end up there were specified manually (and through an excruciatingly painful UI) by the user
They were? I have this in modprobe.conf and I know I didn't put it there:
options snd-hda-intel index=0
On Thu, 2007-03-22 at 14:31 -0400, Chuck Ebbert wrote:
Jeremy Katz wrote:
But don't we do that now? Doesn't Anaconda know about options needed for certain hardware and put them in modprobe.conf at install time?
Nope! We list the module name and that's in. Any module options that end up there were specified manually (and through an excruciatingly painful UI) by the user
They were? I have this in modprobe.conf and I know I didn't put it there:
options snd-hda-intel index=0
Ugh... system-config-soundcard seems to be doing so. And it really really shouldn't be doing that as it's ultimately way too fragile to do :-/
Jeremy
Jeremy Katz (katzj@redhat.com) said:
options snd-hda-intel index=0
Ugh... system-config-soundcard seems to be doing so. And it really really shouldn't be doing that as it's ultimately way too fragile to do :-/
It's the only way to get persistent device ordering for sound cards. Yay crappy APIs.
Bill
On Sun, 2007-03-25 at 20:25 -0400, Bill Nottingham wrote:
Jeremy Katz (katzj@redhat.com) said:
options snd-hda-intel index=0
Ugh... system-config-soundcard seems to be doing so. And it really really shouldn't be doing that as it's ultimately way too fragile to do :-/
It's the only way to get persistent device ordering for sound cards. Yay crappy APIs.
Crap like that can hopefully go the way of the Dodo once we start using PulseAudio by default; won't happen for Fedora 7 though...
David
kernel@lists.fedoraproject.org
-
Bill Nottingham -
Chuck Ebbert -
David Zeuthen -
Jeremy Katz -
Jon Masters