all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* why is linux-libre-headers behind linux-libre?
@ 2017-10-31 12:35 Dave Love
  2017-10-31 13:00 ` Vincent Legoll
  0 siblings, 1 reply; 12+ messages in thread
From: Dave Love @ 2017-10-31 12:35 UTC (permalink / raw)
  To: guix-devel

Why is linux-libre-headers a long way behind linux-libre (currently at
version 4.4.47, compared with 4.13.10 for linux-libre)?

I ask because current OmniPath fabric support ("psm2") won't build
against it, so I wonder if it can be updated.  Maybe other recent
hardware support will be similar.  (I realize the relevant driver, hfi1,
is deblobbed in linux-libre.)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: why is linux-libre-headers behind linux-libre?
  2017-10-31 12:35 why is linux-libre-headers behind linux-libre? Dave Love
@ 2017-10-31 13:00 ` Vincent Legoll
  2017-10-31 19:38   ` Efraim Flashner
  0 siblings, 1 reply; 12+ messages in thread
From: Vincent Legoll @ 2017-10-31 13:00 UTC (permalink / raw)
  To: Dave Love; +Cc: guix-devel

Hello,

On Tue, Oct 31, 2017 at 1:35 PM, Dave Love <fx@gnu.org> wrote:
> Why is linux-libre-headers a long way behind linux-libre (currently at
> version 4.4.47, compared with 4.13.10 for linux-libre)?

I suspect this is due to massive rebuilding that would occur when
updating linux-libre-headers

-- 
Vincent Legoll

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: why is linux-libre-headers behind linux-libre?
  2017-10-31 13:00 ` Vincent Legoll
@ 2017-10-31 19:38   ` Efraim Flashner
  2017-11-02 10:16     ` Dave Love
  0 siblings, 1 reply; 12+ messages in thread
From: Efraim Flashner @ 2017-10-31 19:38 UTC (permalink / raw)
  To: Vincent Legoll; +Cc: guix-devel, Dave Love

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

On Tue, Oct 31, 2017 at 02:00:35PM +0100, Vincent Legoll wrote:
> Hello,
> 
> On Tue, Oct 31, 2017 at 1:35 PM, Dave Love <fx@gnu.org> wrote:
> > Why is linux-libre-headers a long way behind linux-libre (currently at
> > version 4.4.47, compared with 4.13.10 for linux-libre)?
> 
> I suspect this is due to massive rebuilding that would occur when
> updating linux-libre-headers
> 

This is typically updated in the core-updates branch, but it hasn't been
updated yet. Based on the LTS versions, we should upgrade it to the 4.9
branch.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: why is linux-libre-headers behind linux-libre?
  2017-10-31 19:38   ` Efraim Flashner
@ 2017-11-02 10:16     ` Dave Love
  2017-11-05 15:51       ` Ludovic Courtès
  0 siblings, 1 reply; 12+ messages in thread
From: Dave Love @ 2017-11-02 10:16 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: guix-devel

Efraim Flashner <efraim@flashner.co.il> writes:

> On Tue, Oct 31, 2017 at 02:00:35PM +0100, Vincent Legoll wrote:
>> Hello,
>> 
>> On Tue, Oct 31, 2017 at 1:35 PM, Dave Love <fx@gnu.org> wrote:
>> > Why is linux-libre-headers a long way behind linux-libre (currently at
>> > version 4.4.47, compared with 4.13.10 for linux-libre)?
>> 
>> I suspect this is due to massive rebuilding that would occur when
>> updating linux-libre-headers
>> 
>
> This is typically updated in the core-updates branch, but it hasn't been
> updated yet. Based on the LTS versions, we should upgrade it to the 4.9
> branch.

Thanks for the explanations.  I checked that 4.9 would support the
Omnipath library, at least.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: why is linux-libre-headers behind linux-libre?
  2017-11-02 10:16     ` Dave Love
@ 2017-11-05 15:51       ` Ludovic Courtès
  2017-11-06  8:44         ` Mark H Weaver
  2017-11-06 15:16         ` Dave Love
  0 siblings, 2 replies; 12+ messages in thread
From: Ludovic Courtès @ 2017-11-05 15:51 UTC (permalink / raw)
  To: Dave Love; +Cc: guix-devel

Hello,

Dave Love <fx@gnu.org> skribis:

> Efraim Flashner <efraim@flashner.co.il> writes:
>
>> On Tue, Oct 31, 2017 at 02:00:35PM +0100, Vincent Legoll wrote:
>>> Hello,
>>> 
>>> On Tue, Oct 31, 2017 at 1:35 PM, Dave Love <fx@gnu.org> wrote:
>>> > Why is linux-libre-headers a long way behind linux-libre (currently at
>>> > version 4.4.47, compared with 4.13.10 for linux-libre)?
>>> 
>>> I suspect this is due to massive rebuilding that would occur when
>>> updating linux-libre-headers

That and also because glibc targets (can target) older kernels, which is
something we rely on.

>> This is typically updated in the core-updates branch, but it hasn't been
>> updated yet. Based on the LTS versions, we should upgrade it to the 4.9
>> branch.
>
> Thanks for the explanations.  I checked that 4.9 would support the
> Omnipath library, at least.

The Omnipath library relies on Linux (not libc) headers, and a specific
version thereof?

I suppose we could also introduce a more recent version of
‘linux-libre-headers’ specifically for this purpose, with the
understanding that the resulting binaries rely on a specific kernel
version.

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: why is linux-libre-headers behind linux-libre?
  2017-11-05 15:51       ` Ludovic Courtès
@ 2017-11-06  8:44         ` Mark H Weaver
  2017-11-06  8:51           ` Pjotr Prins
  2017-11-07  9:56           ` Ludovic Courtès
  2017-11-06 15:16         ` Dave Love
  1 sibling, 2 replies; 12+ messages in thread
From: Mark H Weaver @ 2017-11-06  8:44 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, Dave Love

Hi,

ludo@gnu.org (Ludovic Courtès) writes:

> Dave Love <fx@gnu.org> skribis:
>
>> Efraim Flashner <efraim@flashner.co.il> writes:
>>
>>> On Tue, Oct 31, 2017 at 02:00:35PM +0100, Vincent Legoll wrote:
>>>> Hello,
>>>> 
>>>> On Tue, Oct 31, 2017 at 1:35 PM, Dave Love <fx@gnu.org> wrote:
>>>> > Why is linux-libre-headers a long way behind linux-libre (currently at
>>>> > version 4.4.47, compared with 4.13.10 for linux-libre)?
>>>> 
>>>> I suspect this is due to massive rebuilding that would occur when
>>>> updating linux-libre-headers
>
> That and also because glibc targets (can target) older kernels, which is
> something we rely on.
>
>>> This is typically updated in the core-updates branch, but it hasn't been
>>> updated yet. Based on the LTS versions, we should upgrade it to the 4.9
>>> branch.
>>
>> Thanks for the explanations.  I checked that 4.9 would support the
>> Omnipath library, at least.
>
> The Omnipath library relies on Linux (not libc) headers, and a specific
> version thereof?
>
> I suppose we could also introduce a more recent version of
> ‘linux-libre-headers’ specifically for this purpose, with the
> understanding that the resulting binaries rely on a specific kernel
> version.

Are you sure about this?  My impression was that binaries compiled with
newer linux-libre-headers can be run on older kernels.  If you were
correct, then the binaries we've been building throughout 2017 could be
reliably run only on linux-libre-4.4 or newer.

In fact, we've been successfully running these Guix binaries on
hydra.gnu.org with its old 2.6.x kernel, and on build slaves running
kernels older than 4.4.  Furthermore, I strongly suspect that many of
our users (e.g. Trisquel users) have been running Guix on older kernels
as well, and yet I don't recall seeing any bug reports related to this.

My recommendation would be to update linux-libre-headers to the latest
LTS kernel (currently 4.9.x) in every core-updates cycle.

What do you think?

      Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: why is linux-libre-headers behind linux-libre?
  2017-11-06  8:44         ` Mark H Weaver
@ 2017-11-06  8:51           ` Pjotr Prins
  2017-11-06 15:18             ` Dave Love
  2017-11-07  9:56           ` Ludovic Courtès
  1 sibling, 1 reply; 12+ messages in thread
From: Pjotr Prins @ 2017-11-06  8:51 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel, Dave Love

On Mon, Nov 06, 2017 at 03:44:41AM -0500, Mark H Weaver wrote:
> Are you sure about this?  My impression was that binaries compiled with
> newer linux-libre-headers can be run on older kernels.  If you were
> correct, then the binaries we've been building throughout 2017 could be
> reliably run only on linux-libre-4.4 or newer.
> 
> In fact, we've been successfully running these Guix binaries on
> hydra.gnu.org with its old 2.6.x kernel, and on build slaves running
> kernels older than 4.4.  Furthermore, I strongly suspect that many of
> our users (e.g. Trisquel users) have been running Guix on older kernels
> as well, and yet I don't recall seeing any bug reports related to this.
> 
> My recommendation would be to update linux-libre-headers to the latest
> LTS kernel (currently 4.9.x) in every core-updates cycle.
> 
> What do you think?

The Linux kernel API is remarkably stable. It is indeed the reason we
*can* run GNU Guix on older kernels in the first place - the kernel is
our single dependency. The headers do change, but mostly due to kernel
internals which are not used from glibc etc.

I remember for Nix there was a breaking kernel API change at
some point.  But it is extremely rare. Must have been 10 years ago.

Pj.
-- 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: why is linux-libre-headers behind linux-libre?
  2017-11-05 15:51       ` Ludovic Courtès
  2017-11-06  8:44         ` Mark H Weaver
@ 2017-11-06 15:16         ` Dave Love
  1 sibling, 0 replies; 12+ messages in thread
From: Dave Love @ 2017-11-06 15:16 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

Ludovic Courtès <ludo@gnu.org> writes:

> The Omnipath library relies on Linux (not libc) headers, and a specific
> version thereof?

The current version of the library relies on a recent enough version of
the module/headers as it's fairly new stuff.  It's interacting with the
driver at a fairly low level.  I assume it's similar for the Infiniband
equivalents, but I don't know what the Mellanox ones require.

I don't know the details of what support is required, or if there's
useful out-of-tree support for different versions, but OPA is probably
most commonly used on RHEL 7-ish kernels.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: why is linux-libre-headers behind linux-libre?
  2017-11-06  8:51           ` Pjotr Prins
@ 2017-11-06 15:18             ` Dave Love
  2017-11-06 19:22               ` Mark H Weaver
  0 siblings, 1 reply; 12+ messages in thread
From: Dave Love @ 2017-11-06 15:18 UTC (permalink / raw)
  To: Pjotr Prins; +Cc: guix-devel

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> The Linux kernel API is remarkably stable.

Actually, I don't think that's the case, speaking as someone who's had
to deal with out-of-tree drivers for various reasons.  For instance, the
OrangeFS module typically broke when I tried to rebuild the package on a
new version of Fedora.  Even RHEL can break such things with minor
releases.

> It is indeed the reason we
> *can* run GNU Guix on older kernels in the first place - the kernel is
> our single dependency. The headers do change, but mostly due to kernel
> internals which are not used from glibc etc.

It's a hardware driver library, not anything at the libc level.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: why is linux-libre-headers behind linux-libre?
  2017-11-06 15:18             ` Dave Love
@ 2017-11-06 19:22               ` Mark H Weaver
  2017-11-06 21:00                 ` Pjotr Prins
  0 siblings, 1 reply; 12+ messages in thread
From: Mark H Weaver @ 2017-11-06 19:22 UTC (permalink / raw)
  To: Dave Love; +Cc: guix-devel

Dave Love <fx@gnu.org> writes:

> Pjotr Prins <pjotr.public12@thebird.nl> writes:
>
>> The Linux kernel API is remarkably stable.
>
> Actually, I don't think that's the case, speaking as someone who's had
> to deal with out-of-tree drivers for various reasons.  For instance, the
> OrangeFS module typically broke when I tried to rebuild the package on a
> new version of Fedora.  Even RHEL can break such things with minor
> releases.

When Pjotr said that the Linux API is remarkably stable, I assume he was
talking about the syscall API, i.e. the API available to programs run in
user space.  The Linux kernel project has a strict policy to avoid
changing its API in a way that would break user programs.

The internal API available to kernel modules and drivers is another
matter entirely.  The Linux kernel project reserves the right to change
that internal API freely, and does so regularly.

      Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: why is linux-libre-headers behind linux-libre?
  2017-11-06 19:22               ` Mark H Weaver
@ 2017-11-06 21:00                 ` Pjotr Prins
  0 siblings, 0 replies; 12+ messages in thread
From: Pjotr Prins @ 2017-11-06 21:00 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel, Dave Love

On Mon, Nov 06, 2017 at 02:22:50PM -0500, Mark H Weaver wrote:
> When Pjotr said that the Linux API is remarkably stable, I assume he was
> talking about the syscall API, i.e. the API available to programs run in
> user space.  The Linux kernel project has a strict policy to avoid
> changing its API in a way that would break user programs.
> 
> The internal API available to kernel modules and drivers is another
> matter entirely.  The Linux kernel project reserves the right to change
> that internal API freely, and does so regularly.

Right, and libre-headers should follow that kernel version. In other
words, for the generic case any version of libre-headers will work. I
am not talking about device drivers etc.

Pj.
-- 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: why is linux-libre-headers behind linux-libre?
  2017-11-06  8:44         ` Mark H Weaver
  2017-11-06  8:51           ` Pjotr Prins
@ 2017-11-07  9:56           ` Ludovic Courtès
  1 sibling, 0 replies; 12+ messages in thread
From: Ludovic Courtès @ 2017-11-07  9:56 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel, Dave Love

Mark H Weaver <mhw@netris.org> skribis:

> Hi,
>
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Dave Love <fx@gnu.org> skribis:
>>
>>> Efraim Flashner <efraim@flashner.co.il> writes:
>>>
>>>> On Tue, Oct 31, 2017 at 02:00:35PM +0100, Vincent Legoll wrote:
>>>>> Hello,
>>>>> 
>>>>> On Tue, Oct 31, 2017 at 1:35 PM, Dave Love <fx@gnu.org> wrote:
>>>>> > Why is linux-libre-headers a long way behind linux-libre (currently at
>>>>> > version 4.4.47, compared with 4.13.10 for linux-libre)?
>>>>> 
>>>>> I suspect this is due to massive rebuilding that would occur when
>>>>> updating linux-libre-headers
>>
>> That and also because glibc targets (can target) older kernels, which is
>> something we rely on.
>>
>>>> This is typically updated in the core-updates branch, but it hasn't been
>>>> updated yet. Based on the LTS versions, we should upgrade it to the 4.9
>>>> branch.
>>>
>>> Thanks for the explanations.  I checked that 4.9 would support the
>>> Omnipath library, at least.
>>
>> The Omnipath library relies on Linux (not libc) headers, and a specific
>> version thereof?
>>
>> I suppose we could also introduce a more recent version of
>> ‘linux-libre-headers’ specifically for this purpose, with the
>> understanding that the resulting binaries rely on a specific kernel
>> version.
>
> Are you sure about this?  My impression was that binaries compiled with
> newer linux-libre-headers can be run on older kernels.  If you were
> correct, then the binaries we've been building throughout 2017 could be
> reliably run only on linux-libre-4.4 or newer.

You’re right, but my guess was that if the Omnipath library requires
specific kernel headers, then it may be using functionality (and
syscalls) only implemented by newer kernels.  I haven’t checked though.

Ludo’.

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2017-11-07  9:56 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-31 12:35 why is linux-libre-headers behind linux-libre? Dave Love
2017-10-31 13:00 ` Vincent Legoll
2017-10-31 19:38   ` Efraim Flashner
2017-11-02 10:16     ` Dave Love
2017-11-05 15:51       ` Ludovic Courtès
2017-11-06  8:44         ` Mark H Weaver
2017-11-06  8:51           ` Pjotr Prins
2017-11-06 15:18             ` Dave Love
2017-11-06 19:22               ` Mark H Weaver
2017-11-06 21:00                 ` Pjotr Prins
2017-11-07  9:56           ` Ludovic Courtès
2017-11-06 15:16         ` Dave Love

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.