[RFC] switch default kernel to 7.x based

[Petr Salinger-3]

Hello,

GNU/kFreeBSD currently supports FreeBSD 7.0 and FreeBSD 6.3 kernels,
the primary one is 6.3.

The current upstream upcoming release schedule:

August 2008 FreeBSD 7.1 and 6.4
February 2009 FreeBSD 7.2
June 2009 FreeBSD 8.0

I would like to switch primary kernel to 7.0 (or even to RELENG_7 branch).
It basically means update of freebsd-libs, freebsd-utils and
namely kfreebsd-kernel-headers.

It should allow us to create "lenny snapshot" with kernel from FreeBSD 7.1.

Do you have any trouble with 7.0 kernel ?
Do you have any objections, comments ?

Petr


--
To UNSUBSCRIBE, email to debian-bsd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Petr Salinger-3]

> I would like to switch primary kernel to 7.0 (or even to RELENG_7 branch).
> It basically means update of freebsd-libs, freebsd-utils and namely
> kfreebsd-kernel-headers.
>
> It should allow us to create "lenny snapshot" with kernel from FreeBSD 7.1.
>
> Do you have any trouble with 7.0 kernel ?
> Do you have any objections, comments ?

Switch to 7.x based kernels also have one big advantage, there would be
available real-time signals. It would be possible to runtime detect this
and select rt/non-rt implementation of linuxthreads in glibc dynamically.
With the rt one "ext/threads/shared/t/stress" in perl testsuite passes ...

Petr


--
To UNSUBSCRIBE, email to debian-bsd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

On Tue, Jun 10, 2008 at 03:37:46PM +0200, Petr Salinger wrote:
>> I would like to switch primary kernel to 7.0 (or even to RELENG_7 branch).
>> It basically means update of freebsd-libs, freebsd-utils and namely  
>> kfreebsd-kernel-headers.
>>
>> It should allow us to create "lenny snapshot" with kernel from FreeBSD 7.1.
>>
>> Do you have any trouble with 7.0 kernel ?
>> Do you have any objections, comments ?

It looks like a good idea. I am also wondering if we should provide ZFS
support in our kernels. I have played a bit with it recently and its
clearly a killer feature. Currently it is disabled because we have
enabled ext2 support. Both have incompatible licenses (GPL v2 vs CDDL),
so that would mean disabling ext2 support. Any comments?

> Switch to 7.x based kernels also have one big advantage, there would be  
> available real-time signals. It would be possible to runtime detect this
> and select rt/non-rt implementation of linuxthreads in glibc dynamically.
> With the rt one "ext/threads/shared/t/stress" in perl testsuite passes ...
>

That's clearly something we need. BTW, do you know if the futexes
support in the FreeBSD 7.1 will be correct enough to use an NPTL glibc?

--
  .''`.  Aurelien Jarno            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@...         | aurelien@...
   `-    people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to debian-bsd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Thorsten Glaser-3]

Aurelien Jarno dixit:

>enabled ext2 support. Both have incompatible licenses (GPL v2 vs CDDL),
>so that would mean disabling ext2 support. Any comments?

I wonder why FreeBSD ext2fs code is GPL'd. Other BSDs have a UFS-based
implementation under BSD licence. (It's slow though.)

bye,
//mirabilos
--
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs


--
To UNSUBSCRIBE, email to debian-bsd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Petr Salinger-3]

> It looks like a good idea. I am also wondering if we should provide ZFS
> support in our kernels. I have played a bit with it recently and its
> clearly a killer feature. Currently it is disabled because we have
> enabled ext2 support. Both have incompatible licenses (GPL v2 vs CDDL),
> so that would mean disabling ext2 support. Any comments?

I personally use ext2 to share /home on dual boot machine.
So it would be nice to have a recipe for building kernel with opposite
feature, regardless which one would be the default one.

>> Switch to 7.x based kernels also have one big advantage, there would be
>> available real-time signals. It would be possible to runtime detect this
>> and select rt/non-rt implementation of linuxthreads in glibc dynamically.
>> With the rt one "ext/threads/shared/t/stress" in perl testsuite passes ...

> That's clearly something we need.

Definitely, we need a current perl available, it is a reason
for huge number of uninstallable packages shown by
http://edos.debian.net/edos-debcheck/kfreebsd.php

> BTW, do you know if the futexes support in the FreeBSD 7.1 will be
> correct enough to use an NPTL glibc?

I don't know, we will see.
For "lenny snapshot" we should stay with current linuxthreads add-on.
For "lenny+1", FreeBSD 8.x with *at syscalls should be available.

Petr


--
To UNSUBSCRIBE, email to debian-bsd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

On Wed, Jun 11, 2008 at 10:19:27AM +0000, Thorsten Glaser wrote:
> Aurelien Jarno dixit:
>
> >enabled ext2 support. Both have incompatible licenses (GPL v2 vs CDDL),
> >so that would mean disabling ext2 support. Any comments?
>
> I wonder why FreeBSD ext2fs code is GPL'd. Other BSDs have a UFS-based
> implementation under BSD licence. (It's slow though.)
>

I don't know why, but a grep GPL conf/files is really explict:

conf/files:     warning "kernel contains GPL contaminated csaimg.h header"
conf/files:     warning "kernel contains GPL contaminated emu10k1 headers"
conf/files:     warning "kernel contains GPL contaminated emu10kx headers"
conf/files:     warning "kernel contains GPL contaminated emu10kx headers"
conf/files:     warning "kernel contains GPL contaminated emu10kx headers"
conf/files:     warning "kernel contains GPL contaminated maestro3 headers"
conf/files:     warning "kernel contains GPL contaminated ext2fs filesystem"
conf/files:     warning "kernel contains GPL contaminated ReiserFS filesystem"
conf/files:     warning "kernel contains GPL contaminated xfs filesystem"

sys/gnu/fs/ext2fs/COPYRIGHT.INFO contains more details about ext2fs
support license.

--
  .''`.  Aurelien Jarno            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@...         | aurelien@...
   `-    people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to debian-bsd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

On Wed, Jun 11, 2008 at 02:35:40PM +0200, Petr Salinger wrote:

>> It looks like a good idea. I am also wondering if we should provide ZFS
>> support in our kernels. I have played a bit with it recently and its
>> clearly a killer feature. Currently it is disabled because we have
>> enabled ext2 support. Both have incompatible licenses (GPL v2 vs CDDL),
>> so that would mean disabling ext2 support. Any comments?
>
> I personally use ext2 to share /home on dual boot machine.
> So it would be nice to have a recipe for building kernel with opposite  
> feature, regardless which one would be the default one.
>

We currently have a high number of flavors, maybe we can reduce the
number of flavours and provide a ZFS one with all the GPL code disabled.

For example, I am not sure there is a big speed difference between the
em64t and the amd64 version of the FreeBSD kernel. We can probably ship
only one version (as it is already done for the Linux kernel). Also modern
computers are mostly having dual- (or more) core CPU, we can maybe only
provide an SMP version for 686 and amd64 kernels, I don't think it will
visibly impact the speed on non-SMP machines.

--
  .''`.  Aurelien Jarno            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@...         | aurelien@...
   `-    people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to debian-bsd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Joshua Cummings-2]

On Thu, 2008-06-12 at 00:56 +0200, Aurelien Jarno wrote:

> We currently have a high number of flavors, maybe we can reduce the
> number of flavours and provide a ZFS one with all the GPL code disabled.
>
> For example, I am not sure there is a big speed difference between the
> em64t and the amd64 version of the FreeBSD kernel. We can probably ship
> only one version (as it is already done for the Linux kernel). Also modern
> computers are mostly having dual- (or more) core CPU, we can maybe only
> provide an SMP version for 686 and amd64 kernels, I don't think it will
> visibly impact the speed on non-SMP machines.
>

Sounds like a fantastic idea.

What's involved in making ZFS happen? Do we simply need to indentify the
GPLed drivers/components in the kernel and disable them accordingly at
build time? Obviously we need the kernel and userland parts included in
our source first...

Features like ZFS are what we really need to get people interested. If
we could provide a ZFS experience as stable as a standard FreeBSD 7
system can achieve, we'd have a unique feature available that I'm sure
would attract quite a few new users.

