How small is your dev

What features/apps/bugfixes needed in a future Puppy
Post Reply
Message
Author
User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

How small is your dev

#1 Post by mikeb »

One of the greatest joys of a distro and kernel builder is keeping up with hardware. 20 devices per minute are not fun.

Since I tend to build drivers rather than changing kernels it occured to me perhaps it might make more sense to supply drivers on demand just for the hardware in question as a source tarball and build it in situ.

Madness....

Maybe but for basic gcc toolset and kernel headers that comes to something in the 15-25mb region.... which i believe is similar to the current stock of wifi drivers plus firmware especially if we are dealing with STA types.

Its also takes around a minute to build a kernel driver...faster than even a decent windows installer.... and the process is usually simple and hands off.

As for the distro builder he just has a stock of driver sources (still having a core stock for such as drives , soundcore and so on....in other words the more generic stuff needed to get a running system) with no need for a build per kernel. If an update is needed the user already has the tools... could be merged in to the main system or a small sfs zdrv style.
For the user life is a bit slimmer yet as up to date as driver makers allow.

making any more sense?

mike

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#2 Post by amigo »

You have to have the (mostly) full kernel sources to compile modules for it. And the sources need to have been configured and partially built. At any rate, I'm quite sure my 'dev', or whatever you kids call it these days..., is much bigger than yours.

Oh, sorry... Dipping into my sources I find my build script for the kernel sources package, which does this:

Code: Select all

cp /path/to/regular/kernel/config .config
make oldconfig
make
make clean
This leaves your sources properly configured, and with the Kconfig binaries intact for compiling in-tree or out-of-tree modules from source.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#3 Post by mikeb »

Well such thoughts came from my slax dev package just has kernel headers which weigh in at 6.5MB compressed but I have built alsa, wifi and video4linux using them just fine.

In fact i knocked up a driver module years ago for a 2.6.27 oddball kernel build that had no dev package using bits from the source tree, a hacked config based on the one from the running kernel and gcc... it worked in the end and was small too...ok perhaps i went about it the hard way but the dev went into hiding as they do so needs must. Actually I had to do similar things as a limited company when my accountant disappeared :D

Only time I have needed the full tree was for making a patched drm to suit a bleeding awful via graphics driver.

mike

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#4 Post by amigo »

Giving sway to the GPL suggests that I provide the complete kernel sources along with the configuration file used and scripts used to produce the package -in this case the sources themselves are a package and must be since they contain binaries.

I never waste time trying to make things smaller -just for smallness sake. Since I maintain over 1,00 packages, I can't spend time on each package for such frivolous goals. My take is that, anyone who wants a certain software should and will be happy to 'spend' the needed space -however much or little that may be. And certainly, anyone who's doing a bit of development should not be concerned at all about size -or they are gonna be making lots of work for themselves.

In the early days of src2pkg -before it had routines which could sometimes find an existing text description of the software, I found that I spent more time composing the description file than in all the other packaging steps. Hence, the routine which tries to automate that for me. The point is this: If you maintain lots of packages, then even a couple of minutes of extra work for each package translates quickly into 'real' time. This also goes for any manual fudging or tweaking of packages -it simply is not maintainable. Hence, all my packages are built using build scripts which can, and do, run non-interactively. This also makes upgrading to later versions much easier -usually a simple bump to the version/release numbers and it builds again. Of course sometimes the old script contained lines to fix or patch something which may get later fixed upstream -a couple of commented lines usually fixes that.

Anyway, I most certainly would not waste a moment trying to sort through 40,000+ kernel sources files to decide which is *really* needed for some purpose. You mention kernel-headers -are you sure you are not talking about the kernel-headers used for compiling glibc? If you are using slackware-based, then the package kernel-headers is exactly that -they are really the glibc-headers which are needed for compiling *nearly* anything -but are not the full set needed for compiling kernel components.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#5 Post by mikeb »

Hmmm well if you happen to grab slax 6 or 7 part of the iso is a 30-35mb dev file that can be used to build user space binaries and kernel modules... so we are talking definately more than glibc. I cannot see it being a major job creating it since its included with any slax version....perhaps they have a script to do the job. Maybe 'headers ' is the wrong term in this instance but it appears to work in a similar fashion.

I have a 18MB module built for my slax kernel pup thats just for module building made by removing the userspace side of the original....it has gcc and a kernel src build folder but obviously not the whole tree. I could upload it if you are curious

mike

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#6 Post by mikeb »

This is a stripped down kernel source tree. It is INCOMPLETE!
It's used if you build a kernel modules for your devices,
but it can't be used to build completely new kernel.
from the aforementioned dev module src folder.

My interest in size is simply the possibility of its tidy inclusion with little space penalty compared to a full inventory of built modules and firmware.

mike

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#7 Post by mikeb »

Ok a quick refresher for me .. been a year or two since I last touched on this... it does appear to be a case of removing the drivers to reduce the size ... heres a screenie of before and after. I basically followed the pattern for other kernel dev files.

mike
Attachments
dev.png
(46.49 KiB) Downloaded 352 times

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#8 Post by Ibidem »

amigo wrote:You have to have the (mostly) full kernel sources to compile modules for it. And the sources need to have been configured and partially built. At any rate, I'm quite sure my 'dev', or whatever you kids call it these days..., is much bigger than yours.

Oh, sorry... Dipping into my sources I find my build script for the kernel sources package, which does this:

Code: Select all

cp /path/to/regular/kernel/config .config
make oldconfig
make
make clean
This leaves your sources properly configured, and with the Kconfig binaries intact for compiling in-tree or out-of-tree modules from source.
Debian does not use full kernel sources for building modules. It has a special install of the unstripped headers, .config, and the build system.
This is actually packaged up by the regular kernel build scripts (

Code: Select all

make deb-pkg
in vanilla kernel.org linux).

...
From what I understand, the kernel developers interpret the GPL a bit more laxly than the FSF, with the minimum being "fetch tarball linux-x.y, (maybe) apply this patch, use this .config"...of course, even companies that fail to comply with this rarely get sued outside Germany--so I could be mistaking lax enforcement with lax interpretation.
And they seem to treat many things that lets you do that as compatible with the GPL (see arch/arm/nwfpe/softfloat.c, released under a license the FSF does not consider GPL-compatible.)

User avatar
Karl Godt
Posts: 4199
Joined: Sun 20 Jun 2010, 13:52
Location: Kiel,Germany

#9 Post by Karl Godt »

Nothing that would likely fit here , but I started to build the kernels without AUFS module ,
and other Puppy Patches like the Loglevel-Patch since I am running full installations mainly .

And I don't build a kernel often, since the 3.y series doesn't give me much .

However, I started to

Code: Select all

git init
git remote add linux-stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git remote -v
git pull linux-stable
for i in 0 1 2 3 4 5 6 7 8 9 do
git checkout linux-2.6.3${i}.y
git branch
sleep 2s
done
800-1000 MB download !

User avatar
puppyluvr
Posts: 3470
Joined: Sun 06 Jan 2008, 23:14
Location: Chickasha Oklahoma
Contact:

#10 Post by puppyluvr »

:D Hello,
My last kernel I`m using now with aufs and the Puppy patches:
Image

Thats just one kernel.. I have many.. plus Woof for lucid, precise, arch, debian, t2, (and one I tried to woof fedora with), plus Unleashed..
My "Woof" directory alone is (via df -h) 191gb.. 8)

My "dev" is huge.........
Close the Windows, and open your eyes, to a whole new world
I am Lead Dog of the
Puppy Linux Users Group on Facebook
Join us!

Puppy since 2.15CE...

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#11 Post by mikeb »

Debian does not use full kernel sources for building modules. It has a special install of the unstripped headers, .config, and the build system.
This is actually packaged up by the regular kernel build scripts (
Code:
make deb-pkg
in vanilla kernel.org linux).
thanks for the info....

So not a major task then .... So drivers build on demand with a mini dev ... any thoughts assuming mini devs are feasible?

mike

Post Reply