Prev: [RFC] Tight check of pfn_valid on sparsemem
Next: sparc: move is_root_node from private header to of.h
From: David Brown on 12 Jul 2010 19:40
On Monday 12 July 2010 16:18:01 Linus Torvalds wrote:

> 2010/7/12 David Brown <davidb(a)codeaurora.org>:
> >
> > Do you have scripts or tools that you did this with, or is a manual
> > process. We're about to add several new (ARM) targets, and it'd be
> > nice to be able to make small defconfigs for those targets as well.
>
> Uwe posted it earlier in this thread as an attachement, and I put the
> python script into the merge commit message too. And we should
> probably put it somewhere in scripts too, and/or make a 'make' target
> to create the small config files.
>
> I pushed it all out, and tagged it as -rc5.

Got it, thanks. I just pulled a bit soon.

It seems a bit brute force, probably not something I can make part of
our regular build process, but I can definitely run it before sending
patches out.

I wonder if there's a more efficient way of doing it that doesn't
involve invoking make for each line of the file. It at least
shouldn't be necessary to actually build the kernel each time.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Nicolas Pitre on 12 Jul 2010 21:00
On Mon, 12 Jul 2010, David Brown wrote:

> On Monday 12 July 2010 16:18:01 Linus Torvalds wrote:
>
> > 2010/7/12 David Brown <davidb(a)codeaurora.org>:
> > >
> > > Do you have scripts or tools that you did this with, or is a manual
> > > process. We're about to add several new (ARM) targets, and it'd be
> > > nice to be able to make small defconfigs for those targets as well.
> >
> > Uwe posted it earlier in this thread as an attachement, and I put the
> > python script into the merge commit message too. And we should
> > probably put it somewhere in scripts too, and/or make a 'make' target
> > to create the small config files.
> >
> > I pushed it all out, and tagged it as -rc5.
>
> Got it, thanks. I just pulled a bit soon.
>
> It seems a bit brute force, probably not something I can make part of
> our regular build process, but I can definitely run it before sending
> patches out.
>
> I wonder if there's a more efficient way of doing it that doesn't
> involve invoking make for each line of the file. It at least
> shouldn't be necessary to actually build the kernel each time.

I'm sure that some clever people will come up with a better script
eventually. Maybe this could even be generated by scripts/kconfig/conf
directly.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Uwe Kleine-König on 13 Jul 2010 03:10
Hi

On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> <torvalds(a)linux-foundation.org> wrote:
> > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico(a)fluxnic.net> wrote:
> >> I think Uwe could provide his script and add it to the kernel tree.
> >> Then all architectures could benefit from it. �Having the defconfig
> >> files contain only those options which are different from the defaults
> >> is certainly more readable, even on x86.
> >
> > Quite possible. But maintainers would need to be on the lookout of
> > people actually using the script, and refusing to apply patches that
> > re-introduce the whole big thing.
>
> I can (partially) speak for powerpc. If ARM uses this approach, then
> I think we can do the same. After the defconfigs are trimmed, I
> certainly won't pick up any more full defconfigs.
I just restarted my script on the powerpc defconfigs basing on rc5, I
assume they complete in a few days time.

> Of course, I'm also operating under the assumption that this is a
> temporary measure until one of the better solutions is implemented.
ack

> I
> do suspect that the trimmed defconfigs will tend to be unstable and
> will still require manual maintenance. I think the Kconfig fragments
> approach is the most promising if the dependencies issue can be
> solved.
I don't understand what you mean with unstable here. They are sensible
to changed defaults in the Kconfig files which you can consider to be
good or bad.

And ack, I like the Kconfig approach, too.

Best regards
Uwe

--
Pengutronix e.K. | Uwe Kleine-K�nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Grant Likely on 13 Jul 2010 14:40
2010/7/13 Uwe Kleine-K�nig <u.kleine-koenig(a)pengutronix.de>:
> Hi
>
> On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
>> On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
>> <torvalds(a)linux-foundation.org> wrote:
>> > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico(a)fluxnic.net> wrote:
>> >> I think Uwe could provide his script and add it to the kernel tree.
>> >> Then all architectures could benefit from it. �Having the defconfig
>> >> files contain only those options which are different from the defaults
>> >> is certainly more readable, even on x86.
>> >
>> > Quite possible. But maintainers would need to be on the lookout of
>> > people actually using the script, and refusing to apply patches that
>> > re-introduce the whole big thing.
>>
>> I can (partially) speak for powerpc. �If ARM uses this approach, then
>> I think we can do the same. �After the defconfigs are trimmed, I
>> certainly won't pick up any more full defconfigs.
> I just restarted my script on the powerpc defconfigs basing on rc5, I
> assume they complete in a few days time.
>
>> Of course, I'm also operating under the assumption that this is a
>> temporary measure until one of the better solutions is implemented.
> ack
>
>> � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �I
>> do suspect that the trimmed defconfigs will tend to be unstable and
>> will still require manual maintenance. �I think the Kconfig fragments
>> approach is the most promising if the dependencies issue can be
>> solved.
> I don't understand what you mean with unstable here. �They are sensible
> to changed defaults in the Kconfig files which you can consider to be
> good or bad.

With the trimmed config, changes to default settings on config items
will immediately picked up regardless of whether or not it was wanted,
and potentially disabling things that were explicitly selected in
defconfig. But thinking about it more, that isn't really any worse
than the old situation where defconfigs always override Kconfig
defaults. So either way, defconfigs are simply a broken concept.

> And ack, I like the Kconfig approach, too.

Yeah, the problem goes away with Kconfig fragments. A programmer can
then explicitly state which CONFIG values need to be overridden.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Rob Landley on 13 Jul 2010 14:40
On Monday 12 July 2010 18:18:01 Linus Torvalds wrote:
> 2010/7/12 David Brown <davidb(a)codeaurora.org>:
> > Do you have scripts or tools that you did this with, or is a manual
> > process. We're about to add several new (ARM) targets, and it'd be
> > nice to be able to make small defconfigs for those targets as well.
>
> Uwe posted it earlier in this thread as an attachement, and I put the
> python script into the merge commit message too. And we should
> probably put it somewhere in scripts too, and/or make a 'make' target
> to create the small config files.
>
> I pushed it all out, and tagged it as -rc5.

FYI, I repeatedly submitted a bash script to do this back in 2005, with
documentation and makefile changes to call it and so on.

http://lwn.net/Articles/161086/

The current version of that script is is in my mercurial archive here:

http://impactlinux.com/hg/hgwebdir.cgi/aboriginal/file/tip/sources/toys/miniconfig.sh

I'm still using it in my Aboriginal Linux project. (Not just for the kernel,
but for busybox and uClibc too.)

Attached are miniconfigs I use for a dozen or so QEMU targets. (The project is
trying to build kernels aimed at every qemu system emulation. I've got maybe
2/3 of them so far. Arm, mips, sh4, x86, x86_64, sparc...)

They're used to create the system-image tarballs here:

http://impactlinux.com/aboriginal/downloads/binaries/

You can download that for that target that interests you, extract it, and use
run-emulator.sh to launch it under qemu. I have a cron job that does cross-
platform regression testing, spitting /dev/console to a log file on the host.

By the way, my build is generating those miniconfigs via a common "baseconfig"
file to which I append the target-specific stuff. For example, my current
baseconfig is:

CONFIG_EXPERIMENTAL=y
CONFIG_NO_HZ=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_PCI=y
CONFIG_BINFMT_ELF=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_IDE=y
CONFIG_IDE_GD=y
CONFIG_IDE_GD_ATA=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_PCI=y
CONFIG_8139CP=y
CONFIG_HW_RANDOM=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_DEV=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_TMPFS=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_MAGIC_SYSRQ=y

Then for mips I append:

CONFIG_MIPS_MALTA=y
CONFIG_CPU_MIPS32_R2=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
#CONFIG_PM=y
CONFIG_PCNET32=y
CONFIG_BLK_DEV_PIIX=y

Or for x86_64 it's:

CONFIG_ACPI=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_NETDEV_1000=y
CONFIG_E1000=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y

And for armv4tl it's this big long saga (yes, with comments):

# Processor config

# QEMU patch: http://www.mail-archive.com/qemu-devel(a)nongnu.org/msg19370.html
# and QEMU option '-cpu arm920t' enable CONFIG_CPU_ARM920T=y which is the
# processor that actually _needs_ this code. But until then, qemu can only
# emulate an armv5 CPU...

CONFIG_CPU_ARM926T=y
CONFIG_MMU=y
CONFIG_VFP=y
CONFIG_ARM_THUMB=y
CONFIG_AEABI=y

# Versatile board

CONFIG_ARCH_VERSATILE_PB=y
CONFIG_PCI_LEGACY=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_RTC_DRV_PL031=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_MMIO=y

Rob
--
GPLv3: as worthy a successor as The Phantom Meanace, as timely as Duke Nukem
Forever, and as welcome as New Coke.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [RFC] Tight check of pfn_valid on sparsemem
Next: sparc: move is_root_node from private header to of.h