Think about it. We'd have something I'm sure a *lot* of users would
love; a Debian system with ZFS. Coupled with things like complete PF
support, DTrace (eventually), jails (I need to get back to work on that)
and more, we can show off the amazing features that *should* be the
focal point of GNU/kFreeBSD.

But, of course, my ranting won't get anything done ;)


--
Joshua




--
To UNSUBSCRIBE, email to debian-bsd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Thorsten Glaser-3]

Joshua Cummings dixit:

>Do we simply need to indentify the
>GPLed drivers/components in the kernel and disable them accordingly at

Just a question… I wonder if it’s possible to build all GPL’d _and_ CDDL’d
components as modules. If so, no extra kernel hassle required, just make
sure that they can’t be loaded at the same time if you want to be extra
pedantic (end users may, they just mustn’t distribute a core dump of the
kernel with both type modules loaded ;).

//mirabilos
--
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs


--
To UNSUBSCRIBE, email to debian-bsd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[NN_il_Confusionario]

On Mon, Jun 16, 2008 at 05:41:17PM +1000, Joshua Cummings wrote:
> jails

espacially interesting if Linux kernel in lenny will be packaged without
a vserver (or openvz) precompiled binary

--
Chi usa software non libero avvelena anche te. Digli di smettere.
Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale.
Informatica=bomba: intelligente solo per gli stupidi che ci credono.


--
To UNSUBSCRIBE, email to debian-bsd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Petr Salinger-3]

> We currently have a high number of flavors, maybe we can reduce the
> number of flavours and provide a ZFS one with all the GPL code disabled.
>
> For example, I am not sure there is a big speed difference between the
> em64t and the amd64 version of the FreeBSD kernel. We can probably ship
> only one version (as it is already done for the Linux kernel). Also modern
> computers are mostly having dual- (or more) core CPU, we can maybe only
> provide an SMP version for 686 and amd64 kernels, I don't think it will
> visibly impact the speed on non-SMP machines.

The current popcount results are bellow.

IMHO, for kfreebsd-amd64 should suffice to produce only one generic with
smp enabled. The kfreebsd-i386 should have i486, i686 and i686-smp.

While modern CPUs have either dual core or hyper-threading,
there are many variant of i686 (pentiumpro, pentiumII, pentiumIII, early
pentiumIV, k6, k7, ...) without smp available. In fact, there is no smp
variant on kfreebsd-i386 reported so far.

Petr


kfreebsd-image-6-686               5     0     0     0     5 (Not in sid)
kfreebsd-image-6-amd64-generic     2     0     0     0     2 (Not in sid)
kfreebsd-image-6-amd64-k8          1     0     0     0     1 (Not in sid)
kfreebsd-image-6-em64t-p4          1     0     0     0     1 (Not in sid)
kfreebsd-image-6.1-1-686           1     0     1     0     0 (Not in sid)
kfreebsd-image-6.2-1-486           1     0     1     0     0 (Not in sid)
kfreebsd-image-6.2-1-686           1     0     1     0     0 (Not in sid)
kfreebsd-image-6.2-1-amd64-generic     1     0     1     0     0 (Not in sid)
kfreebsd-image-6.3-1-686           5     0     5     0     0 (Not in sid)
kfreebsd-image-6.3-1-amd64-generic     2     1     1     0     0 (Not in sid)
kfreebsd-image-6.3-1-amd64-k8      1     0     1     0     0 (Not in sid)
kfreebsd-image-6.3-1-em64t-p4      1     0     1     0     0 (Not in sid)
kfreebsd-image-7-686               2     0     0     0     2 (Not in sid)
kfreebsd-image-7-em64t-p4-smp      1     0     0     0     1 (Not in sid)
kfreebsd-image-7.0-1-686           3     0     2     1     0 (Not in sid)
kfreebsd-image-7.0-1-em64t-p4-smp     1     0     0     1     0 (Not in sid)
kfreebsd-image-7.1-1-em64t-p4-smp     1     1     0     0     0 (Not in sid)


--
To UNSUBSCRIBE, email to debian-bsd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...