Tim Bird wrote:
Gilad Ben-Yossef wrote:
Tim Bird wrote:
I agree. When you say have the application call modprobe directly,
I'm not sure I understand what you mean.
I simply meant that you can fork and exec modprobe itself (or use
system() but that
would require a working
Gilad Ben-Yossef wrote:
Tim Bird wrote:
I agree. When you say have the application call modprobe directly,
I'm not sure I understand what you mean.
I simply meant that you can fork and exec modprobe itself (or use
system() but that
would require a working shell). This would save the need
Tim Bird wrote:
Gilad Ben-Yossef wrote:
Well, seeing as both modprobe and a minimal shell are part of busybox
which is included in over 90%+ of Linux based embedded systems and that
the script is trivial, not to mention that you can just have the
application call modprobe directly, just as
Gilad Ben-Yossef wrote:
Well, seeing as both modprobe and a minimal shell are part of busybox
which is included in over 90%+ of Linux based embedded systems and that
the script is trivial, not to mention that you can just have the
application call modprobe directly, just as it will be calling
[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
On Wed, 2008-06-18 at 09:47 +0300, Gilad Ben-Yossef wrote:
This may sound like a stupid question, but why are you compiling the
modules statically?
I wondered that.
One potential reason to avoid modules is that they waste RAM -- you have
to allocate an integral number of pages for each one,
On Wed, 2008-06-18 at 09:20 +0100, David Woodhouse wrote:
So the only real reason I can see to avoid modules in the _current_
kernel would be the wasted RAM, which should be something we can
address. Tim, have I missed something?
... like the time it takes to actually load modules and do the
On Wed, Jun 18, 2008 at 09:20:22AM +0100, David Woodhouse wrote:
On Wed, 2008-06-18 at 09:47 +0300, Gilad Ben-Yossef wrote:
This may sound like a stupid question, but why are you compiling the
modules statically?
I wondered that.
One potential reason to avoid modules is that they waste
On Wed, 18 Jun 2008, Adrian Bunk wrote:
On Wed, Jun 18, 2008 at 09:20:22AM +0100, David Woodhouse wrote:
On Wed, 2008-06-18 at 09:47 +0300, Gilad Ben-Yossef wrote:
This may sound like a stupid question, but why are you compiling the
modules statically?
I wondered that.
One
On Wed, Jun 18, 2008, Stefan Richter wrote:
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
On Wed, 2008-06-18 at 10:57 +0200, Geert Uytterhoeven wrote:
On Wed, 18 Jun 2008, Adrian Bunk wrote:
On Wed, Jun 18, 2008 at 09:20:22AM +0100, David Woodhouse wrote:
On Wed, 2008-06-18 at 09:47 +0300, Gilad Ben-Yossef wrote:
This may sound like a stupid question, but why are you
On Wed, 2008-06-18 at 13:33 +0300, Adrian Bunk wrote:
But even after all optimizations CONFIG_MODULES=y will still cause a
significant additional cost [1] when thinking in the dimensions of
Tim's the 30 or so Linux-tiny patches that I use get me about 110k of
reductions. For me, this is
On Wed, 18 Jun 2008, Adrian Bunk wrote:
On Wed, Jun 18, 2008 at 10:59:50AM +0100, David Woodhouse wrote:
On Wed, 2008-06-18 at 10:57 +0200, Geert Uytterhoeven wrote:
On Wed, 18 Jun 2008, Adrian Bunk wrote:
You miss the size increase imposed by CONFIG_MODULES=y.
E.g. setting
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.
I landed in same
On Wed, 18 Jun 2008, Geert Uytterhoeven wrote:
On Wed, 18 Jun 2008, Adrian Bunk wrote:
On Wed, Jun 18, 2008 at 10:59:50AM +0100, David Woodhouse wrote:
On Wed, 2008-06-18 at 10:57 +0200, Geert Uytterhoeven wrote:
On Wed, 18 Jun 2008, Adrian Bunk wrote:
You miss the size increase
Gilad Ben-Yossef wrote:
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
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
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.
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
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
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
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
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
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
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?
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()
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
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?
28 matches
Mail list logo
