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 she
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
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 i
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 calli
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 th
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 si
>
> 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, 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.
> > > >
> > > >
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 i
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:
> > > On Wed, Jun 18, 2008 at 09:20:22AM +0100, David Woodhouse wrote:
> > > > On Wed, 2008-06-18 at 09:47 +0300, Gilad Ben-Yos
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, 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 ha
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.
>
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 th
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 th
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,
[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 module
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
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. (O
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...
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
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
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 o
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
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
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 wi
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
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
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.
.
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 in
30 matches
Mail list logo
