Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: curaga on May 28, 2011, 01:37:04 AM
-
Post here if you would like to see changes in the next config. If you have already posted during the 3.x cycle and I have noticed it (posted saying so ;)), no need to repeat here.
-
It would be good to set this one for avahi zeroconf support:
# CONFIG_IP_MULTICAST is not set
-
@SamK: Why not put that in a script? I don't see how there's a general need, beep is not a standard cli command really.
@Juanito: that one was already in the other list
-
LXC support.
A lightweight system to launch linux containers would be good.
-
Beep discussion split.
-
My #1 desire: Successful resume from suspend.
-
One of the key benefits of new Fedora 15 is its advanced power managment, see:
http://fedoraproject.org/wiki/Features/PowerManagementF15
We had a discusson a while ago regarding PowerTOP:
http://forum.tinycorelinux.net/index.php?topic=2984.0
I do not know, how current Kernel options are related to power management and PowerTOP. It is an important point.
-
The timer stats will be available in a separate debug kernel, but not the main one, for reasons lined in that topic.
-
# CONFIG_MINIX_FS is not set
This option will enlarge your kernel by about 28 KB.
.....
To compile this file system support as a module, choose M here: the module will be called minix.
Lack of minixfs support is the only reason for me to still use any other Linux system at times, in order to access data I had prior to switching to TC on floppies and loop files on vfat file systems.
-
I can not secure erase my SSD, as in https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
because I want to restore max speed on my SDD, by issuing a SATA secure erase command (busybox hdparam has not this command). And I find that even with the hdparm 9.36 I must recompile the kernel as a parameter such CONFIG_TASK_IO_CTRL is not activated...
-
not a config request but what version of kernel are we moving to?
or are we recomplile existing?
-
Ack on lxc and minixfs. Do you need minix partitioning as well, or is the fs enough?
@nick65go, that was mentioned earlier, will include that as well.
@aus9: looking at 3.0.
-
Ack on lxc and minixfs. Do you need minix partitioning as well, or is the fs enough?
While searching config options for "minix" I saw that option about subpartitions but couldn't really understand what exactly it would do.
Perhaps though, once minix would be included, it should be considered if the option would be of any need or benefit for anyone in general - in proportion to its "cost".
Also it might be considered to have a separate extension for minixfs if it would be deemed enough of an advantage to keep filesystems*.tcz smaller, depending on final difference in size it would account for.
-
AFAIK it's a different partition setup compared to MBR or GPT, that is, if you have a hard disk made with minix fdisk (or whatever app they use). Floppies and direct loops shouldn't need it.
-
I would like to see a kernel which identifies all drives as sda, sdb, sdc, sdd, and not hda, hdb, hdc.
I have been working on an installer.
http://forum.tinycorelinux.net/index.php?topic=9827.0
Having all drives starting with an s, would make is simpler.
-
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.
-
I'd like to have CONFIG_WATCHDOG for software watchdog ;)
-
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.
-
I would like to see an installation option to enable Real Time operation without the need to resort to a special build.
Peter.
-
Hi Tuftec
Someone contributed a real time kernel. Search the forum for it.
-
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).
-
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 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
-
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?
-
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.
-
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.
-
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).
-
Yeah, btrfs will go to the filesystems extension then. It should be stable enough in 3.0.
-
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
-
If it isn't already in your notes, CONFIG_MATH_EMULATION (http://cateee.net/lkddb/web-lkddb/MATH_EMULATION.html) 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 (http://forum.tinycorelinux.net/index.php?topic=8759.msg47476#msg47476), 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).
-
It's +80kb not needed by 99%, plus it hardly works nowadays. It gets no testing and no fixes..
-
It's +80kb not needed by 99%, plus it hardly works nowadays. It gets no testing and no fixes..
It works for me (http://forum.tinycorelinux.net/index.php?topic=9740), although I've not tested it extensively. Since the size and user base can't justify inclusion, I'll look into creating a custom kernel (http://forum.tinycorelinux.net/index.php?topic=8923.0). That'll work just as well.
-
That'd be good. Available for those who need it.
-
What about moving from the old, deprecated ATA drivers to the new Serial/Parallel ATA drivers where possible?
-
Please read the thread, especially posts 14 and 15 ;)
-
Please read the thread, especially posts 14 and 15 ;)
Whoops! Missed that one. ;D
-
powertop suggests enabling
-CONFIG_HPET_TIMER and
-CONFIG_NO_HZ for longer sleep times
-CONFIG_INOTIFY allows programs to wait for changes in files and directories
-CONFIG_USB_SUSPEND for disabling UHCI USB when not in use
-CONFIG_CPU_FREQ_GOV_ONDEMAND better speed governor
edit: statistics go into debug kernel
-
$ egrep 'HPET_TIMER|NO_HZ|INOTIFY|USB_SUSP|ONDEMAND' config-2.6.33.3-tinycore
CONFIG_NO_HZ=y
CONFIG_HPET_TIMER=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_USB_SUSPEND=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
Powertop is not the smartest app it seems ;) I recall it suggested I enable usb and sound suspend, when I already had them enabled, just with a different timeout than the one powertop expected.
-
Strange. IIRC there were power usage improvements when I let powertop enable USB suspending.
I'll check again
-
How about nbd module?
-
OK, will add nbd.
-
Not so much a particular wish (at this stage), but more of a point I'd suggest to put on a dedicated list of test scenarios: During the 3.x phase we've seen repeatedly DMA problems with CD-ROM devices (mostly on older systems). The most recent one (http://forum.tinycorelinux.net/index.php?topic=10862) has triggered me to write this post.
I am one who still owns such a system, but I pretty much only boot it with TC to investigate for example possible hardware issues. I've noticed a kind of regression in the "out of the box" behaviour in this area between TC 2.x and 3.x: there are warnings etc. when booting 2.6.11, but it will eventually work, whilst 3.x gets "fatally stuck" on this problem (if not using the 'ide-core.nodma' boot code). Combine this with reports that others (like Puppy) are not showing those problems one likes to think that we've got an "unfortunate" kernel config in 3.x.
I don't think it's serious enough to try to track it down on the current kernel, but I think it would be worth comparing kernel configs of others (like Puppy) and attempting to test things when we move to a new kernel.
-
I don't have any hw that fails DMA. But with the transition to libata, the issue is likely to go away.
-
I'm liking the new build so far :) Also, my new netbook shows the floppy issue, so I can confirm that delay gone.
Qemu before-after:
(http://preview.shareapic.net/preview7/025248689.png) (http://www.shareapic.net/View-25248689-TC.html) (http://preview.shareapic.net/preview7/025248690.png) (http://www.shareapic.net/View-25248690-TC.html)
AMD netbook before-after:
(http://preview.shareapic.net/preview7/025248691.png) (http://www.shareapic.net/View-25248691-TC.html) (http://preview.shareapic.net/preview7/025248692.png) (http://www.shareapic.net/View-25248692-TC.html)
-
So now the whole base will be booted faster than some of our extensions need to get mounted, hah :D
-
It already did that ;) of course hw-dependant, the floppy delay in particular was nasty on affected hw.
There will also be other improvements; busybox 1.19 in particular will speed up boot nicely too, when it's released.
-
Sure, looking forward to it.
My only fears are about Xorg, getting it to work was always a hassle with new kernels.
-
I can report that much is working for me.
Xvesa with 915resolution 1024x600, flwm, atheros WPA2 wifi network
I am posting this from opera-next + flash. flit battery monitor is working.
Only caveat on this machine is sound.
Just note the kernel + base modules are larger.
Appears so far that we will grow to 12MB
But for a very early rough cut of TinyCore 4.0 it is impressive.
-
Xorg 7.5 is working for me so far, I just had to update xf86-video-ati to support the chip in the netbook.
-
Would there be any advantages in using XZ compression for extensions in Tinycore version 4.x?
-
XZ would be space saving but slower in performance (I don't know right now as of by what margin), so I am not sure we are at the point of wanting to sacrifice performance for smaller extension size.
-
No XZ included in the current build, for those reasons. OTOH LZO is there, since it comes "for free" (it's required by zram and zcache).
-
xz BusyBox applet is part of the base. This can decompress archives.
-
I'd rather like speed improvements of mount than smaller tczs.
-
xz BusyBox applet is part of the base. This can decompress archives.
I was talking about kernel code; the kernel can't use the busybox applet :)
-
xz BusyBox applet is part of the base. This can decompress archives.
I was talking about kernel code; the kernel can't use the busybox applet :)
I see. I made som test a while ago on my daily backups. xz could result smaller files than gzip bzip significantly slower using much more resources. Tuning it for same time were no benefits so decided not to use xz. It is about compression. Decompression can be better.
-
No XZ included in the current build, for those reasons. OTOH LZO is there, since it comes "for free" (it's required by zram and zcache).
Including xz or lzma support in kernel's squashfs to me would present only advantages:
tce-load would transparently handle both zip and xz tcz modules without no added work needed.
You would get more possibilities for free, without having anything to lose.
Official repository modules would still be zip, but custom modules could be packaged in xz if a user needs more compression.
What is the problem, seriously?
Or am I missing something? Maybe kernel with xz support has big size increase/performance loss?
-
It would increase the kernel size, for a small minority of users. It's a tradeoff that's not worth it right now, in my opinion.
Note that you can get better compression by using bigger gzip block sizes too; the official repo is limited to 4kb only because of ram use.
-
It would increase the kernel size, for a small minority of users. It's a tradeoff that's not worth it right now, in my opinion.
Note that you can get better compression by using bigger gzip block sizes too; the official repo is limited to 4kb only because of ram use.
Though wouldn't it at the same time decrease the size of the tc/mc image by using xz over gz?
-
Yes, at the cost of much longer boot & higher ram requirement.
-
It would increase the kernel size, for a small minority of users. It's a tradeoff that's not worth it right now, in my opinion.
I see, that makes sense. Thanks for the explanation.
-
it would be very nice if all good tricks from powertop 1.13 would be implemented, (i know was talked before)
also two killer setting i use for greatest power savings:
echo low > /sys/class/drm/card0/device/power_profile for latest radeon(ATI) Xorg driver => finally makes my fan to be quiet, a solution long waiting from 2009 when catalyst drv was not used by me.
grub line, kernel parameter pcie_aspm=force was found as the solution to kernel bug of the power regression (on phoronix site),
Edit: used 64 bits of kernel 3.0.3, Xorg 1.10.4 RC1, radeon 6.14.2 in archlinux
with acpi-cpufreq and ondemand kernel modules. powertop shows the improvements; sometimes as low as 10-15 wake ups per seconds.