Re: Bug#658185: freebsd-9: freebsd-9 kernel + smartmontools: "error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device"
2012/2/5, Aurelien Jarno <aurelien@aurel32.net>:
> The problem there is that given that all 9.x packages have been already
> pushed to the archive with ABI changes and so on, we *must* switch the
> default kernel for wheezy to 9.x.
This is not really the case. We can switch the default [1] kernel if
we want to, or we can add 9.0 compat glue to 8.x kernel.
[1] For a very loose meaning of "default". User selection is still
very explicit.
> I don't say it's a bad decision, but
> I would have prefer to have some discussion about, it including the
> possible consequences of such a choice, instead of getting to the point
> of not having any other choice.
I would have preferred that, too. This is why I asked whether it was
a good idea to upgrade kfreebsd-kernel-headers to 9.0:
http://lists.debian.org/debian-bsd/2012/01/msg00057.html
I only realized that freebsd-utils 8.x [1] wouldn't build with the new
headers about 3 weeks later, after several hours of trying. I wish
someone had told me. At that point packages were already building
against 9.0 headers and we had no way to turn back.
[1] Yes, freebsd-utils. Of course I _did_ test freebsd-libs 8.x with
the new k-k-h, but freebsd-libs 8.x had no problem because it
duplicates the whole thing and was silently using its private copy of
kernel headers. Too bad I only run into real trouble when attempting
the upgrade of freebsd-utils to 8.3~snapshot, which required a small
change in libcam API. Then I tried cherry-picking that change, and it
kept dragging more things in. Eventually it was unmanageable. And
yes, I wish someone had told me to test freebsd-utils first. I guess
if noone said this it's simply because nobody knew.
FWIW, I'll see if freebsd-libs can be fixed to use system k-k-h
instead of duplicating everything.
> Now we have no choice than making a real plan for switching to 9.x
> kernel:
> - We have to make sure users are using wheezy/sid with a 9.x kernel.
> - We have to provide an upgrade path for users, including the best
> moment to switch from one kernel to another in the release notes.
You're missing a bigger part of the problem: fixing runtime problems
in userland that are only exposed by kfreebsd-9.
Overall I wouldn't recommend making 9.x "default" if we can avoid it.
The only problem with kfreebsd-8 right now, that we know of, is CAM.
And it's not a severe problem (camcontrol effect on average user is
only cosmetical), nor a hard problem (see #658617).
> - The build daemons are going to stay with the 8.1 kernel up to the
> release of wheezy. Will it work?
Sounds like a safe bet to me.
> Sometimes after they are going to
> switch to a 9.x kernel, but they should still be able to build squeeze
> packages. Will it work?
kfreebsd-9 is unusable on Squeeze. After glibc 2.11.3-1 upload this
got much better but there are still incompatibilities with sysvinit
and with ZFS v28 userland.
> Who wants to work on addressing these points?
I don't like the incriminatory tone of this mail. I'm just trying to
help here. When I run into a complex decision, I ask the list for
advice, most of the time I don't get any of. But I try anyway,
because I think advice is valuable. Oh yes, I wish people had
participated in that discussion, as with many others. But I don't
blame anybody, I don't point at them. People are busy. It's ok really.
But I'd rather have a productive discussion than a useless rant. Can
we argue about how to solve things?
My advice is not to make this any bigger than it is: The only
kernel<->user problem we know of is an incompatibility in CAM, which
has a low impact and is not hard to fix. I don't recommend trying to
declare kfreebsd-9 as fully supported because that smells like a lot
more work than simply cherry-picking a few commits into kfreebsd-8.
--
Robert Millan
Reply to: