Re: Recommendation for activating a deferred module init in the kernel
[Resending due to reject from vger mail server. My apologies if you got this twice ] Hi, Tim Bird wrote: I am working with a product team on bootup time issues. One technique that we are forward-porting from an old kernel (and that I thought I might work on mainlining) is to compile modules statically into the kernel, but defer their initialization until after boot time. This may sound like a stupid question, but why are you compiling the modules statically? I mean, it sounds to me like the perfect way to do what you want is to compile the modules dynamically (you can store them in a an in kernel initramfs if you want to keep them attached to the kernel binary for ease of maintenance) and simply call a script that calls modprobe when it's OK to load them? Sounds a hell of lot simpler to me... Gilad -- Gilad Ben-Yossef Chief Coffee Drinker Codefidence Ltd. The code is free, your time isn't.(TM) Web:http://codefidence.com Email: [EMAIL PROTECTED] Office: +972-8-9316883 ext. 201 Fax:+972-8-9316885 Mobile: +972-52-8260388 Q: How many NSA agents does it take to replace a lightbulb? A: dSva7DrYiY24yeTItKyyogFXD5gRuoRqPNQ9v6WCLLywZPINlu! -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommendation for activating a deferred module init in the kernel
Johannes Stezenbach wrote: I think the USB bus enumeration can take significant time: recognize a device is connected, turn on bus power, try to read descriptors (bus powered devices might be slow to respond after power up). And this will happen even with drivers_autoprobe == 0, right? Probably... I don't know which particular steps happen in the USB core before upper layer drivers are bound. Not binding the [eou]hci-hcd PCI driver would certainly be more effective. -- Stefan Richter -=-==--- -==- =--=- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommendation for activating a deferred module init in the kernel
On Wed, Jun 18, 2008 at 12:48:27AM +0200, Stefan Richter wrote: >>> On Tue, 17 June 2008 12:55:31 -0700, Tim Bird wrote: > On Tue, 17 Jun 2008 11:28:29 -0700, Tim Bird wrote: > | One of the main sub-systems that we defer initialization of this > | way is USB, and this saves quite a bit of time. (Of course the > | same, or slightly more CPU cycles are eventually used during > | bootup time. But this lets us get to user space quicker so we > | can start user-visible applications faster.) > > What if you don't defer module initialization, but merely device probing? ... > If you set /sys/bus/foo/drivers_autoprobe to 0 (default is 1), then a > /sys/bus/foo/drivers/bar will not be bound to devices. You can trigger > driver--device binding later per device by writing a device's bus ID > into /sys/bus/foo/drivers/bar/bind, or by writing into > /sys/bus/foo/drivers_probe (I guess; I only used the per-device way so > far). I think the USB bus enumeration can take significant time: recognize a device is connected, turn on bus power, try to read descriptors (bus powered devices might be slow to respond after power up). And this will happen even with drivers_autoprobe == 0, right? OTOH I think just calling the module init function when no devices are present on the bus doesn't need much time. If you could delay the enumeration it would not be neccessary to mess with drivers_autoprobe. However, I don't know enough about USB so I don't know how to do it... Johannes -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommendation for activating a deferred module init in the kernel
On Tue, 17 June 2008 12:55:31 -0700, Tim Bird wrote: Sorry - I responded too quickly. I'm not sure I follow the original suggestion. How would I call the open function of a module that is not initialized yet? You will be able to open a character device file as soon as cdev_init() finished... when the Big Kernel Lock is not being taken around file_operations.open() anymore. On Tue, 17 Jun 2008 11:28:29 -0700, Tim Bird wrote: | One technique | that we are forward-porting from an old kernel (and that I thought I | might work on mainlining) is to compile modules statically into the | kernel, but defer their initialization until after boot time. ... | One of the main sub-systems that we defer initialization of this | way is USB, and this saves quite a bit of time. (Of course the | same, or slightly more CPU cycles are eventually used during | bootup time. But this lets us get to user space quicker so we | can start user-visible applications faster.) What if you don't defer module initialization, but merely device probing? $ ls /sys/bus/*/drivers_autoprobe /sys/bus/acpi/drivers_autoprobe /sys/bus/firewire/drivers_autoprobe /sys/bus/i2c/drivers_autoprobe /sys/bus/ide/drivers_autoprobe /sys/bus/pci/drivers_autoprobe /sys/bus/pci_express/drivers_autoprobe /sys/bus/platform/drivers_autoprobe /sys/bus/pnp/drivers_autoprobe /sys/bus/scsi/drivers_autoprobe /sys/bus/serio/drivers_autoprobe /sys/bus/usb/drivers_autoprobe If you set /sys/bus/foo/drivers_autoprobe to 0 (default is 1), then a /sys/bus/foo/drivers/bar will not be bound to devices. You can trigger driver--device binding later per device by writing a device's bus ID into /sys/bus/foo/drivers/bar/bind, or by writing into /sys/bus/foo/drivers_probe (I guess; I only used the per-device way so far). Now, since you want to do this with statically linked drivers, i.e. need to prevent probing before userspace and sysfs are up and running, you probably need to modify the bus types or/and the driver core so that the the less vital buses have drivers_autoprobe off by default. On the other hand, maybe you want to have probes of some PCI drivers executed but not the probes of some other PCI drivers; uhci_hcd for example. I guess you could achieve that by modifying drivers/pci/pci-driver.c::pci_bus_match(). E.g. add a sysfs attribute to pci-driver.c which, as long as containing its initial value, lets bus_match skip certain unwanted drivers (or match only whitelisted drivers). Later, userspace writes into the extra sysfs attribute and into the standard driver core sysfs attributes to trigger the deferred driver probes. -- Stefan Richter -=-==--- -==- =--=- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommendation for activating a deferred module init in the kernel
On Tue, 17 Jun 2008 22:23:19 +0200 Jörn Engel <[EMAIL PROTECTED]> wrote: > On Tue, 17 June 2008 12:55:31 -0700, Tim Bird wrote: > > > > Sorry - I responded too quickly. I'm not sure I follow the > > original suggestion. How would I call the open function of > > a module that is not initialized yet? > > Hmm, good point. I guess that suggestion has just failed the reality > test. Have a simple module that calls the initialization functions for anything with a deferred init. Then you can open that and use an ioctl to... I think if we try really really hard, we can make this a Rube-Goldberg Machine! josh -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommendation for activating a deferred module init in the kernel
On Tue, 17 June 2008 12:55:31 -0700, Tim Bird wrote: > > Sorry - I responded too quickly. I'm not sure I follow the > original suggestion. How would I call the open function of > a module that is not initialized yet? Hmm, good point. I guess that suggestion has just failed the reality test. Jörn -- You ain't got no problem, Jules. I'm on the motherfucker. Go back in there, chill them niggers out and wait for the Wolf, who should be coming directly. -- Marsellus Wallace -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommendation for activating a deferred module init in the kernel
On Tue, 17 June 2008 12:52:22 -0700, Tim Bird wrote:
> Jörn Engel wrote:
> > On Tue, 17 June 2008 11:23:18 -0700, Tim Bird wrote:
> >> I'm not that happy using an ioctl for this trigger. What is
> >> the preferred method of activating a kernel feature like this?
> >> I presume something in /proc or /sys, but I'm not sure.
> >
> > I personally would be unhappy with any kind of interface for this. It
> > would be much nicer to make it transparent and still get the benefits.
> > One option would be to start a kernel thread for the initialization and
> > renice it to 19 or so.
>
> That's an interesting idea. I'm pretty sure the product guys want
> an explicit trigger, so they can make sure they've got the main
> application well underway before this deferred initialization occurs.
Well, there should be a way to ensure this doesn't hog the cpu at all -
unless it is idle or someone is actually waiting for the initialization
to finish. Not sure if nice 19 is good enough for that.
> > If you want an explicit trigger, you could either hook into init_post()
> > or have hooks in the open functions of drivers with deferred
> > initialization.
>
> This would presumably require multiple calls (one to the open of
> each deferred module). I would still need a trigger for the memory
> free operation, unless I hardcode the order of the opening and just
> "know" that the last one should free the memory. I'll have to see
> if all the modules being loaded like this have open()s.
If you want to keep things simple - and I believe initially you should -
you can simply do all initializations in one go. Something like this:
int foo_open(...)
{
wait_for_deferred_init();
...
}
static DECLARE_COMPLETION(init_complete);
void wait_for_deferred_init(void)
{
static atomic_t in_progress = ATOMIC_INIT(-1);
if (!atomic_inc_not_zero(in_progress) {
wait_for_completion(init_complete);
return;
}
for (all deferred initcalls)
foo_init();
complete(init_complete);
free_memory();
}
Jörn
--
Anything that can go wrong, will.
-- Finagle's Law
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommendation for activating a deferred module init in the kernel
Jim Freeman wrote: > Run modprobe? Have it do just the _init bits without a load/link > of the actual module text? Interesting... Maybe I could overload sys_init_module(). I'll take a look at this. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommendation for activating a deferred module init in the kernel
Tim Bird wrote: >> If you want an explicit trigger, you could either hook into init_post() >> or have hooks in the open functions of drivers with deferred >> initialization. > > This would presumably require multiple calls (one to the open of > each deferred module). I would still need a trigger for the memory > free operation, unless I hardcode the order of the opening and just > "know" that the last one should free the memory. I'll have to see > if all the modules being loaded like this have open()s. Sorry - I responded too quickly. I'm not sure I follow the original suggestion. How would I call the open function of a module that is not initialized yet? -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommendation for activating a deferred module init in the kernel
Jörn Engel wrote: > On Tue, 17 June 2008 11:23:18 -0700, Tim Bird wrote: >> I'm not that happy using an ioctl for this trigger. What is >> the preferred method of activating a kernel feature like this? >> I presume something in /proc or /sys, but I'm not sure. > > I personally would be unhappy with any kind of interface for this. It > would be much nicer to make it transparent and still get the benefits. > One option would be to start a kernel thread for the initialization and > renice it to 19 or so. That's an interesting idea. I'm pretty sure the product guys want an explicit trigger, so they can make sure they've got the main application well underway before this deferred initialization occurs. > > If you want an explicit trigger, you could either hook into init_post() > or have hooks in the open functions of drivers with deferred > initialization. This would presumably require multiple calls (one to the open of each deferred module). I would still need a trigger for the memory free operation, unless I hardcode the order of the opening and just "know" that the last one should free the memory. I'll have to see if all the modules being loaded like this have open()s. Thanks for the ideas! -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommendation for activating a deferred module init in the kernel
On Tue, Jun 17, 2008 at 09:07:51PM +0200, J??rn Engel wrote: > On Tue, 17 June 2008 11:23:18 -0700, Tim Bird wrote: > > > > I'm not that happy using an ioctl for this trigger. What is > > the preferred method of activating a kernel feature like this? > > I presume something in /proc or /sys, but I'm not sure. > > I personally would be unhappy with any kind of interface for this. It > would be much nicer to make it transparent and still get the benefits. > One option would be to start a kernel thread for the initialization and > renice it to 19 or so. > > If you want an explicit trigger, you could either hook into init_post() > or have hooks in the open functions of drivers with deferred > initialization. Obviously you need to wait for completion here anyway, > so adding a trigger wouldn't be too expensive. Run modprobe? Have it do just the _init bits without a load/link of the actual module text? > J??rn > > -- > Joern's library part 13: > http://www.chip-architect.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommendation for activating a deferred module init in the kernel
On Tue, 17 June 2008 11:23:18 -0700, Tim Bird wrote: > > I'm not that happy using an ioctl for this trigger. What is > the preferred method of activating a kernel feature like this? > I presume something in /proc or /sys, but I'm not sure. I personally would be unhappy with any kind of interface for this. It would be much nicer to make it transparent and still get the benefits. One option would be to start a kernel thread for the initialization and renice it to 19 or so. If you want an explicit trigger, you could either hook into init_post() or have hooks in the open functions of drivers with deferred initialization. Obviously you need to wait for completion here anyway, so adding a trigger wouldn't be too expensive. Jörn -- Joern's library part 13: http://www.chip-architect.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recommendation for activating a deferred module init in the kernel
Tim Bird wrote: Hi all, I am working with a product team on bootup time issues. One technique that we are forward-porting from an old kernel (and that I thought I might work on mainlining) is to compile modules statically into the kernel, but defer their initialization until after boot time. ... One of the main sub-systems that we defer initialization of this way is USB, and this saves quite a bit of time. (Of course the same, or slightly more CPU cycles are eventually used during bootup time. But this lets us get to user space quicker so we can start user-visible applications faster.) I'm not that happy using an ioctl for this trigger. What is the preferred method of activating a kernel feature like this? I presume something in /proc or /sys, but I'm not sure. From your description, it seems as though you always want to do the initialization, you just may want to delay it until well after starting up user space. If something like this were performance-critical, an ioctl might be justified, but this would be a one-time trigger. I think that making this as closely analogous to loading a kernel module as possible is a good conceptual approach. Since you might choose, at run time, whether or not to load a kernel module, it makes sense to do this on a device-by-device basis. To me, that suggests doing something in /sys. My first impression was that this was an awful kludge, but drawing the parallel to loadable modules makes me not only happier, but also leads me into wondering if there shouldn't be a generic framework for supporting this. So, instead of using module_init, there might be some other macro that indicated that this driver was to be initialized in a deferred, and optional, fashion. -- David VomLehn, [EMAIL PROTECTED] The opinions expressed herein are likely mine, but might not be my employer's... - - - - - Cisco- - - - - This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Recommendation for activating a deferred module init in the kernel
Hi all, I am working with a product team on bootup time issues. One technique that we are forward-porting from an old kernel (and that I thought I might work on mainlining) is to compile modules statically into the kernel, but defer their initialization until after boot time. Normally, module init routines are declared with module_init(), which, when they are statically linked into the kernel, uses the macro __define_initcall() to add an entry to a special init segment. This is called during bootup by do_initcall() (in init/main.c), and the memory where the function resides is eventually freed. There are several phases of initcalls (see include/linux/init.h), including core, postcore, arch, subsys, fs, rootfs, device, and late. In our modification, we: 1) add another phase for deferred initcalls 2) modify the module_init macro definition to use that phase, for the modules we wish to defer initialization of 3) modify the free code to not free the memory until later 4) add an ioctl to trigger the deferred initialization (and memory free) One of the main sub-systems that we defer initialization of this way is USB, and this saves quite a bit of time. (Of course the same, or slightly more CPU cycles are eventually used during bootup time. But this lets us get to user space quicker so we can start user-visible applications faster.) I'm not that happy using an ioctl for this trigger. What is the preferred method of activating a kernel feature like this? I presume something in /proc or /sys, but I'm not sure. Also, is there something like this in the kernel now that I'm missing? Any advice or comments would be welcome. Thanks, -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
On Tuesday 17 June 2008 15:46:36 Enrico Weigelt wrote: > * Alexander Neundorf <[EMAIL PROTECTED]> schrieb: > > On Monday 16 June 2008 17:15:37 Enrico Weigelt wrote: > > > * Alexander Neundorf <[EMAIL PROTECTED]> schrieb: > > > > CMake has a cache, where the values of variables are stored, e.g. if > > > > an option is enabled or not, or where a library has been found (e.g. > > > > JPEG_LIBRARY=/usr/local/lib/libjpeg.so). > > > > The way to influence the behaviour of cmake is to change the value of > > > > these variables, this can be done either via a GUI (curses based or > > > > with cmake 2.6 also a graphical one), or via the command line: > > > > $ cmake -D= ...more options > > > > > > Are these variables strictly specified or is all left to individual > > > author's decision ? > > > > Authors decision. > > Then you've got the same problem as w/ autoconf's config.status: > You have to tweak it for each individual package separately :( Well, these are all more or less scripting languages, so people can create whichever variables they like, no way to enforce something. Still one can suggest standards which should be followed. Alex -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
* Rob Landley <[EMAIL PROTECTED]> schrieb: Hi, > You can't get away from cross compiling whenever you want to bootstrap a new > platform. But cross compiling can be minimized and encapsulated. It can be > a stage you pass through to get it over with and no longer have to deal with > it on the other side, which is the approach I take. That's not enought for me. I want more encapsulation (yes, but buildfarm is also running in a VZ, but still sysroot'ed). For example, I *want* certain tests (like running target code) to fail, since I *do not* trust them. (btw: I also let compiler warnings fail, just to be sure). I, personally, prefer high build-time constraints, because runtime tests are quite limited. > By my count sysroot is the fifth layer of path logic the gcc guys have added > in an attempt to paint over the dry rot. I see this as a quite good separation between running and target system, just one more fence for clear borders. As long as you don't pass absolute search pathes to it, you can be sure that it doesn't mix up target and host. Actually, I never want to crosscompile w/o it. > Personally I use a derivative of the old uClibc wrapper script that rewrites > the command line to start with "--nostdinc --nostdlib" and then builds it > back up again without having any paths in there it shouldn't. Might work, but then you're limited to some specific cases. If you *only* intent bootstrapping of an minimal system, fine, but for my projects too complex to handle. > > #2: fix broken configure.in's (and feed back to upstream or OSS-QM) > > Whack-a-mole. Fun for the whole family. Only problem is, it never stops. Most times, it as only to be done one per package. And it's an clean solution. > > #3: replace libtool by unitool > > Uninstall libtool and don't replace it with anything, it's a NOP on Linux. The problem is: many packages are entirely built upon this. So you'll have to de-libtoolize them. Very much work. As I already had Unitool, I preferred investing just a few hours for creating an generic drop-in replacement for libtool instead of touching each single package. > > Only crap sw looks at /proc at build time. > > Yes, there's *much* crap sw out there :( > > 99% of all the developers out there don't really care about portability, and > never will. Even if you eliminate the windows guys and the people who don't > do C, 90% of the people who are _left_ get to work on the PC first, get it to > work natively on other Linux platforms afterwards. True :( Some packages out there even don't have an clean native build path, eg. requiring parts of the package already built and installed (-> firebird-db) > Cross compiling is a step beyond "portability". They'll _never_ care about > cross compiling. If they get inspired to make it work on MacOS X, then > you'll have to extract the source and _build_ it on MacOS X to make that > work. And 99% of all developers will nod their heads and go "quite right, as > it should be". > > This isn't going to change any time soon. Actually, I don't care much about that. I concentrate on getting those packages I need cleaned-up and crosscompile'able - even if this means going alone and maintaining an own branch. If I sum up all the invested working hours of all the last years on that and substract the total saved time from other projects where I'm reusing this work, I get a positive balance ;-P cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
* Adrian Bunk <[EMAIL PROTECTED]> schrieb: Hi, > > I won't to that w/ my TreeBuild. It is intentionally limited on > > easily structured packages. People should either structure their > > packages properly use something else ;-P > > For simple packages autoconf+automake+libtool is already near at your > descriptive paragidm. Yes, but mine is much simpler and syntactically stable. With autotools there are uncountable things you can do wrong, without even noticing - it needs *very* much care. In TreeBuild there's almost no room for those mistakes. A simple typo can lead autoconf to unpredictable behaviour - TreeBuild spits out an parse error. So for these cases (which already make up a very large number of total packages in the world), maintaining buildfiles becomes a lot easier ;-P > And despite all nasty details of autoconf/automake/libtool they also > have advantages: > - they are quite powerful when you know how to handle them The point is: you *must* know autotools very well, otherwise you soon run into pitfalls. > - they allow to build your software on non-Linux systems TreeBuild does that too, as soon as someone wrote a proper config for another platform. The design is platform agnostic, just lacking ports to other platforms, due lack of (my) time. > - they are the de-facto standard in the open source world, and everyone > building open source software knows them I don't think that this is a good argument. M$-Word is also an "de facto" standard ;-P > And the last point is a very important one: > > For me as someone who is often compiling software your plan of creating > yet another build tool I have to handle does not sound like a good idea. Yes, but that's not a problem of TreeBuild, but the total count of different build systems around the world. That's why a new buildsystem should be an really good solution for an reasonable class of problems and should be easy to learn. IMHO, TreeBuild does this - for simple structed packages. (which make up about 99% of my own ones). Of course, TreeBuild still in an early development stage. So I don't claim it's really usable for everyone - for now it's more an academic issue. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cross-compiling alternatives (was Re: [PATCH 0/1] Embedded Maintainer(s)...)
* Alexander Neundorf <[EMAIL PROTECTED]> schrieb: > On Monday 16 June 2008 17:15:37 Enrico Weigelt wrote: > > * Alexander Neundorf <[EMAIL PROTECTED]> schrieb: > > > CMake has a cache, where the values of variables are stored, e.g. if an > > > option is enabled or not, or where a library has been found (e.g. > > > JPEG_LIBRARY=/usr/local/lib/libjpeg.so). > > > The way to influence the behaviour of cmake is to change the value of > > > these variables, this can be done either via a GUI (curses based or with > > > cmake 2.6 also a graphical one), or via the command line: > > > $ cmake -D= ...more options > > > > Are these variables strictly specified or is all left to individual > > author's decision ? > > Authors decision. Then you've got the same problem as w/ autoconf's config.status: You have to tweak it for each individual package separately :( My destiny is to have strictly standardized variables for all the common things, so you can use an global per-target configuration for *all* packages ever coming. That's what Unitool's system properties db is for. > > hmm, why not just expecting an sane shell on the building system ? > > (as you already have to expect a sane compiler) > > Well, we could go so far to expect a "sane" operating system, but you can't > change it, there are "insane" people in the world ;-) Many, many things can be done within in the toolchain, eg. fixes for broken libc's. For example, I've seen packages adding several missing functions for certain platforms - this should be the job of the toolchain. cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ - -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
