Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] udev vs. hotplug, part two: solutions

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Juuso Alasuutari <iuso AT sourcemage.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] udev vs. hotplug, part two: solutions
  • Date: Fri, 19 Jan 2007 11:10:35 +0000

I'll take the lack of responses to this mail as a silent nod to go ahead.
I'll
of course run local tests of a stable to stable-rc upgrade before committing.


On Tuesday 16 January 2007 10:46, Juuso Alasuutari wrote:
> I've been thinking more about how to make the transition from hotplug to
> udev work smoothly for stable 0.4 -> 0.6. My conception is that there are
> two main obstacles:
>
> 1) Udev needs to replace hotplug during system-upgrade if both are already
> installed, but hotplug needs to be available for e.g. static /dev systems.
> 2) The new udev needs to be cast after linux if both are in the install
> queue.
>
>
> Possible solution for 1:
>
> This would be easily solved if we could just deprecate hotplug in favor of
> udev. But there are those who use static /dev or want to experiment.
> Therefore I suggest this solution:
>
> - Add 'conflicts hotplug y' in udev, so that it will overthrow hotplug when
> cast. (Having udev installed implies that you're not a static /dev user.)
> - Add a check in hotplug that will abort cast if udev > 0.91 is installed
> and tell the user why. This will fix situations where both udev and hotplug
> are in the queue and hotplug is cast after udev -- without this check udev
> would dispel hotplug, but it would then be cast again.
>
> One problem I can see with this is, that if udev fails to cast, the user
> will be left without a new udev and hotplug. But I think we can't
> absolutely guarantee that a conflict is safe, or can we?
>
>
> Possible solution for 2:
>
> This problem stems from the fact that the new udev spell won't cast if
> linux < 2.6.15. If during a system-upgrade udev is queued before linux,
> linux will still be 2.6.14.2 when udev attempts to cast.
>
> It would be a neat solution to add 'depends linux' in udev, but we won't do
> that because some users prefer custom kernels. For them we can't guarantee
> that the system-upgrade pulls through unless they cast a new kernel before
> it, but that's the risk that one takes with custom stuff. We should mainly
> worry about udev working together with the linux spell without enforcing
> linux on anyone.
>
> Something that a few people have suggested already is adding an up_trigger
> in linux. It would trigger a udev cast if:
>
> - Udev is installed and its version is < 0.92, and the udev in the grimoire
> is > 0.91.
>
> - Installed kernel version is < 2.6.15 and the version to be installed is
> >= 2.6.15.
>
> These checks should narrow the up_trigger cases to the one time we need to
> worry about, which is the transition.
>
>
> As always I'm in need of feedback to point out the possible holes in this
> scheme before I implement it.

--
Juuso Alasuutari
[[ Source Mage GNU/Linux ]]

Attachment: pgpGnN7QPjzl4.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page