On http://elinux.org/Linux_Tiny I see that there's no public
release of Linux-Tiny-Patches since Kernel 2.6.23. Is this
right?


I have a bunch of local tiny-patches for 2.6.32:

tiny-scsi-ioctl.patch
Get rid of unconditional compiled scsi_ioctl.o
add/remove: 0/8 grow/shrink: 0/0 up/down: 0/-3596 (-3596)
tiny-fb.patch
Shrink modedb, get rid of fb-related sysfs, removes misc
other functions that I don't need in an environment where
the framebuffer never changes it's mode
add/remove: 0/29 grow/shrink: 0/6 up/down: 0/-4876 (-4876)
tiny-config-net-small.patch
Adds CONFIG_NET_SMALL
add/remove: 0/0 grow/shrink: 7/4 up/down: 28/-2756 (-2728)
tiny-namei-inlines.patch
Uninline various namei.c functions
add/remove: 2/0 grow/shrink: 0/8 up/down: 584/-2024 (-1440)
tiny-crc.patch
Calculate CRC32 without tables
add/remove: 2/0 grow/shrink: 0/10 up/down: 584/-2356 (-1772)
tiny-ldiscs.patch
Configurable no. of TTY line disciplines (I use 4 instead
of 16)
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-64 (-64)
tiny-max-user-rt-prio.patch
Configurable no. of realtime priority levels (I use 5
instead of 100)
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-840 (-840)

... but would be grateful for a source of more stuff like this !

Best regards,
Holger

--
http://www.holgerschurig.de

Hi Holger,

On 01/12/2010 10:19 AM, Holger Schurig wrote:

On http://elinux.org/Linux_Tiny I see that there's no public
release of Linux-Tiny-Patches since Kernel 2.6.23. Is this
right?

That's right. We stopped releasing patches after realizing that we were
spending more time updating old patches than getting them merged.

Thanks to this, we managed to merge some of these patches (see
http://free-electrons.com/community/contributions/kernel-contributions/),
but it's true that some patches / ideas haven't been merged yet.

I have a bunch of local tiny-patches for 2.6.32:

tiny-scsi-ioctl.patch
Get rid of unconditional compiled scsi_ioctl.o
add/remove: 0/8 grow/shrink: 0/0 up/down: 0/-3596 (-3596)
tiny-fb.patch
Shrink modedb, get rid of fb-related sysfs, removes misc
other functions that I don't need in an environment where
the framebuffer never changes it's mode
add/remove: 0/29 grow/shrink: 0/6 up/down: 0/-4876 (-4876)
tiny-config-net-small.patch
Adds CONFIG_NET_SMALL
add/remove: 0/0 grow/shrink: 7/4 up/down: 28/-2756 (-2728)
tiny-namei-inlines.patch
Uninline various namei.c functions
add/remove: 2/0 grow/shrink: 0/8 up/down: 584/-2024 (-1440)
tiny-crc.patch
Calculate CRC32 without tables
add/remove: 2/0 grow/shrink: 0/10 up/down: 584/-2356 (-1772)
tiny-ldiscs.patch
Configurable no. of TTY line disciplines (I use 4 instead
of 16)
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-64 (-64)
tiny-max-user-rt-prio.patch
Configurable no. of realtime priority levels (I use 5
instead of 100)
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-840 (-840)

... but would be grateful for a source of more stuff like this !

Would you have time to submit these patches to the LKML? This would be
very useful, and if you CC the linux-embedded mailing list, you should
get support from our 3 embedded maintainers.

Otherwise, if you don't have enough time, please send them to me and I
will upload them on the Linux-Tiny page, and will take care of them as
soon as I have time.

Thanks,

Michael.

--
Michael Opdenacker, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+ 33 621 604 642

On Tuesday 12 January 2010 08:13:03 Michael Opdenacker wrote:

Hi Holger,

On 01/12/2010 10:19 AM, Holger Schurig wrote:

On http://elinux.org/Linux_Tiny I see that there's no public
release of Linux-Tiny-Patches since Kernel 2.6.23. Is this
right?

That's right. We stopped releasing patches after realizing that we were
spending more time updating old patches than getting them merged.

Thanks to this, we managed to merge some of these patches (see
http://free-electrons.com/community/contributions/kernel-contributions/),
but it's true that some patches / ideas haven't been merged yet.

Back when Matt Mackall gave up on the first linux-tiny tree, I realized that
the fundamental problem with linux-tiny is it's going about it all wrong.

Think about embedded development in userspace. People who put together their
first headless box tend to start by grabbing a desktop distro and uninstalling
stuff they don't need. But after a while you have to approach the problem from
the other end, starting with an empty root filesystem and adding just what you
need. Whether you do so with cp and ldd, or whether you build stuff from
source, is a side issue. The point is instead of starting with buckets of
stuff and chopping it down, you start from zero and build _up_.

The linux kernel's "allnoconfig" produces a kernel that's over a megabyte. The
linux-tiny patches are finding ways to disable more of that stuff, but it's
still the "start with a distro and remove stuff" approach. That's a Red
Queen's Race, you're running at full speed to avoid _losing_ ground.

What's needed is a "hello world" Linux kernel, that makes the smallest
bootable binary you can actually see do something. Start with Linux, grab
whatever setup.S code you need to get the processor ready to run C code, plus
the early_printk stuff to print "hello world" out to a simple console device,
and then halt the CPU. Make that work on each target.

Then once you've got your zero state, then add the compression wrapper. Then
work your way through init/main and start adding stuff a bit at a time, with
stub versions of everything (possibly copied from linux 0.95 or thereabouts).
The world's crappiest in-kernel memory allocator. A mindless round-robin
scheduler. Sad interrupt handling that just _does_ it without even bottom
halves. A single mount point vfs. The posix system calls, and so on. Figure
out what they ARE. Look at linux 0.0.1 to see the minimum you can get away
with. Disentangle each of these chunks from each other and try to figure out
if there's any possible use you could put the system to without this one.

Note that kernels are potentially actually useful even in the absence of
userspace. Back in the 2.2 days there was as trick where you'd set up your
ipchains so everything was routing and masquerading how you wanted, and then
intentionally have init exit (panicing the kernel). The machine would still
handle interrupts and thus still route packets, but there was no userspace.
(Try running your rootkit on _that_ box.) I don't think it still works on
modern systems, but you see my point.

Imagine a kernel that does nothing but parse a device tree, probe a little bit
of described hardware and early_printk some information about it, and then
halt. That's a tool on the order of memtest86 that's conceivably useful as an
early smoketest, and the fact it _can't_ currently be built from the Linux
source is _sad_.

The thing is, making such a "hello world" kernel is a HUGE amount of work, and
then breaking out other pieces of code from Linux so they're independent of
each other and can be added one at a time would be an enormous undertaking.
Right now it's all one big huge tangled mess. But working from the top down
does not scale, you have to take the bottom up approach at some point, or else
accept that the kernel will continue to bloat and that linux-tiny and friends
are at best a holding action.

(I blathered about this a bit in that OLS compiler BOF Michael recorded in
2008. Haven't found time to mess with it much since. Not really my area, I'm
afraid.)

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds

Rob Landley wrote:
<snip>

The thing is, making such a "hello world" kernel is a HUGE amount of work, and then breaking out other pieces of code from Linux so they're independent of each other and can be added one at a time would be an enormous undertaking. Right now it's all one big huge tangled mess. But working from the top down does not scale, you have to take the bottom up approach at some point, or else accept that the kernel will continue to bloat and that linux-tiny and friends are at best a holding action.

Such an effort would have many, many applications, especially as devices that can run linux slowly move into the $10 or so bracket.

It would be a very useful project, but as you say is huge.

On Saturday 16 January 2010 09:10:04 Ian Stirling wrote:

Rob Landley wrote:
<snip>

The thing is, making such a "hello world" kernel is a HUGE amount of
work, and then breaking out other pieces of code from Linux so they're
independent of each other and can be added one at a time would be an
enormous undertaking. Right now it's all one big huge tangled mess. But
working from the top down does not scale, you have to take the bottom up
approach at some point, or else accept that the kernel will continue to
bloat and that linux-tiny and friends are at best a holding action.

Such an effort would have many, many applications, especially as devices
that can run linux slowly move into the $10 or so bracket.

It would be a very useful project, but as you say is huge.

I had a second round of projects to propose to CELF after I thought about it a
bit. (I have such a long todo list I don't even remember things like this
unless I dig a bit.)

Another one was getting uClibc on a regular release schedule again, and uClibc
NPTL ported to all supported hardware targets in an actual _release_ version.
Or perhaps getting android's bionic (bsd licensed libc) and toolbox (their
bsd-licensed busybox clone) properly documented and mirrored (with an actual
mailing list instead of a google group) so people interested in poking at them
don't need to agree to a deeply stupid (very much not open source) SDK license
before playing with 'em.

But somebody said the deadline had gone past. *shrug* Maybe next year.

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds

On Sat, Jan 16, 2010 at 12:12, Rob Landley <rob@...> wrote:

On Saturday 16 January 2010 11:28:13 Bill Traynor wrote:

On Sat, Jan 16, 2010 at 12:12, Rob Landley <rob@...> wrote:

But somebody said the deadline had gone past. *shrug* Maybe next year.

Rob, you should submit them anyway so they can be added to the
elinux.orgwiki. That way there's a record of useful projects.

There's a shortage of todo items?

Somebody needs to make a kernel filesystem that can read-only loopback mount a
zip file. (Yay squashfs, but we've had a compressed archive format you can
easily get individual files out of for 20 years now, and the Linux kernel never
learned to loopback mount it. Sad.)

Somebody needs to genericize kconfig, as discussed years ago at
http://lkml.indiana.edu/hypermail/linux/kernel/0707.1/2803.html
so the code that's currently copied by uClibc and busybox and buildroot and
such can be _shared_ rather than just copied from the Linux kernel. (But I
can't even get the Kernel guys to take my perl removal patches.)

Somebody needs to help the http://www.kernelpodcast.org/ guy catch up
(possibly reading some of his old entries that haven't got MP3's out loud and
sending him the recordings, and maybe trying to summarize the gaps, ala
http://www.kernelpodcast.org/2010/01/14/ ). Speaking of which, I need to dig
up http://landley.net/qemu and start that up again.

Maybe I should even dredge up http://kernel.org/doc and do something with
that. It would be nice if the OLS people inherited http://kernel.org/doc/ols
and my script to generate http://kernel.org/doc/htmldocs/ broke when they
introduced subdirectories. (Easy to fix, I just haven't yet. And I need to
get the cron job set back up to update it regularly again.)

I need to dig up my old project to build a genext2fs program that works like
an archiver (I.E. so you can pipe its output directly into gzip or through
ssh, without it having to mmap a big file and work on that). I should probably
also do a btrfs one while I'm at it.

Somebody somewhere needs to teach qemu to emulate a 3D chip. (Doesn't matter
which one, something simple you can translate to opengl. Software render it
in 2D on the host for the first pass if need be, just put _support_ in there.)
And while we're fiddling with qemu, why does the -kernel mode _not_ parse ELF
vmlinux files on every single target? The code's generic, it's just not
_enabled_...

I need to properly write up my rant about why autoconf and make need to die
and what to replace them with, random examples of material at:
http://lkml.indiana.edu/hypermail/linux/kernel/0901.2/00434.html
http://lkml.indiana.edu/hypermail/linux/kernel/0901.2/00720.html

I need to dig up my miniconfig stuff and make kconfig do it automatically in C:
http://lwn.net/Articles/161086/
http://landley.net/hg/firmware/file/tip/sources/toys/miniconfig.sh

I need to finally write the book on the history of open source I've been
collecting research for (http://landley.net/history/mirror) for ages. And no,
http://landley.net/notes-2009.html#11-05-2009 and
http://landley.net/notes-2009.html#23-05-2009 (and for that matter,
http://landley.net/code/firmware/history.html) don't count. I also need to
write up how to actually run a convention. (Again,
http://landley.livejournal.com/41393.html doesn't count.) And I need to do a
PROPER write-up on the old Three Waves stuff I wrote articles on ten years ago
(Cutting and pasting from the last time I mentioned it, <a
href=http://www.fool.com/news/foth/2000/foth000731.htm>one</a>,
<a href=http://www.fool.com/news/foth/2000/foth000913.htm>two</a>,
<a href=http://www.fool.com/news/foth/2000/foth000905.htm>three</a>,
<a href=http://www.fool.com/news/foth/2000/foth000918.htm>four</a>,
<a href=http://www.fool.com/news/foth/2000/foth000925.htm>five</a>,
<a
href=http://www.fool.com/portfolios/rulemaker/2000/rulemaker000928.htm>six</a>,
<a href=http://www.fool.com/news/foth/2000/foth001002.htm>seven</a>,
and some <a
href=http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/839/748>third
party reaction</a>). That was a DECADE ago, I hadn't even come up with decent
names for the stages yet (Cringely's names are ok, but Hobbyist, Employee, and
Bureaucrat are much more descriptive)...

(And I need to write a proper book on embedded development, explaining all the
stuff I've written scattered around http://busybox.net/FAQ.html#tips and
http://landley.net/code/toybox/design.html and so on. And to do so I need to
LEARN so much stuff, such has how to set up JTAGS properly which is an AMAZING
pain.)

Today I'm halfway through a write-up on what's actually WRONG with the Android
project (from a 10,000 foot view, not actually looking at the code yet), and
my long-term hobby project (stalled while I find a real job) is getting my
Firmware Linux project working on every target QEMU supports (producing a
prebuilt binary cross compiler, native compiler, root filesystem tarball, and a
bootable system image containing a native development environment, plus
prebuilt static binaries for dropbear and strace, ala
http://impactlinux.com/fwl/downloads/binaries/ ). I also need to get it
building nightly snapshots using the -git versions of uClibc, busybox, and the
Linux kernel, and automatically doing a "git bisect" for any build break or
test break to determine what commit broke it and automatically emailing a
build log to that person.

I'm sorry, I'm confused by the CONCEPT of having a shortage of TODO items.
This is just the top of my head _Linux_ stuff, and doesn't include purely-me
items like learning LUA. I want to get a mac and learn THAT stuff. I want to
get my master's degree so I can become a full-time college professor when I'm
ready to retire from programming. I want to write multiple books. I want to
start a third convention so I have an excuse to wave the Cartoon Guide to
Federal Spectrum Policy at people
(http://www.newamerica.net/files/archive/Pub_File_1555_1.pdf). I want to learn
to draw so I can start a webcomic. I have enormous stacks of books to read.
I need to watch the rest of Mythbusters, catch up on the new Dr. Who, and play
Dragon Age. I want to garden and cook and bike and swim. I want to get rich
and start the world's largest nudist resort. I want to dig up the recording
of the time I got Neil Gaiman to say "By Grabthar's hammer, you shall be
avenged" into a microphone (after his reading of Crazy Hair at Penguicon 2)
and also get Ralph Nader to say "Luke, I am your Father" into another
microphone. I need to completely redo my website (and make a "random cool
stuff" page listing http://sidhefaer.livejournal.com/87839.html and
http://theglen.livejournal.com/16735.html and so on...)

Theres... a shortage of stuff to do somewhere?

Really?

How does that work?

Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds