[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:


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: