Re: Bug#658185: freebsd-9: freebsd-9 kernel + smartmontools: "error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device"
2012/2/5, Aurelien Jarno <firstname.lastname@example.org>:
> 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  kernel if
we want to, or we can add 9.0 compat glue to 8.x kernel.
 For a very loose meaning of "default". User selection is still
> 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:
I only realized that freebsd-utils 8.x  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.
 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
> - 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.