Next kernel wishlist

[curaga]

That looks very likely, since recent udev has dropped support for the ide drivers. Since I have no reason to put those rules back, libata it is.

[gutmensch]

I'd like to have CONFIG_WATCHDOG for software watchdog

[curaga]

Just noting, that while there is full Xen support in that version, it and 486 support are mutually exclusive, and we're going to choose 486 again.

[Tuftec]

I would like to see an installation option to enable Real Time operation without the need to resort to a special build.

Peter.

[Rich]

Hi Tuftec
Someone contributed a real time kernel. Search the forum for it.

[curaga]

Realtime, xen, and other configurations are not really in our goals, so they will stay as user-contributed ones (assuming someone is interested in doing them, of course).

[genec]

1) Latest stable kernel release if possible (currently 2.6.39.1)

2) All file systems (assuming they are not mutually exclusive of a higher priority feature)

[bmarkus]

1) Latest stable kernel release if possible (currently 2.6.39.1)

2) All file systems (assuming they are not mutually exclusive of a higher priority feature)

1) Latest is a moving target. Be a bit conservative

2) ALL? You are joking

[curaga]

We have always aimed for 1), that is, shipped latest stable at the time.

On FS, like the very bad quality staging drivers, I do not want to ship unstable or even dangerous ones. Besides those, there are some that are very rarely used like minix, which will now be enabled due to demand. Do you need one of those?

[SvOlli]

Here's another suggestion for the next kernel:

instead of using a 64bit kernel with a 32bit userland, how about using a 32bit PAE-kernel with a 32bit userland? About what I read, the main cause for the 64bit kernel is to get >3.x GB of RAM. PAE provides this, it works with Xvesa, and it wouldn't confuse software assuming a 64bit userland when detecting a 64bit kernel.

[curaga]

PAE is a bad hack, see Linus

But beyond the issues of it (not much ram for apps with >16gb, none with >32gb), PAE needs > 486.

[genec]

1) Latest is a moving target. Be a bit conservative

2) ALL? You are joking

We have always aimed for 1), that is, shipped latest stable at the time.

On FS, like the very bad quality staging drivers, I do not want to ship unstable or even dangerous ones. Besides those, there are some that are very rarely used like minix, which will now be enabled due to demand. Do you need one of those?

Let's restate #1: Latest stable kernel within a reasonable time frame.  Yes, it needs pre-release testing to ensure it's good.  I'd just lean towards within the last 2 months.

#2: That's what the filesystems TCE is for.  I'm not so much looking for cramming every single one into base.  Just that with a few TCEs, you can get all current stable file systems (I can understand not including the unstable/dangerous modules unless they're in a TCE with unstable/dangerous in the name).  As far as any targets, I'd be looking at possibly btrfs (as another way to toy with it; I'm still not comfortable with using it on a production system with the lack of a fsck that can fix errors).

[curaga]

Yeah, btrfs will go to the filesystems extension then. It should be stable enough in 3.0.

[nick65go]

I would like TC kernel to be version 3.x, because the expected improvements for video and network drivers.
And maybe in the mean time the bug of power increased consumption will be corrected, see the "Mobile Users Beware: Linux Has Major Power Regression" from
http://www.phoronix.com/scan.php?page=article&item=linux_mobile_uffda&num=1

[danielibarnes]

If it isn't already in your notes, CONFIG_MATH_EMULATION would be nice for the 486 systems which do not include an FPU. They make ideal platforms for Tiny Core.

My concern is that it may break dropbear, but hopefully that problem will not exist or have a better solution.

EDIT: Might update the dropbear extension while we're on the topic and see if that helps. The latest is 0.53.1 (March 2011) vs. 0.52 in repo (Nov 2008).